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

本文中的基准数字反映的是发布时(2026 年 6 月)的 RTEB 排行榜状态。排行榜会变动,请把这些排名当作某个时间点的快照,而不是永恒不变的事实。

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

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

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

基准测试

我们做这个决定,靠的不是感觉。公开的 Retrieval Embedding Benchmark(RTEB,检索 Embedding 基准测试) 会依据真实的检索任务,对各家 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 模型,不是一个花哨的功能,它是支撑其他一切的那道底线,而我们刚刚把它抬高了。你不会注意到这一点,而这正是重点所在。