跳到主要内容

93-Agent面试题精讲：RAG篇

前言​

这节开始更一下Agent岗的面试题，很多都是学员去面试真实遇到的。

大家可以先自己想一下怎么答，然后看一下思路解析和参考回答。

形成自己的答题思路。

这样面试遇到类似问题就能比较完整流畅的回答了。

这节先集中更RAG相关的

什么是 RAG？详细描述一个完整 RAG 系统的详细工作流程？​

RAG全称是 Retrieval-Augmented Generation，就是检索增强生成。我理解它解决的核心问题是，LLM的知识在训练完之后就固定了，遇到私有数据或者最新的信息它就答不上来。RAG的做法是在生成答案之前，先去外部知识库里检索相关内容，然后把检索结果和用户的问题一起交给LLM，让它基于这些上下文来回答。本质上就是给LLM开了一个开卷考试的口子，不用再靠死记硬背了。

大模型的 RAG 主要用来解决什么问题？​

RAG主要解决三个问题。 第一是知识时效性，LLM训练完知识就固定了，训练截止日期之后发生的事它一无所知

第二是私有知识覆盖，公司内部文档、行业专有数据根本没有机会进训练集，LLM对这些内容是空白的

第三是幻觉问题，没有知识依据时LLM容易「自己发挥」编出一个听起来合理但实际错误的答案，给了它参考资料之后幻觉就少很多。

这三个问题的根源都是同一件事，知识被固化在了模型参数里。RAG的解法是把知识存到外部，用的时候实时检索注入，彻底绕开了参数里的知识限制。

微调和 RAG 各自的优劣势是什么​

我的理解是这两个东西解决的不是同一层面的问题，不是谁替代谁的关系。

微调是把新知识直接烧进模型参数里，适合改变模型的行为风格或者培养深度的专业能力

RAG是在推理的时候实时检索注入知识，适合知识需要频繁更新、或者需要有溯源的场景。

如果非要让我选一个，知识库类的问答系统我会首选RAG，成本低而且可以随时更新。

如果是要让模型学会特定的输出格式或者行业语气，那微调更合适。

实际上这两个方案也可以组合用，先微调再套RAG。

RAG 中的文档是怎么存的？粒度是多大？详细说说文档切割（Chunking）策略？​

文档不能直接存进向量库，必须先切成小块也就是chunk，每个chunk分别向量化之后存成一条记录。

每条记录我理解有三个核心部分:向量用于相似度检索，原始文本是检索命中之后塞给LLM读的内容，metadata是来源文件、页码这些附加信息，用于过滤和溯源。这两个东西缺一不可，向量负责找到，原文负责阅读。

切割粒度没有固定答案，通常会根据文档类型和检索效果进行调整，比如 300～800 tokens，并配合一定的 overlap，但更重要的是根据文档类型来选策略，普通文本用固定大小加重叠，有标题结构的文档按语义边界切，代码按函数切，如果既要检索精度又要上下文完整的话，我会用父子切割，也就是小块检索、大块返回。

怎么规避语义被切割掉的问题？​

我的思路是从两个方向来规避这个问题。第一个方向是切的时候就不要在语义中间截断，用重叠切割和语义边界切割来保证每个chunk内容是完整的，也就是按句子、段落这些自然的边界来切。

第二个方向是切完之后用检索策略把上下文补回来，核心方案是句子窗口检索，命中一个句子就把周围几句一起返回给LLM;另外还有父子切割，小块检索命中、大块内容输出。

还有一个我觉得比较有价值的方案，是Anthropic提出的上下文检索（Contextual Retrieval）的方法，在做Embedding之前先让大模型看着整篇文档为每个chunk生成一段背景说明，把这段背景和chunk拼在一起再向量化，从根本上解决孤立chunk没头没尾的问题。

在 RAG 中 Embedding 究竟是什么？如何选择和评估一个 Embedding 模型？​

Embedding我理解就是把一段文本转成一串数字向量的过程。它有一个很关键的特性，就是语义相近的文本，转出来的向量在数学空间里的距离也近。RAG里的语义检索就是靠这个实现的，不是关键词匹配，而是看两段内容的意思相不相近。

