RAG 进阶与优化
朴素 RAG 在真实场景常常召回不准、答非所问。本文系统梳理「检索前-检索中-检索后」三段优化、高级 RAG 范式与评估方法，是进阶面试的高频深水区。基础流程见 RAG 基础，向量检索原理见 Embedding 与向量库。
一、朴素 RAG 的常见问题
- 召回内容不相关或缺失关键信息；
- query 与文档表述不一致导致召回失败（语义鸿沟）；
- 切分不当导致上下文断裂；
- 检索到太多无关内容稀释了有效信息；
- 多跳问题（需综合多个文档）回答不好；
- 召回相关但不足以回答。
优化框架：从**检索前（Pre-retrieval）、检索中（Retrieval）、检索后（Post-retrieval）**三个环节切入，对症下药。
二、检索前优化：让 query 更好检索
核心是弥补「用户问法」和「文档写法」之间的语义鸿沟：
- Query Rewriting / 扩展：用 LLM 改写、澄清、扩展用户问题。
- HyDE（假设性文档嵌入）：先让 LLM 生成一个「假想答案」，再用它去检索——因为答案和文档在语义空间比「问题和文档」更接近。
- Multi-Query：让 LLM 把一个问题拆成多个子查询，分别检索后合并，提升召回覆盖。
- Step-back Prompting：先退一步问更抽象的问题，召回背景知识，再回答具体问题。
- 路由（Routing）：多知识库时，先判断该查哪个库/用哪种检索。
三、检索中优化：召回得更准
混合检索（Hybrid Search）★
结合两种检索互补：
- 稠密检索（向量）：擅长语义相似（同义、改写）。
- 稀疏检索（BM25/关键词）：擅长精确匹配专有名词、术语、编号、罕见词。
用 RRF（Reciprocal Rank Fusion，倒数排名融合） 等方式融合两路结果。当 query 含具体术语/编号时，纯向量常失灵，混合检索是高性价比的救命手段。
其他
- 元数据过滤：结合时间、来源、标签、权限等结构化条件，缩小检索范围、提精度。
- 更优的切分：父子分块（小块用于精准检索、命中后返回所在大块给 LLM）、按语义/标题层级切分。
四、检索后优化：精排与精炼
- Rerank（重排）★：用 cross-encoder 对召回的几十条结果精排，只保留最相关的少数 chunk。性价比极高的一步（见 Embedding 与向量库 的 bi/cross-encoder）。
- 上下文压缩 / 过滤：去掉检索结果中的无关句子，只留与问题相关的内容，节省上下文并减少干扰。
- 重排位置：把最相关内容放在 prompt 首尾，缓解 lost in the middle。
五、高级 RAG 范式
| 范式 | 思路 | 适合 |
|---|---|---|
| 多路召回 + 融合 | 多种检索器并行召回再融合 | 提升覆盖 |
| Self-RAG | 模型自行判断是否需检索、结果是否有用、答案是否有依据 | 减少无谓检索、提质 |
| CRAG（纠正式） | 评估检索质量，差则触发重检索/网搜 | 鲁棒性 |
| GraphRAG | 构建知识图谱，按实体关系检索 | 跨文档关联、全局总结 |
| Agentic RAG | 把检索当作 Agent 工具，自主决定何时/检索什么/是否多轮 | 复杂多跳、推理型问题 |
趋势：从「固定流水线」走向「模型自主决策的 Agentic RAG」——让模型自己判断要不要查、查几次、查完够不够。
六、RAG 评估
分两部分评估（这是面试必答的结构）：
- 检索质量：命中率（Hit Rate）、MRR、召回率、上下文相关性（Context Relevance）、上下文精确率。
- 生成质量：
- 忠实度（Faithfulness）：回答是否忠于检索内容（不编造）。
- 答案相关性（Answer Relevance）：回答是否切题。
常用框架：RAGAS、TruLens，多用 LLM-as-a-Judge 自动评测。建评测集 + 量化指标 + bad case 分析 + 持续迭代 是 RAG 工程化的关键。
七、高频追问
Q：RAG 优化从哪几个环节入手？ 检索前（查询改写/HyDE/Multi-Query/路由）、检索中（混合检索/元数据过滤/父子分块）、检索后（Rerank/上下文压缩/重排位置）。先定位问题在检索还是生成，再对症下药。
Q：HyDE 为什么有效？ 用户问题和文档的表述差异大（问题 vs 陈述），直接检索易错配；HyDE 先让 LLM 生成一个「假想答案」再去检索，答案和文档同为陈述句、语义更接近，召回更准。即使假想答案有错，其语义方向通常对。
Q：混合检索为什么有用？怎么融合？ 稠密向量擅长语义、稀疏 BM25 擅长精确匹配术语/编号，二者互补。用 RRF（倒数排名融合）等把两路排名合并。当 query 含专有名词或编号时尤其关键。
Q：召回率高但回答还是差，问题在哪？ 多半在生成环节：上下文过长稀释信息、相关内容位置不佳（lost in middle）、prompt 模板差，或检索内容虽相关但不足以回答（需多跳/补充检索）。
Q：chunk 大小怎么定？ 没有银弹，需实验。常见 256~512 token + 10~20% 重叠；可用父子分块兼顾检索精度与上下文完整。
Q：什么是 Agentic RAG？ 把检索当作 Agent 可调用的工具，让模型自主决定何时检索、检索什么、是否需要多轮检索、检索够不够再补。适合复杂多跳和推理型问题，是 RAG 与 Agent 的融合趋势。
Q：怎么评估 RAG 系统？ 分检索（命中率/MRR/上下文相关性）和生成（忠实度/答案相关性）两部分，用 RAGAS 等 LLM-as-a-Judge 自动评测，并建评测集做 bad case 分析和持续迭代。
Q：GraphRAG 解决什么问题？ 朴素 RAG 按片段检索，难处理「需要跨多个文档综合」或「全局总结」的问题。GraphRAG 先抽取实体和关系构建知识图谱，按图结构检索，擅长跨文档关联和宏观总结，代价是构建成本高。