Por qué las respuestas de RAG parecen completas cuando la búsqueda de Azure DevOps demuestra que no lo son

Un sistema que carga la historia de Azure DevOps en una base de datos gráfica puede responder preguntas sobre proyectos, responsables y trabajo entregado mediante texto legible y citas accesibles por clic. Durante un tiempo eso pareció suficiente, hasta que las respuestas se comparaban contra un criterio básico y rudimentario: una consulta directa de Azure DevOps. La diferencia entre una respuesta pulida y una lista exhaustiva es donde la recuperación “completa” falla silenciosamente. Superar esa brecha requirió pasos deterministas, pruebas medibles y varias correcciones que a su vez generaron nuevos problemas.

La pregunta que reveló la brecha

Las preguntas iniciales generaron respuestas claras y bien fundamentadas, con poca invención. Una pregunta más amplia —“¿Qué trabajos de IA se están realizando en esta organización?”— también parecía adecuada: unos pocos párrafos, unas cuantas citas, nada obviamente incorrecto. La misma pregunta formulada mediante az boards query, una búsqueda de fuerza bruta sin inteligencia para clasificar resultados, devolvió docenas de elementos que la respuesta pulida nunca mencionó. No hubo resultados relacionados con la evaluación de asistentes de programación, la comparación de costos de modelos o la depuración de una herramienta específica, ya que compartían poca similitud en redacción con la pregunta y nunca aparecieron entre los primeros resultados de la búsqueda semántica.

Ese tipo de fallo es fácil de pasar por alto: una respuesta bien clasificada no equivale necesariamente a una respuesta completa, y el sistema no ofrece indicio alguno que indique cuál de las dos se recibió.

Una pregunta que solo a veces ayudó

El primer impulso fue instruir al modelo para que fuera más cuidadoso: en preguntas generales, debía revisar las etiquetas de categoría antes de responder en lugar de confiar únicamente en la búsqueda. Eso ayudó de forma intermitente. La misma redacción producía comportamientos diferentes en cada ejecución: a veces el modelo revisaba las etiquetas y otras veces las omitía. Nada cambiaba en la pregunta, solo si se seguía o no esa instrucción en ese turno.

Una instrucción dirigida a un modelo de lenguaje es un estímulo, no una garantía. Cuando la exhaustividad es importante, la minuciosidad no puede depender de que el modelo decida, en el momento, si ser minucioso o no.

Hacer que el camino sea determinista

El siguiente cambio dejó de hacer preguntas. El código siempre verifica las etiquetas en cada pregunta general, independientemente de si el modelo considera que es necesario. Solo eso hizo que un grupo de datos con verdades objetivas pasara de representar aproximadamente la mitad de los resultados a alrededor de siete de dieciséis elementos; algo mejor, pero aún incompleto. Los siguientes pasos surgieron de las deficiencias concretas encontradas en las pruebas, no de especulaciones:

Un paso que analiza los resultados de búsquedas por etiquetas en busca de nombres y frases repetidos dos o tres veces, y luego busca directamente esos nombres; así, el nombre de un producto aparece incluso cuando nadie lo consultó explícitamente, una vez que el pequeño grupo de datos que lo contiene ya está visible.

Un paso que analiza las relaciones entre elementos del grafo, no solo el texto escrito, ya que los elementos hermanos pueden compartir un padre sin tener en común ninguna palabra del título. Un elemento titulado como un repositorio de pruebas de referencia con tareas de programación representativas puede no mencionar nada sobre inteligencia artificial en su propio texto y solo conectarse a través de la jerarquía.

Un paso para los repositorios, que no llevan las mismas etiquetas de categoría que los elementos de trabajo y, de lo contrario, permanecerían invisibles para las rutas basadas en etiquetas.

Un paso para las personas, después de que preguntas como la frecuencia con la que dos colaboradores trabajaban juntos generaran respuestas erróneas de forma categórica.

Cada uno cerró una brecha medible. Finalmente, el caso más difícil, compuesto por dieciséis elementos, se resolvió por completo; no solo en parte, sino totalmente.

Más contexto recuperado empeoró las respuestas

De forma contraintuitiva, una vez que la capacidad de recuperación mejoró lo suficiente y el conjunto de datos del modelo pasó de unas pocas cientos de elementos a más de mil, las respuestas se volvieron más cortas e incompletas. El modelo no colapsó; simplemente generó menos texto a pesar de contar con más material relevante disponible. Más allá de un umbral de volumen, la calidad de las respuestas no aumenta con el tamaño del contexto: sino que disminuye. Mientras que las métricas de recuperación mejoraron, las métricas relacionadas con las respuestas finales empeoraron durante la misma prueba. La solución no consistió en “añadir más”, sino en identificar ese límite y mantenerse por debajo de él.

Una solución para la transparencia que saturó las preguntas simples

Cuando el modelo resumía material real en lugar de nombrarlo, una nueva sección de respuestas enumeraba los elementos encontrados pero sin nombre, por lo que nada desaparecía en silencio. La primera versión incluía más de mil elementos poco relacionados entre sí en las respuestas a preguntas específicas, ya que el generador de listas no podía distinguir entre coincidencias precisas y ruido generado por etiquetas genéricas. Una categoría amplia reunía todo lo remotamente relacionado y lo trataba como si tuviera el mismo valor para ser mostrado.

