RAG corpus curation: el bibliotecario activo que decide qué entra, qué sale y qué firma

Mon, 25 May 2026 11:00:00 +0200

Esta es la capa de curación dentro de la etapa 1 (Data) del pipeline LLMOps de seis etapas. Complementa los otros posts Data: el de versionado de datasets para los cuatro artefactos versionables, el de ingestión PostgreSQL + Qdrant en microservicios para el patrón outbox + CDC, y el de RAG sobre Kafka y datalake para el transporte streaming. Aquí no hablamos de mover datos: hablamos de qué hacer con ellos antes de dejar que un modelo los lea.

TL;DR

Un RAG que sirve respuestas mediocres rara vez es culpa del retriever ni del modelo. La causa raíz suele estar en el corpus: tres versiones casi idénticas del mismo PDF que hacen que el top-k devuelva siempre tres veces lo mismo, un manual antiguo no eliminado que contradice al vigente, un campo libre con números de cliente que el modelo cita literalmente, un PDF escaneado con OCR sucio que el chunker partió por la mitad de una frase. Ninguna de esas cosas se arregla cambiando el modelo, el embedder, el rerankear o el prompt. Se arreglan curando el corpus. Este post desmonta las cinco capas operacionales de la curación (schema-validated ingest, deduplicación en tres niveles, anonimización PII medida con precision/recall, anti-contaminación con el golden eval, lineage chunk→trace), las matemáticas mínimas para no autoengañarse, el stack 2026 (Presidio, Unstructured, Argilla, LangChain text splitters, OpenLineage, Marquez, Great Expectations), las siete trampas que tiran la etapa al teatro, y el hardware on-premise para sostener todo esto sin enviar nada sensible a APIs externas.

La analogía: el bibliotecario activo

Un bibliotecario serio no acepta libros al peso. Cuando alguien le propone un volumen nuevo:

Mira el lomo, el ISBN y el sello: ¿es legible? ¿está catalogado correctamente? ¿pertenece a una colección reconocida? Sin metadata válida, no entra. Esto es el schema check.
Comprueba si ya tiene una copia: ¿es exactamente el mismo libro? ¿es una edición posterior del mismo? ¿es una versión traducida de algo que ya está? Si lo tiene, decide explícitamente qué hacer (sustituir, archivar la vieja, retirar las dos del préstamo). Esto es el dedup en sus tres niveles.
Marca lo restringido: si el libro contiene datos personales identificables, hay páginas que no se pueden prestar tal cual — hay que tacharlas, anonimizarlas o moverlas a la sección reservada. Esto es la anonimización PII.
Verifica que no es el libro del examen final del año: si lo es, fuera del fondo público hasta que cambie el temario, porque si los estudiantes lo consultan deja de medir lo que el examen pretende medir. Esto es la anti-contaminación con el golden eval set.
Anota en el registro: este libro, esta edición, esta procedencia, esta fecha, este responsable que aprobó la entrada. Esto es el lineage.

Si el libro pasa las cinco, entra al fondo. Si falla en cualquiera, va a una estantería de cuarentena auditable con la razón del rechazo. La diferencia entre un fondo bueno y uno mediocre no es el tamaño: es cuánta disciplina aplicas en las cinco capas, todos los días, sobre cada libro nuevo que llega.

El corpus de RAG es exactamente eso. Lo único distinto es la escala (miles o millones de documentos por mes) y que los “lectores” son LLMs que no saben distinguir un duplicado de una verdad reforzada, ni un dato PII de un ejemplo sintético, ni un fragmento contaminado de uno auténtico.

Los cuatro artefactos data y dónde encaja el corpus RAG

Antes de bajar a las cinco capas conviene ser claro sobre qué corpus estamos curando. La etapa Data del pipeline gestiona cuatro artefactos diferenciados, cada uno con disciplina distinta. El post de data versioning los enumera; aquí los reordeno desde la perspectiva de curación:

