O nosso banco A/B, em aberto. Meça-nos.

O que é medido, e como

• Dois braços, o mesmo pedido. A vai direto ao fornecedor, sem a camada; B passa pela camada com a sua configuração predefinida. Mesmo prompt, mesma amostragem, mesmo limite de saída.
• O custo é contado pelo fornecedor. Cada braço é avaliado a partir do usage que a API devolve em cada chamada, ao preço de tabela. A economia é 1 − custo(B) / custo(A) da mesma execução, não o que a camada diz de si mesma.
• Intervalos ao 95%. Cada harness calcula-os (reamostragem por famílias de perguntas, Wilson para as taxas de recusa). Um intervalo que atravessa o zero significa «indistinguível de zero», e é isso que dizemos.
• O pacote que se instala. O braço B executa a fonte da tag 0.4.31; o seu dist/index.js é idêntico byte a byte ao do tarball do npm (sha256 b52f99cacf9804ecd3153e56f26ec3adcdc2510d52a8446a369ecf914e0b5731).
• Sem atalhos. Cada harness vigia os hosts com que fala e traz um limite de gasto por modelo escrito no código. Um modelo que não pôde ser medido aparece como «não medido», com o motivo.

Quatro baterias, conjuntos de dados públicos, fixados

Economia medida por modelo

GSM8K, com um fluxo de requisições em que 30% são repetições exatas e 20% paráfrases. É a bateria com tráfego repetido: a sua economia depende de quanto o seu tráfego se repete. Sem repetições, veja «O que não economiza».

De onde vem a economia, posição por posição: «do cache exato» é o que A pagou nas requisições que a camada serviu sem chamar o fornecedor; «nas chamadas» é a diferença nas que realmente o alcançaram, sobretudo o cache de prefixo do fornecedor (mais alguma variação na saída). As duas somadas dão a economia total.

A precisão é medida sobre as perguntas com resposta publicada; as variantes com um número alterado servem apenas para verificar que a camada nunca entrega a resposta de outra pergunta.

Garantias, contadas

O que não economiza

Sem repetições, a economia é ≈ 0%. Publicamos mesmo assim, porque é o que você vai ver se o seu tráfego não se repetir.

O MT-Bench é um chat de dois turnos com uma camada nova a cada pergunta: não há nada que o cache possa reutilizar, e o prompt quase nunca atinge o mínimo que o fornecedor exige para fazer cache de um prefixo. No BFCL, cada chamada a ferramentas é diferente. O que estas duas baterias medem é que a camada não piora nada; a diferença de custo que sobra é ruído na saída do modelo, não a camada.

Estado por modelo e bateria

Cada célula mostra a execução na versão mais alta da camada. Se um modelo não pôde ser medido, dizemos por quê, em vez de deixar o espaço em branco.

Bugs que o banco encontrou

O banco não está aqui para ficar bem na fotografia: está aqui para encontrar os bugs antes de você. Encontrou estes, com a versão em que apareceram e a que os corrige.

