Pipeline RAG, chunking por estructura, recuperación contextual y metadatos de versión

Un asistente responde consultas sobre un manual de suscripción de 900 páginas. Los fragmentos que recupera dicen cosas como “este límite no aplica en los casos listados arriba”, sin decir qué límite ni qué casos, y las tablas de cobertura llegan cortadas a mitad de una fila. El equipo achicó los fragmentos a la mitad y después subió a 50 los recuperados por pregunta: nada mejoró y lo segundo encareció cada respuesta. Cuando un sistema de generación aumentada por recuperación (retrieval-augmented generation, RAG) responde mal, la primera sospecha es qué contexto le llega al modelo, y eso se decide al indexar.

Cortar por la estructura

La fragmentación (chunking) en tamaños fijos es simple, pero corta donde cae: separa una oración de la sección que le da sentido y parte tablas. La alternativa:

• Cortar en los límites de la estructura: secciones, subsecciones, cláusulas, artículos.
• Mantener enteras las tablas y las listas que se leen juntas.
• Ajustar el tamaño dentro de esa estructura, no al revés.

Achicar los fragmentos empeora el problema (cada uno pierde todavía más contexto) y traer más fragmentos solo suma costo y latencia: siguen siendo fragmentos incompletos.

Que cada fragmento se entienda solo

La recuperación contextual (contextual retrieval) antepone a cada fragmento, antes de indexarlo, un breve texto que lo sitúa: de qué documento es, de qué sección, a qué se refiere. “Manual de suscripción, sección 4.2, exclusiones del límite por granizo: este límite no aplica…” se recupera mejor y el modelo lo interpreta bien. Ese contexto se puede generar con un modelo chico durante la ingesta, y se usa tanto para los embeddings (embeddings) como para el índice por palabras clave.

Cambiar el modelo de embeddings sin tocar el corte no sirve: ningún embedding recupera contexto que el fragmento no tiene.

Lo que no se indexó no existe

Un caso que el examen usa: para acelerar la primera carga, la ingesta indexó solo los primeros 500 tokens de cada contrato, y nadie sacó ese límite. Las cláusulas de indemnidad y rescisión, que suelen estar al final, nunca aparecen. Ni un embedding mejor ni más resultados las van a encontrar. La respuesta es reindexar los documentos completos en fragmentos.

Lo mismo vale después de una actualización de documentos: si las respuestas empiezan a salir seguras pero equivocadas y el modelo no cambió, revisá primero la reindexación y los fragmentos que se recuperan.

Metadatos: versión, vigencia y lo que no va al prompt

Los metadatos (metadata) de cada fragmento resuelven dos problemas distintos:

Versiones. Si cada revisión de una política se suma al índice como documento nuevo, las versiones casi idénticas puntúan igual y el asistente cita reglas reemplazadas. Pedirle al modelo que “prefiera lo más reciente” no es un control: muchas veces ni recibe la versión vigente. Lo que funciona es guardar versión, fecha de vigencia y estado en cada fragmento y filtrar en la consulta: lo vigente por defecto, y una fecha pasada cuando auditoría la pida. Reconstruir el índice cada semana con los mismos archivos no cambia nada.

Datos de archivo. La metadata administrativa (quién escaneó, ruta de la carpeta, historial) no se pega en cada fragmento que va al modelo. Se guarda como campos del índice: queda disponible para auditoría y para filtrar, y deja de ocupar contexto en cada pedido.

Las trampas típicas

• Fragmentos más chicos o más fragmentos recuperados para un problema de corte.
• Un modelo de embeddings nuevo para encontrar texto que nunca se indexó.
• Pedirle al modelo que elija la versión más nueva.
• Fragmentos enormes “para que se vea la fecha”.
• Borrar la metadata que la política exige conservar para ahorrar tokens.
• Culpar al modelo cuando las respuestas empeoran justo después de actualizar documentos.

En el examen

Leé el síntoma con cuidado. Fragmentos sin contexto o tablas cortadas piden cortar por estructura y recuperación contextual. Contenido que “nunca aparece” pide revisar qué se indexó. Citas de versiones viejas piden metadatos de vigencia con filtro en la consulta. Y si el escenario menciona que la metadata ocupa tokens pero hay que conservarla, la respuesta es moverla a campos del índice. Descartá las opciones que tocan el modelo o la cantidad de resultados cuando el problema está en la ingesta.