Certo uma vez não é certo: a métrica de consistência que derrubou agentes contábeis a 2,6%

TV
Thiago Victorino
7 min de leitura
Certo uma vez não é certo: a métrica de consistência que derrubou agentes contábeis a 2,6%

Rode a mesma tarefa contábil oito vezes, com o mesmo modelo, em condições idênticas. Conte quantas vezes o modelo acerta por completo nas oito. No APEX-Accounting, o benchmark que a Mercor construiu com a Ramp sobre 160 tarefas e nove modelos de fronteira, o modelo mais consistente passou nesse critério em 2,6% das tarefas.

O mesmo benchmark registra que ao menos um modelo obteve algum crédito em mais de 95% das tarefas. Os dois números são verdadeiros, e a distância entre eles é a história inteira. Quase tudo é solucionável por alguém, uma vez. Quase nada é solucionável por alguém, de forma confiável.

Para um chatbot, essa distinção não tem consequência. Para um processo que escreve num registro contábil, tem consequência enorme.

O que oito execuções revelam e uma esconde

Leaderboards reportam médias. Na média de critérios atendidos, o APEX-Accounting parece um benchmark de fronteira comum: Claude Fable 5 com 56,4%, Muse Spark 1.1 com 52,6%, GPT-5.6 Sol com 51,5%, até Qwen 3.5 com 24,4%, o menor dos nove. Olhando só essa coluna, você concluiria que os modelos do topo já passaram da metade do caminho para automatizar o fechamento mensal, com ordenação clara e curva de melhoria plausível.

Agora troque a agregação. Pass@8, ou seja, a tarefa resolvida em todas as oito tentativas, coloca Muse Spark 1.1 em 21,5% e Fable 5 em 20,1%. Exija correção completa nas oito execuções e o líder cai para 2,6%. E 58% das 160 tarefas nunca foram totalmente resolvidas por nenhum dos nove modelos em nenhuma execução.

A média está correta. Ela responde a uma pergunta que não governa nada. Uma média de 56% descreve valor esperado sobre uma população de tentativas, o que serve quando você produz cem rascunhos de baixo risco e um revisor passa os olhos. Diz quase nada sobre o que acontece na única tentativa que de fato entra no razão. Para isso, o número necessário é com que frequência a mesma entrada produz a mesma saída correta.

Contabilidade sente esse efeito primeiro por uma propriedade incomum: o artefato persiste, é assinado e é comparado ao período anterior. Um agente de marketing que varia entre execuções produz variedade. Um agente de fechamento que varia entre execuções produz trabalho de reconciliação, e a reconciliação custa mais que a tarefa original.

Sete em cada dez falhas são de julgamento, não de busca

O instinto, quando um modelo falha sobre dados corporativos, é culpar o retrieval. Documento errado, contexto faltando, chunking ruim, índice desatualizado. Esse instinto é mensurável, e neste benchmark ele erra na maioria dos casos.

Cerca de sete em cada dez falhas avaliadas vieram de raciocínio falho, não de recuperação de informação. Fable 5: 19 de 24 falhas avaliadas. GPT-5.6 Sol: 21 de 28. Muse Spark 1.1: 13 de 22. Os modelos encontraram os números certos e então fizeram a coisa errada com eles.

Os autores do benchmark colocam a consequência operacional de forma direta: “Um modelo que perde uma resposta intermediária correta ainda pode criar um lançamento contábil ruim.” Esse é o modo de falha que sobrevive a qualquer melhoria de RAG que você possa comprar. Retrieval melhor eleva o teto do que o modelo consegue enxergar. Não toca no que o modelo conclui.

O mesmo relatório traça uma linha que importa para quem usa evidência de prova para justificar deploy. “Este é um resultado muito diferente do desempenho em exames de contabilidade. Modelos conseguem produzir a resposta certa num teste controlado e ainda assim falhar em carregar julgamento contábil por um fluxo real.” Um exame pontua a resposta final. Um fluxo exige carregar um julgamento por uma dúzia de passos dependentes sem derrubá-lo nenhuma vez.

O método por trás desses números é mais pesado que o de boa parte dos benchmarks. São 160 tarefas em 10 empresas simuladas. Mais de 40 profissionais de contabilidade com mediana de 11 anos de experiência, mais da metade ex-Big Four, escrevendo rubricas com média de 13,7 critérios por tarefa. Um juiz de IA open-source que atinge 97% de concordância com os avaliadores humanos. Não é um banco de questões raspado da internet.

Tetos de orçamento se comportam de forma diferente em cada modelo

O achado de custo é o mais fácil de ler errado, e ele inverte uma suposição comum de compras.

