大模型面试必问RAG：核心原理、对比与实战避坑指南

最近在系统盘大模型应用方向的面经，发现一个绕不开的大头就是 RAG，检索增强生成。这个词几乎出现在每一场大模型相关面试里，不管是算法岗还是应用工程岗，面试官都喜欢从RAG切入，一路往下问。我本来以为原理听熟了就行，结果真把问题往深里挖的时候，才发现很多细节其实没有真正想透。这篇就把我自己梳理过的RAG高频问题、核心原理、对比逻辑和踩过的坑整理成一份可以反复看的面经笔记，当作系列第一篇。

1. 为什么RAG会出现在几乎每一场大模型面试里

1.1 大模型落地眼下遇到的那些真实瓶颈

先把一个基本问题想明白：大模型本身再强，也有它回答不了的问题。这种“回答不了”不是模型能力不够，而是知识来源受限。训练数据决定了模型只能知道截止到某个时间点之前的事情，可现实业务里用户问的问题，往往集中在内部文档、私有知识库、实时数据这些模型根本没见过的内容上。

我自己见过很多次这种场景：企业想把几万页的产品手册变成一个问答机器人，模型直接拿来答，用户问“新版本的某个参数怎么配”，模型很容易一本正经地编一个不存在的配置项，听起来还挺像回事。这就是行业里说的幻觉问题。要解决这个，不能说靠模型再训练就能搞定，因为文档每天都在更新，模型训练成本又高，不可能为了每个新文档都重新训练一次。

RAG的思路其实特别朴素的：模型不知道答案，那就先到外部资料库里去把最相关的内容捞出来，再把这些内容塞进提示词里，让模型带着资料来回答。相当于给模型配了一个随时更新的外部记忆，模型只需要学会“怎么基于已有材料作答”就行。这个思路既绕开了重新训练的高成本，也能保证回答内容有据可查，所以成了大模型落地最常见的方案之一。

1.2 面试官问RAG，真正想考察的是什么

我在准备面经的时候发现，RAG相关的问题通常不是考察孤立的知识点，而是想通过这一条线把候选人的综合能力摸清楚。

第一层是基础原理。问你什么是RAG，能不能把索引、检索、生成三个阶段讲明白，考察的是你有没有真正理解这套技术栈的基本工作方式，而不是只记住了几个名词。

第二层是决策能力。问你RAG和微调怎么选、RAG和长上下文方案怎么取舍，考察你有没有在实际项目中做过方案评估。这一层特别容易暴露问题，因为很多人只背了一堆概念，却说不清楚在什么场景下该选哪个，选了的理由到底是什么。

第三层是工程落地感。面试官会通过追问细节来考察：分块大小怎么定、嵌入模型怎么选、检索召回多少条合适、重排序要不要做、Bad Case怎么排，这些全是做真实项目时会遇到的问题。如果你没亲手搭过一套流水线，这些问题基本很难答到点子上。

第四层是问题排查能力。比如你做的问答系统效果不好，用户说模型答非所问，你会从哪里下手。这一层最体现经验，也是拉开差距的地方。

所以准备RAG面经的时候，不能只背概念，得把自己的完整思考过程理一遍，包括做过什么、遇到了什么问题、最后怎么解决的。面试官其实想知道你有没有能力独立支撑起一个RAG项目。

1.3 RAG典型业务场景，说几个好讲清楚的

面试里提到应用场景，尽量不要抽象地说“可以用在很多地方”，要能举出具体场景和其中的技术难点。

我准备过几个方向。第一个是知识库问答，比如企业内部的员工手册查询、产品FAQ，用户问一句，系统到文档库里检索答案。难在文档格式五花八门，有PDF有表格，还经常有人名或者专有词，检索容易不准。第二个是客服辅助，用户发起问题，系统先到历史工单里找相似问题，把解决方式和相关案例整理出来，辅助客服人员回答。难在历史工单质量参差不齐，语气乱、口语多、噪音大。第三个是专业内容生成，比如分析师写报告时，系统抓取最新数据、新闻和相关研报片段来辅助生成，这种场景对时效性和引用来源要求比较高。第四个是私有化知识服务，比如企业把内部技术文档做成对话式查询，安全要求高，往往还要全部本地部署。

