/ Proyectos / Negocios / Sesgo entre árbitros de minerales
Detección de sesgo entre árbitros de análisis de minerales, con diseño de problema y backtesting
Antes de preguntar qué modelo usar, había que resolver una pregunta más difícil, cómo distinguir un error aleatorio de una tendencia sistemática con los datos que ya existían.
En la compraventa de concentrados minerales, el vendedor y el comprador hacen cada uno su propio análisis de laboratorio para determinar cuánto mineral de valor contiene el embarque. Cuando esos dos análisis se acercan, se suele usar el promedio. Cuando se alejan demasiado, entra un árbitro, un laboratorio independiente, cuyo resultado se vuelve la referencia final para liquidar el contrato.
La empresa que encargó este proyecto trabaja con varios árbitros distintos, y quería responder una pregunta incómoda de hacer en voz alta pero muy razonable de investigar en privado. ¿Alguno de estos árbitros tiende, de forma consistente, a favorecer a una de las partes? Y si es así, ¿es identificable con los datos que ya se tienen, o solo es ruido estadístico disfrazado de patrón?
Mapa del casoContenido
- Diagrama de la solución. De la transacción con arbitraje a la decisión comercial
- Construcción de la solución. Diseñar la pregunta antes de entrenar el modelo
- Condiciones del proyecto. Qué datos existían realmente, y qué no
- Pasos. De la prueba de hipótesis al backtesting
- Proceso de iteración. Un resultado incómodo, documentado sin maquillaje
- Descargables. Notebook y repositorio del proyecto
- Lecciones importantes. Por qué el encuadre del problema importó más que el modelo
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
Las pruebas de hipótesis ocurren antes que cualquier modelo. Son las que responden si vale la pena seguir investigando un árbitro, o si la diferencia observada es simple variación estadística.
De la pregunta de negocio al modeloConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Datos disponibles | Solo el resultado final de vendedor, comprador y árbitro, sin etiqueta de "sesgo intencional" |
| Elementos de interés | Cobre, oro, plata y arsénico, que concentran la mayoría de los contratos |
| Cobertura útil tras filtrar | Alrededor del 10% de los registros originales correspondía a casos con arbitraje real y datos completos |
| Prioridad del negocio | Una decisión defendible sobre con qué árbitros trabajar, no solo un modelo con buena métrica |
| Opción | Por qué se descartó |
|---|---|
| Comparar promedios de diferencia por árbitro y sacar conclusiones directas | Una diferencia promedio distinta de cero puede deberse a variación aleatoria, no a un patrón real, sin una prueba estadística de por medio |
| Entrenar un solo modelo global para todos los árbitros | El comportamiento de cada árbitro puede depender de variables específicas de sus contratos, y mezclar todo diluye esa señal |
| Validar con pruebas de hipótesis antes de modelar, comparar dos enfoques de modelado, y respaldar todo con backtesting contra los métodos ya usados en la práctica | Da evidencia estadística de que el patrón es real antes de construir cualquier modelo, y demuestra con datos que el modelo mejora lo que ya se hacía |
Pasos
El diseño del problema, antes que el modelo
Ningún dato decía "este árbitro está sesgado". Lo único disponible eran tres números por transacción: el análisis del vendedor, el del comprador, y el del árbitro. La pregunta de negocio, saber si un árbitro favorece sistemáticamente a alguna de las partes, tuvo que traducirse en una pregunta estadística contestable con esos tres números, comparar la diferencia entre el árbitro y el vendedor contra una hipótesis de media cero. Esto es lo que muchas veces se subestima en proyectos de datos, no siempre se trata de meter información a un modelo y esperar una predicción, a veces la parte más difícil es encuadrar la pregunta de forma que los datos que ya tienes puedan responderla.
Probar si la diferencia es azar o tendencia, antes de modelar
Agente: propuso calcular directamente el promedio de diferencia por árbitro y ordenar de mayor a menor.
Criterio aplicado: aplicar una prueba de hipótesis de media cero sobre esa diferencia, tanto a nivel agregado como por cliente, para distinguir con evidencia estadística una tendencia sistemática de una variación explicable por azar.
Comparar dos formas de organizar los modelos predictivos
Agente: sugirió entrenar un único modelo global con todos los árbitros mezclados.
Criterio aplicado: comparar dos enfoques, un modelo por árbitro y un modelo por elemento químico, evaluando siete algoritmos distintos en cada caso para decidir cuál organización captura mejor el comportamiento real de los datos.
Reformular el problema como clasificación, no solo como regresión
Agente: propuso quedarse únicamente con la predicción numérica del resultado del árbitro.
Criterio aplicado: agregar un modelo de clasificación binaria que predice directamente a quién favorece el resultado final, comprador o vendedor, porque para la decisión de negocio esa pregunta puede importar más que el valor exacto predicho.
Validar con backtesting contra lo que ya se usaba
Agente: propuso reportar solo las métricas del modelo entrenado, sin comparación externa.
Criterio aplicado: comparar el error del modelo contra dos métodos simples ya usados en la práctica, el promedio histórico de diferencia, y una elección al azar entre comprador y vendedor, para demostrar con evidencia que el modelo aporta valor real sobre lo existente.
Proceso de iteración
Ajuste documentado, no forzado
Tras filtrar el conjunto de datos para quedarse solo con los casos realmente útiles, casos con arbitraje, con los cuatro elementos de interés, y con análisis independiente de ambas partes, el conjunto útil se redujo a aproximadamente una décima parte del original. Es una reducción considerable, y hay que ser honestos al respecto, un modelo entrenado sobre el 10% de los datos disponibles no tiene la misma robustez que uno entrenado sobre el conjunto completo. Filtrar así era necesario para responder la pregunta correctamente, pero significa que las conclusiones sobre árbitros con pocos casos de arbitraje en ese subconjunto deben tomarse con más cautela que las de árbitros con mayor volumen.
CierreLecciones importantes
El bosque aleatorio terminó siendo el modelo más consistente, y superó de forma clara a los dos métodos que la empresa ya usaba en la práctica. Pero ese resultado no es la lección más importante de este proyecto.
La lección real es que meter datos en un modelo y esperar una predicción no es lo mismo que resolver un problema de negocio. Aquí la parte difícil no fue entrenar el bosque aleatorio, fue decidir qué pregunta estadística exacta había que contestar con los datos disponibles, y qué comparación había que hacer para que el resultado sirviera para decidir algo, no solo para describir algo. Cualquier proyecto de datos con una pregunta de negocio genuina se beneficia de dedicarle tiempo real a esta etapa, antes de tocar cualquier algoritmo.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato