Proč jsme upgradovali vyhledávání v kódu na voyage-4-large

Čísla benchmarků v tomto příspěvku odrážejí žebříčky RTEB v době zveřejnění (červen 2026). Žebříčky se hýbou; berte pořadí jako momentku, ne trvalý fakt.

Sémantické vyhledávání je jen tak dobré jako embeddingy pod ním.

Když se agent zeptá Maguyvy „kde řešíme retry“, negrepuje slovo „retry“. Ptá se na význam — smyčku s backoffem, jistič, tu věc, která obaluje nespolehlivé volání. Na tuhle otázku odpovídá vektorový model, který promění kód na bod v prostoru a najde sousedy. Vyberte lepší model a každý sémantický dotaz v produktu se tiše zostří.

Tak jsme svůj změnili. Od června 2026 běží embeddingy kódu v Maguyvě na voyage-4-large, který nahrazuje voyage-code-3.

Benchmark

Tohle rozhodnutí jsme neudělali na základě pocitu. Veřejný Retrieval Embedding Benchmark (RTEB) řadí embedding modely podle skutečných retrieval úloh a na svém žebříčku Code sedí voyage-4-large na 1. místě celkově (90,86) — před gemini-embedding-2-preview (90,26) a, což je pozoruhodné, před modelem, který jsme už používali, voyage-code-3 (89,73, 3. místo).

To je malá absolutní mezera. Ale je to mezera ve správném směru, na veřejném benchmarku, přesně na úloze, na které nám záleží: dohledávat kód podle významu.

Kompromis, který přijímáme: binární kvantizace

Tady je část, kterou většina příspěvků typu „upgradovali jsme náš model“ vynechává.

Maguyva neukládá vektory v plné přesnosti. Ukládáme binárně kvantizované embeddingy: každý 2048-dimenzionální vektor se zhroutí na 2048bitovou signaturu — 256 bajtů na vektor. Tyto signatury se prohledávají Hammingovou vzdáleností, indexované a rozdělené na partition podle tenanta.

To je záměrný kompromis. Binární kvantizace obětuje trochu přesnosti retrievalu výměnou za dramaticky menší úložiště a rychlou, levnou matematiku vzdálenosti bez nutnosti provozovat samostatnou vektorovou databázi. Pro produkt, který indexuje celé repozitáře na jeden pracovní prostor, na téhle ekonomice záleží víc než na vymáčknutí posledního zlomku bodu z benchmarku.

voyage-4-large do tohoto designu zapadá, aniž by si vynutil migraci vrstvy úložiště: produkuje 2048-dimenzionální výstup, stejně jako voyage-code-3, takže se naše sloupce bit(2048) a cesta Hammingova vyhledávání nezměnily. Model se zlepšil; schéma zůstalo na místě.

Kód byl jen začátek

Maguyva je nástroj pro inteligenci nad kódem. Ale jsme taky zákazník číslo jedna a míříme s ní i na něco jiného: na markdown, který v našich repozitářích žije vedle kódu. Záznamy architektonických rozhodnutí, runbooky, smlouvy, finanční a policy dokumenty — všechno verzované v Gitu, všechno za stejným MCP serverem, sémantický index nad dokumenty, ne jen nad zdrojovým kódem.

Přesně proto na šíři voyage-4-large záleží. Na stejné rodině žebříčků RTEB je 1. na financích, 1. ve zdravotnictví a 1. na celkovém textovém retrievalu — před Gemini Embedding od Googlu, Embed v4 od Cohere a text-embedding-3-large od OpenAI. (Voyage je spoluautorem RTEB, takže to čteme jako silný veřejný signál, ne jako dokonale neutrálního rozhodčího — ale je benchmarkovaný hlava na hlavu proti každému velkému komerčnímu modelu na privátních hold-out sadách.) Stejný index, který agentovi najde správnou funkci, najde i správnou klauzuli ve smlouvě nebo správný řádek v policy dokumentu — a v těchto doménách voyage-4-large není kompromis, je to lídr.

Proč platíme za prémiové embeddingy

Existuje levnější způsob, jak dělat vyhledávání, a velká část je zdarma. Lexikální vyhledávání — BM25 a jeho příbuzní — sedí na klíčových slovech, běží lokálně a nic nestojí. Open-source embedding modely jako BGE, Nomic a embeddinggemma dávají opravdu slušný sémantický retrieval a můžete si je hostovat sami za cenu GPU. Maguyva používá i tu bezplatnou stranu: každý dotaz fúzuje textové, AST, grafové a sémantické vyhledávání. Na čem nešetříme, je sémantická vrstva.

Za prémiové embeddingy — voyage-4-large — platíme za token místo toho, abychom si sami hostovali bezplatný model, ze dvou důvodů. Za prvé, samotné vyhledávání podle klíčových slov nedokáže odpovědět na „kde řešíme retry“, když kód říká backoff a circuit breaker a nikdy neřekne slovo „retry“ — význam je celý smysl embeddingu a v doménách, které obsluhujeme, otevřené modely za prémiovými zaostávají: pár bodů pozadu na obecném textu a ještě víc pozadu v nikách jako kód, smlouvy a finance. Za druhé, podle naší zkušenosti kvalita retrievalu tvaruje finální odpověď víc než model na druhém konci — silný agent, kterému dáte špatný kontext, pořád odpoví špatně, a nikdy neuvidí dokument, který nikdy nedostal.

Prémiové embeddingy jsou tedy účet za token, který roste s každým repozitářem a dokumentem, který indexujeme — a platíme ho záměrně. Pro výsledek, který naši uživatelé dostanou, správnou funkci nebo správnou klauzuli, si myslíme, že ten kompromis stojí za to.

Upřímná část

Vlastní dokumentace Voyage pořád označuje voyage-code-3 jako model optimalizovaný pro kód. Tak proč přejít?

Protože jsme si přečetli veřejný benchmark, ne jen tabulku modelů dodavatele, a benchmark postavil na první místo pro retrieval kódu voyage-4-large. Bylo to rozhodnutí s výhledem dopředu: vzít novější, obecně silnější model a ověřit ho proti veřejnému žebříčku na úlohách, na kterých záleží. Cítíme se s touhle sázkou dobře, protože důkazy jsou široké — voyage-4-large nevyhrává jen na kódu, vede i na financích, zdravotnictví a celkovém retrievalu.

Tichý strop

Každý nástroj, který vystavujeme — sémantické vyhledávání, sběr task-context, ukotvené odpovídání na otázky — se nakonec zlomí v retrievalu. Když se retriever zlepší, agent na druhém konci dostane lepší důkazy, udělá méně špatných odboček a ukotví své odpovědi ve správném kódu — nebo ve správné klauzuli, nebo ve správném policy dokumentu. Ostřejší embedding model není okázalá funkce. Je to podlaha pod vším ostatním, a my jsme ji právě zvedli. Nevšimnete si toho. To je ten záměr.