每个场景都能顺带说出对应的技术选型考量，这样答题就不空了。

2. 经典RAG流水线：索引、检索、生成

2.1 索引阶段的关键动作：加载、清洗、切分、向量化

我把RAG分成三个阶段去理解会清楚很多：索引、检索、生成。其中索引是整个系统的地基，这个阶段做不好，后面全白搭。

索引阶段的第一步是把文档加载进来。不同格式处理方式完全不同，PDF要考虑解析版式，Word要处理标题和表格，HTML要去掉标签提取正文。很多真实项目的坑都埋在加载这里，尤其扫描版PDF，直接解析经常乱码，还得走OCR流程。

加载完之后是清洗。文档里往往夹杂着页面页脚、表格错位、换行符乱七八糟的内容。如果不清洗，后面切分出来的文本块质量会很差，检索效果直接打折。我见过一个案例，PDF里一个句子被页脚隔成了三段，检索的时候明明有关键词，却因为碎片化导致语义被冲淡，召回的排名反而很靠后。

清洗完最关键的一步是切分，也就是把长文档切成一个个小片段。为什么要切？因为嵌入模型和语言模型都有输入长度限制，而且一篇几万字的手册直接整篇编码成一向量，语义信息早就被稀释了，检索根本定位不到用户想要的那一小段内容。具体怎么切我后面会详细展开，这里先记住切分的两个目标：一是每个片段语义尽量完整，二是片段之间的长度大致均匀，便于管理。

切完之后就到了向量化。用的是嵌入模型，把文本片段转换成向量。向量是一个由浮点数组成的数组，比如一个一千多维度的高维向量，它让文本变成可以用数学计算的形态。语义越相似的两个文本，它们的向量在空间里就靠得越近。向量化之后把这些向量存进向量数据库，同时把原文也存起来，方便后面检索到结果以后取出来用。这里的几个考量细节，章节再说。

2.2 检索阶段：从向量库到召回策略

索引阶段建的库，检索阶段就是去用。用户在对话里提了一个问题，系统需要先去向量数据库里找最相关的文档片段，找出来以后交给模型。

大致的流程是：先把用户的问题喂给同一个嵌入模型，转成向量；然后拿这个向量到数据库里做相似度计算，找到距离最近的若干个片段；最后把这几个片段按顺序拼起来，作为上下文交给你选用的生成模型。

这里面有几个我经常在面试里被追问的细节。第一是“同一个嵌入模型”这句话很重要，如果索引用的是模型A，检索的时候用模型B，两边向量空间不一致，检索结果完全不可信。第二是召回数量怎么定，Top5、Top10还是Top20，太少了可能漏掉关键内容，太多了会把无关内容也塞进上下文，影响生成质量，还要增加模型处理的token数。第三是相似度怎么算，最常见的是余弦相似度。第四是向量检索查出来的结果到底精准度够不够，这是RAG系统里最大的一块变数和优化空间。

工程上还有一个点，向量检索只是召回的手段，不是最终排序的依据。真实系统里，往往会把向量检索当作第一轮粗筛，先把候选范围缩到几十条，再用更强的方式精排，保证真正有用的内容能排到最前面。这个“粗召+精排”的思想，面试中非常加分。

2.3 生成阶段：上下文注入与答案构造

生成阶段反而是整个流程里看起来最简单、但细节最影响体验的一环。系统把检索到的片段塞进一个设计好的提示词模板里，再附上用户的原始问题，一起交给语言模型生成最终回答。

提示词模板怎么设计很重要。要明确告诉模型：只能依据给出的资料回答，资料里没有的内容直接说不知道，不要编造；回答时可以引用资料中的关键信息，但不要逐字照抄，要重新组织语言；如果是列表型问题，要用清晰的结构输出。目的就是明确地对齐模型行为的边界，尽量把幻觉压下去。

这个阶段我还注意到一个容易被忽略的点：检索片段怎么排进上下文也有讲究。假设你检索到了五条相关片段，是原样往模板里一塞就行吗？不是。通常要按相关性从高到低排列，也可以先在片段前面加一个简单的编号或标题，让模型能区分不同来源。如果结果里有一个片段明显和问题无关，最好直接过滤掉，别让噪声干扰模型判断。

