Passer au contenu
cd /blog

Pourquoi nous avons fait évoluer la recherche de code vers voyage-4-large

[Embeddings][Recherche][Architecture]

> Nous avons migré nos embeddings de code vers voyage-4-large — actuellement en tête du classement public RTEB pour la récupération de code. La version honnête : le compromis que nous faisons, ce que nous indexons réellement, et pourquoi nous payons pour des embeddings premium.

Les chiffres de benchmark de cet article reflètent les classements RTEB au moment de la publication (juin 2026). Les classements évoluent ; considérez-les comme un instantané, pas comme un fait permanent.

Une recherche sémantique ne vaut que ce que valent les embeddings qui la sous-tendent.

Quand un agent demande à Maguyva « où gérons-nous les nouvelles tentatives », il ne grep-pe pas le mot « retry ». Il demande le sens — la boucle de backoff, le disjoncteur (circuit breaker), la chose qui enveloppe un appel instable. Cette question trouve sa réponse grâce à un modèle vectoriel qui transforme le code en un point dans l’espace et trouve ses voisins. Choisissez un meilleur modèle, et chaque requête sémantique du produit devient discrètement plus fine.

Nous avons donc changé le nôtre. Depuis juin 2026, les embeddings de code de Maguyva tournent sur voyage-4-large, en remplacement de voyage-code-3.

Le benchmark

Nous n’avons pas pris cette décision à l’instinct. Le Retrieval Embedding Benchmark (RTEB) public classe les modèles d’embedding sur de vraies tâches de récupération, et sur son classement Code, voyage-4-large se trouve 1er au classement global (90,86) — devant gemini-embedding-2-preview (90,26) et, notamment, devant le modèle que nous utilisions déjà, voyage-code-3 (89,73, 3e place).

C’est un petit écart en valeur absolue. Mais c’est un écart dans la bonne direction, sur un benchmark public, sur exactement la tâche qui nous intéresse : récupérer du code par le sens.

Le compromis que nous acceptons : la quantification binaire

Voici la partie que la plupart des articles « nous avons mis à niveau notre modèle » passent sous silence.

Maguyva ne stocke pas de vecteurs en pleine précision. Nous stockons des embeddings quantifiés en binaire : chaque vecteur à 2048 dimensions se réduit à une signature de 2048 bits — 256 octets par vecteur. Ces signatures sont recherchées par distance de Hamming, indexées et partitionnées par tenant.

C’est un compromis délibéré. La quantification binaire sacrifie un peu de précision de récupération en échange d’un stockage nettement plus petit et d’un calcul de distance rapide et peu coûteux, sans base de données vectorielle séparée à exploiter. Pour un produit qui indexe des dépôts entiers par espace de travail, cette économie compte plus que grappiller le dernier centième d’un point de benchmark.

voyage-4-large s’inscrit dans cette conception sans forcer une migration de la couche de stockage : il produit une sortie à 2048 dimensions, identique à voyage-code-3, donc nos colonnes bit(2048) et notre chemin de recherche par distance de Hamming n’ont pas changé. Le modèle s’est amélioré ; le schéma est resté en place.

Le code n’était qu’un début

Maguyva est un outil d’intelligence du code. Mais nous sommes aussi notre propre client zéro, et nous le pointons vers autre chose : le markdown qui vit dans nos dépôts aux côtés du code. Fiches de décision architecturale, runbooks, contrats, documents financiers et de politique — tout cela versionné dans Git, tout cela derrière le même serveur MCP, un index sémantique sur les documents, pas seulement sur la source.

C’est exactement pourquoi l’étendue de voyage-4-large compte. Sur la même famille de classements RTEB, il est 1er en finance, 1er en santé, et 1er en récupération de texte globale — devant Gemini Embedding de Google, Embed v4 de Cohere, et text-embedding-3-large d’OpenAI. (Voyage est co-créateur de RTEB, nous le lisons donc comme un signal public fort plutôt que comme un arbitre parfaitement neutre — mais il est comparé tête-à-tête à tous les grands modèles commerciaux, sur des jeux de données privés tenus en réserve.) Le même index qui trouve la bonne fonction pour un agent trouve la bonne clause dans un contrat, ou la bonne ligne dans une politique — et sur ces domaines, voyage-4-large n’est pas un compromis, c’est le leader.

Pourquoi nous payons pour des embeddings premium

Il existe une façon moins chère de faire de la recherche, et une bonne partie en est gratuite. La recherche lexicale — BM25 et ses cousins — fait correspondre des mots-clés, tourne localement, et ne coûte rien. Des modèles d’embedding open source comme BGE, Nomic et embeddinggemma offrent une récupération sémantique réellement correcte, et on peut les auto-héberger pour le prix d’un GPU. Maguyva utilise aussi le côté gratuit : chaque requête fusionne recherche textuelle, AST, graphe et sémantique. Ce sur quoi nous ne lésinons pas, c’est la couche sémantique.

Nous payons au token pour des embeddings premium — voyage-4-large — plutôt que d’auto-héberger un modèle gratuit, pour deux raisons. Premièrement, la recherche par mots-clés seule ne peut pas répondre à « où gérons-nous les nouvelles tentatives » quand le code dit backoff et circuit breaker sans jamais dire le mot « retry » — le sens est tout l’intérêt de l’embedding, et sur les domaines que nous servons, les modèles ouverts restent en retrait par rapport aux modèles premium : quelques points de retard sur le texte général, et davantage sur des niches comme le code, les contrats et la finance. Deuxièmement, d’après notre expérience, la qualité de la récupération façonne la réponse finale plus que ne le fait le modèle en bout de chaîne — un agent puissant à qui l’on donne le mauvais contexte répond quand même mal, et il ne voit jamais le document qu’on ne lui a jamais fourni.

Les embeddings premium représentent donc une facture au token qui grandit avec chaque dépôt et chaque document que nous indexons — et nous la payons délibérément. Pour le résultat obtenu par nos utilisateurs, la bonne fonction ou la bonne clause, nous pensons que ce compromis en vaut la peine.

La partie honnête

La documentation de Voyage elle-même désigne toujours voyage-code-3 comme le modèle optimisé pour le code. Alors pourquoi changer ?

Parce que nous lisons le benchmark public, pas seulement le tableau de modèles du fournisseur, et que le benchmark place voyage-4-large en tête pour la récupération de code. C’était un pari tourné vers l’avenir : prendre le modèle plus récent, généralement plus puissant, et le valider face à un classement public sur les tâches qui comptent. Nous sommes à l’aise avec ce pari, car les preuves sont larges — voyage-4-large ne gagne pas seulement sur le code, il mène aussi en finance, en santé et en récupération globale.

Le plancher discret

Chaque outil que nous exposons — recherche sémantique, collecte de contexte de tâche, questions-réponses ancrées dans le code — se ramène en dernière analyse à la récupération. Quand le moteur de récupération s’améliore, l’agent en bout de chaîne obtient de meilleures preuves, fait moins de faux pas, et ancre ses réponses dans le bon code — ou la bonne clause, ou la bonne politique. Un modèle d’embedding plus fin n’est pas une fonctionnalité tape-à-l’œil. C’est le plancher sous tout le reste, et nous venons de le relever. Vous ne le remarquerez pas. C’est bien le but.

Lectures associées

Encore plus du journal de bord Maguyva