deepseek-r1 嵌入模型

很多人搭知识库时，手上正好有 DeepSeek-R1，就想省事直接拿它出向量，结果要么接不上、要么召回一塌糊涂。这篇不讨论 R1 推理强不强，只解决一件事：它能不能当嵌入模型，不能的话按什么标准换人。读完你能判断自家链路该不该动、换成哪一类模型，以及换完怎么验证没白换。

搭知识库的时候，很多人手上正好有一套 DeepSeek-R1 的调用额度，第一反应就是省点事，直接拿它把文档转成向量。结果往往是两种：要么接口根本接不上，返回的是聊天补全而不是向量；要么勉强凑出一个向量能入库，检索出来却一塌糊涂，明明文档里有这条内容，问它就是找不到。这篇不讨论 R1 推理能力怎么样，只解决一件事：它能不能当嵌入模型用，如果不行，按什么标准换人、换完怎么验。

读完之后你应该能判断三件事：自家这条检索链路要不要动、该换成哪一类模型、换完用什么方法确认没白折腾。判断标准都是可操作的，你拿着就能对照自家项目过一遍。

先定性：R1 是生成模型，不是嵌入模型

先把概念上的账算清。生成模型做的事是预测下一个 token 的概率分布，输出是一串文字；嵌入模型做的事是把一段文本压缩成一个定长向量，输出是一组数字。这两件事的训练目标、优化方式、对外接口形态都不一样。不是能力高低的问题，是压根不是同一类工具。

判断一个模型能不能干嵌入的活，有三个硬指标，缺一个都别往上凑：第一，有没有专门的向量输出接口，也就是你传文本进去，它直接还你一组数字；第二，输出维度是不是固定的，不管输入多长，返回的向量长度必须一样，否则向量库里没法比距离；第三，它在检索类任务上有没有训过，这一点最容易被忽略，但也最影响实际召回。

• 有专门的向量接口，不是让你从对话接口里截字段
• 输出维度固定且文档里写明了是多少
• 训练阶段接触过语义相似度、检索、问答匹配这类任务
• 这两条不满足，就别继续往下试了，直接进替代选型

有一种情况要单独说：如果你只是做离线聚类，比如把一堆工单粗分几个大类，对召回精度要求很低，那用生成模型的隐状态凑一个向量，也不是完全不能用。但这条路径别指望它稳，一旦业务要求提高到「用户问一句，必须精确命中对应文档」，凑合向量立刻就不够了。判断标准很简单：你的场景里，检索错一条会不会有人来投诉。会，就老老实实换专用嵌入模型。

动手第一步：查接口而不是查宣传

别急着写代码，先去核对接口。很多人踩坑是因为看了模型名字或者宣传口径，觉得「这个大模型这么强，出个向量还不是顺手的事」，然后写了一半才发现接口对不上。正确顺序是先确认 API 表面能力，再决定要不要试。

具体动作分三步。第一步，到站内模型资料库核对这个模型标的是 chat 类型还是 embedding 类型，分类标签比模型名字靠谱得多。第二步，如果平台只提供对话补全接口，那它就没有嵌入能力，直接排除，不用浪费时间试。第三步，如果实在不确定，用一次最小请求验证：请求里带上 input 文本，期望返回的应该是一组固定长度的数字，如果返回的是一段文字补全，说明方向从一开始就错了。

顺带记一下计费口径。嵌入是按 token 计费还是按调用次数计费，这决定了你后面换模型时的成本基线，也影响你入库策略怎么设计——按 token 计费的，长文档切块方式会直接影响账单。具体单价到价格追踪页看当时的数字，别凭印象拍。

硬拿 R1 当嵌入会踩的三个坑

假设你不信邪，真把它接进检索链路了，通常会在这三个地方出问题。提前知道这三个坑长什么样，能帮你在测试阶段就判断出「是不是模型选错了」，而不是一路查到前端代码。

这三个坑里，召回质量不稳最致命，因为它不像报错那样明显，表现是「偶尔找不到」，很容易被归咎于文档切分或者阈值设置，排查半天才发现根子在模型本身。第二和第三个坑更多是工程和维护层面的代价，短期能忍，长期会拖慢迭代速度。

不适用的情况也说清楚：如果你的知识库文档量很小，几百条以内，而且是内部人自己用、答不准也能接受，那这三个坑的实际影响会被摊薄。但只要是对外服务、量大、有人依赖检索结果做决策，这三条就是硬伤。

替代选型：按这四条挑，别按名气挑