生成阶段的策略还包括：要不要让模型输出引用来源、要不要给模型一个“放弃回答”的选项、要不要做答案重写让输出更口语化。这些都属于生成策略的问题，面试时可以提，能体现出你对用户体验的考虑。

2.4 一个完整流程跑下来，数据是怎么流动的

用一句话把整个流程串起来：文档进门，切块编码进库；问题进门，编码后去召回；召回结果组装成提示词；模型基于提示词输出回答。听起来很线性，但实际项目里，每个环节都可能被反复调试。

我把数据流动拆理解一下。它把整个流程分成离线和在线两个部分：离线部分负责处理文档、构建索引，可以提前跑好，不占用用户请求时间；在线部分负责处理用户问题、检索、拼上下文、生成回答，必须控制在几百毫秒到几秒内。示意图层面是这样，文档先经过解析引擎生成纯文本，再经过清洗和切分成为若干片段；每个片段经过嵌入模型变成向量，写入向量库；线上收到用户query后，query也变向量，从库里查TopK，得到候选片段；片段传递到重排序器，重排选出精排片段；最后和系统提示词、历史对话一起送到生成模型，输出答案。

这个流程的理解程度，基本决定了RAG面试能走多深。脑子里有了这张流程路网，后面不管面试官往哪个方向深入问，都能接得住。

3. 面试必答题：RAG和微调、长上下文怎么选

3.1 RAG与微调：各自的优劣势对比

这是RAG面试里出镜率最高的一道对比题。先说结论：RAG和微调不是对立的，解决的问题也不完全一样，更多的时候是配合使用。但面试官问这道题，通常是想看你怎么在有限条件下做选择，而不是等一个标准答案。

RAG的核心优势在于不动模型本身，知识更新快，今天文档改了，重新把文档切片进向量库就能生效，成本低、可控性强。它天然适合知识密集型场景，比如企业知识库、客服问答、私有文档查询，因为回答可以被资料支撑。

微调的核心优势在于改变模型本身的行为模式和风格。比如让模型更贴合某个行业术语的表达习惯，让模型的回复语气更像是某个品牌的客服，或者让模型学会某种特定的输出格式。微调适合的是模型行为训练，而不是知识注入。如果你指望微调让模型记住几千页文档，训练数据量会非常夸张，效果还不一定稳定，成本也高得离谱。

我把对比点整理一下，面试时可以照着说：

这个对比如果光背出来，很干，面试官继续追问一句“那你实际项目里怎么选”就容易卡住。最好准备一个自己经历过的场景去说明，比如某个项目里要做一个内部文档问答，那时你选择RAG是因为文档更新频繁、需要能追溯答案来源，同时又用微调做了提问意图分类，两者是配合关系。

3.2 RAG与长上下文：窗口真能解决一切吗

另一个高频对比是RAG和长上下文。现在很多模型的上下文窗口动辄几十万上百万token，看起来似乎可以一条提示词把整本手册塞进去，那还要RAG干嘛？这个问题的答案，应该是既要考虑技术效果也要考虑成本。

长上下文方案的逻辑很直白：既然输入窗口够大，就把相关资料全部塞进上下文，让模型自己看完再回答。这个思路在小范围内有效，我试过把几十页的文档全部塞进去，效果确实比RAG好，因为信息没有经过切割，语义是完整的。但一旦资料量再大一些，问题就出现了。

第一是成本问题。上下文越长，token费用越高，而且模型处理长上下文的速度明显变慢，对线上交互体验来说是不能接受的。第二是效果问题。模型处理超长上下文时，有一个在业内被称为lost in the middle的现象，就是模型对长文本中间部分的内容利用效果差，信息容易被开头和结尾的内容淹没。第三是覆盖问题。就算窗口再大，也不可能把所有历史工单、所有产品手册都塞进去，用户的问题又各不相同，真正需要的只是其中一小部分相关内容。

所以面试时可以说：长上下文更适合那些“资料量可控、可以一次性读完”的场景，比如单篇长文档的总结、翻译、整本资料分析；RAG更适合“资料量巨大、答案是局部的”场景，比如企业级知识库检索。现在主流做法是RAG和长上下文结合，先用检索缩小范围，再把检索出的相关片段完整塞进模型上下文，兼顾覆盖和效果。

