コード検索をvoyage-4-largeへアップグレードした理由

この記事のベンチマーク数値は、公開時点(2026年6月)のRTEBリーダーボードを反映しています。リーダーボードは変動するものなので、この順位は永続的な事実ではなく、ある時点のスナップショットとして捉えてください。

セマンティック検索の質は、その土台にある埋め込みの質次第です。

エージェントがMaguyvaに「リトライはどこで処理しているか」と尋ねるとき、それは「retry」という単語をgrepしているわけではありません。求めているのは意味です ―― バックオフループ、サーキットブレーカー、不安定な呼び出しをラップしているもの。この問いに答えるのは、コードを空間上の1点に変換し、その近傍を見つけるベクトルモデルです。より良いモデルを選べば、プロダクト内のあらゆるセマンティッククエリが静かに鋭くなります。

そこで私たちは自分たちのモデルを変更しました。2026年6月時点で、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は、ストレージ層の移行を強いることなく、この設計にぴたりと収まります。voyage-code-3と同じく2048次元の出力を生成するため、私たちのbit(2048)カラムとハミング検索の経路は変更する必要がありませんでした。モデルは良くなり、スキーマはそのままです。

コードはほんの始まりに過ぎなかった

Maguyvaはコードインテリジェンスのツールです。しかし私たち自身も最初の顧客であり、それを別のものにも向けています。コードと並んでリポジトリに存在するMarkdownです。アーキテクチャ上の意思決定記録、ランブック、契約書、財務・ポリシー文書 ―― そのすべてがGitでバージョン管理され、そのすべてが同じMCPサーバーの背後にあり、ソースコードだけでなく文書そのものに対するセマンティックインデックスが張られています。

だからこそ、voyage-4-largeの守備範囲の広さが重要なのです。同じRTEBファミリーのリーダーボード群において、これはfinance(金融)で1位、healthcare(医療)で1位、そして総合テキスト検索でも1位です ―― GoogleのGemini Embedding、CohereのEmbed v4、OpenAIのtext-embedding-3-largeを上回っています。(Voyageは RTEBの共同開発者でもあるため、私たちはこれを完全に中立な審判というより、強力な公開シグナルとして読んでいます ―― とはいえ、プライベートなホールドアウトセットの上で、あらゆる主要な商用モデルと直接比較されてはいます。)エージェントのために正しい関数を見つけ出すのと同じインデックスが、契約書の中の正しい条項や、ポリシーの中の正しい一文を見つけ出します ―― そしてそれらの領域において、voyage-4-largeは妥協案ではなく、トップランナーです。

なぜプレミアムな埋め込みにお金を払うのか

検索にはもっと安く済ませる方法があり、その多くは無料です。字句検索 ―― BM25やその類 ―― はキーワードにマッチし、ローカルで動作し、コストはゼロです。BGE、Nomic、embeddinggemmaのようなオープンソースの埋め込みモデルは、正真正銘まずまずなセマンティック検索を提供してくれますし、GPU1台分の費用で自前ホストすることもできます。Maguyvaもこの無料の側面を使っています ―― すべてのクエリは、テキスト検索、AST検索、グラフ検索、セマンティック検索を統合しています。私たちが手を抜かないのは、このセマンティックレイヤーです。

私たちは、無料モデルを自前ホストする代わりに、トークンあたりの課金でプレミアムな埋め込み ―― voyage-4-large ―― を利用しています。理由は2つあります。第一に、コードがbackoffやcircuit breakerと書いていて「retry」という単語を一度も使っていない場合、キーワード検索だけでは「リトライはどこで処理しているか」に答えられません ―― 意味こそが埋め込みの存在意義であり、私たちが扱うドメインにおいてオープンモデルはプレミアムモデルに後れを取っています。一般的なテキストでは数ポイント差、コード・契約書・金融のようなニッチな領域ではさらに差が開きます。第二に、私たちの経験では、最終的な答えの質は、応答する側のモデルよりも検索の質によって形作られます ―― 優れたエージェントであっても、誤ったコンテキストを渡されれば誤った答えを返しますし、渡されなかった文書を目にすることは決してありません。

つまりプレミアムな埋め込みは、インデックス化するリポジトリや文書が増えるたびにスケールする、トークンあたりの請求書です ―― そして私たちは、それを意図的に払っています。ユーザーが得る成果 ―― 正しい関数、あるいは正しい条項 ―― を考えれば、そのトレードオフには十分見合う価値があると私たちは考えています。

正直な部分

Voyage自身のドキュメントは、今もvoyage-code-3をコードに最適化されたモデルとして位置づけています。では、なぜ移行したのでしょうか?

私たちは、ベンダーのモデル表だけでなく、公開ベンチマークそのものを読んだからです。そしてそのベンチマークは、コード検索においてvoyage-4-largeをトップに置いていました。これは先を見据えた判断でした。より新しく、全般的により強力なモデルを選び、重要なタスクにおいて公開リーダーボードで検証する、という判断です。私たちがこの賭けに踏み切れるのは、その根拠が幅広いからです ―― voyage-4-largeはコードだけで勝っているのではなく、金融、医療、そして総合検索でも先頭に立っています。

静かな土台

私たちが公開しているすべてのツール ―― セマンティック検索、タスクコンテキストの収集、根拠に基づくQ&A ―― は、最終的には検索に行き着きます。検索エンジンが改善されれば、その先にいるエージェントはより良いエビデンスを手にし、誤った方向へ進む回数が減り、正しいコード ―― あるいは正しい条項、正しいポリシー ―― に自らの答えを根拠づけられるようになります。より鋭い埋め込みモデルは、派手な機能ではありません。それは、他のすべてを支える土台であり、私たちはたった今、それを引き上げました。あなたは気づかないでしょう。それこそが狙いです。