企业官网建设流程全解析

1. RAG 面试为什么成了技术岗的“必考题”

RAG，检索增强生成，这两年从论文里的一个概念，变成了招聘市场上实打实的硬通货。你去看现在的大模型应用岗位，不管是做对话系统、知识库问答、智能客服，还是做企业级搜索，JD 里几乎都会写一条“熟悉 RAG 架构，有检索优化经验优先”。面试官也不傻，他们知道微调成本高、周期长，而 RAG 是能快速落地、能解释、能迭代的方案，所以面试里问得特别细。

我前阵子帮几个朋友做模拟面试，发现一个很普遍的问题：很多人能说出“RAG 就是先检索再生成”，但一问到“检索器怎么选”“召回率上不去怎么办”“幻觉怎么压”“多路召回怎么融合”，就开始含糊了。这恰恰是面试官区分“用过”和“懂”的分水岭。这篇文章我打算把 RAG 面试里最高频的六个问题拆开讲，从原理到优化，从选型到踩坑，尽量还原真实面试的追问逻辑。不管你是准备跳槽，还是刚接手一个知识库项目，这些内容都能直接拿去用。

先说一下这六个问题的来源。它们不是我从某一份面经里抄的，而是我过去两年参与面试、被面试、以及和同行交流时反复出现的核心考点。我把它归纳成一条线：原理理解 → 检索优化 → 生成控制 → 评估迭代。这条线走下来，基本能覆盖一个 RAG 岗位 80% 的技术追问。下面逐个展开。

2. 第一问：RAG 的基本流程和核心组件到底是什么

2.1 别只背“检索+生成”，要讲清楚数据流

面试官问“介绍一下 RAG”，很多人张口就是“检索增强生成，先检索相关文档，再让大模型生成答案”。这句话没错，但太薄了。面试官想听的是你对数据流的理解。一个完整的 RAG 系统，至少包含四个阶段：索引、检索、增强、生成。索引阶段要把原始文档切块、向量化、存进向量库；检索阶段要根据用户 query 去向量库里找 top-k 相似块；增强阶段要把检索结果和原始问题拼成 prompt；生成阶段才是大模型输出答案。

我一般会用一个类比来解释：RAG 就像开卷考试。索引是把教材拆成小卡片放进抽屉，检索是根据题目去抽屉里找相关卡片，增强是把卡片内容抄到答题纸上，生成是结合卡片和题目写出答案。这个类比面试官一听就懂，而且能自然引出后面的优化点——卡片切得好不好、抽屉找得准不准、抄的时候有没有抄错、写答案时有没有被卡片带偏。

2.2 核心组件拆解：每个环节都有坑

具体到组件，索引阶段的核心是文档切分策略和嵌入模型选择。切分不是随便按 500 字一刀切，要考虑语义完整性。我见过一个项目，把技术文档按固定长度切，结果一个函数的定义和它的参数说明被切到两个块里，检索时只召回一半，生成答案自然缺胳膊少腿。嵌入模型的选择也很关键，中文场景下，有些通用模型对专业术语的区分度不够，比如“召回率”和“准确率”在向量空间里离得很近，检索时容易混。

检索阶段的核心是相似度度量和top-k 策略。余弦相似度是最常用的，但也不是万能。如果向量没有归一化，点积和余弦的结果会不一样。top-k 的 k 值也不是拍脑袋定的，k 太小召回不足，k 太大噪声多，还会撑爆 prompt 长度。我通常建议从 k=5 开始调，结合评估指标再微调。

增强阶段最容易被忽视的是prompt 模板设计。检索结果怎么塞进 prompt，塞多少，要不要加指令让模型“只根据检索内容回答”，这些都会影响最终效果。生成阶段则要关注模型选型和温度参数。温度太高，答案发散；温度太低，答案死板。知识库问答场景我一般建议温度设在 0.1 到 0.3 之间。

注意：面试时如果只讲流程不讲组件，面试官会觉得你停留在概念层；如果只讲组件不讲数据流，又会显得零散。最好的方式是先画一条数据流，再在每个节点上点出关键组件和常见问题。

3. 第二问：检索效果差，召回率上不去怎么排查

3.1 先定位是“索引问题”还是“检索问题”

