Agent面试真题09:这7道面试必考的RAG场景面试题答不对直接挂(附详细答案)

大家好，我是大志。

在上一篇文章中，我们梳理了 RAG 相关的基础知识。在面试中，除了会考查这些基础概念，面试官还会追问一些与 RAG 实际应用场景有关的问题，比如：如何评估 RAG 的效果、如何选择嵌入模型、系统上线后会遇到哪些问题，以及检索不到内容时该如何排查。

本文将围绕这些项目中的实际场景，整理一些常见的 RAG 进阶面试题。

另外，完整的 AI Agent 面试题文档也已经同步到了 aiflowline.cn，大家可以结合文档阅读。

1、如何评估 RAG 效果？

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

（1）检索结果

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

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

（2）生成效果

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

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

（3）端到端效果

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

（4）观察线上反馈

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

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

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

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

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

• 更新知识库更容易

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

• 更适合接入私有知识库

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

• 成本更低

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

• 文档可追溯

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

• 降低幻觉

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

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

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

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

有以下优化方式：

• 合理切分 Chunk

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

• 控制 TopK

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

• Rerank 重排序

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

• 压缩上下文

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

• 使用 metadata 过滤

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

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

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

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

• 语言和业务数据

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

• 最大输入长度

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

• 向量维度和检索成本

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

• 部署方式

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

• 向量数据库配置

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

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

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

常见的问题如下：

• 文档质量和文档解析

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

• 权限控制

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

• 知识更新

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

• 处理延迟

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

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

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

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

GraphRAG 的数据处理过程如下：

两者主要有以下区别：

• 检索方式

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

• 适用场景

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

• 可解释性

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

• 系统搭建成本

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

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

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

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

• 检查文档是否入库

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

• 检查向量和索引

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

• 检查查询向量

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

• 检查过滤条件

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

• 检查检索参数

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

• 查看检索日志

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

好啦，今天这期 RAG 场景面试题 就到这里。后面我会 每周至少更新 1 期面试题系列，想看后续 AI Agent 进阶面试题 的朋友，欢迎关注「大志说编程」！

觉得有用的话，转发给正在面试的小伙伴，咱们下期见~