确认要换之后，选什么？很多人第一反应是「找个榜单排第一的」。榜单能看，但不能只看名次，得按你自己的约束条件排。下面四条是按优先级来的，前两条决定能不能用，后两条决定用起来贵不贵、麻不麻烦。

• 中文检索优先：知识库主要是中文文档时，中文语义检索表现比多语言通用模型更重要，别被多语言标签带偏
• 维度与存储：维度越高越吃存储和内存，先算清楚你的文档量级再定档位，别为了那点精度把检索延迟顶上去
• 部署位置：要数据不出内网就走本地部署路线，能吃外部接口就优先看托管方案，两条路的取舍标准完全不同
• 许可证与商用边界：对外提供服务前，先把模型权重的商用条件看清楚，别上线后才发现不能用

这四条里，最容易翻车的是第四条的排序——很多人是先挑效果、再看许可证，结果效果好的那个不能用。正确顺序是先看许可证能不能过，再看部署位置，最后在剩下的候选里比效果。第一和第二条会在效果对比阶段用上。

不适用的边界：如果你的语料主要是英文技术文档，那「中文检索优先」这条自动失效，应该按英文检索表现来排。如果你们的检索只是给内部员工用、不出网，那许可证审查可以放宽，但数据出内网这件事本身就是个红线，得单独确认。

换模型的操作顺序：先测再换，别直接切线上

选好了替代方案，下一步是换。这一步最常见的错误是直接改配置、重建向量库、上线，出问题了再回滚——但向量库重建是有成本的，回滚不一定来得及。正确做法是先把旧索引留着，新模型在旁路跑验证。

1. 固定回归题集从客服记录或历史搜索日志里挑一批真实问句，数量够覆盖主要业务场景即可，这份题集后面每次换模型都能复用
2. 新旧模型对比召回同一批问句分别用新旧模型出向量，比对前几条召回结果，重点看新模型有没有把本该命中的东西挤出去
3. 确认提升再重建命中质量确实提升后，再重建向量库；重建期间保留旧索引，出现问题时能切回去
4. 重设重排与阈值换嵌入模型后，原来的相似度阈值基本都要重设，重排环节的输入分布也变了，这两个地方必须跟着调
5. 灰度上线先放一部分流量走新链路，观察几天召回和延迟再决定全量；监控项至少包含检索延迟和命中率

第三步和第四步之间有个容易被跳过的动作：确认新模型是不是真的更好，而不是只是「换了」。判断方法不是看平均分，而是看有没有「以前答对、现在答错」的样本。有这种样本说明新模型在你的语料上有短板，得先搞清楚是哪个场景再决定要不要全量。

本地部署还是调接口：按数据敏感度分线

嵌入模型的部署方式分两条路，本地部署和调托管接口。选哪条不是看哪个先进，是看你的数据能不能出内网。这条线划清楚，后面的工程量测算才有意义。

本地部署这条路上，嵌入模型本身不算大，但并发入库时会吃内存，尤其是批量处理长文档的时候。显存和批处理能力要按你的文档量估算，站内的部署测算页可以按输入量级算一遍，别凭感觉估。托管接口这条路简单，但要留意调用频率限制和超时重试策略，入库阶段最容易在这里卡住。

混合做法这两种之外还有一种：检索用本地小模型，重排用外部接口。这个组合的前提是重排那一步传出去的只是文档片段而不是全文，否则等于把数据全送出去了，合规上说不通。如果你的文档极度敏感，这个组合也不成立，老老实实全本地。

换完怎么确认没白换：一份自检清单

换完模型不算结束，得确认这次换是值的。很多人只跑一遍「问题能答上来了」就当验收通过，这不够——嵌入模型的改动会同时影响召回、延迟、成本三条线，得分开看。

• 同一批问句换模型前后各跑一遍，记录命中位置的变化，不只是看命中没命中
• 抽一批「以前答错、现在答对」和「以前答对、现在答错」的样本人工看一眼，后者才是真正要警惕的
• 监控入库耗时与检索延迟，换嵌入模型这两项一定会变，变了要有预期
• 把这次选型的理由、被否掉的方案、验证数据简单记一页，半年后你不会记得为什么选它

第二条是这份清单里最容易被跳过、但最值得做的。新模型带来的提升往往是全局平均值上的，而回归通常集中在某个特定场景——比如短问句、比如带缩写术语的查询。只看平均指标会把这些吃掉，人工抽看才能发现。

判断一次换模型值不值，标准不是「新的比旧的好」，而是「新的没有在某个场景上变差」。