选模型的话，我主要看三个维度:第一是中文支持，中文场景我会优先选BGE系列，效果其实比OpenAI的模型还要好;第二是向量维度，维度越高精度越好，但存储成本也越大;第三是最大输入长度，这个决定了能处理多长的chunk。

评估这块我的建议是不要只看通用排行榜，一定要在自己的业务数据上跑召回测试，那个才是真正有参考价值的。

❌Embedding 有哪几种算法你了解过吗？​

Embedding算法大致经历了三代演进。

第一代是静态词向量，以Word2Vec和GloVe为代表，把每个词映射成固定向量，但同一个词不管上下文是什么，向量永远不变，处理不了多义词。

第二代是以BERT为代表的上下文相关向量，同一个词在不同语境下有不同的向量，表达能力大幅提升，但BERT本身输出的是token级别的向量，两个句子要比较相似度就必须拼在一起跑，百万条文档就要跑百万次，检索速度完全不可接受。

第三代是以SBERT、SimCSE、BGE为代表的句子级对比学习Embedding,专门为「两段文本有多相似」这个任务优化，能提前把所有文档向量算好存起来，查询时只需算一次，是RAG场景的标配。

❌什么是向量数据库？有没有做过向量数据库的对比选型？​

向量数据库是专门用来存储和检索高维向量的数据库，核心能力是近似最近邻搜索，也叫ANN，能在百万甚至亿级的向量里快速找出最相似的几条。

普通关系型数据库的索引结构对高维向量基本上是失效的，所以需要专门的数据库来处理这个场景。

我自己做过一些选型，本地开发阶段我用Chroma，零配置上手极快;生产环境的中小规模我推荐Qdrant，性能不错、API也比较简洁;如果到了超大规模就要考虑Milvus了，字节和小米都在用;不想自己运维的话Pinecone是一个云托管的选项;如果项目里已经有PostgreSQL，也可以直接用pgvector 插件，不用引入新组件。

❌讲讲你用的向量数据库？数据量级是多大？性能如何？遇到过性能瓶颈吗？​

我们生产环境用的是Milvus，数据量级在百万条向量左右，每条是1024维，用HNSW索引，单次查询的延迟在20到50毫秒。选Milvus主要是因为它支持分布式部署和读写分离，适合数据量大、并发高的场景。

我遇到过两个比较典型的瓶颈。

第一个是内存压力，百万级的1024维向量光原始数据就要好几个GB，后来我们开启了标量量化SQ8，把float32压成int8，内存直接降到原来的四分之一。

第二个是大批量写入的时候会触发后台Segment合并，影响查询延迟，我们的解法是把批量写入改到业务低峰期，分批小批次写入。

你使用 RAG 给大模型一个输入，系统是怎样的工作流程？​

当你把一个问题输入给RAG系统，它不会直接丢给大模型，而是先经历一套「检索->整理->生成」的流水线。

具体来说:系统先对问题做预处理(改写成更适合检索的形式)，然后把问题向量化，去向量库里找最相关的文档片段，再经过精排筛掉噪音，最后把筛选出来的片段和问题起拼成Prompt交给大模型，大模型基于这些「参考资料」生成最终答案。

整个流程的核心目标只有一个:让大模型在回答时有真实的知识作为依据，而不是凭空发挥。

请你介绍一下向量检索和关键词检索的区别？​

关键词检索(BM25这类)靠的是词频统计，看查询词在文档里出现了多少次，擅长精确命中

向量检索靠的是语义空间里的距离，能理解「换了种表达方式的同一个意思」，擅长模糊语义匹配。

两者各有盲区:BM25遇到同义词就没辙，向量检索遇到专有名词、产品型号这类精确词就容易漏。所以RAG系统里通常两路都跑，向量检索捕获语义相关的内容，BM25精准命中关键词，再用RRF算法把两路结果合并，这样覆盖面比单路宽很多。

如何润色用户的 Query（Query Rewrite）？目的是什么？​

我用Query Rewrite主要是为了弥补用户提问方式和知识库文档表述之间的语义鸿沟。用户的问题往往口语化、模糊、带缩写，而文档写的是正式书面语，向量相似度天然偏低，导致该召回的内容没被召回。

