La calificación de datos es fundamental
Wikipedia enumera siete pasos para un proceso de análisis de datos: requisitos 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 pronostica inventario, optimiza precios o cada vez que abordamos alguna optimización de comercio, nuestro proceso es muy similar al descrito anteriormente. Sin embargo, hay otro paso vital que generalmente representa más de la mitad de todo el esfuerzo aplicado por el equipo de Lokad 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 común de fracaso en proyectos, justo después de objetivos comerciales poco claros o poco sabios, lo cual ocurre cada vez que una iniciativa comienza desde la “solución” en lugar de comenzar desde el “problema”. Vamos a arrojar luz sobre este misterioso paso de “calificación de datos”.
Datos como subproducto de aplicaciones empresariales
La gran mayoría del software empresarial está diseñado para ayudar a operar empresas: el sistema de punto de venta está ahí para permitir que los clientes paguen; el Sistema de Gestión de Almacenes está ahí para recoger y almacenar productos; el software de conferencia web permite a las personas llevar a cabo sus reuniones en línea, etc. Este tipo de software también puede estar produciendo 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 una mejor operación o mejores datos, siempre se favorecerán las mejores operaciones. Por ejemplo, si un código de barras falla al escanearse en el punto de venta de su hipermercado local, el cajero invariablemente elegirá un producto que tenga el mismo precio y lo escaneará dos veces; a veces incluso tienen una hoja de trucos con todos los códigos de barras recopilados en un papel. El cajero tiene razón: la prioridad número uno es permitir que el cliente pague sin importar qué. Generar registros de stock precisos no es una meta inmediata en comparación con la necesidad urgente de atender a una fila de clientes.
Se podría argumentar que el problema del escaneo de códigos de barras es en realidad un problema de limpieza de datos. Sin embargo, la situación es bastante sutil: los registros siguen siendo precisos hasta cierto punto, ya que la cantidad cobrada al cliente sigue siendo correcta y también lo es el recuento de artículos en la cesta. Filtrar ingenuamente todos los registros sospechosos haría más daño que bien para la mayoría de los análisis.
Sin embargo, observamos que con demasiada frecuencia, las empresas, y también sus proveedores de software, ignoran entusiastamente este patrón fundamental para casi todos los datos empresariales que se generan, pasando 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 aclarar y documentar a fondo la semántica de los datos. La mayoría de las veces, cuando las empresas (grandes) envían archivos de datos tabulares a Lokad, también nos envían una hoja de Excel, donde cada columna encontrada en los archivos recibe una breve línea de documentación, típicamente como: Precio: el precio del producto. Sin embargo, una breve línea de documentación deja una miríada de preguntas abiertas:
- ¿cuál es la moneda aplicable para el producto?
- ¿es un precio con o sin impuestos?
- ¿hay alguna otra variable (como un descuento) que afecte el precio real?
- ¿es realmente el mismo precio para el producto en todos los canales?
- ¿se supone que el valor del precio tiene sentido para productos que aún no se han vendido?
- ¿hay situaciones especiales como ceros para reflejar valores faltantes?
Las fechas también son excelentes candidatas para ambigüedades semánticas cuando una tabla de pedidos contiene una columna de fecha, el tiempo de fecha puede referirse a:
- la validación de la cesta
- la entrada de pago
- la autorización de pago
- la creación del pedido en el sistema contable
- el despacho
- la entrega
- el cierre del pedido
Sin embargo, esta lista corta apenas cubre las peculiaridades reales encontradas en situaciones de la vida real. Recientemente, por ejemplo, mientras trabajábamos para uno de los mayores negocios en línea de Europa, 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 utilizando camiones y la fecha reflejaba la llegada al almacén; mientras que los proveedores asiáticos enviaban utilizando, bueno, barcos, y la fecha reflejaba la llegada al puerto. Este pequeño “giro” típicamente representaba más de 10 días de diferencia en el cálculo del tiempo de entrega.
Para conjuntos de datos relacionados con negocios, la semántica de los datos casi siempre depende de los procesos y prácticas de la empresa subyacente. La documentación relacionada con dichos procesos, cuando existe, generalmente se centra en lo que interesa a la dirección o a los auditores, pero rara vez en la multitud de pequeños elementos que existen dentro del panorama informático de la empresa. Sin embargo, el diablo está en los detalles.
La cualificación de datos no es limpieza de datos
La limpieza de datos tiene más sentido en las ciencias experimentales, donde ciertos puntos de datos (valores atípicos) deben eliminarse porque distorsionarían 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 generalmente se necesita al analizar datos comerciales. Los valores atípicos pueden encontrarse al tratar con los restos de una recuperación de base de datos fallida, pero en su mayoría, los valores atípicos son marginales. La integridad (en términos comerciales) 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 al prevenir las más frecuentes y también son bastante útiles cuando se trata de corregirlas posteriormente. Sin embargo, la cualificació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 los datos en su conjunto, para que el análisis posterior realmente tenga sentido. Lo único que se “altera” mediante el proceso de cualificación de datos es la documentación original de los datos.
La cualificación de datos es la mayor parte del esfuerzo
Mientras trabajamos en docenas de proyectos basados en datos relacionados con el comercio, la aeroespacial, la hostelería, la bioinformática, la energía, hemos observado que la cualificación de datos siempre ha sido el paso más exigente del proyecto. Los algoritmos de aprendizaje automático pueden parecer sofisticados, pero siempre que la iniciativa se mantenga dentro de los límites conocidos de problemas de regresión o clasificación, el éxito en el aprendizaje automático es principalmente una cuestión de conocimiento previo del dominio. Lo mismo ocurre con el procesamiento de Big Data.
Los problemas de cualificación de datos son insidiosos porque no sabes lo que te estás perdiendo: 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 su lugar, y la semántica “real” tal como es percibida por las personas que llevan a cabo 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 TI subestiman en gran medida la profundidad de las particularidades 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 tienen una línea completa de documentación por campo de tabla. Sin embargo, típicamente encontramos que incluso con media página de documentación por campo, la documentación está lejos de ser exhaustiva.
Uno de los (muchos) desafíos a los que se enfrenta Lokad es que es difícil cobrar por algo que ni siquiera se percibe como una necesidad en primer lugar. Por lo tanto, con frecuencia asignamos el trabajo de cualificación de datos bajo la apariencia de tareas más nobles como “ajuste de algoritmos estadísticos” u otras tareas que suenan científicas.
Sin embargo, la realidad del trabajo es que la cualificación de datos no solo es intensiva desde una perspectiva de mano de obra, sino que también es una tarea verdaderamente desafiante en sí misma. Es una mezcla entre comprender el negocio, comprender cómo se distribuyen los procesos en muchos sistemas, algunos de ellos inevitablemente de tipo heredado, y cerrar la brecha entre los datos tal como salen y las expectativas del flujo de trabajo de aprendizaje automático.
La mayoría de las empresas invierten muy poco en la cualificación de datos. Además de ser un desafío subestimado, invertir talento en la cualificación de datos no resulta en una demostración llamativa ni siquiera en números reales. Como resultado, las empresas se apresuran a las etapas posteriores del proceso de análisis de datos solo para encontrarse nadando en melaza porque nada funciona realmente como se esperaba. No hay una solución rápida para comprender realmente los datos.
