不同业务场景下的幻觉问题
同样一句“AI 答错了”，在不同业务场景里的含义完全不同。
客服机器人答错退款规则，可能造成用户投诉和运营补偿。文档问答引用错内部制度，可能让员工按错误流程办事。代码助手生成不存在的 API，开发者通常能通过编译发现。数据分析助手误读指标，可能影响经营判断。医疗和法律助手给出未经确认的建议，则可能带来真实伤害。
所以讨论幻觉，必须把场景放在前面。不是所有场景都需要同等强度的治理，也不是所有场景都能接受同样的错误率。
这篇文章按常见业务场景拆解幻觉问题：每个场景的收益在哪里，容错边界在哪里，常见幻觉是什么，以及应该优先使用哪些方案。
场景一：客服和售后
客服是很多团队最早尝试 AI 的场景，因为它有明显收益：
- 高频问题可以自动回复。
- 人工客服可以用 AI 生成回复草稿。
- 工单摘要和分类能减少处理时间。
- 多语言、夜间、节假日覆盖更容易。
但客服也是很容易出现“低成本错误变高成本事故”的场景。模型一句自信的承诺，可能会被用户截图当成官方政策。
场景分析
客服幻觉常见在四类问题里。
第一类是政策编造。比如用户问“超过 30 天还能退款吗”，模型为了安抚用户，编造了一个不存在的特殊退款通道。
第二类是过度承诺。比如模型说“我们一定会在今天退款到账”，但系统并没有查支付渠道状态，也没有这个服务承诺。
第三类是状态错判。比如用户订单仍在审核中，模型却说“已经发货”。这通常不是语言能力问题，而是没有调用订单工具或工具结果没有被正确使用。
第四类是情绪处理失衡。用户投诉时，模型可能过度道歉、过度承诺、推卸责任，或者把内部流程暴露给用户。
收益和容错
客服场景的收益很高，但容错取决于输出位置。
很多客服 AI 最合理的起点不是全自动机器人，而是“客服辅助”：让模型生成草稿、总结历史、推荐知识库条目，由人工确认后发送。
方案选型表
场景二：文档问答和知识库
文档问答的目标看起来清楚：用户问问题，AI 根据文档回答。
它的收益是把“找资料”变成“问问题”。对内部制度、产品文档、API 文档、研究资料、项目文档都很有用。
但它的幻觉也很隐蔽，因为答案常常带着引用。用户看到引用后会更信任，而引用未必真的支持结论。
场景分析
文档问答的幻觉主要来自五个环节。
检索阶段可能找错文档。比如用户问“企业版审计日志保存多久”，系统检索到了“日志导出格式”，但没检索到“保存周期”。
切分阶段可能破坏语义。一个条款被拆成两段，模型只看到例外条件，看不到适用条件。
上下文组装可能混入无关内容。多个版本的政策同时进入上下文，模型把旧版本和新版本混在一起。
生成阶段可能过度概括。文档只说“部分客户可申请试用”，模型总结成“所有客户都可以试用”。
引用阶段可能失真。答案引用了某个 source id，但句子里的关键结论并不在该 source 里。
收益和容错
文档问答的容错比普通聊天低，但比医疗法律最终建议高。因为它通常有可验证资料，用户也可以点回原文。
关键是让用户知道：答案是基于哪些资料生成的，哪些问题当前资料无法回答。
方案选型表
场景三：代码助手
代码助手的收益非常直接：
- 生成样板代码。
- 解释陌生代码。
- 修改已有实现。
- 写测试。
- 排查报错。
- 迁移框架或 API。
代码场景的特殊之处在于：很多幻觉可以被工具发现。类型检查、单元测试、lint、构建、运行时错误、代码审查，都是天然的校验层。
场景分析
代码助手常见幻觉包括：
- 编造不存在的库、方法、参数或配置项。
- 使用过时 API。
- 忽略项目里的封装和约定。
- 生成能跑但不符合业务规则的代码。
- 修复一个问题时引入安全漏洞。
- 对报错原因做过度推断。
代码助手最危险的不是“写不出代码”，而是“写出看起来对、但没有经过项目验证的代码”。
例如模型生成了一个 React 组件，语法正确，但没有处理加载态、错误态、可访问性和权限边界。它不是简单事实幻觉，而是工程上下文缺失。
收益和容错
代码助手的容错通常高于高风险业务建议，因为开发流程可以逐步验证。但这不代表可以放任模型自由提交代码。
代码场景尤其适合“工具校验”。不要只问模型代码对不对，要真的运行测试、类型检查和构建。
方案选型表
场景四：数据分析和 BI 助手
数据分析助手的收益在于把自然语言转成查询、图表和解释。业务用户不需要熟悉 SQL，也能问“上周华东区续费率为什么下降”。
但数据场景的幻觉非常容易影响决策。模型可能字段名写对了，结论却错了。
场景分析
数据分析幻觉通常不是单纯编造事实，而是指标口径、查询条件和解释链路出错。
常见问题包括：
- 使用错误指标口径，例如把 GMV 当收入。
- 时间范围不一致，例如“上周”按自然周还是最近 7 天。
- 维度过滤错误，例如漏掉退款、测试订单或内部账号。
- SQL 生成错误但仍然解释结果。
- 把相关性解释成因果。
- 对小样本波动做过度解读。
- 忽略数据延迟和缺失。
收益和容错
数据助手的收益很高，但容错取决于它输出的是“探索线索”还是“决策结论”。
数据助手应该把“查询”和“解释”分开。查询结果可以由工具返回，解释必须标注假设和限制。
方案选型表
场景五：医疗、法律、金融和合规
这些场景常被统称为高风险场景，但它们之间也有差别。
共同点是：用户往往缺少专业判断能力，错误可能带来健康、权益、财务或法律后果，且模型输出容易被误认为权威意见。
场景分析
高风险场景的幻觉不一定表现为明显错误。更常见的是越界：
- 把一般信息说成个体化诊断。
- 把法规摘要说成正式法律意见。
- 把投资教育内容说成买卖建议。
- 把合规资料整理说成最终合规结论。
- 忽略地区、时间、身份、资质和适用条件。
- 在证据不足时给出确定性措辞。
这里的治理目标通常不是“让模型答得更像专家”，而是“让模型不冒充专家”。
收益和容错
高风险场景仍然有很大 AI 价值，但适合切入辅助环节。
高风险场景里，简单加一句“仅供参考”远远不够。系统要在交互流程上限制输出边界。
方案选型表
跨场景比较
把几个场景放在一起看，差异会更明显。
一个实用判断是：如果用户能轻松验证输出，系统可以更偏辅助；如果用户会把输出当结论，系统就要更偏流程控制。
常见反模式
第一种反模式：把所有场景都做成聊天机器人。
聊天界面很灵活，但也容易让模型越界。客服退款、数据查询、合规判断、代码修改，都应该有工具、表单、确认和状态，而不是只靠一段对话。
第二种反模式：低风险场景过度工程化。
内部写作助手、摘要草稿、头脑风暴工具，不一定需要复杂 RAG、人工审核和重型 Eval。过度治理会让产品难用。
第三种反模式：高风险场景只加免责声明。
免责声明不能阻止模型输出危险结论，也不能保证用户理解风险。高风险场景需要流程级限制：拒答、转人工、引用、确认、审计。
第四种反模式：把“有引用”当成“可信”。
引用只是可追溯的入口。引用是否来自本次检索、是否有权限、是否支持结论，都需要校验。
第五种反模式：把工具结果和模型结论混在一个气泡里。
订单状态、查询结果、执行成功与否，应该在 UI 上有明确状态。模型解释可以放在旁边，但不能替代系统事实。
小结
幻觉治理必须从业务场景开始。
客服关注政策、承诺和转人工；文档问答关注检索、引用和拒答；代码助手关注项目上下文和工具校验；数据分析关注指标口径和解释边界；高风险专业场景关注越界、人工审核和审计。
同样的技术方案，在不同场景里的优先级不同。最好的路线不是一开始上最复杂架构，而是先判断收益、成本和容错，再选择刚好足够的可靠性设计。