最近好几个朋友在准备大模型方向的面试都不约而同来问我RAG到底该怎么准备。这问题其实特别实在现在做应用层的大模型开发RAG几乎就是个绕不开的基础功十个面试里至少有八个会聊到检索增强生成。但大多数人准备得都比较零散知道个大概流程就说要去面了结果被面试官从切分问到重排从评估问到优化一路追下去就露馅了。这篇我直接按面试官的视角把RAG面试里最常出现的6类问题串成一条线从最基础的“为什么需要RAG”讲到“召回质量怎么优化”每个问题都拆开揉碎把背后的原理、工程实现里的关键参数、以及实际踩过的坑都说清楚。你在准备面试也好还是想把手上的RAG系统做扎实都建议顺着这个思路过一遍。1. 第一问为什么需要RAG它到底解决了什么问题1.1 大模型的天然短板面试问RAG十有八九会从一个问题切入既然大模型已经很强了为什么还要挂一个检索系统在外面这个问题看似基础但很多人的回答都浮在表面上。要回答好这个问题你先得清楚大模型的天然短板在哪。第一是知识新鲜度大模型的参数是在某个时间点冻结训练的之后发生的事情它一概不知问它最近发布的新产品、新政策它只能靠推理去猜。第二是事实准确率模型倾向于生成“听起来合理”的内容而不是“真实存在”的内容这也就是所谓的幻觉问题。第三是专业深度通用模型对垂直领域里的专业术语、内部规范、非公开资料几乎无能为力。RAG的思路就是给模型外挂一个动态的知识库。用户提问时先从知识库里检索出相关内容再把这些检索结果塞进Prompt里让模型基于这个上下文来生成答案。1.2 RAG与微调怎么选面试官通常还会追问一句这些问题用微调也能解决一部分为什么偏偏选RAG这个问题要答到点子上。微调的本质是把知识写入模型参数成本高、周期长而且每次知识更新都得重新训练一轮。更重要的是微调后的模型仍然可能产生幻觉因为知识在参数里是分布存储的模型无法精确区分“我学过的知识”和“我推断出来的内容”。RAG则把知识存储完全外部化答案由检索结果驱动模型只是把检索到的证据组织成语言。某个知识要更新直接改数据库里的文档就行不需要动模型。站在工程角度看还有一个关键优势可解释性。RAG的答案可以追溯到具体的参考文档这在企业级应用里是硬性要求。合规审计也好、用户投诉追溯也好你能指出来源问题就解决大半。微调在这方面就是黑盒你很难说明模型为什么给出这个答案。1.3 面试官真正想听什么我个人觉得这道题的考察重点不是背概念而是看你有没有做技术选型的判断力。你至少要表达出两个层次第一你清楚RAG适合解决“知识频繁更新对准确率要求高需要可追溯”的场景典型如企业内部知识库、智能客服、法规咨询。第二你了解RAG的局限比如对多跳推理的能力比较弱、对检索质量的依赖极重这些局限意味着什么、怎么去补面试官听到这里才会觉得你是真的做过而不是背了一篇综述。2. 第二问RAG的完整链路到底怎么跑起来的2.1 离线索引四步走RAG的完整流程一般分成离线索引和在线检索两个阶段面试时最好按照这个框架来说逻辑会很清晰。离线阶段做的是把知识库变成可检索的数据结构核心四步文档加载、文本切分、向量化、索引存储。文档加载就是把PDF、Word、Markdown这些原始格式解析成纯文本文本切分是解决模型输入长度限制的问题把长文档切成合适大小的块向量化是把每个文本块用Embedding模型转成向量索引存储则是把向量和文本块一起写入向量数据库同时建立元数据字段方便后续过滤。这里有一个面试官非常爱追问的细节为什么不能直接把整篇文档交给模型作答原因有两个层面。一是模型的上下文窗口有限长文档塞不进去二是检索效率问题从几千篇文档里精确找到相关联的内容靠的是向量近邻搜索而不是把全部文档都喂给模型去理解。2.2 在线检索与生成在线阶段就是用户提问到拿到答案的全过程。用户输入问题后系统先对Query做理解与改写如果句子太长或口语化太重需要提取关键词、补全意图然后对改写后的Query做向量化用同一个Embedding模型把Query也映射到向量空间接着去向量数据库做近邻搜索根据相似度召回TopK个候选文档块如果有更精细的要求还要加一步重排序把召回的候选块按与Query的相关程度重新排序最后把这TopK个块拼装进Prompt交给大模型生成最终答案。这个流程里有一个几乎人人都容易忽略的问题Query向量化和文档向量化必须使用同一个模型。之前遇到过一个团队索引阶段用了某个开源的文本向量模型后面为了省成本换了个轻量级模型做Query编码两个模型的向量空间分布完全不一致检索效果直接崩掉。这个问题在面试里讲出来会显得你很有实战经验。2.3 链路里最容易翻车的地方以我实际调系统的经验来看整个链路里最容易被低估的环节是文档解析的预处理。你以为PDF解析出来就能直接切分入库实际上扫描件需要OCR、表格需要特殊解析、页眉页脚混在里面会造成噪声、多栏排版会打乱阅读顺序。这一步的质量直接决定后续切分和检索的上限。面试聊到这里时你可以主动提出预处理的重要性这比单纯背诵流程有明显优势。另一个常见翻车点是没有做去重。同一个资料库里有历史版本和最新版本检索时旧版本被召回了答案引用了过期信息。这个问题在线下很难发现用户一问才发现所以工程上一定要在索引阶段做版本管理和内容去重。3. 第三问文档切分怎么做才能让召回质量站得住3.1 切分粒度为什么是召回效果的分水岭如果把RAG比作做饭检索就是买菜切分就是切菜。菜切得不合适后面厨艺再好也白搭。文本切分直接决定了检索系统能不能把“真正相关的信息”和“用户的问题”精确匹配上。切分块太细比如每块只几十个字符检索时召回的内容往往信息不完整一个概念被拦腰截断模型拿到的上下文是碎片化的。切分块太粗比如把整章节塞进一个块向量化后特征被平均化块里的大量无关内容稀释了要害信息召回时相关性得分上不去。核心矛盾在于检索的粒度需要“块与问题”语义对齐而生成的粒度需要“上下文充足”。这两个诉求天然有张力。3.2 主流切分策略横向对比我整理了目前工程上几种主流切分策略的特点面试时可以横向比较着说切分方式实现思路优势劣势固定大小切分按字符数或Token数均匀切分实现简单效果稳定容易切断语义完整的句子句级切分按句号、问号等边界切分语义完整性较好句子太短时信息量不足递归字符切分按段落→句子→词语逐级降维切分兼顾语义完整性与块大小参数需要根据文档类型调语义切分用Embedding判断句子间语义断点切分边界更符合语义计算量大实现复杂目前业界用得最多的是递归字符切分。它的做法是从最大的粒度开始比如先按段落分如果段落超长再按句子切句子还超长就继续往下。这种策略的好处是尽量保证切出来的块是人类可读的完整语段又不会因为固定长度限制而粗暴截断。对一些复杂格式的文档语义切分在AI知识库场景效果更好因为它解决了“语义相关但地理上分散”的问题。3.3 块大小与重叠参数的实践经验面试官经常会抛细节问题你切分时块大小设多少为什么这里不用背一个标准答案但要能说出调参逻辑。块大小的设定与模型和场景强相关。常见经验值通用知识库单块在256到512个Token之间既保证语义完整性又不会超过向量模型的最大输入长度。代码类文档单块可以适当放大因为代码的语义依赖上下文环境法规合同类文档建议用句级甚至条款级切分因为这些文档里一个条款就是一个完整语义单元。还有一个容易忽略的参数是重叠大小。相邻切分块之间保留一定的重叠文本一般设成块大小的10%到20%可以避免关键信息恰好落在两个块的边界上被切散。举个实际例子如果块大小是500个字符重叠设50到100个字符就能让处于边界附近的句子在相邻两块中都完整出现显著降低关键信息被截断的概率。面试时如果能说出一句“切分策略不能脱离你的业务文档类型单独设计、需要反复看召回case来调”面试官基本就会认可你是真做过索引工程的。4. 第四问向量检索的原理与模型选型4.1 Embedding模型选型的几个关键指标聊完切分面试官大概率会追问向量化用什么模型你怎么评估模型的好坏这个问题想答好需要你了解几个硬性指标。第一个指标是检索效果在公开的中文语义相似度评测集上用准确率、召回率衡量。目前的行业经验是开源中文向量模型之间差距还是存在但头部几个都已经很能打。第二个指标是最大输入长度也就是这个模型最长能处理的文本有多长。如果你的切分块比较大就要选支持长文本的模型否则超出上限的内容会被截断向量就无法完整表达语义。第三个指标是向量维度维度越高单个向量的表达能力越强但存储开销和检索耗时也随之增加。第四个指标是推理速度Embedding要处理的是全量知识库如果模型推理太慢几十万篇文档的索引就得跑好几天。除了模型本身Embedding服务化也是个工程细节。不要把Embedding计算直接封装在业务服务里不然每次知识库更新都会拖垮在线服务最好把Embedding单独部署成异步任务。4.2 相似度计算的数学直觉向量化之后如何判断两段文本长得像这就涉及相似度计算。最常用的指标是余弦相似度衡量的是两个向量在方向上的接近程度。余弦相似度等于两个向量点积除以模长的乘积范围在-1到1之间越大越相似。实际工程中向量数据库一般默认用内积或余弦相似度。用归一化向量时两者的排序效果等价所以很多向量库直接用点积实现因为计算效率更高。L2距离衡量的是向量在空间的绝对距离更关注“量级”差异在文本语义相似度场景里用得相对少一些但在对向量模长敏感的场景也有它的价值。面试时讲清楚核心的余弦相似度原理向量语义方向一致程度再补充一句工程实现上向量库常见的选择这一段就算答到位了。4.3 检索系统的工程实现细节向量检索落地的工程方案现在主要有几种。全量暴力计算的做法在小数据量场景也能跑几万条向量直接算相似度毫秒级能出结果。当数据量上到百万级就必须用ANN近似最近邻检索业界成熟度较高的开源库有Faiss完整的向量数据库也有多个常见选型各家的技术路线差异主要在于索引结构和压缩策略。选型时除了性能还要考虑自己团队的技术栈。如果知识库体量不大比如几万条文档块用轻量级方案完全够如果体量是百万级、千万级就要上分布式向量库了。面试时如果被问到你可以把数据量级、QPS、成本这几条线摆出来做决策分析比单纯报一个库名要更有说服力。检索并不是召回最好的那个块就结束了。实际系统里经常把向量召回和关键词召回结合起来这就是后文会展开讲的混合检索。5. 第五问RAG系统的效果怎么量化评估5.1 从RAGAS三指标说起RAG系统上线容易但怎么证明它效果好这是一个被很多团队忽视的问题。面试官如果问到评估一定要能答出评估维度而不是说“我用人看”。目前比较系统的评估框架是RAGAS提出的三指标方案忠实度、答案相关性、上下文相关性。忠实度衡量答案是否严格基于检索到的上下文生成也就是检查答案中的断言在上下文里有没有依据。这个指标直接对幻觉作出评估。答案相关性衡量答案是否完整回答了用户提出的问题。上下文相关性衡量检索到的文档块与用户问题之间的相关程度它反映的是检索环节的质量。三个指标一个对应生成、一个对应问答匹配、一个对应检索恰好覆盖了RAG链路的两大阶段。面试时如果能把这三个维度拆开讲清楚就已经超过大半候选人了。5.2 评估数据集怎么构建光有评估指标还不够你得有评估数据集才能落地。构建RAG评估集是典型的脏活累活但这也是区分做没做过的重要分水岭。我一般建议按这个流程做从业务场景里选取有代表性的真实用户问题大概50到100条就够一轮迭代用。然后为每个问题标注标准答案和参考依据文档这些标注数据就是你的黄金标准。最后还要专门设计几条容易触发幻觉的问题比如“知识库里没有相关文档的问题”“多个文档答案有冲突的问题”专门用来测边界情况。评估跑完后的分析同样关键。观察核心指标的分布忠实度偏低问题大概率出在生成侧检察Prompt约束和上下文注入方式上下文相关性偏低问题在检索侧去检查切分质量和重排策略答案相关性偏低可能是Query改写不到位问题问偏了也可能跨文档多跳推理能力不足。5.3 线上指标和离线指标如何配合离线评估做完了不代表万事大吉。RAG系统上线后观察线上表现同样重要。我常用的几个线上指标首答准确率人工抽检的比例、用户追问率、答案采纳率、平均响应时间。另外版权投诉或内容安全相关的指标虽然不是体验指标但必须纳入监控大盘。离线和线上指标是什么关系离线指标用来做系统改版之前的快速验证线上指标用来判断真实用户的实际体感。离线评估分数提升了20%不代表线上用户的体验就会提升20%——用户的问题分布和测试集差异往往很大。所以务必要建立日常抽样机制记录线上真实问题和预期答案定期回流到离线评估集里让测试集持续贴合真实场景。6. 第六问RAG优化手段有哪些抓手6.1 检索侧优化改写、扩展与多路召回评估做完面试官就该问优化了。RAG的优化手段特别多但一定要分层次回答不要东一榔头西一棒子。检索侧是最优先要动的部分因为检索质量决定效果上限。Query改写是非常有效的一招。用户原始提问往往随手就来口语化严重、指代不清、语义有歧义。可以拆解成几个手段同义词扩展、指代消解、意图补全。实现上最简单的方式是直接让大模型充当改写器先分析原始Query把核心实体和意图提取出来再生成一个适合用于搜索的规范化Query。我踩过的坑是改写器如果被触发得太频繁会把很简单的问题改复杂反而降低检索精度所以要做触发策略判断。HyDE也可以作为备选方案聊几句。它的思路是用大模型针对Query先生成一个假设性答案再用这个答案的向量去检索文档在语义空间里“答案与文档的距离”往往比“问题与文档的距离”更近。代价是多一次大模型推理延迟高一些但语义召回效果在某些场景下有明显提升。多路召回的作用也不可忽视。单独用向量检索同义词问题处理得比较好但专有名词、精确ID、缩写词的匹配就是经典的关键词检索更准。实践里常用的是向量检索和关键词检索并行跑最后合并候选集再用重排模型统一排序。6.2 排序侧优化重排模型与混合检索很多RAG系统在这里踩坑。向量检索阶段只是从几十万文档里初步筛选出Top50甚至Top100的候选集但TopK直接作为最终结果使用精度往往不够。向量召回的排序分数并不完全等于语义相关程度它只是近似检索。更靠谱的做法是先用粗排快速圈定候选范围再用更强大的重排模型做精排。重排模型和Embedding模型的区别在于重排模型把查询和文档拼接成一对输入通过交叉编码器逐对计算相关度精确度更高但计算成本也更高。因为要对每一个候选对都做一次模型推理所以重排的对象只能是粗排后的少量文档不可能在全库上跑。关于排序的位置我强调一点不要用内置的关键词检索替代重排。一些团队图省事粗排用关键词检索效果损失很大。标准的优化路径是“向量召回关键词召回的合并候选集”交给重排模型做交叉编码精排。混合检索加重排是目前业内性价比最高的检索优化组合。6.3 生成侧的优化Prompt约束与上下文压缩检索侧优化的上限在那里摆着如果召回的文档里确实没有答案生成侧再怎么优化也说不出花来。但很多时候是相关文档明明召回了答案却没用上这就需要生成侧的策略。Prompt设计里最重要的一条原则是让模型明确知道自己的知识边界。你需要在系统提示词中写明如果上下文中没有与问题相关的信息请直接说明知识库中未收录相关信息不要根据自身知识作答。这句话听起来简单实际上能把幻觉比例降低一半以上。原因在于很多模型的默认倾向是无论如何都要给一个像样的回答你必须明确给它托底选项。另一个实用技巧是上下文压缩。召回多个文档块之后里面可能夹杂着与问题无关的段落全部塞进Prompt会形成干扰。可以把召回的文档重新交给大模型先抽取与Query相关的句子再拼装成精简版上下文。这确实会增加一次模型调用但对答案质量的提升很明显。6.4 进阶方向从RAG到GraphRAG和Agent化前面聊的是经典RAG的优化面试官如果问得深可能会继续问你有没有了解更进阶的方向。这一部分不必答得面面俱到但要能说出思路。GraphRAG解决的是多跳推理的问题。经典RAG里每个文档块都是独立的语义碎片块与块之间的关联关系没有被建模。一条信息分散在多个文档里、需要逻辑串联时向量检索很难把它一次性召回。GraphRAG在文档之上用LLM抽取实体和关系构建知识图谱检索时先定位实体再沿着关系边扩展实现多跳信息整合。代价是索引构建成本和复杂度都要高不少适合有复杂关联查询的知识域不适合所有场景。Agent化RAG是另外一个方向。经典RAG只有“一次检索、一次生成”碰到需要多步推理的问题就力不从心。Agent化RAG将大模型作为调度核心拆解问题、规划每一步需要检索什么、完成一步再决定下一步动作循环直至把问题解决。典型应用包括复杂科研调研、跨系统资料对比等场景。这两个方向面试讲到“了解且能说出适用边界”即可核心是表达你对RAG不是停留在会用轮子层面的理解而是知道它当前的边界在哪里。7. 最后再聊几句面试表达与学习路径关于RAG面试的准备我个人最大的体会是节奏比广度重要。很多人准备面试时巴不得把所有知识点一次性塞进脑子里结果一条线都讲不透。面试官问一个点你就顺着那条线往下挖挖到工程细节、挖到参数选择、挖到你踩过的坑比铺开十张概念图更有说服力。最终呈现的高质量回答是一个清晰的漏斗先说结论再说依据最后说代价。比如问到为什么要用重排你就说“向量召回是近似检索精度不够——重排候选集可以提升相关性——但是多了模型推理代价只能对粗排后的少量结果用”。一个好的回答就像一个工程方案的浓缩提案。另一个实用建议是多拆解真实的RAG系统。你在学习时可以找一个开源的RAG项目或者自己搭一个Demo把文档切分、向量化、检索、重排、生成的每个环节逐步替换观察指标怎么变化。把这个过程记录下来复盘成自己的实战笔记比背一百篇面试题都管用。面试官最后往往会问“你遇到最难的问题是怎么解决的”这种由自己踩出来的经验就是最有说服力的答案。 
长河君 · 2026/10/22 19:18:44 · 阅读 1.2k RAG面试六问：从检索增强生成到优化实战
最近好几个朋友在准备大模型方向的面试都不约而同来问我RAG到底该怎么准备。这问题其实特别实在现在做应用层的大模型开发RAG几乎就是个绕不开的基础功十个面试里至少有八个会聊到检索增强生成。但大多数人准备得都比较零散知道个大概流程就说要去面了结果被面试官从切分问到重排从评估问到优化一路追下去就露馅了。这篇我直接按面试官的视角把RAG面试里最常出现的6类问题串成一条线从最基础的“为什么需要RAG”讲到“召回质量怎么优化”每个问题都拆开揉碎把背后的原理、工程实现里的关键参数、以及实际踩过的坑都说清楚。你在准备面试也好还是想把手上的RAG系统做扎实都建议顺着这个思路过一遍。1. 第一问为什么需要RAG它到底解决了什么问题1.1 大模型的天然短板面试问RAG十有八九会从一个问题切入既然大模型已经很强了为什么还要挂一个检索系统在外面这个问题看似基础但很多人的回答都浮在表面上。要回答好这个问题你先得清楚大模型的天然短板在哪。第一是知识新鲜度大模型的参数是在某个时间点冻结训练的之后发生的事情它一概不知问它最近发布的新产品、新政策它只能靠推理去猜。第二是事实准确率模型倾向于生成“听起来合理”的内容而不是“真实存在”的内容这也就是所谓的幻觉问题。第三是专业深度通用模型对垂直领域里的专业术语、内部规范、非公开资料几乎无能为力。RAG的思路就是给模型外挂一个动态的知识库。用户提问时先从知识库里检索出相关内容再把这些检索结果塞进Prompt里让模型基于这个上下文来生成答案。1.2 RAG与微调怎么选面试官通常还会追问一句这些问题用微调也能解决一部分为什么偏偏选RAG这个问题要答到点子上。微调的本质是把知识写入模型参数成本高、周期长而且每次知识更新都得重新训练一轮。更重要的是微调后的模型仍然可能产生幻觉因为知识在参数里是分布存储的模型无法精确区分“我学过的知识”和“我推断出来的内容”。RAG则把知识存储完全外部化答案由检索结果驱动模型只是把检索到的证据组织成语言。某个知识要更新直接改数据库里的文档就行不需要动模型。站在工程角度看还有一个关键优势可解释性。RAG的答案可以追溯到具体的参考文档这在企业级应用里是硬性要求。合规审计也好、用户投诉追溯也好你能指出来源问题就解决大半。微调在这方面就是黑盒你很难说明模型为什么给出这个答案。1.3 面试官真正想听什么我个人觉得这道题的考察重点不是背概念而是看你有没有做技术选型的判断力。你至少要表达出两个层次第一你清楚RAG适合解决“知识频繁更新对准确率要求高需要可追溯”的场景典型如企业内部知识库、智能客服、法规咨询。第二你了解RAG的局限比如对多跳推理的能力比较弱、对检索质量的依赖极重这些局限意味着什么、怎么去补面试官听到这里才会觉得你是真的做过而不是背了一篇综述。2. 第二问RAG的完整链路到底怎么跑起来的2.1 离线索引四步走RAG的完整流程一般分成离线索引和在线检索两个阶段面试时最好按照这个框架来说逻辑会很清晰。离线阶段做的是把知识库变成可检索的数据结构核心四步文档加载、文本切分、向量化、索引存储。文档加载就是把PDF、Word、Markdown这些原始格式解析成纯文本文本切分是解决模型输入长度限制的问题把长文档切成合适大小的块向量化是把每个文本块用Embedding模型转成向量索引存储则是把向量和文本块一起写入向量数据库同时建立元数据字段方便后续过滤。这里有一个面试官非常爱追问的细节为什么不能直接把整篇文档交给模型作答原因有两个层面。一是模型的上下文窗口有限长文档塞不进去二是检索效率问题从几千篇文档里精确找到相关联的内容靠的是向量近邻搜索而不是把全部文档都喂给模型去理解。2.2 在线检索与生成在线阶段就是用户提问到拿到答案的全过程。用户输入问题后系统先对Query做理解与改写如果句子太长或口语化太重需要提取关键词、补全意图然后对改写后的Query做向量化用同一个Embedding模型把Query也映射到向量空间接着去向量数据库做近邻搜索根据相似度召回TopK个候选文档块如果有更精细的要求还要加一步重排序把召回的候选块按与Query的相关程度重新排序最后把这TopK个块拼装进Prompt交给大模型生成最终答案。这个流程里有一个几乎人人都容易忽略的问题Query向量化和文档向量化必须使用同一个模型。之前遇到过一个团队索引阶段用了某个开源的文本向量模型后面为了省成本换了个轻量级模型做Query编码两个模型的向量空间分布完全不一致检索效果直接崩掉。这个问题在面试里讲出来会显得你很有实战经验。2.3 链路里最容易翻车的地方以我实际调系统的经验来看整个链路里最容易被低估的环节是文档解析的预处理。你以为PDF解析出来就能直接切分入库实际上扫描件需要OCR、表格需要特殊解析、页眉页脚混在里面会造成噪声、多栏排版会打乱阅读顺序。这一步的质量直接决定后续切分和检索的上限。面试聊到这里时你可以主动提出预处理的重要性这比单纯背诵流程有明显优势。另一个常见翻车点是没有做去重。同一个资料库里有历史版本和最新版本检索时旧版本被召回了答案引用了过期信息。这个问题在线下很难发现用户一问才发现所以工程上一定要在索引阶段做版本管理和内容去重。3. 第三问文档切分怎么做才能让召回质量站得住3.1 切分粒度为什么是召回效果的分水岭如果把RAG比作做饭检索就是买菜切分就是切菜。菜切得不合适后面厨艺再好也白搭。文本切分直接决定了检索系统能不能把“真正相关的信息”和“用户的问题”精确匹配上。切分块太细比如每块只几十个字符检索时召回的内容往往信息不完整一个概念被拦腰截断模型拿到的上下文是碎片化的。切分块太粗比如把整章节塞进一个块向量化后特征被平均化块里的大量无关内容稀释了要害信息召回时相关性得分上不去。核心矛盾在于检索的粒度需要“块与问题”语义对齐而生成的粒度需要“上下文充足”。这两个诉求天然有张力。3.2 主流切分策略横向对比我整理了目前工程上几种主流切分策略的特点面试时可以横向比较着说切分方式实现思路优势劣势固定大小切分按字符数或Token数均匀切分实现简单效果稳定容易切断语义完整的句子句级切分按句号、问号等边界切分语义完整性较好句子太短时信息量不足递归字符切分按段落→句子→词语逐级降维切分兼顾语义完整性与块大小参数需要根据文档类型调语义切分用Embedding判断句子间语义断点切分边界更符合语义计算量大实现复杂目前业界用得最多的是递归字符切分。它的做法是从最大的粒度开始比如先按段落分如果段落超长再按句子切句子还超长就继续往下。这种策略的好处是尽量保证切出来的块是人类可读的完整语段又不会因为固定长度限制而粗暴截断。对一些复杂格式的文档语义切分在AI知识库场景效果更好因为它解决了“语义相关但地理上分散”的问题。3.3 块大小与重叠参数的实践经验面试官经常会抛细节问题你切分时块大小设多少为什么这里不用背一个标准答案但要能说出调参逻辑。块大小的设定与模型和场景强相关。常见经验值通用知识库单块在256到512个Token之间既保证语义完整性又不会超过向量模型的最大输入长度。代码类文档单块可以适当放大因为代码的语义依赖上下文环境法规合同类文档建议用句级甚至条款级切分因为这些文档里一个条款就是一个完整语义单元。还有一个容易忽略的参数是重叠大小。相邻切分块之间保留一定的重叠文本一般设成块大小的10%到20%可以避免关键信息恰好落在两个块的边界上被切散。举个实际例子如果块大小是500个字符重叠设50到100个字符就能让处于边界附近的句子在相邻两块中都完整出现显著降低关键信息被截断的概率。面试时如果能说出一句“切分策略不能脱离你的业务文档类型单独设计、需要反复看召回case来调”面试官基本就会认可你是真做过索引工程的。4. 第四问向量检索的原理与模型选型4.1 Embedding模型选型的几个关键指标聊完切分面试官大概率会追问向量化用什么模型你怎么评估模型的好坏这个问题想答好需要你了解几个硬性指标。第一个指标是检索效果在公开的中文语义相似度评测集上用准确率、召回率衡量。目前的行业经验是开源中文向量模型之间差距还是存在但头部几个都已经很能打。第二个指标是最大输入长度也就是这个模型最长能处理的文本有多长。如果你的切分块比较大就要选支持长文本的模型否则超出上限的内容会被截断向量就无法完整表达语义。第三个指标是向量维度维度越高单个向量的表达能力越强但存储开销和检索耗时也随之增加。第四个指标是推理速度Embedding要处理的是全量知识库如果模型推理太慢几十万篇文档的索引就得跑好几天。除了模型本身Embedding服务化也是个工程细节。不要把Embedding计算直接封装在业务服务里不然每次知识库更新都会拖垮在线服务最好把Embedding单独部署成异步任务。4.2 相似度计算的数学直觉向量化之后如何判断两段文本长得像这就涉及相似度计算。最常用的指标是余弦相似度衡量的是两个向量在方向上的接近程度。余弦相似度等于两个向量点积除以模长的乘积范围在-1到1之间越大越相似。实际工程中向量数据库一般默认用内积或余弦相似度。用归一化向量时两者的排序效果等价所以很多向量库直接用点积实现因为计算效率更高。L2距离衡量的是向量在空间的绝对距离更关注“量级”差异在文本语义相似度场景里用得相对少一些但在对向量模长敏感的场景也有它的价值。面试时讲清楚核心的余弦相似度原理向量语义方向一致程度再补充一句工程实现上向量库常见的选择这一段就算答到位了。4.3 检索系统的工程实现细节向量检索落地的工程方案现在主要有几种。全量暴力计算的做法在小数据量场景也能跑几万条向量直接算相似度毫秒级能出结果。当数据量上到百万级就必须用ANN近似最近邻检索业界成熟度较高的开源库有Faiss完整的向量数据库也有多个常见选型各家的技术路线差异主要在于索引结构和压缩策略。选型时除了性能还要考虑自己团队的技术栈。如果知识库体量不大比如几万条文档块用轻量级方案完全够如果体量是百万级、千万级就要上分布式向量库了。面试时如果被问到你可以把数据量级、QPS、成本这几条线摆出来做决策分析比单纯报一个库名要更有说服力。检索并不是召回最好的那个块就结束了。实际系统里经常把向量召回和关键词召回结合起来这就是后文会展开讲的混合检索。5. 第五问RAG系统的效果怎么量化评估5.1 从RAGAS三指标说起RAG系统上线容易但怎么证明它效果好这是一个被很多团队忽视的问题。面试官如果问到评估一定要能答出评估维度而不是说“我用人看”。目前比较系统的评估框架是RAGAS提出的三指标方案忠实度、答案相关性、上下文相关性。忠实度衡量答案是否严格基于检索到的上下文生成也就是检查答案中的断言在上下文里有没有依据。这个指标直接对幻觉作出评估。答案相关性衡量答案是否完整回答了用户提出的问题。上下文相关性衡量检索到的文档块与用户问题之间的相关程度它反映的是检索环节的质量。三个指标一个对应生成、一个对应问答匹配、一个对应检索恰好覆盖了RAG链路的两大阶段。面试时如果能把这三个维度拆开讲清楚就已经超过大半候选人了。5.2 评估数据集怎么构建光有评估指标还不够你得有评估数据集才能落地。构建RAG评估集是典型的脏活累活但这也是区分做没做过的重要分水岭。我一般建议按这个流程做从业务场景里选取有代表性的真实用户问题大概50到100条就够一轮迭代用。然后为每个问题标注标准答案和参考依据文档这些标注数据就是你的黄金标准。最后还要专门设计几条容易触发幻觉的问题比如“知识库里没有相关文档的问题”“多个文档答案有冲突的问题”专门用来测边界情况。评估跑完后的分析同样关键。观察核心指标的分布忠实度偏低问题大概率出在生成侧检察Prompt约束和上下文注入方式上下文相关性偏低问题在检索侧去检查切分质量和重排策略答案相关性偏低可能是Query改写不到位问题问偏了也可能跨文档多跳推理能力不足。5.3 线上指标和离线指标如何配合离线评估做完了不代表万事大吉。RAG系统上线后观察线上表现同样重要。我常用的几个线上指标首答准确率人工抽检的比例、用户追问率、答案采纳率、平均响应时间。另外版权投诉或内容安全相关的指标虽然不是体验指标但必须纳入监控大盘。离线和线上指标是什么关系离线指标用来做系统改版之前的快速验证线上指标用来判断真实用户的实际体感。离线评估分数提升了20%不代表线上用户的体验就会提升20%——用户的问题分布和测试集差异往往很大。所以务必要建立日常抽样机制记录线上真实问题和预期答案定期回流到离线评估集里让测试集持续贴合真实场景。6. 第六问RAG优化手段有哪些抓手6.1 检索侧优化改写、扩展与多路召回评估做完面试官就该问优化了。RAG的优化手段特别多但一定要分层次回答不要东一榔头西一棒子。检索侧是最优先要动的部分因为检索质量决定效果上限。Query改写是非常有效的一招。用户原始提问往往随手就来口语化严重、指代不清、语义有歧义。可以拆解成几个手段同义词扩展、指代消解、意图补全。实现上最简单的方式是直接让大模型充当改写器先分析原始Query把核心实体和意图提取出来再生成一个适合用于搜索的规范化Query。我踩过的坑是改写器如果被触发得太频繁会把很简单的问题改复杂反而降低检索精度所以要做触发策略判断。HyDE也可以作为备选方案聊几句。它的思路是用大模型针对Query先生成一个假设性答案再用这个答案的向量去检索文档在语义空间里“答案与文档的距离”往往比“问题与文档的距离”更近。代价是多一次大模型推理延迟高一些但语义召回效果在某些场景下有明显提升。多路召回的作用也不可忽视。单独用向量检索同义词问题处理得比较好但专有名词、精确ID、缩写词的匹配就是经典的关键词检索更准。实践里常用的是向量检索和关键词检索并行跑最后合并候选集再用重排模型统一排序。6.2 排序侧优化重排模型与混合检索很多RAG系统在这里踩坑。向量检索阶段只是从几十万文档里初步筛选出Top50甚至Top100的候选集但TopK直接作为最终结果使用精度往往不够。向量召回的排序分数并不完全等于语义相关程度它只是近似检索。更靠谱的做法是先用粗排快速圈定候选范围再用更强大的重排模型做精排。重排模型和Embedding模型的区别在于重排模型把查询和文档拼接成一对输入通过交叉编码器逐对计算相关度精确度更高但计算成本也更高。因为要对每一个候选对都做一次模型推理所以重排的对象只能是粗排后的少量文档不可能在全库上跑。关于排序的位置我强调一点不要用内置的关键词检索替代重排。一些团队图省事粗排用关键词检索效果损失很大。标准的优化路径是“向量召回关键词召回的合并候选集”交给重排模型做交叉编码精排。混合检索加重排是目前业内性价比最高的检索优化组合。6.3 生成侧的优化Prompt约束与上下文压缩检索侧优化的上限在那里摆着如果召回的文档里确实没有答案生成侧再怎么优化也说不出花来。但很多时候是相关文档明明召回了答案却没用上这就需要生成侧的策略。Prompt设计里最重要的一条原则是让模型明确知道自己的知识边界。你需要在系统提示词中写明如果上下文中没有与问题相关的信息请直接说明知识库中未收录相关信息不要根据自身知识作答。这句话听起来简单实际上能把幻觉比例降低一半以上。原因在于很多模型的默认倾向是无论如何都要给一个像样的回答你必须明确给它托底选项。另一个实用技巧是上下文压缩。召回多个文档块之后里面可能夹杂着与问题无关的段落全部塞进Prompt会形成干扰。可以把召回的文档重新交给大模型先抽取与Query相关的句子再拼装成精简版上下文。这确实会增加一次模型调用但对答案质量的提升很明显。6.4 进阶方向从RAG到GraphRAG和Agent化前面聊的是经典RAG的优化面试官如果问得深可能会继续问你有没有了解更进阶的方向。这一部分不必答得面面俱到但要能说出思路。GraphRAG解决的是多跳推理的问题。经典RAG里每个文档块都是独立的语义碎片块与块之间的关联关系没有被建模。一条信息分散在多个文档里、需要逻辑串联时向量检索很难把它一次性召回。GraphRAG在文档之上用LLM抽取实体和关系构建知识图谱检索时先定位实体再沿着关系边扩展实现多跳信息整合。代价是索引构建成本和复杂度都要高不少适合有复杂关联查询的知识域不适合所有场景。Agent化RAG是另外一个方向。经典RAG只有“一次检索、一次生成”碰到需要多步推理的问题就力不从心。Agent化RAG将大模型作为调度核心拆解问题、规划每一步需要检索什么、完成一步再决定下一步动作循环直至把问题解决。典型应用包括复杂科研调研、跨系统资料对比等场景。这两个方向面试讲到“了解且能说出适用边界”即可核心是表达你对RAG不是停留在会用轮子层面的理解而是知道它当前的边界在哪里。7. 最后再聊几句面试表达与学习路径关于RAG面试的准备我个人最大的体会是节奏比广度重要。很多人准备面试时巴不得把所有知识点一次性塞进脑子里结果一条线都讲不透。面试官问一个点你就顺着那条线往下挖挖到工程细节、挖到参数选择、挖到你踩过的坑比铺开十张概念图更有说服力。最终呈现的高质量回答是一个清晰的漏斗先说结论再说依据最后说代价。比如问到为什么要用重排你就说“向量召回是近似检索精度不够——重排候选集可以提升相关性——但是多了模型推理代价只能对粗排后的少量结果用”。一个好的回答就像一个工程方案的浓缩提案。另一个实用建议是多拆解真实的RAG系统。你在学习时可以找一个开源的RAG项目或者自己搭一个Demo把文档切分、向量化、检索、重排、生成的每个环节逐步替换观察指标怎么变化。把这个过程记录下来复盘成自己的实战笔记比背一百篇面试题都管用。面试官最后往往会问“你遇到最难的问题是怎么解决的”这种由自己踩出来的经验就是最有说服力的答案。