RAG 2: documentos con identidad, estructura y procedencia
Qué conservar de un documento oficial o empresarial antes de dividirlo en fragmentos y producir embeddings.
En este artículo
Un buscador puede encontrar un párrafo convincente y aun así devolver la versión equivocada. En la revisión de Taesa, esa confusión es una hipótesis que necesita rankings y ejemplos revisados; los CSV históricos no identifican cada causa. Mi propuesta empieza por hacer verificable la identidad de los documentos. Así podré investigar el fallo en lugar de atribuírselo automáticamente al embedding.
El archivo, la versión y la familia
Doy un identificador estable a cada documento, otro a su versión y otro a la familia cuando varios archivos pertenecen al mismo caso. Guardo origen, emisor, tipo, fecha de publicación, fecha de captura y hash. Cuando corresponde, registro vigencia y relaciones de modificación, pero con fuente y estado de verificación. Publicación reciente no significa sustitución automática de todo lo anterior.
Los duplicados exactos pueden compartir contenido almacenado sin perder sus distintas procedencias. Las versiones casi iguales no deben desaparecer por una deduplicación agresiva: una fecha, una excepción o un importe pueden ser precisamente lo que cambia la respuesta. El manifiesto debe registrar también lo que no entró en el índice y por qué.
Conservar tres representaciones
Conservo el original, una extracción estructurada y la representación de búsqueda. Cada transformación registra parser, versión, configuración y relación con el archivo anterior. En PDF reviso orden de lectura, tablas, notas, signos y unidades. Una extracción extensa no garantiza que las columnas estén bien asociadas. Los errores van a una cola de revisión, no a una exclusión silenciosa.
{
"document_id": "doc-001",
"version_id": "doc-001-v2",
"family_id": "case-017",
"chunk_id": "doc-001-v2-section-3-p2",
"source_locator": {"page": 8, "section": "3.2"},
"valid_from": null,
"validity_status": "unverified",
"original_text": "...",
"generated_context": null,
"access_policy_id": "policy-017"
}Cortar sin borrar las relaciones
Mi primera comparación sería entre una división simple por tamaño y otra por secciones, artículos, cláusulas y tablas. Mantendría un vínculo entre cada fragmento y su unidad superior para ampliar el contexto después de recuperar. No separaría deliberadamente una regla de su excepción ni una cifra de su unidad. Si una sección excede el límite, la subdivisión conserva encabezados y referencias.
Las etiquetas empiezan pequeñas: tipo documental, entidad, tema y estado. Distingo el metadato explícito en la fuente, el derivado por regla y el inferido por modelo. Una etiqueta inferida puede ayudar a ordenar, pero convertirla en filtro obligatorio puede eliminar evidencia relevante. La vigencia y los permisos no se deducen de un resumen generado.
Akoma Ntoso ofrece una referencia para estructura y metadatos normativos. Adoptar sus principios no exige implementar toda la especificación. Para aprobar esta fase pediría trazabilidad de cada cita al original, revisión de una muestra de extracciones difíciles y un informe de pérdidas por tipo documental. El porcentaje objetivo depende del riesgo y debe fijarse antes de comparar modelos.
OASIS: estructura y metadatos Akoma Ntoso
Caso Taesa: límites del diagnóstico original
Un preprint de septiembre de 2026 evalúa conjuntamente parser, chunking y embedding en cuatro documentos regulatorios indios. Encuentra interacciones: el mejor conjunto no se deduce del ranking aislado de cada componente. Sus preguntas son generadas por LLM, con revisión manual de una muestra, y no evalúa respuestas finales. Para Taesa, esto sugiere una pequeña comparación factorial después del diagnóstico inicial; miles de evaluaciones sobre cuatro documentos no representan miles de contextos regulatorios independientes.
Interacciones entre parser, chunking y embedding
Descargar scripts, manifiesto y documentación de la revisión