Artefacto	Quién lo consume	Curación dominante
Training dataset	Tune (fine-tuning del modelo o adapter)	dedup agresivo + filtros de calidad + balanceo por etiqueta
RAG corpus	Deploy (retrieval en tiempo de petición)	las 5 capas de este post
Golden eval set	Eval (gates de promotion)	hold-out estricto + estratificación + mantenimiento con incidentes
Retrain enriched dataset	Retrain (cierre del bucle)	feedback de producción + triage humano

El RAG corpus es el más volátil de los cuatro y el que más expuesto está al usuario final: cada respuesta que el sistema sirve contiene literalmente fragmentos suyos. Un duplicado en el training dataset degrada el aprendizaje pero queda enterrado en los pesos; un duplicado en el RAG corpus aparece en la respuesta de hoy y la de mañana. Esto justifica la disciplina extra que sigue.

Capa 1 — Schema-validated ingest

Toda pieza que entra al corpus tiene que llegar acompañada de metadata estructurada y validada contra un esquema. No es burocracia: es la única forma de hacer que las capas siguientes (dedup, PII, lineage) funcionen sin frituras.

El patrón canónico es definir un schema en JSON Schema o Pydantic que cada documento debe satisfacer:

class CorpusDocument(BaseModel):
 source_system: str # ej. "confluence", "salesforce", "manual_pdf"
 source_id: str # ID único en el sistema origen
 version: str # versión del documento (semver o fecha)
 language: str # ISO 639-1: "es", "en"
 title: str
 body: str
 captured_at: datetime
 captured_by: str # pipeline o humano
 sensitivity: Literal["public", "internal", "restricted"]
 schema_version: str # versión del propio schema, no del documento

Toda pieza que no cumple este contrato se rechaza al ingest, no llega a las capas siguientes. La validación se hace con Great Expectations (suites declarativas), Pandera (más pythónico, integra con pandas) o Soda (orientado a data quality continuo). La elección es estilo; lo decisivo es:

Las suites de validación viven en código y se versionan con el pipeline, no en un cuaderno aparte.
El rechazo genera un evento auditable (cuarentena) con la razón concreta del fallo de schema, no un log perdido en stdout.
El schema mismo se versiona — cuando cambia, los documentos previos se reprocesan o se mantiene compatibilidad backward explícita.

El post de RAG sobre Kafka cubre el patrón Schema Registry (Confluent Schema Registry o Apicurio) que materializa esto en streaming: cada mensaje del topic se valida contra el schema registrado antes de propagarse aguas abajo. Para batch o pull, Great Expectations es el equivalente.

Trampa habitual: dejar el campo body libre sin más validación. Hay que afinar — longitud mínima/máxima (un PDF que arroja 12 caracteres tras la extracción seguramente está roto), encoding válido (UTF-8 sin caracteres de control), proporción de caracteres alfanuméricos (un OCR sucio devuelve sopa de signos). Estas son reglas simples que filtran el 80% del ruido sin necesidad de IA.

Capa 2 — Deduplicación en tres niveles

El error más caro y silencioso del corpus RAG es el duplicado. Un documento que aparece tres veces en el corpus consigue que el top-k del retrieval lo devuelva tres veces — desperdiciando dos slots y reforzando una sola fuente. El LLM lo lee como si tres fuentes independientes coincidieran, cuando en realidad es la misma cosa repetida.

La deduplicación se hace en tres niveles, en este orden por coste:

Nivel A — Exact dedup (hash SHA-256)

Calcular el hash del contenido normalizado (trim, lower-case si aplica, eliminar whitespace redundante) y comparar contra un índice de hashes ya ingeridos. Si coincide, descarta o sustituye. Coste: (O(1)) por documento. Atrapa duplicados literales (el mismo PDF subido dos veces, dos copias byte-a-byte del mismo HTML).

Nivel B — Near-duplicate (MinHash + LSH)