召回率上不去，很多人第一反应是换嵌入模型。但根据我的经验，七成以上的召回问题出在索引阶段，而不是检索阶段。所以排查顺序应该是：先看文档切分，再看嵌入质量，最后才看检索策略。怎么判断？你可以拿一批已知答案的问题，手动去看向量库里有没有包含答案的块。如果没有，那就是索引阶段就没把答案切进去，换什么检索器都没用。

文档切分常见的问题有三个：切得太碎、切得太粗、切断了语义。切得太碎，一个块只有一两句话，向量表达的信息量不足，检索时区分度低；切得太粗，一个块上千字，里面混了好几个主题，向量被平均了，反而匹配不准。切断语义是最隐蔽的，比如把“步骤如下”和具体步骤切开，检索到“步骤如下”这个块，模型根本不知道步骤是什么。

3.2 嵌入模型的选型和微调

如果索引没问题，那就要看嵌入模型。通用嵌入模型在垂直领域往往不够用，因为它的训练数据里专业术语的分布和你的业务数据不一样。这时候有两个方向：一是换一个在相关领域表现更好的模型，二是用业务数据做微调。微调嵌入模型需要构造正负样本对，正样本是问题和它对应的答案块，负样本是问题和无关块。这个工作量大，但效果通常比换模型更明显。

还有一个容易被忽略的点是查询改写。用户的原始 query 往往很短、很口语，直接拿去检索效果不好。可以先让大模型把 query 改写成更规范的检索语句，或者生成多个相关查询做多路召回。我实测下来，查询改写对召回率的提升有时候比换模型还大，而且成本低得多。

3.3 混合检索：向量不是唯一的路

纯向量检索有个天然缺陷：它对关键词精确匹配不敏感。比如用户问“XX 型号的额定功率是多少”，向量检索可能召回一堆讲功率的文档，但就是漏掉那个具体型号。这时候需要引入关键词检索，比如 BM25，和向量检索做混合。混合的方式有两种：一种是并行召回后融合排序，另一种是先关键词过滤再向量排序。融合排序常用的算法是 RRF，倒数排名融合，它不依赖分数归一化，实现简单，效果稳定。

实操心得：排查召回问题时，先别急着调参。拿 20 个 bad case，手动看每个 case 的检索结果，归类是切分问题、嵌入问题还是策略问题。这个动作花不了半小时，但能省掉你盲目试错的一整天。

4. 第三问：检索到了但答案不对，幻觉怎么压

4.1 幻觉的来源不止一个

很多人把幻觉归咎于大模型“胡说”，但在 RAG 场景里，幻觉的来源至少有三个：检索内容本身有噪声、prompt 没有约束、模型过度依赖自身知识。检索内容有噪声，比如召回了相关但不完全匹配的块，模型会强行把这些块拼成一个答案，结果就是似是而非。prompt 没有约束，模型可能忽略检索内容，直接用自己的参数知识回答。模型过度依赖自身知识，在检索内容不充分时，它会“脑补”缺失部分。

所以压幻觉不能只靠一句“请根据以下内容回答”。我通常会在 prompt 里加三层约束：第一层是角色约束，告诉模型它是一个严谨的知识库助手；第二层是内容约束，明确“只使用提供的资料，不要引入外部知识”；第三层是格式约束，要求模型在答案里标注引用来源，比如“根据资料 1”。标注引用这个动作很关键，它强迫模型去核对检索内容，而不是自由发挥。

4.2 检索质量决定生成质量的上限

有一句话我经常在团队里说：检索是上限，生成是下限。检索内容不对，prompt 写得再好也救不回来。所以压幻觉的第一步永远是提升检索精度。除了前面说的混合检索，还可以加重排序。向量检索召回 top-20，然后用一个交叉编码器对这 20 个块重新打分，取 top-5 送给模型。交叉编码器比向量相似度更准，因为它能同时看 query 和文档的交互信息，但计算量大，所以只适合做精排。

另一个技巧是设置相关性阈值。如果检索结果的相似度分数低于某个阈值，就判定为“没有找到相关资料”，让模型直接回答“根据现有资料无法回答”。这个动作看起来简单，但能挡掉大量幻觉。我见过一个项目，加了阈值过滤之后，幻觉率直接降了一半。

4.3 生成阶段的参数和策略

