Text and Data Mining: por qué la calidad del dato de entrada destruye más pipelines que el código

Text and Data Mining: por qué la calidad del dato de entrada destruye más pipelines que el código

Cuando un pipeline de Text and Data Mining falla en producción, el primer instinto es mirar el código. Se revisan las transformaciones, se auditan las llamadas a la API, se buscan excepciones sin capturar. En la mayoría de los casos, el problema no está ahí.

El dato de entrada lleva roto desde mucho antes.

Este es el patrón más repetido en proyectos de TDM que escalan: el prototipo funciona sobre datos limpios, cuidados, preparados a mano. En producción, el volumen obliga a automatizar la ingesta. Y ahí aparecen los problemas que nadie anticipó en el diseño: textos duplicados, campos vacíos en posiciones críticas, codificaciones inconsistentes, marcado HTML sin limpiar, idiomas inesperados, fechas sin zona horaria.

El algoritmo no tiene la culpa. El modelo tampoco. El problema es estructural y empieza en la capa más temprana del pipeline.

El ruido que no parece ruido

El dato basura evidente —campos null, cadenas vacías, registros malformados— se detecta pronto. El problema real es el ruido que parece válido pero no lo es.

Un texto duplicado que llega por dos fuentes distintas no rompe ninguna validación de esquema. Un artículo cuya fecha de publicación está en UTC pero se procesa como hora local no lanza ningún error. Un campo de 400 caracteres que en realidad es el pie de página del sitio web, no el contenido de interés, pasa todos los filtros de longitud mínima.

Este tipo de contaminación tiene efectos acumulativos. En análisis de sentimiento, duplicados no detectados inflan artificialmente el peso de ciertas menciones. En extracción de entidades, el HTML residual genera falsos positivos. En clasificación por relevancia, los metadatos mal asignados desvían las frecuencias de términos de forma silenciosa.

El sistema sigue funcionando. Los resultados simplemente son peores. Y ese deterioro es difícil de rastrear hasta su origen.

Dónde fallan las validaciones habituales

La validación estándar en un pipeline de TDM suele cubrir tres capas: esquema (¿el campo existe y tiene el tipo correcto?), completitud (¿hay un porcentaje mínimo de campos rellenos?) y unicidad básica (¿hay registros duplicados por ID?).

Esas tres capas son necesarias, pero insuficientes.

Lo que no cubren es la semántica del dato: si el contenido del campo es coherente con lo que ese campo debería contener. Ejemplos concretos:

• Un campo body que contiene solo boilerplate de cookie consent.
• Un campo language que dice es pero el texto está en catalán o en portugués.
• Un campo published_at que contiene la fecha de indexación, no la de publicación original.
• Un campo source que agrupa bajo el mismo dominio decenas de subdominios con líneas editoriales distintas.

Ninguno de estos casos rompe una validación de esquema. Todos distorsionan el análisis.

Qué controles añadir antes de que el dato entre al pipeline

El enfoque práctico es añadir una capa de validación semántica ligera entre la ingesta y el procesamiento. No hace falta un sistema complejo: basta con reglas deterministas que cubran los vectores de error más frecuentes.

Control de idioma real. No confíes en el campo declarado. Aplica detección de idioma sobre el texto —librerías como langdetect o lingua son suficientes para este paso— y descarta o segrega los registros que no coinciden con el idioma esperado.

Control de densidad de contenido. Define un umbral mínimo de tokens de contenido real, excluyendo stopwords. Un texto de 300 caracteres con 80% de stopwords o signos de puntuación no aporta señal útil al análisis.

Normalización de fechas con zona horaria explícita. Toda fecha debe convertirse a UTC antes de entrar al pipeline. Si la fuente no provee zona horaria, documenta la suposición y aplícala consistentemente. Los análisis de tendencias temporales son especialmente sensibles a este error.

Deduplicación por huella de contenido, no por ID. El mismo contenido puede llegar con identificadores distintos desde fuentes distintas. Una huella de similitud sobre los primeros 200 caracteres del texto (hash o similitud coseno) detecta duplicados que el ID nunca detectará.

Control de boilerplate. Mantén una lista de patrones frecuentes en textos no deseados: avisos legales, formularios de suscripción, mensajes de error HTTP. Un simple filtro de expresiones regulares sobre el inicio y el final del campo body elimina buena parte de este ruido antes de que llegue al modelo.

El coste de ignorarlo: no es solo precisión

El argumento técnico es claro. Pero hay un argumento de negocio que pesa más en entornos B2B: el coste de procesar datos sucios escala con el volumen.

Cada registro que entra al pipeline consume tokens si hay un LLM de por medio, consume cómputo si hay un modelo de clasificación, y consume tiempo de ingeniería cuando el resultado es incorrecto y hay que trazar la causa.

En un modelo de consumo pay-as-you-go —como el que opera FeedScale— el coste de una llamada a API con un texto de entrada basura es exactamente el mismo que el de una llamada con un texto limpio. La diferencia es que solo una de las dos produce un resultado útil.

Dicho de otro modo: la calidad del dato de entrada no es un problema de calidad del análisis. Es un problema de eficiencia económica del pipeline.

Cuándo aplicar estas validaciones

La respuesta instintiva es "antes de la ingesta". Pero en la práctica, muchos equipos no controlan la fuente: consumen una API externa y reciben lo que la API entrega.

En ese escenario, el punto de intervención es la capa de staging: un área intermedia donde el dato llega bruto, pasa por los controles descritos y solo se promueve al pipeline de análisis si supera los umbrales definidos. Los registros rechazados no se descartan; se almacenan con una etiqueta de motivo de rechazo, para poder auditar la fuente y ajustar los umbrales con el tiempo.

Este patrón tiene una ventaja adicional: te da visibilidad real sobre la calidad de cada fuente de datos. Después de varias semanas en producción, puedes cuantificar qué porcentaje de los registros de cada fuente pasan el filtro. Esa métrica dice más sobre el valor real de una fuente de datos que cualquier SLA comercial.

La calidad del dato de entrada no es un problema que se resuelve una vez. Es un proceso continuo de observabilidad y ajuste. Los equipos que lo tratan como un paso puntual de limpieza antes del lanzamiento suelen encontrarse, meses después, auditando resultados que no cuadran y sin saber por qué. Los que lo diseñan como una capa permanente del pipeline rara vez llegan a ese punto.

← Volver al blog