Documentos casi idénticos con diferencias menores (un encabezado distinto, una fecha actualizada, una versión en castellano y otra en gallego con cambios mínimos). El algoritmo canónico es MinHash con Locality-Sensitive Hashing (LSH), que aproxima la similitud de Jaccard sobre shingles de k tokens. Para n documentos, comparar todos contra todos es (O(n^2)) — inviable para corpus grandes. LSH reduce el coste a (O(n)) buckets más probables.

Un threshold típico es Jaccard ≥ 0,80 sobre shingles de 5 tokens. Las librerías estándar son datasketch (Python, MIT) o dedup (Python, MIT). Ejemplo numérico: para 1 M de documentos cortos (300 tokens cada uno), datasketch.MinHashLSH con 128 permutations y threshold 0,8 ocupa ~2 GB de RAM y procesa el corpus completo en ~30 minutos sobre una CPU moderna. La fracción de duplicados detectados en un corpus empresarial real suele estar entre el 5% y el 25% — eliminarlos reduce el storage y mejora la calidad del retrieval simultáneamente.

Nivel C — Semantic dedup (coseno sobre embeddings)

Documentos que dicen lo mismo en palabras distintas — paráfrasis, traducciones, versiones reescritas — no los captura MinHash. Aquí entra la similitud semántica: calcular el embedding de cada documento y comparar el coseno entre pares.

El problema es de coste cuadrático: para n documentos, calcular todas las parejas es (O(n^2)). Para n = 1 M y embeddings de 768 dimensiones (modelo típico tipo BAAI/bge-base-en-v1.5), son 5×10^11 dot products — inviable. La solución es la misma idea que LSH pero sobre vectores densos: HNSW (Hierarchical Navigable Small World) o IVF (Inverted File) para construir un índice de búsqueda aproximada. Para cada documento nuevo, se hace una query k-NN al índice y se examinan sólo los k vecinos más cercanos.

Threshold sensato para considerar duplicado semántico: coseno ≥ 0,95. Por debajo de 0,95 son documentos relacionados pero distintos; por encima, casi siempre son la misma información reescrita. El threshold exacto se calibra observando precision/recall sobre una muestra anotada por humanos — 100 pares confirmados por revisor es razonable para fijarlo.

Ejemplo numérico: con qdrant o pgvector como índice HNSW y k=10 vecinos por query, deduplicar 1 M de documentos contra el corpus existente lleva del orden de 2-4 horas sobre una RTX 4090 (incluyendo el cómputo de embeddings). Si el embedder es self-hosted con vLLM, el coste por token es despreciable contra el tiempo de cómputo.

Política de qué hacer con un duplicado

Detectar no es suficiente — hay que decidir. Tres políticas comunes, en orden de complejidad:

Drop: descartar el más reciente, mantener el más antiguo. Simple, sin lineage extra.
Replace: descartar el viejo, indexar el nuevo. Más volatilidad pero refleja la actualización.
Merge with provenance: marcar el nuevo como “shadow” del viejo, mantener ambos en lineage pero indexar sólo uno. Mejor para auditoría regulada.

La política tiene que ser explícita y aplicada por igual, no decisión ad-hoc por documento.

Capa 3 — Anonimización PII con precision/recall medidos

Esta capa es la que más fácilmente se vuelve teatro. El error típico: instalar Presidio, ejecutarlo sobre el corpus, asumir que el output está limpio. Sin medir precision y recall del detector contra un golden anotado, no sabes nada.

El detector de PII puede fallar de dos formas:

Falso negativo (recall bajo): no detecta un DNI escrito como “12345678-A” porque tu modelo está entrenado en formato 12345678A sin guión. El RAG sirve datos personales sin redactar.
Falso positivo (precision baja): redacta el número de un manual de configuración pensando que es un teléfono. El RAG pierde información útil.

