La calificación de datos es crítica
Wikipedia enumera siete pasos para un proceso de data analysis: requerimientos de datos, recolección de datos, procesamiento de datos, limpieza de datos, análisis exploratorio de datos, modelado de datos, y finalmente la generación de resultados de producción. Cuando Lokad forecast inventory, optimizes prices, o cada vez que abordamos algún tipo de optimización de comercio, nuestro proceso es muy similar al descrito anteriormente. Sin embargo, existe otro paso vital que típicamente representa más de la mitad de todo el esfuerzo que el equipo de Lokad suele aplicar y que ni siquiera forma parte de la lista anterior. Este paso es la calificación de datos.
Ahora que “Big Data” se ha convertido en una palabra de moda, innumerables empresas están tratando de hacer más con sus datos. La calificación de datos es probablemente la segunda causa más grande de fallos de proyectos, justo después de objetivos de negocio poco claros o imprudentes, lo que sucede cada vez que una iniciativa parte de la “solución” en lugar de partir del “problema”. Aportemos algo de luz sobre este misterioso paso de “calificación de datos”.
Datos como subproducto de las aplicaciones empresariales
La gran mayoría del software empresarial está diseñado para ayudar a operar las empresas: el sistema de Punto-Of-Sale está allí para permitir que los clientes paguen; el Sistema de Gestión de Warehouse está allí para recoger y almacenar productos; el software de Web Conferencing permite a las personas realizar sus reuniones en línea, etc. Dicho software también podría generar datos, pero los datos son solo un subproducto secundario del propósito principal de este software.
Los sistemas mencionados están diseñados para operar el negocio, y como resultado, siempre que un profesional tenga que elegir entre mejores operaciones o mejores datos, siempre se favorecerán las mejores operaciones. Por ejemplo, si un código de barras falla al ser escaneado en el punto de venta de tu hipermercado local, el cajero invariablemente elegirá un producto que tenga el mismo precio y lo escaneará dos veces; a veces incluso tienen una hoja con códigos de barras todos reunidos en un papel. El cajero tiene razón: la prioridad número uno es permitir que el cliente pague, pase lo que pase. Generar registros precisos de stock no es un objetivo inmediato en comparación con la urgente necesidad de atender a una fila de clientes.
Se podría argumentar que el problema del escaneo del código de barras es, en realidad, un problema de limpieza de datos. Sin embargo, la situación es bastante sutil: los registros se mantienen precisos hasta cierto punto, ya que el monto cargado al cliente permanece correcto y también lo hace el recuento de artículos en la cesta. Filtrar ingenuamente todos los registros sospechosos podría hacer más daño que beneficio en la mayoría de los análisis.
Sin embargo, observamos que con demasiada frecuencia, las empresas – y también sus software vendors – ignoran con entusiasmo este patrón fundamental para casi todos los datos empresariales que se generan, saltándose directamente del procesamiento de datos a la limpieza de datos.
La calificación de datos se relaciona con la semántica de los datos
El objetivo del paso de calificación de datos es clarificar y documentar a fondo la semántica de los datos. La mayoría de las veces, cuando las empresas (grandes) nos envían archivos de datos tabulares, también nos envían una hoja de Excel en la que cada columna de los archivos recibe una breve línea de documentación, típicamente como: Precio: el precio del producto. Sin embargo, tan breve línea de documentación deja abiertas innumerables preguntas:
- ¿cuál es la moneda aplicable para el producto?
- ¿es un precio con o sin impuestos?
- ¿existe alguna otra variable (como un descuento) que impacte el precio real?
- ¿es realmente el mismo precio para el producto a través de todos los canales?
- ¿se supone que el valor del precio debe tener sentido para productos que aún no se han vendido?
- ¿existen situaciones atípicas, como ceros, para reflejar valores faltantes?
Las fechas también son excelentes candidatas para ambigüedades semánticas cuando una tabla orders contiene una columna date, ya que la fecha y hora puede referirse al momento de:
- la validación de la cesta
- el registro del pago
- la compensación del pago
- la creación del pedido en el paquete de contabilidad
- el despacho
- la entrega
- el cierre del pedido
Sin embargo, esta lista corta difícilmente abarca las extrañas particularidades que se encuentran en situaciones reales. Recientemente, por ejemplo, mientras trabajábamos para uno de los mayores negocios online europeos, nos dimos cuenta de que las fechas asociadas con las órdenes de compra no tenían el mismo significado dependiendo del país de origen de las fábricas proveedoras. Los proveedores europeos enviaban mercancía usando camiones y la fecha reflejaba la llegada al almacén; mientras que los proveedores asiáticos enviaban, bueno, en barcos, y la fecha reflejaba la llegada al puerto. Este pequeño giro típicamente representaba una diferencia de más de 10 días en el cálculo del lead time.
Para los conjuntos de datos relacionados con el negocio, la semántica de los datos depende casi siempre de los procesos y prácticas subyacentes de la empresa. La documentación relativa a dichos procesos, cuando existe, se enfoca típicamente en lo que interesa a la dirección o a los auditores, pero muy rara vez en la miríada de pequeños elementos que existen dentro del panorama IT de la empresa. Sin embargo, el diablo está en los detalles.
La calificación de datos no es limpieza de datos
La limpieza de datos (o depuración) tiene mayor sentido en las ciencias experimentales, donde ciertos puntos de datos (valores atípicos) deben eliminarse porque podrían distorsionar incorrectamente los experimentos. Por ejemplo, las mediciones de un gráfico en un experimento de óptica podrían simplemente reflejar un defecto en el sensor óptico en lugar de algo realmente relevante para el estudio.
Sin embargo, este proceso no refleja lo que típicamente se necesita al analizar datos empresariales. Se pueden encontrar valores atípicos al lidiar con los remanentes de una recuperación fallida de bases de datos, pero en su mayoría, los valores atípicos son marginales. La integridad (en términos empresariales) de la gran mayoría de las bases de datos actualmente en producción es excelente. Existen entradas erróneas, pero la mayoría de los sistemas modernos hacen un buen trabajo evitando los errores más frecuentes y son bastante útiles a la hora de corregirlos posteriormente. Sin embargo, la calificación de datos es muy diferente en el sentido de que el objetivo no es eliminar o corregir puntos de datos, sino arrojar luz sobre el conjunto de datos, de modo que el análisis subsecuente realmente tenga sentido. Lo único que se “altera” con el proceso de calificación de datos es la documentación original de los datos.
La calificación de datos representa la mayor parte del esfuerzo
Mientras trabajábamos con docenas de proyectos impulsados por datos relacionados con el comercio, la aeroespacial, la hostelería, la bioinformática y la energía, hemos observado que la calificación de datos siempre ha sido el paso más exigente del proyecto. Los algoritmos de Machine learning pueden parecer sofisticados, pero mientras la iniciativa se mantenga dentro de los conocidos límites de problemas de regresión o clasificación, el éxito en machine learning es en gran medida una cuestión de conocimiento previo del dominio. Lo mismo ocurre con el procesamiento de Big Data.
Los problemas de calificación de datos son insidiosos porque no sabes lo que te falta: esta es la brecha semántica entre la semántica “verdadera”, tal como debería entenderse en términos de los datos producidos por los sistemas en funcionamiento, y la semántica “real”, tal como la perciben las personas que realizan el análisis de datos. Lo que no sabes puede hacerte daño. A veces, la brecha semántica invalida por completo todo el análisis.
Observamos que la mayoría de los profesionales de IT subestiman enormemente la profundidad de las peculiaridades que acompañan a la mayoría de los conjuntos de datos empresariales de la vida real. La mayoría de las empresas ni siquiera cuentan con una línea completa de documentación por cada campo de una tabla. Sin embargo, típicamente encontramos que, incluso con media página de documentación por campo, ésta está lejos de ser exhaustiva.
Uno de los (muchos) desafíos que enfrenta Lokad es que resulta difícil cobrar por algo que ni siquiera se percibe como una necesidad en primer lugar. Por lo tanto, con frecuencia disimulamos el trabajo de calificación de datos bajo el disfraz de tareas más nobles como “ajuste de algoritmos estadísticos” o tareas similares con un aire científico.
La realidad del trabajo, sin embargo, es que la calificación de datos no solo es intensiva desde la perspectiva del personal, sino que también es una tarea verdaderamente desafiante en sí misma. Es una combinación de comprender el negocio, entender cómo los procesos se extienden a lo largo de muchos sistemas – algunos de ellos invariablemente del tipo legado – y cerrar la brecha entre los datos tal como salen y las expectativas del pipeline de machine learning.
La mayoría de las empresas invierte muy poco en la calificación de datos. Además de ser un desafío subestimado, invertir talento en la calificación de datos no resulta en una demo llamativa ni en cifras reales. Como resultado, las empresas se precipitan a las etapas posteriores del proceso de análisis de datos, solo para encontrarse nadando en melaza, porque nada funciona realmente como se espera. No existe una solución rápida para lograr una comprensión real de los datos.
