大模型幻觉问题有什么风险和解决方案

模型答得又快又像真的，可一旦把编出来的数字写进对账表、把不存在的条款说给客户，损失就是真金白银。这篇不重复讲幻觉是怎么产生的，而是站在落地负责人的位置：先判断这类错误落在你的业务里算几级风险，再给一套从输入约束、检索兜底、输出校验到人工卡点的手段清单和验收动作，最后说清什么场景光靠技术收敛不了。

先按后果给幻觉分级，别一上来就谈技术

聊幻觉别急着上技术手段。先问一句：这条错信息要是真错了，最坏能坏到哪？同一个模型写错一个形容词和写错一个报价数字，后果差着量级。先把后果分级，再决定投入多少防护，顺序反了容易在无关紧要的地方堆一堆校验，真正要命的地方反而裸奔。

区分这三类的关键不在内容本身，而在有没有下游动作。事实性错误通常停在文本里，人还能看一眼；引用性错误一旦进了合同或对外答复，就变成信任问题；执行性错误最麻烦，错信息被当成正确输入喂给接口或流程，错会顺着链路往下传。所以同样的错误率，三类要的防法完全不同。

1. 第一问：有没有下游自动动作这条输出后面接的是人还是系统。接系统（调接口、写数据库、发邮件、生成工单）就算执行性风险，必须加确认环节；纯人看的内容先按文本风险处理。
2. 第二问：多久能被发现估算从输出到被复核的时间差。当天有人对账的和一个月后才可能在审计里翻出来的，暴露窗口差很多，窗口越长越要在入口拦。
3. 第三问：发现后能不能撤回能改就改的（草稿、内部文案）和发出去就收不回的（对外邮件、已提交的报价、写进系统的数据），防的强度不在一个档。三个问题任何一个答不清，先别接自动动作，退回人工确认。

按业务能不能复核来定等级会更实在。写文案、做摘要这类，错了人工顺手改掉，代价可控；对账、报价、合同条款、医疗或法律提示这类，错了要赔钱甚至担责，就得在生成环节加校验和留痕。这不是说低风险场景可以不管，而是投入要和后果匹配。不适用的情形要说清：如果输出会进入对外正式文件，或者团队里没人有精力复核，那它就自动升到高风险档，不能按「反正是草稿」来算。

• 高风险：涉及金额、条款、时效、人身或合规建议，默认必须人工确认后才能外发
• 中风险：对外内容但不涉钱不涉责，抽检加关键字段校验即可
• 低风险：内部草稿、头脑风暴、格式整理，错了改掉就行
• 升级条件：出现下游自动动作、暴露窗口变长、撤回成本变高，任一条命中就往上提一档
• 降级不成立：不能因为「模型看起来挺准」就把高风险场景降成中风险

哪些业务场景最容易放大幻觉

幻觉不是均匀分布的，它在某些场景里只是「答案看着不顺眼」，在另一些场景里会直接变成事故。判断一个业务要不要重点防幻觉，看两件事：模型答错之后，人有没有能力当场发现；以及这个错误会不会被后续流程继续使用。两个答案都是「不能」和「会」，就属于高风险区。

• 长尾问答：模型不知道时，往往不是沉默，而是编一个像模像样的答案，外行很难分辨
• 多步调用：错误在第一步只是个小偏差，传到第三步可能变成完全错误的结论
• 时效信息：昨天还对的规则今天可能就改了，模型不会提醒你它记的是旧的
• 高风险组合：既要多步执行、又依赖实时数据、还要写进正式文档或发给客户

反过来说，不是所有场景都要上重防护。纯创意发散、起标题、头脑风暴这类任务，本来就不要求事实准确，卡得太死反而限制发挥。判断标准可以简化成一句：输出会不会被当成事实使用，或者会不会触发后续动作。不会，就轻防；会，就按上表逐项加校验。

1. 先分场景把业务里所有用到模型的环节列出来，逐个标注「事实型 / 创意型」和「单步 / 多步」，多步加事实型的排最前面处理
2. 再定兜底事实型问答要求给出来源或明确说不确定；多步任务在工具返回处加校验，失败即停
3. 最后验一遍故意问几个冷门细节和已变更的规则，看模型是老实说不知道，还是继续编；具体对照哪些页面、怎么记录，到站内指南中心的相关篇目里按步骤走

第一层：在输入端把可编造的空间压小

这一层解决的是「模型没材料可依、只好自己编」的问题。做法不复杂：把用户问题和手头的资料一起放进上下文，并且明确写死一句「只依据下面材料回答，材料里没有的说不知道」。关键在于配套：光说没用，得给拒答一个固定格式，前端才认得出。