生成阶段能调的参数不多，但每个都关键。温度前面说了，知识问答建议 0.1 到 0.3。top-p可以设在 0.9 左右，保持一定的多样性但又不至于发散。最大生成长度要限制，防止模型长篇大论跑偏。还有一个策略是分步生成：先让模型判断检索内容是否足够回答问题，如果不够就直接说不够；如果够，再生成答案。这个两步走的方式比一步到位更稳。

注意：不要指望一个 prompt 解决所有幻觉。幻觉是系统性问题，需要检索、排序、prompt、参数四层一起发力。面试时如果你能说出“检索是上限，生成是下限”这句话，面试官会知道你是有实战经验的。

5. 第四问：多路召回和融合排序怎么设计

5.1 为什么要多路召回

单路召回有个根本矛盾：召回率和精度难以兼得。向量检索擅长语义匹配，但对关键词不敏感；BM25 擅长关键词匹配，但不懂语义。如果只用一路，要么漏召回，要么噪声多。多路召回的思路是让不同检索器各自召回一批结果，然后融合排序，取长补短。常见的组合是向量加 BM25，进阶一点可以加知识图谱检索或规则检索。

多路召回的关键不是“路越多越好”，而是每路要有差异化。如果两路检索器的结果高度重叠，那加了一路等于没加，还增加了计算成本。所以设计多路召回时，要先分析每路的召回特点，确保它们覆盖不同的 query 类型。比如向量检索覆盖语义类问题，BM25 覆盖专有名词类问题，规则检索覆盖结构化查询。

5.2 融合排序的三种主流方案

融合排序我用过三种方案，各有适用场景。第一种是加权分数融合，把每路的相似度分数归一化后加权求和。这个方案简单，但归一化方式对结果影响很大，不同检索器的分数分布不一样，归一化不好反而会拖累效果。第二种是RRF 倒数排名融合，不看分数只看排名，每路召回的第 n 名得 1/(k+n) 分，k 通常取 60。这个方案不依赖分数归一化，鲁棒性强，是我最常用的。第三种是交叉编码器精排，把多路召回的结果合并后，用交叉编码器统一打分。这个方案效果最好，但计算成本最高，适合对精度要求极高的场景。

5.3 去重和截断的细节

多路召回后一定要做去重。不同检索器可能召回同一个块，如果不去重，这个块在融合排序里会被重复计分，导致它被过度加权。去重可以用文档 ID 或内容哈希。去重之后是截断，根据 prompt 长度限制和模型上下文窗口，决定最终送几个块给模型。我一般会留 20% 的余量，防止 prompt 超长被截断。

实操心得：RRF 的 k 值不是固定的，可以根据你的召回数量调整。召回数量多的时候，k 可以设大一点，让排名靠后的结果也有机会；召回数量少的时候，k 设小一点，突出头部结果。我一般从 60 开始试，根据评估结果微调。

6. 第五问：RAG 的评估怎么做才靠谱

6.1 评估不能只看最终答案

很多人评估 RAG 只看最终答案对不对，这太粗了。RAG 是个多阶段系统，最终答案错，可能是检索没召回，也可能是召回但排序不对，还可能是生成跑偏。所以评估要分层：检索层看召回率和精度，生成层看答案相关性和忠实度，端到端看用户满意度。分层评估的好处是，你能定位问题出在哪个环节，而不是笼统地说“效果不好”。

检索层的评估需要构造问题-答案块的标注数据。这个数据不用多，一两百条就能看出趋势。召回率看的是答案块有没有被召回，精度看的是召回结果里有多少是相关的。生成层的评估可以用大模型做裁判，让一个强模型给答案打分，维度包括相关性、忠实度、完整性。忠实度特别重要，它衡量答案是否完全基于检索内容，有没有编造。

6.2 自动化评估和人工评估的配合

全自动评估省事，但不够准。全人工评估准，但成本高。我的做法是自动评估做日常监控，人工评估做关键节点。日常迭代时，用自动评估跑一批固定测试集，看指标有没有下降。版本发布前，抽一批 case 做人工评估，重点看边界情况和 bad case。自动评估的指标要固定，不能每次换，否则没法对比。

还有一个技巧是构造对抗测试集。专门找那些容易出错的 query，比如多跳问题、否定问题、时间敏感问题。这些 case 在常规测试集里占比低，但恰恰是区分系统好坏的关键。我一般会留 20% 的测试集给对抗样本。

