08 RAG 面试题

1、什么是 RAG？

RAG（Retrieval-Augmented Generation，检索增强生成） 是指在调用 LLM 回答问题之前，先从知识库里查询与问题相关的信息，再把相关信息和用户提出的问题，一起放到提示词中，再交给 LLM，让 LLM 基于知识库信息来回答问题。

RAG 解决的最主要的问题是：LLM 回答问题都是根据自身训练数据来给出答案，但实际应用中，一些内部知识库的内容是不被模型所了解的，比如说，公司的规章制度、项目的文档、产品使用说明等等，如果直接问 LLM 它不了解的问题，LLM 可能会出现幻觉而胡编乱造。

并且 LLM 的训练数据都是截止到某个时间点信息，当我们提问一些最近发生的事情，LLM 也会出现幻觉。

因此，通过 RAG 来检索外部知识库，可以很好的解决 LLM 出现幻觉的问题。

2、在 Agent 中使用 RAG 有哪些好处？

在 Agent 中，使用 RAG 有如下好处：

• 扩展 LLM 知识范围

企业知识库、产品文档、代码文档，这些内容不可能在 LLM 训练数据中，通过检索让 LLM 能了解这些信息。

• 降低幻觉

明确让 LLM 基于 RAG 检索到的资料回答问题，很大程度上能避免幻觉的出现。

• 保持知识库更新

当一些知识库内容发生更新，可以直接将知识库更新到最新内容，而 LLM 要了解更多的知识需要重新训练模型。

• 可以追溯引用来源

RAG 检索完成后，可以返回给用户当前答案是引用知识库的哪篇文档、哪个章节。

3、RAG 完整流程是什么？

一个完整的 RAG 系统一般分成两个阶段：文档入库和文档检索。

• 文档入库阶段

文档入库阶段主要完成的工作是对文档进行解析、清洗，之后将文档拆分成文档片段，再将这些文本片段进行文本嵌入，保存到向量数据库。

• 文档检索阶段

在文档检索阶段，主要完成的是将用户提出的问题通过 Embedding 文本嵌入模型转换成向量，根据向量进行相似性检索，找出 TopK 的文本片段，这里可以和关键词检索混合使用。

最后将找到的文本片段进行 Rerank 重排序，找到真正最相关的文本片段，将这些文本片段拼接到提示词中，一起交给 LLM，LLM 生成最终答案。

4、Embedding 是什么？

Embedding 就是利用文本嵌入模型，将文本转换成向量的过程。

在传统的软件开发中，我们通常使用关系型数据库，通过精确匹配或者模糊匹配来做数据检索，在 Agent 开发中，我们使用 RAG 对信息匹配检索的能力有了更高的要求，不能只做关键字检索，更重要的是做语义检索。

首先需要先把一段文本利用 Embedding 模型转换成一组数字。语义越接近的文本，生成的向量距离越接近。比如：”如何申请年假”和”年假怎么请”，这两句话不完全一样，但表达的意思非常接近。这两段文本经过 Embedding 后，它们在向量空间里的距离相对也会很近。Embedding 的作用，就是让系统可以做语义检索。

一个文本经过 Embedding 之后，会生成一组数字，大概长成这样：

[0.012, -0.231, 0.548, ...]

实际上，在使用 Embedding 模型和向量数据库时，可以支持几百、上千维甚至更多。但是我们不需要关心每一维具体代表什么，只需要理解如何利用 Embedding 模型和向量数据库进行语义检索即可。

5、向量数据库是如何进行相似性搜索的？

向量数据库主要完成向量和对应元数据的存储，在进行相似性搜索时，可以快速匹配到语义最相似的文本片段。

将向量存储到向量数据库时，每个 Chunk 都会将 Embedding 向量、原文、来源等元数据一起存入向量数据库。结构类似：

{
  "id": "chunk_001",
  "content": "员工入职满一年后可享受年假。",
  "embedding": [0.12, 0.34, 0.56],
  "metadata": {
    "doc_id": "hr_policy_001",
    "title": "员工休假制度",
    "page": 3,
    "status": "published"
  }
}

在使用相似性检索时，先把要检索的文本通过 Embedding 模型转换成向量，然后到向量数据库里找跟这个向量距离最近的几个 Chunk，一般在检索时会加上 metadata 的过滤条件，如只检索 tenant_id = t_001 的文档。

常见相似度计算方式有：

• Cosine Similarity：余弦相似度
• Dot Product：点积
• Euclidean Distance：欧氏距离

6、Chunk 如何切分？

Chunk 是指文档切分之后产生的文本片段。 在 RAG 中，我们不会把一整篇文档直接转换成向量保存到向量库中，而是先将整篇文档切成多个 Chunk，再分别使用 Embedding 模型生成向量。

