什么是幻觉，为什么无法彻底消除
幻觉指模型生成了看似合理但错误的内容：不存在的函数名、虚构的论文、算错的金额。它源于模型的工作方式——按概率续写最可能的下一个词，而不是查证事实库。因此幻觉无法被提示词彻底消除，只能靠流程把它挡在使用之前。
四类最容易幻觉的场景
| 场景 | 典型表现 | 防线 |
|---|---|---|
| API 与函数名 | 编造不存在的参数、返回值 | 查官方文档、IDE 跳转、编译验证 |
| 数字与计算 | 金额、百分比、统计口径出错 | 计算交给工具，不让它口算 |
| 引用与来源 | 虚构论文、链接、条款编号 | 要求给出可核验链接并逐个打开 |
| 「我记得有这个功能」 | 把 A 库的能力安到 B 库上 | 写 20 行最小例子实跑验证 |
六步校验清单
- 区分事实与推断：提示中要求「不确定就写未知」，并在输出里标注依据；
- 要求可核验来源：每个关键结论附官方文档链接或代码文件路径；
- 用工具替代口算：计算、编码转换、哈希与文件校验交给确定性工具；
- 最小复现：涉及 API 或依赖行为的结论，写一个最小例子跑一遍；
- 自动化拦截：结构化输出先进 schema 校验，再进入业务逻辑；
- 保留人工终审：对外发布、结算、合规相关内容必须由人确认。
三个可直接复用的提示片段
// 1. 强制标注不确定性
对每个结论标注 [确定] / [推测] 并说明依据；依据缺失时写 [未知]
// 2. 禁止编造来源
只引用你能给出的链接；找不到就回答「我没找到可靠来源」
// 3. 计算交给工具
不要直接给出计算结果，只列出公式与参数，我来用工具算实战场景：三类高危幻觉
- 伪造引用与链接：文献名、DOI、链接看似合理却不存在，必须逐条打开验证。
- 过时或相反的事实：模型可能把旧版本信息说得斩钉截铁，涉及版本、数值要回源核对。
- 看似严谨的计算：步骤完整但中间数错了，关键计算要用工具或代码复核。
常见问题
降低 temperature 就不会幻觉了吗？会减少随机性，但不能消灭幻觉——错误内容同样可以「稳定地」被反复生成。让模型自己复查一遍有用吗？有帮助（自我一致性检查），但它可能重复同一个错误，仍需要外部验证。加了 RAG 就安全吗？只能降低凭空编造的概率：检索到的片段本身可能过时或不相关，来源仍需校验。
把校验写进流程，而不是靠自觉
- 输出结构化：让模型以 JSON 输出结果，进入业务前先做 schema 校验，把「差不多」挡在系统之外；
- 关键结论必带来源：没有来源的结论不允许进入文档、代码注释或对外回复；
- 计算类任务一律走工具：模型只负责描述步骤与公式，不负责给出最终数值；
- 保留人工终审清单：对外发布、金额、合规与安全相关内容逐条签字确认；
- 记录失败样本：把每次发现的幻觉整理成用例，用于回归评估提示词与流程是否真的改善。
交叉验证技巧
- 换问法再问一次：把同一问题换个表述或反过来问，两次答案矛盾就是危险信号；
- 要求给出处：让它标明依据来自哪段材料，无法标明的部分一律按未证实处理；
- 拆成可验证的小问题：把大结论拆成若干可独立核实的事实点，逐条查证比整体“看起来对”可靠得多；
- 重点核对三类内容：数字与日期、API 与函数签名、法规与标准条款——这三类最容易被编造且代价最高。