二十七：RAG 优化自测题答案¶

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484309&idx=1&sn=f0d82d5ae8029d0faa9bca3d46c92461&chksm=f01eb0ecc76939faf3b466b9edebe2944c83015909811e4674ec00d1ef635a0ced03c0bfcebd#rd

参考资料¶

LangChain RAG tutorials: https://python.langchain.com/docs/tutorials/rag/
LangChain Query Analysis: https://python.langchain.com/docs/tutorials/query_analysis/
LangChain Contextual Compression: https://python.langchain.com/docs/how_to/contextual_compression/
LangChain MultiQueryRetriever: https://python.langchain.com/docs/how_to/MultiQueryRetriever/
LangChain Parent Document Retriever: https://python.langchain.com/docs/how_to/parent_document_retriever/
LangChain Self Query Retriever: https://python.langchain.com/docs/how_to/self_query/
LlamaIndex Advanced RAG: https://docs.llamaindex.ai/en/stable/optimizing/advanced_retrieval/advanced_retrieval/
Microsoft GraphRAG: https://microsoft.github.io/graphrag/
LangChain RAG from scratch playlist: https://www.youtube.com/playlist?list=PLaIDFEXuae2LXbO1_PKyVJiQ23ZztA0x
RAG 优化介绍: https://zhuanlan.zhihu.com/p/678893732

A. RAG 优化诊断¶

1. RAG 效果不好时，为什么不应该第一反应就是换大模型？¶

因为 RAG 错误可能来自数据缺失、chunk 切分、embedding 不适配、query 表达、检索漏召回、rerank 错误、上下文噪声、prompt 约束不足或权限问题。换大模型只可能改善生成层，无法解决正确证据没有进入上下文的问题。面试要点：先定位瓶颈，再决定换模型、改检索还是改数据。

2. 请给出 RAG 问题排查的分层诊断框架。¶

可以按数据层、切分层、索引层、查询层、召回层、排序层、上下文层、生成层、评估层排查。具体看知识是否存在、chunk 是否完整、embedding 是否适配、query 是否需要改写、top-k 是否召回正确证据、rerank 是否排前、上下文是否清晰、prompt 是否要求忠实和引用、评估是否能定位问题。

3. 如何判断一个 RAG 错误主要是检索失败还是生成失败？¶

查看最终 prompt 中是否包含支持答案的正确证据。如果没有，是检索或上下文组装失败。如果有证据但模型没用好、误读或幻觉，是生成、prompt 或上下文组织问题。这要求系统记录检索结果、rerank 结果和最终 prompt。

4. 为什么“正确证据是否进入最终 prompt”是 RAG 调试的关键问题？¶

因为 LLM 只能基于可见上下文回答。正确证据没有进入 prompt 时，模型只能依赖参数知识或猜测，容易幻觉。正确证据进入 prompt 后仍答错，才有必要重点优化 prompt 和生成模型。这是区分优化方向的分水岭。

5. RAG 中数据层常见问题有哪些？¶

包括知识库缺失、资料过期、重复版本、格式解析错误、OCR 错误、表格丢失、权限元数据缺失、文档来源不可靠、文档冲突。数据层问题会直接限制 RAG 上限。

6. RAG 中切分层常见问题有哪些？¶

chunk 过小导致上下文不完整，chunk 过大导致检索不精确；标题和章节路径丢失；表格、代码、条款被切断；overlap 不合理；父子文档映射缺失。切分应按文档类型定制并通过评估调参。

7. RAG 中检索层常见问题有哪些？¶

包括 embedding 模型不适配、相似度配置错误、top-k 太小、向量索引召回率低、query 表达不清、关键词检索缺失、metadata filter 错误、权限过滤错误。检索层目标是让正确证据稳定进入候选集。

8. RAG 中生成层常见问题有哪些？¶

包括 prompt 未限制上下文忠实性、没有拒答策略、引用格式不清、模型忽略证据、使用参数知识补全、多文档冲突时强行合并、输出格式不稳定。生成层优化要结合上下文和评估，不能孤立改 prompt。

9. 为什么 RAG 优化必须有标注评估集？¶

没有评估集只能凭主观感觉调参，容易过拟合少数案例。标注评估集能分别衡量检索、排序、生成、拒答和引用质量，让优化有方向。评估集应包含问题、标准答案和支持文档。

10. 一个好的 RAG 评估集应该包含哪些类型的问题？¶

应包含常见问题、难问题、多跳问题、无答案问题、权限问题、冲突资料问题、长上下文问题、术语/编号问题和 prompt injection 对抗问题。这样才能覆盖真实生产风险，而不是只测简单问答。