3.3 如何给出“组合拳”式答案

这道题如果想答出水平，就不要给出非此即彼的答案，而是展现你自己的系统设计思维。我准备了一个相对完整的作答思路。

首先说明判断维度：你的知识更新频率、成本预算、可解释性要求、延迟要求、资料体量。不同维度的权重决定了方案的偏向。然后结合一个例子展开：某项目里资料库有上万份文档，用户问题高度依赖最新资料，同时需要回答有出处，那RAG就是主架构；再配合场景对这种任务做一些微调，比如让模型更懂用户提问的表达习惯；如果遇到特殊用户上传了一份全新长文档，希望得到全文分析，那就单独走长上下文模式，把整份文档塞进模型。三种方案各管一段，互相补充。

这样描述的好处是让面试官看见你有完整的方案储备能力，而不是只知道某一种技术的调参。现在大模型应用基本没有银弹，组合式架构才是工程常态。

4. 面试官深挖不放手：关键细节逐个击破

4.1 分块到底怎么切：固定大小、重叠、语义切分

分块策略是RAG面试里最被高频追问的工程细节，也是实际项目里影响效果最直接的一环。我刚做RAG项目时，就是随便定一个块大小，比如512个字符，后来发现效果不稳定。简单场景够用，但复杂文档就很容易翻车，因为固定大小切分完全不理解语义边界，经常把一段逻辑完整的话从中间劈开。

固定大小切分的优点是简单、可控、实现成本低，适合内容相对规整的文档。但它的问题也很明显，就是会把句意切断。比如一句话讨论某个接口的调用方式，前半句讲参数定义、后半句讲返回结果，一刀切成两块，检索的时候如果用户只问了返回结果，单独看后半块，缺少前半句的定义，答案就不完整。解决这个问题有一个常见技巧，就是让相邻块之间有一定程度的重叠。我常用的做法是：块大小512个字符，重叠部分50到80个字符。这样即使切断了，下一块开头会带上上一块的结尾，资料的上下文信息有一定连续性。

更高级的方式是语义切分，根据标点符号、段落结构、标题层级这些信息找到自然的语义边界，再在这个边界附近切分。比如按段落切、按章节切，或者根据Markdown标题来切。通用文本里，我已经过惯用迭代式切分：先用段落作为最粗粒度，如果段落太长再按句子边界切开，这样能最大程度保留语义完整性。还有一种方法是利用模型做切分，成本较高，适合对效果要求极高的场景。

面试时最好把这几层都说清楚，再补一句：没有哪种分块策略是万能，需要根据不同文档类型去测试对比选型，选型依据最终看检索效果。

4.2 嵌入模型与向量化原理

分块决定了检索的粒度，嵌入模型则决定了检索的语义理解水平。面试官经常会问：嵌入模型怎么选？别小看这个问题，回答得好不好，很能体现项目深度。

先说嵌入式模型的本质。它做的事情是把一段文本映射到一个高维向量空间，在这个空间里，语义相近的文本距离更近。比如“怎么退款”和“如何申请退货”，字面差异很大，但因为语义相近，它们的向量距离会很近。这就是向量检索能突破关键词匹配局限的原因。

选嵌入模型的标准，我自己的体会是一看模型能力、二看维度、三看稀缺词覆盖、四看成本。模型能力看它对领域内的语义理解是否足够；维度不是越高越好，维度高信息丰富但存储和计算开销大；稀缺词覆盖要看模型对专有名词、产品名、人名这种标准场景之外的词汇能不能正确嵌入；成本包括调用费用和部署成本。另外还有一个很关键的点：同一套系统，索引阶段和查询阶段必须使用完全相同的嵌入模型，这一点我会在面经里专门标出来，因为它是初做RAG的人最容易犯的错误之一，换模型就要重新切库，这个教训我吃过一次。

面试时还可以补一句关于文档篇幅的话：如果拆出来的块比较长，整个块直接转成一个向量，这个向量包含的信息含量会很高，但可能不够聚焦；如果块太短，向量对上下文理解又不够。嵌入模型和分块策略其实是绑定在一起调试的。

4.3 向量检索怎么选：稠密、稀疏与混合检索

向量检索是RAG的核心环节，但面试里真正能把这个话题讲透的人不多。我整理一下几种检索方式：纯稠密检索、纯稀疏检索、混合检索。