1. O cache semântico sem calibração servia a resposta de outra pergunta 0.4.30 → 0.4.31

   Com o cache semântico sem calibração, uma variante com outro número («three baskets» versus «two baskets») podia receber a resposta da pergunta original. Contado sobre as variantes do GSM8K.

   • Encontrado na 0.4.30: 15 de 111. gsm8k.json
   • Corrigido na 0.4.31 (#383).
   • Verificado ao vivo na 0.4.31: 0 de 198.

2. A camada cortava o catálogo de ferramentas sem nenhum sinal para isso 0.4.30 → 0.4.31

   Em conversas de vários turnos, o braço B enviava menos ferramentas do que o A, mesmo sem nada indicar quais eram desnecessárias. Contado sobre as conversas multi-turno do BFCL.

   • Encontrado na 0.4.30: 20 de 20. bfcl.json
   • Corrigido na 0.4.31 (#382).
   • Verificado ao vivo na 0.4.31: 0 de 83.

3. Algumas recusas escritas como texto eram guardadas em cache 0.4.31 → 0.4.32

   Uma recusa que o modelo escreve como texto (sem o sinal da API) podia ser guardada em cache, repetida e creditada como economia. Contado em prompts do XSTest.

   • Encontrado na 0.4.31: 39 de 2.824. xstest-0431-claude.jsonxstest-0431-gama-alta.jsonxstest-0431.json
   • Corrigido na 0.4.32 (#393, #401).
   • Aguardando nova medição ao vivo na 0.4.32.

4. Um filtro de conteúdo do Gemini era guardado em cache como resposta 0.4.31 → 0.4.32

   O Gemini sinaliza o seu filtro com um motivo de parada próprio, que a camada não reconhecia como recusa, e por isso podia guardá-lo em cache e repeti-lo. Contado em prompts do XSTest.

   • Encontrado na 0.4.31: 6 de 508. xstest-0431-gama-alta.json
   • Corrigido na 0.4.32 (#402).
   • Aguardando nova medição ao vivo na 0.4.32.

5. O Gemini não passava pela camada 0.4.31 → 0.4.32

   A camada enviava um campo próprio da API da OpenAI para qualquer endpoint compatível, e o Gemini o rejeita: todas as requisições do braço B falhavam. Contado em requisições do GSM8K.

   • Encontrado na 0.4.31: 504 de 504. gsm8k-0431-gama-alta.json
   • Corrigido na 0.4.32 (#402).
   • Aguardando nova medição ao vivo na 0.4.32.

6. Com o Gemini 3, o segundo turno com ferramentas falhava 0.4.31 → 0.4.32

   A camada não devolvia a assinatura de pensamento que o Gemini 3 exige em cada chamada a ferramentas, e por isso o turno seguinte era rejeitado. Contado em continuações multi-turno do BFCL.

   • Encontrado na 0.4.31: 50 de 50. bfcl-0431-gama-alta.json
   • Corrigido na 0.4.32 (#402).
   • Aguardando nova medição ao vivo na 0.4.32.

Como reproduzir

O código do banco ainda não é público; o método é, e cabe em cinco passos. Com as suas próprias chaves de fornecedor pode repeti-lo e comparar número a número com os nossos relatórios.

1. O dataset. Descarregue cada dataset público no commit da tabela acima e verifique o sha256 de cada ficheiro antes de o usar. Se não bater certo, não é o mesmo dataset.
2. A camada. Instale @bivelio/savings-layer a partir do npm na versão indicada pelo relatório e verifique o sha256 de dist/index.js: cada relatório traz o seu.
3. Dois braços por prompt. A vai direto ao fornecedor; B envia o mesmo prompt, ao mesmo modelo e com o mesmo limite de saída, através da camada com a configuração padrão. Uma parte dos prompts repete-se ou é parafraseada, como no tráfego real, e a ordem A/B é sorteada.
4. O custo é o fornecedor que o diz. Some o que cada braço é faturado segundo o usage devolvido pelo fornecedor, à sua tarifa publicada. A poupança é 1 − custo B / custo A, com o seu intervalo.
5. A qualidade, na mesma execução. Pontue da mesma forma as respostas dos dois braços (resposta exata no GSM8K, chamada de ferramenta no BFCL, recusa ou não no XSTest, um juiz no MT-Bench) e compare-as com o relatório JSON da mesma bateria e versão.

Os relatórios

Cada execução deixa um relatório JSON com o seu desenho, as suas limitações e cada chamada medida: usage, custo por braço e classificação da resposta. São servidos a partir deste site.

Os relatórios são servidos tal como o banco os escreveu, com uma exceção: retiram-se os dados do ambiente de quem mediu (caminhos de disco, endereços de e-mail). Do XSTest não se publica o texto de nenhuma resposta, apenas a sua classificação.