Um Harness Levou o Modelo Barato de 3 Para 10 Builds Aceitos. O Modelo de Fronteira Ficou em 10.

TV
Thiago Victorino
6 min de leitura
Um Harness Levou o Modelo Barato de 3 Para 10 Builds Aceitos. O Modelo de Fronteira Ficou em 10.

O GPT-6 Luna, executado sem harness, entregou 3 builds aceitáveis em 10. Com um harness comportamental em volta, o mesmo modelo entregou 10 em 10. O GPT-6 Sol, o modelo mais forte, foi aceito nas 10 execuções com harness e nas 10 sem ele.

Os números vêm de Are Harnesses Worth the Cost?, de Naresh Jain, publicado no martinfowler.com. O desenho do experimento é estreito e declarado sem rodeios: 10 execuções pareadas por modelo em um único serviço Java greenfield, com os dois modelos em baixo esforço de raciocínio. Um build contava como aceitável quando subia com sucesso e passava em todos os 178 testes de aceitação externos.

O achado que nos interessa está na coluna de custo. Uma tentativa do Luna com harness custou cerca de US$ 0,273. Uma tentativa do Sol sem harness custou cerca de US$ 0,406. Jain calcula que a tentativa do Luna com harness saiu cerca de 33% mais barata, e restringe a conclusão a “nesta amostra”.

As quatro linhas

A tabela completa, com médias de 10 execuções por condição:

CondiçãoTokensTempoCusto est.Aceitos
Sol, com harness11.331.97019 min 53 s~US$ 2,67910 de 10
Sol, sem harness1.076.3716 min 51 s~US$ 0,40610 de 10
Luna, com harness22.933.64835 min~US$ 0,27310 de 10
Luna, sem harness5.860.73615 min 56 s~US$ 0,0863 de 10

Para o Sol, o harness não melhorou a aceitação. Jain resume: o harness usou cerca de 10,5 vezes mais tokens, levou quase 3 vezes mais tempo e custou cerca de 7 vezes mais, e as duas condições tiveram sucesso nas 10 execuções.

Para o Luna, o harness acrescentou em média 17.072.912 tokens, 19 minutos e 4 segundos de execução autônoma e cerca de US$ 0,187 de custo estimado equivalente de API por tentativa. Esse gasto levou a contagem de aceitos de 3 para 10.

O mesmo harness teve dois efeitos muito diferentes. No modelo forte, foi custo extra sem retorno nesta amostra. No modelo fraco, separou um resultado utilizável de uma aposta com chance contra você.

As execuções que falharam chegaram perto

Um detalhe muda a leitura dos 3 em 10. Jain relata que as execuções do Luna sem harness passaram em 94,8% das verificações funcionais. As que falharam ainda passaram em pelo menos 144 dos 178 testes.

Um build do Luna sem harness que falha está quase todo certo. Esse é o tipo caro de falha. Um build que quebra na inicialização se denuncia sozinho. Um build que passa em 144 de 178 testes de aceitação parece pronto até alguém rodar os outros 34. Com o harness, as 10 execuções do Luna passaram nos 178.

Isso conversa com o que escrevemos quando a Builder.io atribuiu seus saltos à verificação: a checagem define o que um modelo menor pode assumir. Os dados de Jain acrescentam o que aquele caso isolado não tinha, uma comparação pareada entre dois modelos sob o mesmo portão.

Custo por resultado aceito

Custo por tentativa é o número óbvio a tirar dessa tabela, e aqui ele engana. A unidade útil é o custo por resultado aceito.

Considerando apenas o custo equivalente de API, a conta a partir da tabela de Jain fica mais ou menos assim:

  • Sol sem harness: cerca de US$ 0,406 por build aceito, já que toda tentativa foi aceita.
  • Luna com harness: cerca de US$ 0,273 por build aceito, pelo mesmo motivo.
  • Luna sem harness: cerca de US$ 0,86 gastos em 10 tentativas para 3 builds aceitos, ou seja, aproximadamente US$ 0,29 por build aceito.
  • Sol com harness: cerca de US$ 2,679 por build aceito.

A terceira linha parece competitiva em computação. Ela esconde os sete builds inaceitáveis, cada um dos quais alguém precisa encontrar, diagnosticar e consertar. Os números de Jain excluem esse trabalho de conserto. Também excluem o esforço de construir e manter o harness, então as linhas com harness carregam a própria conta sem preço. A diferença é que a linha do Luna sem harness parece competitiva enquanto esconde sete falhas.

