Como a Mendral Reduziu Custos de LLM ao Atualizar para Opus: Padrão Triager, Acesso SQL e Arquitetura de Sub-Agente

A Mendral publicou recentemente detalhes sobre como eles migraram para o Opus 4.6 para análise de falhas de CI enquanto reduziam os custos gerais de LLM em comparação com a configuração anterior com Sonnet 4.0. A chave é uma arquitetura que separa a triagem da investigação e usa subagentes baratos para o trabalho pesado.

Arquitetura: Triador barato, planejador caro

Das ~4.000 falhas de CI analisadas, 3.187 eram duplicatas — um teste instável conhecido, um soluço de infraestrutura ou um pico de rede. Acordar um modelo caro para isso é um desperdício. Mas a deduplicação não é determinística: o mesmo job pode falhar por razões diferentes. A solução deles é um padrão de triador:

• Um agente Haiku lida com a tarefa restrita: decidir se uma falha já está rastreada. Ele usa correspondência exata e busca semântica (pgvector) em mensagens de erro conhecidas. Duas strings diferentes como operator does not exist bigint character varying e migration type mismatch on installation_id são a mesma causa raiz — a busca semântica captura isso.
• Em caso de dúvida, o Haiku escala para o Opus 4.6. Um falso positivo custa um pouco; um falso negativo perde um bug real.
• 4 de cada 5 falhas nunca chegam ao Opus. Uma correspondência do triador custa ~25x menos que uma investigação completa.

Deixe os agentes puxarem o contexto, não empurre

Em vez de enfiar logs de 200K+ linhas nos prompts, os agentes recebem uma interface SQL para o ClickHouse. Há uma tabela bruta (github_logs, uma linha por linha de log) e views materializadas com dados pré-agregados: taxas de falha por workflow, tempos de job, contagens de resultado. A maioria das investigações começa com as views para restringir, depois mergulha nos logs brutos. Se uma consulta retornar muitas linhas, o sistema trunca e sugere uma view mais específica. Se os logs ainda não foram ingeridos, os agentes recorrem ao GitHub CLI.

Modelos caros planejam, modelos baratos executam

O Opus forma uma hipótese e gera subagentes Haiku limitados a um nível de profundidade — sem expansão ilimitada. Cada subagente recebe um prompt do Opus: exatamente o que pesquisar e como. Exemplo de um caso real:

Três jobs de CI do Storybook falharam no mesmo commit, travando em pnpm install. O Opus enviou um subagente para buscar mensagens de erro dessa etapa. O ClickHouse ainda não tinha os logs, então o subagente usou o GitHub CLI e retornou: gyp ERR! not found: make — [email protected] não conseguiu compilar porque make não estava no runner. O Opus então consultou o ClickHouse pela tendência de falha nos últimos 14 dias, encontrou o ponto de inflexão e escalou. Os prompts dos subagentes são explícitos: "Busque os logs de CI para esta execução. Retorne as mensagens de erro exatas da etapa pnpm install, a saída de erro completa, especialmente as últimas 50-100 linhas."

Para quem é isso

Equipes construindo agentes baseados em LLM para depuração de CI ou qualquer tarefa onde o tamanho do contexto e o custo sejam preocupações.