Nosso sistema fez uma coisa, e funcionou bem: transformou perguntas de linguagem pure em chamadas de API.
Os usuários eram analistas, gerentes de contas e líderes de operações. Eles sabiam de quais dados precisavam, mas montá-los manualmente significava extrair de quatro painéis, duas ferramentas de BI e um criador de relatórios do Salesforce. Com nosso sistema, eles digitaram a solicitação em inglês simples. Uma solicitação como “Compilar um relatório de quantity de vendas de janeiro a março de 2026 para a região Nordeste, discriminado por cidade” foi traduzida em uma chamada de API na qual o sistema poderia atuar:
json
{
“description”: “O usuário solicitou quantity de vendas para um determinado intervalo de datas, aqui está a chamada da API para obter a resposta”,
“api_call”: “/api/volume_vendas”,
“post_body”: {
“data_inicial”: “01/01/2026”,
“data_final”: “31/03/2026”,
“região”: “nordeste”
}
}
O resto do gasoduto period engenharia convencional. O sistema despachou a chamada para o back-end certo – tínhamos integrações com portais de relatórios internos, Salesforce e vários serviços locais – aplicou uma consulta JSON gerada por modelo de linguagem grande (LLM) para filtrar e moldar a resposta e a entregou por e-mail, como um documento do Drive ou renderizado como um gráfico no navegador.
Em meados de 2025, o sistema gerava várias centenas de relatórios por mês. Esses relatórios foram consumidos pela liderança e analistas e distribuídos para stakeholders externos. Tornou-se a forma padrão pela qual a maioria das equipes extraía dados ad-hoc.
O contrato entre o LLM e o resto do sistema period um objeto JSON estruturado conforme descrito no exemplo acima.
json
{
“description”: “O usuário solicitou quantity de vendas para um determinado intervalo de datas, aqui está a chamada da API para obter a resposta”,
“api_call”: “/api/volume_vendas”,
“post_body”: {
“data_inicial”: “01/01/2026”,
“data_final”: “31/03/2026”,
“região”: “nordeste”
}
}
Nós o construímos no Claude Sonnet 3.5 no início de 2025. Atualizamos para 3.7 sem incidentes e para 4.0 sem incidentes. Quando o Sonnet 4.5 foi lançado, estávamos cada vez mais complacentes com a estabilidade e previsibilidade dos LLMs na resolução do que acreditávamos ser um problema simples. As atualizações de modelos tornaram-se rotineiras, como destruir uma versão secundária de uma biblioteca bem comportada.
Em seguida, lançamos o 4.5. Para uma porcentagem significativa de solicitações, o modelo começou a incluir o conteúdo de post_body no campo de descrição. Seguiram-se dois modos de falha.
Primeiro, os parâmetros do filtro nunca chegaram à API. Nosso sistema leu post_body como a fonte da verdade para a carga útil da solicitação, e esse campo voltou vazio. A chamada de API foi feita sem o filtro de período ou região. Dependendo da API específica que está sendo chamada, o back-end retornou o quantity de vendas para todo o período ou todas as regiões ou retornou um erro 500.
Em segundo lugar, o modelo começou a fazer perguntas esclarecedoras na sua resposta. Isso period novo. As versões anteriores sempre adotavam uma abordagem de melhor esforço para uma solicitação ambígua e retornavam um objeto estruturado. O Soneto 4.5, sendo mais cauteloso, às vezes respondia com uma pergunta. Nosso sistema não tinha caminho para isso. Ele foi construído com base no pressuposto de que cada invocação de modelo resultaria em uma chamada de API. Não havia nenhum componente humano no circuito e nenhum estado para reter uma solicitação parcialmente concluída. Isso fez com que os sistemas downstream quebrassem de várias maneiras.
Voltamos para 4.0. Isso foi mais difícil do que deveria: entre as implantações 4.0 e 4.5, nossa equipe adicionou novas integrações de API, todas qualificadas em relação à 4.5. Reverter o modelo significou requalificar cada um deles contra o 4.0 sob pressão de tempo.
Por que a disciplina tradicional de engenharia falha aqui
A engenharia de software program baseia-se na capacidade de limitar o efeito de uma mudança. Ao atualizar um driver ou biblioteca, você lê as notas de versão para ver se espera alterações significativas. Os testes unitários circunscrevem o que poderia ter sido movido. Você pode aproveitar a seguinte propriedade: O sistema que está sendo alterado é determinístico o suficiente para que seu comportamento possa ser previsto ou, pelo menos, amostrado com densidade suficiente para lhe dar confiança. O raio da explosão é limitado pela construção.
Os sistemas apoiados por LLM quebram essa suposição. O componente que produz sua saída não está sob seu controle. Você não pode diferenciar um aumento de versão do modelo de 4.0 para 4.5. É uma substituição completa da funcionalidade da qual seu sistema depende.
Isto é o que queremos dizer com um raio de explosão infinito: uma mudança cujos efeitos posteriores não podem ser enumerados antecipadamente porque o espaço de entrada (linguagem pure) e os modos de falha (qualquer coisa que o modelo possa fazer de maneira diferente) são ambos ilimitados.
Anatomia do fracasso
A autópsia revelou que nosso alerta sempre foi subespecificado. Dissemos ao modelo para retornar um objeto JSON com três campos. Tínhamos descrito para que servia cada campo. Não declaramos explicitamente que a descrição deve ser uma string de linguagem pure e não deve conter representações serializadas de outros campos.
Versões anteriores do modelo inferiram essa restrição do contexto. O Soneto 4.5, evidentemente melhor em ser “útil” em suas escolhas de formatação, decidiu que pedir esclarecimentos ou fornecer o corpo da solicitação na descrição tornava a resposta mais útil. Do ponto de vista do modelo, esta foi uma interpretação razoável de uma instrução ambígua. No entanto, isto violou os pressupostos sob os quais o nosso sistema foi construído.
O bug não estava no modelo. O erro estava em nossa suposição de que o modelo continuaria a preencher nossas lacunas de especificação como sempre fez. Três atualizações bem-sucedidas nos treinaram para acreditar que essas lacunas eram seguras.
Os modos de saída estruturados e as APIs de uso de ferramentas teriam detectado essa falha específica no nível do esquema. Não os estávamos usando por motivos de engenharia fora do escopo deste artigo. Mas os esquemas restringem apenas a sintaxe, não a semântica. Um esquema não pode especificar que uma pergunta de esclarecimento não deve aparecer em um sistema sem caminho para esclarecimento ou que um intervalo de datas nunca deve ser padronizado silenciosamente para todos os tempos. Os esquemas resolvem a metade mais fácil do problema.
A arquitetura evals-first
A disciplina que preenche esta lacuna é tratar o conjunto de avaliação — e não o immediate — como a especificação formal do sistema. O immediate é um implementação da especificação. O modelo é um intérprete. As avaliações são a própria especificação, e qualquer modelo ou alteração de immediate é válida se e somente se for aprovada.
Na prática, um eval é um triplo: uma entrada, uma propriedade que a saída deve satisfazer e uma função de pontuação. Para nosso sistema, a avaliação que teria capturado a regressão 4,5 é mais ou menos assim:
píton
def test_description_contains_no_serialized_payload(resposta):
desc = resposta[“description”].mais baixo()
proibido = [“curl”, “post_body”, “{“, ” “https://”]
afirmar não qualquer(token em desc para token em proibido),
f”descrição vazou conteúdo estruturado: {resposta[‘description’]}”
Algumas centenas dessas propriedades, algumas escritas à mão para invariantes importantes conhecidos, algumas geradas como testes de regressão a partir de tráfego de produção actual, algumas pontuadas por um LLM como juiz para qualidades mais confusas como tom, tornam-se uma porta. As atualizações de modelo e as alterações imediatas devem ser tratadas como solicitações pull que devem deixar o conjunto verde antes de serem mescladas.
Avaliações são caras para construir e manter. Eles mudam conforme seu produto muda. A pontuação do LLM como juiz introduz sua própria variação nos resultados. E o conjunto só pode detectar modos de falha que você pensou em especificar – você não pode avaliar seu caminho para a segurança contra uma categoria de falha que você nunca imaginou. Aprendemos esta lição da maneira mais difícil: ninguém em nossa equipe jamais escreveu uma afirmação que dissesse “o campo de descrição não deve conter um comando curl”, porque ninguém pensou que o modelo colocaria um ali.
Evals não são uma solução mágica. Eles oferecem a capacidade de limitar o raio de explosão de uma mudança da única maneira disponível quando a função subjacente é uma caixa preta: amostrando densamente a resposta de entrada-saída com a qual você realmente se importa e recusando-se a implantar quando esse comportamento muda.
O roteiro
A comunidade de engenharia ainda precisa desenvolver um corpo de conhecimento para escrever avaliações eficazes. Não existem padrões amplamente aceitos sobre o que significa “cobertura” em espaços de entrada de linguagem pure. Os sistemas CI/CD não foram construídos para controlar resultados de testes probabilísticos. À medida que os agentes assumem um trabalho mais autónomo – escrever códigos, movimentar dinheiro, agendar alterações de infraestrutura – a lacuna entre “o modelo passou nos nossos testes de fumaça” e “sabemos o que este sistema fará na produção” torna-se o problema central de engenharia dos próximos anos.
As equipes que preencherem essa lacuna serão aquelas que pararão de tratar as avaliações como uma reflexão tardia de garantia de qualidade e começarão a tratá-las como a especificação actual do que é seu sistema.
Vijay Sagar Gullapalli é engenheiro fundador de IA na Undertake AI e inventor patenteado pelo USPTO.
Sarat Mahavratayajula é engenheiro de software program sênior na Sherwin-Williams.
Bem-vindo à comunidade VentureBeat!
Nosso programa de visitor posts é onde especialistas técnicos compartilham insights e fornecem análises profundas, neutras e não adquiridas, sobre IA, infraestrutura de dados, segurança cibernética e outras tecnologias de ponta que moldam o futuro das empresas.
Leia mais do nosso programa de visitor publish – e confira nosso diretrizes se você estiver interessado em contribuir com um artigo de sua autoria!
