Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images

Sintesi Tecnica: Pixel per Programmi? Uno studio comparativo tra diversi provider sull'accounting dei token di input per codice sorgente come testo e immagini

Problematica
I contesti di codice sorgente molto lunghi spesso superano i limiti di token dei modelli linguistici, motivando proposte di rendere il codice sotto forma di immagini per i modelli vision-language (VLM). Mentre la ricerca recente indaga se i modelli siano in grado di risolvere compiti di codifica dopo questa trasformazione, rimane irrisolta una questione sistemistica critica: come i provider di API commerciali contabilizzano le richieste risultanti? In particolare, non è chiaro come l'accounting dei token di input cambi quando il codice viene trasmesso come testo grezzo rispetto a immagini renderizzate compatte, come questa relazione scala con la lunghezza della sorgente e se la "compressione visiva" offra una riduzione netta dei token riportati tra i diversi provider e gli alias dei modelli.

Metodologia
Lo studio impiega un protocollo di misurazione black-box riproducibile per confrontare l'accounting dei token di input tra tre principali provider: Anthropic, OpenAI e Google Vertex AI.

• Corpus: Il dataset consiste in cinque file sorgente con versione bloccata (Python, JavaScript, Rust, Go e Java) provenienti da importanti progetti open-source. Questi file sono suddivisi in nove prefissi nidificati che vanno da 20 a 2.000 righe.
• Trattamento (Immagine Compatta): Il braccio dell'immagine applica una trasformazione a due stadi:
  1. Compressione dell'indentazione: Gli spazi iniziali vengono sostituiti con marcatori compatti (ad es. > per indentazioni di 4 spazi, ^N per sequenze irregolari).
  2. Rendering: Il testo trasformato viene renderizzato come pagine PNG.
• Disegno Sperimentale: Per ogni dimensione della sorgente e linguaggio, vengono inviate richieste accoppiate a 15 alias di modelli disponibili (4 Anthropic, 6 OpenAI, 5 Gemini). Entrambi i bracci includono un'istruzione di riepilogo di una sola frase ("Riassumi cosa fa questo codice in una frase").
• Metriche: La metrica primaria è il rapporto tra i token di input immagine riportati dal provider ($I$) e i token di input testo ($T$). Lo studio riporta rapporti aggregati pesati (sommando tutti i token attraverso il dataset) e rapporti stratificati per dimensione per identificare i punti di pareggio (break-even).
• Vincoli: Lo studio isola esplicitamente l'accounting dei token dalla fedeltà semantica, l'accuratezza del compito, la latenza, il costo monetario o l'efficienza degli agenti di codifica. Non sostiene che i token immagine siano computazionalmente equivalenti ai token di testo.

Contributi Chiave

1. Artefatto Riproducibile: Un dataset di 1.350 chiamate API andate a buon fine e 675 coppie testo/immagine complete, inclusi i record di utilizzo grezzi, i validatori e gli script di analisi deterministici.
2. Misurazioni Stratificate per Dimensione: Evidenza empirica che la riduzione dei token non è uniforme; varia significativamente in base alla lunghezza della sorgente e al provider.
3. Audit della Modalità: Un'indagine mirata che rivela un comportamento non monotono nell'accounting delle immagini, specificamente ai confini delle pagine.
4. Confine di Validità: Una chiara demarcazione tra le metriche di conteggio dei token e la preservazione dell'informazione, evitando la confusione tra "meno token" e "migliore prestazione" o "costo inferiore".

Risultati

• Riduzioni Aggregate: Su tutto il benchmark, le immagini compatte ricevono significativamente meno token di input riportati rispetto al testo grezzo:
  • Anthropic: Rapporto 0,135 (riduzione dell'86,5%).
  • OpenAI: Rapporto 0,194 (riduzione dell'80,6%).
  • Gemini: Rapporto 0,242 (riduzione del 75,8%).
• Comportamento di Break-Even: I rapporti aggregati celano differenze critiche di scaling:
  • Anthropic e OpenAI: Gli input immagine ricevono conteggi di token inferiori rispetto al testo per ogni dimensione testata (da 20 a 2.000 righe).
  • Gemini: Le immagini comportano un enorme overhead per contesti brevi. A 20 righe, le immagini di Gemini richiedono 6,95 volte più token rispetto al testo. L'approccio con immagini diventa vantaggioso (scendendo sotto la parità) solo a 200 righe.
• Alias dei Modelli: All'interno dei provider, molti alias di modelli condividono firme di accounting identiche (ad es., tutti i sei modelli OpenAI nello studio hanno restituito rapporti aggregati identici), suggerendo regole di accounting interne condivise piuttosto che comportamenti indipendenti dei modelli.
• Non-Monotonicità: Un audit mirato di Gemini ha rivelato che i conteggi dei token immagine riportati possono cambiare in modo non monotono ai confini delle pagine. Ad esempio, aumentare la sorgente da 800 a 1.200 righe (aggiungendo una seconda pagina) ha causato una diminuzione dei token immagine riportati per un modello, contraddicendo l'aspettativa che i conteggi dei token scalino linearmente con il contenuto.

Significatività e Rivendicazioni
Il documento sostiene che, sebbene il rendering di immagini compatte possa ridurre drasticamente i token di input riportati per contesti lunghi, il beneficio è altamente condizionale:

1. Specificità del Provider: Non esiste un vantaggio universale di "compressione visiva". Provider come Gemini presentano alti costi fissi che rendono le immagini controproducenti per contesti brevi.
2. Implicazioni di Routing: Un harness di codifica non può fare affidamento su una politica globale di "inviare il codice come immagini". Inveve, la logica di routing deve essere calibrata per ogni provider e dimensione della sorgente, potenzialmente tornando al testo per contesti brevi o quando i confini delle pagine introducono discontinuità.
3. Limiti dei Conteggi dei Token: Lo studio sottolinea che una riduzione dei token riportati non implica un contenuto informativo equivalente, un costo monetario inferiore o una riduzione del calcolo. I marcatori di indentazione potrebbero essere decodificati erroneamente e la rasterizzazione potrebbe oscurare la punteggiatura o la struttura.
4. Lavoro Futuro: Gli autori posizionano questo studio come una "superficie di misurazione" su cui la ricerca futura può costruire. Argomentano che il passo successivo necessario è incrociare la rappresentazione con la qualità del compito (ad es., trascrizione esatta, localizzazione dei difetti) per determinare se il risparmio di token si traduca in effettiva utilità di codifica.

Il documento conclude che il codice renderizzato compatto è una strategia valida per l'accounting dei token in regimi specifici (contesti lunghi, provider specifici), ma richiede una calibrazione attenta e specifica per ogni provider e una ulteriore validazione riguardo alla fedeltà dell'informazione.