前言
滴滴 Agent 岗二面，面试官抛出一道看似常规的题：「RAG 系统中大模型的幻觉问题你怎么处理？」候选人下意识答「检索做好就不会幻觉」，结果被追问到第三轮才意识到自己把两类完全不同的幻觉混为一谈。
很多开发者对 RAG 幻觉的认知停留在「检索到了就没事」这一层，实际上检索层幻觉和生成层幻觉是两套完全不同的机制，解法也分四道防线，从成本最低的 Prompt 约束一路递进到结构化溯源。这道题考察的不是你能背几个方案名，而是你能不能把幻觉的来源拆开、按场景选对组合。
先把面试现场的四轮交锋还原出来：
👔 面试官：RAG 系统中大模型的幻觉问题你怎么处理？
🙋♂️ 候选人：幻觉的话，我觉得只要检索到了相关内容，LLM 就不会编造了，所以关键是把检索做好就行了。
👔 面试官：检索做好了就不会幻觉了？检索到了内容但 LLM 没有严格照着说的情况你怎么处理？这叫「生成层幻觉」，你连这个都没考虑过？
🙋♂️ 候选人：那我在 prompt 里加一句「请根据资料回答」应该就可以了？
👔 面试官：加一句就够了？你知道 RAG 里的幻觉有两个完全不同的来源吗？检索层没找到和生成层超发挥，解法完全不一样。你就只会加一句 prompt？
四轮下来，候选人从「检索做好就行」一路退到「加一句 prompt」，基本被筛掉了。这道题的真实考察深度在于：你能不能把幻觉拆成检索层和生成层两类根源，再针对每一类给出从成本到机制的递进方案。
如果你读过这个系列前几篇------阿里那篇讲检索效果优化、字节那篇讲 Chunking 语义保真------这篇正好补上 RAG 的最后一环：检索拿到内容之后，怎么防止 LLM 在生成环节跑偏。读完这篇文章，你能搞明白：
- 幻觉的本质：LLM 为什么会一本正经胡说，RAG 塞了知识库为什么还挡不住
- 两类根源：检索层没找到 vs 生成层超发挥，各自的表现和危害
- 四道防线：Prompt 强约束、检索质量门控、生成后核查、结构化溯源，成本和严格度递进
- 组合策略：企业知识库、金融法律、医疗合规三类场景分别该上哪几道
- 工程取舍：拒答阈值怎么调、二次调用成本怎么算、JSON 溯源怎么落地
- 面试话术：60 分和 90 分回答差在哪，考官想听的「分层 + 升华」模板
不管你是正在准备大厂 RAG 岗面试的候选人，还是已经在做 RAG 生产系统想压住线上幻觉率的一线工程师，这篇都值得拆一遍。开整！
一、先把"幻觉"这个词说透
要讲清 RAG 里的幻觉，先得把"幻觉"这个词本身拆开。大模型的幻觉，说白了就是模型用一种极其自信的口吻，说出了一件根本不存在的事。它不是在故意骗你------LLM 的底层机制就是预测下一个 token，当它手里没有可靠依据时，会按概率拼凑出一个"读起来挺顺"的答案，但内容可能完全经不起推敲。
这里有个流传很广的误区：以为做了 RAG、把知识库内容塞进 prompt，幻觉问题就自动消失了。这个想法忽略了一个关键事实------塞进去不等于 LLM 会照着说。大模型在预训练阶段已经攒下了一整套"自以为对"的知识储备，当 prompt 里的资料和它记忆里的内容对不上，或者 prompt 里压根就没有相关 chunk，它完全可能绕过你给的资料、按自己的"老经验"发挥。
换句话说，RAG 解决的是"知识从哪来"的问题，但没解决"LLM 会不会老老实实用这份知识"的问题。前者是检索层的活，后者是生成层的活，两件事经常被混为一谈，这也是这道面试题的第一层陷阱。
举个最常见的翻车场景：知识库里明明白白写着退款政策是"7 天无理由退款"，但某次检索没把这条 chunk 召回，prompt 里是空的，LLM 就可能凭训练时见过的电商常识，给出"30 天退款"的答案。用户照着操作，退款失败，这就是幻觉造成真金白银损失的典型路径。后面会看到，这个例子恰好对应了"检索层幻觉"------四道防线里的方案二专门治它。
二、RAG 里有两类幻觉，根源完全不同
把幻觉拆成两类，是这道题的真正分水岭。很多人答不上来，不是因为没听过这四个方案，而是压根没意识到检索层和生成层是两套独立的故障模式。
1. 检索层幻觉：压根没找到，LLM 靠"猜"
这是最根本的故障。RAG 的前提是"先检索到相关内容，再让 LLM 生成"，但如果检索这一步就失败了------向量没召回相关 chunk，prompt 里要么是空的，要么塞了一堆不相关的内容------LLM 会怎么反应？它不会主动承认"我不知道"，而是会从自己预训练攒下的知识里挑一个"看起来像答案"的内容编出来。
这种幻觉的可怕之处在于：LLM 说得极其自信，语气和真答案一模一样，用户根本没有分辨能力。比如知识库写的是"7 天无理由退款"，检索没召回到这条，LLM 凭电商常识给出"30 天退款"，用户照着操作直接退款失败------这就是检索层幻觉在真实业务里造成的损失。
2. 生成层幻觉：找到了，但 LLM 没照着说
检索到了就安全了吗？恰恰相反，这种幻觉更隐蔽、也更常见。相关的 chunk 确实被召回了，也塞进 prompt 了，但 LLM 在生成答案时"超发挥"了------它把资料内容当基础，往上加自己的推断、补原文没有的细节，甚至把两段不相关的信息拼成一个"更完整"的答案。读者很难分辨哪句话来自文档、哪句是 LLM 现场加的。
3. 两类幻觉的对比
用一张表把差异钉死：
| 维度 | 检索层幻觉 | 生成层幻觉 |
|---|---|---|
| 故障位置 | 检索阶段没召回相关 chunk | 检召回成功，生成阶段 LLM 超发挥 |
| prompt 状态 | 空或全是不相关内容 | 有相关内容，但 LLM 没严格遵循 |
| LLM 行为 | 凭预训练知识编答案 | 在资料基础上加推断、补细节、混拼 |
| 用户感知 | 答案自信但完全错 | 答案"看起来对"但夹带私货 |
| 主治方案 | 方案二（检索质量门控） | 方案一（Prompt 强约束）+ 方案四（结构化溯源） |
| 危害等级 | 直接给错答案，造成业务损失 | 部分对部分错，长期侵蚀信任 |
这两类幻觉的根源不同，解法也完全不一样。下面四个方案，就是从「成本最低」到「机制最严格」依次递进的思路------方案一二各管一类，方案三四是兜底加固。
三、方案一：Prompt 强约束------成本最低的第一道闸
这是四道防线里成本最低、上手最快的一道，效果也立竿见影。很多团队搭 RAG 时的默认做法是把 chunk 塞进 prompt，然后问一句"请回答这个问题"------这种问法等于没约束，LLM 会默认"这些资料只是参考，我可以结合自己的知识一起回答"，生成层幻觉就是这么冒出来的。
修复思路很直接：在 system prompt 里把规矩立死，明确告诉 LLM 只能当传话人、不能当百科全书。一套可落地的约束规则长这样：
text
你是一个严格基于参考资料回答问题的助手。遵守以下规则：
1. 只能使用【参考资料】中的信息回答，不得引入资料之外的任何知识
2. 若参考资料中信息不足以回答，必须明确回复："根据现有资料，无法回答该问题"
3. 回答时标注每条信息来自哪条参考资料（编号）
4. 不得推断、不得猜测、不得补充资料中没有明确说明的内容这四条规则，每一条都有它的工程意义：
- 第一条划清边界------告诉 LLM 你只是传话人，不是百科全书，资料之外的内容一概不许碰。这是压制生成层幻觉最核心的一条。
- 第二条给逃生出口------当资料里确实没答案时，"我不知道"比"编一个看起来合理的答案"安全得多。这条规则让 LLM 优雅地认怂，而不是硬撑。
- 第三条强制自检------让 LLM 在生成时主动对照原文，每句话都要说清楚来自哪条资料，相当于在生成过程中嵌入了一道校验。
- 第四条封死推断------LLM 最爱在"资料说了 A"的基础上推断"所以 B 也成立"，这条直接把这种习惯掐掉。
这套约束对"生成层幻觉"压制效果显著，但对"检索层幻觉"帮助有限------如果 prompt 里压根就没有相关 chunk，再强的约束也拦不住 LLM 瞎编。所以方案一必须配合方案二使用，两道闸一起才能把两类幻觉都罩住。这也是为什么生产系统上线前，方案一加方案二是必须做的基础配置。
四、方案二：检索质量门控------检索失败就拒答
方案一解决了"LLM 超发挥"，但如果检索这一步就失败了，prompt 里全是无关内容，光靠 Prompt 约束根本拦不住------LLM 手里没有可靠依据，再强的"不准编"规则也压不住它编。这时候的正确做法是：与其让 LLM 在低质量上下文里硬撑出一个"可能是错的答案"，不如直接告诉用户"知识库里没这个信息"。前者让用户误以为答案是对的，后者虽然看起来不那么智能，但至少不会给用户错误信息。
1. 用 Rerank 分数当质量闸门
判断检索质量够不够，最直接的办法是上 Rerank 模型打分。整个流程很干脆：
- 检索阶段召回 top-K 个候选 chunk
- Rerank 模型对每个候选打一个 0 到 1 之间的相关度分数
- 看最高分------低于阈值就直接返回"知识库无相关信息，建议联系人工"，不让 LLM 强行回答
- 最高分达标，就把所有达标的 chunk 筛出来喂给 LLM
这道闸门的核心思想是：把"要不要让 LLM 回答"这个决策权从 LLM 手里夺回来，交给一个可量化的分数。LLM 没有"我这个上下文靠不靠谱"的自知之明，但 Rerank 分数有。
2. 阈值怎么调
这个阈值到底设多少？没有通用数字，得按你自己的业务数据调。调法是拿一批测试集跑一遍------一半是"已知答案在知识库里"的正样本，一半是"已知答案不在知识库里"的负样本------看 Rerank 分数在这两类上的分布，找那个能把两类分开的切点。
经验值一般在 0.3 到 0.6 之间：
| 业务场景 | 阈值倾向 | 原因 |
|---|---|---|
| 金融、医疗、合规 | 偏高（0.5-0.6） | 精度要求高，宁可多拒答也不能答错 |
| 企业知识库、客服问答 | 中间值（0.4 左右） | 平衡精度和召回 |
| 闲聊型问答 | 偏低（0.3-0.4） | 召回率宽松，答得宽泛也比拒答强 |
实操建议从中间值起步，根据线上误判样例往上或往下微调。如果线上出现"该答的没答"（阈值偏高），往下调；如果出现"不该答的瞎答了"（阈值偏低），往上调。这是一个需要持续监控的动态参数，不是设一次就完事。
3. 拒答不是缺陷，是设计
你可能会觉得"拒答"让系统显得很笨。但换个角度想：用户问了一个知识库覆盖不到的问题，最好的答案就是"我不知道，请联系人工"，而不是 LLM 编一个听起来合理但实际错误的回答。答错比不答更危险------答错会让用户照着错误信息操作造成损失，拒答最多让用户多问一次。
方案一加方案二组合起来，就能同时压制两类幻觉：方案二负责"检索质量差时不让 LLM 胡说"，方案一负责"检索质量还行但 LLM 容易超发挥时把它框住"。这两个是 RAG 系统上线前的基础配置，成本也最低，绝大多数企业知识库场景上这两道就够了。
五、方案三：生成后引用核查------给答案请个审稿人
前两个方案都是在"生成之前"做防控------方案一约束 LLM 怎么生成，方案二决定要不要让 LLM 生成。但防控再多，总有漏网的时候。方案三换了个位置：在"生成之后"做校验。
1. 思路：发起第二次 LLM 调用当审稿人
LLM 生成完答案后，再发起一次 LLM 调用，把原始答案和 chunk 一起送给它，让它充当编辑角色，逐条核查答案里的每个声明有没有来源支撑。没有依据的内容，要么标注"无法核实"，要么直接删掉。
这个思路和人类写作的流程很像：方案一是事前给作者立规矩（"你只能照着资料写"），方案三是事后请编辑审稿（"你写完了，我来对一遍来源"）。两者互补------事前约束再强，LLM 仍可能在生成时"无意识"地补推断；事后审稿能把这种漏网之鱼捞回来。
2. 代价：延迟翻倍、成本翻倍
方案三的硬代价是多一次 LLM 调用。这意味着：
- 响应延迟接近翻倍------用户得等两次 LLM 推理，体感上明显变慢
- Token 成本翻倍------第二次调用要把 chunk 和原始答案都塞进去，输入 token 比第一次还多
- 系统复杂度上升------要管理两次调用的编排、失败重试、结果合并
所以方案三不是默认配置，而是按场景选装。普通的企业知识库问答，方案一加方案二的组合通常已经够用；只有对准确性要求极高、容错率极低的场景------比如医疗问诊、法律咨询、合规审核------才值得为多一层校验付出延迟和成本的代价。在这些场景里，答错一句话可能意味着医疗事故或法律纠纷，多花一倍成本换准确性是划算的。
3. 事前防控 vs 事后校验的定位差异
| 维度 | 方案一+二（事前） | 方案三（事后） |
|---|---|---|
| 作用阶段 | 生成前 | 生成后 |
| 成本 | 极低（改 prompt + 加阈值） | 高（多一次 LLM 调用） |
| 延迟影响 | 几乎无 | 接近翻倍 |
| 适用场景 | 所有 RAG 系统 | 准确性要求极高的场景 |
| 防控逻辑 | 阻止 LLM 编 | 编完了再删 |
记住一个原则：事前防控是性价比最高的，事后校验是兜底加固。不要一上来就上方案三，先把方案一二做到位，再根据线上幻觉残留率决定要不要加方案三。
六、方案四：结构化输出强制溯源------让 LLM 自己写参考文献
方案三是在内容层面做校验，方案四则换了个维度------在格式层面做约束，和方案一的 Prompt 约束配合使用效果更好。核心思路是：不让 LLM 自由吐自然语言，而是强制它输出结构化 JSON，每个结论都必须填上来自哪条参考资料的编号。
1. 输出格式长什么样
一个典型的结构化输出协议大致是这样：
json
{
"answer": "完整回答文本",
"statements": [
{
"claim": "结论一的具体表述",
"source_ids": [1, 2]
},
{
"claim": "结论二的具体表述",
"source_ids": [3]
}
],
"confidence": "high"
}answer 是给用户看的完整回答，statements 是把回答拆成一条条可核查的声明，每条声明必须挂上 source_ids 指向它来自哪条 chunk，confidence 是 LLM 自评的置信度。这个协议的关键不在于字段长什么样，而在于强制 LLM 在生成时为每条结论找来源。
2. 为什么格式约束能压幻觉
这个方案有效，靠的是两个机制叠加：
第一，生成时的"找来源"动作本身就在降幻觉。 LLM 在构建 JSON 时，必须主动想"这条结论我从哪条资料里找到的"------这个过程逼着它回头核对原文，而不是信口开河。就好比让学生写论文必须标注参考文献，他下笔时自然就不敢随便编了，因为编了也得编个来源编号出来，难度比自由发挥高得多。
第二，系统拿到 JSON 后可以做程序化验证。 source_ids 里的编号如果对应的 chunk 和 claim 明显不相关，就可以自动过滤掉这条结论。这等于在 LLM 之外又加了一道机器校验------LLM 可能会瞎编来源编号，但程序一比对就能发现"你说的来源 3 根本没讲这件事"，直接把这条声明删掉或标红。
3. 和方案一的配合关系
方案四不是独立使用的，它必须和方案一的 Prompt 约束配合。方案一在 system prompt 里立规矩"必须标注来源"，方案四把这个规矩落到具体的 JSON schema 上------前者是意愿，后者是执行。单独用方案四，LLM 可能填个假来源糊弄；单独用方案一，LLM 可能在自然语言里随便提一句"来自资料 3"但根本没对上。两者一起用，才能既逼 LLM 找来源，又让系统能验证来源真不真。
七、四道防线怎么组合：按场景递进
四个方案不是非此即彼，而是按场景从严要求程度递进组合。从易到难，大致分三档：
1. 基础档：方案一 + 方案二
适用场景：普通企业知识库、客服问答、内部 FAQ。
这是所有 RAG 系统上线前必须做的基础配置。方案一改改 prompt，方案二加个 Rerank 阈值，两个都不需要额外 LLM 调用，成本极低，但能把幻觉问题解决大半。绝大多数非关键业务的 RAG 系统，上这两道就够了。
2. 进阶档：方案一 + 方案二 + 方案四
适用场景：金融分析、法律文档查询、合规咨询等对可信度要求高的场景。
在基础档上加方案四的结构化输出，让每条答案都带上来源编号。用户看到答案的同时就能看到来源，可以自己去原文核实。这一档的边际成本主要是 JSON 解析和来源验证的逻辑开发，没有额外的 LLM 调用，延迟几乎不变，但可信度提升明显。
3. 顶配档：四道全上
适用场景：医疗问诊、合规审核、法律意见生成等容错率极低的场景。
四个方案全上，在延迟和成本上付出最大代价，换取最高级别的准确性保证。方案三的二次调用让延迟翻倍，但在这些场景里，答错一句话的代价远超多花一倍推理成本。
4. 组合策略速查表
| 场档 | 方案组合 | 延迟影响 | 成本 | 适用业务 |
|---|---|---|---|---|
| 基础 | 一+二 | 几乎无 | 极低 | 企业知识库、客服 FAQ |
| 进阶 | 一+二+四 | 几乎无 | 低 | 金融、法律、合规咨询 |
| 顶配 | 一+二+三+四 | 接近翻倍 | 翻倍 | 医疗、合规审核、法律意见 |
5. 一句话核心认知
说到底，规避幻觉没有一劳永逸的银弹。最重要的认知是：检索质量是幻觉的最大来源。检索到了正确的内容，Prompt 再稍微约束一下，幻觉就已经少很多了；如果检索这一步就烂，再多的生成层约束也填不了这个坑。
所以治幻觉的优先级是：先治检索，再治生成。方案二（检索质量门控）的优先级其实高于方案一（Prompt 约束）------很多人一上来就死磕 prompt 怎么写，却忽略了检索质量这个根本问题。把检索做扎实，四道防线的压力会小很多。
八、从架构师视角看 RAG 幻觉防控的几个工程取舍
前七章讲的是"有什么方案"，这一章讲"落地时怎么选"。四道防线在工程实践中不是简单堆叠，每道都有几个真实的取舍点，选错了要么压不住幻觉、要么成本失控。
1. 拒答阈值：静态全局 vs 动态分桶
方案二的 Rerank 阈值，最简单的做法是全局设一个静态值（比如 0.4）。但实际业务里，不同问题类型对精度的要求差很多------查退款政策必须精准，查公司动态可以宽松。静态阈值要么在高精度场景下漏放幻觉，要么在宽松场景下过度拒答。
取舍建议：MVP 阶段用静态阈值快速上线，跑通后按业务线分桶------给每类问题配独立阈值，甚至按用户分级（VIP 用户走更严格的阈值，减少答错风险）。这需要一套阈值管理配置，但能把拒答率和幻觉率同时压到更优区间。
2. 方案三的审稿模型：同模型自审 vs 异模型交叉审
方案三让 LLM 审自己的输出，最省事的做法是用同一个模型当审稿人。但同模型的盲点是一致的------它在生成时犯的错，自审时大概率也看不出来，等于自己批自己的作业。
取舍建议：关键场景（医疗、法律）用异模型交叉审------生成用 A 模型，审稿用 B 模型，两个模型盲点不同，交叉能捞回更多漏网之鱼。普通场景用同模型省成本，因为异模型要多付一份不同供应商的调用费，还要处理两家 API 的兼容性。这个取舍本质是"多花钱换准确性"还是"省成本接受残留幻觉"。
3. 结构化输出的 schema 复杂度 vs LLM 遵循率
方案四的 JSON schema 越复杂（字段越多、嵌套越深），LLM 的遵循率越低。强行要求复杂 schema，反而会催生大量格式错误------LLM 要么漏字段、要么字段类型错，最后你还得写一堆容错逻辑去兜底，工程复杂度急剧上升。
取舍建议 ：MVP 阶段只要求两个字段------answer 和 source_ids，把 LLM 的认知负担降到最低。跑通后再按业务需要逐步加字段（比如 confidence、evidence_quote）。每加一个字段都要评估它对遵循率的影响，不要一次性堆复杂 schema。
4. 拒答率 vs 用户体验的平衡
方案二的拒答是设计而非缺陷，但拒答率过高会让用户觉得系统"什么都不会"。如果用户连着问三个问题都被拒答，大概率直接弃用。
取舍建议：把拒答率纳入监控指标，正常区间在 5%-15%。超过 20% 就该回头查检索质量------可能是 Embedding 模型选错了、Chunking 切太碎、或者知识库覆盖面不够。同时给拒答配兜底动作：转人工客服、推荐相关问题、或者明确提示"这个问题需要人工处理"，让拒答不显得生硬。
5. 缓存策略对幻觉的隐性影响
为了省成本和降延迟，很多 RAG 系统会缓存 LLM 的输出。但知识库是会更新的------今天改了退款政策，明天用户问的时候如果命中了昨天的缓存，拿到的就是过期答案，这本质也是一种"幻觉"（答案和当前知识库不一致）。
取舍建议：缓存 key 必须包含相关 chunk 的版本号或哈希，知识库更新时主动失效相关缓存。不要用纯 query 哈希做 key------同一个问题在不同知识库版本下答案可能不同。这个取舍是"缓存命中率 vs 数据新鲜度"，关键业务宁可牺牲命中率也要保新鲜。
6. 多路召回下的幻觉叠加
很多团队为了提高召回率，会上向量检索 + 关键词检索 + 语义改写的多路召回。但多路召回的 chunk 质量参差不齐，如果直接拼在一起喂给 LLM，低质量 chunk 会稀释上下文质量，反而增加幻觉概率------LLM 在一堆半相关的 chunk 里更容易"超发挥"。
取舍建议：多路召回必须配统一的 Rerank 闸门，所有路的 chunk 汇总后过一遍 Rerank 打分，按分数排序筛 top-K，不要直接拼。这个取舍是"召回率 vs 上下文质量"，多路召回的价值在于把候选池做大，但最终喂给 LLM 的必须是经过质量过滤的精挑细选的 chunk。
九、面试话术：考官想听的是什么
这道题在面试里反复出现，但能答到 90 分的人不到两成。差在哪？不是背不全四个方案，而是没把"两类根源"这个分水岭讲清楚。
1. 两个常见错误回答
错误一：把幻觉当单一问题治。
"我在 prompt 里加一句'请根据资料回答'，让 LLM 只能照着资料说。"
这个回答只想到生成层，完全没意识到检索层幻觉的存在。面试官一句"检索没召回到相关内容怎么办"就能把你问住------prompt 里压根没资料，再强的约束也压不住 LLM 编。
错误二：甩锅模型能力。
"主要是模型能力不够，换个更强的模型就好了。"
这个回答把工程问题甩给模型能力，没认识到幻觉是系统设计问题。更强的模型确实能降低幻觉率，但不能消除------只要检索会失败、生成会超发挥，幻觉就存在，区别只是概率高低。面试官想听的是你怎么在系统层面防控，不是让你换个模型就完事。
2. 高分答题模板：三层结构 + 一句升华
第一层（基本原理）：先把幻觉拆成两类根源。
"RAG 里的幻觉有两类完全不同的来源。第一类是检索层没召回到相关内容，LLM 凭预训练知识编答案；第二类是检索到了但 LLM 没严格照着说，在资料基础上超发挥加推断。这两类的根源不同，解法也完全不一样。"
第二层（细节为什么）：针对每类根源给解法。
"针对检索层幻觉，我用 Rerank 模型打分做质量门控，最高分低于阈值就直接拒答，不让 LLM 在低质量上下文上硬撑。针对生成层幻觉，我在 system prompt 里立四条规矩------只用资料内容、资料没有就说不知道、标注来源、不推断------再用结构化 JSON 输出强制每条结论挂来源编号，系统可以程序化验证来源真不真。"
第三层（设计哲学）：讲组合策略和优先级。
"这四道防线按场景递进组合：企业知识库上方案一加方案二就够了，金融法律加方案四，医疗合规四道全上。但核心认知是------检索质量是幻觉的最大来源，治幻觉先治检索，检索做扎实了生成层的压力会小很多。"
升华一句：
"幻觉防控不是堆方案，是按场景做组合加持续监控的工程问题。"
3. 60 分 vs 90 分对比表
| 追问点 | 60 分回答 | 90 分回答 |
|---|---|---|
| 幻觉来源 | "模型能力问题" | "检索层和生成层两类根源" |
| 检索层怎么治 | "换更好的 Embedding" | "Rerank 门控 + 阈值拒答" |
| 生成层怎么治 | "prompt 加一句约束" | "Prompt 四条规矩 + 结构化溯源" |
| 方案怎么组合 | "全都上最稳" | "按场景三档递进，成本和严格度匹配" |
| 核心认知 | （没提） | "治幻觉先治检索" |
4. 加分项
如果时间允许，再提一两个工程细节能明显加分：
- 拒答率的监控：提到"拒答率超过 20% 就该回头查检索质量"，说明你不只会设阈值，还知道阈值背后的健康度指标。
- 异模型交叉审：提到"方案三的关键场景用异模型交叉审，避免同模型盲点一致"，说明你对模型局限有深入理解。
- 缓存版本失效：提到"知识库更新要失效相关缓存，否则缓存命中的是过期答案也算幻觉"，说明你想到了别人容易忽略的隐性幻觉来源。
这几个细节原文没讲，是你作为架构师的增量判断------考官听到会知道你是真做过 RAG 生产系统的人，不是背书的。
总结
把这篇拆完，RAG 幻觉防控的完整图景就清晰了：
- 幻觉的本质是 LLM 预测下一个 token 时无可靠依据就拼凑------RAG 塞了知识库不等于 LLM 会照着说，预训练攒下的"老经验"随时可能盖过你给的资料。
- 两类根源必须分开理解------检索层没找到（LLM 凭预训练知识编）和生成层超发挥（在资料基础上加推断），表现、危害、解法都不同，混为一谈是最大的认知误区。
- 四道防线按成本和严格度递进------Prompt 强约束（成本最低）→ 检索质量门控（Rerank 阈值拒答）→ 生成后引用核查（二次 LLM 调用）→ 结构化输出溯源（JSON + source_ids）。
- 组合策略分三档------基础档（方案一+二）覆盖企业知识库，进阶档（一+二+四）用于金融法律，顶配档（四道全上）用于医疗合规，成本和严格度匹配场景。
- 核心认知：治幻觉先治检索------检索质量是幻觉的最大来源，检索做扎实了生成层压力小很多，方案二的优先级其实高于方案一。
- 六个工程取舍决定落地质量------拒答阈值动态分桶、异模型交叉审、schema 简化起步、拒答率监控（超 20% 查检索）、缓存版本失效、多路召回必配 Rerank 闸门。
- 面试答题分水岭在"两类根源"------三层结构答题（基本原理→细节为什么→设计哲学），加分项是拒答率监控、异模型交叉审、缓存版本失效这些工程细节。
回到面试现场，"检索做好就不会幻觉"这个想法是错的，"加一句 prompt"也远远不够。你需要的是一整套按场景组合的防控策略，外加对检索质量这个根本问题的持续治理。记住那句话：治幻觉，先治检索。
你的 RAG 系统线上幻觉率大概在什么量级？用了哪几道防线？有没有踩过检索质量门控阈值调不准的坑？欢迎评论区交流。