Chunk 的切分主要遵循：单个片段不能太长，但是也要避免太短，单个片段尽量保证语义完整。

Chunk 切分有以下几种方案：

• 按固定长度切分

比如每 500 个字符进行一次切分。这种切分方式最简单，但是容易把一个完整的段落切断。

• 按段落切分

比如按标题、章节、段落、列表切。Markdown 等文档都适合这种切分方式。

• 按语义切分

按照语义来切分，把同一个主题的内容尽量放在一起。这种效果通常更好，但实现成本也更高。

除了以上切分方式外，还可以使用重叠切分 overlap，重叠切分是指为了避免上下文被破坏，相邻 Chunk 之间可以保留一部分重叠内容，比如

Chunk 1：第1-500个字符 Chunk 2：第401-900个字符

这样每个 Chunk 中间重叠 100 个字符，可以减少上下文被破坏的可能性。实际项目里，比较稳的做法是：先按文档结构切，再对过长段落做二次切分，并保留一定重叠。除此之外，对于代码、表格等内容，最好按它们各自的结构进行切分，不要所有内容都用固定长度进行切分。

7、Chunk 大小如何确定？

Chunk 大小没有统一标准，要根据文档的类型、模型上下文长度、Embedding 模型能力和具体业务特点来确定。

Chunk 切分的太小，会破坏上下文。Chunk 太大，会导致一个 Chunk 里内容太多，在进行检索匹配时，无法确定重点，并且 Chunk 太长会导致最终 Prompt 太长，会造成 Token 浪费，LLM 也更难找到重点。

具体的 Chunk 切分方式，可以参考下面的一些经验。

• 普通文档：300 - 800 左右字符
• 技术文档：按小节切分
• 代码文档：按函数、类或模块切分
• 长文档：按标题层级切分，再做摘要
• Overlap 一般可以设置在 Chunk 大小的 10-20% 左右

实际上，确定 Chunk 方案最好的方法是用实际问题来测试，准备几十个常见问题，测试不同 Chunk 大小，召回正确内容的情况，再确定最终方案。

8、TopK 如何选择？

TopK 是指在向量检索时，取前几条最相关的结果，比如 TopK = 5，就是返回最相关的 5 个 Chunk。

在 TopK 大小的选择上，TopK 太小可能会漏掉正确答案，TopK 太大，又会带来 Token 消耗和上下文过长找不到重点。

在选择 TopK 大小时，需要考虑下面几个因素：

• 问题复杂度

整体都是比较简单的问题，那么 TopK 可以设置小一点，比如 3 到 5。复杂问题需要综合多个文档的内容，TopK 可以大一点，比如 8 到 15。

• Chunk 大小

Chunk 越大，每条内容占用上下文空间、消耗的 Token 越多，因此 TopK 就不能设置的太大。Chunk 越小，可能需要更多条才能找到正确的答案。

• 是否有 Rerank 重排序

如果在检索之后有 Rerank 重排序，那可以先召回一些 Chunk，比如 TopK = 20，后面再重排序之后，再取最相关的 3-5 条。

• 模型上下文限制

RAG 检索的 Chunk 的多少，要考虑模型的上下文窗口大小，避免太多信息导致超过上下文大小限制。

在生产环境中常见的做法是通过相似性搜索，召回 20 条左右，再根据 Rerank 结果取前 5 条最相关内容。要注意的是 TopK 不是一成不变的，我们需要根据业务的实际情况，通过测试来调整 TopK 的大小。

9、Rerank 有什么作用？

Rerank 是指对向量数据库初步召回结果，按照相关性由高到低进行二次排序。

那么为什么需要 Rerank 呢？主要是因为通过向量数据库进行相似性检索之后，有一些召回结果看起来和我们提出的问题相关，但实际上却不是正确答案。使用向量的相似性检索，经常会召回一些看起来相似，但实际上没有关联的内容。

Rerank 的作用，就是从检索到的结果中，选择真正和问题相关的 Chunk。Rerank 会把用户问题 + 候选 Chunk 一起传给模型，让模型来判断这个 Chunk 是否真的与问题相关。

在以下场景可以考虑使用 Rerank：

• 文档很多，召回文本产生的噪声较大
• 文档的业务术语相近，容易混淆
• 问题比较复杂，需要精确匹配
• 向量检索 TopK 取值较大

10、如何提高检索准确率？

提高 RAG 检索的准确率，可以从以下这些方面来进行优化：

• 清洗数据

原始文档中的目录、页眉页脚、乱码、重复内容、无意义表格，都会影响检索效果。入库前要先清洗掉这些内容。

• 优化 Chunk 切分

按语义和文档结构切分，通常比固定长度切分效果更好。其中标题、段落、表格、代码块要单独处理。