稠密检索用的是语义向量，理解能力强，能处理同义词、近义词、上下文意思。比如“这款产品耗电吗”和“续航表现怎么样”，在语义上是相近的，稠密检索通常能抓住。但它的弱点是依赖嵌入模型的理解能力，如果模型对某些专有名词、缩写、型号不敏感，或者数字型查询精确匹配要求很高，检索效果就会下降。

稀疏检索走的是传统关键词路线，可以理解为把文本表示成词频向量，精确匹配能力强，对专有名词、编号、型号很友好。但它没有语义理解能力，换个说法就匹配不上了。两种方式单独用，效果都有天花板，所以实际上现在越来越多项目会用混合检索：同时跑稠密和稀疏两路，综合打分。

具体做混合的时候，通常会给两路召回各自一个权重，然后把分数融合，比如用倒排融合（RFF）来合并两路结果。这么做的好处是既保留了语义召回的优势，又能确保精确匹配的内容不会因为嵌入模型理解偏差被漏掉，尤其在产品型号、编号、政策条款这类领域很有用。我自己的体会是：在通用知识库场景，稠密检索为主已经够用；但如果资料里充满了专有名词、编号、精确数据，混合检索基本上是必须的。

4.4 为什么“检索出来不等于可用”：重排序

很多刚接触RAG的人会有一个误区：觉得向量检索出来的Top5就已经是最好的结果了。实际上，向量检索的召回结果只是一个“候选集合”，里面很可能混着一些看着相似但实际不对题的片段。面试官很喜欢针对这点追问，就是为了看你对“召回-精排”体系是否有概念。

重排序的原理是：用向量检索先快速召回一批候选片段，比如50条，再用一个更强的模型逐一计算每条候选和用户问题的相关性分数，然后重新排序，只取最前面的几条。为什么不能一开始就用重排序模型？因为重排序模型的计算成本远高于向量检索，对全部文档逐条算，线上性能根本来不及。先粗筛、再精排，是经典的业务逻辑。

重排序模型我会选择专门学习这个任务的模型。另外，实践里还有一些轻量技巧：如果用户问题里包含关键词，可以用关键词命中情况给候选加分；在结构化数据里，某些字段的精确匹配权重更高；还可以手动给不同文档来源设置不同的优先级。这些都不需要额外的模型，也能明显改善效果。

面试时提到重排序，我建议一定强调它不是可选项，而是效果优化的关键环节——很多评测里加不加重排序，指标差异是非常大的。

4.5 召回率和精确率的博弈

RAG系统的效果，本质上是信息检索质量决定的。面试官可能会问你：怎么衡量检索好坏？这里两个指标绕不开：召回率和精确率。

召回率衡量的是所有与该问题相关的文档片段里，系统到底捞出来了多少。精确率衡量的是系统捞回来的片段里，有多少是真正相关的。这两个指标是天然矛盾的，召回率高了，往往会把大量无关片段也带回来，精确率就降了；精确率太高，又容易漏掉真正有用的内容。

怎么平衡，要看应用场景。比如知识库问答，用户问一个问题，如果相关片段没被召回，模型就只能瞎编，所以宁可多召回一些，也要保证答案被看到，此时召回率优先。而另一种业务比如邮件分类，把不相关的内容召回来，会让模型输出一堆噪声信息，此时精确率优先更合适。

具体调优的时候，我一般通过调整召回数量来观察效果变化：Top5效果不好就试Top10，Top20，配合重排序找出当前数据下的最优区间。也可以用评分阈值的思路，低于某个相似度分数的片段直接丢弃。千万不能只看单条Case，需要你从测试集数据里统计整体趋势来判断召回率、精确率的变化，并据此确定阈值。这个思维过程面试官很看重。

5. 进阶面经：检索增强的复杂形态

5.1 多跳检索与迭代式RAG

基础RAG只能处理单轮检索能解决的简单问题，面试问到你熟悉哪些进阶方向时，可以谈谈多跳检索与迭代式RAG。

什么是多跳问题？就是用户问的问题，需要跨多个文档片段拼出答案，光靠一次检索根本不够。举个例子，用户问“A部门去年和B公司合作的那个项目是由谁负责的”，答案分散在三个不同的文档里：一个文档记录了A部门的合作项目列表，另一个文档记录了该项目的成员名单，第三个文档才对应到负责人。一次检索可能只命中一份，无法给出完整答案。

