Hace unos meses comenzamos un proyecto donde el cliente quería un sistema que pudiera contestar preguntas sobre documentación oficial — plazos, criterios, requisitos enterrados en cláusulas de cuarenta páginas — y que cada respuesta fuera defendible. Su condición era sin margen: "si el sistema dice algo, yo tengo que poder abrir el documento y encontrar esa frase".

En jerga técnica, eso se llama RAG. Pero no el RAG de las demos.

Lanzando al sistema una consulta: "cuántos días tienen los licitadores para clarificar documentación desde la notificación".

El retrieval devolvió tres hits en menos de un segundo.

El primero, un chunk de texto narrativo de la cláusula 5 del pliego. El segundo, una tabla con la celda "5 working days from notification". El tercero, una declaración firmada por el propio licitador reconociendo que acepta ese plazo. Tres documentos distintos. Misma convocatoria. Misma respuesta.

Cada hit llevaba su cita: identificador del documento, rango de páginas, tipo de chunk, modelo de embedding usado. Podía abrir cualquiera de los tres PDFs, ir a la página indicada, y leer la frase exacta que el sistema había destacado.

Sin ese nivel de trazabilidad, lo único que el sistema podría haber dicho es "cinco días". Igual que si lo hubiera inventado.

La mayoría de lo que hoy se vende como RAG es un LLM encima de un índice vectorial. Funciona en demos, pero colapsa en producción.

La regla que seguimos es corta y un poco arisca: el LLM no es la fuente de verdad. El parsing determinista lo es. Las identidades canónicas de los documentos lo son. El LLM enriquece, resume y responde con evidencia — pero nunca decide qué entra al sistema.

Los próximos días voy a contar cómo está construido por dentro: arquitectura, flujos asíncronos, cómo se preservan las tablas en los PDFs, y dónde sí y dónde no tiene sentido meter un LLM.

Este era el punto de partida: si el sistema dice algo, se tiene que poder comprobar.