Чому ми оновили пошук коду до voyage-4-large

Числа бенчмарків у цьому дописі відображають рейтинги RTEB на момент публікації (червень 2026). Рейтинги змінюються; сприймайте позиції як знімок моменту, а не постійний факт.

Семантичний пошук настільки хороший, наскільки хороші ембеддинги під ним.

Коли агент запитує Maguyva «де ми обробляємо повторні спроби», він не грепає слово «retry». Він запитує сенс — цикл backoff, запобіжник (circuit breaker), те, що обгортає ненадійний виклик. На це запитання відповідає векторна модель, що перетворює код на точку в просторі й знаходить сусідів. Оберіть кращу модель, і кожен семантичний запит у продукті тихо стає точнішим.

Тож ми змінили нашу. Станом на червень 2026 року ембеддинги коду Maguyva працюють на voyage-4-large, замінивши voyage-code-3.

Бенчмарк

Ми не ухвалювали це рішення на відчуттях. Публічний Retrieval Embedding Benchmark (RTEB) ранжує моделі ембеддингів на реальних задачах пошуку, і в його рейтингу Code voyage-4-large посідає #1 загалом (90.86) — попереду gemini-embedding-2-preview (90.26) і, що важливо, попереду моделі, яку ми вже використовували, voyage-code-3 (89.73, #3).

Це невеликий абсолютний розрив. Але це розрив у правильному напрямку, на публічному бенчмарку, на точно тій задачі, яка нас цікавить: пошук коду за сенсом.

Компроміс, на який ми йдемо: бінарна квантизація

Ось та частина, яку більшість дописів «ми оновили нашу модель» пропускають.

Maguyva не зберігає вектори повної точності. Ми зберігаємо бінарно-квантизовані ембеддинги: кожен 2048-вимірний вектор стискається до 2048-бітного підпису — 256 байт на вектор. Ці підписи шукаються за відстанню Хеммінга, індексовані та розділені по тенантах.

Це навмисний компроміс. Бінарна квантизація жертвує деякою точністю пошуку в обмін на драматично менше сховище та швидку, дешеву математику відстані без окремої векторної бази даних для експлуатації. Для продукту, що індексує цілі репозиторії на робочий простір, ця економіка важливіша, ніж вичавлювання останньої частки бенчмаркового балу.

voyage-4-large вписується в цей дизайн без примусової міграції шару сховища: вона видає 2048-вимірний вивід, так само як voyage-code-3, тож наші колонки bit(2048) та шлях пошуку за Хеммінгом не змінилися. Модель стала кращою; схема залишилася на місці.

Код був лише початком

Maguyva — інструмент інтелекту коду. Але ми також клієнт номер нуль, і ми спрямовуємо його на дещо інше: markdown, що живе в наших репозиторіях поруч з кодом. Записи архітектурних рішень, runbook-и, контракти, фінансові та політичні документи — усе це під контролем версій у Git, усе за тим самим сервером MCP, семантичний індекс над документами, а не лише над джерельним кодом.

Саме тому широта voyage-4-large має значення. У тій самій родині рейтингів RTEB вона #1 у фінансах, #1 в охороні здоров’я і #1 у загальному текстовому пошуку — попереду Gemini Embedding від Google, Embed v4 від Cohere та text-embedding-3-large від OpenAI. (Voyage — співтворець RTEB, тож ми сприймаємо це як сильний публічний сигнал, а не абсолютно нейтральний суддя — але вона бенчмаркується напряму проти кожної великої комерційної моделі на приватних відкладених наборах.) Той самий індекс, що знаходить потрібну функцію для агента, знаходить потрібне положення в контракті чи потрібний рядок у політиці — і в цих доменах voyage-4-large не компроміс, а лідер.

Чому ми платимо за преміум-ембеддинги

Існує дешевший спосіб робити пошук, і чимало з нього безкоштовне. Лексичний пошук — BM25 та його родичі — зіставляє ключові слова, працює локально й нічого не коштує. Моделі ембеддингів з відкритим кодом на кшталт BGE, Nomic та embeddinggemma дають справді пристойний семантичний пошук, і їх можна хостити самостійно за ціну GPU. Maguyva також використовує безкоштовний бік: кожен запит зливає текстовий, AST, графовий та семантичний пошук. На чому ми не економимо — це семантичний шар.

Ми платимо за токен за преміум-ембеддинги — voyage-4-large — замість того щоб самостійно хостити безкоштовну модель, з двох причин. По-перше, самого лише пошуку за ключовими словами недостатньо, щоб відповісти на «де ми обробляємо повторні спроби», коли код каже backoff та circuit breaker і ніколи не каже слово «retry» — сенс і є весь сенс ембеддингу, і в доменах, які ми обслуговуємо, відкриті моделі відстають від преміум: на пару балів на загальному тексті, і ще більше в нішах на кшталт коду, контрактів та фінансів. По-друге, за нашим досвідом, якість пошуку формує фінальну відповідь більше, ніж модель на іншому кінці — сильний агент, якому дали неправильний контекст, все одно відповість неправильно, і він ніколи не побачить документ, якого йому ніколи не дали.

Тож преміум-ембеддинги — це рахунок за токен, що масштабується з кожним репозиторієм і документом, який ми індексуємо — і ми платимо його навмисно. Заради результату, який отримують наші користувачі — правильної функції чи правильного положення — ми вважаємо, що цей компроміс вартий того.

Чесна частина

Власна документація Voyage все ще позначає voyage-code-3 як модель, оптимізовану для коду. То чому ж перехід?

Бо ми читаємо публічний бенчмарк, а не лише таблицю моделей вендора, а бенчмарк поставив voyage-4-large на вершину для пошуку коду. Це було рішення з поглядом уперед: взяти новішу, загалом сильнішу модель і валідувати її проти публічного рейтингу на задачах, які мають значення. Нам комфортно робити цю ставку, бо докази широкі — voyage-4-large не просто перемагає в коді, вона також лідирує у фінансах, охороні здоров’я та загальному пошуку.

Тиха підлога

Кожен інструмент, який ми надаємо — семантичний пошук, збір контексту задачі, обґрунтовані запитання й відповіді — врешті-решт спирається на пошук. Коли ретрівер покращується, агент на іншому кінці отримує кращі докази, робить менше неправильних поворотів і обґрунтовує свої відповіді в правильному коді — або правильному положенні контракту, чи правильній політиці. Гостріша модель ембеддингів — не яскрава функція. Це підлога під усім іншим, і ми щойно її підняли. Ви цього не помітите. У цьому й суть.