AI anomaly detection en eventos de trazabilidad: de la detección al yield optimization

TL;DR — “AI anomaly detection” suena a deep learning sofisticado. En la práctica, los modelos que mueven la aguja en producción de alimentos son simples, interpretables y están conectados directamente al proceso operativo. Contamos cómo en Darwin pasamos de “detectamos anomalías” a “optimizamos yield” — y por qué el gap entre los dos es más grande de lo que parece.

El problema: anomalías detectadas ≠ valor capturado

Muchas plataformas prometen “detectar anomalías en supply chain con AI”. El ML detecta outliers — fácil. Pero un outlier detectado no es valor hasta que:

El operador lo entiende (no es una caja negra que dice “anomalía”)
Llega a tiempo (alerta 4 horas después no sirve)
Se traduce en una acción concreta (no solo “dashboard con gráfico rojo”)
Se mide el impacto (¿cuánto ahorraste? ¿cuánto yield ganaste?)

La mayoría de proyectos se quedan en el paso 1 — detectan cosas, pero no se cierran el loop. En Darwin construimos el sistema end-to-end. Así es como.

Qué detectamos (y qué no)

✅ Anomalías que sí detectamos

Tipo	Ejemplo	Modelo
Desvíos de proceso	Temperatura de cadena de frío fuera de rango	Reglas + rolling statistics
Inconsistencias de lote	Peso declarado vs. peso real en despacho	Regresión simple por producto
Fraude potencial	Proveedor reportando más volumen que su capacidad productiva histórica	Isolation forest sobre features de proveedor
Calidad degradada	Retornos de cliente correlacionan con un lote específico	Correlación + análisis causal básico
Patrones temporales	Rendimiento baja sistemáticamente los lunes después de paradas	Seasonal decomposition

❌ Lo que NO hacemos (todavía)

Predicción de demanda — no es trazabilidad, no entramos ahí
Computer vision de producto — requiere hardware específico; fuera de alcance
Deep learning end-to-end — el overhead vs. valor no justifica en este dominio

Nuestra regla: modelo interpretable que el operador entiende > modelo complejo que es “mejor” en métricas. Si un cliente no puede explicarle a su auditor cómo se detectó la anomalía, no nos sirve.

El stack

Data pipeline:

Eventos CTE/KDE ingresando via Captia → Pub/Sub → PostgreSQL (raw) + data warehouse (features)
Feature engineering programado (cada N eventos o cada X minutos)

Models:

Python (scikit-learn, statsmodels) — modelos simples, interpretables
Prophet — para patterns temporales
Isolation Forest — para multivariate outliers en features de proveedor

Serving:

Modelos entrenados offline, scoring en tiempo real en un service dedicado
Scoring típico: <100ms por evento
Rule-based alerts on top (combinamos ML + reglas de negocio)

Delivery:

Alertas a operadores via WhatsApp + email + dashboard
Cada alerta incluye: qué se detectó, por qué, qué features contribuyeron, acción sugerida

Del outlier al yield: el paso que nadie cuenta

Acá está el trabajo real. Detectar un outlier es fácil. Convertirlo en valor para el cliente requiere:

1. Alertas accionables, no informativas

Malo:

“Anomalía detectada en lote #12345”

Bueno:

“Lote #12345 tiene peso 7% menor al esperado (basado en 200 lotes similares últimos 90 días). Posible causa: pérdida de humedad por ventilación excesiva. Revisá: compresor #3 (última mantención hace 6 meses) o puerta de cámara (cierre).”

La alerta incluye: qué, por qué, qué chequear primero. El operador actúa en minutos, no en horas.

2. Feedback loop con el operador

Cuando el operador resuelve una alerta, la app pregunta:

¿Era una anomalía real? (feedback al modelo)
¿Cuál fue la causa raíz?
¿Qué acción tomaste?

Esos labels se vuelven training data para la próxima iteración del modelo. Los modelos aprenden de las decisiones humanas, no solo de la data histórica.

3. Métricas de negocio, no solo de ML

Los dashboards que enseñamos al cliente NO muestran “precision: 0.94 / recall: 0.87”. Muestran:

Yield preservado — toneladas recuperadas porque la alerta llegó a tiempo
Tiempo de respuesta mejorado — de X horas a Y minutos
Recalls evitados — incidentes que se detectaron antes de llegar al consumidor

Esos son los números que hacen que el cliente renueve el contrato, no la matriz de confusión.

4. Causal analysis, no solo correlation

Detectar que “el yield baja los lunes” es fácil. Lo útil es: por qué.

Combinamos:

Event sequence analysis — qué eventos preceden al drop de yield
Operator feedback — el conocimiento local del planta manager
LLM-assisted root cause — el LLM propone hipótesis que el experto confirma

Resultado: no solo alertamos, explicamos patrones. Eso transforma “detección” en “optimización”.

Un caso real: pérdida de yield en procesamiento de frutas

Un cliente notaba que el rendimiento de procesamiento (kg materia prima → kg producto final) bajaba sin explicación clara. Varía entre 72% y 78%, sin patrón obvio.

Con Captia + Tracium ya teníamos todos los eventos detallados. Aplicamos:

Feature engineering — temperatura ambiente, proveedor, lote de origen, turno, operador, tiempo entre cosecha y procesamiento
Modelo de regresión simple — predice yield esperado dado features conocidos
Analysis de residuos — casos donde yield real difiere >3% del esperado

Hallazgo: el tiempo entre cosecha y procesamiento era el predictor más fuerte. Lotes que entraban a procesamiento >48hs después de cosecha tenían yield 5-8% más bajo.

Acción del cliente: reorganizaron el flujo logístico para priorizar lotes más viejos. En 3 meses:

Yield promedio +3.2% → $180k/año en ahorro para esta sola planta
Alertas accionables cuando un lote pasa el threshold de “riesgo”
Mejor negociación con proveedores — data para exigir entregas más rápidas

Este no es deep learning sofisticado. Es regresión + feature engineering + distribución disciplinada de la alerta. El valor está en cerrar el loop, no en la complejidad del modelo.

Lo que no funcionó

V0: deep learning end-to-end — probamos LSTMs sobre series temporales de eventos. Precisión parecida a regresión simple, pero no interpretable. Los operadores no confiaban en alertas que no podían explicar. Abandonamos.

Dashboards como principal canal — muchas anomalías quedaban en el dashboard sin acción. Migramos a push notifications (WhatsApp) con call-to-action explícita.

Modelos globales por industria — un modelo para “todas las frutas” daba peor precisión que modelos específicos por producto-planta-proveedor. Ahora entrenamos específicos y damos versioning claro.

Lessons learned

El gap entre detección y valor es el 80% del proyecto — no el modelo
Interpretabilidad > precisión en dominios con operadores humanos
Feedback loop desde el día 0 — sin labels de operadores, el modelo se estanca
Métricas de negocio, no de ML en los reportes al cliente
Simples modelos + domain knowledge > complex modelos sin contexto

¿Y ahora?

Estamos explorando causal AI con herramientas como DoWhy — no solo detectar correlations sino inferir causalidad real de eventos. Combinado con LLMs para formular hipótesis, puede acelerar mucho el root cause analysis.

Si estás construyendo anomaly detection en supply chain y tu modelo detecta bien pero nadie actúa sobre las alertas, el problema no es tu modelo — es el loop de acción. Empezá por ahí.

¿Tenés un problema de yield, waste o pérdida de calidad en producción? Hablemos — podemos mostrarte casos reales con impacto medible.