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

Canonical source: https://maguyva.ai/cs/blog/upgrading-code-search-to-voyage-4-large

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-06-09 · Author: Maguyva Team

> Přesunuli jsme naše embeddingy kódu na voyage-4-large — aktuálně na špici veřejného žebříčku RTEB pro retrieval kódu. Upřímná verze: kompromis, který děláme, co skutečně indexujeme a proč platíme za prémiové embeddingy.

> *Čí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, vzor circuit breaker, 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)](https://embedding-benchmark-rteb.hf.space/code) ř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í rozdíl. Ale je to rozdíl 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 zkomprimuje 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 code intelligence. Ale jsme také svým vlastním prvním zákazníkem 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 přímo srovnávaný v benchmarku 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í — porovnává klíčová slova, 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.

## Nenápadný základ

Každý nástroj, který vystavujeme — sémantické vyhledávání, sběr task-context, ukotvené odpovídání na otázky — v základu stojí na kvalitě vyhledávání. 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 základ všeho ostatního a ten jsme právě zlepšili. Nevšimnete si toho. To je ten záměr.