#降低幻觉的方案阶梯

降低幻觉不等于一上来就做复杂系统。

有些场景，一个写清楚边界的提示词就足够。比如内部写作润色、低风险摘要、可编辑草稿，用户本来就会检查和修改。此时上重型 RAG、人工审核和复杂 Eval，可能收益不大，反而拖慢产品。

但有些场景不能只靠提示词。只要答案涉及私有知识、实时数据、用户权益、不可逆操作、高风险专业建议，就需要把可靠性从“模型自觉”升级成“系统约束”。

这篇文章把降低幻觉的手段整理成一条方案阶梯。你不需要每个项目都走完整条阶梯，但需要知道什么时候该往上走。

#第零步：先判断需不需要治理升级

在选择方案之前，先做一个简短判断。

如果这些问题大多是否定的，提示词和 UI 边界可能就够了。

如果其中两三个是肯定的，就应该逐步引入更强约束。

#第一层：提示词边界

提示词是最便宜的治理手段。它不能彻底消除幻觉，但可以显著减少明显越界。

一个可靠的提示词边界通常包含：

• 角色和任务范围。
• 可以使用的信息来源。
• 不知道时如何回答。
• 不能编造来源、链接、数据或操作结果。
• 需要追问的条件。
• 输出格式和语气。
• 高风险问题的拒答或转人工规则。

例如文档问答可以写：

你只能根据提供的文档片段回答。
如果文档片段无法支持答案，请说“当前资料无法确认”，并说明缺少什么信息。
不要使用常识补全文档没有给出的政策、价格、时间或承诺。
每个关键结论后都必须标注 source id。

这个提示词并不复杂，但它比“请准确回答用户问题”强得多。

#场景分析

提示词适合低风险、可编辑、用户能判断的场景：

• 写作润色。
• 会议纪要草稿。
• 邮件草稿。
• 头脑风暴。
• 简单分类和摘要。
• 内部低风险助手。

它也适合作为所有复杂方案的第一层。即使后面接 RAG、工具和 Eval，模型仍然需要清楚知道边界。

#收益和成本判断

提示词的性价比很高，但它是软约束。只要错误成本开始升高，就要加入硬约束。

#方案选型表

#第二层：引用和上下文

当答案需要事实依据时，下一步是把依据放进上下文，并让答案展示引用。

引用的价值不是装饰，而是让用户和系统都能追溯“这句话凭什么这么说”。

一个可用引用系统至少需要：

• source id。
• 标题或来源名称。
• 文档版本或更新时间。
• 片段位置，如页码、段落、行号。
• 权限过滤后的来源集合。
• 答案中的关键结论和来源绑定。

#场景分析

引用适合：

• 文档问答。
• 内部制度查询。
• 产品政策解释。
• API 文档问答。
• 合同和条款摘要。
• 研究资料整理。

引用不能保证答案正确，但能降低“无法追溯”的风险。用户看到原文后，可以判断答案是否过度概括。

#收益和成本判断

因此引用最好配合后端校验：答案里出现的 source id 必须来自本次检索结果，不能让模型编 source id。

#方案选型表

#第三层：RAG

RAG 适合答案依赖私有知识、长文档或频繁更新资料的场景。

但 RAG 的核心不是“向量数据库”。一个真正可用的 RAG 链路包括：

• 文档入库。
• 清洗和切分。
• 元数据和权限。
• 向量、关键词或混合检索。
• rerank。
• 上下文组装。
• 引用展示。
• 缺资料拒答。
• trace 和评估。

#场景分析

RAG 适合：

• 文档问答。
• 企业知识库。
• 产品帮助中心。
• 合同和制度查询。
• 技术文档助手。
• 内部流程和政策助手。

RAG 不适合解决所有幻觉。比如订单余额、库存状态、今天的数据指标，通常应该查数据库或业务 API，而不是放进向量库。

#收益和成本判断

RAG 的难点通常在工程细节，而不是模型调用。文档版本、删除失效、权限隔离、chunk 粒度、检索召回、上下文排序，都会影响幻觉。

#方案选型表

#第四层：工具校验

当事实来自业务系统时，工具比 RAG 更可靠。

订单状态、账户余额、库存、权限、日程、审批、运行测试、查询数据库、执行 SQL、调用风控规则，这些都应该由工具返回结果。

模型在这里的角色是：

• 理解用户意图。
• 选择需要调用的工具。
• 生成工具参数候选。
• 解释工具结果。
• 在工具失败时说明状态。

模型不应该凭空声明工具结果。

#场景分析

工具校验适合：

• 客服订单查询。
• 数据分析。
• 代码助手。
• 自动化工作流。
• 预约、审批、支付、发票、库存等业务操作。