我接触过的方法主要有四种:第一是直接改写，让LLM把口语化的问题转成更精准的表述;第二是Query扩展，补充相关关键词;第三是HyDE，让LLM先生成一个假设答案，然后用答案的向量去检索;第四是Step-back Prompting，把具体问题往上抽象一层，检索更通用的背景知识。

什么是多路召回？具体怎么做？​

多路召回就是同时用多种不同的检索方式去捞候选内容，然后合并排序，而不是只靠单一的向量检索。我理解核心出发点是向量检索和关键词检索各有盲区，向量检索擅长语义相似，但对精确词语比如产品型号、缩写、数字效果比较差;BM25关键词检索正好相反，精确匹配强，但不理解语义。我在项目里常用的组合是向量检索加BM25混合检索，再加上多Query扩展，也就是把用户问题改写成多个版本分别检索。多路的结果用RRF算法融合，最后送进Rerank精排。

RAG 检索优化策略有哪些？​

我理解RAG的检索优化可以从四个层次来看:索引层决定知识怎么存，查询层决定问题怎么转换，召回层决定从哪些路径去找，重排序层决定最终哪些内容进入prompt。 每一层都有对应的优化手段，我的经验是单独优化一个层次往往效果有限，线上系统我会组合来用，先靠索引优化和多路召回来保证覆盖率，再用Rerank保证精度，如果用户提问质量比较差，再额外加上查询优化。

在什么场景下，你会选择使用图数据库来增强传统的向量检索？​

我的判断是，当业务问题涉及多个实体之间的关联推理的时候，就需要考虑引入图数据库来增强。 向量检索有一个根本的局限，它只能做单跳检索，找和问题直接相关的文档，没办法沿着实体之间的关系链做推理。比如你问公司A的投资方和公司B有什么交集，单纯向量检索就很难处理了，因为答案不在某一段文档里，而是藏在多个节点之间的关系上。

这时候图数据库就能发挥作用，沿着关系边一跳一跳地把关联信息收集回来。我接触过的典型场景有企业关系分析、医疗知识图谱、代码依赖关系查询、供应链溯源这些。

如何规避 RAG 系统中大模型的幻觉？​

怎么量化你的 RAG 效果？​

RAG 知识库如何实现动态与持续更新？​

我理解知识库更新的核心挑战是，文档变了，对应的chunk和向量都要跟着变，而且要做到增量处理，不能每次全量重建。我们的通用方案是给每个文档算一个内容hash，通过轮询或者监听数据源变更，检测到文档新增、修改、删除的时候，先清掉旧的向量，再重新切割入库。对于实时性要求比较高的场景，我会用消息队列比如Kafka做变更事件驱动，实现秒级的入库。

在实际落地中，你觉得 RAG 最难的地方是哪里？那你是怎么解决的呢​

我觉得RAG最难的不是把它跑起来，一个基础的Demo一两天就能搭起来，难的是把它调好。工程上最让我头疼的有三块。

第一是文档预处理，原始数据的格式五花八门，PDF里面的表格、图片、嵌套的格式，处理不好就是一堆乱码进了知识库，进去的是垃圾出来的也是垃圾。

表格转为markdown

对于 PDF 中的图片，我会根据图片类型采用不同策略。对于扫描件使用 OCR 提取文字；对于架构图、流程图等图片，可以通过多模态模型进行理解，将图片中的关键实体、关系和业务信息转换成文本描述或者结构化数据，再和普通文本一样进入 Chunking 和 Embedding 流程。

标题层级主要是为了保留文档的上下文结构。我在解析 PDF 的时候，会尽量识别 H1、H2、H3 这样的标题层级，比如“第一章 RAG → 1.1 检索 → 1.1.1 向量检索”。在 Chunking 的时候，我不会把标题和正文完全分开，而是把当前 Chunk 所属的标题路径作为上下文一起保留下来。比如一个 Chunk 属于“RAG → 检索 → 向量检索”，那么最终的 Chunk 内容可以是“RAG > 检索 > 向量检索 + 正文内容”。这样做可以避免 Chunk 被切出来以后丢失上下文，提高后面的 Embedding 和检索效果。同时我会把标题、章节、页码等信息放到 Metadata 里，方便后续过滤和引用。

