Perché abbiamo aggiornato la ricerca sul codice a voyage-4-large

I numeri di benchmark in questo articolo riflettono le classifiche RTEB al momento della pubblicazione (giugno 2026). Le classifiche si muovono; considera i ranking come uno scatto istantaneo, non un fatto permanente.

La ricerca semantica vale solo quanto gli embedding che ha sotto.

Quando un agente chiede a Maguyva “dove gestiamo i retry”, non sta facendo grep della parola “retry”. Sta chiedendo il significato - il loop di backoff, il circuit breaker, la cosa che avvolge una chiamata instabile. A quella domanda risponde un modello vettoriale che trasforma il codice in un punto nello spazio e trova i vicini. Scegli un modello migliore e ogni query semantica nel prodotto diventa silenziosamente più precisa.

Quindi abbiamo cambiato il nostro. A partire da giugno 2026, gli embedding del codice di Maguyva girano su voyage-4-large, sostituendo voyage-code-3.

Il benchmark

Non abbiamo preso questa decisione a sensazione. Il pubblico Retrieval Embedding Benchmark (RTEB) classifica i modelli di embedding su task di retrieval reali, e sulla sua classifica Code voyage-4-large si trova al #1 assoluto (90,86) - davanti a gemini-embedding-2-preview (90,26) e, in modo significativo, davanti al modello che stavamo già usando, voyage-code-3 (89,73, #3).

È un piccolo divario assoluto. Ma è un divario nella direzione giusta, su un benchmark pubblico, esattamente sul task a cui teniamo: recuperare codice per significato.

Il compromesso che accettiamo: quantizzazione binaria

Ecco la parte che la maggior parte degli articoli “abbiamo aggiornato il nostro modello” tralascia.

Maguyva non archivia vettori a piena precisione. Archiviamo embedding quantizzati binariamente: ogni vettore a 2048 dimensioni collassa in una firma a 2048 bit - 256 byte per vettore. Quelle firme vengono cercate con la distanza di Hamming, indicizzate e partizionate per tenant.

È un compromesso deliberato. La quantizzazione binaria rinuncia a un po’ di precisione di retrieval in cambio di uno storage drasticamente più piccolo e di calcoli di distanza veloci ed economici senza dover gestire un database vettoriale separato. Per un prodotto che indicizza interi repository per workspace, quell’economia conta più che spremere l’ultima frazione di punto di benchmark.

voyage-4-large si adatta a questo design senza forzare una migrazione del layer di storage: produce un output a 2048 dimensioni, come voyage-code-3, quindi le nostre colonne bit(2048) e il percorso di ricerca Hamming non sono cambiati. Il modello è migliorato; lo schema è rimasto fermo.

Il codice era solo l’inizio

Maguyva è uno strumento di Code Intelligence. Ma siamo anche il cliente zero, e lo puntiamo anche su qualcos’altro: il markdown che vive nei nostri repository accanto al codice. Record di decisioni architetturali, runbook, contratti, documenti di finanza e policy - tutto versionato in Git, tutto dietro lo stesso server MCP, un indice semantico sui documenti, non solo sul codice sorgente.

Ecco esattamente perché conta l’ampiezza di voyage-4-large. Sulla stessa famiglia di classifiche RTEB è #1 in finanza, #1 in sanità, e #1 nel retrieval testuale complessivo - davanti a Gemini Embedding di Google, Embed v4 di Cohere, e text-embedding-3-large di OpenAI. (Voyage è co-creatore di RTEB, quindi lo leggiamo come un forte segnale pubblico piuttosto che come un arbitro perfettamente neutrale - ma viene confrontato testa a testa con ogni modello commerciale importante, su set di hold-out privati.) Lo stesso indice che trova la funzione giusta per un agente trova la clausola giusta in un contratto o la riga giusta in una policy - e su quei domini, voyage-4-large non è un compromesso, è il leader.

Perché paghiamo per embedding premium

C’è un modo più economico di fare ricerca, e gran parte è gratuita. La ricerca lessicale - BM25 e i suoi simili - fa il match delle parole chiave, gira localmente, e non costa nulla. I modelli di embedding open-source come BGE, Nomic, ed embeddinggemma offrono un retrieval semantico genuinamente decente, e puoi ospitarli tu stesso al prezzo di una GPU. Anche Maguyva usa il lato gratuito: ogni query fonde ricerca testuale, AST, a grafo, e semantica. Ciò su cui non risparmiamo è il layer semantico.

Paghiamo per token per embedding premium - voyage-4-large - invece di ospitare noi stessi un modello gratuito, per due motivi. Primo, la sola ricerca per parole chiave non può rispondere a “dove gestiamo i retry” quando il codice dice backoff e circuit breaker e non dice mai la parola “retry” - il significato è tutto il punto dell’embedding, e sui domini che serviamo i modelli open restano indietro rispetto a quelli premium: un paio di punti indietro sul testo generale, e ancora più indietro in nicchie come codice, contratti, e finanza. Secondo, nella nostra esperienza la qualità del retrieval plasma la risposta finale più di quanto faccia il modello dall’altra parte - un agente forte a cui viene dato il contesto sbagliato risponde comunque male, e non vede mai il documento che non gli è mai stato dato.

Quindi gli embedding premium sono una bolletta per token che scala con ogni repository e documento che indicizziamo - e la paghiamo di proposito. Per il risultato che ottengono i nostri utenti, la funzione giusta o la clausola giusta, pensiamo che quel compromesso valga la pena.

La parte onesta

La documentazione stessa di Voyage etichetta ancora voyage-code-3 come il modello ottimizzato per il codice. Allora perché passare al nuovo?

Perché leggiamo il benchmark pubblico, non solo la tabella dei modelli del vendor, e il benchmark ha messo voyage-4-large in cima per il retrieval di codice. Questa è stata una scommessa lungimirante: prendere il modello più nuovo e generalmente più forte e validarlo contro una classifica pubblica sui task che contano. Siamo a nostro agio a fare quella scommessa perché l’evidenza è ampia - voyage-4-large non vince solo sul codice, guida anche in finanza, sanità, e retrieval complessivo.

Il pavimento silenzioso

Ogni strumento che esponiamo - ricerca semantica, raccolta del task-context, domande e risposte fondate - alla fine si riduce al retrieval. Quando il retriever migliora, l’agente dall’altra parte ottiene prove migliori, fa meno svolte sbagliate, e ancora le sue risposte al codice giusto - o alla clausola giusta, o alla policy giusta. Un modello di embedding più preciso non è una feature vistosa. È il pavimento sotto tutto il resto, e lo abbiamo appena alzato. Non te ne accorgerai. Questo è il punto.