Waarom we code search hebben geüpgraded naar voyage-4-large

Benchmarkcijfers in deze post weerspiegelen de RTEB-leaderboards op het moment van publicatie (juni 2026). Leaderboards veranderen; behandel de ranglijsten als een momentopname, geen permanent feit.

Semantisch zoeken is slechts zo goed als de embeddings eronder.

Wanneer een agent Maguyva vraagt “where do we handle retries”, grept hij niet naar het woord “retry”. Hij vraagt naar de betekenis — de backoff-lus, de circuit breaker, het ding dat een onbetrouwbare call omhult. Die vraag wordt beantwoord door een vectormodel dat code omzet in een punt in de ruimte en de buren vindt. Kies een beter model en elke semantische query in het product wordt in stilte scherper.

Dus veranderden we het onze. Sinds juni 2026 draaien de code-embeddings van Maguyva op voyage-4-large, ter vervanging van voyage-code-3.

De benchmark

We hebben deze beslissing niet op gevoel genomen. De publieke Retrieval Embedding Benchmark (RTEB) rangschikt embeddingmodellen op echte retrievaltaken, en op het Code-leaderboard staat voyage-4-large op #1 overall (90,86) — vóór gemini-embedding-2-preview (90,26) en, opvallend genoeg, vóór het model dat we al gebruikten, voyage-code-3 (89,73, #3).

Dat is een klein absoluut verschil. Maar het is een verschil in de juiste richting, op een publieke benchmark, op precies de taak waar het ons om gaat: code ophalen op betekenis.

De afweging die we accepteren: binary quantization

Dit is het deel dat de meeste “we hebben ons model geüpgraded”-posts weglaten.

Maguyva slaat geen full-precision vectoren op. We slaan binary-quantized embeddings op: elke 2048-dimensionale vector wordt gereduceerd tot een 2048-bit-signature — 256 bytes per vector. Die signatures worden doorzocht met Hamming-afstand, geïndexeerd en gepartitioneerd per tenant.

Dat is een bewuste afweging. Binary quantization levert wat retrievalprecisie in, in ruil voor drastisch kleinere opslag en snelle, goedkope afstandswiskunde zonder een aparte vectordatabase om te beheren. Voor een product dat hele repositories per workspace indexeert, weegt die economie zwaarder dan het laatste fractie benchmarkpunt eruit persen.

voyage-4-large past in dit ontwerp zonder een migratie van de opslaglaag te forceren: het produceert 2048-dimensionale output, net als voyage-code-3, dus onze bit(2048)-kolommen en Hamming-zoekpad zijn niet veranderd. Het model werd beter; het schema bleef staan.

Code was slechts het begin

Maguyva is een code-intelligence-tool. Maar we zijn ook customer zero, en we richten het ook op iets anders: de markdown die in onze repo’s naast de code leeft. Architecture decision records, runbooks, contracten, finance- en policydocumenten — allemaal onder versiebeheer in Git, allemaal achter dezelfde MCP-server, een semantische index over de documenten, niet alleen de bron.

Dat is precies waarom de breedte van voyage-4-large ertoe doet. Op dezelfde familie van RTEB-leaderboards staat het #1 op finance, #1 op healthcare, en #1 op overall text retrieval — vóór Google’s Gemini Embedding, Cohere’s Embed v4, en OpenAI’s text-embedding-3-large. (Voyage is een medeoprichter van RTEB, dus we lezen het als een sterk publiek signaal in plaats van een volstrekt neutrale scheidsrechter — maar het wordt kop-aan-kop gebenchmarkt tegen elk groot commercieel model, op private hold-out-sets.) Dezelfde index die de juiste functie vindt voor een agent, vindt de juiste clausule in een contract of de juiste regel in een policy — en op die domeinen is voyage-4-large geen compromis, het is de koploper.

Waarom we betalen voor premium embeddings

Er is een goedkopere manier om te zoeken, en veel daarvan is gratis. Lexicaal zoeken — BM25 en zijn verwanten — matcht keywords, draait lokaal, en kost niets. Open-source-embeddingmodellen zoals BGE, Nomic en embeddinggemma leveren écht behoorlijke semantische retrieval, en je kunt ze self-hosten voor de prijs van een GPU. Maguyva gebruikt de gratis kant ook: elke query voegt tekst-, AST-, graaf- en semantisch zoeken samen. Waar we niet op beknibbelen, is de semantische laag.

We betalen per token voor premium embeddings — voyage-4-large — in plaats van een gratis model self-hosten, om twee redenen. Ten eerste kan keywordzoeken alleen niet antwoorden op “where do we handle retries” wanneer de code backoff en circuit breaker zegt en nooit het woord “retry” gebruikt — betekenis is het hele punt van de embedding, en op de domeinen die we bedienen lopen de open modellen achter op de premium modellen: een paar punten achter op algemene tekst, en verder achter in niches zoals code, contracten en finance. Ten tweede bepaalt retrievalkwaliteit in onze ervaring het uiteindelijke antwoord meer dan het model aan de andere kant — een sterke agent die de verkeerde context krijgt, antwoordt nog altijd fout, en hij ziet nooit het document dat hem nooit werd gegeven.

Premium embeddings zijn dus een per-token-rekening die meeschaalt met elke repo en elk document dat we indexeren — en we betalen die met opzet. Voor het resultaat dat onze gebruikers krijgen, de juiste functie of de juiste clausule, denken we dat die afweging het waard is.

Het eerlijke deel

Voyage’s eigen documentatie noemt voyage-code-3 nog altijd het code-geoptimaliseerde model. Waarom dan overstappen?

Omdat we de publieke benchmark lezen, niet alleen de modeltabel van de vendor, en de benchmark zette voyage-4-large bovenaan voor code-retrieval. Dit was een toekomstgerichte beslissing: het nieuwere, over het algemeen sterkere model nemen en het valideren tegen een publiek leaderboard op de taken die ertoe doen. We voelen ons comfortabel bij die weddenschap omdat het bewijs breed is — voyage-4-large wint niet alleen op code, het leidt ook op finance, healthcare en overall retrieval.

De stille bodem

Elke tool die we blootstellen — semantisch zoeken, task-context gathering, onderbouwde Q&A — komt uiteindelijk neer op retrieval. Wanneer de retriever verbetert, krijgt de agent aan de andere kant beter bewijs, maakt hij minder verkeerde afslagen, en verankert hij zijn antwoorden in de juiste code — of de juiste clausule, of de juiste policy. Een scherper embeddingmodel is geen opzichtige feature. Het is de bodem onder al het andere, en die hebben we net verhoogd. Je zult het niet merken. Dat is precies het punt.