二十六：RAG自测题答案¶

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484292&idx=1&sn=40c49db1cf34c9528b9d9d260051ab6a&chksm=f01eb0fdc76939ebecc663a64ffb5c0c126e1bda15c635a3306186b710ca8ed6346ad1dd7a24#rd

参考资料¶

LangChain RAG tutorials: https://python.langchain.com/docs/tutorials/rag/
LangChain RAG from scratch playlist: https://www.youtube.com/playlist?list=PLaIDFEXuae2LXbO1_PKyVJiQ23ZztA0x
Retrieval-Augmented Generation paper: https://arxiv.org/abs/2005.11401
Lewis et al. RAG paper page: https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html
LlamaIndex RAG docs: https://docs.llamaindex.ai/en/stable/understanding/rag/
FAISS documentation: https://faiss.ai/
CSDN RAG 基础概念讲解: https://blog.csdn.net/2401_82452722/article/details/135934144

A. RAG 基础概念¶

1. 什么是 RAG？它的核心思想是什么？¶

RAG 是 Retrieval-Augmented Generation，即检索增强生成。核心思想是在生成答案前，先从外部知识库检索相关资料，再把资料作为上下文交给大模型生成答案。它把知识更新和证据存储放在外部检索系统，把语言理解、归纳和表达交给 LLM。

2. RAG 主要解决大模型的哪些问题？¶

主要解决知识过时、无法访问私有数据、答案不可追溯、容易幻觉和知识更新成本高的问题。 RAG 不是让模型“记住”知识，而是在推理时把相关知识取出来给模型使用。

3. 请画出或描述一个基础 RAG 系统的完整流程。¶

基础流程：

离线：Documents -&gt; Load -&gt; Clean -&gt; Split -&gt; Embed -&gt; Index
在线：Query -&gt; Rewrite/Embed -&gt; Retrieve -&gt; Rerank -&gt; Context -&gt; Prompt -&gt; LLM -&gt; Answer

关键是离线把文档变成可检索索引，在线把用户问题变成检索请求，并把检索结果转成可回答上下文。

4. RAG 和直接把问题发给 LLM 有什么区别？¶

直接问 LLM 依赖模型参数知识，可能过时、缺少私有知识且不可追溯。RAG 会把外部资料放入上下文，让答案基于可更新、可引用的知识库。因此 RAG 更适合企业知识、技术文档、法规制度等需要证据的问题。

5. RAG 和微调分别适合解决什么问题？¶

RAG 适合注入外部知识、实时知识、私有知识和可追溯证据。微调适合改变模型行为、稳定输出格式、学习风格和领域任务模式。知识频繁变化优先 RAG；输出行为长期稳定且样本充足，可以考虑微调。两者也可以组合。

6. 哪些业务场景适合使用 RAG？¶

适合企业知识库问答、客服知识库、技术文档问答、合同条款问答、论文阅读助手、产品手册查询、内部制度查询和需要引用来源的场景。共同特征是答案依赖外部文本资料，且资料需要更新或可追溯。

7. 哪些场景不适合优先使用 RAG？¶

不依赖外部知识的创意写作、纯格式转换、稳定风格学习、检索库质量极差、需要强业务流程控制但资料不足的场景，不一定优先 RAG。如果问题是模型输出格式不稳，可能微调或结构化输出更合适；如果问题是数据质量差，RAG 也救不了。

8. 为什么说 RAG 不等于“接一个向量数据库”？¶

向量库只是 RAG 的检索存储组件。完整 RAG 还包括文档加载、清洗、切分、embedding、query 处理、hybrid search、rerank、上下文组装、prompt、引用、权限和评估。只接向量库但不做评估和上下文设计，通常效果不稳定。

9. RAG 系统中离线阶段和在线阶段分别做什么？¶

离线阶段处理知识库：加载文档、清洗、切分、生成 embedding、写入索引和元数据。在线阶段处理用户问题：query 改写、检索、重排、上下文组装、调用 LLM 生成答案。离线决定知识可检索性，在线决定答案相关性和用户体验。

10. RAG 的上限为什么很大程度由知识库质量决定？¶

如果知识库缺失、过时、重复、格式混乱或权限错误，检索系统就无法提供正确证据。LLM 只能基于给定上下文生成，不能可靠弥补知识库缺陷。 RAG 的常见原则是 garbage in, garbage out。

B. 文档加载、清洗与元数据¶

11. RAG 常见数据源有哪些？¶

