# 我们为什么把代码搜索升级到了 voyage-4-large

Canonical source: https://maguyva.ai/zh-hans/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 排行榜状态。排行榜会变动，请把这些排名当作某个时间点的快照，而不是永恒不变的事实。*

语义搜索的好坏，完全取决于它底层所用的 Embedding。

当一个智能体问 Maguyva “我们在哪里处理重试”时，它并不是在用 grep 搜索“retry”这个单词，而是在寻求*含义*——退避循环、熔断器，那些包裹着一次不稳定调用的东西。这个问题的答案，来自一个把代码转化为空间中一个点、再去寻找邻近点的向量模型。选一个更好的模型，产品里的每一次语义查询，都会悄悄变得更精准。

所以我们换了模型。截至 2026 年 6 月，Maguyva 的代码 Embedding 运行在 **`voyage-4-large`** 之上，取代了 `voyage-code-3`。

## 基准测试

我们做这个决定，靠的不是感觉。公开的 [Retrieval Embedding Benchmark（RTEB，检索 Embedding 基准测试）](https://embedding-benchmark-rteb.hf.space/code) 会依据真实的检索任务，对各家 Embedding 模型进行排名，而在它的 **Code** 排行榜上，`voyage-4-large` 以 **总分 90.86 排名第一**——领先于 `gemini-embedding-2-preview`（90.26），而且值得注意的是，也领先于我们当时正在使用的模型 `voyage-code-3`（89.73，排名第三）。

这是一个很小的绝对差距。但它是在一个公开基准测试上、在我们真正在意的那项任务（按含义检索代码）上，朝着正确方向迈出的差距。

## 我们接受的取舍：二值量化（Binary Quantization）

这里是大多数“我们升级了模型”的文章都会略去的部分。

Maguyva 并不存储全精度向量，我们存储的是**二值量化**后的 Embedding：每个 2048 维的向量，都会被压缩成一个 2048 比特的签名——**每个向量只占 256 字节**。这些签名会用汉明距离（Hamming Distance）来搜索，并按租户进行索引和分区。

这是一次刻意为之的取舍。二值量化牺牲了一部分检索精度，换来的是大幅缩小的存储体积，以及快速、廉价的距离运算，而且不需要运维一个独立的向量数据库。对于一个要为每个工作区索引整个代码仓库的产品来说，这种经济性，比在基准测试分数上多抠出最后那一点点更重要。

`voyage-4-large` 恰好契合这套设计，不需要强行迁移存储层：它产生的是 2048 维输出，和 `voyage-code-3` 一样，所以我们的 `bit(2048)` 列和汉明搜索路径都不需要改动。模型变好了，Schema 原封不动。

## 代码只是个开始

Maguyva 是一个代码智能工具。但我们自己也是零号客户，而我们把它指向了另一样东西：那些和代码一起存在于我们代码仓库里的 Markdown 文档。架构决策记录、Runbook、合同、财务和政策文档——全部都在 Git 中受版本控制，全部都藏在同一个 MCP 服务器背后，是一个针对*文档*本身、而不只是源代码的语义索引。

这正是 voyage-4-large 的广度之所以重要的原因。在同一个 RTEB 排行榜家族中，它在**金融领域排名第一，在医疗领域排名第一，在整体文本检索上也排名第一**——领先于 Google 的 Gemini Embedding、Cohere 的 Embed v4，以及 OpenAI 的 text-embedding-3-large。（Voyage 是 RTEB 的共同创建者之一，所以我们把这个结果解读为一个有力的公开信号，而不是一个完全中立的裁判——但它确实是在私有的保留测试集上，与每一个主流商业模型正面对比得出的。）那套能为智能体找到正确函数的索引，同样能在一份合同里找到正确的条款，或者在一份政策文件里找到正确的那一行——在这些领域里，voyage-4-large 不是一种妥协，而是当之无愧的领跑者。

## 我们为什么愿意为高端 Embedding 付费

搜索本来有更便宜的做法，而且很大一部分是免费的。词法搜索——BM25 及其同类方法——匹配关键词，本地运行，不花一分钱。像 BGE、Nomic 和 embeddinggemma 这样的开源 Embedding 模型，能提供真正*说得过去*的语义检索能力，你只需要一块 GPU 的成本，就能自行托管它们。Maguyva 也用了这些免费的部分：每一次查询都融合了文本、AST、图谱和语义搜索。我们唯独不在语义这一层省钱。

我们按 Token 付费使用高端 Embedding——`voyage-4-large`——而不是自行托管一个免费模型，原因有两个。第一，当代码里写的是 `backoff` 和 `circuit breaker`、却从没出现过“retry”这个词时，单靠关键词搜索没法回答“我们在哪里处理重试”这个问题——含义，才是 Embedding 存在的全部意义，而在我们服务的这些领域里，开源模型都落后于高端模型：在通用文本上落后几分，在代码、合同、金融这类细分领域里则落后得更多。第二，根据我们的经验，检索质量对最终答案的影响，比另一端用的是什么模型更大——一个强大的智能体，如果拿到的是错误的上下文，依然会给出错误的答案，它永远看不到那份从未被交到它手上的文档。

所以，高端 Embedding 是一笔按 Token 计费、并随着我们索引的每一个代码仓库和每一份文档不断增长的账单——而我们是有意为之地在支付它。为了让用户得到那个正确的函数、或者那条正确的条款，我们认为这笔交易是值得的。

## 诚实的部分

Voyage 自己的文档，依然把 `voyage-code-3` 标注为代码优化模型。那我们为什么还要换？

因为我们参考的是公开基准测试，而不只是供应商自家的模型对照表，而这份基准测试，把 `voyage-4-large` 排在了代码检索的榜首。这是一个具有前瞻性的决定：选用更新、总体上更强的模型，并在关乎实际任务的公开排行榜上验证它。我们愿意下这个注，是因为证据是全面的——voyage-4-large 不只是在代码上获胜，它在金融、医疗和整体检索上同样领先。

## 默默支撑一切的基础

我们暴露出去的每一个工具——语义搜索、任务上下文收集、有据问答——最终都要落到检索上。当检索器变好了，另一端的智能体就能获得更好的证据，少走一些弯路，把答案扎根在正确的代码上——或者正确的条款、正确的政策上。一个更锐利的 Embedding 模型，不是一个花哨的功能，它是支撑其他一切的基础，而我们刚刚提升了这层基础的质量。你不会注意到这一点，而这正是重点所在。