Aqui entra a proposta de Michael Cutler em How to Measure the Human Cost of Agent Work. Ele define duas razões: minutos humanos por tarefa aceita, igual a todos os minutos humanos da coorte divididos pelas tarefas aceitas, e gasto do agente por tarefa aceita, calculado do mesmo jeito. As duas dividem por tarefas aceitas. A tabela de Jain entrega a segunda razão. O registro de Cutler pede que você meça a primeira, e ele avisa que uma revisão não registrada continua tendo duração.

Juntando as duas, a decisão sobre um harness deixa de ser debate de gosto técnico e vira medição: gasto do agente mais minutos humanos, divididos pelos resultados que alguém aceitou.

O que a amostra não diz

Jain é cuidadoso com as próprias conclusões, e as ressalvas fazem parte de qualquer leitura da tabela.

Os custos são estimativas equivalentes de API, baseadas no uso registrado de tokens e no preço dos modelos, e não são o valor efetivamente cobrado. Eles excluem o esforço inicial de escrever, revisar e manter os contratos, exemplos, asserções e o próprio harness. Também deixam de fora o esforço de encontrar, diagnosticar e consertar um resultado inaceitável. Nas palavras dele, uma amostra pequena não consegue dizer a taxa de falha de longo prazo nem o custo total de chegar a uma aplicação aceitável.

Há mais a pesar. O experimento cobre um serviço Java, 10 execuções por modelo e apenas baixo esforço de raciocínio. Jain descreve o enunciado como um ponto de partida favorável para um agente sem ajuda, então um trabalho mais difícil pode aumentar ou reduzir a diferença. Ele fundou a Specmatic, a ferramenta que construiu o harness, e declara que usou IA generativa para pesquisar o tema e construir partes do harness. Nada disso invalida a tabela. Significa que o resultado é uma amostra bem documentada, vinda de uma parte interessada, e que você deve tratá-la como hipótese a testar no seu próprio trabalho.

O texto de Cutler traz o próprio rótulo: ele se apresenta como um método proposto e avisa que ainda não relata um experimento concluído. Os números de exemplo são sintéticos, por isso citamos apenas o método.

A linha do Luna com harness também tem um preço que não aparece em dólares. Ela usou cerca de 21 vezes os tokens do Sol sem harness e levou cerca de 5 vezes mais tempo. Se o tempo até o resultado pesa mais para você do que o gasto de API, a linha mais barata pode continuar sendo a escolha errada.

O portão fica quando o modelo melhora

O harness não trouxe ganho de aceitação ao Sol nesta amostra. A conclusão tentadora é que modelos fortes dispensam portões. Jain a rejeita. Para ele, a capacidade do modelo muda quando e com que frequência os sensores rodam, e a necessidade de um portão de verificação independente continua.

Isso bate com a leitura que fizemos sobre trabalho agêntico regulado e sobre governar o harness. Um modelo mais forte permite rodar as checagens com menos frequência ou mais tarde no ciclo. Ninguém checando continua sem justificativa. O Sol passar em 10 de 10 sozinho nesta amostra nada diz sobre a execução 11, e foram os 178 testes de aceitação que mostraram que o Sol passou.

Na prática, o harness é algo que se ajusta por modelo. Com um modelo forte, talvez baste rodar o portão completo uma vez no final. Com um modelo mais barato, os sensores rodam ao longo do trabalho e o modelo itera contra eles. O portão é o mesmo. A cadência muda.

Faça isso agora

Escolha uma tarefa recorrente de agente que seu time já executa. Conte, no último mês, quantas saídas foram aceitas e quantas voltaram ou foram reescritas. Registre o gasto do agente e, com honestidade, os minutos humanos gastos revisando e consertando, usando as duas razões de Cutler.

Depois rode o modelo mais barato que você vem evitando pelo portão de verificação mais forte que conseguir construir para essa tarefa, em um lote pareado pequeno. Compare o custo por resultado aceito, incluindo minutos humanos e tempo até o resultado. Se o modelo barato com portão vencer nos seus números, você achou uma alavanca de custo. Se perder, você tem um motivo medido para continuar pagando pelo modelo de fronteira.


Fontes

A Victorino ajuda times de engenharia a construir os portões de verificação e os registros de custo que mostram qual modelo cada tarefa realmente exige: 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