B. Query Transformation¶

11. 什么是 query rewrite？它解决什么问题？¶

query rewrite 是把用户原始问题改写成更适合检索的表达。它解决口语化、省略、指代、术语不一致和文档表达不匹配的问题。改写后的 query 应保留原意，并记录用于调试。

12. 多轮对话中 query rewrite 为什么重要？¶

多轮对话常包含“它”“这个方案”“上面那个问题”等指代。如果直接检索，query 信息不足，容易召回错误文档。 query rewrite 把当前问题改写成独立完整问题，提高检索稳定性。

13. query rewrite 可能引入什么风险？¶

风险是改变用户意图、加入错误假设、过度扩展导致检索偏移，或丢失关键约束。降低风险的方法是保留原始 query、限制改写目标、必要时同时检索原 query 和改写 query。

14. 什么是 query decomposition？适合哪些问题？¶

query decomposition 把复杂问题拆成多个子查询。适合多实体、多条件、多跳推理、多问题合并和复杂比较问题。拆分后分别检索证据，再合成答案。

15. query decomposition 和 multi-hop retrieval 有什么关系？¶

query decomposition 可以作为 multi-hop retrieval 的第一步，把一个需要多跳证据的问题拆成多个可检索子问题。multi-hop retrieval 可能进一步使用前一跳结果生成下一跳查询。两者都服务于复杂问题的证据链构建。

16. 什么是 multi-query retrieval？它的流程是什么？¶

multi-query retrieval 为同一个问题生成多个不同表达的 query，分别检索，再合并去重和 rerank。流程：

query -&gt; generate q1/q2/q3 -&gt; retrieve each -&gt; merge -&gt; deduplicate -&gt; rerank

17. multi-query retrieval 为什么能提升召回？¶

因为用户表达和文档表达可能不一致。多个 query 覆盖不同同义词、角度和术语，能增加命中正确文档的概率。它本质上用查询多样性换召回率。

18. multi-query retrieval 的成本和风险是什么？¶

成本是更多 LLM 调用或 embedding 检索，延迟和费用增加。风险是扩展 query 偏离原意，引入更多噪声，增加后续 rerank 压力。因此要配合去重、过滤和 rerank。

19. 什么是 HyDE？它的基本流程是什么？¶

HyDE 是 Hypothetical Document Embeddings。流程是先让 LLM 根据用户问题生成一个假想答案文档，再对这个假想文档做 embedding，用它检索真实文档。它把短 query 转成更接近文档风格的语义表示。

20. HyDE 为什么可能提升检索效果？¶

用户 query 往往很短，而文档是陈述式长文本。HyDE 生成的假想文档包含更多语义上下文，embedding 后可能更接近真实相关文档。对抽象问题、短 query 和文档表达差异大的场景尤其有用。

21. HyDE 可能带来哪些错误？¶

LLM 生成的假想文档可能包含错误假设或幻觉，导致检索偏向错误方向。它还增加调用成本和延迟。高风险场景应结合原始 query 检索和 rerank，避免完全依赖 HyDE。

22. 什么是 step-back retrieval？适合什么场景？¶

step-back retrieval 先把具体问题抽象成更一般的背景问题，检索原则性资料，再回到具体问题。适合概念解释、技术原理、复杂 debug 和需要背景知识的问题。风险是抽象过度，召回泛泛资料而漏掉具体细节。

23. query expansion 和 query rewrite 有什么区别？¶

query rewrite 通常把原问题改写为一个更清晰的检索 query；query expansion 会增加同义词、相关术语或多个表达，扩大召回范围。 rewrite 强调改清楚，expansion 强调扩覆盖。

24. 如果用户问题包含多个实体和多个约束，你会如何设计 query transformation？¶

先解析实体、时间、文档类型等结构化约束，生成 metadata filter；再把复杂问题拆成子问题；对每个子问题做必要 rewrite 或 multi-query；最后合并证据并 rerank。同时保留原始问题，防止改写链路偏离用户意图。

C. 高级检索与元数据过滤¶

25. 什么是 metadata filter？它在 RAG 中有什么价值？¶

metadata filter 是基于文档元数据进行过滤，例如时间、部门、文档类型、权限、语言、版本。它能提高检索精度、降低噪声，并保证权限安全。例如只检索 2024 年后的政策文档。

26. 什么是 self-query retriever？请举例说明。¶

self-query retriever 让 LLM 从自然语言问题中解析出检索 query 和结构化 filter。例如“查找 2023 年后关于报销制度的财务文档”可解析为：

