Los cuatro errores que arruinan un dataset hecho con tus documentos
Duplicados, contaminación, fuga por troceado y datos personales: cuatro errores documentados, cómo arreglarlos y por qué el tercero engaña a tu métrica.
Por Brayan Pedraza11 min de lectura
En corto
Los cuatro errores son: dejar texto duplicado, que el modelo memoriza en vez de generalizar; contaminar el conjunto de evaluación con fragmentos del de entrenamiento; trocear los documentos antes de repartirlos, que filtra la misma plantilla a entrenamiento y a prueba; y dejar dentro datos personales, que el modelo puede acabar recitando. El tercero es el más peligroso porque no da error: sube la métrica y parece que el modelo aprendió.
Los cuatro están documentados. Los cuatro tienen arreglo. Y los cuatro aparecen casi siempre que alguien construye por primera vez un conjunto de datos con documentos de su empresa, porque los pipelines públicos están pensados para corpus web y los documentos de oficina se comportan distinto: más plantilla, más repetición, más datos personales por página.
1. Duplicados: el modelo memoriza en vez de aprender
Lee y otros, Deduplicating Training Data Makes Language Models Better (ACL 2022, arXiv:2107.06499):
«over 1% of the unprompted output of language models trained on these datasets is copied verbatim from the training data […] Deduplication allows us to train models that emit memorized text ten times less frequently and require fewer train steps to achieve the same or better accuracy.»
Dos cifras para dimensionarlo. En C4 encontraron una frase de 61 palabras repetida más de 60.000 veces. CCNet (arXiv:1911.00359) midió que los párrafos duplicados eran el 70 % del texto de su corpus.
Y Carlini y otros (arXiv:2202.07646) muestran que la memorización crece log-linealmente con el número de veces que aparece un ejemplo. Deduplicar no es solo calidad: es privacidad.
En documentos de empresa el problema es peor, no mejor. La misma plantilla de contrato, el mismo membrete, el mismo informe en dos versiones, el mismo párrafo de tratamiento de datos en cada anexo.
Qué parámetros usa la gente
El consenso es shingles de 5-gramas de palabras. El resto varía:
| Pipeline | Hashes | Umbral |
|---|---|---|
| The Pile | 10 | 0,5 |
| FineWeb | 112 (14 bandas × 8) | 0,75 |
| text-dedup (por defecto) | 240 | 0,7 |
| RefinedWeb / Lee et al. | 9.000 (20 × 450) | 0,8 |
RefinedWeb (arXiv:2306.01116) critica explícitamente los 10 hashes de The Pile: dieron «lower deduplication rates and worse model performance».
El detalle que cuesta una tarde: bajar el umbral no basta si el bandeado LSH no acompaña. El bandeado determina qué pares se comparan siquiera; si está fijo, puedes bajar el umbral todo lo que quieras y no encontrarás un duplicado más, porque esos pares nunca llegan a compararse.
2. Contaminación: la métrica deja de medir
Si un fragmento del conjunto de evaluación está también en el de entrenamiento, la puntuación no mide lo que el modelo aprendió sino lo que recordó.
GPT-3 (arXiv:2005.14165, apéndice C) fijó el método:
«We attempted to remove text occurring in benchmarks from training data by searching for 13-gram overlaps […] We ignored 13-grams that matched more than 10 training documents, as inspection showed the majority of these to contain common cultural phrases, legal boilerplate, or similar content.»
Esa segunda frase es la que importa en documentos de empresa, donde el formulario domina el texto.
Llama 3 (arXiv:2407.21783) usa hoy 8-gramas con umbral de fracción de tokens, y publicó cuánta contaminación tienen los benchmarks conocidos: AGIEval 98 %, BIG-Bench Hard 95 %, HellaSwag 85 %, GSM8K 41 %. Tulu 3 encontró NuminaMath-TIR contaminado un 11,3 % contra MATH.
Límite conocido: el solapamiento de n-gramas no ve una paráfrasis. Un modelo entrenado con un benchmark reescrito puntúa alto y pasa el filtro.
3. Fuga por troceado: el error silencioso
Este es el que más veces se comete y el que menos se nota, porque el resultado es una métrica mejor.
Si troceas los documentos primero y repartes los trozos después, dos fragmentos del mismo contrato acaban uno en entrenamiento y otro en prueba. El modelo ya vio la plantilla, el vocabulario y el formato. No ha generalizado: ha reconocido.
El principio está en la documentación de scikit-learn sobre validación cruzada:
«we need to ensure that all the samples in the validation fold come from groups that are not represented at all in the paired training fold»
Kapoor y Narayanan, Leakage and the Reproducibility Crisis in ML-based Science (arXiv:2207.07048), lo catalogan como fuga tipo L3.2 y contabilizan 329 artículos afectados en 17 campos. Un trabajo sobre ventanas deslizantes cuantifica el efecto: el reparto ingenuo «can inflate classification accuracy from a genuine ~20–60 % to an artefactual 99.9 %», con los mismos datos y el mismo modelo.
Hasta The Pile lo admite de sí mismo: «it is still possible that some documents are duplicated across the train/validation/test splits».
El arreglo es simple: reparte por documento, no por trozo. Y que el reparto sea estable, para poder regenerar el conjunto sin invalidar la evaluación anterior: misma semilla, mismo reparto, y añadir un documento nuevo no mueve de partición a los que ya estaban.
Lo que el reparto por documento no arregla: dos documentos distintos pueden ser casi iguales, como dos versiones del mismo contrato. Por eso hacen falta también los pasos 1 y 2.
4. Datos personales que el modelo acaba recitando
Carlini y otros, Extracting Training Data from Large Language Models (USENIX Security 2021, arXiv:2012.07805), extrajeron de GPT-2 cientos de secuencias literales, incluidos «names, phone numbers, and email addresses», de secuencias que aparecían en un solo documento del corpus. Y los modelos grandes son más vulnerables que los pequeños.
Lo que hacen los pipelines públicos es menos de lo que parece:
- Dolma (arXiv:2402.00159) se limita a «three kinds of PII that are detectable with high precision: email addresses, IP addresses and phone numbers». Si un documento tiene más de cinco apariciones, lo descarta entero.
- FineWeb anonimiza solo correos e IP públicas.
- Llama 3 elimina dominios enteros con mucha PII, no la PII en sí.
- StarCoder (arXiv:2305.06161) entrenó un detector con 22.950 entidades anotadas a mano: EMAIL 99 %, NAME 89 %, y identificador genérico 53 %, tan malo que lo excluyeron.
Esa última cifra es la lección honesta: nadie detecta identificadores genéricos de forma fiable, ni con anotadores humanos. Cualquier herramienta que te prometa anonimización perfecta te está vendiendo algo.
Lo razonable: anonimizar por defecto, contar cuántas sustituciones se hicieron, avisar si lo desactivas, y que sea reversible con un mapa que se queda contigo. Una sustitución irreversible por un token fijo destruye información que quizá necesites; una reversible te deja volver.
El orden importa
Los cuatro pasos no son independientes:
- Deduplicar antes de repartir. Si repartes primero, los casi-duplicados se reparten a los dos lados y el paso 3 no te salva.
- Anonimizar antes de exportar, pero clasificar antes de anonimizar: los marcadores borran justo las palabras que delatan de qué tipo es el documento.
- Medir contaminación al final, contra el conjunto de evaluación real, y con el fragmento literal que coincidió en el informe, para poder comprobarlo en vez de creerlo.
Cómo comprobarlo en tus documentos
Sin instalar nada, en el navegador: PDF a datos de IA enseña cuántos duplicados salieron, cuántos datos personales se sustituyeron y cómo quedó el reparto.
En terminal, cada paso por separado y con salida JSON para scripts:
npx sirdas dedupe docs/*.pdf --threshold 0.8 --json
npx sirdas boilerplate docs/*.pdf
npx sirdas contamination train/*.pdf --against eval/*.pdf --n 13