Custo no SWE-bench: como calcular o preço por incidência resolvida sem ocultar falhas, novas tentativas nem avaliação

O valor enganador: o preço por incidência resolvida não se explica por si só

Expressar o resultado de um agente como «custo por incidência resolvida» parece transformar uma avaliação técnica numa decisão económica simples. No entanto, esse valor é uma razão entre variáveis que podem ter sido definidas de formas muito diferentes. O numerador pode conter apenas os tokens de uma chamada final, ou todas as chamadas iniciadas ao longo de uma trajetória. O denominador pode ser o número de patches que passam o verificador, o número de incidências inicialmente selecionadas ou um resultado escolhido entre várias tentativas. Sem estas definições, dois valores iguais não descrevem necessariamente operações comparáveis.

A distinção é especialmente importante no SWE-bench. A tarefa parte de incidências reais associadas a repositórios e exige produzir uma alteração que possa ser verificada num ambiente preparado para esse efeito. O custo observável não se limita, portanto, a redigir um patch. Um sistema pode inspecionar ficheiros, pedir contexto adicional, executar ferramentas, reiniciar uma estratégia ou esgotar um limite sem gerar uma solução válida. Todos estes eventos podem consumir recursos, mesmo que a instância não seja contabilizada como resolvida.

A pergunta económica correta depende da decisão. Para orçamentar uma execução completa, interessa o custo médio por incidência tentada. Para avaliar o desempenho de um fluxo que só entrega alterações verificadas, pode interessar o custo total dividido pelos sucessos estritos. Para decidir se uma configuração mais cara compensa, a comparação relevante costuma ser o custo adicional por sucesso adicional face a uma linha de base. E, se forem autorizadas várias trajetórias e uma delas for conservada, é necessário medir o custo da política completa, não apenas o da trajetória selecionada.

Isto não significa que uma métrica resumida seja inútil. Significa que deve ser lida como a capa de uma ficha de custos. A ficha deve indicar a versão do conjunto, o subconjunto efetivamente executado, as exclusões, o número de tentativas, a regra de seleção, o protocolo de paragem, as categorias de consumo e que parte da infraestrutura de avaliação foi incluída. Sem estes elementos, o valor pode ser uma observação interna válida, mas não uma base suficiente para comparar agentes ou estimar uma automatização.

O que se paga durante uma execução

O primeiro componente é a inferência. Numa API, o registo de consumo deve separar tokens de entrada e de saída quando o fornecedor os fatura de forma distinta. Se a plataforma reportar entrada em cache ou tokens de raciocínio faturáveis, estas categorias também devem surgir separadamente. A documentação da OpenAI, aplicável apenas a sistemas que utilizem essa API, distingue estas categorias e assinala que pedir múltiplas completions consome tokens adicionais. Esta terminologia, nem a respetiva estrutura de preços, não deve ser extrapolada automaticamente para outros fornecedores.

O segundo componente são as chamadas auxiliares e as ferramentas. Um agente pode fazer pesquisas, resumir ficheiros, gerar testes, rever diffs ou pedir novas completions depois de executar comandos. Algumas ferramentas não têm um preço direto de API, mas aumentam o contexto das chamadas posteriores ou usam computação própria. Se uma ferramenta externa cobrar por utilização, deve constar como rubrica independente. Se não lhe for atribuído um custo monetário, devem pelo menos ser registados o número de invocações e os recursos consumidos, para que outra organização os possa avaliar com a sua própria tarifa.

O terceiro componente é a avaliação. O harness do SWE-bench prepara imagens Docker, aplica patches e executa testes com limites de tempo por instância. A sua documentação também contempla requisitos de CPU, memória, armazenamento e mecanismos de cache. Construir ou obter imagens, executar contentores e conservar artefactos pode representar um custo material, sobretudo em campanhas amplas, embora não seja custo de inferência. Misturá-lo sem discriminação impede perceber se uma melhoria vem do agente ou da infraestrutura; omiti-lo de um orçamento operacional pode subestimar a despesa real.

Convém ainda separar o custo amortizado do custo marginal. Preparar uma imagem partilhada para muitas instâncias não tem o mesmo custo por execução que reconstruí-la de raiz. Do mesmo modo, uma cache de resultados pode evitar trabalho posterior. Estas eficiências são legítimas se forem documentadas, mas não devem ser apresentadas como se cada incidência tivesse exigido a mesma despesa marginal. Uma ficha sólida oferece ambos os planos: o custo da campanha observada e as regras usadas para atribuir custos partilhados.