query = "报销制度"
filter = department == "finance" AND updated_at &gt;= "2023-01-01"

27. self-query retriever 解析错误会造成什么问题？如何降低风险？¶

解析错误可能导致过滤过严漏召回，或过滤过宽带来噪声和权限风险。降低风险的方法包括限制 filter schema、校验解析结果、记录 filter、对低置信度查询回退到普通检索。权限 filter 应由系统强制，不应完全交给 LLM 推断。

28. hybrid search 中 dense retrieval 和 sparse retrieval 分别擅长什么？¶

dense retrieval 擅长语义相似和同义表达。sparse retrieval/BM25 擅长精确关键词、编号、错误码、API 名、产品型号、法律条款。 hybrid search 利用二者互补。

29. 什么时候应该提高 sparse/BM25 的权重？¶

当 query 包含错误码、条款号、产品型号、函数名、API 名、特定术语或精确短语时，应提高 sparse 权重。这类信息向量模型可能不如关键词匹配可靠。

30. 什么时候应该提高 dense vector retrieval 的权重？¶

当 query 是自然语言、同义改写多、用户表达和文档表达差异大，或需要语义理解时，提高 dense 权重更合适。例如“如何提升模型回答可靠性”可能对应“减少幻觉和增强忠实性”的文档。

31. RRF 融合为什么在工程上常用？¶

RRF 基于排名而不是原始分数融合，不要求不同检索器分数同尺度。它能稳定合并 BM25 和向量检索结果。一个文档在多个检索器中都靠前时，会得到更高排名。

32. hybrid search 中如何处理重复结果？¶

应基于 document_id、chunk_id、文本 hash 或父文档 ID 去重。重复结果可以合并分数、保留最高排名或合并来源信息。否则重复 chunk 会挤占 top-k，降低上下文多样性。

33. 如果企业文档中有大量错误码、API 名和产品型号，检索策略应如何调整？¶

应使用 hybrid search，提高 BM25 权重；保留大小写、符号和代码块；chunking 时不要切断 API 名和错误码；metadata 中保留产品线和版本；必要时加入精确过滤。只依赖语义向量容易漏掉精确标识符。

34. 如何根据 query 类型选择不同 retriever？¶

可以先做 query classification：编号/错误码型走 sparse 或 hybrid；概念解释型走 dense；时间/部门约束型走 metadata filter；复杂多跳型走 decomposition；权限敏感型先强制权限过滤。这比所有问题统一走同一 retriever 更稳。

D. 多向量、父文档与上下文扩展¶

35. Parent Document Retriever 的核心思想是什么？¶

用小 chunk 做 embedding 和检索，但返回对应更大的 parent document 或父章节作为上下文。小 chunk 提供精确召回，大 parent 提供完整上下文。

36. Parent Document Retriever 解决了什么矛盾？¶

解决“检索需要小粒度，生成需要完整上下文”的矛盾。小 chunk 太碎，模型缺背景；大 chunk 检索不准。父文档检索兼顾两者。

37. Parent Document Retriever 的风险是什么？¶

parent 太大会引入噪声、增加 token 成本，甚至让模型忽略关键命中片段。父子映射错误也会导致返回不相关内容。需要合理控制 parent 粒度并做上下文压缩。

38. Multi-Vector Retriever 的核心思想是什么？¶

为同一文档建立多个向量表示，例如原文、摘要、标题、假设问题、表格说明等。检索命中任一向量后，返回对应原文档。它通过多视角表示提升召回。

39. 同一文档可以生成哪些不同向量表示？¶

可以生成原文 chunk embedding、文档摘要 embedding、章节标题 embedding、由 LLM 生成的 hypothetical questions embedding、表格 caption embedding、代码函数说明 embedding。这些表示覆盖用户可能提出问题的不同方式。

40. Multi-Vector Retriever 适合什么场景？¶

适合长文档、主题多样、用户问题和原文表达差异大、表格/代码/图片说明复杂的场景。例如用户问“怎么退款”，文档标题可能是“费用结算与退订流程”，多向量能提高命中概率。

41. Multi-Vector Retriever 的成本和风险是什么？¶

成本是索引规模增加、embedding 成本增加、去重复杂。风险是摘要或假设问题引入偏差，召回噪声增加。需要合并去重和 rerank 控制质量。

42. small-to-big retrieval 的流程是什么？¶

先检索小粒度 chunk，命中后扩展到父章节、相邻段落或上下文窗口，再交给 LLM。流程：

retrieve small chunk -&gt; expand neighbor/parent -&gt; rerank/compress -&gt; generate

43. small-to-big retrieval 和 parent document retrieval 有什么关系？¶

