Varför vi uppgraderade kodsökningen till voyage-4-large

Benchmarksiffrorna i det här inlägget speglar RTEB-topplistorna vid publicering (juni 2026). Topplistor rör sig; behandla rankningarna som ett ögonblicksutsnitt, inte ett permanent faktum.

Semantisk sökning är bara så bra som inbäddningarna under den.

När en agent frågar Maguyva “var hanterar vi återförsök” grepar den inte efter ordet “retry”. Den frågar efter meningen — backoff-loopen, circuit breakern, det som omsluter ett flakigt anrop. Den frågan besvaras av en vektormodell som förvandlar kod till en punkt i rymden och hittar grannarna. Väljer man en bättre modell blir varje semantisk sökfråga i produkten tyst skarpare.

Så vi bytte vår. Från och med juni 2026 körs Maguyvas kodinbäddningar på voyage-4-large, som ersätter voyage-code-3.

Benchmarket

Vi tog inte det här beslutet på känn. Den offentliga Retrieval Embedding Benchmark (RTEB) rankar inbäddningsmodeller på verkliga hämtningsuppgifter, och på dess Code-topplista ligger voyage-4-large på förstaplats totalt (90,86) — före gemini-embedding-2-preview (90,26) och, anmärkningsvärt, före modellen vi redan använde, voyage-code-3 (89,73, plats 3).

Det är ett litet absolut gap. Men det är ett gap åt rätt håll, på ett offentligt benchmark, på exakt den uppgift vi bryr oss om: att hämta kod efter mening.

Avvägningen vi accepterar: binär kvantisering

Här är delen de flesta “vi uppgraderade vår modell”-inlägg utelämnar.

Maguyva lagrar inte fullprecisionsvektorer. Vi lagrar binärt kvantiserade inbäddningar: varje 2048-dimensionell vektor komprimeras till en 2048-bitars signatur — 256 byte per vektor. De signaturerna söks med Hamming-avstånd, indexerade och partitionerade per tenant.

Det är en avsiktlig avvägning. Binär kvantisering ger upp viss hämtningsprecision i utbyte mot dramatiskt mindre lagring och snabb, billig avståndsmatematik utan en separat vektordatabas att driva. För en produkt som indexerar hela repositorier per arbetsyta väger den ekonomin tyngre än att pressa ut den sista bråkdelen av en benchmarkpoäng.

voyage-4-large passar den här designen utan att tvinga fram en migrering av lagringslagret: den producerar 2048-dimensionell utdata, precis som voyage-code-3, så våra bit(2048)-kolumner och Hamming-sökvägen ändrades inte. Modellen blev bättre; schemat stod kvar.

Kod var bara början

Maguyva är ett kodintelligensverktyg. Men vi är också kund noll, och vi riktar det mot något annat: markdownen som lever i våra repon vid sidan av koden. Arkitekturbeslutsregister, runbooks, kontrakt, finans- och policydokument — allt versionshanterat i Git, allt bakom samma MCP-server, ett semantiskt index över dokumenten, inte bara källkoden.

Det är exakt därför voyage-4-larges bredd spelar roll. På samma RTEB-familj av topplistor ligger den på förstaplats inom finans, förstaplats inom sjukvård, och förstaplats i övergripande texthämtning — före Googles Gemini Embedding, Coheres Embed v4, och OpenAIs text-embedding-3-large. (Voyage är en av skaparna av RTEB, så vi läser det som en stark offentlig signal snarare än en helt neutral domare — men den benchmarkas huvud mot huvud mot alla stora kommersiella modeller, på privata hold-out-set.) Samma index som hittar rätt funktion åt en agent hittar rätt klausul i ett kontrakt eller rätt rad i en policy — och på de domänerna är voyage-4-large inte en kompromiss, det är ledaren.

Varför vi betalar för premiuminbäddningar

Det finns ett billigare sätt att göra sökning på, och mycket av det är gratis. Lexikal sökning — BM25 och dess släktingar — matchar nyckelord, körs lokalt och kostar ingenting. Öppna inbäddningsmodeller som BGE, Nomic och embeddinggemma ger genuint hyggig semantisk hämtning, och man kan self-hosta dem för priset av en GPU. Maguyva använder den gratis sidan också: varje sökfråga slår ihop text-, AST-, graf- och semantisk sökning. Det vi inte snålar på är det semantiska lagret.

Vi betalar per token för premiuminbäddningar — voyage-4-large — istället för att self-hosta en gratis modell, av två skäl. För det första kan nyckelordssökning ensam inte besvara “var hanterar vi återförsök” när koden säger backoff och circuit breaker och aldrig säger ordet “retry” — mening är hela poängen med inbäddningen, och på de domäner vi betjänar ligger de öppna modellerna efter premiummodellerna: några poäng efter på allmän text, och längre efter inom nischer som kod, kontrakt och finans. För det andra formar hämtningskvaliteten enligt vår erfarenhet det slutgiltiga svaret mer än modellen i andra änden gör — en stark agent som får fel kontext svarar ändå fel, och den ser aldrig dokumentet den aldrig fick.

Så premiuminbäddningar är en per-token-räkning som skalar med varje repo och dokument vi indexerar — och vi betalar den med flit. För resultatet våra användare får, rätt funktion eller rätt klausul, tycker vi att den avvägningen är värd det.

Den ärliga delen

Voyages egen dokumentation märker fortfarande voyage-code-3 som den kodoptimerade modellen. Så varför byta?

Eftersom vi läser det offentliga benchmarket, inte bara leverantörens modelltabell, och benchmarket satte voyage-4-large i topp för kodhämtning. Det här var ett framåtblickande beslut: ta den nyare, generellt starkare modellen och validera den mot en offentlig topplista på de uppgifter som spelar roll. Vi känner oss trygga med den satsningen eftersom beviset är brett — voyage-4-large vinner inte bara inom kod, den leder inom finans, sjukvård och övergripande hämtning också.

Det tysta golvet

Varje verktyg vi exponerar — semantisk sökning, task-context-insamling, grundade frågor och svar — urbottnas i hämtning. När hämtaren förbättras får agenten i andra änden bättre bevis, gör färre fel svängar, och förankrar sina svar i rätt kod — eller rätt klausul, eller rätt policy. En skarpare inbäddningsmodell är inte en flashig funktion. Det är golvet under allt annat, och vi höjde det just. Du kommer inte märka det. Det är poängen.