AI anomaly detection em eventos de rastreabilidade: da detecção ao yield optimization

TL;DR — “AI anomaly detection” soa como deep learning sofisticado. Na prática, os modelos que mexem o ponteiro em produção de alimentos são simples, interpretáveis e conectados diretamente ao processo operacional. Contamos como na Darwin passamos de “detectamos anomalias” para “otimizamos yield” — e por que o gap entre os dois é maior do que parece.

O problema: anomalias detectadas ≠ valor capturado

Muitas plataformas prometem “detectar anomalias em supply chain com AI”. O ML detecta outliers — fácil. Mas um outlier detectado não é valor até que:

1. O operador o compreende (não é uma caixa preta dizendo “anomalia”)
2. Chega a tempo (alerta 4 horas depois não serve)
3. Se traduz em ação concreta (não só “dashboard com gráfico vermelho”)
4. O impacto é medido (quanto você economizou? quanto yield ganhou?)

A maioria dos projetos fica no passo 1 — detectam coisas, mas não fecham o loop. Na Darwin construímos o sistema end-to-end. É assim.

O que detectamos (e o que não)

✅ Anomalias que detectamos

❌ O que NÃO fazemos (ainda)

• Previsão de demanda — não é rastreabilidade, não entramos aí
• Computer vision de produto — requer hardware específico; fora de escopo
• Deep learning end-to-end — o overhead vs. valor não justifica neste domínio

Nossa regra: modelo interpretável que o operador entende > modelo complexo que é “melhor” em métricas. Se um cliente não consegue explicar ao auditor como a anomalia foi detectada, não nos serve.

O stack

Data pipeline:

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

Models:

• Python (scikit-learn, statsmodels) — modelos simples, interpretáveis
• Prophet — para patterns temporais
• Isolation Forest — para outliers multivariados em features de fornecedor

Serving:

• Modelos treinados offline, scoring em tempo real em um service dedicado
• Scoring típico: <100ms por evento
• Rule-based alerts em cima (combinamos ML + regras de negócio)

Delivery:

• Alertas aos operadores via WhatsApp + email + dashboard
• Cada alerta inclui: o que foi detectado, por quê, quais features contribuíram, ação sugerida

Do outlier ao yield: o passo que ninguém conta

Aqui está o trabalho real. Detectar um outlier é fácil. Convertê-lo em valor para o cliente requer:

1. Alertas acionáveis, não informativos

Ruim:

“Anomalia detectada no lote #12345”

Bom:

“Lote #12345 tem peso 7% menor que o esperado (baseado em 200 lotes similares nos últimos 90 dias). Causa possível: perda de umidade por ventilação excessiva. Verifique: compressor #3 (última manutenção há 6 meses) ou porta da câmara (fechamento).”

O alerta inclui: o quê, por quê, o que checar primeiro. O operador age em minutos, não horas.

2. Feedback loop com o operador

Quando o operador resolve um alerta, o app pergunta:

• Era uma anomalia real? (feedback ao modelo)
• Qual foi a causa raiz?
• Que ação você tomou?

Esses labels viram training data para a próxima iteração do modelo. Os modelos aprendem com as decisões humanas, não só com os dados históricos.

3. Métricas de negócio, não só de ML

Os dashboards que mostramos ao cliente NÃO mostram “precision: 0.94 / recall: 0.87”. Mostram:

• Yield preservado — toneladas recuperadas porque o alerta chegou a tempo
• Tempo de resposta melhorado — de X horas para Y minutos
• Recalls evitados — incidentes detectados antes de chegar ao consumidor

Esses são os números que fazem o cliente renovar o contrato, não a matriz de confusão.

4. Causal analysis, não só correlation

Detectar que “o yield cai às segundas” é fácil. O útil é: por quê.

Combinamos:

• Event sequence analysis — quais eventos precedem o drop de yield
• Operator feedback — o conhecimento local do plant manager
• LLM-assisted root cause — o LLM propõe hipóteses que o expert confirma

Resultado: não só alertamos, explicamos patterns. Isso transforma “detecção” em “otimização”.

Um caso real: perda de yield em processamento de frutas

Um cliente notava que o rendimento de processamento (kg matéria-prima → kg produto final) caía sem explicação clara. Varia entre 72% e 78%, sem pattern óbvio.

Com Captia + Tracium já tínhamos todos os eventos detalhados. Aplicamos:

1. Feature engineering — temperatura ambiente, fornecedor, lote de origem, turno, operador, tempo entre colheita e processamento
2. Modelo de regressão simples — prevê yield esperado dado features conhecidas
3. Analysis de resíduos — casos onde yield real difere >3% do esperado

Achado: o tempo entre colheita e processamento era o preditor mais forte. Lotes que entravam em processamento >48h após colheita tinham yield 5-8% mais baixo.

Ação do cliente: reorganizaram o fluxo logístico para priorizar lotes mais velhos. Em 3 meses:

• Yield médio +3,2% → US$ 180k/ano em economia para esta única planta
• Alertas acionáveis quando um lote passa o threshold de “risco”
• Melhor negociação com fornecedores — dados para exigir entregas mais rápidas

Isso não é deep learning sofisticado. É regressão + feature engineering + distribuição disciplinada do alerta. O valor está em fechar o loop, não na complexidade do modelo.

O que não funcionou

V0: deep learning end-to-end — testamos LSTMs sobre séries temporais de eventos. Precisão parecida com regressão simples, mas não interpretável. Os operadores não confiavam em alertas que não podiam explicar. Abandonamos.

Dashboards como canal principal — muitas anomalias ficavam no dashboard sem ação. Migramos para push notifications (WhatsApp) com call-to-action explícita.

Modelos globais por indústria — um modelo para “todas as frutas” dava pior precisão que modelos específicos por produto-planta-fornecedor. Agora treinamos específicos e damos versioning claro.

Lessons learned

1. O gap entre detecção e valor é 80% do projeto — não o modelo
2. Interpretabilidade > precisão em domínios com operadores humanos
3. Feedback loop desde o dia 0 — sem labels de operadores, o modelo estagna
4. Métricas de negócio, não de ML nos relatórios ao cliente
5. Modelos simples + domain knowledge > modelos complexos sem contexto

E agora?

Estamos explorando causal AI com ferramentas como DoWhy — não só detectar correlations mas inferir causalidade real de eventos. Combinado com LLMs para formular hipóteses, pode acelerar muito a root cause analysis.

Se você está construindo anomaly detection em supply chain e seu modelo detecta bem mas ninguém age nos alertas, o problema não é seu modelo — é o loop de ação. Comece por aí.

Tem um problema de yield, waste ou perda de qualidade em produção? Vamos conversar — podemos mostrar casos reais com impacto mensurável.