迭代式RAG的做法是：根据用户问题先做第一轮检索，拿到结果；如果模型判断信息还不够，就把当前的中间结果作为新的线索，衍生出新的查询词或查询条件，再做下一轮检索；数轮后再综合所有收集到的内容生成回答。听起来很灵活，但代价是回答时间变长、成本变高，还可能越检索越偏离原始问题，所以通常需要设定最大迭代轮数，避免失控。

面试里讲这部分时，我会说明：多跳RAG本质上是在“用更多检索步骤换取更完整的答案”，适用于复杂推理型问题，但要做很多工程约束来控制成本和话题漂移。这样显得考虑全面。

5.2 RAG与Agent结合

如果再往上走一层，RAG完全可以被当成Agent的一个工具调用环节。这个结合方式是目前大模型应用架构里比较高级的打法，面试聊到这里时属于加分项了。

Agent的思路是让模型自己决定怎么做：面对用户问题，模型先判断需要查什么，然后决定调用哪个工具，工具返回结果后，模型再基于结果继续推理。RAG在这里面不是一个独立的管道，而是Agent可选用的众多工具之一。比如用户问“这个月的退款率和上个月比，差了百分之几”，Agent可能先调一个数据查询工具拿到本月的退款率，再调一个历史数据接口拿到上个月的数值，最后算出差值，并组织成回答。也可能会觉得需要查公司政策，再触发一次RAG检索。

这种架构好处是扩展性强，模型不再只是回答问题，而是在调度多个信息源。难点在于模型要走多步判断，可靠性就成了大问题，所以通常需要控制Agent的执行步骤，有的地方明明可以直接RAG一步到位，就不要让Agent绕一大圈。面试里能讲出这种“组合和约束”的意识，比单纯堆概念要好很多。

5.3 结构化数据、表格与知识图谱RAG

还有一个值得准备的进阶方向：非纯文本场景的RAG。很多真实业务资料不只是文档，还有大量表格数据，例如财务数据、用户名单、库存清单，这些数据直接在纯文本RAG里处理，效果很差。

表格RAG大致有这么几条路线。一条是把表格转成自然语言描述再做常规RAG，比如把“库存表：SKU_001，可乐，2023-11-01，500件”转换成“SKU_001是可乐，入库日期2023年11月1日，数量500件”，让它变成模型和向量检索更容易理解的文本。另一条是先把表格切成Excel里的单元格区域，利用行列标题信息来实现检索，需要先识别出用户问题涉及哪几个行列。还有一条是混合检索加代码生成，让模型先写一个查询脚本，直接对结构化数据做查询。

知识图谱RAG是更硬核的方向，把文档里的实体和关系抽取出来，构建成图结构，用户提问的时候，既做向量检索，也可以在知识图谱上做多跳路径推理，然后把图上的相关路径或三元组作为上下文再给模型。做法很优雅，适合实体关系复杂的领域，但构建成本高，知识图谱的维护也是大工程。面试时不需要深入实现细节，如果能讲清楚“不同数据结构对应不同RAG方案”，就已经很能打了。

5.4 怎么评估一套RAG系统

评估思路上，我一般会把评估切成两个层面来看。第一个层面是每个模块单独评估，分为检索质量和生成质量。检索质量看召回率和精确率、指标上加一个nDCG（Normalized Discounted Cumulative Gain）。生成质量看回答是否正确，关注三个方面：忠实度，衡量生成的回答是否严格基于检索到的上下文内容，有没有凭模型自己的知识瞎编；相关性，看回答是不是真的解决了用户的问题，而不是答非所问；以及完整性，看有没有遗漏关键信息。

第二个层面是端到端评估。用户实际体验到的答案，是一个复杂加工的结果。最好的办法是构建一组评估数据集，其中包含真实用户问题、对应的标准答案、以及相关的标准文档片段。遇到已经知道正确答案的问题，就能把真实答案和系统输出做对比。如果没有人工验证的资源，也可以让大模型当裁判去打分，但大模型互评既省时也省力，缺点是有“偏袒”现象，仍需要人工抽检。