La solución duradera no fue solo establecer un límite numérico. Consistió en separar dos tipos de “encontrados pero sin nombre”: un pequeño conjunto de coincidencias precisas que siempre debían aparecer, y un gran grupo de ruido con etiquetas poco claras que requería un límite realista además de una nota indicando que existen más. Esa distinción era más importante que el límite en sí.

Proporcionar herramientas al modelo, con límites

Una pregunta útil determinó el resto del trabajo: ¿por qué un ser humano puede responder lo que el sistema no puede, si ambos ven los mismos datos? Los humanos pueden escribir una nueva consulta cuando las herramientas existentes no son adecuadas, y verifican nuevamente las respuestas que parecen incorrectas. El modelo no tenía ninguna de estas capacidades. Recibió una herramienta para escribir su propia consulta a una base de datos de solo lectura, la cual era restringida a lectura por parte de la base de datos, tenía un límite de tiempo y un tope en el tamaño de los resultados.

Fueron necesarias dos rondas más. Al preguntarse con qué frecuencia colaboraban dos personas nombradas, el modelo primero asumió que compartían un apellido por ser mencionados juntos, obtuvo un resultado vacío y luego adivinó basándose en comentarios no relacionados en lugar de cuestionar ese resultado vacío. La regla pasó a ser: primero resolver cada nombre con su registro exacto, y considerar una consulta propia que dé resultado vacío como evidencia de que la consulta es incorrecta, y no de que la cantidad sea cero.

En el intento siguiente se resolvieron ambos casos, se ejecutó la consulta correcta, se obtuvieron veinticinco elementos compartidos; sin embargo, aún no se indicó el número, porque cada afirmación factual requería un identificador de cita y un conteo calculado no tenía ninguno. Al seguir al pie de la letra la regla de las citas, se descartó una respuesta correcta. Se necesitaba una excepción explícita: un número calculado podía indicarse directamente sin un identificador de fuente.

Ninguno de esos fracasos fue una incapacidad; ambos fueron una obediencia correcta a instrucciones que no abarcaban la situación. Esa distinción es más importante de lo que parece a primera vista.

Cómo se mantuvo la honestidad en las pruebas

La verdad objetiva no era una verificación de ambiente. Para el grupo más complejo, se enumeraron primero dieciséis elementos conocidos a partir de la consulta exhaustiva, y luego se calificaron tras cada cambio en la recuperación: cuántos aparecieron en la respuesta final, cuántos fueron citados y cuántos se descartaron silenciosamente. Fue ese sistema de puntuación lo que dio sentido a “siete de dieciséis” y posteriormente a “dieciséis de dieciséis”. Sin una lista exhaustiva externa, afirmar que “parece completo” es solo cuestión estética.

Ordenar el proceso sin sobrecargar al modelo

Los pasos deterministas aún necesitan un orden. La expansión de etiquetas amplía primero el conjunto de candidatos; la minería de nombres lo profundiza luego; los recorridos en grafo añaden vecinos estructurales; los pasos relacionados con repositorios y personas llenan las lagunas en la modalidad. Solo después de que se construye ese conjunto se aplica un límite de tamaño para reducir lo que ingresa en la solicitud. Invertir ese orden —pedirle al modelo que sea exhaustivo antes de construir el conjunto— vuelve al problema del estímulo insuficiente. El trabajo relacionado con la completitud corresponde al diseño de la pipeline, no a adjetivos mejores en el prompt del sistema.

Citas versus hechos computados

La regla de citar cada afirmación protege contra la invención cuando el modelo cita elementos de trabajo. Se vuelve perjudicial cuando el modelo realiza operaciones aritméticas o combina resultados de herramientas. Separar la “afirmación citada” del “valor agregado calculado” en las instrucciones restableció la cuenta de veinticinco colaboraciones sin debilitar la disciplina de citación para las afirmaciones narrativas. Los sistemas RAG que utilizan herramientas necesitan ambas reglas, establecidas de forma explícita.

Situación actual

Una consulta directa a una base de datos es exhaustiva por diseño: no se pueden pasar por alto las filas que coinciden. Tampoco puede explicar, agrupar o narrar significados; devuelve una lista, no una respuesta. El sistema ahora compara la exhaustividad de dicha consulta en los casos difíciles que se encontraron y probaron, al tiempo que sigue explicando los hallazgos en prosa con fuentes verificables. Ese resultado se mide, no se asume.

No se trata de un problema resuelto. Cada solución mencionada anteriormente existe porque surgió un fallo específico al verificar las respuestas contra una lista exhaustiva. Ese método detecta deficiencias, pero no demuestra que no queden ninguna. Después de los cambios anteriores, apareció un nuevo tipo de pregunta que involucraba una cita utilizada para respaldar una afirmación sobre una persona, cuando la fuente citada no decía nada sobre dicha persona; se detectó, pero aún no se había corregido en el momento de redactar. El patrón continúa: se verifica algo que parece completo y surge algo nuevo.

La conclusión honesta no es que “se haya resuelto la completitud de RAG”. Es más bien que cada brecha específica que se pudo encontrar y probar fue cerrada, con cifras antes y después. No hay forma de garantizar que no existan brechas futuras, y ningún sistema de este tipo debería dar esa impresión. “El modelo suele acertar” no constituye una base para la fiabilidad; precisamente la palabra “suele” es la que falla en lo que realmente importa.