Quatro denominadores para quatro perguntas diferentes

A primeira métrica é o custo médio por incidência tentada: o custo total da campanha dividido por todas as incidências para as quais o protocolo foi iniciado. É a medida mais adequada para estimar a despesa de processar uma fila de trabalho semelhante, porque inclui sucessos, falhas, trajetórias inválidas e casos esgotados por limites. Deve ficar claro se uma incidência excluída antes de iniciar o agente faz parte do universo ou não. Uma exclusão posterior à execução não deve apagar o seu custo.

A segunda métrica é o custo por sucesso estrito: o custo total das trajetórias incluídas na política dividido pelo número de incidências cujo patch passa o processo de verificação definido. Descreve, em média, que despesa foi necessária para obter um resultado validado sob esse protocolo. Pode aumentar mesmo que o custo por tentativa diminua, quando a taxa de resolução cai; por isso, não deve ser publicada sem ambas as quantidades de base.

A terceira é o custo incremental de elevar a resolução. Se uma configuração B resolver mais incidências do que uma configuração A, calcula-se como a diferença de custo total entre B e A dividida pela diferença de sucessos. Esta razão responde a uma decisão marginal: quanto custa obter cada sucesso adicional com uma configuração mais ambiciosa. Só é interpretável se ambos os sistemas forem executados sobre o mesmo conjunto, com critérios de sucesso e recursos de avaliação equivalentes.

A quarta corresponde a políticas com várias tentativas por incidência. Se for permitido pass@k, novas tentativas ou seleção posterior, o custo deve somar as trajetórias geradas para cada incidência, incluindo as não escolhidas. Reportar o custo da melhor trajetória encontrada equivale a reportar um resultado condicional que não reproduz a despesa necessária para a encontrar. A publicação deve esclarecer se foi executada uma única trajetória por instância, várias trajetórias independentes ou uma árvore de decisões adaptativa.

O protocolo altera a fatura e o significado do resultado

Um limite de passos, tempo, chamadas ou orçamento monetário faz parte da intervenção avaliada. Aumentá-lo pode permitir que algumas incidências difíceis recebam mais exploração, mas também pode concentrar uma fração importante da despesa numa cauda longa de casos sem resolução. Por isso, além da média, convém publicar a mediana, os percentis e a distribuição por instância. Uma média baixa pode coexistir com poucos casos excecionalmente caros que sejam inaceitáveis em produção.

A política de paragem deve ser explícita. Uma execução pode ser interrompida ao obter um patch, ao não encontrar ficheiros relevantes, ao exceder um orçamento, depois de testes falharem ou ao atingir um número de iterações. Cada opção altera tanto o custo como a probabilidade de sucesso. As novas tentativas exigem a mesma precisão: deve indicar-se o que as ativa, se herdam contexto, se reutilizam cache e se as tentativas descartadas são contabilizadas. Chamar «uma tentativa» a uma sequência de reinícios internos pode ocultar uma diferença material de consumo.

Pass@1 e pass@k respondem a perguntas diferentes. Pass@1 aproxima-se do desempenho de uma única oportunidade sob uma configuração fixa. Pass@k descreve a possibilidade de pelo menos uma de várias oportunidades produzir um sucesso, mas não equivale ao custo de uma oportunidade. Quando há seleção posterior, deve documentar-se o sinal usado para selecionar, se a seleção consumiu modelo ou computação adicional e se teve acesso a resultados de testes. Uma seleção informada pelo verificador pode ser útil para investigação, mas não deve ser confundida com uma política disponível antes de verificar.

A comparação mais informativa costuma fixar restrições comuns: o mesmo conjunto de instâncias, o mesmo harness, os mesmos limites de avaliação e, quando o objetivo é económico, um orçamento máximo comparável por incidência. Depois, podem apresentar-se curvas de custo em função da resolução. Esta apresentação permite ver se o ganho de resolução aparece a um custo gradual ou depende de uma minoria de trajetórias muito caras. Também evita atribuir à qualidade do agente aquilo que pode resultar de lhe ter sido permitido gastar mais.

Inferência e avaliação: separá-las não significa ignorar nenhuma

