想象一下，你在给一家拥有数千份内部文档的公司搭建AI助手。员工问了一句：“企业客户能在续约前取消合同吗？”系统检索向量数据库，抓出几个片段，丢给大模型，得到一个自信满满的答案。演示很顺利。然后有人换了个问法：“如果一个大客户想在合同续约前退出，会怎样？”

系统这次检索出了另一批文档。一份是过时的定价政策，另一份讨论续约流程，第三份只沾了点边。大模型依然给出了一个听起来很有说服力的回答。没有报错，没有崩溃，只是这个答案缺乏足够的依据支撑。这就是生产环境里的RAG和演示版RAG开始分道扬镳的地方。

打开网易新闻 查看精彩图片

从“向量库加大模型”到一条更长的链路

如果今天要搭建一套生产级RAG系统，我不会止步于“向量数据库接大模型”这条最短路径。那只是验证RAG可行性的起点。真正面向生产，我更倾向于把链路拆成：用户请求、API接入、查询处理、混合检索、重排序、上下文压缩、大模型生成、引用校验、最终响应。

关键不在于必须拆出九个独立服务，而在于让每个环节都承担清晰且单一的职责。每一层只解决一个问题，出了问题也容易定位。

查询处理：别把用户原话直接当搜索词

用户的问题并不总是合格的搜索查询。比如有人问：“它的限制是什么？”如果上一轮对话在聊企业级API，人类能理解“它”指什么。但只看这几个字的检索系统，拿到的信息远远不够。

查询处理环节可以利用对话历史、问题改写、元数据提取、过滤条件，甚至确定性的规则，把原始请求转换成检索真正能用的形式。目标很直接：给检索阶段一个更贴近用户真实意图的表达。

混合检索：语义相似不等于答案相关

拿到查询之后，下一步是找证据。向量搜索擅长捕捉语义相似性，但语义相似并不总是等于相关。如果有人搜“OAuth刷新令牌轮换”，一篇包含这个精确短语的文档，可能比一篇语义相近但讨论会话过期的文档更有用。

所以我会采用混合检索：语义搜索处理概念层面的相似，词法搜索处理精确术语、产品名、标识符、错误码这类措辞本身就很重要的场景。两条路汇合之后，候选集的质量会明显更扎实。

重排序：检索负责找到，重排负责选准

假设混合检索返回了30个片段，我不会把这30个全部塞给大模型。检索阶段的任务是尽可能找出可能的候选，重排序器再拿着这些候选和原始查询逐一比对，判断哪些真正有用。

这里有一个关键区分：“这份文档看起来相关”和“这份文档能帮助回答问题”是两回事。前者是检索的直觉，后者才是重排序要做的判断。

上下文压缩：更多上下文不一定是好事

当检索效果不佳时，一个常见的反应是“多塞点上下文”。但上下文窗口不是越大越好。无关信息会稀释真正有用的证据，还会推高延迟和成本。上下文压缩环节的作用，是在送入大模型之前，把候选片段里最核心、最相关的部分提炼出来，让模型看到的是精炼后的证据，而不是一堆噪音。

这套架构的核心思路并不复杂：把“找到可能相关的材料”和“判断哪些材料真正能支撑回答”拆成两个阶段，再在中间加上查询理解和上下文整理。每一步都在降低后续环节的负担，最终让大模型拿到的输入更干净、更可验证。

生产级RAG和演示版RAG的差距，往往不在模型本身，而在模型之前的那几道工序。向量搜索只是起点，真正决定答案质量的是查询怎么被理解、候选怎么被筛选、上下文怎么被压缩。把这些环节做扎实，系统才不会在换一种问法时悄悄翻车。