parent document retrieval 是 small-to-big 的一种实现。二者都使用小粒度召回、大粒度生成的思想。区别是 small-to-big 更泛化，可扩展相邻 chunk、父章节或自定义窗口。

44. 相邻 chunk 合并什么时候有用？什么时候会引入噪声？¶

当答案跨越 chunk 边界、命中段落缺少前后条件时，相邻合并有用。若相邻段落主题不同或文档结构混乱，合并会引入噪声。应基于章节边界、分数和 token 预算控制合并范围。

E. Rerank、压缩与长上下文¶

45. 为什么 rerank 是提升 RAG precision 的关键环节？¶

第一阶段 retriever 追求召回，容易带来噪声。rerank 对候选进行更精细的 query-document 相关性判断，把真正相关内容排到前面，减少无关上下文进入 prompt。它对最终答案质量影响很大。

46. Cross-encoder reranker 和 bi-encoder retriever 有什么区别？¶

bi-encoder 分别编码 query 和 document，速度快，适合大规模召回。cross-encoder 把 query 和 document 一起输入模型，能建模细粒度交互，相关性判断更准但速度慢。所以常见架构是 bi-encoder 召回，cross-encoder 精排。

47. LLM reranker 的优点和缺点是什么？¶

优点是理解能力强，能处理复杂相关性、约束和语义。缺点是成本高、延迟大、输出稳定性和批处理效率不如专用 reranker。适合小候选集、高价值问题或复杂判断。

48. 为什么 reranker 通常只用于第一阶段召回后的候选？¶

reranker 计算成本高，无法对全量文档运行。先用快速 retriever 缩小候选范围，再用 reranker 精排，是质量和成本的折中。候选数要足够大以保证召回，但不能大到成本失控。

49. 什么是 contextual compression？¶

contextual compression 是在生成前压缩检索内容，只保留与 query 相关的片段或句子，删除无关内容。目标是降低 token 成本、减少噪声、突出证据。

50. contextual compression 的常见实现方式有哪些？¶

包括 LLM 抽取相关句子、embedding 句子过滤、reranker 过滤低相关 chunk、摘要压缩、规则截取和元数据过滤。不同方式在成本、忠实性和压缩率上有差异。

51. contextual compression 可能误删哪些关键信息？¶

可能误删限制条件、否定词、时间范围、例外条款、表格列名、代码上下文和引用信息。摘要式压缩还可能引入幻觉。高风险场景应保留原文引用或支持用户展开原文。

52. 长上下文模型是否意味着不再需要 RAG 优化？为什么？¶

不是。长上下文虽然能放更多文档，但成本更高、延迟更大、噪声更多，模型也可能忽略中间信息。检索、排序和上下文组织仍然重要。长上下文解决容量问题，不自动解决相关性和忠实性问题。

53. 长上下文 RAG 需要注意哪些问题？¶

注意去重、排序、章节结构、关键信息位置、引用、冲突资料、token 预算、成本、延迟和安全过滤。不要把长上下文当作粗暴塞全文的理由。

54. 如何控制最终上下文的 token 预算？¶

可以控制 top-k、合并相邻 chunk 的范围、使用 rerank、contextual compression、摘要、按相关性截断、按文档权威性排序，并为 prompt 和答案预留 token。还可以对不同 query 类型设置不同预算。

F. 多跳、GraphRAG 与忠实性¶

55. 什么是 multi-hop RAG？请举例。¶

multi-hop RAG 是需要多次检索或多个证据链才能回答的问题。例如先检索某产品的负责模块，再检索该模块的部署文档，最后回答使用了哪个数据库。单次向量检索可能只找到其中一跳，无法完成推理。

56. multi-hop RAG 中错误为什么容易累积？¶

每一跳的检索和中间答案都会影响下一跳。如果第一跳实体识别错，后续检索会沿错误方向继续，最终答案错误。因此需要记录中间证据、验证每一跳，并在不确定时停止或回退。

57. GraphRAG 的基本思想是什么？¶

GraphRAG 把文档中的实体和关系抽取成图结构，结合图检索、子图遍历或社区摘要来辅助回答复杂关系问题。它让 RAG 不只检索文本相似片段，也利用实体关系结构。

58. GraphRAG 适合什么类型的问题？¶

适合多实体关系、组织架构、供应链、论文引用网络、复杂依赖、全局概览和多跳推理问题。如果只是简单 FAQ，GraphRAG 可能过度复杂。

59. GraphRAG 的构建流程通常包括哪些步骤？¶

