我从实际开发和系统设计角度总结一下防御 AI 幻觉的手段，按层次从高到低排列：

一、架构层面：不给它瞎编的机会

1. 约束输出空间（最重要的单一手段）

• 用 JSON Schema / Function Calling / 工具调用 严格定义输出格式和取值范围
• 不是让 AI “自由发挥”，而是让它在你划定的框里选择
• 例：让它返回一个枚举值 {"action": "APPROVE" | "REJECT" | "ESCALATE"}，而不是让它在文本里自己编一个

2. RAG + 事实锚定

• 复杂业务逻辑不应依赖模型的训练记忆，而应检索相关文档/规则注入上下文
• 关键：检索到的内容要明确标记为"事实来源"，并在 prompt 中强调"只能基于以下内容回答"

3. 拆解为原子任务

• 把一个复杂判断拆成多个小步骤，每步只做一件事
• 例：不要问"这个贷款该不该批"，而是拆成：
  • Step 1: 提取用户收入（结构化提取）
  • Step 2: 根据规则表计算负债比（规则匹配）
  • Step 3: 对比阈值返回结论（布尔判断）
• 越少的自由文本生成空间 = 越少的幻觉

二、Prompt 层面：降低自由度

4. System Prompt 里的硬约束

1
2
3

- 不要编造任何不在上下文中提到的数据
- 如果不确定，必须回答"我不知道"而不是猜测
- 所有数字引用必须注明来源

5. Few-shot 示例

• 给出 3-5 个标准输入输出示例，建立模式
• 对于业务规则类任务，few-shot 的效果往往比长篇指令更好

6. Chain-of-Thought + 自我验证

• 让模型先展示推理过程，再给出结论
• 加入验证步骤：“请检查你的回答是否与上下文一致，如不一致请修正”

7. 温度调低

• 复杂业务逻辑场景，temperature 设为 0 或极低值（0.01-0.1）
• 你要的是确定性和一致性，不是创造力

三、工程层面：多重校验

8. 输出校验层（Guardrails）

• AI 输出后，用确定性代码做后验证：
  • 类型检查、范围检查、格式检查
  • 业务规则引擎二次校验
  • 关键字段与源数据交叉比对
• 工具如 Pydantic 验证、自定义 validator chain、Outlines/Instructor 等库

9. 多次采样 + 一致性投票

• 对同一个问题跑 3-5 次，取多数一致的结果
• 不一致的部分标记为"需要人工审核"
• 成本高但对高风险场景（金融、医疗）值得

10. Human-in-the-loop

• 高风险决策：AI 只做推荐，最终由人确认
• 中风险：AI 自主执行，但异步审计日志留痕
• 低风险：全自动，但定期抽检

四、模型层面：选对工具

11. 能力匹配

• 简单分类/提取 → 小模型足够（GPT-4o-mini / Claude Haiku），小模型反而幻觉少
• 复杂推理 → 大模型（GPT-4o / Claude Opus / Gemini 1.5 Pro），但必须配合上述约束
• 不要用大模型做小模型能做的事，能力过剩反而增加幻觉空间

12. 微调 vs 提示工程

• 如果某个业务逻辑反复出现且规则固定，微调比 prompt 更可靠
• 但微调不等于解决幻觉，规则频繁变化的场景更适合 RAG

实战优先级排序

一句话总结：对抗幻觉的核心策略是 —— 尽可能压缩 AI 的"自由发挥空间"，让它在结构化的框架里做事，然后用确定性代码兜底。 AI 擅长的是理解和编排，不是凭空生成事实。