RAG 的工程化实践：别被"接入向量数据库"骗了

一、先说结论

RAG（检索增强生成）不是"把文档切块、丢进向量库、查询时取 top-k"这么简单。这条路径上 80% 的工程复杂度不在检索本身，而在检索之前和检索之后。下面按生产落地顺序拆解。

二、切块：这是第一个坑

切块粒度直接决定检索质量。太细，上下文碎片化，模型抓不到完整语义；太粗，噪声大，相关性分数失真。

经验值：

纯文本：256~512 token，重叠 50~80 token
代码：按函数/类切，别按 token 切
表格/结构化数据：保持结构完整，宁可单块大一点

切块策略要按内容类型区分。一份文档里同时有标题、正文、表格、代码块，用同一套切块逻辑必然出问题。生产级做法是：先做内容分类（标题段/正文段/表格段/代码段），再按各自策略切。这一步多花两天，后面向量检索的误报率能降 30% 以上。

三、Embedding：选模型不是选"最新"

当前主流方案：

OpenAI text-embedding-3-small：便宜，够用，中文尚可
text-embedding-3-large：质量上限高，但成本翻 10 倍
bge-m3 / m3e：开源，中文强，可本地部署
Cohere / Voyage：英文场景表现优异

选型原则：先跑 benchmark，别凭直觉。用你自己的数据（不是公开数据集）测 Recall@3 和 MRR。中文场景下，bge-m3 往往比 OpenAI 的通用模型更准，而且数据不出境。

一个常被忽略的点：Embedding 模型和 LLM 的语义空间不一定对齐。同一个问题，Embedding 模型认为最相关的 top-3 文档，LLM 读起来可能觉得完全不沾边。如果出现这种情况，考虑用 LLM 做二次重排序（rerank），而不是硬调 Embedding 参数。

四、检索：向量相似度不是银弹

余弦相似度只解决"语义接近"，不解决"逻辑相关"。举个例子：用户问"如何重置密码"，向量库里最相似的是"如何修改用户名"——语义接近，但答案完全不对。

生产级检索必须多路召回：

向量相似度（语义匹配）
关键词匹配（BM25/倒排索引，兜底精确术语）
元数据过滤（时间、来源、类型、权限）

三路召回结果做加权融合，权重根据场景调。技术文档场景，关键词权重可以拉高；创意写作场景，向量权重更高。

重排序（Rerank）是必选项。第一轮召回 top-20，用轻量 cross-encoder 模型重排到 top-5，再喂给 LLM。这一步增加 50~200ms 延迟，但能显著降低"答非所问"的概率。代价换收益，值得。

五、上下文注入：别把 top-k 文档直接塞给 LLM

这是最常见的错误做法：检索到 top-5 文档，拼成 prompt 丢给模型。问题在于：

文档里可能有 80% 是无关内容，占上下文、干扰模型
多文档之间信息冲突，模型不知道该信哪个
上下文长度爆炸，成本飙升

正确做法：检索后加一道压缩与筛选。

用 LLM 判断每篇文档与用户问题的相关性（二分类），只保留高相关文档
对保留文档做摘要压缩，提取与问题直接相关的片段
标注文档来源和置信度，让模型知道"这段话来自哪个文档、是否权威"

这一步叫 Context Compression，是 RAG 工程化的核心环节。没做压缩的 RAG，本质上是在赌模型能从噪声里挑出有用信息。

六、幻觉治理：RAG 不治本

很多人以为 RAG 能解决 LLM 幻觉。不能。RAG 只是降低了幻觉概率，但模型仍然可能：

编造文档里不存在的细节
把多篇文档的信息错误拼接
对检索到的内容过度自信

治理手段：

在 prompt 里明确约束：“仅基于以下文档回答，文档未提及的内容请声明未知”
要求模型标注信息来源（“根据文档 A 第 3 段…”）
对关键事实做二次校验（用 LLM 验证答案是否与原文一致）
对敏感领域（医疗、法律、金融）加人工审核环节
七、评估：没有指标就是盲飞

RAG 系统上线前必须跑通这套评估：

检索层指标：Recall@K、MRR、NDCG（衡量"找得对不对"）
生成层指标：事实一致性（FactScore）、答案忠实度（Faithfulness）
端到端指标：人工抽样评分（1~5 分）、用户满意度（CSAT）

不要只看自动指标。自动指标能告诉你"检索覆盖率"和"文本相似度"，但判断"答案是否真正解决了用户问题"，必须人工抽样。建议每周抽 50~100 条真实 query 做人工评分，建立回归基线。

八、成本：别让 RAG 变成印钞机

RAG 的隐性成本常被低估：

Embedding API 调用费（文档更新频繁时很贵）
向量数据库存储与检索成本（百万级文档起，QPS 上来后线性增长）
LLM 上下文 token 费（每次查询都带上下文）
重排序模型推理成本

优化方向：

冷热数据分层：高频 query 对应文档常驻内存，低频走磁盘
缓存层：相同 query 的检索结果缓存 24 小时
混合精度：简单问题走小模型 + 轻量检索，复杂问题才走全链路
定期清理过时文档，避免向量库膨胀
九、几个直白的结论
RAG 的工程复杂度 70% 在数据预处理（切块、清洗、标注），20% 在检索策略，10% 在生成。别把精力全砸在向量数据库选型上。
多路召回 + 重排序是生产级 RAG 的标配，单路向量检索只适合 PoC。
上下文压缩不是可选项，是必选项。不压缩的 RAG 就是"把图书馆搬进 prompt"。
RAG 不治幻觉，但能显著降低幻觉概率。治理幻觉需要 prompt 约束 + 来源标注 + 二次校验的组合拳。
评估体系必须先于上线。没有指标的 RAG 系统，上线即盲飞。