怎么识别 H1、H2、H3？这个一般是在文档解析阶段完成的。解析 PDF 时，可以根据 PDF 本身的目录、字体大小、字体粗细、位置等版式信息判断标题层级；如果是结构比较复杂的 PDF，也可以使用专门的文档解析工具，或者结合模型进行结构识别。解析完成后统一转换成带层级结构的 Document，再进行 Chunking。

第二是检索质量的调优，向量召回不准是整个系统效果的天花板，但问题来源很多，Chunking、Embedding、Query改写，任何一个环节出问题都会影响结果，排查起来很费劲。

解决方案就是混合检索+rrf结果融合+重拍模型精排

如果发现召回结果不准，我会针对不同环节排查，比如：

  • Chunk 是否切得太大或者太碎
  • Embedding 模型是否适合当前领域
  • Query 是否需要改写
  • Top-K 是否合理
  • BM25 和向量检索的召回结果是否互补
  • Reranker 有没有把真正相关的文档排到前面

这样可以定位到底是召回问题还是排序问题，而不是盲目调整 Prompt。

第三是效果评估，答案对不对很难系统性地衡量，不知道是哪个环节出了问题，优化就变成了瞎猜。

解决方案就是如何评估rag的效果的方案

文章​

说一下RAG的流程​

RAG分为两个阶段：离线知识库构建阶段、在线问答阶段

知识库构建阶段，就是对各种格式的文档做解析、清洗、分块

分块后用嵌入模型生成向量，存入向量数据库，用于语义检索

构建BM25倒排索引，存入全文检索数据库，用于关键词检索

在线问答阶段，会对用户问题做 query 改写，换成更适合检索的表达。

然后会做混合检索：

向量检索根据语义匹配相似内容

关键词检索根据具体术语、专有名词去精确匹配内容。

之后用rerank 重排模型筛选和问题最相关的文档片段

两路检索完成后，之后会做去重、用RRF算法对结果做合并排序。

把筛选后的文档片段放入prompt，交给大模型生成回答。

这就是混合检索RAG的流程。

image-20260806212328129

上面是参考回答

再额外解释下去重:

多路召回会出现同一个文本块同时被向量检索和BM25检索命中的情况，产生重复数据。我们基于Chunk唯一ID完成去重，但这要求:同一个文本块存入向量库、全文检索库时，绑定相同的chunk_id。

什么是RRF算法​

向量检索的相似度分数，区间一般0~1，数值越大语义越匹配。

BM25关键词检索得分没有固定上限，可能是十几、几十甚至上百。

二者分数取值范围不同。

所以多路召回的两个结果列表不能直接融合

RRF(Reciprocal Rank Fusion)全称倒数排名融合，

它不看原始分数，只根据文本块在结果列表中的排名计算融合分值。

可以有效融合向量语义检索、BM25关键词检索两路结果。

之后再从融合后的列表截取前面部分，用rerank重排模型做深度语义排序。

image-20260806212435841

上面是参考回答

有同学可能会有疑问，后续都会经过Rerank模型精排，为什么还需要先用RRF做粗融合?

举个例子:

向量召回100条、BM25召回100条。

先基于chunkid完成去重，再使用RRF重新排序。

从融合后的候选列表截取Top50，送入Rerank重排模型。

我们双路召回的结果会很多，用RRF粗融合之后，再从列表里截取一部分来精排。

你知道Graph RAG吗​

Graph RAG是在向量+关键词混合检索RAG的基础上，引入知识图谱进行能力增强。

向量检索、BM25关键词检索仅针对文本块做匹配，缺少实体之间的关联链路，难以推导出分散文档里的间接关联

离线构建阶段，GraphRAG从文档中抽取实体、关系搭建知识图谱，同时对文本分片，构建向量索引与BM25索引。

在线问答阶段，一方面通过混合检索召回相关文本片段，另一方面提取Query内的实体，在图谱中遍历关联链路，找到分散在不同文档里的隐含信息。

把图谱关联信息和检索得到的文本内容整合在一起，交给大模型生成答案，解决传统混合检索RAG只能匹配片段，无法梳理实体关系链条的局限

image-20260806212544762

什么是Agenic RAG​

传统RAG的一些问题：

  • 所有问题都走检索，其实简单常识类问题不需要检索，浪费资源
  • 没有纠错和评估机制，无法判断检索内容是否准确、是否足够
  • 处理不了需要多步检索的复杂问题，比如先查 A、再查 B 才能得出结论
  • 专业术语、精确实体更适合关键词检索，纯语义检索容易匹配不准
  • 本地知识库没有的内容，不会主动去网络搜索补充，容易编造答案

