La calidad de datos de IA es un problema de dominio, no un problema de código

Existe una creencia persistente en la industria de IA de que la calidad de datos es un desafío de ingeniería. Construye un mejor pipeline. Escribe más reglas de validación. Agrega verificaciones automatizadas de calidad. Despliega detección estadística de anomalías. Si los datos son malos, el razonamiento dice, el código no es lo suficientemente bueno.

Esta creencia es incorrecta. La calidad de datos es fundamentalmente un problema de conocimiento del dominio. Ninguna cantidad de sofisticación en ingeniería puede compensar la falta de comprensión sobre lo que significan los datos, qué valores son correctos y cómo se ve la "calidad" en el contexto específico del problema que estás intentando resolver.

La ilusión del pipeline

Considera una empresa construyendo un modelo para clasificar tickets de soporte al cliente por urgencia. Su ingeniería de datos es excelente:

• Ingestión automatizada desde 5 fuentes de tickets
• Deduplicación usando coincidencia difusa con umbral de similitud de 0.92
• Validación de esquema asegurando que todos los campos requeridos estén presentes
• Verificaciones estadísticas señalando valores atípicos en longitud de texto y tiempo de respuesta
• División automatizada train/test con estratificación

El pipeline está limpio. El código es robusto. El modelo se entrena con 50,000 tickets y logra 73% de precisión en clasificación de urgencia.

El problema no es el pipeline. El problema es que los criterios de etiquetado para "urgente" versus "alta prioridad" versus "normal" fueron definidos por un ingeniero de ML que nunca había trabajado en soporte al cliente. En su esquema, un ticket sobre una caída de producción que afecta a 3 usuarios es "alta prioridad." En el marco real de triaje del equipo de soporte, es "urgente" porque esos 3 usuarios están en un plan empresarial con un SLA que activa penalidades financieras después de 2 horas.

El pipeline procesó los datos perfectamente. Solo procesó datos con las etiquetas incorrectas.

Donde el código no puede ayudar

Hay categorías específicas de problemas de calidad de datos que ninguna solución de ingeniería puede abordar:

Criterios de etiquetado incorrectos. Si la definición de "positivo" y "negativo" en tu esquema de clasificación no coincide con el límite de decisión del mundo real, cada etiqueta es potencialmente incorrecta — pero ninguna regla de validación puede detectar esto. Las etiquetas son internamente consistentes, correctamente formateadas y estadísticamente distribuidas. Simplemente están equivocadas.

Un ejemplo concreto: un equipo de imágenes médicas etiqueta radiografías de tórax para detección de neumonía. Su guía de etiquetado dice "etiquetar como positivo si hay opacidad presente en los campos pulmonares." Un radiólogo les diría que el 15-20% de las opacidades en los campos pulmonares no son neumonía — son atelectasia, derrames o artefactos. Las etiquetas pasan todas las verificaciones de calidad. El modelo aprende a detectar opacidad, no neumonía.

Decisiones de deduplicación incorrectas. Los algoritmos de deduplicación pueden identificar que dos registros son similares. No pueden determinar cuál es correcto. Cuando un cliente aparece dos veces en un dataset con direcciones ligeramente diferentes, el algoritmo puede señalar el duplicado. No puede saber que una dirección es el hogar del cliente y la otra su oficina, y la dirección correcta depende del caso de uso.

Trabajamos con un equipo de servicios financieros que usó deduplicación automatizada en registros de transacciones. El algoritmo fusionó registros con montos idénticos y marcas de tiempo similares, tratándolos como duplicados. En realidad, el 8% de los "duplicados" eran transacciones separadas legítimas — dos transferencias bancarias de $4,500 al mismo destinatario el mismo día por facturas diferentes. La deduplicación redujo el tamaño del dataset pero también redujo la precisión del modelo al eliminar datos reales.

Semántica de datos malinterpretada. Un campo etiquetado "fecha_completado" podría significar cosas diferentes en distintos contextos: la fecha en que la tarea fue marcada como completa en el sistema, la fecha en que el trabajo realmente se terminó, o la fecha en que la finalización fue verificada por un supervisor. Usar la interpretación incorrecta introduce error sistemático que ninguna regla de validación puede detectar porque el tipo de dato y formato son correctos.

Estándares de calidad dependientes del contexto. En algunos dominios, la calidad de datos "suficientemente buena" depende de la aplicación específica. Un nombre de cliente mal escrito como "Jonh" en vez de "John" es aceptable para un sistema de recomendaciones pero inaceptable para un modelo de verificación de cumplimiento que compara nombres contra listas de sanciones. La puntuación de calidad que no considera el contexto de aplicación produce confianza engañosa.

El conocimiento de dominio que importa

Las decisiones de calidad de datos requieren tres tipos de conocimiento de dominio que el código no tiene:

Conocimiento semántico. Entender qué significan los valores de datos en contexto. Un ingeniero de ML ve un campo con valores 0-10 y lo trata como una característica numérica continua. Un experto del dominio sabe que los valores 1-3 son "normales," 4-6 son "elevados" y 7-10 son "críticos" — y que los umbrales entre categorías son donde las decisiones del modelo más importan.