Los dos son problemas; la regulación (RGPD, ENS, NIS2) penaliza el primero, la experiencia del usuario se degrada con el segundo. El ratio aceptable depende del dominio — en datos médicos prácticamente cero falsos negativos es no-negociable; en documentación técnica interna se puede tolerar más recall a cambio de menos precision.

La métrica estándar es F1 sobre un golden anotado:

[ \text{precision} = \frac{TP}{TP + FP}, \quad \text{recall} = \frac{TP}{TP + FN}, \quad F_1 = 2 \cdot \frac{\text{precision} \cdot \text{recall}}{\text{precision} + \text{recall}} ]

Para construir el golden de PII, anotar ~200 documentos a mano con cada entidad marcada (DNI, IBAN, email, teléfono, dirección, nombre propio). Después, ejecutar el detector y calcular las métricas por categoría — no solo agregadas, porque un F1 global 0,90 puede esconder un recall 0,55 sobre IBANs.

Stack 2026 para esta capa:

Microsoft Presidio (MIT, Microsoft): el OSS más completo. Detectores configurables, reconoce ~50 entidades por defecto, extensible con patrones regex propios o con modelos NER fine-tuneados.
spaCy NER (MIT, Explosion AI): base para detectores custom; útil cuando Presidio no cubre una entidad de dominio.
Llama Guard 4 (LLama Community License, Meta): clasificador safety que también detecta PII en una pasada — opción cuando ya tienes GPU para inferencia y prefieres una sola pasada.
DataFog (Apache 2.0): alternativa más reciente, especializado en pipelines streaming.

Patrón híbrido recomendado: Presidio para detección rule-based + regex (rápido, deterministic) → Llama Guard como segunda pasada sobre lo que Presidio no marcó (ensemble que sube recall sin matar throughput). Esto se mide y se reporta como F1 agregado y por categoría en cada release del detector.

Falacia común: confiar en que un detector con F1 0,95 “es muy bueno”. Si tienes 1 M de documentos y cada uno contiene 1 entidad PII media, F1 0,95 significa 50.000 entidades mal manejadas (entre falsos positivos y negativos). En datos sensibles, hay que diseñar para que los falsos negativos vayan a cuarentena humana, no al corpus público.

Capa 4 — Anti-contaminación con el golden eval set

Si el RAG corpus contiene fragmentos del golden eval set, las métricas de Eval miden memorización. El modelo devuelve la respuesta exacta porque la tiene literalmente en su contexto, no porque haya generalizado nada. El deploy promociona modelos que brillan en el examen y fallan en producción.

Esta capa es la más fácil de implementar y la más fácil de olvidar:

El golden eval set tiene su hash versionado.
Antes de indexar cualquier documento nuevo en el corpus RAG, ejecutar un check de overlap token-a-token (o por shingles, similar a MinHash) contra el golden set.
Si hay overlap superior a un umbral (típicamente ≥ 30% de n-gramas de 5 tokens), el documento no se indexa. Se queda en cuarentena con bandera de “contamination risk vs golden_v12”.
Un humano revisa los rechazos. A veces son falsos positivos (cita corta, frase boilerplate). A veces son contaminación real que un proveedor metió sin darse cuenta.

La razón profunda: el RAG corpus y el golden set son artefactos enemigos por diseño. El golden mide qué tan bien el sistema generaliza a preguntas que no ha visto. Si esas preguntas están en el RAG, el sistema las “ve” en cada query. La métrica deja de medir generalización.

Este check es trivial computacionalmente — un hash join sobre n-gramas. La complejidad está en mantenerlo: cada vez que el golden cambia (mensual o trimestral), hay que re-validar el corpus completo contra el nuevo golden. Sin esa disciplina, la contaminación entra por la puerta de atrás cuando alguien actualiza el golden con casos reales que ya estaban siendo servidos por el RAG.

Capa 5 — Lineage end-to-end: del documento al trace

