RAG sin misterio: de los documentos a una recuperación fiable
RAG no es “meter PDFs en una base vectorial”. Es un pipeline de datos que convierte fuentes cambiantes en evidencia trazable, encuentra los fragmentos adecuados para cada pregunta y aporta contexto para responder con citas verificables. Si una respuesta falla, el problema puede estar en la extracción, los permisos, los límites de los fragmentos, el ranking o la generación. Cada etapa debe poder observarse y medirse; alargar el prompt no es el primer recurso.
Publicado el 28 de septiembre de 202615 min de lecturaBúsqueda documental e IA aplicada
Sigue la evidencia por todo el sistema
Cada respuesta debe poder rastrearse hasta la versión exacta de su fuente
1 / OrigenResponsable, versión, permisos y vigencia.
2 / ExtraerConserva texto, tablas y estructura.
3 / SegmentarDivide por significado y guarda metadatos.
4 / IndexarGenera embeddings y conserva procedencia.
5 / RecuperarBusca, filtra, ordena y elige evidencia.
6 / ResponderGenera con citas o se abstiene.
Empieza por la identidad y los permisos
Asigna a cada fuente un ID estable, versión, hash del contenido, responsable, vigencia, fecha de ingesta y política de acceso. Una nueva versión debe sustituir a la anterior de forma explícita, no crear evidencia duplicada sin control. Las eliminaciones y los cambios de permisos deben propagarse a los fragmentos e índices derivados. Si el archivo desaparece pero sus fragmentos siguen siendo recuperables, hay una exposición de datos.
Registra en cada ejecución la versión del parser, los avisos de extracción y la configuración de segmentación. Cuando la política de retención lo permita, conserva el original o una referencia controlada para investigar respuestas incorrectas. El texto recuperado de documentos no confiables es dato, no instrucción: no puede sustituir la política del sistema ni autorizar acciones de herramientas.
Extrae estructura, no solo volumen de texto
La extracción de PDF puede mezclar columnas, omitir encabezados o separar una tabla de sus unidades. El HTML puede incluir navegación repetida y el OCR introduce incertidumbre. Conserva títulos, páginas, rótulos de tablas y enlaces de origen como metadatos; envía extracciones deficientes a revisión. En una tabla, mantén el contexto de filas y columnas para que el valor siga asociado a su encabezado.
Elige los límites según el contenido
Tipo de contenido
Límite inicial recomendable
Riesgo habitual
Políticas y manuales
Título y sección coherente, con contexto del documento padre
Separar una excepción de la regla que modifica
Código y documentación API
Símbolo, endpoint o ejemplo completo
Separar la firma de sus parámetros o versión
Tablas y catálogos
Filas con encabezados y unidades repetidos
Recuperar cifras sin su categoría
Conversaciones de soporte
Problema, solución y metadatos de producto/versión
Perder la pregunta que explica una respuesta
Las ventanas fijas de tokens son una línea base reproducible, no una regla universal. La superposición protege el contexto en los bordes, pero aumenta el índice y puede duplicar resultados. Una segmentación que respeta la estructura y recupera padre e hijo puede devolver un fragmento preciso sin perder la sección amplia que necesita el modelo. Compara opciones con tus documentos y consultas, no por una cifra elegida de oídas.
Los embeddings son una señal más
Un embedding representa el texto como vector para encontrar fragmentos semánticamente relacionados aunque usen otras palabras. No garantiza relevancia, exactitud ni autorización. Guarda la versión del modelo, las dimensiones y la identidad del fragmento; cambiar de modelo suele requerir una reindexación planificada. Para códigos, nombres, fechas y errores exactos, la búsqueda léxica puede funcionar mejor. La búsqueda híbrida combina señales y puede añadir reranking si compensa la latencia y el coste.
Aplica filtros de permisos antes de pasar contenido al modelo. Usa organización, audiencia, estado documental y vigencia como metadatos, y prueba consultas entre clientes de forma explícita. No se arregla una fuga pidiendo al modelo que ignore contenido que nunca debió recibir.
Evalúa la búsqueda aparte de la respuesta
Prepara un conjunto representativo de consultas reales y sus documentos o fragmentos esperados. Mide si la evidencia correcta aparece entre los primeros resultados y si los filtros de acceso funcionan. Después evalúa la respuesta generada: fidelidad a las fuentes, relevancia, completitud y exactitud de las citas. Sigue la búsqueda y la generación por separado para que una respuesta fluida no oculte una recuperación defectuosa.
Incluye casos habituales y adversariales: preguntas sin respuesta en el corpus, versiones contradictorias, políticas caducadas, términos ambiguos, tablas, consultas multilingües e instrucciones maliciosas dentro de documentos. Define cuándo el sistema debe abstenerse, pedir aclaraciones o derivar el caso a una persona. Clasifica fallos por etapa y repite las pruebas tras cada cambio.
Haz que las citas sirvan al lector
Muestra título, versión o fecha, sección/página y un enlace estable. La cita debe señalar el fragmento realmente recuperado, no solo un archivo de título parecido. Conserva la relación entre cada fragmento y su posición original para mostrar el contexto y permitir la comprobación. Si la búsqueda no encontró evidencia suficiente, no fabriques certeza con el conocimiento general del modelo.
En resumen
Un RAG fiable combina ingesta gobernada, recuperación inspeccionable y generación evaluable. Conserva identidad, permisos y procedencia; extrae la estructura; prueba segmentación y búsqueda híbrida; mide la recuperación aparte de la calidad de respuesta y considera válida la abstención. La base vectorial es un componente, no todo el sistema.