解决这些问题，显然要在 RAG 的固定流程中，引入大模型来思考。

  • 让模型根据问题类型选择检索策略，简单问题直接回答，复杂问题才走完整检索
  • 评估检索结果是否相关、是否足够，让模型判断是否需要重新检索或补充检索
  • 让模型自动拆解复杂问题，决定先查什么、后查什么，实现多步检索
  • 同时结合关键词检索与语义检索，由模型统一融合多路结果，提升专业场景准确率
  • 让模型判断本地知识库是否覆盖答案，覆盖不足时自动触发网络搜索补充信息

最终把原本 “死板的检索 - 生成” 流程，升级为可思考、可判断、可纠错的智能 RAG 架构。

Agentic RAG是引入大模型来自主决策怎么检索

把混合检索、知识图谱检索、联网搜索等各类检索能力封装为工具

收到用户提问后，Agent 会理解需求，完成Query改写，自主选择调用哪种检索工具

拿到检索结果之后，Agent会校验现有信息是否能够充分解答问题

如果信息不足，它会优化查询语句，发起新一轮检索，形成规划、工具调用、结果评估、迭代重试的闭环

直到搜集到充足信息，再整合上下文输出答案。

image-20260806212619500

你知道父子分块策略吗​

父子分块策略，是先将长文档切分为粒度较大的父块，再在父块内部进一步切分出更小的子块。

子块做向量化，存在向量数据库，父块不做向量化，存在其他数据库。

子块通过parentid和对应父块建立关联。

子块负责向量检索，保障召回的精准度;

检索命中子块后，再通过关联关系取出完整父块，把父块作为上下文交给大模型做生成。

本质就是把检索用的分块和生成用的分块进行解耦，子块做检索，父块做生成。

好处是既能发挥小分块检索精准的优势，又解决了子块内容碎片化、上下文不全的问题。

同时规避大分块直接向量化造成的召回噪声，让大模型获取完整连贯的上下文，有效缓解幻觉，提升回答的完整度与准确性。

image-20260806212714816

上面是参考回答

这里解释下召回噪声

长文档直接向量化，会导致召回不够精准，容易把无关的文档召回，这就是召回噪声，它属于检索阶段的概念。

用子块做检索可以缓解这类召回噪声，让检索更精准，定位到真正相关的父块;

之后再取出完整父块上下文交给大模型做生成。

如何降低大模型的幻觉​

降低大模型幻觉可以从知识层、提示词层、模型层、校验层4个层面处理:

知识层：

接入RAG检索机制，保障知识库原始数据准确，合理划分Chunk。

采用向量检索+关键词混合检索，兼顾语义匹配与关键词精准匹配。

用Rerank重排模型，过滤相关度低的文档片段。

设置相似度阈值，阻止低相似度片段进入上下文。

引入Agentic RAG自主评估检索结果（把「用户问题 + 检索出来的文档/Chunk」一起给评估模型，让模型判断这些文档是否与问题相关、是否足够回答问题。），信息不足时迭代补充检索，保障上下文充足可靠。

提示词层：

通过Prompt强约束模型，仅依据给定上下文生成答案，要求答案标注原文引用。

开启拒答机制，无匹配信息时如实回复，禁止模型编造内容。

模型层：

选用事实性、稳定性表现更优的大模型。

面向垂直领域，可使用高质量业务数据进行微调，让模型更倾向依据外部资料作答

校验层：

将 问题 + 检索上下文 + 模型答案 交给评估模型，判断答案是否有上下文依据、是否存在事实错误。

识别出无依据、前后矛盾的内容，进行拦截、修正，减少错误输出。

image-20260806212854823

RAG如何做权限过滤​

我们项目基于RBAC模型做检索权限控制。

文档切片入库时，chunk会继承父文档的权限配置，将允许访问的角色、是否公开等权限信息作为元数据，同步存入向量数据库与全文检索库。

用户检索时，会先从获取当前用户的角色集合。

基于角色元数据做筛选，只在该用户有权访问的切片范围内执行语义与关键词匹配。

