# Proveniencia en Tiempo de Extracción: Capa de Origen
## Resumen
Este documento captura notas sobre la proveniencia en tiempo de extracción para futuros trabajos de especificación. La proveniencia en tiempo de extracción registra la "capa de origen": de dónde provienen los datos originalmente, cómo se extrajeron y transformaron.
Esto es diferente de la proveniencia en tiempo de consulta (ver `query-time-provenance.md`), que registra el razonamiento del agente.
## Declaración del Problema
### Implementación Actual
Actualmente, la proveniencia funciona de la siguiente manera:
Los metadatos del documento se almacenan como triples RDF en el grafo de conocimiento.
Un ID de documento vincula los metadatos al documento, de modo que el documento aparece como un nodo en el grafo.
Cuando se extraen aristas (relaciones/hechos) de los documentos, una relación `subjectOf` vincula la arista extraída con el documento de origen.
### Problemas con el Enfoque Actual
1.**Carga repetitiva de metadatos:** Los metadatos del documento se empaquetan y cargan repetidamente con cada lote de triples extraídos de ese documento. Esto es un desperdicio y redundante: los mismos metadatos viajan como carga con cada salida de extracción.
2.**Proveniencia superficial:** La relación `subjectOf` actual solo vincula los hechos directamente con el documento de nivel superior. No hay visibilidad de la cadena de transformación: qué página proporcionó el hecho, qué fragmento, qué método de extracción se utilizó.
2.**Proveniencia superficial:** La relación `subjectOf` actual solo vincula los hechos directamente al documento de nivel superior. No hay visibilidad de la cadena de transformación: qué página proporcionó el hecho, qué fragmento, qué método de extracción se utilizó.
1.**Cargar metadatos una vez:** Los metadatos del documento deben cargarse una vez y adjuntarse al nodo del documento de nivel superior, no repetirse con cada lote de triples.
2.**DAG de proveniencia rica:** Capturar toda la cadena de transformación desde el documento de origen a través de todos los artefactos intermedios hasta los hechos extraídos. Por ejemplo, una transformación de un documento PDF:
2.**DAG de proveniencia enriquecido:** Capturar la cadena de transformación completa desde el documento de origen a través de todos los artefactos intermedios hasta los hechos extraídos. Por ejemplo, una transformación de un documento PDF:
3.**Almacenamiento unificado:** El grafo de procedencia se almacena en el mismo grafo de conocimiento que el conocimiento extraído. Esto permite consultar la procedencia de la misma manera que se consulta el conocimiento: siguiendo los enlaces hacia atrás a lo largo de la cadena desde cualquier hecho hasta su ubicación de origen exacta.
5.**Enlace padre-hijo:** Los documentos derivados se vinculan a sus padres hasta el documento fuente de nivel superior, utilizando tipos de relación consistentes.
6.**Atribución precisa de hechos:** La relación `subjectOf` en los bordes extraídos apunta al padre inmediato (fragmento), no al documento de nivel superior. La procedencia completa se recupera recorriendo el DAG.
## Casos de uso
### UC1: Atribución de la fuente en las respuestas de GraphRAG
**Escenario:** Un usuario ejecuta una consulta de GraphRAG y recibe una respuesta del agente.
**Flujo:**
1. El usuario envía una consulta al agente de GraphRAG.
2. El agente recupera hechos relevantes del grafo de conocimiento para formular una respuesta.
3. De acuerdo con la especificación de procedencia en tiempo de consulta, el agente informa qué hechos contribuyeron a la respuesta.
4. Cada hecho se vincula a su fragmento de origen a través del grafo de procedencia.
5. Los fragmentos se vinculan a páginas, las páginas se vinculan a documentos fuente.
Profundizar desde hechos → fragmentos → páginas → documentos.
Examinar los documentos fuente originales para verificar las afirmaciones.
Comprender exactamente dónde en un documento (en qué página, en qué sección) se originó un hecho.
**Valor:** Los usuarios pueden verificar las respuestas generadas por la IA con fuentes primarias, lo que genera confianza y permite la verificación de hechos.
### UC2: Depuración de la calidad de la extracción
Un hecho parece incorrecto. Rastrear hacia atrás a través del fragmento → página → documento para ver el texto original. ¿Fue una mala extracción, o la fuente en sí misma estaba equivocada?
### UC3: Reextracción incremental
El documento fuente se actualiza. ¿Qué fragmentos/hechos se derivaron de él? Invalidar y regenerar solo esos, en lugar de volver a procesar todo.
### UC4: Eliminación de datos / Derecho al olvido
Se debe eliminar un documento fuente (GDPR, legal, etc.). Recorrer el DAG para encontrar y eliminar todos los hechos derivados.
### UC5: Resolución de conflictos
Dos hechos se contradicen. Rastrear ambos hasta sus fuentes para comprender por qué y decidir a cuál confiar (fuente más autorizada, más reciente, etc.).
### UC6: Ponderación de la autoridad de la fuente
Algunas fuentes son más autorizadas que otras. Los hechos se pueden ponderar o filtrar según la autoridad/calidad de sus documentos de origen.
### UC7: Comparación de la canalización de extracción
Comparar los resultados de diferentes métodos/versiones de extracción. ¿Qué extractor produjo mejores hechos del mismo documento fuente?
El componente de bibliotecario ya proporciona almacenamiento de documentos con identificadores de documentos únicos. El sistema de procedencia se integra con esta infraestructura existente.
#### Capacidades existentes (ya implementadas)
**Vinculación de documentos padre-hijo:**
Campo `parent_id` en `DocumentMetadata`: vincula el documento hijo al documento padre.
Campo `document_type`: valores: `"source"` (original) o `"extracted"` (derivado).
API `add-child-document`: crea un documento hijo con `document_type = "extracted"` automático.
API `list-children`: recupera todos los hijos de un documento padre.
Eliminación en cascada: eliminar un padre elimina automáticamente todos los documentos hijo.
El componente de "Librarian" ya proporciona almacenamiento de documentos con identificadores de documentos únicos. El sistema de procedencia se integra con esta infraestructura existente.
#### Capacidades Existentes (ya implementadas)
**Vinculación de Documentos Padre-Hijo:**
Campo `parent_id` en `DocumentMetadata`: vincula el documento hijo al documento padre.
Campo `document_type`: valores: `"source"` (original) o `"extracted"` (derivado).
API `add-child-document`: crea un documento hijo con `document_type = "extracted"` automáticamente.
API `list-children`: recupera todos los hijos de un documento padre.
Eliminación en cascada: eliminar un padre elimina automáticamente todos los documentos hijos.
El diseño se adapta a ambos porque el componente de segmentación trata su entrada de forma genérica; utiliza cualquier ID de documento que reciba como elemento padre, independientemente de si se trata de un documento fuente o de una página.
El diseño se adapta a ambos casos porque el componente de división de texto (chunker) trata su entrada de forma genérica; utiliza cualquier ID de documento que reciba como elemento padre, independientemente de si se trata de un documento fuente o de una página.
Los metadatos de procedencia utilizan la ontología W3C PROV-O. Esto proporciona un vocabulario estándar y permite la futura firma/autenticación de los resultados de la extracción.
**Incrustación (almacenada en un almacén de vectores, no en un almacén de triples):**
Las incrustaciones se almacenan en el almacén de vectores con metadatos, no como triples RDF. Cada registro de incrustación contiene:
| Campo | Descripción | Ejemplo |
|-------|-------------|---------|
| vector | El vector de incrustación | [0.123, -0.456, ...] |
| entity | URI del nodo que representa la incrustación | `entity:JohnSmith` |
| chunk_id | Fragmento de origen (procedencia) | `chunk:123-1-1` |
| model | Modelo de incrustación utilizado | `text-embedding-ada-002` |
| component_version | Versión del incrustador de TG | `1.0.0` |
El campo `entity` vincula la incrustación al grafo de conocimiento (URI del nodo). El campo `chunk_id` proporciona la procedencia de vuelta al fragmento de origen, lo que permite el recorrido ascendente del DAG hasta el documento original.
#### Extensiones del Espacio de Nombres de TrustGraph
Predicados personalizados dentro del espacio de nombres `tg:` para metadatos específicos de la extracción:
El grafo de conocimiento es neutral con respecto a la ontología y se inicializa vacío. Cuando se escriben datos de procedencia PROV-O en una colección por primera vez, el vocabulario debe inicializarse con etiquetas RDF para todas las clases y predicados. Esto garantiza una visualización legible por humanos en las consultas y la interfaz de usuario.
**Nota de implementación:** Este vocabulario de inicio debe ser idempotente, es decir, seguro de ejecutar varias veces sin crear duplicados. Podría activarse durante el procesamiento inicial de un documento en una colección, o como un paso separado de inicialización de la colección.
**Nota de implementación:** Este proceso de inicialización del vocabulario debe ser idempotente, es decir, seguro de ejecutar varias veces sin crear duplicados. Podría activarse durante el procesamiento inicial de un documento en una colección, o como un paso separado de inicialización de la colección.
Alternativamente, se puede realizar un procesamiento posterior para hacer coincidir de forma difusa las entidades extraídas con el texto fuente.
Compromiso entre la complejidad de la extracción y la granularidad de la procedencia.
Puede ser más fácil de lograr con métodos de extracción estructurados que con la extracción de LLM de formato libre.
Esto se considera una meta a largo plazo; primero se debe implementar la procedencia a nivel de fragmento, y el seguimiento de subfragmentos puede ser una mejora futura si es factible.
### Modelo de almacenamiento dual
El DAG de procedencia se construye progresivamente a medida que los documentos fluyen a través de la canalización:
| Almacén | ¿Qué se almacena | Propósito |
|-------|---------------|---------|
| Bibliotecario | Contenido del documento + enlaces padre-hijo | Recuperación de contenido, eliminación en cascada |
| Gráfico de conocimiento | Bordes padre-hijo + metadatos | Consultas de procedencia, atribución de hechos |
Ambos almacenes mantienen la misma estructura DAG. El bibliotecario almacena el contenido; el gráfico almacena las relaciones y permite las consultas de recorrido.
1.**El ID del documento como unidad de flujo**: Los procesadores pasan ID, no contenido. El contenido se recupera del bibliotecario cuando es necesario.
2.**Emitir una vez en la fuente**: Los metadatos se escriben en el gráfico una vez al inicio del procesamiento, no se repiten en procesos posteriores.
5.**Optimización posterior al fragmentador**: Después de la fragmentación, los mensajes contienen tanto el ID como el contenido. Los fragmentos son pequeños (2-4 KB), por lo que incluir el contenido evita viajes de ida y vuelta innecesarios al bibliotecario, al tiempo que preserva la procedencia a través del ID.
5.**Optimización posterior al fragmentador**: Después de la fragmentación, los mensajes contienen tanto el ID como el contenido. Los fragmentos son pequeños (2-4 KB), por lo que incluir el contenido evita viajes de ida y vuelta innecesarios al bibliotecario al tiempo que preserva la procedencia a través del ID.