评估数据集的构建，建议从真实线上日志里抽样，不要自己编问题，否则覆盖不到用户真实问法。这部分的深度很能体现项目经验，面试时一定要准备。

6. 真实排查经验：那些面试里能讲的踩坑实例

6.1 分块边界切断语义，回答不完整

我在项目里遇过一个很典型的坑：用户问“缺货订单如何处理”，系统给出的回答只有一个支离破碎的句子，完全没有讲清操作步骤。后来排查发现，问题的根源不在检索也不在生成，而在分块阶段。

那份文档是一段操作手册，分块用的是固定大小切块，512字符一块，结果正好把一个完整的“缺货订单处理流程”从中间切成两半，前半块只有“若订单缺货则标记为等待补货”这句，下半块才有“联系供应商并在系统中更新预计到货时间”。用户的问题检索命中了前半块，模型只看到了“标记等待补货”，自然答不完整。

这个Case给我几个教训。第一个是分块不能只看字符数，要看语义边界。第二个是可以给同一份文档保留两条索引路径，一条粗粒度，一条细粒度，检索时同时查。第三个是遇到“回答不完整”这类Bad Case，先不要急着改提示词，检查分块边界往往更快定位问题。

面试里讲这种真实案例，面试官会明显更感兴趣，因为这比背诵分块策略有用得多。

6.2 召回了相似内容，但生成的就是不对

另一个我印象很深的案例是用户问“iOS版的录制功能为什么闪退”，系统召回的片段全是关于“录制功能使用说明”的内容，相似度分数也很高，但就是没有解决闪退问题的答案。这是典型的“语义相关但是答案不对”的问题。

用户的问题是排障类问题，需要召回的内容不仅和“录制功能”相关，还得和“闪退”这一故障现象相关。向量检索只看语义相关性，“录制功能使用说明”和“录制功能闪退”在语义上是相近的，都会被召回，而且分数可能都不低。光是看Top结果的相似度，根本分辨不出来。

这个问题我最后是通过两条路解决的。一是在文档索引阶段就有意识地把“问题描述”和“解决方案”打上不同的标签元数据，检索的时候优先召回问题描述类内容。二是在重排序阶段专门训练或挑选对“故障-解决方案”匹配更敏感的模型，这种对细粒度语义差异的分辨能力，普通向量模型不一定具备。

这个Case也让我明白一个道理：RAG系统的效果不是某一个模型的单点能力，而是每个环节配合出来的结果。

6.3 上下文放多了，回答反而更差的lost in the middle问题

我记得有一次把检索数量从Top5调到Top10，目标是让模型看到更多信息，结果回答质量反而下降了。用户问的明明是一个具体参数配置，模型居然开始答非所问，把无关的其他配置也写进去了。

后来查资料才知道，这就是语言模型长上下文处理中的一个现象：模型对超长上下文里中间位置的信息利用度较低，注意力更容易集中到上下文开头和结尾的内容，中间的信息容易被“忽略”。我要真验证的时候，把相关片段放到了提示词的最后，然后把几段不相关的内容放在前面，结果模型答得非常好。说明问题不在模型能力，而在上下文组织方式。

调整方案有几个。一是控制检索数量，不要盲目追求多，通常Top3到Top5就足够了。二是把最相关的片段放在开头和结尾这些“高注意力区”，中间的部位放相对次要的补充内容。三是在提示词里明确告诉模型哪个片段是最关键的，直接引导模型优先看。四是如果业务允许，可以分多次生成，每次只聚焦一个子问题，避免一次塞入太多内容。

这类细节，在面试实战里属于“加分项”，能说清楚往往比单纯背一个RAG的流程运转逻辑更有说服力。

6.4 我们怎么一步步定位Bad Case

最后总结一套定位Bad Case的排查方法，面试被问“RAG系统效果不好怎么排查”时可以直接套用。

第一步，先看问题出在哪个环节。我自己定的排查顺序是：加载解析对不对，分块合不合理，向量检索召回的片段里有没有正确答案，重排序有没有把正确答案顶掉，生成模型有没有忠实于上下文。从召回结果截断检查开始，通常能很快定位。

