# 我們為何將程式碼搜尋升級至 voyage-4-large

Canonical source: https://maguyva.ai/zh-hant/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

> 我們將程式碼嵌入模型換成了 voyage-4-large——目前在公開的 RTEB 程式碼檢索排行榜上排名第一。這是誠實的版本：我們做了什麼取捨、我們實際索引的是什麼，以及我們為何願意為高階嵌入模型付費。

> *本文中的基準測試數字，反映發布當下（2026 年 6 月）的 RTEB 排行榜狀態。排行榜會變動，請將這些排名視為某一時間點的快照，而非永久不變的事實。*

語意搜尋的品質，取決於其底層嵌入模型的品質。

當代理向 Maguyva 提問「我們在哪裡處理重試機制」時，它並不是在用 grep 搜尋「retry」這個字，而是在尋求*意義*——退避迴圈、斷路器，或是任何包裹了不穩定呼叫的機制。這個問題，是由一個向量模型負責回答的：它會把程式碼轉化為空間中的一個點，再找出相鄰的點。換一個更好的模型，產品中每一次語意查詢都會悄悄變得更精準。

因此我們換了模型。自 2026 年 6 月起，Maguyva 的程式碼嵌入運行於 **`voyage-4-large`**，取代了 `voyage-code-3`。

## 基準測試

我們做這個決定不是憑感覺。公開的[檢索嵌入基準測試（RTEB）](https://embedding-benchmark-rteb.hf.space/code)會依真實檢索任務為嵌入模型排名，而在其 **Code** 排行榜上，`voyage-4-large` 高居 **總排名第一（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 文件。架構決策紀錄、操作手冊、合約、財務與政策文件——全都以 Git 進行版本控管，全都藏在同一個 MCP 伺服器背後，是一份針對*文件*本身、而不只是原始碼的語意索引。

這正是為何 voyage-4-large 的廣度如此重要。在同一個 RTEB 系列排行榜上，它在**金融領域排名第一、醫療保健領域排名第一，整體文字檢索也排名第一**——領先 Google 的 Gemini Embedding、Cohere 的 Embed v4，以及 OpenAI 的 text-embedding-3-large。（Voyage 是 RTEB 的共同創建者之一，因此我們將這視為一項有力的公開訊號，而非完全中立的裁判結果——但它確實是在私有的保留測試集上，與每個主要商業模型正面較量得出的結果。）能為代理找到正確函式的那套索引，同樣也能找到合約中正確的條款、或政策中正確的那一行——而在這些領域，voyage-4-large 並非退而求其次的選擇，而是當之無愧的領先者。

## 我們為何願意為高階嵌入模型付費

搜尋還有更便宜的做法，而且很多都是免費的。詞彙搜尋——BM25 及其同類方法——靠關鍵字比對，可在本機執行，完全不花錢。像 BGE、Nomic、embeddinggemma 這類開源嵌入模型，能提供貨真價實、還算*不錯*的語意檢索能力，你甚至可以只花一張 GPU 的錢就自行架設。Maguyva 也同樣運用這免費的一面：每一次查詢都會融合文字、AST、圖譜與語意搜尋。我們唯一不肯省的，是語意這一層。

我們選擇按 token 計費、為高階嵌入模型——`voyage-4-large`——付費，而不是自架一個免費模型，原因有二。第一，當程式碼寫的是 `backoff` 和 `circuit breaker`、卻從未出現「retry」這個字時，單靠關鍵字搜尋根本回答不了「我們在哪裡處理重試機制」這個問題——掌握語意正是嵌入模型的核心價值，而在我們服務的這些領域中，開源模型確實落後於高階模型：在一般文字上落後個幾分，在程式碼、合約、金融這類利基領域則落後得更多。第二，就我們的經驗而言，檢索品質對最終答案的影響，遠大於另一端所使用的模型本身——一個強大的代理，若拿到錯誤的情境資訊，依然會答錯；而它從未被交付的文件，它也永遠看不見。

因此，高階嵌入模型是一筆隨著我們索引的每個儲存庫與每份文件而持續增加的按 token 計費帳單——而我們是刻意選擇支付這筆費用的。為了讓使用者得到正確的函式、或正確的條款這樣的結果，我們認為這筆取捨值得。

## 誠實的部分

Voyage 自家的文件，目前仍將 `voyage-code-3` 標示為程式碼最佳化模型。那我們為什麼還要換？

因為我們參考的是公開的基準測試，而不只是廠商自己的模型比較表，而基準測試顯示，在程式碼檢索上排名第一的是 `voyage-4-large`。這是一個前瞻性的決定：採用更新、整體表現更強的模型，並依公開排行榜、針對真正重要的任務加以驗證。我們之所以敢下這個賭注，是因為證據相當充分——voyage-4-large 不只在程式碼上獲勝，在金融、醫療保健與整體檢索表現上也同樣領先。

## 那個默默支撐一切的基礎

我們對外提供的每一項工具——語意搜尋、任務情境蒐集、有憑有據的問答——最終都仰賴檢索作為基礎。當檢索器變得更好，另一端的代理就能得到更好的佐證、少走幾步冤枉路，並將答案扎根於正確的程式碼——或是正確的條款，或是正確的政策。更精準的嵌入模型並不是一項華麗的功能，它是支撐其他一切的基礎，而我們剛剛把它墊高了一些。你不會注意到這件事，而這正是重點所在。