• 添加元数据

每个 Chunk 都要带上属于哪个知识库、哪个文档、哪个用户等信息，方便在检索时进行过滤。

• 使用混合检索

向量相似性检索是对语义相似的内容进行检索，而关键词检索更适合精确匹配。分别使用两种方式进行检索，之后再将结果进行合并去重，再进行 Rerank，这样检索的效果会更好。

• Rerank

先多召回一些 Chunk，之后再进行重排

• 问题重写

用户提问的问题可能很口语化、不明确的、依赖上下文的。可以先把问题进行改写，改写成更适合 RAG 检索的问题。

11、如何解决知识库召回错误？

知识库召回错误通常有几类原因：文档质量差、切分 Chunk 不合理、检索范围过大、TopK 设置不合理，或者知识库中的知识无法回复用户的问题。

排查问题时可以按照如下顺序进行排查：

• 检查包含正确答案的文档是否入库

• 检查切分 Chunk 时是否将上下文截断

如果正确答案被切分到两个 Chunk 中，那么召回其中任何一个都无法给出正确答案。

• 相似性检索是否召回正确 Chunk

如果包含正确答案的 Chunk 没进 TopK，说明召回策略有问题，可以调整 Chunk 切割策略、Embedding 模型、TopK 数量，或者增加关键词检索。

• 确认正确 Chunk 排名是否太低

如果包含正确内容的 Chunk 被检索出来了，但是排名较低，可以使用 Rerank 进行重排序。

• 检查检索时是否缺少过滤条件

检查是否忘记通过 metadata 过滤知识库、文档、用户。

12、如何评估 RAG 效果？

评估 RAG 的效果，不能只看最终答案是否正确，因为 RAG 分为检索和生成两个环节。在评估时，要分别评估检索效果和生成效果。除此之外，端到端效果和用户反馈也可以用来评估 RAG 效果。

（1）检索结果

评估检索效果的常见指标有：

• Recall@K：目标文档是否出现在前 K 个结果里
• Precision@K：前 K 个结果有多少是真的相关
• MRR：正确结果排名是否靠前
• Hit Rate：是否命中正确的文本片段

（2）生成效果

评估生成效果的常见指标有：

• 答案是否正确
• 是否根据检索结果回答
• 是否产生幻觉
• 是否缺少关键信息
• 是否给出引用来源

（3）端到端效果

对用户来说，最重要的是系统能不能正确回答用户提出的问题。我们可以准备一个测试集，每次修改文本片段、Embedding 模型、TopK、提示词等内容后，都重新运行一遍测试集，观察系统能否正确回答问题。

（4）观察线上反馈

系统上线以后，对于通过 RAG 检索得到答案的问题，要记录用户是否继续追问、是否点赞、是否点踩、是否点击引用来源，这些都能反映 RAG 的真实效果。

13、请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？有哪些优势？

RAG 的工作原理是在 LLM 生成答案之前，先从知识库中检索与用户问题相关的文本片段，再把这些文本片段作为上下文传递给 LLM 生成答案。模型微调是指在已有大模型的基础上，使用新的数据继续训练，让模型参数发生变化。

RAG 适合用于补充外部知识，而模型微调适合用于改变模型行为、输出格式或语言风格。

RAG 相比于微调有以下优势：

• 更新知识库更容易

当知识库文档发生变化，只需要更新知识库或索引，而不需要重新训练模型。

• 更适合接入私有知识库

比如公司制度、产品文档、技术方案，都可以直接使用 RAG 检索。

• 成本更低

相比微调大模型，构建和维护知识库成本更低，迭代知识库内容也更快。

• 文档可追溯

通过 RAG 很容易返回引用来源，用户可以清晰地看到回答问题时参考了哪个知识库、文档或文本片段。

• 降低幻觉

在提示词中明确要求模型只能基于 RAG 检索结果回答，可以降低幻觉。

在实际项目中，RAG 可以和模型微调配合使用。

14、RAG 怎么解决 LLM 上下文窗口有限的问题？

LLM 的上下文窗口大小是有限的。当 RAG 检索出来的文档片段很长时，不能把它们全部放到 Prompt 中。解决 LLM 上下文窗口限制问题时，最重要的目标是保证最终的检索结果与问题内容最相关。

有以下优化方式：

• 合理切分 Chunk

Chunk 太大会占用大量上下文空间，太小又可能导致上下文被破坏。要根据文档类型选择合适的大小。

• 控制 TopK

初步召回可以多返回一些 Chunk，但最终放到 Prompt 中的 Chunk 要限制数量。

• Rerank 重排序

通过 Rerank 重排序，把检索结果中真正相关的内容放到上下文中。

• 压缩上下文