6.3 评估指标的取舍

召回率和精度往往此消彼长，怎么取舍取决于业务场景。知识库问答场景，我倾向于精度优先，因为召回噪声会直接导致幻觉。搜索场景可以召回优先，因为用户自己会筛选。忠实度和相关性也有取舍，有时候答案很忠实但不够相关，有时候很相关但有点自由发挥。我的经验是，忠实度是底线，相关性是目标。忠实度不达标，相关性再高也不能用。

注意：评估不是一次性的，要持续做。每次改切分、换模型、调 prompt，都要跑一遍评估。没有评估的优化都是盲调，今天调好了明天可能又坏了。

7. 第六问：RAG 的优化方向和未来演进

7.1 从“能用”到“好用”的优化路径

RAG 系统上线只是开始，优化是长期的事。我一般把优化分成三个阶段：第一阶段解决召回问题，确保答案在库里能被找到；第二阶段解决排序问题，确保找到的答案排在前头；第三阶段解决生成问题，确保答案准确、简洁、有引用。每个阶段的优化手段不一样，不要跳步。召回没解决就去调 prompt，那是白费力气。

进阶优化方向有几个：自适应检索，让模型自己判断要不要检索、检索几次；迭代检索，根据第一轮检索结果生成更好的查询再做第二轮；图增强检索，把文档之间的关系也纳入检索范围。这些方向在学术上很热，但落地时要考虑成本和收益，不是越复杂越好。

7.2 成本、延迟和效果的三角平衡

RAG 系统有个绕不开的三角：成本、延迟、效果。多路召回效果好但成本高，交叉编码器精排效果好但延迟高，大模型生成效果好但 token 消耗大。优化不是把每个指标都拉满，而是找到业务能接受的平衡点。比如客服场景，延迟要求高，那就不能用太重的精排；内部知识库场景，延迟容忍度高，可以上更复杂的方案。

我通常的做法是先定延迟和成本预算，再在预算内最大化效果。比如延迟预算 2 秒，那就把检索和排序控制在 500 毫秒内，留 1.5 秒给生成。如果生成超时，就降级到更小的模型或更短的 prompt。这个降级策略一定要提前设计，不能等线上出问题再补。

7.3 面试里怎么回答“未来演进”

面试官问未来演进，不是要你背论文，而是看你有没有技术判断力。我的回答框架是：短期看工程优化，中期看架构演进，长期看范式变化。短期就是把切分、检索、排序、生成每个环节做扎实；中期是引入自适应检索和迭代检索，让系统更智能；长期是关注端到端的检索生成一体化模型，减少中间环节的信息损失。这个回答既有落地性，又有前瞻性，面试官一般会比较认可。

实操心得：优化 RAG 最忌讳“一把抓”。每次只改一个变量，跑评估，看指标变化，再决定下一步。我见过一个团队同时换了嵌入模型、改了切分策略、调了 prompt，结果效果变差了，根本不知道是哪个改动导致的。控制变量，是优化的基本功。

8. 面试之外的实战建议

聊完六个问题，再说几句面试之外的话。RAG 这个领域变化很快，今天的最佳实践明天可能就被新方案替代。但有些东西是不变的：对数据的理解、对评估的重视、对成本的敏感。我见过很多项目，技术选型很先进，但数据质量一塌糊涂，最后效果还不如一个简单的 BM25 加规则。所以别迷信新技术，先把基础打牢。

另外，面试时不要只回答“是什么”，要多说“为什么”和“怎么选”。比如问到你为什么用 RRF 而不是加权融合，你可以说因为 RRF 不依赖分数归一化，鲁棒性更强，而且实现简单。这种回答能体现你的思考深度。还有，遇到不会的问题不要硬编，可以说“这个方向我了解不多，但我会从某某角度去排查”，面试官更看重你的思路，而不是标准答案。

最后分享一个我自己的习惯：每次做完一个 RAG 项目，我都会整理一份 bad case 集，记录每个问题的现象、原因和解决方案。这份集子既是复盘材料，也是下次面试的素材库。面试官问“你遇到过什么难题”，你随手就能讲出一个有细节、有排查过程、有解决结果的案例，这比背任何面经都管用。