La última capa es la que cierra la cadena auditable. Cada chunk que se indexa en el vector store lleva metadata que permite responder a la pregunta forense:

“El sistema generó esta respuesta el 14 de marzo a las 16:23. ¿De qué documento exacto salió el fragmento citado? ¿Cuándo entró ese documento al corpus? ¿Qué versión del embedder lo procesó? ¿Quién aprobó su ingest?”

Sin lineage, esa pregunta es irrespondible. Con lineage bien hecho, son cuatro queries.

El patrón canónico:

Cada chunk indexado lleva en su metadata: source_system, source_id, document_version, chunk_index, embedder_version, dataset_hash, ingested_at, ingested_by, schema_version.
Cada respuesta del RAG en producción emite un span de trace que incluye los chunk_id recuperados.
El sistema central de tracing (Langfuse, Phoenix u OpenLLMetry) une chunk_id → metadata del chunk → metadata del documento → dataset_hash del corpus → versión del embedder → etc.

Las herramientas que estandarizan este pegamento son OpenLineage (Apache 2.0, LF AI & Data) y Marquez (Apache 2.0, su implementación de servidor). Definen un schema de eventos de lineage interoperable entre sistemas; un job de ingest emite un evento “produced corpus_v12.3 from source X with embedder bge-base-v1.5”; un job de retrieval emite “consumed corpus_v12.3 with query Q produced response R”. El grafo se reconstruye automáticamente.

Esta capa es la única forma de cumplir auditorías reales bajo regulaciones tipo EU AI Act, RGPD o ENS, donde la trazabilidad de qué dato entró en qué respuesta es exigencia, no opción. Sin ella, la respuesta “no sabemos de qué documento salió esto” no es aceptable — y es la respuesta por defecto si no se construye el lineage desde el día uno.

Las matemáticas que importan

Más allá de los thresholds de dedup y las F1 de PII, hay tres piezas matemáticas que cualquier equipo serio acaba usando.

Chunk size vs retrieval quality. El tamaño del chunk afecta la calidad del retrieval de forma no monótona: chunks demasiado pequeños fragmentan ideas (el retrieval devuelve un trozo sin contexto), demasiado grandes diluyen la señal (el embedding mezcla varios temas y la similitud baja). El sweet spot empírico para textos técnicos en 2026 está entre 256 y 768 tokens por chunk, con overlap de 15-25% entre chunks contiguos para preservar continuidad.

Numéricamente, para un corpus de 1 M documentos con longitud media 2.000 tokens, chunkear a 512 tokens con overlap 100 da: (\frac{2000}{512 - 100} \approx 5) chunks por documento, total ≈ 5 M chunks indexados. Con embeddings de 768 dimensiones y float32, ocupa (5 \cdot 10^6 \cdot 768 \cdot 4 \approx 15) GB de memoria de vectores — manejable en cualquier vector store moderno.

Cobertura del golden de PII. Para saber si el golden anotado de PII es suficientemente representativo, calcular la proporción de categorías cubiertas: si tu golden de 200 documentos tiene 5 ejemplos de IBAN y producción tiene 12.000 IBANs por día, el F1 sobre IBANs medido es ruido estadístico. Regla práctica: mínimo 30 ejemplos por categoría para que las métricas por categoría tengan sentido.

Coste de re-embedding al rotar el modelo. Cambiar el embedder invalida el índice entero. Para un corpus de 5 M chunks con un modelo tipo BAAI/bge-base-en-v1.5 (768 dim, ~110 M parámetros) servido en vLLM sobre 1× H100, el throughput es del orden de 8.000-15.000 chunks/segundo. Re-embedding completo: ~5-10 minutos. Para un embedder más grande (bge-large, 1024 dim, ~335 M parámetros): factor 3× peor, ~15-30 minutos. El cuello de botella suele ser el I/O del vector store, no el cómputo GPU. El patrón dual-index —mantener el índice viejo sirviendo mientras se construye el nuevo, swap atómico al final— evita downtime y permite rollback.

