你有没有这样的体验：问 ChatGPT 一个问题，它回答得头头是道、引经据典，你差点就信了——直到你发现它引用的那篇论文根本不存在。
这就是所谓的”幻觉”（Hallucination）。
围绕幻觉，业界有各种各样的解释：训练数据有噪音、模型参数不够大、RLHF 没对齐好……这些说法都对，但都没有触及最本质的那一层。
今天我想聊聊，大模型幻觉到底是怎么回事，以及一个正在被越来越多人重视的解决思路——上下文工程（Context Engineering）。
先搞清楚一件事：大模型在干什么
要理解幻觉，得先理解大模型的工作原理。
大模型本质上是一个条件概率机器。给定前文，它预测下一个 token 出现的概率分布，然后从中采样。整个生成过程，就是一连串的”下一个词最可能是什么”的概率接龙。
注意，是最可能，不是最正确。
这两者的区别，恰恰就是幻觉的根源。
林黛玉倒拔垂杨柳
我们来做一个思想实验。
假如你问模型：”请描述林黛玉倒拔垂杨柳的情节。”
这句话里有两个强信号：林黛玉和倒拔垂杨柳。前者指向《红楼梦》里那个弱柳扶风、多愁善感的少女，后者指向《水浒传》里鲁智深酒后逞威的经典桥段。这两个信号指向截然不同的语义空间，把它们拼在一起，就构成了一个信息熵极高的上下文。
什么是信息熵高？简单说就是”不确定性大”。模型拿到这个 prompt 后，陷入了纠结：到底该往《红楼梦》的方向生成，还是往《水浒传》的方向生成？两边的概率势均力敌，上下文没有提供足够的约束来把不确定性降下来。
但模型不能不回答，它必须输出点什么——因为自回归语言模型的本质就是”给定前文，生成续文”，它没有”我不知道”这个内建选项。
于是它开始做最擅长的事情：统计补全。
它会综合两边的语义，编出一段看上去合理但事实上荒谬的文字。比如它可能写出：”林黛玉走到大观园的垂杨柳前，气运丹田，双手抱住树干，一声娇叱之下连根拔起……”——语言通顺，文笔甚至还不错，但内容纯属一本正经地胡说八道。
这就是幻觉的本质：在信息熵高或信噪比低的上下文中，模型为了完成概率语言建模而进行的统计补全。
它不是”故意骗你”，也不是”太笨了不知道”。它只是一台概率机器，在信号不明确的时候，依然忠实地执行自己的使命——生成统计上最合理的下文。
再看几个日常例子
理解了这个本质，你会发现生活中大量的幻觉案例都可以用这个框架解释。
例一：捏造论文引用
你让模型”列出近五年关于xxx的重要论文”。模型的训练数据里确实见过大量论文标题、作者名和期刊名，但这些信息是碎片化的——它知道”Attention Is All You Need”是 Vaswani 等人写的，也知道 Nature 和 Science 发过很多文章，但它并没有一个结构化的论文数据库。当你要求它生成一个它不确定的引用时，它会把”看起来像论文标题的词组”+”看起来像作者名的人名”+”看起来像期刊名的名词”拼在一起。每一个局部都符合统计规律，但组合起来就是一篇不存在的论文。
这就是典型的信噪比低的场景：模型脑子里有大量关于论文的”噪声”，但缺少指向具体某篇论文的”信号”。
例二：信誓旦旦地算错数
问模型”17 × 24 等于多少”，它可能回答 able 408（正确答案），也可能回答 388 或者 418。因为乘法运算在语言模型的概率空间里本身就是一个高熵事件——从纯语言统计的角度看，”17 × 24 = 408”和”17 × 24 = 418”在 token 概率上并没有天壤之别。模型从来就不是在”算”，它是在”猜一个看起来像答案的数字”。
例三：编造 API 参数
你让模型写一段调用某个冷门 SDK 的代码。主流的 SDK 它见过足够多的示例，能写对；但遇到冷门的，训练数据里可能只出现过寥寥几次，信号极弱。于是它根据”类似 SDK 通常长这样”的统计规律，编造出一组似是而非的 API 签名。函数名像那么回事，参数顺序看着合理，但跑起来就是报错。
一个统一的解释框架
把上面的例子汇总，我们可以得到一个简洁的框架：
幻觉 = f(上下文的信息熵, 上下文的信噪比)
信息熵越高（不确定性越大），幻觉概率越高。信噪比越低（有效信息越少、干扰信息越多），幻觉概率越高。
反过来说，如果你能把上下文的信息熵降下来、把信噪比提上去，幻觉就会大幅减少。
这就引出了我们今天的主角：上下文工程。
什么是上下文工程
Prompt Engineering（提示词工程）你一定听过。上下文工程可以理解为它的进化版本——不只是关心怎么写 prompt，而是关心模型在生成时，整个上下文窗口里都装了什么。
一个大模型在推理时，它看到的全部信息就是上下文窗口里的内容。这包括：
- 系统提示词（System Prompt）
- 用户输入（User Message）
- 检索增强的文档（RAG 结果）
- 工具调用的返回值
- 历史对话记录
- 中间推理步骤
上下文工程的核心命题就是：如何精心组织这些信息，让模型在生成每一个 token 时，都处于一个低信息熵、高信噪比的上下文环境中。
说白了，就是帮模型”开卷考试”，而且是把正确答案翻到对应页码、用荧光笔划好重点地那种开卷。
上下文工程怎么治幻觉
1. RAG：把”闭卷”变成”开卷”
最直接的一招。模型不知道某个事实？没关系，帮它查好资料、塞进上下文。
比如前面”捏造论文”的例子。如果你先通过学术搜索引擎检索出真实的论文列表，把标题、作者、摘要、发表年份等结构化信息放进上下文，模型就不再需要”猜”了——它只需要把这些已有的事实用通顺的语言组织起来。信噪比直接拉满。
但 RAG 不是万能药。塞太多不相关的文档进去，反而会降低信噪比，引入新的混乱。所以 RAG 的关键不在于”检索”，而在于精准检索和结果筛选。
2. 结构化 Prompt：给不确定性上约束
信息熵高的本质是”模型不知道该往哪个方向生成”。那我们就用 prompt 把方向限死。
回到林黛玉的例子。如果 prompt 改成：”以下是一道测试题，请判断’林黛玉倒拔垂杨柳’这个说法是否正确，并说明理由。”——这就给模型施加了一个强约束：输出空间从”写一段情节描写”缩小到了”判断正误”。模型很容易就能给出正确答案，因为判断真假比无中生有容易得多——信息熵一下子就降下来了。
再比如，要求模型以 JSON 格式输出、给定输出字段的枚举值、限定回答长度、要求分步骤推理——这些都是在用结构化约束来降低输出空间的不确定性。
3. 工具调用：让模型调用外部能力而非硬猜
算数会出错？让模型调计算器。不知道今天星期几？让模型调日期 API。不确定某个函数的签名？让模型查文档。
工具调用的本质是：把模型不擅长的高熵任务，外包给确定性的外部系统，然后把确定性的结果注入回上下文。模型拿到精确结果后，只需要做它最擅长的事——用自然语言把结果讲清楚。整个过程中，模型始终处于低熵、高信噪比的舒适区。
4. 上下文精简：少即是多
很多人以为上下文越长越好，128K 的窗口恨不得填满。其实正好相反。
上下文窗口就像模型的”工作记忆”。你往里面塞了一大堆跟当前问题无关的对话历史、冗余的系统提示、检索出来但不相关的文档片段，模型就像一个在嘈杂菜市场里试图听清你说话的人——它能听到的有效信息被噪声淹没了。
好的上下文工程会做”减法”：对历史对话做摘要压缩，对检索结果做相关性过滤，对系统提示做精简聚焦。让每一个 token 都是有效信号。
5. 思维链与多步推理：化整为零
一道复杂的推理题，如果让模型一步给出答案，信息熵很高——因为可能的答案空间巨大。但如果引导模型分步骤思考，每一步的输出空间都很小、确定性都很高，最终组合起来就能得到正确答案。
这就像你问一个人”从北京到纽约的最优路线是什么”，如果要求他一口气答出来，很容易出错。但如果拆成”先选交通方式→再选出发机场→再选航线→再选中转站”，每一步的决策都简单明确得多。
思维链的本质，就是用中间步骤不断往上下文注入确定性，把一个大的高熵问题分解成一连串小的低熵问题。
小结
让我们回到最初的那个判断：
幻觉不是 bug，而是概率语言模型在信息不充分时的必然行为。
既然根源在于上下文的信息质量，那解药自然也在上下文里。上下文工程做的事情，说到底就一句话：
在模型生成每一个 token 的那个瞬间，确保它眼前摆着的是低熵、高信噪比、指向明确的上下文。
Prompt Engineering 教你”怎么问问题”，上下文工程教你”怎么准备考场”。
一个准备充分的考场里，学生很难答错题——哪怕这个学生只是一台概率机器。
