首页 / 文章 / RAG详解

RAG检索增强生成详解：架构、评测与常见失败模式

工程实践 · 约4000字 · 预计阅读17分钟 · 更新于2026年1月

RAG（Retrieval-Augmented Generation，检索增强生成）是当前企业落地大模型最主流的架构之一：先从企业知识库检索相关片段，再让模型基于这些片段生成回答。它的价值在于把「可变知识」从模型参数中剥离，提高时效性与可审计性，并降低微调成本。

但现实中大量「向量库+Chat」项目表现不佳：答非所问、张冠李戴、引用空洞、权限穿透。原因通常不在模型本身，而在检索链路设计与评测缺失。本文按工程视角拆解全流程。

一、RAG要解决什么问题

纯LLM回答企业私有问题有三类硬伤：知识未写入训练语料；知识会过期；无法证明答案依据。RAG用外部检索补这三块，同时带来新复杂度：检索错了，生成再流畅也是错的；检索对了，提示组装不当仍可能忽略证据。

因此，请把RAG看成搜索系统+生成系统，而不是「给模型加点记忆」。

二、标准架构拆解

一条可上线的RAG链路通常包含：

1. 接入层：身份认证、租户隔离、限流。
2. 查询理解：改写、补全、意图分类、是否需要检索。
3. 检索层：关键词、向量、混合检索，可选多路召回。
4. 重排层：用交叉编码器或业务规则精排。
5. 上下文组装：去重、截断、按来源标注、注入系统约束。
6. 生成层：要求基于证据回答，无法支持则明确说不知道。
7. 后处理：引用校验、敏感过滤、格式检查。
8. 观测层：记录检索命中、引用率、用户反馈、延迟与成本。

若你的系统缺少重排、引用校验与评测集，它仍停留在概念验证阶段。

三、文档处理与切分策略

垃圾进，垃圾出。入库前至少完成：

• 格式解析：PDF扫描件需OCR；表格尽量保留结构。
• 清洗：页眉页脚、水印、重复目录、无意义导航文本。
• 元数据：来源系统、更新时间、权限级别、文档类型、适用产品线。
• 版本：同一政策多版本并存时，必须能按生效日期过滤。

切分（chunking）没有万能参数。可参考：

• 政策问答：按条款/标题切，保留上下条款编号。
• 技术手册：按小节切，块长400–800汉字或对应Token，重叠10%–15%。
• FAQ：一问一答保持完整，不要把答案切开。
• 代码：按函数/类切，附文件路径。

切太碎会丢语境；切太大则检索粒度粗、噪声多。应准备20–50个真实问题，对比不同切分方案的检索命中率，而不是凭感觉选「512」。

四、检索、重排与上下文组装

向量检索擅长语义相近但用词不同的问题；对专有名词、错误拼写、精确编号，关键词检索（如BM25）往往更稳。生产环境推荐混合检索：两路召回后融合。

重排用更强但更贵的模型对Top-K精排，通常能显著提升准确率。若预算有限，至少用规则：标题命中加权、更新时间加权、同文档多块聚合。

上下文组装建议强制：

1. 每段证据带来源ID与标题。
2. 总Token设硬上限，优先保留重排分数高的块。
3. 系统提示写明：只能依据证据；证据不足则拒答；输出引用列表。

五、评测指标怎么定

至少同时跟踪检索与生成两侧：

• 检索：Recall@K、MRR、业务专家标注的「是否包含充分证据」。
• 生成：忠于证据率（是否编造）、完整性、可读性、拒答正确率。
• 产品：人工接管率、点踩率、首次解决率、平均成本/会话。

自动指标（BLEU等）对开放问答帮助有限。更有效的是：固定评测集+抽样人工复核+线上反馈闭环。没有评测集就优化RAG，等于闭眼调参。

六、十个常见失败模式

1. 文档未清洗，页眉被当成答案。
2. 切分切断关键条件句（「仅适用于……」丢失）。
3. 只用向量，订单号/政策编号检索失败。
4. Top-K过小，证据根本没进入上下文。
5. Top-K过大，模型在噪声中「自由发挥」。
6. 多租户未按权限过滤，造成信息越权。
7. 提示未要求引用，用户无法核验。
8. 知识更新后未重建索引，回答过期政策。
9. 把聊天历史无限制塞进检索查询，意图漂移。
10. 用开放域闲聊模型设定，导致即使有证据也爱补充训练记忆。

七、从Demo到生产的检查表

• 是否有文档Owner与更新SLA？
• 是否有按权限过滤的索引策略？
• 是否有黄金问题集（建议≥100）并定期回归？
• 是否记录每次回答的检索片段便于复盘？
• 是否有拒答与转人工路径？
• 是否监控延迟、空检索率、引用缺失率？

RAG不是插件，而是内容工程+搜索工程+生成约束的组合。把它当成可持续运营的知识服务，而不是一次性接入，效果才会随时间变好而不是随文档膨胀变差。

相关阅读：Prompt工程方法论、LLMOps、可行性评估。