Чому ми оновили пошук коду до 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 не просто перемагає в коді, вона також лідирує у фінансах, охороні здоров’я та загальному пошуку.

Непомітна основа

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