1. 先把这个“同源”说清楚：幻觉和创造在模型里共用同一条底裤
1.1 从一次离谱回答说起：它是“错”还是“过于自由”
去年我做一个垂直领域的智能辅助工具，目标是让模型帮运营同学生成活动方案。测试时问了一个很普通的问题：某个快消品牌要做夏季新品推广，预算有限，怎么设计一个线下快闪活动？
模型给出的回答里藏着一句话：“建议与本地独立咖啡品牌联名，在门店内设置AI生成艺术装置，并在小程序端发起打卡集章任务。”
这句话让我盯着屏幕看了很久。活动方案本身没问题，咖啡联名也是常见玩法。但“AI生成艺术装置”这个点，既不在我喂给它的行业资料里，也没有在任何一条参考来源中出现。它是模型自己“长”出来的。
放在传统软件工程里，这叫输出不可控，是缺陷。可放在创意生产场景里，它反而成了亮点。问题就来了：同样是“模型自由发挥”，什么时候它是令人惊喜的创新，什么时候它是让人尴尬的幻觉？
我用了很长时间才想明白一件事：在生成式模型内部，创新和幻觉共用同一个底层过程。真正有价值的工作不是“把幻觉消灭掉”，而是设计一套框架，让这个过程大部分时候向创新一侧倾斜。
这个视角我管它叫“孤能子视角”。名字有点玄乎，其实意思很简单：把每一次生成看作一个孤立粒子的状态——它可能向上自旋，也可能向下自旋，你的观察方式决定了你看到的是噪声还是信号。工程化框架要做的，就是为这些粒子设置磁场，让自旋方向大概率可控。
1.2 大模型生成机制里的“随机外推”与“记忆压缩”
要想管理幻觉，得先理解它从哪来。很多人以为幻觉是模型“算错了”，实际上更准确的描述是：模型在概率空间里“走远了”。
大模型的本质是一个超大型条件概率分布。给定前文，它逐词预测下一个词最可能是什么。训练过程做的事，是让这个分布尽量贴近训练数据的真实分布。但注意，真实分布里的很多区域是稀疏的、不完整的。比如训练语料里关于“AI生成艺术装置”的片段可能极少，模型只能根据相近概念的分布特征，硬生生把这个词组合出来。
这就是第一个关键机制：随机外推。模型不是数据库，不会精确返回训练集里某一段原文。它把所有知识压成了高维空间里的参数，生成时从参数空间中做插值和外推。外推合理，就是“举一反三”；外推过度，就是“无中生有”。
第二个机制叫记忆压缩。大模型参数量有限，语料库却近乎无限。为了把海量知识塞进有限参数里，模型必须做有损压缩。压缩过程中，细节被牺牲，边界被模糊。所以模型擅长记得“大致轮廓”，却不擅长记住“精确数字”“具体出处”“事件时间线”。我测试过很多次，问它某个冷门政策文件的发布时间，它经常给出一个看起来精确、实际上错误的日期。这不是它傻，而是压缩过程允许它丢掉低频细节，然后用高频常识去“脑补”一个合理答案。
这两个机制解释了为什么幻觉如此普遍：它是生成式模型的物理学必然，不是修一个bug就能解决的。你不可能让一个擅长插值外推的系统永远只做“严谨复读”。
1.3 为什么说“幻觉”不是bug，是未被约束的过程
再深入一层。如果你把幻觉看作是未被约束的创新，很多工程决策就会发生改变。
我在实践中做过一个小实验。同一个模型，同一个Prompt，把温度参数从0.1调到1.2，它生成的文案风格截然不同。低温时，它倾向于安全、重复、正确的废话；高温时，它冒出大量新鲜角度，也伴随着大量事实错误。
从中可以提炼出一个关键观点：模型的“创造性”和“可靠性”不是两个开关，而是一条连续谱上的不同区间。温度只是最直观的调节旋钮，实际上影响这个谱系的还有采样策略、上下文长度、知识锚点密度、验证机制等。你要做的工作不是选一个“不撒谎的模式”，而是找到你的业务场景在谱系上应该落在哪个区域，再把一套系统工程搭在周围，既保留足够的探索空间，又把风险限制在可接受范围。
这个想法就是我最终决定写这篇文章的原因。我见过太多团队在“AI不准”这个问题上反复打转：有人拼命调Prompt，有人疯狂堆RAG，有人直接放弃生成只做检索。这些做法不是错，但都只处理了谱系的一端。真正稳妥的路径，是把创新与幻觉放进同一个框架里管理，先定义你的业务能容忍多大的风险额度，再设计生成、验证、兜底的完整链路。
接下来几节，我把自己落地这套框架的过程、踩过的坑和最终保留下来的设计逐一写出来。
2. 框架要解决的根本问题：为什么单靠提示词压不住幻觉
2.1 工程现场的失控点：从“偶尔惊艳”到“经常翻车”
先说一个我在多个项目里反复观察到的现象：大模型的输出质量分布极不稳定。通常刚接入时你会觉得它很聪明，跑一阵子后就会发现，它今天能给出完美答案，明天同样的问题就会变成一个看似流畅但完全错误的回答。这种非线性波动对内容生产、知识问答、辅助决策类场景都是致命的。你没法向业务方解释“模型今天心情不好”。
许多团队的第一反应是优化提示词。做法无非是：在Prompt里写“请基于以下资料回答，不要编造”“不确定时请回答不知道”。这些约束真的有用吗？有一点用，但远远不够。原因是模型对“不确定”的自我感知极不可靠。它有大量错误是“高置信度的错误”——生成时它真的觉得自己知道，注意力机制和概率分布都表现得很顺畅，没有任何内部信号提示这里可能要出错。
所以提示词工程能解决的是“语义对齐”问题，也就是让模型更准确地理解你的意图格式，但它解决不了“知识边界”问题。模型分不清自己的知识边界在哪里，它对外推和记忆都同样自信。
2.2 把创新和幻觉放进同一条管线的前提：先定义边界
在做框架设计之前，我强制自己完成一个动作：给“允许的创新”和“不允许的幻觉”划出明确边界。没有这个边界，任何技术参数的调整都是盲人摸象。
以我做的内容生成类项目为例，最终边界定义如下：
| 类别 | 允许范围 | 禁止范围 |
|---|---|---|
| 事实陈述 | 可溯源至知识库、引用出处可查 | 编造数据、虚构来源、伪造时间地点 |
| 观点输出 | 明确标注为“建议”“推测” | 把主观臆断包装成客观结论 |
| 创意发散 | 基于已有信息的合理延伸 | 脱离任务目标的无边际联想 |
| 预测推断 | 给出概率区间和前提条件 | 用确定性语气描述未发生之事 |
这个表格看起来简单，但它解决了一个容易被忽略的问题：不是所有幻觉都需要被消灭。在观点生成场景里，一定程度的自由发挥就是价值本身。而在事实问答场景里，哪怕一个数字错误都是事故。边界清晰之后，你才能给模型设计差异化的生成路线，而不是用一套冷冰冰的规则锁死所有输出。
2.3 四个矛盾与框架的整体姿态
画完边界，我开始梳理这个框架必须同时处理的四组矛盾。这四组矛盾是所有AI生成类项目共同的痛点：
第一，流畅性与可验证性的矛盾。模型生成越是行云流水，你越难快速定位它的论据支点。反之，如果每句话都挂引用，可读性和生成效率又会大幅下降。
第二，探索性与稳定性的矛盾。你希望模型给你一些“没想到”的角度，同时又希望它不要给出一个完全离谱的方向。这两个诉求天然冲突。
第三，任务完整性与安全兜底的矛盾。完整方案包含多个环节，其中某个环节如果出现幻觉，可能污染整个方案的逻辑链。安全兜底如果过于激进，又会打断模型思路，导致输出支离破碎。
第四，规模化效率与人工审核成本的矛盾。全量人工审核最稳妥，但失去了自动化意义。完全依赖自动评测，又会在长尾场景里漏掉隐蔽错误。
这四个矛盾没法靠一招解决。最后我采取的整体姿态，是一套三层结构：生成层负责“尽量探索”，约束层负责“尽量锚定”，评测层负责“尽量把关”。三层之间用路由逻辑连接，不同任务走不同的生成配置和评测强度。
3. 这套框架的骨架：分层可控的“创新-幻觉”工程化设计
3.1 双通道生成：先发散，后收敛
框架的第一个核心设计，是抛弃“一个Prompt走到底”的模式，改用双通道生成。
简单说，把一次任务拆成两段。第一段是发散通道，模型在较高温度下生成多个候选方向，目的是覆盖尽可能多的可能性。第二段是收敛通道，把发散阶段产出的候选方向连同任务原始目标打包，再让模型在较低温度下做筛选、合并和细化。
我用一个内容创作项目来举例。目标是生成一篇“城市夜经济观察”的短文章。发散阶段设置temperature=0.9，让模型一次性输出五个不同切入角度：街头小摊数据、夜间运动人群、24小时书店、灯光景观设计、夜班工作者口述。这五个点里有两个是常识内容，两个有部分依据但细节不足，还有一个方向完全偏离任务主题。
收敛阶段把五个点拿回来，连同用户原始需求一起输入模型，设置temperature=0.3，明确要求：删除与主题无关的内容，保留最多三个有效方向，并且为每个方向标注信息来源是“知识库”“网络检索”还是“模型推测”。最终产出的文章结构就比一次性生成稳健得多，同时也保留了发散阶段带来的新鲜视角。
这个设计的核心逻辑是：把“产生想法”和“打磨想法”交给模型的两个不同状态去完成，而不是让模型在同一状态里既天马行空又严谨求实。人写文章也是先打草稿再修改，模型其实一样。
3.2 约束层的四道阀门：温度、上下文、知识锚点、验证器
发散和收敛解决的是生产流程问题，但还要处理另一个关键点：模型在生成过程中到底靠什么来“不编”。这部分我设计了四个阀门，层层收紧：
第一道阀门：温度与采样参数。这是最粗粒度的控制。事实问答场景下temperature设为0.1-0.3，创意发散场景下设为0.7-1.0。这里我还会关掉top_k的极端采样，避免模型为了追求新奇选择概率极低的尾巴词。
第二道阀门：上下文约束。在Prompt里明确列出“你被允许使用的信息范围”。比如在垂直知识库场景里，我会把任务需要的本体结构、术语表、已知事实清单全部放进上下文，并告知模型只能在这些信息之上做组合，不能超出边界。注意这里的关键是“组合”而不是“引用”。允许模型对已知事实做重新组织，但不允许它新增未知事实。
第三道阀门：知识锚点。这是整个框架里最实用的设计。在生成之前，系统先从知识库检索出若干条与问题相关的内容，作为“锚点”拼入上下文，并要求模型生成的每个关键陈述在锚点集合里有对应支撑。锚点的数量通常控制在5到8条，太少不够覆盖，太多会稀释注意力。
第四道阀门：验证器。生成完成后，用一个独立的验证提示词对输出做二次审查。验证器不看原始Prompt，只看生成文本和锚点集合，逐句标记“有依据”“推测”“无依据”。这一步能显著提高幻觉检出率。原因在于，让模型“审视别人的回答”比让它“审视自己的回答”要容易得多。
3.3 框架的最小落地配置示例
整个框架听起来有点复杂，实际落地时可以用一套轻量配置起步。我把自己项目早期使用的最小配置贴出来，供参考：
generation: temperature: 0.72 top_p: 0.92 max_tokens: 1200 routing: factual_qa: temperature: 0.15 knowledge_anchor: true validator: strict creative_writing: temperature: 0.85 knowledge_anchor: false validator: relaxed analysis_task: temperature: 0.45 knowledge_anchor: true validator: standard knowledge_anchor: retrieval: hybrid top_k: 6 rerank: true require_citation: true validator: factual_strictness: 0.8 novelty_tolerance: 0.5 consistency_check: true这个配置的核心思想是：按任务类型路由到不同的生成策略。事实问答走低温、锚定、严格验证；创意写作走高温、少锚定、宽松验证；分析型任务走中间路线。路由表刚开始可以手工维护，跑一段时间后根据业务反馈逐步调整参数。
我见过一些人照抄这种配置后抱怨“效果没那么好”，原因往往是他们没有理解路由表里的温度差异是为不同任务目标服务的。如果你的业务只做一种类型，那这张表可以先只留一行，把精力放在锚点和验证器的调优上。
4. 评价体系才是最难的工程：把“有效创新”和“有害幻觉”分开度量
4.1 文本层面：事实性、新颖性、一致性三个维度怎么算
很多团队做AI生成项目，评价标准就一句话：“感觉还行。” 这在内部测试期可以凑合，一旦进入生产环境，没有量化指标就没法迭代。
我把输出评价拆成三个分数，每个分数用0到1表示。
事实性分数，衡量生成内容和知识锚点之间的一致性。具体做法是抽取生成文本中的实体、数字、事件关键词，与锚点集合做对比。实体重合率、数字准确性、逻辑关系是否被篡改，都计入得分。
新颖性分数，衡量生成内容相对于训练语料和参考资料的偏离程度。这里有一个很实用的做法：用模型自己算一遍生成文本的困惑度，或者让另一个模型判断“这份内容是否只是对输入资料的复述”。如果新颖性过低，说明模型在机械复读，没有提供额外价值；如果过高，说明它已经跑偏。
一致性分数，衡量输出是否和用户意图对齐。包括格式是否合规、任务要求是否全部覆盖、生成内容内部是否存在自相矛盾。
在工程实现上，这三个分数不需要都靠大模型判断。事实性可以用文本对齐、实体链接这些传统NLP手段来做，速度快且稳定。新颖性和一致性可以用一个轻量模型打分。把三类分数综合起来，就得到每次生成的“质量向量”。
4.2 任务层面：把“创新”放进任务闭环里评估
文本层面的三个分数还有一个盲区：它看不出任务最终是否完成。一篇文章可能每个句子都真实、新颖、连贯，但它根本没有回答用户的问题。
所以我加了一层任务层面的评估。具体做法是把任务拆成几项硬指标，例如：
- 问题覆盖率：回答是否覆盖用户问题中的每个子问题；
- 步骤完整性：操作类回答是否包含完整的执行步骤；
- 资源可用性：生成方案里提到的工具、平台、资源是否真实存在；
- 成本合理性：方案里的预算估算是否在用户给定范围内。
这一层评估不能用纯自动化的方式完成，但可以做一个筛选机制。系统先跑自动指标，对任务层面可疑的结果打上高风险标记，再进入人工抽检队列。我在实践中的节奏是：高风险内容全量人工看，中风险内容按30%比例抽检，低风险内容每两周随机抽50条复核一次。这套节奏把人工成本控制在可接受范围内，同时没有放松质量底线。
4.3 阈值策略与人工抽检节奏
有了分数之后，还要回答一个业务问题：多高的分算通过，多低的分算拒绝？
我的经验是不要搞一刀切。更合理的方式是设置两条线，中间留一片“灰度区”。一条线是“阻止线”，低于这条线的输出直接拦截，不给用户看。另一条线是“提醒线”，高于这条线但没到满分水平的输出可以放行，但需要在界面里给用户提示“本内容部分由模型推测生成，请复核关键数据”。
以我的内容辅助项目为例，事实性分数低于0.6直接进入重写流程；0.6到0.8之间放行但打上提示标签；高于0.8正常展示。新颖性分数则反过来：低于0.3说明模型在复读资料，要求重新生成；0.3到0.7之间是合理区间；高于0.85也要警惕，往往会伴随事实性下降。
这套阈值不是拍脑袋定的。我最初用的是单线判断，结果出现大量边界case。比如一段内容事实性得分0.78，但恰好错在一个关键数据上，直接影响业务决策。后来改成分区制，人为加一道人工复核能力，问题就少了很多。阈值本身也要每季度复盘一次，随模型版本迭代做小幅调整。
说到人工审核，我再补充一个细节：不要只审核输出的文字，一定要把生成日志一并提供给审核者。日志里记录了温度参数、路由类型、锚点召回集合、验证器标记等。审核者能看到这些信息后，判断效率会提高很多。否则你看到的只是一个孤立输出，很难判断它是模型自身问题还是上游参数配置问题。
5. 落地过程中我踩过的几个坑
5.1 温度参数不是越低越好，越低越会触发“机械复读”
先聊一个反直觉的坑。为了追求事实准确性，我最初把所有场景的温度都调得很低，有些场景甚至直接用greedy decoding。结果发现，输出确实不再“胡说八道”了，但内容质量出现另一种恶化：大量套话、表层重复、观点空洞。
原因是过低的采样温度让模型总是选择概率最高的路径，而概率最高的路径往往对应训练语料里的高频表达。高频表达看起来稳妥，却没有实际增量信息。比如你问“如何提高用户留存”，低温模型会给你一套标准的“上线活动、优化体验、建立社群”三板斧，听起来每个字都对，但等于没说。
后来我把所有任务的温度统一提升了0.1到0.2，并保留一个低概率采样空间。效果立竿见影，输出的信息密度明显上升，同时事实性没有明显下降。这就是那个“连续谱”思想的实践体现：你要的是在谱上找到一个平衡点，而不是把自己钉死在最安全的那一端。
5.2 知识锚点会反向污染：数据源里就有幻觉
框架里最常用的知识锚点机制，也踩过大坑。起初我假设知识库里的内容都是可信的，结果有一次系统持续生成错误的行业统计数据。排查时发现，问题出在知识库本身——里面某几篇早期灌入的文章本身就带着过时的、甚至完全错误的数据。
模型只是忠实地把错误锚点里的信息“复述”了出来，看起来有引用、有依据，实际上是在给错误信息背书。这个坑很隐蔽，因为常规评测很难发现：验证器检查的是“输出是否和锚点一致”，它不检查“锚点本身是否正确”。
从那以后，我在知识库入库阶段增加了单独的质量校验，对来源可信度、时效性、数据一致性做评分。低分内容允许进入检索范围，但必须带上“低可信度”标签，生成阶段遇到这类锚点会降低事实性得分权重。这个机制看起来简单，却能让整个防幻觉体系的底座更扎实。
5.3 评估数据集一固定，模型就开始“应试”
另一个深刻教训来自评测集。为了量化框架效果，我建了一套几百条的测试集，每条都有人工标注的参考答案。跑了一两个月，指标很漂亮，应用效果却在下滑。
排查了很久才想明白：基于固定测试集的迭代优化，本质上变成了“针对测试集做拟合”。模型和验证器都慢慢学会了测试集里答案的分布模式，但到了真实用户问题里，输入分布完全不同，效果就露馅了。
后来我改成流动评测集：每个月替换其中的30%，并且从真实用户会话里随机抽选新样例补充进去。这些新样例不需要人工标注，先通过框架自动打分，出现低分再人工复核。这个机制让评测集始终跟进真实分布，模型也没有机会“背题”。
5.4 多语言模型在同一框架下的效果落差
最后一个是相对小众但值得提的坑：同一个框架在不同语言上的表现差异极大。我最初在中文场景里调好的参数，切到英文场景后事实性分数掉了将近十个百分点。
原因不复杂。多语言模型的训练语料在不同语言上的覆盖程度差异极大，英文语料丰富，模型内部记忆本身就比较稠密，外推风险低；中文次之；到了长尾语种，语料稀疏，模型很多回答都是靠邻近语言的迁移完成的，幻觉天然偏高。
应对方式是把路由表按语言拆开，不同语言设置不同的锚点数量和验证强度。稀疏语言场景里，我还会强制开启“拒绝回答”策略：如果锚点召回数量低于阈值，模型必须明确回答“此问题暂时缺少足够信息”，而不是硬着头皮生成。这个策略表面上看损失了一部分回答率，但大幅降低了错误信息的输出量，长期收益更大。
写在最后的经验沉淀
这套框架从雏形到稳定，我前前后后调整了大半年。最大的收获不是技术层面的某个参数或某个模块，而是一种思维方式的转变：不要试图让模型“永远正确”，那是违背其底层机制的。你要做的是给它一个足够清晰的舞台，让它在舞台上跳舞而不是撞翻道具。
如果你也在做类似的事情，我的建议是：先花两周时间把业务的知识边界和幻觉容忍度梳理清楚，再着手配置生成参数和验证器，不要一上来就堆技术方案。过程中持续用真实数据回流迭代，而不是守着固定的测试集自我感动。框架本身不复杂，复杂的是你对自己业务场景里“什么叫好、什么叫坏”想得有多清楚。
