在一把 key 上搭一个小型 RAG 流水线：嵌入、检索与生成分别落在不同后端

为什么要把 RAG 拆成三段看

很多人第一次搭 RAG，会默认「一个模型、一次调用」就能解决。实际上最小可用的检索流水线至少有三种性质不同的工作：

• 嵌入（embedding）：把文本映射成向量，要求同一模型、同一版本、同一预处理，输出可比。
• 检索（retrieval）：在向量集合里做近邻搜索并打分排序，是数据结构与数值问题，不是语言问题。
• 生成（generation）：把检索结果拼进上下文，让对话模型产出答案，是语言与指令遵循问题。

三者对后端的要求不同。聚合站的价值在于：同一把 key 后面挂的是多个模型家族（Claude、GPT、DeepSeek、Qwen、GLM、Kimi），你可以在不改鉴权与计费链路的前提下，把这三段分别指到更合适的后端。

用一把 key 编排三段调用

工程上最常见的做法是：应用侧只持有一个 key 和一个 base URL，用「模型名」做路由，把不同步骤发到不同模型。

• 嵌入步骤调用嵌入类模型，产出向量并入库。
• 检索步骤不调用模型，只在你的向量库（或先用内存里的暴力检索）里执行。
• 生成步骤调用对话类模型，输入是问题 + 检索片段。

这样做的好处是密钥管理面收敛为一个：轮换、限额、审计都只针对一处。计费上按官方价 ×1.3 扣费，所以拆成三次调用并不意味着成本结构变复杂，你仍然只需盯住 token 总量。若你同时也贡献 key，则按官方价 ×1.1（优质 ×1.2）返 USDC，与消费侧是两条独立的账。

需要注意：不同后端的上下文窗口、是否支持批量输入、返回结构可能不同。把模型名做成配置项而不是硬编码，是让这套编排可迁移的最低成本。

嵌入与检索之间最容易破的三个假设

这一段是流水线里最安静、也最容易出错的地方。

假设一：向量维度一致。 换嵌入模型通常意味着维度变化。维度不同的向量不能放进同一个索引做比较。要么重建索引，要么用「每模型一个集合」的方式并存，查询时按当时的嵌入模型选集合。切忌把两种模型的向量混在一个集合里，那不会报错，只会悄悄给出无意义的近邻。

假设二：归一化方式一致。 有的嵌入输出已归一化，有的没有。余弦相似度与点积在向量已归一化时等价，未归一化时不等价。如果你在入库时做了一次归一化、查询时忘了做，打分就会系统性偏移。把归一化写进同一个函数，入库与查询共用，是唯一稳妥的做法。

假设三：距离度量与索引参数匹配。 余弦、内积、欧氏距离对应不同的索引构建方式。用余弦建索引却按内积解释分数，排序结果会看起来「差不多但不对」。另外，近似最近邻索引有召回率参数，调高召回换来的是延迟与内存，这部分要在你的数据规模上实测，而不是照抄别人的配置。

一个实用的自检流程

1. 固定一小批已知相关的问答对作为回归集。
2. 换嵌入模型或改归一化后，先只跑检索，看 top-k 是否仍然包含目标片段。
3. 检索稳定后，再换生成模型，观察答案是否因上下文顺序或片段长度而变差。
4. 每次只改一个变量，否则你无法判断退化来自哪一段。

生成段的拼接策略比模型选择更影响结果

检索回来的片段如何进入上下文，往往比换哪个对话模型更决定成败：

• 顺序：把最相关的片段放在靠前位置，长上下文模型也普遍存在中段信息利用率下降的现象。
• 去重：相邻 chunk 常高度重叠，重复内容会挤占预算。
• 标注来源：给每个片段加编号或来源标识，便于要求模型引用，也便于你在答错时回溯。
• 长度控制：按 token 预算截断，而不是按字符数，不同后端的 tokenizer 不同。

因为一把 key 能切多个模型，你可以用便宜的后端做草稿、用更强的后端做最终答复，或按问题类型路由。但不要假设某个模型「一定更懂」你的领域，回归集上的表现才是依据。

什么时候该考虑更重的方案

最小流水线够用的边界大致是：语料规模能用单机内存索引承载、查询延迟可接受、召回问题主要靠调 chunk 与 top-k 解决。当出现以下信号时再升级：

• 回归集上召回长期卡在瓶颈，调参数无效；
• 需要按元数据过滤、多路召回再融合；
• 需要跨语言或跨模态检索。

这些都属于检索段内部的演进，与用哪把 key、走哪个后端无关。把三段边界划清楚，升级时你只需要替换其中一段。

小结

一把 key 的真正价值不是「少管一个密钥」，而是让嵌入、检索、生成可以各自选型而不牵动鉴权与计费。相应地，风险也从「调用失败」转移到「静默的数值不一致」——维度、归一化、距离度量这三处假设，值得在流水线第一次跑通时就写成断言。