大模型幻觉问题常见问题，一次说清做法

用模型答业务问题，最怕它一本正经地编：编文献、编接口、编价格。这篇不重复讲幻觉的定义，而是按「怎么发现、怎么分场景处理、上线前怎么设卡」把常见问题一次说清，给出能照着做的排查顺序和对策清单，也会说明哪些做法在什么情况下不管用。

用模型答业务问题，最怕它一本正经地编：编文献、编接口、编价格。而且它编得越具体，你越容易信。这篇不重复讲幻觉是什么，而是按「怎么发现、怎么分场景处理、上线前怎么设卡」把常见问题一次说清，给你能照着做的排查顺序和对策清单，也会说明哪些做法在什么情况下不管用。

先说一个前提：幻觉不是单一毛病，混着信息过期、任务超纲、提示词没说清一起出现。如果你拿同一套标准去套所有情况，很容易把「模型不知道」误判成「模型在骗人」，然后改错方向。下面四节按发现、分场景、工程卡点、量化评估的顺序走，你可以跳着看自己卡在哪一步。

先分清是幻觉还是信息过期、任务超纲

第一步不是急着修，而是给「说错」分类。编造不存在的内容、知识截止之后的旧答案、任务本身超出模型能力，这三类的处理方式完全不同：第一类要靠外挂校验和资料约束，第二类要靠更新知识来源或明确告知时效，第三类换模型或拆任务都没用，得换方案。

• 看来源：要它给出处，却给不出能打开、能对上的链接或文档段落，多半是编的
• 看稳定性：同一个问题换个问法、换个顺序再问，答案关键部分就变了，说明它没真掌握
• 看细节走向：越追问细节越具体，但前后对不上，典型的「顺着你编」
• 做对照实验：同题多采样看结果是否收敛；给一段真实材料让它只从中作答；拿它明显不熟的领域题做压力测试

按场景定容忍度，不同任务处理力度不一样

判断标准一句话：错了要赔钱、要担责、要对外发布的，就不能只靠模型自证。按这个标准把任务分三档，处理力度跟着走，比全局调一遍提示词有效得多。

分档之后你会发现，大部分精力应该花在高风险场景的复核流程上，而不是追求模型在所有场景都不出错。这个目标不现实，也不划算。

工程侧的四道卡：约束输入、限制输出、外挂校验、兜底话术

这四道卡按成本从低到高排，建议按顺序上。很多人一上来就做复杂的校验系统，其实把资料喂进去、把输出格式定死，就能挡掉相当一部分问题。

1. 约束输入把相关资料一起喂进去，明确要求「资料里没有就说不知道」。验证方法：故意问一个资料里没有的问题，看它是否老实说不知道。
2. 限制输出要求结构化字段，比如结论、依据、置信度分开写。这样程序能自动校验，出问题时也能一眼看出是依据错了还是结论推错了。
3. 外挂校验数字、链接、代码这类硬事实用规则或工具去核，别指望模型自查。验证方法：抽一批输出，把其中的数字和链接过一遍自动检查。
4. 兜底话术预设「无法确认」的回复模板，并要求模型在不确定时主动触发。验证方法：统计触发率，完全不触发说明提示词没生效，触发太多说明资料覆盖不够。

上线前后怎么量化，别只凭感觉说变好了

没有量化，你每次改提示词都像在碰运气。做法不复杂：建一个小而刁的测试集，专挑历史踩过的坑和模型不熟的领域，几十条就够用。每次换模型、改提示词、换知识库都重跑一遍。

• 记录错误类型分布，而不是只看对错比例，编造型和过时型要分开统计
• 线上收集用户标记的错误回答，定期回灌进测试集，让测试集跟着真实问题长
• 改动前后用同一套用例对比，避免换了用例还以为自己变好了
• 样本量太少时别下结论，几条用例的涨跌说明不了问题

如果你要对照不同模型或中转方案的实际表现，别凭印象，到站内的模型资料库和价格追踪页面核对你关心的那些数字，再结合自己的测试集决定用哪个。