Separar inferência e avaliação permite responder a duas perguntas que um único valor mistura. A primeira é quanto custa ao agente propor uma alteração. A segunda é quanto custa determinar se essa alteração passa o protocolo do benchmark. No SWE-bench, a avaliação exige aplicar a previsão e executar testes num ambiente de repositório. O harness documenta a preparação de imagens, a execução com contentores, limites temporais e opções de cache; por isso, tratar a verificação como uma operação gratuita seria metodologicamente incompleto.

A separação não obriga a escolher uma única convenção. Para investigação de modelos, pode ser razoável reportar primeiro o custo de inferência e, a seu lado, o custo de avaliação da campanha. Para planear um serviço de reparação automatizada, o custo total de propriedade é mais pertinente: inferência, orquestração, ferramentas, computação de testes, armazenamento e revisão humana quando esta fizer parte do fluxo. O essencial é não somar determinadas rubricas para um agente e omiti-las para outro.

Existe uma incerteza prática: os custos de infraestrutura dependem da região, do fornecedor, da capacidade reservada, da concorrência e da política de retenção. As fontes disponíveis descrevem componentes do harness, mas não estabelecem uma tarifa universal para os executar. Por isso, uma publicação rigorosa deve fornecer unidades físicas, como tempo de contentor e recursos atribuídos, além de qualquer conversão monetária local. Assim, outra organização pode recalcular o montante com os seus próprios contratos.

Os artefactos de experiências são essenciais para esta separação. O repositório de experiências do SWE-bench contempla previsões, registos de execução, rastos e resultados por instância. Partilhar ou resumir estes artefactos com uma estrutura consistente permite verificar que patches foram avaliados, detetar instâncias sem resultado e reconciliar os totais de custo com as trajetórias. A auditabilidade não exige revelar credenciais, prompts confidenciais ou dados protegidos; exige, sim, que as exclusões e agregações não impeçam a revisão da contabilidade.

A ficha mínima de publicação e a decisão operacional

A ficha deve começar pela identidade da experiência: variante e revisão do conjunto, número de instâncias elegíveis, tentadas e excluídas, juntamente com os motivos de exclusão. Isto é relevante porque o SWE-bench oferece várias variantes e a documentação do projeto identifica o SWE-bench Verified como um conjunto de 500 instâncias. Indicar apenas «SWE-bench» não basta para saber que população foi avaliada. Também devem ser conservados o identificador do harness, as imagens ou a configuração pertinente e as regras de verificação.

Em seguida, devem constar o modelo, fornecedor ou endpoint, a região se esta alterar o preço, a data de consulta dos preços e a moeda. A contabilidade deve mostrar tokens de entrada, saída, cache e raciocínio quando estas categorias existirem para o fornecedor utilizado, além das chamadas auxiliares. Deve incluir o limite por incidência, a política de paragem, as novas tentativas e o método de seleção. As médias devem ser acompanhadas por distribuição por instância e por contagens de trajetórias falhadas, esgotadas, inválidas ou não verificáveis.

A ficha termina com dois totais: inferência e avaliação. Para cada um, deve indicar que rubricas incorpora, o que exclui e como atribui os custos partilhados. Se for publicado um valor por sucesso, o total do numerador deve reconciliar-se com as rubricas anteriores e o denominador com os sucessos estritos observados. Se existirem várias amostras por instância, o custo reportado tem de ser o de gerar e escolher entre todas elas, e não o da amostra vencedora.

Para explorar modelos numa fase inicial, o custo por incidência tentada e uma curva de resolução sob orçamentos fixos costumam ser as métricas mais úteis. Para otimizar um agente, interessa acrescentar o custo incremental por sucesso adicional e a distribuição de casos caros. Para orçamentar a automatização, a referência é o custo total de propriedade por incidência recebida, incluindo verificação e a intervenção humana que o processo efetivamente exija. Nenhuma destas medidas substitui as restantes: cada uma responde a um risco diferente.

A conclusão prudente é que um agente não reduz necessariamente o custo de resolver incidências por obter uma taxa de resolução maior ou por mostrar um montante baixo associado aos seus sucessos. Pode deslocar a despesa para mais trajetórias, mais contexto, mais computação de testes ou uma seleção posterior. A comparação defensável declara esse deslocamento. Com uma ficha completa, uma equipa pode decidir se paga por mais sucessos, se limita a exposição a casos caros ou se adota uma configuração que oferece uma economia mais previsível.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.