包括 PDF、Word、Markdown、HTML、TXT、数据库、Wiki、Feishu、Confluence、Notion、API 文档、代码仓库、FAQ、工单和聊天记录。不同数据源的结构不同，加载和切分策略也应不同。

12. 文档加载阶段为什么要保留元数据？¶

元数据用于引用、过滤、权限控制、排序、去重、调试和增量更新。没有元数据，即使召回了正确文本，也难以告诉用户来源或判断是否有权限访问。生产 RAG 中元数据和正文同等重要。

13. RAG 中常见元数据字段有哪些？¶

常见字段包括 document_id、chunk_id、title、section_path、source_url、file_path、page_number、author、created_at、updated_at、version、permission、department、language。字段设计应服务于业务过滤和引用需求。

14. 文档清洗的目标是什么？¶

目标是去除噪声、保留语义结构，让 chunk 内容更适合检索和生成。清洗后文本应更接近人类阅读资料，而不是保留大量导航栏、页眉页脚和乱码。同时要保留标题、表格列名、条款编号等关键信息。

15. 文档清洗中常见噪声有哪些？¶

16. 为什么文档清洗不能过度？¶

过度清洗可能删除语义结构和证据，例如法律条款编号、表格标题、代码缩进、公式符号和章节路径。这会让模型无法引用或误解内容。清洗应以“减少噪声、保留结构”为原则。

17. PDF、网页、Markdown、代码仓库在加载时分别有什么特殊注意点？¶

PDF 要注意页码、表格、断行、页眉页脚和 OCR。网页要去掉导航广告但保留标题层级。Markdown 要保留 heading、代码块和列表。代码仓库应按语言结构切分，保留文件路径、函数名和依赖关系。不同格式不能用完全相同的加载器粗暴处理。

18. 为什么去重对 RAG 很重要？¶

重复文档会占用索引空间，导致检索结果被重复内容刷屏，降低上下文多样性。重复版本还可能引入冲突信息。去重可以在文档级、段落级、chunk 级进行，并保留最新或权威版本。

19. 权限信息为什么应该作为元数据进入索引系统？¶

因为 RAG 检索阶段必须先做权限过滤，确保用户只能检索到有权访问的 chunk。否则即使最终答案不直接显示原文，也可能泄露敏感信息。权限控制不能只靠 prompt 说“不要泄露”。

20. 如果文档更新时间不同，RAG 系统应该如何处理？¶

应保留更新时间和版本号，支持增量索引、过期文档下线、同源多版本去重，并在排序时优先新版本或权威版本。如果答案依赖时间，应在生成中说明资料日期。

C. Chunking 与文档切分¶

21. 什么是 chunk？为什么 RAG 需要 chunking？¶

chunk 是从文档中切出来的较小文本片段。RAG 需要 chunking 是因为原始文档太长，无法直接高效检索或放入 LLM 上下文。 chunk 是检索的基本单位，切分质量直接影响召回和答案完整性。

22. 常见 chunking 策略有哪些？¶

包括固定长度切分、递归切分、语义切分、按标题结构切分、按页面切分、表格行/块切分、代码函数/类切分。实际项目通常结合结构优先和长度兜底。

23. 固定长度切分的优点和缺点是什么？¶

优点是简单、稳定、容易实现。缺点是可能切断语义单元，把标题和正文分开，或把一个答案分散到多个 chunk。它适合作为 baseline，但通常不是最终最优策略。

24. 递归切分相比固定长度切分有什么优势？¶

递归切分优先按自然结构切分，如标题、段落、句子，只有超过长度时才继续切。它更容易保留语义完整性。例如 Markdown 文档按标题和段落切，比每 500 字硬切更适合检索。

25. 语义切分适合什么场景？¶

适合长段落、报告、论文和主题自然变化明显的文本。它根据语义相似度或主题边界切分，能让每个 chunk 更聚焦。缺点是实现成本较高，且需要评估切分质量。

26. 代码、法律合同、FAQ、技术文档分别适合怎样切分？¶

代码适合按文件、类、函数切分，保留路径和符号。法律合同适合按条款、子条款切分，保留编号。FAQ 适合问题-答案成对切分。技术文档适合按标题层级和段落切分。切分策略应匹配文档结构，而不是统一固定长度。

27. chunk 太小会带来什么问题？¶

chunk 太小会缺少上下文，导致召回片段无法独立回答问题。模型可能需要的信息分散在多个 chunk 中，增加漏召回和拼接难度。例如只召回一个定义句，但缺少适用条件和限制。

