Los modelos de IA ya pueden leer de una sola vez el equivalente a varios libros. La conclusión parece evidente: si cabe todo, metámoslo todo. Es justo al revés. Cuanto más contexto recibe un modelo, más fácil es que razone peor.

Imaginemos un agente de atención al cliente que recibe una reclamación por un envío que ha llegado incompleto. Para ayudarle, alguien decide darle "todo lo que pueda necesitar": el historial completo de tickets del cliente, las condiciones generales, los últimos doce meses de pedidos, el manual de logística y tres versiones de la política de devoluciones.

La respuesta llega rápido. Bien redactada. Segura.

Y aplica la política de devoluciones del año pasado.

El modelo no se equivocó por falta de información. Se equivocó por exceso.

El deterioro del contexto

A este fenómeno se le empieza a llamar deterioro del contexto. La idea es sencilla: el rendimiento de un modelo no se mantiene estable a medida que crece lo que le damos a leer. Se degrada.

Un estudio reciente que evaluó 18 modelos de los principales proveedores lo puso a prueba con entradas cada vez más largas. Las conclusiones son incómodas para quien confía en la fuerza bruta:

  • Los modelos no usan el contexto de forma uniforme. Leer más no significa atender a todo por igual.
  • Las distracciones pesan. Basta un dato parecido pero incorrecto para que la precisión caiga, y cada distracción adicional lo empeora.
  • El efecto crece con la longitud. Lo que en un texto corto es un detalle inocuo, en uno largo se convierte en una trampa.
  • Con historiales largos de conversación, los resultados son claramente peores que cuando el modelo recibe solo la parte que importa.

Ninguna de esas pruebas era especialmente difícil. Lo que las hacía difíciles era el ruido.

Por qué las pruebas habituales no lo detectan

La forma clásica de medir si un modelo aprovecha un contexto largo es la llamada "aguja en un pajar": se esconde una frase concreta en un texto enorme y se le pide que la encuentre.

Los modelos actuales la superan con nota. Y eso ha alimentado la idea de que el reto de recuperar información ya está resuelto.

Pero la empresa no funciona así. En la empresa la aguja casi nunca es única. Hay diez agujas parecidas:

  • Tres tarifas para el mismo cliente: la vigente, la de la campaña anterior y la que se negoció pero nunca se firmó.
  • Dos fichas del mismo proveedor, una por cada sociedad del grupo.
  • Varias versiones de un procedimiento de cierre contable, con cambios de un trimestre a otro.
  • Un pedido que aparece en el ERP, en el correo y en una hoja de cálculo, con importes distintos.

Encontrar una frase no es el reto. El reto es saber cuál de las frases parecidas es la que vale.

Recuperar información no es buscar. Es razonar sobre qué es relevante y qué solo lo parece.

El reflejo de meterlo todo

¿Por qué se sigue llenando el contexto? Porque es lo más cómodo.

Decidir qué información necesita un agente para una tarea exige entender la tarea. Exige saber qué es un cliente, qué tarifa aplica, qué documento sustituye a cuál. Volcarlo todo, en cambio, no exige pensar. Se delega la decisión en el modelo.

Y el modelo no tiene forma de saber lo que la empresa no le ha explicado. Si recibe dos políticas de devoluciones sin ninguna indicación de cuál está en vigor, elegirá una. Y lo hará con total aplomo.

Las consecuencias operativas son concretas:

  • En compras, un asistente que compara ofertas con condiciones caducadas.
  • En finanzas, una conciliación que mezcla movimientos de dos sociedades porque comparten nombre comercial.
  • En comercial, una propuesta que recupera un descuento que se concedió una sola vez como excepción.
  • En logística, una previsión de entregas que pesa igual un retraso de hace tres años que uno de la semana pasada.

Además, más contexto también significa más coste y más tiempo de respuesta. Se paga más por razonar peor.

El contexto no es un almacén. Es una mesa de trabajo. Y una mesa llena no ayuda a trabajar.

De ampliar el contexto a diseñarlo

La alternativa tiene nombre: ingeniería de contexto. Consiste en tratar lo que recibe el modelo como algo que se diseña, no como algo que se maximiza.

Tres decisiones lo resumen:

  1. Qué entra. Solo la información que la tarea necesita, filtrada por vigencia, por entidad y por permisos.
  2. Cómo se presenta. Ordenada, etiquetada y con lo esencial a la vista, no enterrada entre páginas de texto.
  3. Qué se queda fuera. Lo parecido pero irrelevante, lo caducado, lo duplicado.

Volvamos a la reclamación del envío incompleto. Con un contexto diseñado, el agente no recibe doce meses de historia. Recibe el pedido concreto, el albarán, la política de devoluciones vigente para ese tipo de cliente y las incidencias abiertas con él. Un puñado de piezas en lugar de cientos.

Y responde mejor.

Comparativa entre contexto volcado, con historial sin filtrar, versiones duplicadas y tarifas caducadas mezcladas, y contexto diseñado, con solo las piezas necesarias, la versión vigente y cada dato anclado a un identificador real

Dónde encajan los grafos

Para seleccionar bien hay que saber qué es cada cosa y cómo se relaciona con las demás. Ese es justo el terreno de un grafo de conocimiento apoyado en una ontología: un modelo explícito del significado del negocio.

Un grafo así aporta cuatro cosas a la ingeniería de contexto:

  • Acota la búsqueda. Si la pregunta es sobre un pedido, el grafo sabe qué cliente, qué factura y qué contrato cuelgan de él. No hace falta buscar en todo.
  • Distingue lo parecido. Dos clientes con el mismo nombre son dos nodos distintos con identificadores distintos. La confusión deja de depender de la suerte.
  • Filtra con reglas. Vigencia, sociedad, estado de aprobación. Una tarifa caducada no entra, aunque se parezca mucho a la buena.
  • Explica la selección. Se puede reconstruir por qué una pieza entró en el contexto y otra no. Eso es auditable.
Cuatro pasos con los que un grafo prepara el contexto de un agente: identifica la entidad, recorre sus relaciones, filtra con reglas de vigencia, sociedad y permisos, y entrega un contexto compacto y trazable
Un modelo potente con el contexto equivocado es un experto mal informado. Responde con aplomo sobre lo que no debería.

Lo que esto cambia para la dirección

La conversación habitual sobre IA gira en torno al modelo: cuál es más grande, cuál lee más, cuál razona mejor. Es una carrera que se renueva cada pocos meses.

El contexto es otra conversación. Depende de cosas que solo la empresa puede resolver:

  • Saber qué información es la vigente y cuál ha quedado obsoleta.
  • Tener identificadores únicos para clientes, proveedores, productos y contratos.
  • Definir relaciones claras entre lo que hay en el ERP, en el CRM y en los documentos.
  • Decidir quién puede ver qué, porque un agente no debería recibir lo que su usuario no puede consultar.

Nada de esto lo resuelve una ventana de contexto más grande.

La ventana de contexto la pone el proveedor. Lo que entra en ella lo decide la empresa.

Esta es mi apuesta

Las ventanas de contexto seguirán creciendo, y es una buena noticia. Permiten trabajar con documentos largos y con tareas más complejas.

Pero creo que la diferencia no estará en cuánto puede leer un modelo, sino en lo bien que la empresa sabe elegir qué darle a leer. Esa capacidad no llega con la próxima versión del modelo. Se construye con datos ordenados, significado compartido y reglas claras sobre qué es relevante en cada momento.

Dar más contexto es fácil. Dar el contexto adecuado es lo que separa una IA que impresiona en una demo de una IA en la que se puede confiar cada día.