第二步，针对检索类问题看“召回列表”和“命中位置”。如果正确答案根本不在召回列表里，说明问题在索引或检索，要继续查是分块太粗太细、嵌入模型理解不行，还是检索方式不对。如果正确答案在列表里，但排得太靠后，没进最终TopK，说明问题在排序或粗召精排衔接。如果最终上下文里有正确答案，但生成结果还是错，那问题在生成阶段的提示词设计或模型行为模式。

第三步，用归因法界定问题边界。写一个小工具，把每个Case的用户问题、召回结果、重排序结果、最终上下文、生成输出全部存下来，逐层人工查看。没有这个过程，排查完全靠猜，效率极低。

这个方法在面试里展现出来，能让面试官对“这个人是真做过项目”的判断大幅提高。

7. 答题套路与面试准备建议

7.1 用一个案例串起全部知识点

面经过到最后，我发现最有效的准备方式不是背一堆零散答案，而是准备一个完整而真实的项目案例，用这个案例把RAG几乎所有的知识点串起来。

我自己准备的案例是某公司的内部知识库问答项目。从背景开始：文档量上万份，格式包括PDF、Word、表格，用户问题以操作类为主，要求回答有出处、更新快。然后讲方案设计：为什么选RAG而不是微调，为什么检索层用了混合检索，为什么要加重排序。再讲遇到的坑：分块切断语义、数据检索精确匹配失败、上下文过长导致效果下降，分别怎么排查解决的。最后讲评估：怎么构建测试集，如何衡量忠实度和召回精确率，效果从多少提升到多少。

这个案例一讲，等于把前面所有内容在面试官面前完整地过了一遍。面试官提问也会顺着案例展开，他问的每一个细节你都准备过，自然不容易慌。

准备案例的时候有一个重要原则：细节虽然可以是虚构风格模拟，但逻辑必须自洽。比如你说选择了混合检索，就要能解释为什么不用纯向量检索。面试官最反感的是那种一听就是背出来、经不起追问的经历。

7.2 遇到不会的问题怎么办

哪怕准备再充分，面试中还是有大概率碰到自己真没接触过的问题。我以前遇到这种情况容易慌，后来总结出一个相对稳定的应对套路。

首先，不要直接说“我不知道”，也不要凭空硬编。可以说“这块我了解过不多，但我基于现有经验推断应该是这样”。然后把问题和你熟悉的知识做类比，把已知的部分讲出来，把猜测的部分明确标注为假设。举个例子，如果问“如何降低向量检索的成本”，即使没实际部署过市面上某些大规模场景，也可以从量化、向量降维、分片策略、缓存这几个自己熟悉的思路去推，同时说明“具体方案需要实测验证”。

其次，还有一种很实用的处理方式：把问题拉回到你熟悉的场景里。比如面试官问“多模态RAG怎么做”，如果没实际做过，可以说“我目前更多接触的是文本RAG，但多模态RAG的架构我看过一些，它需要扩展的是文档解析和嵌入模型两个部分……”这样既承认了不足，又把话题带到了自己的主场。

永远不要给自己挖坑。回答中提到的每一个名词，都要确保你是真理解的，否则面试官顺着追问一句就会露馅。

7.3 我的复习节奏和方法

最后分享下我自己的准备节奏，也许对同样在准备的人有帮助。

先把原理吃透，看经典RAG论文和结构清晰的技术博客，画出流水线的完整过程图，理解每个环节的输入输出。然后细过工程细节，把文中提到的分块、嵌入、检索、重排序、评估这些问题，一条条地按面试考题形式重写、用自己的话表达出来。再动手跑一个最小RAG Demo，用一套开源文档，把整个流程从索引到问答完整跑一遍，记录每一步的日志和效果，这个过程会逼着你去理解真实工程中的细节。最后把Demo里遇到的问题变成面经素材，尤其是那些第一轮没想到会出问题的地方，面试的时候反而成了最生动的案例。

动手实操这一步我建议一定不要省。很多原理光看觉得懂了，一跑起来才发现哪哪都不对，而恰恰是那些不对的地方，才是面试里最能打动面试官的东西。

RAG这套东西，面经整理得再好，最终还是得靠真折腾来消化，没有亲手跑过完整流程，面试时经不起深挖。这篇先把RAG主干过完，后面几张再分别整理Agent、Prompt、模型部署这些方向。