Un score vale lo que vale el dato que tiene debajo
Enunciado de forma cualitativa. No hicimos un estudio medido de antes y después, así que no se afirma ningún porcentaje.
Contexto
Qué Compro es un producto de consumo que puntúa alimentos de supermercado. Tiene un catálogo de alrededor de seis mil productos, un modelo de score, una API, una app Android y un cliente web, construidos y operados por BoRo.
Restricción operacional
Los datos nutricionales del mismo producto no coinciden entre fuentes, y un modelo de score entrega sin problema un número seguro encima de un valor equivocado. La restricción no era construir la app. Era que nadie podía decir a qué cifra creerle, y un error silencioso de parseo es indistinguible de una diferencia nutricional real una vez que está en la base de datos.
Arquitectura
- Una jerarquía de evidencia explícita: un valor leído de la etiqueta física manda sobre uno obtenido del sitio de un retailer, y el motivo de cada decisión queda registrado junto al producto.
- La calidad del dato como estado de primera clase, no como tarea de limpieza. Un producto puede quedar en DATA_CONFLICT o DATA_INVALID, y el sistema distingue entre un valor que tiene, uno del que desconfía y uno que no tiene.
- Un modelo de score que se niega a puntuar lo que el dato no sostiene, así la cobertura se reporta con honestidad en vez de rellenarse.
- Un paquete de dominio compartido que usan la API, la app móvil y el cliente web, para que el catálogo, el score y la identidad del producto signifiquen lo mismo en los tres.
Implementación
- API, app Android y cliente web sobre un paquete de dominio compartido, con contrato OpenAPI y restricciones de base de datos escritas junto al modelo de datos.
- Reconciliación de conflictos entre fuentes contra la evidencia de la etiqueta, producto por producto, dejando visibles los casos residuales en vez de resolverlos en silencio.
- Reparación de fallas de parseo que habían escrito valores nutricionales silenciosamente erróneos, cada una con un archivo de auditoría que muestra qué cambió y por qué.
- Una cola de recrawl dirigido para volver a traer exactamente los productos con dato sospechoso, en vez de recrawlear todo.
- Calibración del modelo de score contra revisión humana, con comparaciones por pares y un registro explícito de dónde se esperaba que el modelo y la revisora discreparan.
Resultado observado
- Los conflictos entre fuentes se resuelven por una regla enunciada y evidencia registrada, no por cuál fuente se leyó al final.
- Los productos que el dato no sostiene quedan visiblemente sin puntuar, en vez de cargar un número seguro.
- Las fallas de parseo que antes eran invisibles ahora dejan rastro de auditoría, así que ese tipo de error se puede detectar en lugar de redescubrir.
- El catálogo, el score y la identidad del producto tienen una sola definición compartida por la API, la app y el cliente web.
Enunciado de forma cualitativa. No hicimos un estudio medido de antes y después, así que no se afirma ningún porcentaje.