很多 RAG Demo 做起来不难：切文档、入向量库、检索、把上下文塞给大模型，然后生成答案。
但上线到真实业务后，问题会集中出现：
- 回答不稳定
- 召回不准
- 上下文混乱
- 引用缺失
- 幻觉难控
- 文档一多就变慢
- 用户问法一变就答偏
我在 AI全书里整理了一篇更完整的 RAG 优化文章，覆盖上下文感知分块、重排序、查询扩展、多查询 RAG、Agentic RAG、自反思、知识图谱等策略。
下面是文章的摘要版。
1. 朴素 RAG 的常见问题
文档切块丢上下文
很多系统按固定长度切块。这样实现简单，但容易把一个完整概念拆开，导致检索到的片段缺前因后果。
向量召回不等于答案相关
向量相似度只能说明语义接近，不代表这个片段能回答用户问题。生产系统里通常还需要重排序、过滤和评估。
查询表达和文档表达不一致
用户问的是口语，文档写的是术语。只做一次向量检索，经常召回不到真正相关的内容。
长上下文里有效信息被稀释
把太多片段直接塞给模型，并不一定提升效果。模型可能忽略关键片段，或者被冲突信息干扰。
2. 关键优化策略
策略 1：上下文感知分块
不要只按固定 token 数切块。更好的方式是结合标题、段落、语义边界、表格和代码块。
目标不是“切得均匀”，而是让每个 chunk 能独立表达一个相对完整的信息单元。
策略 2：保留元数据
文档来源、标题层级、发布时间、作者、业务线、权限信息都很重要。
元数据可以帮助：
- 过滤无权限内容
- 优先使用新文档
- 在答案中给出引用
- 做问题定位和效果分析
策略 3：混合检索
单纯向量检索不一定适合所有问题。工程上常见做法是混合：
- 向量检索
- 关键词检索
- BM25
- 结构化过滤
对于包含编号、错误码、产品名、接口名的问题，关键词检索通常非常重要。
策略 4：查询改写
用户的问题可能很短，也可能带口语表达。查询改写可以把问题扩展成更适合检索的形式。
例如：
- 补全上下文
- 生成同义表达
- 抽取关键词
- 拆成多个子问题
策略 5：多查询 RAG
对复杂问题，可以生成多个查询并分别检索，再合并结果。
适合场景：
- 用户问题包含多个意图
- 文档表达方式不统一
- 单次检索召回不稳定
策略 6：重排序
召回阶段可以多取一些候选，再用 reranker 排序。这样能减少“语义相似但不能回答问题”的片段进入最终上下文。
重排序通常是 RAG 从 Demo 走向可用的关键步骤。
策略 7：上下文压缩
检索到的片段可能很长，但真正有用的只有几句话。可以在进入最终 prompt 前做压缩，保留与问题相关的部分。
策略 8：引用和证据链
生产系统里的 RAG 不应该只给答案，还应该给引用来源。
引用能解决两个问题：
- 用户可以验证答案
- 团队可以追踪错误来源
策略 9：拒答机制
知识库里没有答案时，系统应该拒答，而不是编造。
可以通过相似度阈值、重排序分数、证据数量和模型自检来判断是否回答。
策略 10：评估集
没有评估集，就无法判断优化是否有效。
建议维护一批真实问题，记录：
- 标准答案
- 期望引用
- 问题类别
- 难度
- 业务线
每次调整切块、Embedding、reranker、prompt，都用同一套问题评估。
策略 11：Agentic RAG / GraphRAG
当问题需要多步推理、跨文档整合或结构化关系时，可以考虑 Agentic RAG 或知识图谱增强。
但不建议一开始就上复杂方案。先把文档处理、召回、重排序、评估做好，再逐步扩展。
3. 推荐实施路线
第一阶段：先让系统可评估
- 建测试问题集
- 记录标准答案
- 记录引用来源
- 建立基本指标
第二阶段：优化召回
- 改切块策略
- 加元数据
- 做混合检索
- 增加查询改写
第三阶段：优化排序和上下文
- 引入 reranker
- 做上下文压缩
- 控制最终 prompt 长度
- 增加引用约束
第四阶段：再考虑高级能力
- 多查询 RAG
- Agentic RAG
- GraphRAG
- 自反思
- 自动评估
4. 常见错误
错误 1：只换 Embedding 模型
Embedding 重要，但不是唯一因素。切块、元数据、检索策略、重排序和评估同样关键。
错误 2：没有区分问题类型
事实查询、流程查询、排障查询、对比查询需要不同策略。一个统一 prompt 很难覆盖全部场景。
错误 3：没有人工评估
只看模型自评容易高估效果。关键场景必须有人审。
错误 4：把 RAG 当搜索
RAG 不只是搜索，它还包括答案生成、证据约束、权限控制和反馈闭环。
5. 完整文章
更完整的版本我放在 AI全书：
AI全书也整理了 AI 基础、大模型、Agent、MCP、AI 编程和 Prompt 等内容：
