Ao vivo 18/11 · Turma 318 nov às 19:00 MSK — aula prática gratuita de agentes de IA · Turma 3 ao vivo começa 23/11Aula 18/11 →Turma 3 (23/11)
LançamentoAnálise · No radarHabr AI→ original

Avito criou um bot para analisar métricas: a IA escreve o texto, e o código convencional faz as contas

A equipe de BI da Avito criou o Big10 Pulse, um bot no Mattermost que verifica as principais métricas financeiras todas as manhãs e envia um PDF com uma breve análise. A ideia central: tudo o que pode ser definido por regras fica no código convencional — disponibilidade dos dados, limites para detectar anomalias e contribuição dos segmentos. O modelo de linguagem recebe os fatos já calculados e apenas os transforma em um comentário, que depois passa por uma verificação para detectar afirmações inventadas.

Processado por IA de Habr AI; editado por Hamidun News
Avito criou um bot para analisar métricas: a IA escreve o texto, e o código convencional faz as contas
Fonte: Habr AI. Colagem: Hamidun News.
Ouvir artigo
Ficha técnica e números-chave
ParâmetroDados
Fonte originalHabr AI ↗
Editor-chefe
Dado-chave #1O bot não inicia enquanto as fontes de dados não forem atualizadas
Dado-chave #2O código detecta anomalias com base em regras; o modelo não faz essa análise a partir de gráficos
Economia estimadacerca de 99 horas de trabalho por mês

Todas as manhãs, um analista abre o painel financeiro, verifica se os dados foram atualizados, confere a receita e, se o número oscila, começa a investigar onde e por quê. Meia hora por dia, sem nenhuma mágica, mas essas verificações não podem ser deixadas de lado. As desenvolvedoras de BI da Avito Aigul Akhmetova e Valeria Smirnova decidiram passar essa rotina para um bot. Assim nasceu o Big10 Pulse, no Mattermost corporativo. A conclusão mais interessante da equipe diz respeito ao que não se deve delegar a um modelo de linguagem.

Por que um alerta não basta

O gráfico mostra que a métrica mudou, mas não explica por quê. Antes de formular qualquer hipótese, o analista precisa confirmar que os dados do dia foram carregados por completo, que o desvio supera as oscilações habituais, que a base de comparação foi escolhida corretamente e qual segmento mais contribuiu para a mudança. Pular direto para a explicação facilita confundir uma carga incompleta de uma fonte com uma queda do negócio, ou o efeito de um feriado com um incidente. O gráfico continua parecendo convincente, e esse é o problema.

Por isso, a equipe não criou um chat de uso geral com acesso ao relatório. Restringiu a tarefa à análise inicial: verificar a disponibilidade dos dados, separar sinal de ruído, decompor a mudança em fatores e indicar onde investigar em seguida.

O que fica com o código e o que fica com o modelo

A primeira etapa é a mais básica: o bot verifica a data da última atualização das fontes. Enquanto os dados não estiverem prontos, o cálculo não começa. O modelo não participa dessa etapa. Ele consegue produzir uma explicação fluente até para um erro de carregamento, mas, nessa situação, a equipe precisa que nenhum texto seja produzido. Cada envio fica registrado em um log, e o usuário não recebe mensagens duplicadas.

Depois, o bot procura anomalias. Ele compara o valor com o indicador da semana anterior e com a média de sete dias. Os limites dependem do tipo de dia e do histórico de cada métrica, e uma regra específica evita alertas para a recuperação esperada após feriados. O código convencional faz todas essas contas, porque o sistema deve tomar a mesma decisão quando recebe os mesmos dados. A equipe não pediu ao modelo que “olhasse o gráfico e dissesse se parece uma anomalia”.

Em seguida, o bot decompõe a diferença total por áreas de negócio e tipos de receita. Ele ordena esses componentes pela contribuição para o resultado, e não pelo maior percentual. Por exemplo: uma queda total de 100 unidades convencionais resulta de menos 80, menos 30 e mais 10, o que deixa claro por onde começar. Uma categoria pequena pode crescer dezenas de pontos percentuais sem alterar o resultado final.

O modelo só entra em ação no fim. Ele recebe um conjunto pequeno de fatos prontos: as variações relativas são calculadas previamente, e o Python insere os valores absolutos. O relatório completo não é enviado ao modelo, porque, quanto mais relações fortuitas ele encontra, mais fácil fica inventar uma explicação plausível. A fórmula da equipe: quanto menos liberdade o modelo tem, mais útil é a resposta.

