2026-05-16
Question
在企业知识库问答或业务助手中，用户经常会说：“AI 看起来很自信，但答案是错的。”
请你解释：
- 什么是 hallucination？它和普通的“答错”有什么区别？
- 从大模型生成机制角度看，为什么模型会产生 hallucination？
- 在工程系统中，你会用哪些方法降低 hallucination？
- 如何评估一个系统的 hallucination 是否真的减少了？
Your Answer
不知道
Review
本次未作答，完整示范回答如下。
Improved Answer
结论先行：hallucination 是大模型在缺乏可靠依据时，仍然生成看似合理但事实错误的内容。治理 hallucination 的核心不是只调 Prompt，而是要从 grounding、约束生成、评测和失败兜底四个层面系统设计。
1. 什么是 hallucination？它和普通“答错”有什么区别？
hallucination 指模型生成了没有事实依据、与真实知识或给定上下文不一致，但表达上很自信、很流畅的内容。
它和普通“答错”的区别在于：
- 普通答错可能是推理失误、理解偏差、计算错误；
- hallucination 更强调：模型编造了不存在的事实、引用、来源、规则或结论；
- 它通常具有迷惑性，因为语言表达很自然，用户不容易立刻发现问题。
例如企业知识库里没有某个报销政策，模型却回答：“根据公司 2024 年新版制度，住宿费上限是 800 元。”这就是典型 hallucination。
2. 为什么模型会产生 hallucination？
从生成机制看，大模型本质是在根据上下文预测下一个 token，而不是直接查询事实数据库。
主要原因包括：
-
训练目标不是事实校验
- 模型训练目标通常是预测下一个 token；
- 它学到的是语言模式和统计相关性，不保证每句话都真实。
-
模型内部知识可能过期或不完整
- 训练数据有时间边界；
- 企业内部知识、实时信息、私有规则通常不在模型参数里。
-
上下文证据不足时仍会继续生成
- 如果 Prompt 没有要求“不知道就说不知道”，模型可能倾向于补全一个看似合理的答案。
-
高自由度生成会放大不稳定性
- 较高的 temperature、开放式问题、缺少引用约束，都可能增加编造概率。
3. 工程系统中如何降低 hallucination？
可以分四层治理。
第一层：让模型有可靠依据，也就是 grounding。
常见方法是 RAG：
- 把企业文档切成 chunk；
- 用 embedding / hybrid search 检索相关内容；
- 必要时用 reranking 提升相关性；
- 把检索到的证据放进 context；
- 要求模型只能基于证据回答。
第二层：约束模型输出。
例如：
- Prompt 中明确要求：没有证据就回答“不知道”；
- 要求每个关键结论附 citation；
- 限制模型不能使用 context 之外的信息；
- 对结构化场景使用 structured output，减少自由发挥空间。
第三层：增加校验机制。
例如：
- 回答生成后再做 factual consistency check；
- 检查答案中的关键 claim 是否能被引用文档支持；
- 对高风险答案增加人工确认；
- 对 tool call 场景，用真实 API 返回值替代模型猜测。
第四层：产品兜底。
例如：
- 展示引用来源；
- 标注置信度或“基于以下资料回答”；
- 对证据不足的问题明确拒答；
- 支持用户反馈错误答案，并进入后续评测集。
4. 如何评估 hallucination 是否减少？
不能只看主观感觉，需要建立 evaluation。
可以从几个维度评估：
-
构建测试集
- 收集真实用户问题；
- 覆盖有答案、无答案、模糊问题、跨文档问题；
- 为每个问题标注标准答案和支持证据。
-
评估 answer correctness
- 答案是否和标准答案一致；
- 是否遗漏关键条件；
- 是否引入错误事实。
-
评估 groundedness
- 答案中的关键结论是否能被检索证据支持；
- 引用是否真实存在；
- 有没有 context 中没有的编造内容。
-
评估拒答能力
- 对知识库中没有答案的问题，系统是否能正确说不知道；
- 不能为了覆盖率而牺牲真实性。
-
线上监控
- 记录用户反馈、人工纠错、低置信度回答；
- 定期抽样审查；
- 把线上错误 case 回流到 regression test。
总结一句话：hallucination 的治理核心，是让模型从“凭语言概率生成答案”，变成“基于可验证证据生成答案”；并通过 evaluation 持续证明它真的减少了编造。