Aplicado a hardware on-premise típico

Para un despliegue on-premise que mantenga toda la curación sin enviar datos a APIs externas:

RTX 4090 (24 GB): cubre la capa 1 (schema check con Great Expectations es CPU-bound), capa 2 nivel A y B (hash + MinHash son CPU-bound), capa 2 nivel C semantic dedup con embedder tipo bge-base (8-15k chunks/s, suficiente para corpus de hasta 5-10 M chunks en horas). Para Presidio en modo NER (capa 3) corre cómodo. Es la GPU razonable para todo el pipeline de curación en corpus mid-size.
Configuración genérica 4×H100 SXM (320 GB total, NVLink): necesaria sólo si el corpus supera ~50 M chunks o si quieres re-embeddings frecuentes con modelos grandes (bge-large, e5-mistral). En la práctica, dos GPUs sirven el embedder en TP=2 con throughput >50k chunks/s, las otras dos van para el judge PII (Llama Guard 4) o para serving del modelo principal de inferencia. Capacity para corpora de cientos de millones de chunks.

La cuenta tozuda: con 4090, la curación del corpus es una tarea overnight; con 4×H100, es minutos. La decisión depende del tamaño del corpus y de la frecuencia con la que rotas embedder o reglas PII.

Las siete trampas que matan esta etapa

Trampa 1 — Sin schema validado al ingest. Documentos malformados llegan al chunker, el chunker los trocea sin sentido, embeddings basura entran al índice. La respuesta del RAG cita texto incoherente y nadie sabe por qué.

Trampa 2 — Dedup sólo a nivel exact hash. El corpus se llena de paráfrasis y traducciones del mismo documento. El top-k del retrieval devuelve 3 veces la misma fuente. El LLM la lee como tres confirmaciones.

Trampa 3 — PII detector sin medición de precision/recall. Se asume que Presidio “funciona”. Los IBANs en formato no estándar se cuelan. El RAG sirve datos personales.

Trampa 4 — Golden eval set contaminado con corpus. Las métricas de Eval miden memorización. Promociones aprueban modelos que fallan en producción real.

Trampa 5 — Sin lineage al chunk. La pregunta “¿de dónde salió esta cita?” no tiene respuesta. La auditoría regulatoria fracasa. Los incidentes no se pueden investigar.

Trampa 6 — Mantenimiento como evento puntual. El corpus se cura una vez al inicializar el sistema, después se asume que está bien. Tras 6 meses, los documentos están desactualizados, las nuevas reglas PII no se aplican retrospectivamente, el dedup no se re-corre tras añadir nuevas fuentes. El corpus se degrada en silencio.

Trampa 7 — Cuarentena sin revisión humana. Los documentos rechazados van a una tabla que nadie mira. Los falsos positivos se acumulan, los verdaderos casos de contaminación no se investigan, la confianza del equipo en la curación se erosiona y empieza la presión para “relajar los umbrales”.

Las siete son operacionales, no técnicas. La curación del corpus no se rompe por un bug del algoritmo: se rompe porque la disciplina se relaja. Es el equivalente exacto del tipo de degradación que mata las suites de Eval — y en ambos casos el síntoma es el mismo: las métricas mejoran o se mantienen mientras la experiencia real empeora.

Lo que no hemos cubierto (próximos posts)