1. 拼上下文把检索到的片段、用户原话、字段说明按固定顺序拼成一个 prompt 模板；片段带编号，回答时要求引用编号
2. 写死拒答话术约定一个固定字符串或固定字段值作为「答不了」的信号，比如返回 status=unknown；前端拿到它就走「转人工/提示补充资料」分支，而不是把猜测当答案展示
3. 换成结构化返回让模型按固定字段输出，数字、金额、日期单独成字段；字段没依据就留空或置 null，不要让它填一个看起来像的数字
4. 做一次反向抽检故意喂一段不含答案的材料，看模型是老实拒答还是硬编；这一步能直接暴露模板有没有写到位

这一步成本最低，改 prompt 模板加一层解析就行，所以适合作为所有场景的默认动作先铺上。但它收益有上限：模型只是被约束住不主动编，材料本身缺漏、片段之间打架的问题它解决不了。所以别指望靠这一层就把幻觉压到可接受，它更像第一道闸门，后面还得有输出校验和兜底流程接住。

• 材料为空或明显不相关时，直接走拒答分支，别把空上下文丢给模型自由发挥
• 拒答话术要唯一且可被程序匹配，不要用一堆近义句让前端去猜
• 结构化字段里数值类一律允许空值，并在展示层把「暂无数据」和「0」区分开
• 上线后抽一批真实问题回看拒答率，拒答率异常高说明材料侧没跟上，不是模型变笨了
• 把这一层当成基线条，别当成终点，后面还要接输出核对和人工兜底

想对照看不同模型在「给了材料仍硬编」上的表现差异，可以到 模型资料库（/models） 按任务类型筛一遍，再结合 官方 API 价格页（/pricing） 估算加长上下文的成本，具体数字以页面当时为准。成本和效果怎么权衡，站内的 指南中心（/guides） 里有口径可参考。

第二层：检索兜底，把答案钉在可追溯的资料上

检索兜底的思路很直白：别让模型凭空回忆，先把相关资料捞出来，再让它基于资料作答，并且把用到的原文片段和出处一起摆出来。这样业务方拿到答案时，不是只能选择信或不信，而是能顺着出处自己核一遍。凡是回答里没有标注来源的句子，默认当成模型自由发挥，需要人工确认。

1. 先定资料范围明确这类问题该查哪几个库、哪几类文档，写进规则里；范围外的提问直接说明「库里没有」，别让模型硬答。
2. 检索结果先过一遍把捞到的片段按相关度排序，只把最靠前的几条喂给模型，并限制回答必须引用这些片段；片段不相关就返回未命中。
3. 回答附带原文和出处输出里保留引用片段的原句和文档标识，业务方点开就能核对；核对不上的一律当模型补充内容处理。
4. 抽查未标注来源的句子定期抽一批回答，专看没有出处的部分错在哪，反推是检索没捞到还是模型自己加了话。

检索兜底

先查资料再生成，回答基于查到的片段而不是模型记忆。

可追溯

每个关键结论都能对应回具体文档和原文，能被人复查。

未命中

检索不到相关资料时明确说没有，不用模型知识硬补。

库脏

资料过期、互相矛盾或混入废稿，检索反而把错误答案喂得更像真的。

比搭链路更容易被忽略的是库的维护。检索库要指定明确的更新责任人，写清更新频率和触发条件，比如源文档改版、政策调整、产品下线时谁负责同步。库脏了比没库更危险：没库时业务方知道答案靠不住，脏库会让错误答案带着出处显得特别可信。责任人和频率这两项建议直接写进表格挂出来，别停在口头约定。

链路具体怎么搭、用哪种检索方案，这篇不展开，选型可以去看站内的相关文章。这里只强调一个判断：检索兜底适合有相对权威、可查证资料源的场景，比如制度问答、产品参数查询、合同条款核对。任务本身没有权威资料源时别硬上，比如开放式策划、创意写作、头脑风暴，这类问题本来就没有标准出处，强行检索只会拖慢响应，还会把创意拉回资料范围里。判断标准很简单：这个问题存在「查得到、能核对」的答案吗，答案是否，就别做检索兜底。

第三层：输出校验与自动拦截

模型自己检查自己，基本靠不住——同一个模型容易在同一处错得一样自信。所以输出校验要分两步走：先跑代码能判的硬规则，再让模型做软判断。顺序反了，等于让幻觉去审幻觉。