从源头拦截无权限的文档片段，之后再做 Rerank 重排，选出 Top-K相关chunk 交给大模型生成回答。

其实如果再严谨的话，在把chunk交给大模型之前，再做一次权限的校验。根据 userId + documentId 再确认一次访问权限，只有通过校验的 Chunk 才进入 Prompt。

image-20260806212930742

如何评估RAG的效果​

评估RAG效果，一般会拆成检索层、生成层两个维度。

首先，首先要搭建一套贴近真实业务的测试数据集，覆盖高频问题、边界case、易混淆的问题等。

每个问题都要提前标注好标准答案、应该命中的文档以及核心chunk片段，作为后续评测的依据。

检索层主要看两点:

一是有效信息能否成功召回

二是召回的有效信息排序是否合理。

对应的量化指标可以用Recall@K、Hit@K、MRR等来评估。

生成层主要看:

一是忠实度，保证回答不瞎编、全部有据可依;

二是答案相关性、完整性，对标标准答案，校验回答是否答得准、答得全。

整体来看，检索层侧重信息的充分召回与合理排序，生成层侧重回答的答案准确、避免幻觉，二者共同构成完整的RAG效果评估体系。

image-20260806213027002

上面是参考回答

具体的指标过一下：

检索层指标：

Hit@K

Top-K 个召回结果里，是否至少有一个是正确的、相关的结果。

Recall@K召回率

一个问题所需要的“所有相关 Chunk”中，有多少被 Top-K 检索结果找回来了。

示例：

Recall@5=0.8，意思是所有应该被召回的相关文档/Chunk 中，有 80% 出现在 Top 5 结果里。

Hit@K：只关心“有没有命中”。

Recall@K：关心“所有相关结果中，召回了多少”。

Precision@K 精确率

Top-K里相关文档占比，衡量噪声多少的指标

示例：

返回5条结果，只有2条真正有用，剩下都是无关内容，精确率就是0.4

MRR衡量正确文档排序位置，越靠前分越高

示例：

正确内容排在第2位，就打1/2分，排得越靠前分数越高

Hit@K相关文档只要出现在Top-K即命中，只看有无，不看位置

检索指标小结:Recall保证不漏掉信息，Precision减少无效内容，MRR看排序好不好

检索层这些指标依赖标注好的标准文档，是可精确计算的客观指标，不依赖大模型打分。

生成层指标:

Faithfulness (忠实度)

校验输出内容是否全部来源于检索上下文，用来识别模型幻觉

示例：

资料写v2支持批量导入，AI说成v3支持，忠实度就很差，属于幻觉。

Answer Relevancy 答案相关性

回答是否针对用户提问，不跑题、不答非所问

示例：

用户问接口报错原因，模型大段讲业务背景，没有回答报错，相关性差。

Answer Completeness 答案完整性

是否覆盖标准答案全部关键要点。

示例：

问题需要返回3个配置项，回答只说了2个，完整性不足。

Context Utilization 上下文利用率

评估模型对检索回来的上下文信息的实际利用程度。

示例：

检索结果已经包含问题解决方案，但模型依旧输出通用套话，没有使用参考信息。

这几个生成层的指标一般都是LLMasJudge让大模型来判断打分，也可以人工复核

这些就是RAG评估的堂用指标

image-20260806213141200

为什么Claude Code不用RAG检索代码而是用grep​

Claude Code早期试过本地向量库+嵌入模型的RAG方案，后来放弃了，改用模型自主调用 grep、glob、read 等工具的 Agentic Search

有几个原因:

一是因为代码需要的是精确匹配，而不是语义模糊匹配

自然语言适合向量语义检索;但代码的函数名、类名、变量名、报错字符串本身就是标识符，更适合关键词精确查找

二是代码库高频变更，RAG索引很容易过时

代码库频繁改动，RAG要持续更新索引，滞后就会拿到已删除、重构的旧代码。

grep直接读取磁盘实时文件，结果和源码版本完全同步

Claude Code现在是 Agentic Search，让大模型自主决策检索过程:

决定使用grep做内容关键词检索，或是glob做文件名匹配

获取候选文件列表后，调用read读取目标文件完整内容

如果信息不足，自动调整搜索关键词，循环迭代继续查找

image-20260806213413546

标签：