Vector store versioning propiamente dicho: un índice de embeddings no se versiona como un dataset crudo porque depende del modelo de embedding. Cambiar el embedder reescribe todo el índice. Es otro animal con sus propios patrones (branching del índice, reembedding selectivo, recall-aware ANN parameters).
Streaming corpus updates con CDC: cuando el corpus tiene que actualizarse en near-real-time desde un sistema OLTP. El post de ingestión Postgres + Qdrant cubre la mecánica; queda pendiente el patrón de invalidación selectiva de chunks que dependen de filas borradas.
Multi-tenant corpus isolation: cómo se monta un corpus compartido vs uno con namespaces por tenant, con ACLs sobre chunks individuales. Especialmente relevante para RAG multi-cliente bajo soberanía de datos.
Federated corpus: corpora distribuidos en silos que el sistema consulta sin centralizar el contenido. Patrón emergente para empresas con varias sedes y restricciones cross-border.
Reranking aware curation: cómo cambia la disciplina de curación cuando hay un reranker (Cohere Rerank, ColBERTv2, BGE-Reranker) que reordena el top-k tras la retrieval. Algunos duplicados que tolerarías sin reranker no se toleran cuando el reranker les sube en el ranking. La mecánica de la capa de retrieval (hybrid BM25 + dense + reranker) está desarrollada en el post de reranker y hybrid retrieval.

Ver también

El pipeline LLMOps de seis etapas — Etapa 1 (Data) y por qué la curación es la sub-tarea más infravalorada de toda la cadena.
Anatomía de una petición LLM en producción, mayo 2026 — el tour forense cruza el corpus y los chunks recuperados; aquí están los criterios que cualquier chunk tuvo que pasar para estar en producción.
Data versioning: DVC, lakeFS y el reto del golden dataset reproducible — los cuatro artefactos data y por qué se versionan diferenciados. El corpus RAG es uno de los cuatro.
PostgreSQL + Qdrant en la etapa de ingestión — el patrón de microservicios que mueve documentos desde origen hasta el vector store. La curación de este post se enchufa entre el ingest y el indexador.
RAG sobre Kafka y datalake — el transporte streaming. Schema Registry materializa la capa 1.
Reranker y hybrid retrieval: el comité que decide los 5 chunks que el LLM va a leer — la capa siguiente. El bibliotecario de este post decide qué entra al índice; aquel decide qué sale del índice al contexto del LLM.
Evals para LLMs: la capa después del tracing — el golden eval set es el “enemigo por diseño” del corpus RAG; la capa 4 (anti-contaminación) materializa la disciplina entre ambos.
Prompt versioning: el contrato que evita que un cambio de cinco palabras hunda tu sistema — el prompt_id que viaja en el trace es el complemento del dataset_hash del corpus en lineage.
Retrain: cerrar el bucle entre el incidente en producción y el adapter que lo arregla — el corpus enriched de retrain también necesita las cinco capas, con énfasis adicional en el feedback humano.
El catálogo OSS para LLMOps en seis etapas — fichas de Presidio, Unstructured, Argilla, Great Expectations, OpenLineage.

Referencias

Presidio: https://microsoft.github.io/presidio/ — docs oficiales, lista de entidades soportadas, guía de extensión con NER custom.
OpenLineage: https://openlineage.io/ — spec del schema de eventos y libs por lenguaje.
Marquez: https://marquezproject.ai/ — implementación de servidor de OpenLineage.
datasketch (MinHash + LSH): https://ekzhu.com/datasketch/ — librería Python de referencia para deduplicación near-duplicate a escala.
Great Expectations: https://docs.greatexpectations.io/ — suites declarativas de data quality.
Unstructured: https://docs.unstructured.io/ — parseo y normalización de documentos heterogéneos (PDF, HTML, DOCX, eml) antes del chunking.
Argilla: https://docs.argilla.io/ — UI de anotación humana para construir el golden de PII y otros calibration sets.
Llama Guard 4: paper técnico de Meta, multimodal safety classifier — útil como segunda capa de detección PII.
RGPD, EU AI Act, ENS, NIS2 — los marcos regulatorios cuya conformidad depende, en la práctica, de la disciplina de las capas 3 (PII) y 5 (lineage). Pendiente la publicación final de los technical standards de CEN/CENELEC para conformity assessment de sistemas GenAI bajo EU AI Act.

Data-Curation on lo0 — Blog Técnico