• 金额和数量：先用代码卡上下限和正负号，超出就拦，别让模型解释
• 日期与编号：格式用正则验，业务编号回库查存在性，查不到直接判失败
• 字段完整性：关键字段为空或只有占位符，视为未产出，不进下游
• 交叉验证：关键结论同一问题跑两次，或换个模型跑一次，不一致就转人工
• 阈值兜底：来源缺失、字段为空、二次比对不一致，命中条数累计到预设值就走兜底流程

1. 先写硬规则清单把业务里不能错的字段列出来，逐条写出判定条件和失败后的动作，形成一张表放代码里跑。
2. 再加交叉验证只对关键结论做二次调用，比较两次结果的关键字段是否一致；不一致就打标记，不自动采用任何一方。
3. 设拒绝阈值把各类风险信号定义成可累加的分值或条数，超过阈值就转人工或返回兜底话术，阈值先保守再逐步调。
4. 留痕入库每次拦截都记下原始输入、模型输出、触发规则和时间，攒成自己的错误样本集，后面调规则和提示词都翻这个库。具体指标口径可以到 /guides 里对照看。

能被代码判对错的，就别交给模型判；模型只负责代码判不了的那部分。

第四层：人工卡点放在哪、放多少

人工卡点不是越多越安全，而是越靠后果越有用。同一个模型输出，生成完随便扫一眼和提交前逐字核对，拦住问题的概率差很远。所以先问自己：这条内容一旦错了，最晚在哪个动作之后就无法挽回？卡点就设在那一步之前，其他位置能省则省。

• 卡点要贴着后果发生点：发送前、提交前、写库前，而不是生成完在聊天框里看一眼
• 抽检比例、复核清单、谁有权放行，三样都要落进流程文档，不靠个人责任心
• 清单只列「必须逐项确认」的几条，超过七八条执行时一定被跳过
• 留下复核痕迹（谁看的、什么时候放的），出问题才能回溯是卡点失效还是没人看
• 高风险场景宁可慢一点，也别把卡点放在生成环节——那里看不到最终措辞和上下文

1. 先分级把业务流程按「错了会怎样」分高、中、低三档，别按部门或模型能力分。分完确认每档都有对应卡点，缺档就补。
2. 再定位对每条流程找出后果发生的那一个动作（发送、提交、入账、写库），把卡点放在它紧前面，砍掉生成后那些没用的目测环节。
3. 写进文档抽检比例、复核清单、放行权限写进流程文档并指定负责人，让卡点变成制度而不是习惯。
4. 算代价统计每个卡点每天要吃掉多少人工分钟，对比它拦下的错误损失，算不清就别急着上全自动，先小范围跑一段再看。

上线前后怎么验收：一份可执行的检查清单

幻觉很难靠聊天感觉发现，要靠一套固定检查。核心不是证明模型完美，而是能回答两件事：哪些问题它必定该拒绝，线上有没有出现编造迹象。下面按上线前、上线中、上线后三段给动作，模型换代时整套重跑。

1. 先搭上线前测试集按三堆收集问题：边界问题（超范围、超权限、极端输入）、时效问题（答案随时间变化）、无答案问题（资料库里根本没有）。每条标明预期是答还是拒，逐条记录模型实际表现。
2. 逐条判「编还是拒」不要只看对不对，要看它有没有在不该答的地方硬答。把编造的回答和正常拒答分开记，编造的那批就是后续监控和回归的重点样本。
3. 上线中盯三项指标拒答率、人工改写率、二次比对不一致率分开记录。二次比对指对同一问题换个问法或换条资料再问一遍，比对两次结论是否一致；不一致率高说明输出不稳。
4. 定期抽查真实会话每周抽一批线上会话，优先抽语气特别肯定、带具体数字或结论的回答，回资料里找依据。找不到依据的归入幻觉样本，补进测试集。
5. 换代时整套重跑任何模型切换或配置大改，都把测试集和监控基线重跑一遍，用同一套标准比新旧表现，不要凭感觉放行。

• 该拒答却给了肯定答案：最高优先级，直接算幻觉
• 回答正确但资料无依据：也要记，属于运气好，不是稳定能力
• 拒答率突然升高：可能提示词、检索或数据源出了问题，不一定是模型变差
• 人工改写率升高：常是答案格式或口径漂移，先查输入资料再怪模型
• 三项指标同时波动：优先怀疑上游数据和检索链路，而不是单独换模型

这份清单的作用是把幻觉从主观感受变成可比较的记录。测试集条目和三项指标的当前阈值不必写死在文档里，随业务变化调整，具体对照数字到站内页面核对更新的口径。