Yo de esta serie con Angela Shi. Este artículo sobre las trampas enumera los modos de falla que ambos seguíamos viendo en los sistemas RAG de producción y que, en primer lugar, nos empujaron hacia el contrato de cuatro ladrillos.
Admitiré algo. Incluso cuando trabajamos en esta serie, volcamos documentos grandes en ChatGPT. Un PDF, una pregunta, enviar, leer la respuesta. El modelo es bueno, el proveedor paga la factura simbólica y, en casos excepcionales, ese es el camino correcto.
La serie existe para el otro caso. En el trabajo empresarial casi nunca se trata de un solo documento. Un gestor de reclamaciones formula la misma pregunta en el catálogo completo de un corredor. Un equipo de cumplimiento escanea cada contrato de una cartera. A esa escala, dump-it-in-ChatGPT deja de funcionar y se vuelve costoso rápidamente.
Lo que sigue es el resumen de los errores que seguimos viendo, ladrillo a ladrillo. Las correcciones se encuentran en la Parte II.
1. Análisis: cómo el documento pierde su forma
El análisis falla cuando el equipo trata el documento como texto en lugar de como un objeto estructurado. Siguen apareciendo tres patrones: descartar tablas y diseños (Error 1), volcar el documento completo en el mensaje (Error 2) y dividir el documento en ventanas de tamaño fijo que ignoran su estructura (Error 3). La solución es un analizador estructural que produce tablas escritas en lugar de cadenas o ventanas arbitrarias.
Una metaversión de estos tres también se encuentra en el resto del artículo. Los equipos se saltan la corrección del análisis y pasan semanas ajustando el tamaño de los fragmentos, los umbrales de reclasificación, el top-K y las opciones de incrustación, y nunca alcanzan la precisión que esperaban. Cada palanca que miden se encuentra encima de la salida del analizador: un analizador que aplanó la tabla en la página 47 produce un ruido que ningún fragmentador puede recuperar, un analizador que perdió los encabezados de las columnas produce ambigüedad que ningún reclasificador puede superar. La literatura no ayuda. El artículo de proveedores más citado sobre técnicas RAG tiene 194 páginas sobre fragmentación y ninguna sobre análisis. Primero corrija el análisis. El ajuste de recuperación es para tuberías cuyo analizador ya conserva la estructura.
1.1 Error 1: El PDF tenía una tabla. El analizador devolvió una cadena.
El reflejo predeterminado es extraer el PDF como una única masa de texto y dejar que el LLM lo resuelva. Los analizadores modernos hacen que esto sea fácil: una llamada a una función, una cadena atrás y listo.
El costo aparece la primera vez que llega una tabla con etiquetas de filas agrupadas. Un contrato de reclamaciones tiene una tabla de beneficios donde aparece el mismo nombre de fila (Prima, Deducible) en dos categorías (Salud, Dental). Aplanadas en texto, las categorías desaparecen en el flujo de tokens y el LLM ve Plan A Plan B Plan C Prima de salud 100 200 300 Deducible 5 10 15 Prima dental 50 80 120 Deducible 2 4 6. Pregunte “¿cuál es la prima del Plan B?” y hay dos respuestas válidas: 200 (Salud) u 80 (Dental). La cuerda plana no lleva marcador de agrupación. El modelo elige uno. Selecciona mal algunas veces y no hay ninguna señal que indique que eligió mal.
El mismo problema afecta a los diseños de varias columnas (una página de contrato con una barra lateral de notas al pie), encabezados y pies de página (el número de página contamina cada recuperación) y el orden de lectura de los archivos PDF escaneados. Cada uno es un modo de falla diferente, pero comparten la misma raíz: el analizador descartó la estructura que llevaba el documento.
La solución es un analizador relacional que produce tablas escritas (line_df, page_df, toc_df,…) en lugar de una cadena plana. Cada línea lleva su cuadro delimitador, su página, su fuente, su sección. Las mesas tienen su propia veta. Los ladrillos aguas abajo leen estructura, no manchas.
1.2 Error 2: pagar por 1200 páginas por cada pregunta
Un segundo error en el análisis es uno que Angela y yo cometemos nosotros mismos en proyectos pequeños: saltarnos el análisis por completo y meter todo el PDF en el chat. Es rápido de escribir, funciona para un documento y el proveedor paga la factura simbólica en el nivel gratuito.
En un corpus real, el mismo reflejo se vuelve costoso en tres pasos. En primer lugar, el PDF ya no tiene 12 páginas, son 1200. En segundo lugar, la pregunta ya no es una, son 200 por día. En tercer lugar, el equipo agrega cinco documentos más al chat para "dar más contexto al modelo" y el recuento de tokens por pregunta crece linealmente. La factura pasa de céntimos a miles mensuales, y las respuestas empeoran porque el modelo tiene más pajar y la misma aguja.
La solución es hacer coincidir la técnica con el documento y la pregunta: cuando la respuesta cabe en tres páginas, envíe tres páginas, no 1200. El mismo principio aquí: análisis una vez, alcance de recuperación, generación en el contexto más pequeño que contiene la respuesta.
Aquí está el proyecto de ley en un escenario empresarial realista: un contrato de reaseguro de 1200 páginas que un equipo de cumplimiento consulta 200 veces al día. Dos enfoques, la misma pregunta. El primero extrae cada línea de texto del PDF e incluye el resultado en cada mensaje. El segundo es el proceso que construye esta serie: el análisis produce tablas estructuradas, la recuperación devuelve las tres páginas relevantes y la generación solo lee esas.
En un contrato de 1200 páginas, el vertedero paga aproximadamente cuatrocientas veces el costo de los insumos del oleoducto analizado. El volcado crece con el documento y el recuento de preguntas; la tubería crece sólo con la respuesta. Por contrato, por año de doscientas preguntas al día, esa es la diferencia entre gastar 131.000 dólares y gastar 329 dólares.
El almacenamiento en caché rápido inclina las matemáticas sin invertirlas. Las lecturas de caché con un 90 % de descuento de Anthropic y la entrada de caché con un 50 % de descuento de OpenAI se aplican solo en los aciertos de caché, desalojan en un TTL que el equipo no controla y facturan el precio completo en caso de error. A una tasa del 90%, el volcado todavía cuesta $13,140 al año con la misma carga de trabajo, cuarenta veces el alcance del proceso, y sigue creciendo con el tamaño del documento, no con la respuesta.
Un RAG alojado (file_search de OpenAI, AWS Knowledge Bases, similar) se ubica entre los dos: más barato que el volcado porque el proveedor fragmenta el documento y recupera lo que parece relevante, más opaco que el pipeline porque la fragmentación, el modelo de incrustación y la clasificación no son suyos para inspeccionar. Es el término medio conveniente para crear un prototipo de un solo documento. Rara vez es la respuesta a escala empresarial, donde la auditoría y la reproducibilidad importan tanto como la factura.
Para un contrato, el número absoluto es de seis cifras. Para diez mil contratos en una cartera corporativa, la misma proporción decide si la línea de costo anual se mantiene en decenas de miles o salta a millones.
1.3 Error 3: Ajustar el tamaño del fragmento. El PDF tenía estructura.
El tercer error de análisis es suponer que un PDF es una cadena. El equipo importa pdfplumber, pypdf o PyMuPDF, llama a la función denominada extract_text o get_text, canaliza el resultado a un RecursiveCharacterTextSplitter y pasa el mes siguiente ajustando chunk_size y chunk_overlap para aumentar la precisión de la recuperación en dos puntos. El PDF tenía estructura. La API de conveniencia lo borró. La perilla que el equipo está girando está aguas abajo de donde ocurrió la pérdida.
Un contrato de 200 páginas incorpora un TOC de marcador en el que se puede hacer clic (el esquema que cada lector muestra en la barra lateral), encabezados de sección representados en distintos tamaños de fuente (24 puntos para las partes, 18 puntos para las secciones, 14 puntos para las subsecciones, las mismas señales que el ojo del lector usa para escanear) y tablas almacenadas como cuadros delimitadores a nivel de celda que un analizador estructural puede reconstruir. La estructura está ahí en el modelo de objetos PDF. extract_text() lo salta y le entrega al divisor una secuencia indiferenciada. Luego, el divisor corta en chunk_size=500 porque esa es la perilla que el equipo ha estado ajustando, además de la entrada, la propia tipografía del PDF podría haberse anclado de forma gratuita.
El costo es la precisión. Un fragmento que termina en la mitad de la tabla contiene media fila. Un fragmento que comienza en la mitad de la sección no lleva título para anclar el contexto de la respuesta. La respuesta que el LLM produce a partir de esos fragmentos se basa técnicamente en el corpus, pero se basa en fragmentos recortados en lugar de unidades significativas. La recuperación no tiene nada que filtrar, ya que cada fragmento parece más o menos igual. Generation no tiene nada que citar claramente, ya que las citas apuntan a ventanas arbitrarias. La cadena de auditoría muestra líneas como "fragmento 1142 de 10.000" sin significado legible.
Los divisores que tienen en cuenta las rebajas y las secciones solucionan el síntoma y dejan el problema ascendente en su lugar. Fragmentan el texto del encabezado que adivinan a partir de la cadena plana, pero no pueden reconstruir los cuadros delimitadores, la jerarquía de fuentes o la cuadrícula de la tabla que extract_text() ya descartó. El fragmentador lucha con insumos recortados.
La solución es el analizador estructural al que sigue apuntando el resto del artículo. El analizador mantiene la tipografía del PDF (line_df lleva bbox, fuente, página, ruta de sección), mantiene la cuadrícula de la tabla (el extractor de tablas produce celdas escritas, no cadenas), mantiene el TOC (toc_df de los marcadores del PDF más la detección del tamaño de fuente). Los ladrillos situados aguas abajo leen la estructura. Ninguna ventana de 500 caracteres cruza jamás el límite de una sección, porque no hay ninguna ventana. Hay estructura.
2. Análisis de preguntas: cómo ignorar al usuario
El análisis de preguntas falla cuando el equipo trata la pregunta en lenguaje natural del usuario como si fuera una consulta. Dos reflejos siguen regresando: pasar la cadena sin procesar directamente a la recuperación (Error 4) y detenerse en la extracción de palabras clave cuando la pregunta también tenía restricciones de forma, alcance y formato de respuesta (Error 5). La solución es una ParsedQuestion escrita que lo incluye todo.
2.1 Error 4: "Simplemente incruste la pregunta".
El cableado más económico en cualquier marco RAG es tomar lo que el usuario escribió, incrustarlo y enviarlo para su recuperación. Escriba la pregunta, llame a la API y envíe. La pregunta conlleva muchas cosas: un alcance, una forma de respuesta esperada, un formato, a veces una condición, a veces una negación, a veces una referencia a un giro anterior, a menudo una restricción implícita en el documento que el usuario tiene en mente. La incrustación los aplana todos en un vector que captura principalmente las palabras del contenido. Los ladrillos aguas abajo consumen lo que sobrevivió al aplanamiento, lo que generalmente no es lo que quiso decir el usuario.
Las preguntas reales toman todas las formas. Una breve muestra de lo que aparece en producción, con la razón por la que cada uno rompe con la incrustación ingenua:
Una pregunta concisa y estructurada. “Plan B del período de cancelación en días”. Cinco tokens, tres limitaciones: un filtro de alcance (plan B), un tipo de respuesta (una duración), un formato (en días). La incrustación aplana las tres puntuaciones de recuperación de vectores en un solo vector contra el corpus. Una negación. “¿Qué NO cubre esta póliza?” La incrustación apenas codifica NO como una palabra funcional, por lo que la recuperación devuelve los fragmentos más similares al resto de la oración, que describen lo que ESTÁ cubierto. Generation parafrasea lo contrario de lo preguntado. Condiciones anidadas más una pregunta. “Para el plan B, asumiendo un contrato de un año, ¿cuál es el plazo de cancelación si cancelo después de seis meses?” Las condiciones pertenecen al ámbito de la recuperación, la pregunta pertenece al encuadre generacional. La incrustación los mezcla; el ladrillo equivocado consume el campo equivocado. Una comparación de varias partes. “Exclusiones o deducible, ¿cuál importa más?” La recuperación devuelve fragmentos sobre ambos; La generación no recibe ninguna señal de que el usuario quiere una comparación y no una lista. Una referencia elidida. “¿Y qué pasa con el Plan C?” Cinco palabras, sin contexto. La incrustación no tiene nada sobre qué anclarse.
La lista no cierra. Cada nuevo corpus, cada nueva audiencia, cada nuevo producto trae sus propias formas de preguntas. Algunos son concisos, otros explican extensamente, algunos llevan a los operadores, otros se apoyan en el turno anterior. El analizador de preguntas es el ladrillo que absorbe la variedad para que los ladrillos posteriores vean un objeto escrito sobre el que pueden enrutarse. Sin él, cada nueva forma se convierte en un nuevo fracaso silencioso.
El atajo es el mismo en todos los casos. La pregunta conlleva estructura (limitaciones, operadores, alcance, intención, referencias). La incrustación aplana esa cadena en un solo vector. La recuperación actúa sobre lo que sobrevive, la generación lee lo que se encontró y el usuario obtiene algo que puede coincidir o no con lo que pidió.
El costo es una contradicción que el oleoducto no puede detectar. Los fragmentos recuperados parecen relevantes. El modelo escribe un párrafo con fluidez. El usuario lee una respuesta segura sobre la cobertura cuando pregunta sobre las exclusiones, sin bandera, sin advertencia, sin señal de que el operador de la pregunta se perdió en el camino.
El contraataque común es introducir una pequeña llamada de LLM que devuelva un dictado JSON: intención, alcance, palabras clave. Eso resuelve el problema de la falta de estructura, pero no el problema de la falta de contrato. Las claves de dictado varían entre las indicaciones (una llamada devuelve el alcance, la siguiente devuelve alcance_filtro), la recuperación lee una clave, la generación lee la otra y la falla silenciosa llega al usuario. Un esquema ParsedQuestion Pydantic escrito convierte la desviación en un error de tiempo de análisis que detecta el registro de auditoría. La victoria no es el JSON; es la validación.
También bloquea todas las mejoras posteriores. No puede enviar una pregunta a un canal especializado si no sabe qué tipo de pregunta es. No puede solicitar la confirmación del usuario sobre un término ambiguo si no ha señalado la ambigüedad. No puedes descomponer una pregunta de varias partes si no has reconocido que tiene varias partes.
La solución es un objeto ParsedQuestion escrito: el bloque de análisis de preguntas convierte la cadena sin formato en un objeto estructurado con palabras clave, forma de respuesta, filtros de alcance y un plan de ejecución. La cadena es la entrada; todo lo posterior consume el objeto escrito.
2.2 Error 5: "Simplemente use HyDE". O confiar en la incrustación.
El segundo error al analizar la pregunta es suponer que no es necesario que exista el ladrillo. El usuario escribe "¿cuál es el período de cancelación del plan B?". La canalización pasa la cadena a un modelo de incrustación, recupera los fragmentos K superiores por coseno y los entrega a la generación. No hay analizador de preguntas. Los desarrolladores modernos desconfían de la extracción manual de palabras clave (con razón: listas frágiles, deriva, casos extremos específicos del idioma) y en su lugar recurren a la incrustación, que parece absorber el significado de la pregunta de forma gratuita.
Las incrustaciones absorben algo. Producen un vector denso cerca de pasajes que se leen como la pregunta. No producen la forma de la respuesta, el alcance, la restricción de formato o la cláusula implícita "en este documento". Estos no llevan ninguna señal de incrustación hasta que el canal los escribe en algún lugar escrito.
Una solución alternativa común que el campo busca en este punto es HyDE (Incrustaciones de documentos hipotéticos): el LLM genera una respuesta hipotética a la pregunta, el proceso incrusta esa hipotética, la recuperación califica fragmentos de corpus en lugar de en contra de la pregunta. Funciona en puntos de referencia y los desarrolladores lo utilizan como un escape inteligente de la trampa de la integración exclusiva. La razón por la que funciona rara vez se expresa claramente: la respuesta hipotética contiene las palabras clave que contendría una respuesta real, y esas palabras clave latentes son las que recoge la incrustación. HyDE es una extracción disfrazada de palabras clave impulsada por un LLM, una generación adicional por consulta, sin validación de expertos ni auditoría. Cuando su rendimiento es inferior, el reflejo es buscar un modelo más fuerte. La versión determinista de la misma idea es pedirle al experto en el dominio el vocabulario conceptual y almacenarlo una vez. En el ámbito empresarial, la respuesta que vale la pena enviar es la que validaría un experto en el campo, no la que imagina un modelo más capaz.
La restricción de formato “en días” es el caso más agudo. Codificada en el vector de preguntas, la señal de "días" desvía el top-k hacia fragmentos sobre "tiempo de respuesta dentro de los 30 días" o "Día 1 de la póliza", ambos puro ruido para una pregunta sobre cancelación. La restricción pertenece al resumen de generación, no a la consulta de recuperación. Las canalizaciones que omiten el análisis de preguntas envían el mismo vector codificado a la recuperación y la misma cadena sin formato a la generación, y el bloque incorrecto consume el campo incorrecto.
La solución no es una integración más inteligente. La solución es un analizador de preguntas que produce un objeto escrito con forma, alcance, formato y descomposición de la respuesta como campos separados, cada uno dirigido al bloque que lo consume. La palabra clave case se convierte en un campo de ese objeto, validado con un diccionario experto, de modo que el término premium se asigna a prime, cotisation y price sin que el desarrollador mantenga la lista a mano. El artículo 6 desarrolla el analizador sintáctico y los dos escritos mecanografiados que salen del otro lado, uno para recuperación y otro para generación.
3. Recuperación: el reflejo vectorial DB y sus puntos ciegos
La recuperación falla cuando “simplemente incrustarlo y clasificarlo por coseno” se convierte en la única herramienta del paquete. Tres hábitos lo causan: tratar RAG como sinónimo de DB vectorial (Error 6), tratar el fragmento como la única granularidad cuando la respuesta es una línea dentro de un pasaje más grande (Error 7) y detenerse en referencias a otras partes del documento (Error 8). Las correcciones son recuperación híbrida, dos granularidades devueltas juntas y un bucle de resolución de referencia.
3.1 Error 6: "Simplemente use una base de datos vectorial"
Este es el error más grande que vemos y el más costoso de deshacer porque dicta toda la infraestructura. El patrón es fijo: fragmentar el corpus, incrustar cada fragmento, incrustar la pregunta, devolver los k fragmentos superiores por similitud de coseno. Hecho.
El costo aparece en cada pregunta en la que una palabra clave habría ayudado más que un vector. Acrónimos (“RC” en seguros, “SCR” en solvencia), códigos de productos, rangos numéricos, nombres raros, referencias legales como la Sección 4.2(a)(iii). Las incrustaciones los aplanan en un vector denso y pierden la discreción. El bloque de recuperación devuelve un pasaje sobre algo similar en lugar del pasaje que contiene el término.
De manera más general, las incrustaciones funcionan cuando la pregunta se parafrasea en prosa contra prosa parafraseada. Tienen dificultades cuando la pregunta es un token: un código, un número, un patrón en forma de expresión regular, una referencia precisa. Una pequeña anécdota que se me quedó grabada. Hace unos meses utilicé un asistente de chat dentro de una herramienta de redacción para encontrar una frase específica en un documento largo que había pegado. En algún momento, el asistente intentó encontrar la frase con una expresión regular. La expresión regular volvió vacía. Fui a buscar: el PDF original tenía un carácter tipográfico (creo que una cita rizada) que mi copia y pegado había reemplazado con una cita recta. El modelo había acertado al utilizar una expresión regular. La coincidencia de fichas fue la operación fundamental. La tubería que lo rodeaba simplemente no podía soportar una diferencia de un carácter.
Las herramientas de Anthropic van más allá: cuando un agente necesita encontrar un intervalo, busca primitivas tipo grep antes de buscar una incrustación. Esa es la dirección en la que se mueve el campo, lentamente, porque las conversaciones están hechas de palabras, y las palabras coinciden mejor en tokens, no en vectores.
La cuestión más profunda es cultural. El nombre Retrieval Augmented Generation no dice nada sobre los vectores. Dice recuperación, que es un campo de cincuenta años con muchas técnicas. Sin embargo, cuando hablamos con desarrolladores que construyen sistemas RAG, casi todas las conversaciones van en el mismo sentido: "sí, utilizamos una base de datos vectorial para la recuperación". Se trata como algo predeterminado, no como una opción entre muchas.
Ángela y yo incluso discutimos sobre acuñar un nombre diferente para lo que construimos. ROG, por Retrieval Only Generation, porque en la empresa la recuperación es el trabajo y la generación es el envoltorio que lo envuelve. La definición histórica de RAG apuntaba en otra dirección: un modelo paramétrico genera, la recuperación lo aumenta. Al final mantuvimos “RAG” porque así es como se busca y conoce el trabajo, y no queríamos inventar otro acrónimo solo para dejar claro un punto. Pero vale la pena decirlo claramente: no existe una búsqueda vectorial pura en ninguna parte de esta serie. Aparecen incrustaciones, pero como alternativa.
La solución es la recuperación híbrida de forma predeterminada: detectores de palabras clave (exactas, gratuitas, deterministas) que se ejecutan en paralelo con detectores integrados, con un árbitro LLM al final que clasifica a los candidatos agregados con sus razones. El popular atajo “RAG es igual a vector DB” es la mayor fuente de fallas costosas que hemos visto a escala.
3.2 Error 7: El fragmento es correcto. El oleoducto se detuvo allí.
El segundo error de recuperación es más sutil y aparece sólo cuando intentas fundamentar una respuesta en la fuente. La canalización recupera un fragmento, se lo entrega al LLM y el LLM devuelve una respuesta. ¿En qué parte del fragmento estaba la respuesta? Nadie pregunta, porque el trozo era la unidad.
Esto rompe todas las características posteriores que dependen de saber dónde está la respuesta. Resaltado en el PDF de origen. Citas con números de línea. Un rastro de cumplimiento. El sistema puede decir “el plazo de cancelación es de 30 días” pero no puede señalar la línea que leyó.
El instinto es recuperar la ubicación después del hecho, haciendo coincidir la cita del LLM con la fuente. Falla en el momento en que el modelo parafrasea (lo que hace siempre que la cita abarca más de unos pocos tokens) y la cita apunta a una línea que casi falla. La ubicación debe calcularse en el camino de entrada, no actualizarse desde la salida.
El fragmento también es la unidad incorrecta en el otro lado de la solución: la cantidad de texto circundante que necesita el LLM depende de la pregunta. Tome "¿cuál es la fecha de los hechos?" en un informe de incidente de 200 páginas. La palabra clave fecha de los eventos llega a una línea; esa línea lleva la fecha. Dos líneas a su alrededor son suficientes para fundamentar la respuesta. Devolver el fragmento que contiene la línea, y mucho menos el capítulo completo, entierra la fecha en un ruido que el modelo tiene que atravesar. Una pregunta sobre la política de cancelación del contrato requiere un tamaño diferente: uno o dos párrafos, porque la política se construye a partir de varias condiciones que interactúan. Mismo fragmento, mismo documento, diferente respuesta correcta sobre la cantidad de texto circundante que se debe conservar.
La solución no es una mejor solución. La solución es recuperar con dos granularidades a la vez: una lo suficientemente precisa como para resaltar la fuente (la línea donde apareció la palabra clave), otra con el tamaño que necesita la pregunta (dos líneas para una fecha, un párrafo para una política). El Artículo 7 construye el ladrillo de recuperación en torno a esta división y da a los dos ámbitos los nombres sobre los que Ángela y yo discutimos durante semanas antes de decidirnos.
3.3 Error 8: “Ver la Sección 4.2” y nunca mirar
El tercer error de recuperación aparece la primera vez que el documento hace referencia a sí mismo. El fragmento recuperado dice "las exclusiones se enumeran en la Sección 4.2" y la canalización se detiene. La recuperación encontró el fragmento que menciona las exclusiones; no siguió el puntero. Generation obtiene la parte, ve la referencia y tiene dos opciones igualmente malas: inventar el contenido de la Sección 4.2 a partir de sus antecedentes previos al entrenamiento o negarse con "el documento no especifica". El documento sí lo especifica. El oleoducto simplemente no parecía.
El costo es una violación silenciosa de la cadena de auditoría. Se le dice al usuario que el sistema se basa en el corpus, pero cuando las referencias no están resueltas, la respuesta es un razonamiento a partir de antecedentes. Eso es exactamente lo que el contrato de los cuatro ladrillos pretendía evitar. Peor aún, esta falla es imposible de detectar desde el exterior: la respuesta se lee con fluidez en cualquier sentido, y el Span citado cubre la parte que menciona la Sección 4.2, no la sección en sí. Un revisor que hace clic en la cita encuentra una oración que dice "consulte la Sección 4.2" y una respuesta segura al lado. La cadena de evidencia se detiene un paso antes.
Agentic RAG maneja esto de manera agente: el LLM llama a una herramienta fetch_section cuando ve una referencia. Funciona, a un costo que el equipo a menudo no ve. Cada resolución de referencia se convierte en un bucle no determinista, la pista de auditoría se bifurca por paso del agente, el costo por pregunta crece con la profundidad de la cadena de referencia.
La alternativa determinista es un bucle de dos pasadas con un disparador escrito. La primera pasada produce una respuesta estructurada que marca la referencia pendiente en lugar de inventar algo alrededor de ella. El orquestador sigue la referencia a la sección citada, ejecuta la recuperación en las páginas correctas y la segunda pasada vuelve a basarse en la propia Sección 4.2. El artículo 11 desarrolla el campo desencadenante en el esquema de respuesta, el solucionador que asigna una referencia a las páginas correctas y el paso del orquestador que los conecta.
4. Generación: donde muere la cadena de auditoría
La generación falla cuando el bloque se trata como la llamada API que devuelve una cadena. Se repiten dos patrones: enviar la cadena LLM sin formato sin bandera, sin esquema, sin auditoría (Error 9) y confiar en la afirmación "no encontrado" del LLM sin una prueba externa de ausencia (Error 10). La solución es una respuesta escrita conectada a comprobaciones programáticas a las que el modelo no tiene acceso.
4.1 Error 9: Sin bandera, sin esquema, sin auditoría. Solo envía un mensaje de texto.
El pasaje recuperado pasa a un mensaje, el LLM devuelve una cadena y el sistema pasa la cadena al usuario. Los RAG de producción se envían así todos los días. El ladrillo es la llamada API.
El costo es que no tienes señal la respuesta es confiable. El modelo devuelve una oración fluida independientemente de que el pasaje contenga la respuesta o no. No hay ningún indicador de respuesta_encontrado, ni una cita del intervalo de soporte. Cuando el modelo inventa un número, el sistema no tiene señal para captarlo antes de que llegue al usuario.
Los resultados estructurados (response_format de OpenAI, uso de herramientas de Anthropic, Pydantic AI) cierran parte de esto. Una respuesta escrita con los campos respuesta_encontrado y cotización dice en qué cree el modelo que se basa. Lo que no cierran es la calificación del modelo en sí. “confianza”: 0,95 llega con la misma convicción ya sea que la cotización sea real o inventada. El mismo ladrillo que leyó el pasaje es el que califica la respuesta.
La escalada es una verificación programática a la que el modelo no tiene acceso. Una expresión regular verifica que la cita citada aparezca palabra por palabra en el lapso citado. Una verificación de cobertura establecida en las respuestas de enumeración (la pregunta solicita cuatro exclusiones, el esquema devuelve cuatro, cada entrada se asigna a una parte distinta del pasaje). Una verificación de tipo en el valor de la respuesta (la respuesta debe ser una Duración, el modelo devolvió "alrededor de un mes"). Cada verificación es un veredicto que sigue el despachador. El modelo llena el esquema; el verificador decide si realizar el envío.
De esto se desprende un segundo coste: las herramientas posteriores no pueden reaccionar al estado del modelo. El despachador no puede activar una nueva recuperación porque nada le indicó que la recuperación estaba incompleta. El registro de auditoría no puede reconstruir la decisión porque el texto sin formato no indica procedencia. El proceso se vuelve de una sola vez: o la respuesta es buena o se vuelve a ejecutar todo.
La solución es el esquema de respuesta escrito más el verificador que cierra el ciclo. El artículo 8 desarrolla el esquema, el despachador que elige la forma correcta por tipo de respuesta y el verificador que cierra el ciclo.
4.2 Error 10: "No en los fragmentos" no es "no en el corpus".
El error de segunda generación es confiar en el LLM cuando dice "no encontrado". La recuperación rara vez está vacía: con las incrustaciones, el coseno top-k siempre devuelve algo, por lo que el LLM obtiene un puñado de fragmentos y decide si la respuesta está en ellos. Cuando dice que no, la canalización envía answer_found=False al usuario. El sistema acaba de delegar la verificación al mismo bloque que lee los fragmentos.
"No encontrado" del LLM significa "no en estos fragmentos". No significa "no en este corpus". El modelo vio los pasajes top-k, no el documento ni el resto del archivo. Dos modos de falla se esconden detrás de un rechazo confiado: la respuesta estaba allí en el top-k y el modelo la omitió (error LLM), o la respuesta estaba en otra parte del corpus y la recuperación la omitió (error de recuperación). El usuario lee “el documento no especifica” y asume que el corpus ha sido verificado. No es así.
La solución es respaldar el "no encontrado" con una prueba de ausencia determinista. El diccionario experto de palabras clave, cada término y cada sinónimo seleccionado para el concepto de la pregunta, se ejecuta como una búsqueda literal de subcadenas en todo el corpus, no en los fragmentos recuperados. Cero coincidencias y el sistema dice "no en este corpus" con un seguimiento de auditoría defendible. Al menos una coincidencia, pero el LLM aún dijo que no, se perdió la recuperación y el orquestador activa una segunda pasada en las páginas donde aparecieron las palabras clave. Las palabras clave prueban ausencia; las incrustaciones no pueden. La solución utiliza elementos que el artículo ya ha señalado: el diccionario experto de Pitfall 5 y la recuperación de palabras clave de Pitfall 6.
5. Lo que debes esperar de la Parte II
Cada uno de los diez errores anteriores es una elección estructural que el equipo tomó temprano, antes de tener un contrato que nombrara al ladrillo. Los contratos que hacen imposibles estos fallos se desarrollan en el resto de la serie: un analizador relacional que mantiene la estructura del documento, una pregunta escrita que lleva cada restricción hacia abajo, recuperación híbrida en dos granularidades, un bucle de resolución de referencia y una respuesta escrita conectada a comprobaciones programáticas a las que el modelo no tiene acceso. Cada uno es el ladrillo que requirió la división de cuatro ladrillos.
El mismo problema vector-reflejo se presenta con una forma diferente en los sistemas agentes. Cuando un agente tiene que elegir una herramienta de un catálogo de cientos, el reflejo predeterminado es nuevamente incorporar las descripciones de las herramientas y clasificarlas por similitud. El resultado es el mismo: imprecisos en los códigos, ciegos a la diferencia entre “lecturas” y “escrituras”, opacos para la auditoría. La solución tiene la misma forma: las palabras primero, las incrustaciones como alternativa, auditoría en cada elección.
Si se encuentra asintiendo con la cabeza a través de este artículo porque su propio canal hace la mayoría de estos, ese es el tipo de asentimiento más útil. Las correcciones se desarrollan en los artículos siguientes.
6. Fuentes y lecturas adicionales
Otros artículos de la serie:
Referencias externas:
Gao et al., Recuperación densa precisa de disparo cero sin etiquetas de relevancia, ACL 2023. El artículo original de HyDE. El problema 5 explica por qué funciona la técnica (la hipótesis generada por el LLM contiene las palabras clave que tendría una respuesta real) y argumenta que el equivalente determinista es el diccionario experto. Anthropic, Introducing Contextual Retrieval, septiembre de 2024. El enfoque de fragmentación de contexto generado por LLM, adyacente a Pitfall 3. La serie resuelve el problema de la descontextualización con metadatos estructurados en lugar de anuncios publicitarios generados por LLM. Antrópico, almacenamiento en caché rápido con Claude. La palanca de costos que inclina las matemáticas de Pitfall 2 a una tasa de lectura de caché de 90 % de descuento sin invertirla. Pinecone Learn, estrategias de fragmentación para aplicaciones LLM. La encuesta de fragmentación de referencia del campo con la matriz de precisión versus riqueza que Pitfall 3 sostiene se encuentra dentro de un marco que extract_text() ya está dañado. LlamaIndex, creación de aplicaciones RAG de alto rendimiento para producción. Nombra los fragmentos desacoplados para recuperación versus patrón de síntesis, la misma idea que Pitfall 7 enmarca como ancla versus contexto. Liu, instructor: resultados estructurados para LLM. La biblioteca de salida escrita de Pydantic y el argumento de esquema como contrato. Soporte directo para el rechazo de Pydantic-vs-dict en Pitfall 4 y la respuesta escrita en Pitfall 9. Zaharia, Khattab et al., The Shift from Models to Compound AI Systems, BAIR 2024. El marco académico para la arquitectura de cuatro ladrillos que asume este artículo.