Na semana passada, escrevemos sobre como alimentar terabytes de logs de CI para um LLM. A maioria das perguntas no Hacker News não eram sobre os logs. Eles tratavam do agente: quais modelos, como eles coordenam e quanto custa tudo isso.
Hoje rodamos o Opus 4.6 e pagamos menos do que quando rodamos tudo no Sonnet 4.0.
A razão é principalmente o que o Opus não fazer: 80% das falhas nunca o alcançam e, quando o fazem, ele nunca lê uma linha de log.
A arquitetura fica assim:
Deixe um agente barato decidir se o caro é necessário
Na semana passada analisamos cerca de 4.000 falhas de CI. 818 eram problemas novos. Os outros 3.187 eram um problema conhecido que estava surgindo novamente: um teste instável, um problema de infraestrutura, um problema de rede que já havíamos detectado.
Não faz sentido acordar um modelo caro quando 80% das vezes a resposta é “é uma duplicata”. Infelizmente, não podemos detectar duplicatas de forma determinística: o mesmo trabalho pode falhar várias vezes por motivos completamente diferentes, então você precisa realmente olhar os logs para saber se já viu isso antes.
Inicialmente usamos o Sonnet para equilibrar custo e desempenho. Funcionou, mas foi o pior dos dois mundos: ainda caro e os resultados não foram tão bons quanto um modelo de fronteira.
Mudamos para o padrão de “triagem”: um agente Haiku com um trabalho muito específico e restrito. Este problema já foi rastreado ou não? Se for, pare aí mesmo. Caso contrário, passe para o Opus.
Detectar duplicatas com o Haiku foi um pouco desafiador. Precisávamos tornar o trabalho o mais fácil possível, por isso anexamos mensagens de erro às falhas anteriores e demos ao Haiku duas ferramentas de pesquisa: correspondência exata para trechos de erros conhecidos e pesquisa semântica (pgvector) para erros semelhantes, mas não idênticos. O RAG está morto, mas a pesquisa semântica é muito legal. operator does not exist bigint character varying e migration type mismatch on installation_id são strings diferentes, mas a mesma causa raiz, e a pesquisa semântica revela isso.
O agente Haiku lê os logs, pesquisa mensagens de erro, tenta comparar falhas conhecidas e faz uma chamada. Na dúvida, a situação aumenta. Um falso positivo custa um pouco de dinheiro; um falso negativo significa que perdemos algo real.
4 em cada 5 falhas nunca chegam ao Opus. Uma correspondência de triagem custa cerca de 25 vezes menos do que uma investigação completa.
Deixe o agente extrair o contexto, não force
Várias pessoas perguntaram como lidamos com logs com mais de 200 mil linhas. Nós não os empurramos para o prompt. Damos ao agente uma interface SQL para ClickHouse e deixamos que ele pergunte o que precisa.
A razão não é apenas o custo simbólico. Se você entregar a um agente um conjunto específico de linhas de registro, você já terá feito um julgamento sobre o que é relevante antes de saber qual é realmente o problema. O agente se ancora no que você deu. Se a causa real estiver em outro lugar, você tornou mais difícil encontrá-la. É o mesmo motivo pelo qual você não deseja liderar uma sessão de depuração dizendo “Acho que o problema está neste arquivo”: você influenciou a investigação antes de ela começar.
Escrevemos detalhadamente sobre a configuração do SQL na semana passada, mas a versão resumida: há uma tabela com dados brutos (github_logsuma linha por linha de registro) e um conjunto de visualizações materializadas com dados pré-agregados: taxas de falha por fluxo de trabalho, tempos de trabalho, contagens de resultados. A maioria das investigações começa com as visualizações materializadas para restringir a causa e, em seguida, detalha os registros brutos quando necessário.
Não informamos ao agente qual tabela consultar. Em vez disso, usamos as próprias respostas para guiá-lo progressivamente. Se uma consulta retornar muitas linhas, truncaremos e sugeriremos uma visão materializada mais específica. Se os logs ainda não foram ingeridos, apontamos para a CLI do GitHub. O agente descobre o que precisa sem que tenhamos que antecipar cada caminho.
Agentes caros planejam, agentes baratos fazem o trabalho
A Opus analisa o que falhou, formula uma hipótese e cria subagentes do Haiku para fazer a escavação real. Cada subagente recebe um aviso do Opus: exatamente o que pesquisar, como pesquisar, o que retornar. Os subagentes são limitados a um nível de profundidade; eles não podem gerar seus próprios subagentes. A distribuição ilimitada é como você obtém custos excessivos.
Algumas semanas atrás, três jobs do Storybook CI falharam no mesmo commit, todos travando em pnpm install.
Opus começou pedindo a um subagente que buscasse as mensagens de erro da etapa de instalação do pnpm com falha. ClickHouse ainda não tinha os logs, então o subagente voltou para a CLI do GitHub.
Subagente nº 1 incitar:
Busque os logs de CI para esta execução. Retorne as mensagens de erro exatas da etapa de instalação do pnpm, a saída de erro completa, especialmente as últimas 50 a 100 linhas.
Resultado: gyp ERR! not found: make. re2@1.23.0 não pôde compilar porque make não estava no corredor.
A Opus pesquisou insights existentes (sem correspondência) e, em seguida, consultou ClickHouse sobre a tendência de falha ao longo de 14 dias:
Feb 23: 0.2% failure rate
Feb 24: 1.1%
Feb 25: 8.0% <- inflection point
Algo mudou claramente em 25 de fevereiro. Opus gerou Subagente nº 2:
Investigue o que mudou entre 24 e 25 de fevereiro. A taxa de falha passou de 0,2% para 8%. O erro é
gyp ERR! not found: make. Execute git log no arquivo de fluxo de trabalho e package.json para essa janela.
As dependências de compilação foram removidas durante uma migração não relacionada. Correto para essa migração, mas re2 ainda é necessário make para compilar nativamente. Opus gerou Subagente nº 3 para verificar o estado atual do fluxo de trabalho e, em seguida, criou o insight com a causa raiz e a correção.
O orquestrador nunca lê uma linha de logs, histórico do git ou o próprio código.
Algumas coisas dignas de nota:
Custo. O Haiku lida com aproximadamente 65% de todos os tokens de entrada, mas apenas com aproximadamente 36% de nossos gastos com LLM. O modelo caro pensa; o modelo barato diz. Sem a hierarquia do modelo, a fatura diária mais que duplica.
A Opus planeja conforme avança. Tudo começa com uma hipótese, mas os resultados de cada subagente moldam o próximo passo. Nesta investigação obteve o erro, pesquisou o histórico e depois perguntou o que mudou. Cada rodada informava a próxima. Mais de um terço de nossas investigações são multifacetadas e novos problemas precisam de aproximadamente o dobro da profundidade de investigação dos problemas conhecidos.
Higiene do contexto. O contexto do orquestrador permanece limpo: resumos estruturados de subagentes, não saída de log bruta. Cada subagente começa do zero e seu contexto é descartado quando termina. A saída da chamada de ferramenta se acumula rapidamente e o contexto obsoleto do início de uma sessão prejudica as decisões posteriores.
Pesquisa direcionada. “Retornar as mensagens de erro exatas da etapa de instalação do pnpm” é um prompt muito diferente de “analisar esses logs”. A Opus decide o que procurar; Haiku encontra. A relação entrada/saída do Haiku é de 86:1 (lê muito, retorna trechos focados), enquanto o orquestrador fica em torno de 50:1 (sintetiza e decide). O Haiku absorve os dados para que o Opus não precise fazer isso.
Isso não era possível há 6 meses
Há seis meses estávamos no Sonnet 4.0. Ele teve dificuldade para escrever consultas ClickHouse corretas: tabelas erradas, filtros ausentes, leitura de muitos dados. O Haiku 4.0 não foi útil para nada além da classificação sim/não.
Hoje, o Opus 4.6 pode planejar investigações e escrever avisos precisos para subagentes. O Haiku 4.5 pode lidar com tarefas restritas e direcionadas porque o escopo das tarefas é restrito o suficiente para que um modelo rápido e barato possa executá-las.
A atualização para um modelo de fronteira fez com que os custos diminuíssem.
O padrão generaliza
Construímos isso para logs de CI, mas o padrão se aplica a qualquer coisa com alto volume de eventos: logs de segurança, telemetria IoT, dados financeiros. A maioria dos eventos são ruídos ou repetições, e o modelo caro só deveria ver aqueles que não o são.
Há uma quarta camada que não abordamos: a reavaliação. O sistema verifica periodicamente se o que concluiu ainda é verdade, fechando insights obsoletos, capturando falsos positivos e verificando se as correções funcionaram. Essa é uma postagem por si só.
Ainda estamos ajustando onde fica o limite do subagente. Às vezes, gerar um subagente custa mais do que fazê-lo em linha porque a sobrecarga de configuração supera a economia.
A parte mais difícil não foi tornar o agente mais inteligente. Estava construindo as camadas que o impediam de funcionar quando não deveria.
Fonte: theverge