例如用户问“我上个月的消费是多少”，模型不应该直接估计，也不应该从历史聊天里猜。它应该调用账单工具，工具返回金额、币种、时间范围和数据更新时间，再由模型解释。

#收益和成本判断

工具校验的关键是状态机。前端和后端都要区分“模型打算调用”“工具正在执行”“工具成功”“工具失败”“用户已确认”“操作已完成”。

#方案选型表

#第五层：结构化输出

结构化输出解决的是“模型输出能不能被程序可靠消费”。

它不能保证事实正确，但能减少格式幻觉、字段缺失、枚举漂移和下游解析失败。

适合结构化输出的场景包括：

• 表单填充。
• 意图识别。
• 工单分类。
• 工具参数生成。
• SQL 生成后的元信息。
• 风险标签。
• UI 组件渲染数据。

#场景分析

自由文本很适合给人看，但不适合直接驱动系统。

如果模型要输出：

{
  "action": "refund",
  "orderId": "123",
  "amount": 99
}

那系统必须校验 action 是否是合法枚举、orderId 是否属于当前用户、amount 是否在可退款范围内。JSON parse 成功不代表业务正确。

#收益和成本判断

结构化输出应该和 schema 校验、业务规则校验一起使用。

#方案选型表

#第六层：人工审核

人工审核适合错误成本高、自动校验不足、输出会影响真实权益的场景。

它不是把 AI 产品做弱，而是把 AI 放在合适的位置：让模型承担整理、草拟、检索、比对和提醒，让人承担最终判断和责任。

#场景分析

应该考虑人工审核的场景：

• 医疗建议。
• 法律意见。
• 投资和信贷建议。
• 大额退款或补偿。
• 权限变更。
• 删除、提交、发布等不可逆操作。
• 对外正式承诺。

人工审核可以分为几种形态：

• 发送前确认。
• 高风险命中后转人工。
• 专家复核草稿。
• 双人审批。
• 抽样质检。
• 事后审计。

#收益和成本判断

人工审核要配合清晰的审核材料。不要只给审核人一段 AI 答案，还要给来源、工具结果、风险标签、用户上下文和模型不确定点。

#方案选型表

#第七层：Eval 闭环

只要 AI 功能进入线上迭代，就需要 Eval。

原因很简单：Prompt 会改，模型会升级，知识库会更新，检索参数会调，工具接口会变化。没有 Eval，团队只能靠肉眼试几个问题判断质量。

Eval 的目标不是一次性证明“没有幻觉”，而是持续发现退化。

#场景分析

Eval 特别适合：

• 文档问答。
• 客服回复。
• 数据分析助手。
• 代码生成。
• 高风险场景的安全边界。
• 任何频繁迭代的 AI 链路。

一个最小可用 Eval 可以从 30 到 50 条样例开始，覆盖高频问题、边界问题、历史失败、资料缺失、权限边界和安全风险。

#收益和成本判断

Eval 要尽量评估真实链路，而不是只评估裸模型。RAG、工具、结构化输出、UI 状态和拒答都应该进入评估视野。

#方案选型表

#一条实用升级路径

实际项目里，可以按下面路径渐进升级。

这条路径的好处是，每一步都对应一个真实问题，而不是为了架构完整而架构完整。

#常见反模式

第一种反模式：只写“不要幻觉”。

这句话太抽象。模型需要具体规则：何时拒答、依据是什么、引用怎么标、工具失败怎么说、哪些问题必须转人工。

第二种反模式：把 RAG 用在所有事实问题上。

RAG 适合文档知识，不适合实时状态和业务操作。订单、余额、库存、权限、指标，应该优先用工具。

第三种反模式：结构化输出后就信任内容。

JSON 合法不等于事实正确。schema 只解决格式，业务规则和事实来源仍然要校验。

第四种反模式：人工审核没有上下文。

如果审核人看不到来源、工具结果和风险点，只能重新查一遍，审核成本会很高，也容易流于形式。

第五种反模式：Eval 只评估最终文本。

幻觉可能来自检索、工具、上下文、解析和 UI 状态。只看最终答案，会错过问题根因。

第六种反模式：一开始就追求完美 Eval。

Eval 可以从小评估集开始，先覆盖历史失败和高频问题。能稳定防回归，比指标体系漂亮更重要。

#小结

降低幻觉是一条阶梯，而不是一个开关。

低风险场景可以从提示词边界、拒答和用户反馈开始，有时这已经足够。需要事实依据时，加引用和 RAG。涉及实时数据和操作时，让工具成为事实源。输出要进入系统时，用结构化输出和校验。错误成本高时，引入人工审核。功能进入持续迭代后，用 Eval 建立质量闭环。

真正成熟的 AI 应用，不是承诺模型永远正确，而是知道什么时候可以相信、什么时候需要验证、什么时候必须让人接管。