O Fable 5 marca 11,8% com teto de um dólar por tarefa e 55,2% com teto de cinquenta dólares. É um ganho real de capacidade vindo só do orçamento, no mesmo modelo. O relatório informa percentuais apenas nesses dois extremos, então qualquer número citado por aí para tetos de cinco ou dez dólares vem de leitura de gráfico, não do texto.

A parte interessante está no topo dessa faixa. No teto de cinquenta dólares, o Fable 5 gasta cerca de 32 dólares por execução. O Muse Spark 1.1 gasta cerca de 5 dólares e fica dentro de quatro pontos percentuais. No geral, os modelos usam apenas 64,7% do orçamento máximo disponível nesse teto, o que indica que não é o limite superior que os prende.

Um teto único e global, portanto, faz coisas diferentes com cada modelo da sua stack. Coloque em um dólar e você desligou silenciosamente o modelo que escolheu justamente pelo teto de capacidade. Coloque em cinquenta e você paga seis vezes mais por quatro pontos de diferença em um deles. Política de orçamento precisa ser escrita por modelo e por classe de tarefa, calibrada contra a curva real de gasto, em vez de aplicada como um número único de organização na configuração do gateway. Já escrevemos sobre agentes que ignoram o orçamento que receberam; aqui está o problema espelhado, em que o orçamento reescreve em silêncio a capacidade que você achou que tinha comprado.

O que o benchmark deixa de fora

As exclusões são amplas o bastante para mudar o alcance do resultado. O APEX-Accounting deixa explicitamente de fora tributário, auditoria, consolidação, contabilidade multi-entidade e multimoeda, e reporte externo. Também exclui comportamento de pedir esclarecimento, o que significa que um modelo que na vida real faria uma pergunta sensata não ganha crédito por esse instinto aqui.

Essas estão entre as partes mais difíceis de um fechamento real. Os 2,6% de consistência vêm da metade mais simples do domínio.

Há uma segunda ressalva a carregar. O resultado companheiro do Ramp Harness é descrito pelos próprios autores como uma ablação de harness, com escopo limitado ao efeito do scaffolding e fora do produto Ramp Stack completo. Trate assim internamente, e evite que circule como benchmark de produto.

Repetibilidade é o número a governar

A pergunta de governança para qualquer agente que escreve num registro contábil se mede em execuções idênticas: quantas delas produzem saída idêntica e correta, e o que acontece nas que fogem disso. A média que ele marca fica em segundo plano.

Isso reenquadra várias coisas ao mesmo tempo. Teste de aceitação para agente financeiro deve ser de N execuções, com N escolhido para tornar a variância visível em vez de disfarçada. Alegação de fornecedor que cita média deve ser tratada como incompleta até a distribuição de consistência ser divulgada. E o passo de revisão humana precisa ser dimensionado pela consistência medida, porque um processo correto 56% das vezes na média e consistentemente correto 2,6% das vezes exige revisão artefato por artefato, fora de qualquer regime de amostragem.

É essa a textura operacional que o arco de governança além da engenharia continua trazendo à tona. Quando templates de fornecedor redigem artefatos regulados, o perímetro de aprovação se estende ao template. Quando esses templates são não determinísticos na taxa que este benchmark mede, o perímetro se estende a cada execução individual.

Faça isto agora

Escolha o fluxo contábil ou financeiro que você está mais perto de automatizar. Pegue cinco tarefas reais dele, rode cada uma oito vezes com o seu modelo e prompt atuais, e avalie as quarenta saídas contra os seus próprios critérios. Você passa a ter uma taxa de consistência da sua própria stack, que nenhum leaderboard entrega.

Depois, defina sua política de revisão a partir dessa taxa medida, deixando a média de benchmark de fora da conta. Se a consistência ficar abaixo de 25%, o agente é um redator de rascunho com revisão humana obrigatória linha a linha, e o dimensionamento de equipe precisa refletir isso. Se uma classe de tarefa nunca cai no balde consistente ao longo de oito execuções, ela segue manual até cair.

Por último, meça sua curva de gasto por modelo antes de escrever um teto de orçamento. Rode o mesmo conjunto de tarefas em dois ou três níveis de teto e veja onde a pontuação de cada modelo para de se mover. O número que maximiza a capacidade de um modelo pode ser seis vezes o que outro modelo precisa para chegar quase no mesmo resultado.

Nove modelos, oito execuções, 160 tarefas, e nenhum modelo de fronteira consegue fechar um mês ainda. Isso serve como especificação do que instrumentar enquanto você constrói.


Fontes

A Victorino ajuda líderes de finanças e operações a desenhar testes de aceitação de N execuções e política de orçamento por modelo antes de um agente tocar o razão: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa