Il nostro banco di prova A/B, alla luce del sole. Misuraci.

Cosa si misura, e come

• Due bracci, la stessa richiesta. A va direttamente al fornitore, senza il livello; B passa attraverso il livello con la sua configurazione predefinita. Stesso prompt, stesso campionamento, stesso limite di output.
• Il costo lo conta il fornitore. Ogni braccio viene valutato in base all<code>usage</code> restituito dallAPI a ogni chiamata, al prezzo di listino. Il risparmio è 1 − costo(B) / costo(A) della stessa esecuzione, non ciò che il livello dice di sé stesso.
• Intervalli al 95%. Li calcola ciascun harness (ricampionamento per famiglie di domande, Wilson per i tassi di rifiuto). Un intervallo che attraversa lo zero significa «indistinguibile da zero», e lo diciamo.
• Il pacchetto che si installa. Il braccio B esegue il sorgente del tag 0.4.31; il suo dist/index.js è identico byte per byte a quello del tarball npm (sha256 b52f99cacf9804ecd3153e56f26ec3adcdc2510d52a8446a369ecf914e0b5731).
• Nessuna scorciatoia. Ogni harness sorveglia gli host con cui comunica e applica un limite di spesa per modello scritto nel codice. Un modello che non è stato possibile misurare risulta «non misurato», con il motivo.

Quattro batterie, dataset pubblici, fissati

Risparmio misurato per modello

GSM8K, con un flusso di richieste in cui 30% sono ripetizioni esatte e 20% parafrasi. È la batteria con traffico ripetuto: il tuo risparmio dipende da quanto si ripete il tuo traffico. Senza ripetizioni, vedi «Cosa non fa risparmiare».

Da dove viene il risparmio, posizione per posizione: «dalla cache esatta» è ciò che A ha pagato sulle richieste che il livello ha servito senza chiamare il fornitore; «nelle chiamate» è la differenza su quelle che invece lo hanno raggiunto, soprattutto la cache di prefisso del fornitore (più un po' di variazione nell'output). Le due voci sommate danno il risparmio totale.

L'accuratezza è misurata sulle domande con risposta pubblicata; le varianti con un numero cambiato servono solo a verificare che il livello non restituisca mai la risposta di un'altra domanda.

Garanzie, contate

Cosa non fa risparmiare

Senza ripetizioni, il risparmio è ≈ 0%. Lo pubblichiamo comunque, perché è ciò che vedrai se il tuo traffico non si ripete.

MT-Bench è una chat a due turni con un livello nuovo per ogni domanda: non c'è nulla che la cache possa riutilizzare, e il prompt quasi mai raggiunge il minimo richiesto dal fornitore per mettere in cache un prefisso. In BFCL ogni chiamata a strumenti è diversa. Ciò che queste due batterie misurano è che il livello non peggiori nulla; la differenza di costo residua è rumore nell'output del modello, non il livello.

Stato per modello e batteria

Ogni cella mostra l'esecuzione sulla versione più alta del livello. Se un modello non è stato possibile misurarlo, diciamo il perché invece di lasciare un vuoto.

Bug trovati dal banco di prova

Il banco di prova non c'è per fare bella figura: c'è per trovare i bug prima di te. Ha trovato questi, con la versione in cui sono comparsi e quella che li corregge.

1. La cache semantica non calibrata serviva la risposta di un'altra domanda 0.4.30 → 0.4.31

   Con la cache semantica non calibrata, una variante con un altro numero («three baskets» contro «two baskets») poteva ricevere la risposta della domanda originale. Contato sulle varianti di GSM8K.

   • Trovato nella 0.4.30: 15 su 111. gsm8k.json
   • Corretto nella 0.4.31 (#383).
   • Verificato dal vivo sulla 0.4.31: 0 su 198.

2. Il livello tagliava il catalogo di strumenti senza alcun segnale per farlo 0.4.30 → 0.4.31

   Nelle conversazioni multi-turno, il braccio B inviava meno strumenti del braccio A anche se nulla indicava quali fossero superflui. Contato sulle conversazioni multi-turno di BFCL.

   • Trovato nella 0.4.30: 20 su 20. bfcl.json
   • Corretto nella 0.4.31 (#382).
   • Verificato dal vivo sulla 0.4.31: 0 su 83.

3. Alcuni rifiuti scritti come testo venivano messi in cache 0.4.31 → 0.4.32

   Un rifiuto che il modello scrive come testo (senza il segnale dell'API) poteva essere messo in cache, ripetuto e accreditato come risparmio. Contato nei prompt di XSTest.

   • Trovato nella 0.4.31: 39 su 2824. xstest-0431-claude.jsonxstest-0431-gama-alta.jsonxstest-0431.json
   • Corretto nella 0.4.32 (#393, #401).
   • In attesa di essere rimisurato dal vivo sulla 0.4.32.

4. Un filtro di contenuto di Gemini veniva messo in cache come risposta 0.4.31 → 0.4.32

   Gemini segnala il suo filtro con un proprio motivo di arresto, che il livello non riconosceva come rifiuto, così poteva metterlo in cache e ripeterlo. Contato nei prompt di XSTest.

   • Trovato nella 0.4.31: 6 su 508. xstest-0431-gama-alta.json
   • Corretto nella 0.4.32 (#402).
   • In attesa di essere rimisurato dal vivo sulla 0.4.32.

5. Gemini non passava dal livello 0.4.31 → 0.4.32

   Il livello inviava un campo specifico dell'API di OpenAI a qualsiasi endpoint compatibile, e Gemini lo rifiuta: tutte le richieste del braccio B fallivano. Contato nelle richieste di GSM8K.

   • Trovato nella 0.4.31: 504 su 504. gsm8k-0431-gama-alta.json
   • Corretto nella 0.4.32 (#402).
   • In attesa di essere rimisurato dal vivo sulla 0.4.32.

6. Con Gemini 3, il secondo turno con strumenti falliva 0.4.31 → 0.4.32

   Il livello non restituiva la firma di pensiero che Gemini 3 richiede a ogni chiamata a strumenti, così il turno successivo veniva rifiutato. Contato nelle continuazioni multi-turno di BFCL.

   • Trovato nella 0.4.31: 50 su 50. bfcl-0431-gama-alta.json
   • Corretto nella 0.4.32 (#402).
   • In attesa di essere rimisurato dal vivo sulla 0.4.32.

Come riprodurlo

Il codice del banco di prova non è ancora pubblico; il metodo sì, e sta in cinque passi. Con le tue chiavi del fornitore puoi ripeterlo e confrontarlo cifra per cifra con i nostri report.

1. Il dataset. Scarica ogni dataset pubblico al commit della tabella qui sopra e controlla lo sha256 di ogni file prima di usarlo. Se non corrisponde, non è lo stesso dataset.
2. Il livello. Installa @bivelio/savings-layer da npm nella versione indicata dal report e controlla lo sha256 di dist/index.js: ogni report riporta il suo.
3. Due bracci per prompt. A va diretto al fornitore; B invia lo stesso prompt, allo stesso modello e con lo stesso limite di output, attraverso il livello con la configurazione predefinita. Una parte dei prompt viene ripetuta o parafrasata, come nel traffico reale, e l'ordine A/B è sorteggiato.
4. Il costo lo dice il fornitore. Somma quanto viene fatturato a ogni braccio secondo lo usage restituito dal fornitore, alla sua tariffa pubblicata. Il risparmio è 1 − costo B / costo A, con il suo intervallo.
5. La qualità, nella stessa esecuzione. Valuta allo stesso modo le risposte dei due bracci (risposta esatta in GSM8K, chiamata di strumento in BFCL, rifiuto o no in XSTest, un giudice in MT-Bench) e confrontale con il report JSON della stessa batteria e versione.

I report

Ogni esecuzione lascia un report JSON con il suo disegno, i suoi limiti e ogni chiamata misurata: usage, costo per braccio e classificazione della risposta. Sono serviti da questo sito.

I report sono serviti così come il banco li ha scritti, con un'eccezione: si tolgono i dati sull'ambiente di chi ha misurato (percorsi su disco, indirizzi email). Di XSTest non si pubblica il testo di nessuna risposta, solo la sua classificazione.