OpenClaw memorySearch 中文检索从勉强能用到真正好用：Voyage AI 替换本地嵌入模型实战

本地模型的中文检索到底差在哪

OpenClaw 的 memorySearch 默认用的是本地嵌入模型，通过 node-llama-cpp 跑 GGUF 模型，完全离线、零成本。听起来很美好，但实际用下来，中文语义匹配真的一般。我们日常对话大量使用中文，经常出现明明记忆文件里写了相关内容，搜出来就是找不到的情况。

这不是 OpenClaw 的问题，是本地小模型天然的短板——中文语义空间的表达能力就是不够。

翻了一圈方案之后，我们选了 Voyage AI，理由很直接：

中文检索质量领先。从 MTEB 排行榜到实际 RAG 场景，Voyage 的模型一直在第一梯队。它从 multilingual-2 时代就专门优化多语言，中文表现明显优于 OpenAI 的 embedding 系列
32K 上下文窗口。OpenAI 的 text-embedding-3 系列只有 8K，对于稍长的记忆文档就得截断。Voyage 给了 32K，基本不用担心
成本几乎为零。每个新账号自动送 2 亿 token 免费额度。我们实际用量大概 4.5 万 token/月，算一下……能用几百年

2026 年 1 月发布的 Voyage 4 系列提供三个档位：

有个很实用的特性：4 系列所有模型生成的向量互相兼容。你可以用 voyage-4-large 索引文档，用 voyage-4-lite 编码查询，向量空间是一致的。这给成本优化留了很大空间。

我们最终选了中间档 voyage-4。记忆搜索场景文档量不大，就几十个 markdown 文件，不需要 lite 那种极致省钱；而 large 的边际提升对我们这个量级也不明显。$0.06/百万 token 加上 2 亿免费额度，基本等于白嫖。

把几个主流选择放一起看：

中文语义理解能力排序：本地模型 < OpenAI < Voyage，差距明显。

实际操作很简单：

然后在 OpenClaw 中配置 memorySearch（直接把配置需求作为提示词发给 AI 就行）：

更安全的做法是通过环境变量传递 API Key：在配置文件的 env.vars 中添加 VOYAGE_API_KEY，这样配置文件里就不用明文写密钥了。

配置完重启 OpenClaw Gateway，系统会自动对 memory 目录下的文件重新建立向量索引。

这个确实容易搞混，特别说明一下。OpenClaw 体系里其实有两套知识检索机制，完全独立运行：

Voyage AI 驱动的 memorySearch——搜的是 MEMORY.md 和 memory/*.md，也就是 AI 助手自己的"记忆笔记"。这是自动触发的，每次回答前会自动搜一遍看有没有相关历史记忆。比如你问"之前我们讨论过什么"，它就去翻记忆文件。

qmd——搜的是你手动建的知识库，比如公司文档、架构说明、各种数据目录下的文件。这是主动调用的，用 qmd search 或 mq find 去查特定知识。

简单说，Voyage AI 是"自动回忆"，qmd 是"主动查资料"。两套索引不共享，切换 Voyage AI 只改了回忆那部分的搜索质量，qmd 完全不受影响。

从本地嵌入模型切到 Voyage AI，变化是肉眼可见的——中文记忆检索从"勉强能用"变成了"确实好用"。如果你也在用 OpenClaw 并且日常大量使用中文，强烈建议试试这个切换。配置十分钟，免费额度用到天荒地老，投入产出比极高。