Detecção de padrões em produção sem teatro de IA

Detecção de padrões em SaaS B2B tem um problema de marketing. Todo produto promete. A maioria entrega o que é, efetivamente, keyword matching com UI pior. Queríamos fazer melhor. Aqui está o que “melhor” parece por dentro do motor da Luminary.

A abordagem ingênua que rejeitamos

A versão fácil de detecção de padrões: treinar um modelo nas ações do usuário, prever a próxima ação. Pronto. Subir pra produção. Cobrar a mais.

O problema é que ações do usuário são consequência de intenção, e intenção é moldada por contexto que o stream de ações não enxerga. Um usuário “criando um workflow” pode estar fazendo o primeiro ou migrando o centésimo. A ação é idêntica. As implicações são opostas.

As três camadas que de fato compõem nossa detecção de padrões

Camada 1: um transformer em nível de evento que produz embeddings densos de cada ação do usuário com contexto (hora do dia, dia da semana, formato de workflow anterior, tier do time).

Camada 2: um modelo de sequência sobre os últimos 100 eventos que detecta transições de padrão — quando o comportamento do usuário muda de forma.

Camada 3: um conjunto pequeno de heurísticas afinadas à mão que vetam saídas da Camada 2 quando caem em território conhecido de previsões ruins — usuários do primeiro mês, períodos pós-incidente.

A Camada 3 é a parte de que ninguém fala. Também é onde 30% da nossa qualidade veio. Falamos disso no contexto de como mostramos incerteza para o cliente.

Por que a camada heurística importa

Modelos de ML puros ficam ótimos em métricas offline e vergonhosos em produção. As heurísticas da Camada 3 codificam o que engenheiros aprendem em postmortems — situações em que previsões confiantes são sistematicamente erradas. Tratamos esse conhecimento como peça de primeira classe do sistema, não como gambiarra.

Isso é o que diferencia uma detecção de padrões útil de uma demo bonita: aceitar que o sistema vai errar e construir a partir desse fato.