Procedencia de datos para sistemas RAG
Una cita dice al lector dónde buscar. La procedencia explica qué versión exacta de la fuente, transformación, chunk, índice, decisión de retrieval y contexto del modelo produjo el claim leído.
Una URL no es procedencia suficiente
El artículo original de RAG, de Patrick Lewis y coautores, describió generación apoyada en memoria no paramétrica explícita e incluyó procedencia entre las motivaciones. En producción, mostrar una URL ayuda, pero es incompleto. Una página cambia, un PDF se reemplaza, el creador desaparece y una cita puede apuntar a un documento que no sostiene el claim cercano.
La procedencia útil responde una pregunta de reproducibilidad: ¿qué evidencia exacta tenía el sistema al responder? Conserva identidad inmutable, hash, versión o timestamp, autor o creador, publisher, licencia, acceso, parser, chunks, embedding, snapshot, transformaciones de query, ranking, contexto, prompt, modelo, claims y mapeo de citas.
Origen¿El usuario identifica creador, publisher, fuente canónica, derechos y versión exacta?
Transformación¿Se pueden reconstruir parsing, OCR, normalización, chunking, enriquecimiento y embedding?
Autorización¿Se respetaron ACLs y tenants en ingestión, retrieval, caché y respuesta?
Atribución¿Cada claim material apunta a pasajes que lo sostienen con granularidad útil?
Actualidad¿Contenido cambiado, revocado, eliminado o sustituido puede salir de futuras respuestas?
Modela procedencia como entidades, actividades y agentes
W3C PROV ofrece un modelo práctico: entidades como documentos, chunks, embeddings, índices, prompts y respuestas se generan o derivan mediante actividades como ingestión, chunking, indexación, retrieval y generación, asociadas con agentes como creadores, publishers, servicios, usuarios y modelos.
OpenLineage captura datasets, jobs, runs y facets extensibles del pipeline de ingestión. No sustituye el linaje de respuestas, pero conecta un chunk o snapshot con la ejecución que lo produjo. Los IDs estables son esenciales; filenames y URLs visibles no son identificadores.
Grafo RAG desde creador hasta claim
01 FuenteCreador y publicaciónCreador, publisher, URI canónica, fecha, versión, licencia, jurisdicción y hash.
02 AdquirirEvento de ingestiónConector, fetch, respuesta, firma o credential, ACL, consentimiento y retención.
03 TransformarDocumento parseadoParser u OCR, estructura, normalización, idioma, tablas, imágenes y calidad.
04 SegmentarLinaje del chunkID estable, documento padre, rango, headings, overlap y versión del chunker.
05 RepresentarEmbedding e índiceModelo, dimensiones, hash del vector, filtros, colección y snapshot inmutable.
06 RecuperarDecisión de selecciónUsuario, tenant, variantes, filtros, scores, reranker, chunks y orden.
07 GenerarContexto de respuestaTemplate, modelo, parámetros, posiciones, truncado, tools e ID de respuesta.
08 AtribuirClaims y citasSpans de claim y soporte, checks de entailment, confianza, crédito y link.
Los logs de retrieval deben conservar la decisión, no texto sensible crudo
Al responder, registra snapshot, contexto de autorización, filtros, reescritura de query, IDs y scores candidatos, reranker, deduplicación, chunks elegidos, orden y pasajes descartados. Las convenciones GenAI de OpenTelemetry incluyen eventos de retrieval e IDs para correlacionar estas operaciones.
No conviertas observabilidad en exfiltración. Query, documentos y prompts pueden contener datos personales o de tenants. Prefiere IDs, hashes, clasificaciones, snippets limitados y evidence stores protegidos. Mantén procedencia de alta cardinalidad en auditoría o lineage, no en métricas normales.
Las citas deben ser por claim y reconocer a los creadores
Una cita debe conectar un claim con spans exactos de soporte. La referencia visible debe acreditar al creador cuando exista, nombrar obra y publisher, mostrar fecha, enlazar la fuente canónica e informar licencia o restricción relevante. Un dominio genérico oculta a las personas y organizaciones que crearon el conocimiento.
No dejes que el modelo invente referencias de memoria. Entrega IDs opacos al generador y resuelve citas en servidor mediante el registry. Valida que los chunks estaban en contexto y sostienen el claim. RAGAS, ARES, ReClaim y CiteFix muestran que relevancia, faithfulness y corrección de citas son problemas distintos.
| Fallo | Por qué parece confiable | Evidencia que lo expone | Control |
|---|---|---|---|
| URL correcta, versión incorrecta | La página existe, pero cambió después de indexarse. | Hash, versión, timestamp, archive o ID inmutable. | Muestra versión usada y detecta source drift antes de reutilizar. |
| Documento correcto, claim sin soporte | La cita es relacionada, pero no implica la frase. | Mapeo claim-spans y resultado del support check. | Validación por claim y abstention cuando no haya soporte. |
| Fuente obsoleta o revocada | El vector sigue recuperable después de eliminación o corrección. | Status, evento de borrado, snapshot, cachés y respuestas afectadas. | Tombstone de derivados, rebuild, invalidación y replay auditable. |
| Retrieval cross-tenant | La respuesta es fluida y quizá no revele la fuente filtrada. | Usuario, tenant, ACL, filtros, candidatos y chunks. | Autorización antes de retrieval, índices security-trimmed y pruebas de leakage. |
| Creador o licencia perdidos | La respuesta enlaza a mirror y elimina metadatos. | Fuente canónica, creador, publisher, licencia, adquisición y transformación. | Exige atribución antes de indexar y consérvala en derivados. |
| Contexto distorsionado por chunk | Pasaje aparece sin heading, tabla, matiz o excepción. | Rango padre, headings, chunks vecinos, estructura y orden. | Chunking estructural, citas expandibles y checks de completitud. |
| Regresión de índice o modelo | La misma query empieza a producir otra respuesta. | Embedding, índice, reranker, prompt, modelo, parámetros y evaluación. | Replay versionado, comparación por lineage, canario y rollback. |
Eliminación y corrección deben recorrer el grafo
Cuando una fuente se corrige, revoca, expira, cambia licencia o recibe solicitud de eliminación, encuentra chunks, embeddings, snapshots, cachés, muestras y respuestas derivadas. La procedencia permite impact analysis; sin ella, se borra el origen mientras derivados obsoletos siguen respondiendo.
Conserva tombstones y evidencia de revocación sin retener contenido sensible eliminado. Repara índices, invalida semantic caches y marca respuestas anteriores como stale cuando el soporte ya no sea válido. El grafo de procedencia también es el grafo de borrado.
La evaluación debe diagnosticar qué etapa falló
Un score único es débil. Mide actualidad y derechos, recall y relevancia de retrieval, leakage de ACL, completitud de contexto, faithfulness, precisión y recall de citas, cobertura de creadores y calidad de abstention. Conserva linaje de cada resultado para vincular regresiones con fuente, parser, chunker, embedding, retriever, reranker, prompt o modelo.
El perfil de IA generativa de NIST recomienda evaluar procedencia en escenarios reales y con métricas definidas. En RAG significa comprobar no solo si la respuesta parece correcta, sino si el soporte es trazable, autorizado, actual y presentado honestamente.
Lo que construiría
Construiría un registry de procedencia con IDs inmutables para fuentes, versiones, chunks, embeddings, índices, retrievals, context bundles, respuestas, claims y citas. La ingestión emitiría eventos compatibles con OpenLineage; las solicitudes online emitirían traces conectados al registry.
La interfaz mostraría citas concisas y permitiría expandir creador, publicación, versión, licencia, pasaje exacto, momento de retrieval y actualidad. Operadores tendrían reverse lineage: desde una fuente mala o parser defectuoso, localizar cada respuesta afectada.
El principio de diseño
La confianza en RAG no nace de texto con forma de nota al pie. Conserva el grafo desde creador hasta claim, resuelve citas desde evidencia inmutable, aplica derechos y autorización a cada derivado y haz que corrección y borrado recorran el mismo linaje.