28. chunk 太大会带来什么问题？¶

chunk 太大会降低检索精度，embedding 表示变得混杂；同时占用更多 prompt token，引入无关噪声，减少可放入的候选数量。大 chunk 还会提高 rerank 和 LLM 成本。

29. overlap 的作用是什么？¶

overlap 用于保留跨 chunk 边界的信息，防止一句话或一个概念被切断后无法检索完整。它对段落硬切、固定长度切分尤其有用。

30. overlap 太大或太小分别有什么风险？¶

太小可能丢失跨边界上下文；太大则导致索引冗余、重复召回、成本增加，并可能让多个相似 chunk 挤占 top-k。 overlap 应根据文档结构和答案跨度调节。

31. 如何为一个企业知识库选择初始 chunk size？¶

可以从中等大小开始，例如 300-800 tokens，并根据文档类型调整。FAQ 可更小，政策和技术文档可更大。然后用标准问题集评估 Recall@k、答案正确性和上下文噪声。不要只凭经验，应通过检索评估调参。

32. 为什么标题层级和章节路径对 chunk 很重要？¶

标题层级提供语义上下文。单独一个段落可能说“该功能默认关闭”，但不知道是哪项功能；加上章节路径后模型和检索器更容易理解。标题也有助于引用和用户核查来源。

D. Embedding、向量索引与检索¶

33. embedding 模型在 RAG 中承担什么作用？¶

embedding 模型把 query 和 chunk 映射到同一个向量空间，使语义相近的文本距离更近。检索时通过相似度找到最相关 chunk。它决定了语义召回能力，是 RAG 的核心组件之一。

34. 选择 embedding 模型时应该考虑哪些因素？¶

考虑语言支持、领域适配、向量维度、最大输入长度、检索效果、吞吐、延迟、成本、部署方式和是否支持 query/document 指令。中文企业知识库应优先评估中文和领域术语表现。

35. query embedding 和 document embedding 是什么？¶

query embedding 是用户问题的向量表示，document embedding 是文档 chunk 的向量表示。检索时计算二者相似度。有些 embedding 模型对 query 和 document 使用不同指令前缀，以优化检索效果。

36. cosine similarity、dot product、Euclidean distance 有什么区别？¶

cosine 衡量向量方向相似度；dot product 同时受方向和模长影响；Euclidean distance 衡量几何距离。选择哪个指标要与 embedding 模型训练目标和索引配置一致。

37. 为什么向量归一化后 cosine similarity 和 dot product 排序可能等价？¶

如果所有向量都归一化为单位长度，则：

cos(q, d) = q · d / (||q|| ||d||) = q · d

因此 cosine 和 dot product 的排序等价。这也是很多向量检索系统归一化后使用内积搜索的原因。

38. 什么是向量索引？为什么大规模数据不能总是暴力搜索？¶

向量索引用于快速查找近邻向量。暴力搜索需要计算 query 和所有文档向量的相似度，数据量大时延迟和成本太高。 ANN 索引用少量精度损失换取大幅查询加速。

39. Flat、HNSW、IVF、PQ 的基本思想分别是什么？¶

Flat 是精确搜索，遍历所有向量。HNSW 是图索引，通过多层近邻图快速搜索。IVF 是聚类倒排，先找相关簇再在簇内搜索。PQ 是向量量化，压缩向量以降低内存和加速搜索。不同索引在召回率、延迟、内存和构建成本之间权衡。

40. 选择向量数据库时应考虑哪些工程因素？¶

考虑数据规模、查询延迟、过滤能力、增量更新、删除、备份、权限、多租户、混合检索、可观测性、部署成本和生态集成。小规模原型可以用本地 FAISS/Chroma，大规模生产可能需要 Milvus、Qdrant、Weaviate 或云服务。

41. top-k 检索中的 k 如何影响召回和噪声？¶

k 越大，召回正确文档的概率越高，但噪声也越多，后续上下文更长、成本更高。k 越小，precision 可能高，但容易漏掉关键证据。常见做法是第一阶段取较大 k，再 rerank 选较少文档进入 prompt。

42. 为什么向量检索可能搜不到包含关键词的正确文档？¶

向量检索关注语义相似，不一定重视精确字符串、编号、代码符号、产品型号和罕见术语。如果 query 和文档语义表达差异大或 embedding 模型不懂领域词，也会漏召回。这时需要 BM25、hybrid search 或领域 embedding。

