【2026年7月最新】69道RAG面试题

前言

RAG本身的概念还是很容易理解的，既： 索引→检索→生成→评估 四个环节串联，但是在实际的开发项目中还是经常遇到一些问题，而最好的方式就是通过面试题的形式进行记忆和查找，以点带线，以线促面，以下面试题基于实际开发项目以及我们要想掌握RAG必须会的。ps:建议学习一下milvus的使用

典型的RAG项目架构参考：

RAG 面试 69 题附完整答案可以点击目录进行跳转

目录

项目背景与选型

1. 帮助谁解决了什么问题？为什么做这个项目？
2. 系统的每天使用量是多少？
3. [为什么不用工具，要选择代码开发？coze 和 dify 不能实现需求吗？](#为什么不用工具，要选择代码开发？coze 和 dify 不能实现需求吗？)
4. 调研过哪些文档知识库工具？
5. 离线知识库的规模有多大？
6. 如何做知识库版本管理？
7. 怎么做知识溯源？

RAG 基础概念

8. [什么是 RAG？它解决了大模型的哪些问题？](#什么是 RAG？它解决了大模型的哪些问题？)
9. [RAG 的完整工作流程是什么？](#RAG 的完整工作流程是什么？)
10. [RAG 和模型微调有什么区别？如何选择？](#RAG 和模型微调有什么区别？如何选择？)
11. [为什么需要微调？Prompt 或 RAG 不行吗？](#为什么需要微调？Prompt 或 RAG 不行吗？)
12. [如何结合 RAG 和 Fine-tuning 提升提示词效果？](#如何结合 RAG 和 Fine-tuning 提升提示词效果？)
13. [什么是 Advanced RAG？什么是 Modular RAG？](#什么是 Advanced RAG？什么是 Modular RAG？)
14. [Spring AI 的模块化 RAG 架构是什么？](#Spring AI 的模块化 RAG 架构是什么？)
15. [在 LangChain 中如何实现 RAG 应用？](#在 LangChain 中如何实现 RAG 应用？)

文档处理与知识库治理

16. [RAG 的文档处理流程是怎样的？](#RAG 的文档处理流程是怎样的？)
17. 索引流程中的文档解析怎么做？
18. 用什么框架解析文档？为什么不用第三方集成工具？
19. [LangChain 如何处理 PDF 表格数据召回？](#LangChain 如何处理 PDF 表格数据召回？)
20. [PDF 中的图片怎么处理？](#PDF 中的图片怎么处理？)
21. [PDF 中复杂表格如何处理？](#PDF 中复杂表格如何处理？)
22. 什么是分块？为什么需要分块？
23. 常见分块策略有哪些？
24. [中文文档 chunk_size 和 overlap 如何设置？](#中文文档 chunk_size 和 overlap 如何设置？)
25. [父块大小 1000 是怎么定的？](#父块大小 1000 是怎么定的？)
26. 怎么评估知识库分块是否切坏？

Embedding 与向量化

27. [什么是 Embedding？它如何工作？](#什么是 Embedding？它如何工作？)
28. [常见 Embedding 模型有哪些？](#常见 Embedding 模型有哪些？)
29. [如何选择合适的 Embedding 模型？](#如何选择合适的 Embedding 模型？)
30. [Bert 模型能不能用于 embedding？](#Bert 模型能不能用于 embedding？)
31. [你们使用什么 embedding 模型？为什么？](#你们使用什么 embedding 模型？为什么？)

向量数据库

32. [RAG 为什么需要向量数据库？](#RAG 为什么需要向量数据库？)
33. [如何选择向量数据库？Milvus、Pinecone、Chroma 怎么选？](#如何选择向量数据库？Milvus、Pinecone、Chroma 怎么选？)
34. 如何实现向量数据库增量更新？

检索策略与优化

35. 什么是混合检索？如何实现？
36. [什么是 Rerank？为什么需要？如何实现？](#什么是 Rerank？为什么需要？如何实现？)
37. [Top-K 是什么意思？K 值如何确定？](#Top-K 是什么意思？K 值如何确定？)
38. 相似度阈值如何设置？
39. 如何利用元数据过滤提升检索精度？
40. 什么是查询扩展？为什么需要？
41. 什么是自查询？为什么需要？
42. 什么是查询重写？如何优化检索？
43. 检索不到相关文档怎么办？
44. [召回结果和 query 意图不匹配怎么改？](#召回结果和 query 意图不匹配怎么改？)
45. [如何优化 RAG 检索效果？](#如何优化 RAG 检索效果？)
46. [HyDE 是什么？举例说明](#HyDE 是什么？举例说明)
47. 子查询检索是什么？举例说明
48. 回溯检索是什么？适用什么场景？
49. [BM25 是什么？和 TF-IDF 有什么区别？](#BM25 是什么？和 TF-IDF 有什么区别？)
50. 检索效果不好可能哪里出问题？如何优化？
51. 检索内容过长或相关性低怎么优化？

查询处理与意图识别

52. [用户 query 随意或不清楚怎么处理？](#用户 query 随意或不清楚怎么处理？)
53. 为什么要做意图识别？
54. [为什么用 Bert，不直接用大模型做意图识别？](#为什么用 Bert，不直接用大模型做意图识别？)
55. 意图识别具体怎么做？
56. 意图分类错了会怎样？测试过吗？

生成与提示工程

57. [RAG 中如何设计 Prompt？](#RAG 中如何设计 Prompt？)
58. 什么是提示压缩？为什么需要？
59. 提示工程有什么心得和技巧？
60. [如何减少 RAG 幻觉？](#如何减少 RAG 幻觉？)
61. 如何标注信息来源和引用？
62. 如何从根本上缓解幻觉和知识缺乏？

效果评估与调优

63. [如何进行 RAG 调优后的效果评估？](#如何进行 RAG 调优后的效果评估？)
64. [如何评估 RAG 系统效果？检索和生成分别看什么？](#如何评估 RAG 系统效果？检索和生成分别看什么？)
65. [如何评估 LangChain RAG 应用效果？](#如何评估 LangChain RAG 应用效果？)
66. 检索效果如何评估？

生产环境与工程实践

67. 生产环境如何优化性能和降低成本？
68. [RAG 中如何计算文本相似度？](#RAG 中如何计算文本相似度？)
69. 多个知识库时如何兼顾效率、准确性和低幻觉？

---

项目背景与选型

Q01. 帮助谁解决了什么问题？为什么做这个项目？

• 这个项目主要服务内部业务、客服、运营和研发同学，解决文档分散、查资料慢、口径不统一的问题。
• 以前遇到业务规则、产品说明、排障文档时，要去飞书、语雀、PDF、代码仓库里翻，耗时长，而且容易找错版本。
• 做 RAG 的原因是企业知识更新快，单靠大模型本身的训练知识不够新，也不能保证回答基于公司内部资料。
• 项目目标不是做聊天机器人，而是做一个可追溯、可更新、能回答业务问题的知识问答系统。
• 面试里可以强调三点：提升查询效率、统一知识口径、降低人工答疑成本。

Q02. 系统的每天使用量是多少？

• 我们按问答次数、活跃用户数、响应耗时和命中率来统计使用量。
• 试运行阶段日均几百次问答，核心用户主要是客服、运营和内部研发。
• 高峰一般出现在业务上线、活动发布、客服集中处理问题的时候。
• 线上会记录每次 query、命中文档、召回分数、生成耗时、用户反馈，方便后续调优。
• 如果面试官追问具体数值，建议说自己项目真实数据；不要随口编特别夸张的量级。

Q03. 你们为什么不用工具，要选择代码开发，coze 和 dify 不能实现你们的需求吗？

• 我们调研过低代码工具，适合快速验证 Demo，但生产系统需要更强的工程控制。
• 主要限制在四块：文档解析可控性、权限体系、检索策略定制、日志和评估闭环。
• 例如复杂 PDF 表格、图片 OCR、按部门权限过滤、多路召回加 rerank，这些需要自己细调。
• 公司内部系统还要接登录、审计、灰度、监控、知识版本管理，直接用平台会比较受限。
• 所以选择代码开发，不是工具不能用，而是生产环境需要更可控、更好扩展。

Q04. 你们调研过哪些文档知识库的工具？

• 低代码平台：Dify、Coze，适合快速搭流程和验证效果。
• 框架类：LangChain、LlamaIndex，适合自定义 RAG 流程。
• 向量库：Milvus、Chroma、FAISS、Elasticsearch 向量检索、Pinecone。
• 文档解析：Unstructured、MinerU、PyMuPDF、pdfplumber、Apache Tika。
• 最后选型看三点：能否满足私有化部署、复杂文档处理能力、是否方便接入现有 Java/Python 服务。

Q05. 离线知识库的规模有多大？

• 我们会从文档数量、原始文件体积、切分后的 chunk 数、向量数量四个维度描述规模。
• 典型规模是几千到几万份文档，切分后可能是几十万到百万级 chunk。
• 文档类型包括 Markdown、Word、PDF、FAQ、接口文档、产品手册、运营规则。
• 真正影响检索性能的不是原始文档数，而是 chunk 数、向量维度、索引类型和过滤条件。
• 面试回答时要补一句：规模数据会随着知识更新持续变化，所以线上要有统计面板。

Q06. 你们如何做知识库的版本管理？

• 原始文档保留文件 ID、版本号、更新时间、来源系统和负责人。
• 每次文档更新都会重新解析、分块、向量化，并记录本次索引批次号。
• 向量库里每个 chunk 都带 doc_id、chunk_id、version、source、更新时间等元数据。
• 更新时不直接覆盖，通常先写入新版本，验证通过后切换生效版本。
• 出问题可以按版本回滚，也能定位某个回答来自哪个版本的文档。

Q07. 你们是怎么做知识的溯源的？

• 每个 chunk 都保存来源信息，包括文档名、路径、页码、章节标题、chunk 序号。
• 检索结果返回给大模型前，会把来源 metadata 一起带上。
• 最终回答展示引用来源，例如文档名、章节、页码或链接。
• 用户如果质疑答案，可以点开原文核对，不只看模型生成内容。
• 溯源的关键是索引阶段就把 metadata 建好，后面生成阶段才有依据。

RAG 基础概念

Q08. 什么是 RAG？它解决了大模型的哪些问题？

• RAG 是 Retrieval-Augmented Generation，检索增强生成。
• 核心思路是先从外部知识库检索相关资料，再把资料和问题一起交给大模型回答。
• 它解决三个典型问题：知识不够新、内部知识缺失、回答无法溯源。
• RAG 不能完全消灭幻觉，但能把回答约束在可检索的知识范围内。
• 面试里一句话概括：RAG 是把大模型的生成能力和企业知识库的事实依据结合起来。

Q09. RAG 的主要流程/完整工作流程是什么？核心步骤有哪些？

• 离线阶段：文档采集、解析清洗、分块、向量化、写入向量库。
• 在线阶段：用户提问、query 预处理、检索、rerank、组装 prompt、调用大模型生成。
• 生成后还要做引用展示、敏感词过滤、日志记录和用户反馈收集。
• 核心步骤是文档处理、检索召回、上下文构造、生成回答。
• 真正影响效果的是分块质量、embedding 模型、检索策略、prompt 约束和评估闭环。

Q10. RAG 和模型微调有什么区别？如何选择？

• RAG 解决"知识从哪里来"，微调解决"模型怎么说、怎么按固定模式做事"。
• RAG 适合知识频繁更新、需要引用来源、公司内部资料问答的场景。
• 微调适合固定任务、固定风格、分类抽取、格式化输出、领域表达习惯。
• 如果问题是知识缺失，优先 RAG；如果问题是行为不稳定，考虑微调。
• 生产里常见做法是 RAG 提供知识，微调或 prompt 约束回答风格和任务格式。

Q11. 为什么需要微调？直接用 Prompt Engineering 或 RAG 不行吗？

• Prompt 能快速调行为，但稳定性有限，复杂规则太多时容易失效。
• RAG 能补知识，但不一定能让模型稳定执行某类任务。
• 微调适合把大量样例固化到模型里，让它学会固定输出格式、分类边界和行业话术。
• 比如意图识别、结构化抽取、客服话术风格，微调通常比纯 prompt 更稳定。
• 但微调成本更高，知识更新也不如 RAG 灵活，所以不是所有场景都需要微调。

Q12. 如何结合 RAG 和 Fine-tuning 来提升提示词效果？

• RAG 负责提供最新、准确、可溯源的上下文。
• 微调负责让模型更懂业务表达、回答格式和拒答边界。
• 可以用线上高质量问答日志构造训练样本，让模型学会如何使用检索结果。
• 也可以微调 query 改写、意图识别、文档 rerank 等小模型，而不是直接微调大模型。
• 落地原则是：知识放在 RAG，稳定行为交给 prompt 或微调。

Q13. 什么是 Advanced RAG？什么是 Modular RAG？

• Advanced RAG 是在基础 RAG 上加强检索和生成质量，例如 query rewrite、hybrid search、rerank、parent retrieval。
• 它重点解决基础 RAG 召回不准、上下文太长、答案不稳定的问题。
• Modular RAG 是把 RAG 拆成独立模块，例如解析、索引、路由、检索、重排、生成、评估。
• 模块化的好处是每个环节可以单独替换和调优。
• 生产系统一般都会走 Modular RAG，而不是把所有逻辑写死在一条链路里。

Q14. 什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？

• 预检索阶段处理用户 query，例如改写、扩展、意图识别、路由到不同知识库。
• 检索阶段负责从向量库、关键词索引、数据库或外部 API 中召回候选内容。
• 后检索阶段负责过滤、去重、rerank、压缩上下文、合并父文档。
• 最后才是 prompt 组装和大模型生成。
• 这种拆分方便定位问题：召回差看检索，排序差看 rerank，回答差看 prompt 和模型。

Q15. 在 LangChain 中如何实现 RAG 应用？

• 先用 DocumentLoader 加载 PDF、Word、Markdown 等文档。
• 再用 TextSplitter 切块，用 Embeddings 模型向量化。
• 向量写入 VectorStore，例如 Chroma、FAISS、Milvus。
• 在线查询时使用 Retriever 召回文档，可以加 MultiQueryRetriever、EnsembleRetriever 或 ContextualCompressionRetriever。
• 最后用 PromptTemplate 加 LLM 生成回答，并返回 source_documents 做引用。

文档处理与知识库治理

Q16. RAG 的文档处理流程是怎样的？如何处理 PDF、Word、Markdown 等不同格式？

• 统一流程是采集、解析、清洗、结构化、分块、加元数据、向量化、入库。
• Markdown 保留标题层级，按标题和段落切分。
• Word 先提取正文、标题、表格，必要时转成 Markdown 结构。
• PDF 最麻烦，要处理版面、页眉页脚、表格、图片、跨页内容。
• 不同格式最后都转成统一 Document 结构，便于后续分块和检索。

Q17. 在 RAG 中，索引流程中的文档解析你们怎么做的？

• 先按文件类型选择解析器，不同格式走不同 pipeline。
• 解析后会做清洗，例如去页眉页脚、去目录噪声、合并断行、过滤空段。
• 保留结构信息，例如标题、页码、表格位置、图片说明。
• 表格和图片不会简单丢弃，会转成文本描述或结构化 Markdown。
• 解析结果会落盘保存，方便排查检索不到是解析问题还是检索问题。

Q18. 你们用的什么框架解析文档？为什么不用第三方集成好的工具？

• 常用 PyMuPDF、pdfplumber、Unstructured、Apache Tika，复杂 PDF 会结合 OCR。
• Word 和 Markdown 解析相对稳定，可以用 python-docx、Markdown parser 或框架自带 loader。
• 没完全依赖第三方一站式工具，是因为业务文档格式不统一，复杂表格和图片需要定制。
• 另外还要接元数据、权限、版本、异常重试和解析质量校验。
• 我们不是排斥工具，而是在工具基础上加自己的解析和治理逻辑。

Q19. 使用 LangChain 实现 RAG 系统时，如何处理 PDF 文档中的表格数据召回问题？

• 不建议把表格直接当普通文本切碎，容易丢行列关系。
• 解析时把表格转成 Markdown table 或 key-value 描述，保留表头和单位。
• 表格 chunk 单独入库，metadata 标记为 table，方便检索时加权。
• 对复杂表格可以生成一段摘要，和原始表格一起入库。
• 检索时向量召回加关键词匹配，必要时对表格结果单独 rerank。

Q20. PDF 中包含的图片怎么处理？

• 先判断图片是否有业务价值，装饰图可以过滤。
• 流程图、架构图、截图、票据类图片要保留。
• 文字型图片用 OCR 提取文字，并记录图片所在页码和位置。
• 业务图可以用多模态模型生成简短描述，再作为文本 chunk 入库。
• 回答时引用图片来源，必要时返回原图链接，而不是只给模型生成描述。

Q21. PDF 中表格，尤其比较复杂的表格如何处理？

• 简单表格转 Markdown table，保留表头、行列、单位。
• 跨页表格要先合并，再切分，避免一半表格单独入库。
• 合并单元格要补全语义，例如把上级表头下沉到每一行。
• 大表格可以按主题、行组或业务对象拆成多个 chunk。
• 对金额、指标、配置项这类表格，建议同时建结构化索引，不能只靠向量检索。

Q22. 什么是 RAG 中的分块？为什么需要分块？

• 分块就是把长文档切成适合检索和放入上下文的小片段。
• 原因是大模型上下文有限，向量检索也需要粒度合适的文本单元。
• 块太大，召回内容噪声多；块太小，语义不完整。
• 好的分块要尽量保持一个完整知识点，不切断标题、步骤、表格和结论。
• 分块质量直接影响召回质量，是 RAG 里最容易被低估的环节。

Q23. 常见的分块策略有哪些？分别有什么区别？

• 固定长度分块：实现简单，但容易切断语义。
• 按段落分块：更自然，适合说明文档和制度文档。
• 按标题层级分块：适合 Markdown、手册、技术文档，能保留章节语义。
• 递归分块：按标题、段落、句子逐级切，LangChain 常用。
• 语义分块：根据语义相似度切分，效果好但成本更高。
• 父子分块：小块用于检索，父块用于生成，适合长文档问答。

Q24. 中文文档切割的 chunk_size 和 overlap 应该如何设置？

• 中文建议按字符或 token 统计，不要直接套英文参数。
• 常见起点是 chunk_size 500 到 1000 中文字符，overlap 50 到 150。
• FAQ 类短文本可以更小，技术文档和制度文档可以稍大。
• overlap 主要防止上下文被切断，但太大会增加重复召回和成本。
• 最终不是拍脑袋定，要用测试集看召回率、答案准确率和上下文冗余。

Q25. 父块大小 1000 是怎么定的？

• 1000 不是固定标准，是根据业务文档长度、模型上下文和检索效果调出来的。
• 父块要足够包含完整知识点，比如一个小节、一个流程、一个规则说明。
• 太小会丢上下文，太大会带入无关内容。
• 我们会用不同父块大小做对比，例如 800、1000、1500，看命中率和回答质量。
• 如果面试官追问，重点说"通过评估集验证"，不要说"网上都这么配"。

Q26. 你们怎么评估知识库的分块，有没有把知识切开？

• 先人工抽样看 chunk，检查标题、正文、表格是否完整。
• 再用标准问题集测试，看问题是否能召回包含答案的 chunk。
• 关注指标包括 Recall@K、MRR、命中文档准确率、答案引用是否正确。
• 对跨 chunk 的问题，检查是否需要 overlap 或 parent retrieval。
• 如果发现模型回答需要的信息分散在多个 chunk，就要调整分块策略或加父子块。

Embedding 与向量化

Q27. 什么是 RAG 中的 Embedding 嵌入？它是如何工作的？

• Embedding 是把文本转换成向量，用数字表示文本语义。
• 语义接近的文本，向量距离也更近。
• RAG 中会把文档 chunk 和用户 query 都转成向量。
• 检索时计算 query 向量和文档向量的相似度，找出最相关内容。
• Embedding 决定了系统能不能"按意思找资料"，不是简单按关键词匹配。

Q28. 常见的 Embedding Model 嵌入模型有哪些？

• OpenAI text-embedding 系列，效果稳定，适合云服务场景。
• BGE 系列，中文和中英混合场景常用，适合私有化部署。
• M3E、GTE、E5，也常用于中文或多语言检索。
• Sentence-BERT 系列适合语义相似度和句向量任务。
• 选模型不能只看榜单，还要用自己的业务问题集做召回评测。

Q29. 如何为 RAG 系统选择合适的 Embedding 模型？需要考虑哪些因素？

• 先看语言场景：中文、英文、多语言、代码文档是否都要覆盖。
• 再看效果：用业务测试集评估 Recall@K、MRR、nDCG。
• 还要看向量维度、推理速度、部署成本、是否支持私有化。
• 如果文档有大量专业词，要测试同义词、缩写、业务别名的召回。
• 最后看稳定性和维护成本，生产系统不能只追求单次效果最好。

Q30. Bert 模型能不能用于 embedding？

• 可以，但原始 BERT 不是专门为向量检索训练的。
• 直接拿 CLS 向量做检索，效果通常不如 Sentence-BERT、BGE、E5 这类模型。
• 如果要用 BERT，最好经过对比学习或相似句任务微调。
• BERT 更常见的用法是分类、意图识别、序列标注。
• 面试回答可以说：能用，但生产检索一般选专门的 embedding 模型。

Q31. 你们使用的什么 embedding 模型？为什么？还调研过哪些？

• 我们优先选支持中文、效果稳定、可私有化部署的 embedding 模型。
• 常见选择是 BGE 或同类中文向量模型，因为中文检索效果和部署成本比较均衡。
• 调研过 OpenAI embedding、BGE、M3E、GTE、E5，也对比过不同维度和不同推理速度。
• 评估时不是只看相似度，而是看业务问题能不能召回正确文档。
• 最终选择依据是召回效果、延迟、成本、私有化要求和工程维护成本。

向量数据库

Q32. RAG 为什么需要向量数据库？它和传统数据库有什么区别？

• 向量数据库用于存储 embedding 向量，并做近似最近邻检索。
• 传统数据库擅长结构化查询，例如按 ID、时间、状态过滤。
• 向量数据库擅长语义相似度查询，可以按"意思接近"找文档。
• RAG 里通常会把向量检索和元数据过滤结合起来。
• 简单说：传统数据库找精确字段，向量数据库找语义相似内容。

Q33. 如何为 RAG 项目选择向量数据库？Milvus、Pinecone、Chroma 怎么选？

• Milvus 适合大规模、私有化、生产级向量检索，功能完整但运维成本更高。
• Pinecone 是托管服务，上手快，适合能用云服务的团队。
• Chroma 轻量，适合本地开发、Demo、小规模应用。
• FAISS 更偏向向量检索库，适合嵌入到服务里，但缺少完整数据库能力。
• 选型重点看规模、部署方式、过滤能力、索引类型、运维成本和团队技术栈。

Q34. RAG 中如何实现向量数据库的增量更新？

• 给每个文档建立唯一 doc_id 和版本号。
• 发现文档新增、修改、删除后，只处理变更文档，不全量重建。
• 修改文档时先删除或标记旧版本 chunk，再写入新版本 chunk。
• 向量入库要保证幂等，避免重复索引。
• 更新完成后跑抽样校验，确认新内容能检索到，旧内容不会误召回。

检索策略与优化

Q35. 什么是 RAG 混合检索？如何实现向量检索和关键词检索结合？

• 混合检索就是同时用语义检索和关键词检索召回文档。
• 向量检索擅长同义表达，BM25 擅长精确词、编号、专有名词。
• 实现上可以分别取 Top-K，再做去重、分数归一化和融合排序。
• 常见融合方式有加权求和、RRF、先召回再 rerank。
• 适合业务文档里有大量术语、型号、接口名、配置项的场景。

Q36. 什么是 RAG 中的 Rerank？为什么需要？具体如何实现？

• Rerank 是对初步召回结果重新排序，挑出最相关的上下文。
• 向量检索召回快，但排序不一定最准，容易把相似但不回答问题的内容排前面。
• Rerank 通常用 cross-encoder 或专门的 reranker 模型。
• 流程是先召回较多候选，比如 Top 20，再 rerank 取前 3 到 5 个。
• 它能明显提升准确率，但会增加延迟，所以要控制候选数量。

Q37. RAG 检索中的 Top-K 是什么意思？K 值如何确定？

• Top-K 表示检索时返回相似度最高的 K 个 chunk。
• K 太小可能漏掉答案，K 太大容易带入噪声和增加 token 成本。
• 常见做法是初召回 K 取 10 到 30，rerank 后保留 3 到 8 个。
• 最终要根据测试集调参，看 Recall@K、回答准确率和生成成本。
• 不同场景 K 值不同，FAQ 可以小一些，复杂问题需要更大的候选集。

Q38. 相似度阈值如何设置？设置不当有什么影响？

• 相似度阈值用于过滤低相关结果。
• 阈值太高会召回不到内容，导致系统频繁拒答。
• 阈值太低会引入噪声，模型容易根据无关内容编答案。
• 设置方式一般是用标注测试集观察正负样本分数分布。
• 线上可以按知识库、文档类型、问题类型设置不同阈值，而不是全局一个值。

Q39. RAG 系统如何利用元数据过滤提升检索精度？

• 元数据包括部门、文档类型、产品线、版本、时间、权限、语言、来源系统。
• 检索前先根据用户身份和问题意图过滤候选范围。
• 例如问支付问题，只检索支付知识库；问某版本功能，只检索对应版本文档。
• 这样可以减少无关召回，也能保证权限安全。
• 元数据过滤适合和向量检索结合：先缩小范围，再做语义匹配。

Q40. 什么是查询扩展？为什么在 RAG 中需要查询扩展？

• 查询扩展是给用户问题补充同义词、业务别名、上下文词。
• 用户提问往往很短，比如"退款失败怎么办"，但文档里可能写"退费异常处理"。
• 扩展后可以提升召回率，减少因为表达不同导致的漏召回。
• 实现方式可以用词典、规则、LLM 生成扩展词、多查询检索。
• 要控制扩展范围，扩展过头会把问题带偏。

Q41. 什么是自查询？为什么在 RAG 中需要自查询？

• 自查询是让模型把自然语言问题解析成检索条件和语义 query。
• 例如"查 2024 年支付产品的上线规则"，可以解析出时间、产品线、文档类型。
• 它适合有丰富 metadata 的知识库。
• 好处是可以自动生成过滤条件，提高检索精度。
• 风险是模型解析错条件，所以要做字段白名单和规则校验。

Q42. 什么是查询重写（Query Rewriting）？如何优化检索效果？

• 查询重写是把用户原始问题改写成更适合检索的表达。
• 例如把口语、省略、指代不清的问题改成完整问题。
• 多轮对话中还要补齐上下文，把"这个怎么配置"改成具体对象。
• 可以用规则、意图模板或大模型重写。
• 重写后要保留原意，不能为了召回擅自扩展成另一个问题。

Q43. 如何处理 RAG 检索不到相关文档的情况？

• 首先不要让模型硬答，应该明确提示没有找到可靠依据。
• 可以尝试 query rewrite、查询扩展、混合检索、降低阈值再检一次。
• 如果还是没有结果，返回兜底话术，建议用户换个问法或转人工。
• 同时记录这类问题，用来补充知识库或优化分块。
• 生产里要区分"真的没有知识"和"检索策略没召回"。

Q44. 当 RAG 系统召回结果与用户 query 意图不匹配时，有哪些改进方向？

• 先看 query 是否太短或有歧义，必要时做意图识别和查询重写。
• 再看知识库路由是否正确，是否检索到了错误的业务域。
• 检查 embedding 对业务词是否理解，必要时换模型或做领域微调。
• 加 BM25、metadata 过滤和 rerank，减少语义相似但答案不相关的内容。
• 最后用线上 badcase 反推，是分块问题、索引问题还是排序问题。

Q45. 如何优化 RAG 的检索效果？

• 文档侧：优化解析、清洗、分块、metadata 和版本管理。
• 模型侧：选择更合适的 embedding，必要时微调或换 reranker。
• 检索侧：使用混合检索、query rewrite、rerank、parent retrieval。
• 评估侧：建立标准问题集，持续看 Recall@K、MRR、答案准确率。
• 线上侧：收集用户反馈和 badcase，定期回流优化知识库。

Q46. 假设检索（HyDE）是什么？能不能举个例子？

• HyDE 是让大模型先根据问题生成一段"假设答案"，再用这段文本去检索。
• 它不是直接相信假设答案，而是用更完整的语义表达帮助召回。
• 例子：用户问"退款失败怎么处理"，模型先生成可能包含"退款单状态、支付渠道、重试、人工处理"的假设段落。
• 然后用这个假设段落向量检索，可能比短 query 更容易命中文档。
• 适合用户问题很短、语义不充分的场景，但要配合 rerank 防止跑偏。

Q47. 子查询检索是什么？能不能举个例子？

• 子查询检索是把复杂问题拆成多个简单问题分别检索。
• 例子：用户问"新用户活动怎么配置，失败怎么排查？"
• 可以拆成"新用户活动配置流程"和"活动配置失败排查方法"两个子查询。
• 每个子查询分别召回，再合并去重和 rerank。
• 适合多意图、多条件、跨文档的问题。

Q48. 回溯检索（Parent Document Retrieval）是什么？对应场景是什么？

• 回溯检索也叫父文档检索，通常是小块检索、大块生成。
• 小 chunk 用来提高召回精度，父块提供完整上下文。
• 适合长段落、制度条款、流程文档、技术手册。
• 例如小块命中"审批失败原因"，生成时回溯到整个审批流程章节。
• 它能解决小块语义不完整的问题，但父块过大也会带来噪声。

Q49. BM25 是什么算法，与 TF-IDF 有什么区别？

• BM25 是经典关键词检索算法，基于词频、逆文档频率和文档长度归一化。
• TF-IDF 主要看词在文档中是否重要，BM25 在此基础上处理词频饱和和长度影响。
• BM25 对短 query、专有名词、编号、接口名效果很好。
• 它不理解语义相似，比如"退款"和"退费"可能需要分词词典或同义词扩展。
• RAG 中常把 BM25 和向量检索结合，互相补短板。

Q50. 检索效果不好，可能是哪里出问题了，如何优化？

• 文档解析错：正文、表格、标题没提取好，需要优化 parser。
• 分块不合理：知识点被切断或 chunk 太大，需要重新切分。
• embedding 不适合：业务词召回差，需要换模型或加领域样本。
• 检索策略单一：只用向量不够，要加 BM25、metadata、rerank。
• query 太差：需要重写、扩展、意图识别。
• 评估缺失：没有标准问题集，就很难判断优化是否有效。

Q51. 如果检索出的内容过长，或者检索的内容相关性不高，如何优化检索出的内容相关性？

• 先用 rerank 筛掉弱相关结果，只保留真正回答问题的 chunk。
• 对长 chunk 做上下文压缩，提取和 query 相关的句子或段落。
• 调小生成阶段使用的 Top-K，初召回可以多，最终上下文要精。
• 优化分块，避免一个 chunk 混入多个主题。
• 用 metadata 限定范围，比如产品线、版本、文档类型。

查询处理与意图识别

Q52. 如果用户的 query 很随意，或者 query 的描述不清楚，应该如何处理？

• 先判断是否能从上下文补全，例如多轮对话里的指代。
• 如果能补全，就做 query rewrite，把问题改成完整检索语句。
• 如果歧义太大，不直接检索，先反问用户补充关键信息。
• 对常见口语表达建立同义词和业务别名映射。
• 线上要记录这类 query，后续优化提示词、意图识别和知识库 FAQ。

Q53. 为什么要做意图识别？

• 意图识别可以判断用户到底是问知识、查流程、报故障、还是闲聊。
• 不同意图走不同链路，例如知识问答走 RAG，故障排查走诊断流程。
• 它能减少错误知识库召回，提高回答准确率。
• 也能做安全控制，例如敏感问题、越权问题直接拦截。
• 对生产系统来说，意图识别是路由和兜底策略的入口。

Q54. 你们为什么选择用 Bert 模型，不直接用大模型做意图识别呢？

• 意图识别是高频、短文本、分类边界明确的任务，小模型性价比更高。
• BERT 延迟低、成本低、部署可控，适合在线高并发。
• 大模型做分类效果可以，但调用成本和响应时间更高。
• 小模型也更容易做固定标签的稳定输出，不容易生成额外内容。
• 我们会在低置信度或复杂 query 时再调用大模型兜底。

Q55. 你们具体怎么做的？

• 先定义意图标签，例如知识问答、流程咨询、故障排查、闲聊、转人工。
• 从历史 query 和人工标注数据中构建训练集。
• 用 BERT 做文本分类，输出意图标签和置信度。
• 高置信度直接路由到对应链路，低置信度走大模型改写或反问。
• 线上持续收集错分样本，定期增量训练和回归测试。

Q56. 如果意图分类错了，会怎么样，大模型回答效果如何，你们测试过吗？

• 意图错了会导致路由错，比如本该查知识库的问题走了闲聊或错误知识库。
• 结果通常是召回不到、召回错、或者模型答非所问。
• 我们会用标注集测试意图准确率，也会做端到端问答测试。
• 对高风险意图设置二次确认和低置信度兜底。
• 线上看 badcase 时，会区分是意图错、检索错，还是生成错。

生成与提示工程

Q57. RAG 中如何设计 Prompt 来有效利用检索到的文档？

• Prompt 要明确要求模型优先基于检索上下文回答。
• 如果上下文没有答案，要说明不知道，不能编。
• 上下文要带编号和来源，方便模型引用。
• 要限制回答格式，例如分点回答、先结论后原因、必要时给步骤。
• 对冲突资料要要求模型说明冲突来源，优先使用最新版本。

Q58. 什么是提示压缩？为什么在 RAG 中需要提示压缩？

• 提示压缩是把检索到的大段上下文压缩成更短、更相关的内容。
• RAG 里检索结果可能很长，直接塞给模型会浪费 token，也会引入噪声。
• 压缩方式包括抽取相关句、摘要、去重、按 query 过滤段落。
• 它能降低成本，提高回答聚焦度。
• 但压缩不能丢关键事实，重要数字、条件、限制要保留。

Q59. 在 RAG 应用过程中，关于提示工程的设计有什么心得和技巧？

• Prompt 不要写得太玄，核心是任务、上下文、约束、输出格式。
• 明确告诉模型：只能基于资料回答，缺资料就拒答。
• 检索片段要编号，方便引用和调试。
• 对业务问答，最好让模型先给结论，再给依据和步骤。
• 对长上下文，要把最相关内容放前面，减少模型忽略重点。

Q60. 如何减少 RAG 系统的幻觉问题？有哪些实用方法？

• 提高检索质量，保证上下文里真的有答案。
• Prompt 明确要求无依据不回答。
• 设置相似度阈值，低相关结果不进入生成。
• 加引用来源，强制答案能回到原文。
• 对关键场景加规则校验，例如金额、日期、权限、配置项。
• 线上收集幻觉案例，回流到知识库和评估集。

Q61. RAG 系统如何标注信息来源和提供引用？

• 索引阶段给每个 chunk 记录文档名、页码、章节、链接和版本。
• 检索结果进入 prompt 时带上 source_id。
• 生成回答时要求模型在关键结论后标注引用编号。
• 前端展示引用列表，用户可以点击回到原文。
• 如果一个结论没有来源，就不要把它包装成确定答案。

Q62. RAG 主要解决大模型幻觉和知识缺乏问题，有什么办法能够从根本上缓解？

• 根本上要提升知识质量，而不是只调 prompt。
• 知识库要及时更新、去重、清洗、版本化，避免旧知识和错知识进入检索。
• 检索链路要稳定，能把正确资料召回到模型面前。
• 关键业务规则可以结构化，不完全依赖自由文本生成。
• 对高风险问题加审核、规则校验或人工兜底，不能只相信模型。

效果评估与调优

Q63. 如何进行 RAG 调优后的效果评估？真实应用场景中采用哪些评估标准与方法？

• 先建立业务问题集，每个问题要有标准答案和标准来源。
• 离线评估看召回是否命中答案、生成是否正确、引用是否准确。
• 在线评估看用户点赞率、转人工率、追问率、无答案率、平均响应时间。
• 调优前后要做 A/B 或回归测试，避免局部优化导致整体退化。
• 真实场景里最重要的是答案是否能解决问题，而不是模型说得是否流畅。

Q64. 如何评估 RAG 系统的效果？检索和生成分别看哪些指标？

• 检索看 Recall@K、Precision@K、MRR、nDCG、命中文档率。
• 生成看答案正确性、完整性、忠实度、引用准确率、拒答合理性。
• 工程指标看延迟、成本、可用性、索引更新时间。
• 用户指标看满意度、采纳率、重复提问率、转人工率。
• 要分层评估，不能只看最终回答，因为最终错了可能是检索错，也可能是生成错。

Q65. 如何评估 LangChain RAG 应用的效果？

• 可以用 LangSmith 记录每次链路调用，包括 query、检索结果、prompt、模型输出。
• 用固定测试集跑批量评估，比较不同 splitter、retriever、reranker 的效果。
• 检查 source_documents 是否包含标准答案来源。
• 对生成结果可以用人工评估，也可以用 LLM-as-judge 辅助评估。
• 重点不是 LangChain 本身，而是把链路每一步的数据记录下来，方便定位问题。

Q66. 检索的效果如何评估的？

• 准备一批真实问题，并标注正确文档或正确 chunk。
• 看 Top-K 里是否包含正确答案来源。
• 常用指标是 Recall@K、MRR、Precision@K、nDCG。
• 还会人工抽查排序靠前的结果是否真的回答问题。
• 线上结合无答案率、用户反馈和 badcase 分析继续优化。

生产环境与工程实践

Q67. RAG 系统在生产环境中如何优化性能和降低成本？

• 缓存高频 query 的检索结果和生成结果。
• embedding 离线批量计算，避免在线重复向量化文档。
• 初召回多一些，rerank 和生成阶段少一些，控制 token。
• 选择合适模型，大模型处理复杂问题，小模型处理分类、改写、压缩。
• 向量库做好索引、分片、过滤条件和连接池优化。
• 监控延迟、token 成本、召回数量、错误率，按数据继续调参。

Q68. RAG 中如何计算文本相似度？常见算法有哪些？

• 向量检索常用余弦相似度、点积、欧氏距离。
• 余弦相似度关注方向，常用于文本语义相似度。
• 点积适合部分向量模型的默认检索方式，要看模型训练方式。
• 关键词检索常用 BM25、TF-IDF。
• 实际 RAG 里常把向量相似度、BM25 分数和 rerank 分数结合使用。

Q69. 你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？

• 先做知识库路由，根据意图、用户权限、产品线、问题类型选择候选知识库。
• 每个知识库单独维护 metadata、版本和索引，避免全量混检。
• 对不确定的问题可以多知识库并行召回，再用 rerank 统一排序。
• 使用权限过滤，防止模型引用用户无权访问的内容。
• 低相似度或跨库结果冲突时，不强行回答，要提示信息不足或列出冲突来源。
• 线上记录命中的知识库、召回分数和用户反馈，持续优化路由规则和评估集。