Por qué un agente de IA no encuentra una respuesta que sí está en su base de conocimiento

Le preguntás algo a tu agente de IA sobre un tema que sabés que está documentado: en el manual de producto, en una política interna, en el historial de tickets. Y el agente responde "no tengo esa información" o, peor, inventa algo parecido pero incorrecto. La sospecha inmediata suele ser que el modelo es malo. La causa real, casi siempre, es otra: el modelo nunca llegó a leer el fragmento correcto.

¿Por qué un agente falla si la respuesta ya está en tus documentos?

Porque la mayoría de los agentes conectados a una base de conocimiento no leen todos los documentos cada vez que alguien pregunta algo. Primero buscan los fragmentos que parecen más relevantes para esa pregunta puntual (la técnica se llama RAG, retrieval augmented generation) y solo esos fragmentos llegan al modelo que genera la respuesta. Si la búsqueda trae los fragmentos equivocados, o no trae ninguno, el modelo nunca tiene la oportunidad de responder bien. No importa cuán bueno sea ese modelo.

Un paper de la Universidad de Deakin estudió esto en tres casos reales: dos sistemas ya en uso (uno para investigadores, otro para estudiantes) y un tercer experimento a mayor escala, con 15.000 documentos y 1.000 preguntas sobre temas biomédicos. De ahí salió un catálogo de siete puntos de falla distintos. Tres de esos siete pasan antes de que el modelo generador lea una sola palabra: falta la información en la base, el fragmento correcto existe pero no quedó entre los mejores resultados de la búsqueda, o quedó entre los resultados pero se perdió en el paso que junta y recorta todo antes de mandárselo al modelo. El error se cometió en la búsqueda, no en la respuesta.

Buscar por palabras o buscar por significado: los dos fallan, distinto

Antes de los LLMs, buscar información en muchos documentos ya era un problema resuelto, aunque de otra forma: por palabras clave, indexando qué término aparece en qué documento (la técnica clásica se llama BM25). Ese método falla cuando el cliente escribe distinto de como está escrito el documento: pregunta por "cancelar mi suscripción" y el documento dice "dar de baja el plan".

La búsqueda semántica que usa un RAG resuelve justo eso: convierte la pregunta y cada fragmento de documento en un vector, y busca los vectores más cercanos en significado, no en texto exacto. El costo aparece en otro lado, en cómo se corta cada documento en fragmentos. Un fragmento muy chico no tiene suficiente contexto para contestar preguntas que cruzan dos ideas. Uno muy largo diluye la parte relevante entre texto que no viene al caso, y esa parte de más termina compitiendo contra la respuesta real cuando el modelo tiene que decidir qué usar. (Cómo elegir el modelo de embeddings más apropiado para cada dominio es otra discusión, que da para un artículo aparte.)

¿Agregar más contexto arregla esto?

A veces. El mismo estudio encontró que ampliar el contexto que se le pasa al modelo, de 4.000 a 8.000 tokens en su caso, mejoró las respuestas. Pero hay un límite, y no es solo de tamaño: otra investigación sobre cómo los modelos de lenguaje usan contextos largos (Liu et al., 2023, "Lost in the Middle: How Language Models Use Long Contexts") encontró que la precisión cae cuando la información relevante queda en el medio de un contexto largo, ni al principio ni al final. Meter más documentos "por si acaso" no compensa una mala búsqueda. En algunos casos la empeora, porque agrega más lugares donde la respuesta correcta se puede perder de vista.

Lo que ya sabíamos antes de que existieran los LLMs

Buscar el dato correcto entre muchos documentos no es un problema que inventaron los modelos de lenguaje. Existía en buscadores, en sistemas de recomendación, en cualquier pipeline de machine learning de antes de 2020. Y la lección de esa época sigue sirviendo intacta: la calidad de lo que entra a un sistema (cómo está indexado, cómo está segmentado, qué tan bien preprocesado está) pone el techo de lo que ese sistema puede responder, más allá de qué tan sofisticado sea el paso final. Cambiar "modelo estadístico" por "modelo de lenguaje" no cambia esa dependencia; solo la esconde mejor, porque el paso final ahora escribe en prosa convincente incluso cuando no tenía con qué.

Antes entrenábamos a mano el modelo que tenía que corregir ese tipo de error. Hoy se escribe un prompt más prolijo esperando el mismo efecto. El problema de fondo, si el dato correcto llegó o no, es el mismo de siempre.

Qué mirar antes de cambiar de modelo

Cuando un agente responde mal algo que está documentado, conviene mirar un paso antes de tocar el prompt o cambiar de modelo: qué fragmento llegó a esa respuesta. La mayoría de las veces, la respuesta correcta nunca estuvo sobre la mesa. Ese paso (qué se buscó, qué se encontró, qué de eso se le mostró al modelo) es más fácil de auditar que de adivinar, y es ahí donde conviene mirar primero.

---

Fuentes: Barnett, Kurniawan, Thudumu, Brannelly y Abdelrazek, "Seven Failure Points When Engineering a Retrieval Augmented Generation System", Universidad de Deakin, 2024 (arxiv.org/abs/2401.05856). Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", 2023.