43. BM25/关键词检索相比向量检索有什么优势？¶

BM25 对精确词匹配、编号、术语、错误码、API 名称、产品型号和法律条款编号很强，且可解释性较好。但它对同义改写和语义相似不如向量检索。

44. 什么是 hybrid search？适合哪些场景？¶

hybrid search 结合向量检索和关键词检索，利用语义召回和精确匹配互补。适合技术文档、法律条款、API 文档、产品手册和企业知识库。实现方式包括分别召回再融合、分数加权、RRF 或先过滤后向量检索。

45. RRF 融合的直觉是什么？¶

RRF, Reciprocal Rank Fusion, 根据结果在不同检索器中的排名进行融合。一个文档如果在多个检索器中排名都靠前，会得到更高融合分。它不要求不同检索器分数同尺度，因此工程上稳定好用。

E. Query 处理、Rerank 与上下文组装¶

46. 为什么用户 query 进入检索前常需要改写？¶

用户问题可能口语化、带省略、包含指代、多意图或和文档措辞不一致。改写可以补全上下文、标准化术语、拆分子问题，提高检索召回。多轮 RAG 中 query rewrite 尤其重要。

47. 多轮对话中的指代消解对 RAG 有什么价值？¶

用户经常说“它”“这个功能”“上面那个方案”。如果不消解，检索器不知道指代对象，容易召回错误文档。把问题改写成独立问题能显著提升检索稳定性。

48. query expansion 是什么？可能带来什么风险？¶

query expansion 是给原始 query 增加同义词、相关术语或多个改写版本，以提高召回。风险是扩展过宽导致噪声增加，甚至偏离用户真实意图。因此扩展后通常需要 rerank 或过滤。

49. 如果用户一次问多个问题，RAG 检索应该如何处理？¶

可以先拆分成多个子问题，分别检索，再合并证据和答案。否则一个 embedding 可能混合多个意图，导致每个问题都召回不准。生成时也应按子问题组织答案。

50. 什么是 reranker？它和 embedding retriever 有什么区别？¶

embedding retriever 通常是 bi-encoder，query 和文档分别编码，速度快，适合大规模召回。reranker 通常让 query 和候选文档共同输入模型，进行更细粒度相关性判断，速度慢但精度高。所以常用 retriever 召回、reranker 精排。

51. 为什么常见流程是 retrieve top 50 再 rerank top 5？¶

第一阶段取 top 50 保证召回率，第二阶段用 reranker 提高 precision，最后只把 top 5 左右高质量上下文给 LLM，控制 token 和噪声。具体数字要通过评估调参。

52. reranker 能否弥补第一阶段召回失败？为什么？¶

不能。如果正确文档没有进入候选集，reranker 无法看到它，也就无法把它排到前面。因此 RAG 优化要先保证召回，再优化排序。

53. 上下文组装时应考虑哪些因素？¶

要考虑相关性排序、去重、相邻 chunk 合并、标题来源保留、token 预算、引用 ID、权限过滤、时间版本、冲突信息和格式清晰度。上下文不是简单拼接 top-k，组织方式会影响模型是否能正确使用证据。

54. 为什么上下文中要保留 doc_id、标题和来源？¶

doc_id 支持引用和追踪，标题提供语义背景，来源便于用户核查和系统调试。没有这些信息，模型可能给出无法追溯的答案，也难以做 citation 评估。

55. 检索结果中多个 chunk 重复或相邻时应该如何处理？¶

可以去重、合并相邻 chunk、保留最高分 chunk 并补充上下文窗口。这样能减少重复信息占用 prompt，同时恢复被切分打断的上下文。处理时要保留来源和位置，避免引用混乱。

56. 如果检索结果互相矛盾，生成阶段应该如何处理？¶

应让模型指出冲突，优先依据更权威或更新的来源，必要时给出不确定结论。不能强行编造一个看似确定的答案。上下文组装阶段也可以按版本、时间、权限和权威性过滤冲突资料。

F. 生成、引用与评估¶

57. RAG 生成 prompt 应包含哪些关键规则？¶

应包含角色、只基于上下文回答、资料不足时拒答、引用格式、输出结构、安全边界和用户问题。例如要求“每个关键结论都引用 doc_id；上下文不足时说明无法确定”。

58. 为什么 RAG prompt 要明确资料不足时的拒答策略？¶