如果文本片段太长、太多，可以通过做摘要、去重、提取关键信息等方式，只将与问题有关的信息放到上下文。

• 使用 metadata 过滤

在检索时，按照 user_id、knowledge_base_id、文档类型等条件进行过滤，减少无关数据进入检索范围。

15、如何选择一个合适的嵌入模型？

选择 Embedding 模型时，不能只看排行榜，更重要的是看模型是否适合自己的业务和文档类型。

主要从以下几个方面考虑：

• 语言和业务数据

如果文档以中文为主，就选择中文检索效果好的模型；如果文档中经常出现中英文混合内容，还要考虑模型的跨语言检索能力。

• 最大输入长度

模型的最大输入长度要能够覆盖常用的 Chunk 大小。

• 向量维度和检索成本

在进行文本嵌入时，需要确定向量维度。向量维度越高，占用的存储空间越大，检索时也会消耗更多的计算资源。

• 部署方式

部署方式可以选择本地部署，也可以直接使用云端 API。本地部署需要消耗算力资源并增加运维成本，但可以保证数据安全。云端 API 接入简单，而且目前文本嵌入模型的价格比较便宜，在数据安全要求不是特别严格的情况下，推荐选择云端 API。

• 向量数据库配置

嵌入模型的向量维度要和向量数据库保持一致。

16、RAG 系统在实际部署中可能面临哪些挑战？

理想情况下，我们通过 RAG 检索出与问题最相关的文档，然后交给 LLM 生成正确答案。但在实际生产环境中，还会遇到数据、权限、性能等问题。

常见的问题如下：

• 文档质量和文档解析

部分文档可能存在重复、过期、格式混乱等问题。对于 PDF、Word、PPT、网页等不同类型的文件，解析效果也不同。

• 权限控制

不同用户的文档访问权限不同，在检索时必须先做权限过滤。不能先查出所有信息，再让模型判断哪些内容可以展示，否则可能会泄露敏感信息。

• 知识更新

当知识库中的文档新增、修改或删除时，要及时同步向量数据库中的数据，避免检索到已经过期的内容。

• 处理延迟

一次 RAG 操作可能包括问题重写、向量检索、全文检索、Rerank 重排序等步骤。处理步骤越多，系统延迟越高。

17、GraphRAG 与传统 RAG 有什么区别？

传统 RAG 主要通过向量相似度检索，找到与用户问题语义最相近的文本片段（Chunk），GraphRAG 会在此基础上增加实体、关系和图结构。

传统 RAG 的数据处理流程如下：

GraphRAG 的数据处理过程如下：

两者主要有以下区别：

• 检索方式

传统 RAG 主要检索语义相似的文本，GraphRAG 还可以根据实体关系、图路径、邻居节点和社区摘要进行检索。

• 适用场景

如果问题的答案可以从知识库中直接找到，那么传统的 RAG 已经够用了。如果问题涉及多个实体、多个关系，则更适合使用 GraphRAG。例如：“该客户有哪些合同和项目？谁负责这些项目？”对于这类问题，GraphRAG 更有优势。

• 可解释性

GraphRAG 可以给出完整的实体关系路径，而传统 RAG 只能给出文本片段。从这个角度来看，GraphRAG 的可解释性更强。

• 系统搭建成本

传统 RAG 的实现和维护都比较简单，GraphRAG 还要处理实体抽取、关系建模、图谱更新和数据一致性，实现成本也比较高。

在实际项目中，两者通常会配合使用。可以先通过向量检索找到相关文档，再通过图检索补充实体关系信息。

18、如果 RAG 系统返回 0 个检索结果，你会如何排查问题？

当 RAG 返回 0 个检索结果时，可以按照以下几个方向进行排查：

• 检查文档是否入库

确认文档是否已经上传，并且完成了解析、拆分、文本嵌入和入库。如果文档内容没有写入向量数据库，那么检索结果一定为空。

• 检查向量和索引

确认 Chunk 是否已经通过 Embedding 模型成功转换为向量，以及索引是否已经构建完成。

• 检查查询向量

在进行数据检索之前，要先对用户提出的问题进行文本嵌入。如果出现接口调用失败、模型不一致或向量维度不一致等问题，都可能导致检索失败。

• 检查过滤条件

在进行相似度检索时，要对向量的 metadata 进行过滤。这一步可能会因为过滤条件错误，提前过滤掉应该检索到的文档，比如 knowledge_base_id 错误、权限错误等。

• 检查检索参数

检查检索的分数阈值是否设置过高，以及 TopK 是否大于 0。

• 查看检索日志

如果仍然没有找到原因，就查看完整的检索日志，重点记录 query 原文、改写后的 query、query 生成的向量、过滤条件、TopK、分数阈值、检索返回数量等重要信息。