作为产品经理，我怎么"管住"大模型不乱说话——防幻觉设计的 3 个实战方法

行业洞察 · AI 落地实战

上一篇我聊了大模型幻觉是什么，以及为什么它在 B 端是一个比 C 端严重得多的问题。

最后我说了一句话：幻觉不能消灭，但可以被"设计进去"。

这篇就来说具体怎么做。

我不打算讲算法层面的优化方案——那是模型工程师的工作，不是产品经理的工作。我要讲的是：在产品设计层面，有哪些方法可以把幻觉的影响控制在可接受的范围内。

这三个方法，都来自我在实际项目里用过的东西，不是理论推导出来的。

方法一：强约束 System Prompt——给模型划定"只能在这个房间里说话"

很多人用大模型的方式是这样的：把问题扔给模型，让它自由发挥。

在 C 端这没什么问题，但在 B 端企业场景里，这等于把一个有时候会编答案的员工放进会议室，让他对着客户随便说。

System Prompt 的本质，是在模型开口之前，先告诉它它能说什么、不能说什么、用什么格式说。

举个具体的例子。在智能问数场景里，如果不加约束，模型可能会这样回答用户的问题：

> "根据历史数据分析，华东区销售额预计在下个季度呈上升趋势，建议重点关注……"

这段话读起来很"专业"，但问题是：用户问的是一个查数问题，模型没有权限做趋势预测，这个"上升趋势"是模型自己推断出来的，不是数据库里的事实。

加了强约束的 System Prompt 之后，模型会被限制在这个范围内：只能基于查询结果回答，不能做数据库之外的推断，不确定的内容必须明确标注"数据中未找到相关信息"而不是自己补全。

写 System Prompt 有几个实用原则：

• 用否定句比用肯定句更有效。"不得进行数据推断"比"只回答事实"的约束力更强，模型对明确的禁止指令更敏感。
• 把输出格式也写进去。规定模型必须按照固定格式回答，减少它"自由发挥"的空间。
• 边界要具体，不能模糊。"只回答相关问题"是无效约束，"只能基于以下数据源回答，数据源范围为 XXX"才是有效约束。

System Prompt 是第一道防线，但它不是万能的。模型有时候还是会在约束边缘游走。所以需要第二道防线。

方法二：溯源引用机制——让每一句话都有"出处"

这个方法的核心逻辑很简单：模型说的每一句有实质内容的话，都必须能追溯到它来自哪里。

在 RAG 架构的产品里，这件事相对好实现——模型的每个回答都是基于检索出来的文档片段生成的，可以要求模型在回答时标注"以下内容来源于[文件名/段落编号]"。

用户看到一个回答，同时能看到这个回答引用的原始段落是什么。他不需要盲目相信模型，他可以自己去核实。

这个机制在企业知识库和数据治理场景里非常重要。比如用户问"我们公司的数据分级标准是什么"，模型给出的答案如果没有溯源，用户无从判断这个答案是从公司内部文件里读出来的，还是模型根据"行业惯例"编出来的。

但如果模型回答的同时标注了"以上内容来源于《数据治理规范 V2.3》第 4.2 节"，用户就能直接跳转去核实原文。这把验证的主动权交还给了用户，而不是让用户被迫相信模型。

有一个细节值得单独说：溯源机制同时也在倒逼模型约束自己。 当模型知道它必须标注来源时，它生成没有来源的内容的概率会降低——因为一旦标注不出来源，这个回答就会被系统判定为无效输出。这是一种隐性的约束机制。

方法三：Human-in-the-loop——在关键节点把决策权还给人

前两个方法都是在事前和事中约束模型。第三个方法是在结果出来之前，设计一个人工确认的节点。

这件事听起来很朴素，但在实际产品里，决定"在哪里放这个节点"是有讲究的。

放太多：用户每一步都要确认，体验极差，AI 的效率优势全被抵消了。 放太少：模型在关键节点出了错，用户没有机会纠正，问题直接进了下游。

我在做智能问数产品时，把这个节点放在了一个很具体的位置：SQL 执行之前。

具体来说，当用户提出一个查数问题，模型将自然语言翻译成 SQL 之后，不会立刻执行这条 SQL——系统会先把模型的"理解"用大白话展示给用户：

> "我理解你想查询的是：华东区、2025 年 3 月、销售完成率。查询范围包含 XX 张报表。请确认是否正确？"

用户看到这个确认界面，可以判断模型有没有理解偏。如果没问题，点确认，SQL 才会执行，数据才会返回。

这个设计解决了一个很关键的问题：用户不需要懂 SQL，但他能看懂"这条查询在问什么"。 技术黑盒被翻译成了业务语言，在结果出来之前就给了用户一次纠错的机会。

这个节点的位置选得准，原因是：SQL 执行是一个不可逆的动作（尤其在涉及数据修改的场景里），而且是最容易出现理解偏差的地方——自然语言到 SQL 的翻译，稍微一偏，查出来的数据就完全不是用户想要的。把 Human-in-the-loop 放在这里，拦截成本最低，价值最高。

三个方法的组合逻辑

说完三个方法，我想补一句整体的判断：

这三个方法不是选一个用，而是应该组合使用，分别在不同层面形成防线。

System Prompt 是模型层面的约束，在模型开口之前就限制了它的活动范围；溯源引用是结果层面的验证，让每个输出都可以被核实；Human-in-the-loop 是流程层面的兜底，在最关键的节点上保留人的判断权。

三层叠加，不是说幻觉就彻底消失了——而是说，即使幻觉发生，它造成真实损害的概率被大幅压低了。

在 B 端企业场景里，这件事的本质不是"让 AI 变得完美"，而是"让 AI 在不完美的情况下，依然能被安全地使用"。

这两件事，差别很大。

下一篇：从国画系学生到 AI 产品经理——我走了一条不太线性的路