没有拒答策略时，模型倾向于根据先验补全答案，产生幻觉。明确拒答能让系统在检索不足时诚实表达不确定性。好的拒答还应说明缺少什么信息，方便用户补充或系统改进检索。

59. citation 在 RAG 答案中有什么作用？¶

citation 让答案可追溯，便于用户验证，也便于系统评估答案是否被证据支持。但引用必须真实支持对应结论，不能只是随便附一个相关文档 ID。

60. 什么是答案忠实性？它和答案正确性有什么区别？¶

忠实性指答案是否被给定上下文支持。正确性指答案是否符合真实世界事实。一个答案可能真实正确，但如果不在上下文中，就对 RAG 任务不忠实；也可能忠实复述了过时资料，但真实世界已经变化。

61. RAG 检索评估常用指标有哪些？¶

常用指标包括 Recall@k、Precision@k、MRR、nDCG、Hit Rate。它们用于衡量正确证据是否被召回以及排序是否靠前。需要有标注好的问题和支持文档。

62. Recall@k 和 Precision@k 分别衡量什么？¶

Recall@k 衡量 top-k 中是否覆盖了应召回的相关文档，关注漏召回。Precision@k 衡量 top-k 中有多少比例是相关文档，关注噪声。 RAG 通常先重视 Recall@k，因为漏召回后生成阶段无法补救。

63. MRR 和 nDCG 适合衡量什么？¶

MRR 衡量第一个相关结果出现得有多靠前，适合单个关键文档的问答。nDCG 考虑多个相关文档及其相关性等级，适合多证据排序评估。它们比单纯 hit rate 更关注排序质量。

64. RAG 生成评估常用指标有哪些？¶

包括答案正确性、完整性、忠实性、引用准确率、拒答准确率、格式合规率、安全性、可读性和用户满意度。开放问答中常需要人工评估或 LLM-as-judge，但要防止评估偏差。

65. 为什么端到端答案错误时要区分检索失败和生成失败？¶

如果正确证据没被召回，是检索问题；如果正确证据在上下文中但模型没用好，是生成或 prompt 问题。两者优化方向完全不同。不拆分诊断容易盲目改 prompt，却忽略检索召回不足。

66. 如果 RAG 系统经常幻觉，应该从哪些层面排查？¶

检查检索是否召回正确证据、上下文是否噪声过多、prompt 是否要求只基于上下文、是否有拒答策略、引用是否校验、模型是否被要求给确定答案。还要检查知识库是否缺失答案。如果没有证据，应让系统拒答。

67. 如果 RAG 系统经常答“资料不足”，可能是什么原因？¶

可能是检索召回差、chunk 切分不合理、embedding 模型不适合、top-k 太小、reranker 过于严格、prompt 拒答规则过强或知识库确实缺失。排查时先看检索结果中是否有答案，再判断生成策略。

68. 如果用户无权访问某些文档，RAG 系统应如何保证不泄露？¶

应在检索前或检索时基于用户身份做权限过滤，确保无权 chunk 不进入上下文。还要避免日志和引用泄露文档标题或摘要。不能依赖 prompt 告诉模型“不要泄露”，因为模型一旦看到敏感上下文就有泄露风险。

69. 请设计一个最小可用的企业知识库 RAG 系统。¶

最小系统包括：文档连接器加载内部文档；清洗并按标题/段落切分；生成 embedding；存入向量库和元数据；用户 query 做 embedding；检索 top-k；可选 rerank；组装带 doc_id 的上下文；LLM 按“只基于上下文回答并引用来源”生成答案；记录日志和用户反馈。生产化还要加入权限过滤、增量更新、评估集、监控和回滚。

70. 请系统比较 RAG 基础链路中数据、切分、embedding、检索、rerank、prompt、评估各环节的主要风险和优化方向。¶

数据层风险是缺失、过时、重复、格式差和权限错误；优化方向是清洗、去重、元数据和增量更新。切分风险是粒度过大或过小；优化方向是结构化切分、overlap 和按类型定制。 embedding 风险是领域不适配；优化方向是模型评测、领域 embedding 或微调。检索风险是漏召回或噪声多；优化方向是 top-k、hybrid search、query rewrite。rerank 风险是成本高或误排；优化方向是两阶段召回和评估调参。prompt 风险是幻觉和引用不忠实；优化方向是上下文约束、拒答和 citation。评估风险是只看最终答案；优化方向是拆分检索指标和生成指标，建立标准问答集。

            预览时标签不可点




































<div class="