通常包括文档清洗、实体抽取、关系抽取、实体消歧、图构建、社区检测或摘要生成、query 实体识别、子图检索和基于图证据生成答案。每一步都可能引入错误，需要评估和更新机制。

60. GraphRAG 的成本和风险有哪些？¶

成本包括实体关系抽取、图维护、更新、存储和复杂检索。风险包括抽取错误、实体消歧错误、关系过时、摘要丢细节和系统复杂度高。只有关系结构能显著提升效果时才值得引入。

61. RAG 幻觉有哪些常见形式？¶

包括上下文无答案但模型编造、答案部分来自上下文部分来自先验、引用不支持结论、数字日期错误、多文档冲突时强行合并、把检索文档中的恶意指令当规则。 RAG 幻觉比普通幻觉更隐蔽，因为它可能带有看似可信的引用。

62. 什么是 faithfulness？如何评估？¶

faithfulness 指答案中的声明是否被给定上下文支持。评估可以人工标注，也可以用 LLM judge 或规则检查，把答案拆成 claims，逐条判断是否有证据支持。它不同于 factual correctness，后者关注真实世界是否正确。

63. citation verification 要检查什么？¶

要检查引用 ID 是否存在、引用内容是否与答案声明对应、是否支持关键结论、是否遗漏必要引用、是否引用了无关文档。引用不是装饰，而是证据链。

64. 如果引用存在但不支持答案，应该如何处理？¶

应判定为 citation failure 或 unfaithful answer。系统可以要求模型重答、移除无证据声明、重新检索，或在高风险场景转人工审核。评估中要把“有引用”和“引用支持结论”分开统计。

G. 生产化、安全与综合设计¶

65. 生产 RAG 系统应该记录哪些日志？¶

应记录原始 query、改写 query、metadata filter、检索结果和分数、rerank 结果、最终上下文、prompt 版本、模型版本、答案、引用、用户反馈、延迟、成本和错误信息。这些日志用于回放、排错、评估和审计。

66. RAG 系统有哪些常见缓存策略？¶

包括 embedding cache、query rewrite cache、retrieval cache、rerank cache、prompt cache、最终答案 cache 和热门问题 FAQ cache。缓存能降低成本和延迟，但要处理权限、版本更新和过期失效。

67. RAG 中 indirect prompt injection 是什么？如何防护？¶

indirect prompt injection 是检索文档或外部网页中包含恶意指令，诱导模型忽略系统规则、泄露数据或调用工具。防护包括把检索内容标记为数据、系统提示明确文档指令无效、工具权限控制、敏感数据隔离、安全扫描、输出审查和高风险操作人工确认。

68. 为什么 RAG 权限过滤必须在检索阶段完成？¶

因为只要无权文档进入 prompt，模型就可能泄露其中信息。prompt 约束不能保证绝不输出。正确做法是在检索前或检索时基于用户身份过滤索引结果，并对日志和引用也做权限保护。

69. 请给出一个从基础 RAG 到高级 RAG 的优化路线图。¶

路线图：先建立评估集；清洗知识库和元数据；调 chunk size/overlap；评估 embedding；加入 hybrid search；加入 query rewrite 和指代消解；提高 first-stage top-k；加入 reranker；优化上下文去重和合并；加入拒答和 citation verification；复杂问题加入 decomposition/multi-hop/GraphRAG；上线缓存、监控、权限和成本控制。核心是评估驱动，而不是一次堆满所有组件。

70. 请设计一个面向企业内部知识库的高质量 RAG 系统，并说明检索、重排、上下文、生成、安全、评估和成本控制方案。¶

系统设计可以分为离线和在线。离线加载 Feishu/Confluence/PDF/Markdown，清洗去重，按标题结构切分，保留权限、部门、时间、URL 等元数据，生成 embedding，建立向量索引和 BM25 索引，支持增量更新。在线先做用户鉴权和 query rewrite，解析 metadata filter；根据 query 类型走 dense、sparse 或 hybrid search；召回 top 50 后用 reranker 精排；对相邻 chunk 合并、去重、必要时 contextual compression；组装带 doc_id、标题、来源的上下文；LLM prompt 要求只根据上下文回答、资料不足拒答、关键结论引用；输出后做 citation verification 和安全审查。评估上建立包含普通、多跳、无答案、权限、冲突和注入样本的测试集，分别监控 Recall@k、nDCG、faithfulness、citation accuracy、拒答准确率和用户反馈。成本上使用 embedding/retrieval/cache，控制 top-k 和上下文长度，对高频问题缓存答案，对复杂查询才启用 multi-query 或 LLM rerank。

            预览时标签不可点




































<div class="