Verificação do texto antes do envio

Mesmo com dados de entrada corretos, o modelo tende a extrapolar a conclusão. O cálculo diz: a área A deu a maior contribuição negativa. No texto aparece: “a receita caiu por causa de um erro técnico na área A”. O modelo não tinha nenhuma informação sobre esse erro, mas a afirmação soa categórica.

Por isso, a análise passa por duas verificações. A primeira filtra textos provisórios, respostas padronizadas e mensagens sem dados. A segunda compara o texto com o conjunto original de fatos e procura números e afirmações que não estavam ali. Um ponto fundamental é que o componente de verificação recebe os mesmos fatos que o gerador. Caso contrário, um modelo probabilístico apenas avalia o quanto o outro é convincente, sem verificar a veracidade.

O bot distingue três coisas: anomalia (a métrica ultrapassou os limites), contribuição (onde isso aconteceu) e causa (por quê). Em geral, uma pessoa confirma a causa, às vezes com a ajuda de fontes adicionais. Se essas etapas forem misturadas, o sistema começará a apresentar hipóteses como fatos comprovados.

O que mais foi preciso resolver

A assinatura guarda o recorte dos dados, o idioma e o tipo de relatório, e é configurada por botões no Mattermost. Se várias pessoas assinam o mesmo recorte, o cálculo é reaproveitado. Depois do resumo, é possível fazer uma pergunta para esclarecer algum ponto, e a resposta passa por nova verificação. As permissões de acesso não mudam: o bot não mostra nada que o usuário não pudesse ver no sistema de origem. A equipe monitora o uso e as falhas no Grafana e considera o feedback de diretores e gestores parte do produto.

Resultado e limitações

Durante os testes, havia 9 assinantes, e a equipe estimou uma economia de aproximadamente 99 horas de trabalho por mês (9 pessoas × 30 minutos × 22 dias úteis). Mais tarde, outros 55 usuários aderiram por iniciativa própria. É uma estimativa calculada, não uma medição com cronômetro. A mudança na rotina é mais reveladora: em vez de gastar 30–60 minutos verificando o relatório, a pessoa leva um ou dois minutos para ler a análise pronta.

O bot não substitui o analista e não encontra a causa raiz de qualquer oscilação. Ele espera pelos dados corretos, identifica desvios e conduz a pessoa à primeira hipótese que pode ser verificada. O artigo não apresenta números sobre o efeito na qualidade das decisões ou na precisão das análises.

O que aplicar na prática

Se você está construindo um assistente de IA semelhante para métricas, comece delimitando as responsabilidades. A disponibilidade dos dados, os limites, a sazonalidade e a decomposição das contribuições devem ficar no código determinístico. Deixe o modelo redigir o texto com base em um conjunto pequeno de fatos verificados. Dê ao validador os mesmos fatos que o gerador recebe e considere as permissões de acesso desde o primeiro dia. A decisão mais importante da equipe foi saber a hora de limitar a atuação do modelo de linguagem.

História

Perguntas frequentes sobre a notícia

Por que um alerta não basta?

O gráfico mostra que a métrica mudou, mas não explica por quê. Antes de formular qualquer hipótese, o analista precisa confirmar que os dados do dia foram carregados por completo, que o desvio supera as oscilações habituais, que a base de comparação foi escolhida corretamente e qual segmento mais contribuiu para a mudança. Pular direto para a explicação facilita confundir uma carga incompleta de uma fonte com uma queda do negócio, ou o efeito de um feriado com um incidente.

O que fica com o código e o que fica com o modelo?

A primeira etapa é a mais básica: o bot verifica a data da última atualização das fontes. Enquanto os dados não estiverem prontos, o cálculo não começa. O modelo não participa dessa etapa. Ele consegue produzir uma explicação fluente até para um erro de carregamento, mas, nessa situação, a equipe precisa que nenhum texto seja produzido. Cada envio fica registrado em um log, e o usuário não recebe mensagens duplicadas. Depois, o bot procura anomalias.

O que se sabe sobre Verificação do texto antes do envio?

Mesmo com dados de entrada corretos, o modelo tende a extrapolar a conclusão. O cálculo diz: a área A deu a maior contribuição negativa. No texto aparece: “a receita caiu por causa de um erro técnico na área A”. O modelo não tinha nenhuma informação sobre esse erro, mas a afirmação soa categórica. Por isso, a análise passa por duas verificações. A primeira filtra textos provisórios, respostas padronizadas e mensagens sem dados.

ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…