Conocimiento operacional. Entender cómo se recolectaron los datos y cuáles son sus limitaciones. Un experto del dominio sabe que las entradas de fin de semana en un registro de manufactura son menos confiables porque el operador junior las llena de memoria el lunes. Un ingeniero de ML trata todas las filas por igual.

Conocimiento de consecuencias. Entender qué pasa cuando el modelo se equivoca. Un experto del dominio sabe que clasificar erróneamente cierto tipo de transacción tiene implicaciones regulatorias, mientras que clasificar erróneamente otro tipo es simplemente inconveniente. Este conocimiento debería influir en qué tan agresivamente limpias, validas y balanceas diferentes segmentos del dataset.

El proceso real de calidad

La calidad de datos efectiva no es un pipeline de código con conocimiento de dominio espolvoreado encima. Es un proceso impulsado por el dominio con código apoyando la ejecución.

Paso 1: Los expertos del dominio definen los criterios de calidad. Antes de que se ejecute cualquier código, los expertos del dominio especifican qué significa "correcto" para cada etiqueta, qué casos extremos existen y cómo deben manejarse los ejemplos ambiguos. Esto no es una reunión de una hora. Es un proceso iterativo que típicamente toma 1-2 semanas de discusión, revisión de ejemplos y refinamiento de criterios.

Paso 2: Los expertos del dominio etiquetan un dataset semilla. Un pequeño conjunto de ejemplos (200-500) etiquetados por expertos del dominio establece la verdad fundamental. Este dataset semilla sirve como el benchmark de calidad contra el cual todas las etiquetas y salidas del modelo posteriores se miden.

Paso 3: Las métricas de calidad referencian el juicio del dominio. El acuerdo entre anotadores, el análisis de distribución de etiquetas y la revisión de casos extremos se miden contra las etiquetas semilla de los expertos del dominio. Si las verificaciones automatizadas de calidad señalan un lote de etiquetas como problemático, los expertos del dominio — no los ingenieros de ML — investigan y determinan si el problema es un error de etiquetado o un cambio legítimo de distribución.

Paso 4: Los expertos del dominio revisan los errores del modelo. Cuando el modelo clasifica mal los ejemplos, los expertos del dominio examinan las clasificaciones incorrectas para determinar si el error proviene de datos de entrenamiento insuficientes, etiquetas incorrectas, criterios ambiguos o un caso extremo genuino que no se debería esperar que el modelo maneje.

Este proceso requiere que los expertos del dominio interactúen directamente con los datos y las herramientas de etiquetado. Si los expertos del dominio solo pueden participar a través de reuniones y mensajes de Slack, el proceso se degrada de vuelta al etiquetado por proxy — que es donde se originan los problemas de calidad.

El costo de equivocarse en esto

Las organizaciones que tratan la calidad de datos como un problema de ingeniería gastan 2-3x más en desarrollo de modelos que las organizaciones que lo tratan como un problema de dominio. He aquí por qué:

Más ciclos de entrenamiento. Cuando las etiquetas son sutilmente incorrectas, la precisión del modelo se estanca en un nivel que parece mejorable pero resiste cada intervención de ingeniería — más datos, mejores arquitecturas, entrenamiento más largo. El equipo itera durante semanas o meses antes de que alguien finalmente cuestione las etiquetas.

Despliegue retrasado. Un modelo entrenado con datos incorrectos para el dominio falla de manera diferente que un modelo entrenado con datos ruidosos. Los datos ruidosos producen rendimiento uniformemente degradado. Los datos incorrectos para el dominio producen errores seguros en categorías específicas — el modelo está seguro de los casos en que se equivoca. Estos errores seguros se descubren tarde, frecuentemente durante las pruebas de aceptación del usuario, y requieren reiniciar el proceso de recolección de datos.

Confianza erosionada. Cuando un modelo clasifica erróneamente con confianza casos específicos del dominio, los expertos del dominio pierden confianza en las herramientas de IA en general. Reconstruir esa confianza cuesta más que hacerlo bien la primera vez.

La investigación del trabajo de IA centrada en datos de Andrew Ng muestra que las correcciones sistemáticas de etiquetas por expertos del dominio mejoran el rendimiento del modelo entre 5-15% en promedio — más que la mayoría de los cambios arquitecturales. Los datos, no el modelo, son donde vive la calidad.

Poniendo a los expertos del dominio en el asiento del conductor

La calidad de datos mejora cuando los expertos del dominio pueden inspeccionar, etiquetar, validar y corregir datos de entrenamiento directamente. Esto requiere herramientas que sean accesibles para personas sin habilidades de ingeniería de ML.

Ertas Data Suite está construido para este propósito. Es una aplicación de escritorio nativa donde los expertos del dominio trabajan con datos directamente — definiendo esquemas de etiquetas, aplicando etiquetas, revisando métricas de calidad y corrigiendo errores — sin escribir código ni navegar infraestructura técnica. Los datos permanecen locales en su máquina. La interfaz usa terminología del dominio, no jerga de ML.

El equipo de ML obtiene mejores datos. Los expertos del dominio mantienen la propiedad de la calidad. El modelo se entrena con etiquetas que reflejan conocimiento genuino del dominio, no la mejor suposición de un ingeniero.

La calidad de datos es un problema de dominio. Las herramientas deberían dejar que los expertos del dominio lo resuelvan.