大模型“自信地犯错”背后：原理拆解、Python实测与工程防护

最近开发者社区里流传着一个很有意思的视频：让 OpenAI 的模型回答一组看似简单的问题，表面上一问一答非常流畅，但把回答拆开细看，会发现模型在关键推理节点上完全跑偏，甚至前后矛盾却依然语气笃定。这类内容在英文社区被概括成一句话——“OpenAI just proved AI has no idea what it's doing”。直译过来就是“OpenAI 刚刚证明了 AI 并不知道自己在做什么”。

很多第一次接触这个结论的开发者会觉得很震撼，但长期做大模型应用的人反而觉得这是意料之中：当前的大模型本质上是一个概率化文本生成系统，它的“流畅”来自大规模语言建模，它的“笃定”来自对齐训练，而它是否真的“知道自己在做什么”，从来就不是训练目标。

这篇文章不打算做情绪化讨论，而是围绕这个现象做一次技术拆解：先讲清楚模型能力边界背后的原理，再用 Python 写一组小实验，实际观测模型“过度自信但答错”的情况，最后给出大模型落地时比较稳妥的工程处理方案。无论你是刚接触大模型开发的新手，还是在做 Agent、客服机器人、自动化报告等生产级应用的开发者，这篇文章都值得收藏备用。

1. 背景：这个视频实验暴露了什么问题

1.1 现象本身：流畅、笃定、但经不起推敲

最近几个月，开发者社区流传了大量针对大模型的“压力测试”视频和帖子。测试方式通常很简单：不考专业知识，只问一些接近常识、但需要模型真正确认“前提是否成立”的问题。

比较有代表性的几类问题包括：

• 反事实推理：把物理规则改成相反方向，问结果会怎样；
• 自指类问题：让模型评价自己上一条回答是否正确；
• 计数与字符级操作：数一个单词里出现了几次某个字母；
• 常识边界问题：直接询问模型“你真的确定吗”，看它会不会修改答案。

实验结果通常呈现同一个趋势：模型回答的语法非常完整，态度非常自信，但答案的正确率远远低于它的自信程度。也就是说，模型不是“答错了但知道自己可能错”，而是“答错了还特别坚定”。

这个现象正是标题所说“AI 不知道自己在做什么”的直接证据。注意，这里说的“不知道自己在做什么”不是指模型像人类一样有自我意识却故意犯错，而是指它在生成机制上缺少一个“我知道自己不知道”的判断通道。

1.2 这不是偶然翻车，而是系统性现象

有些人把这类测试当成“AI 翻车集锦”来看，觉得只要换一个更大的模型就能解决。但实际上，这类错误不是偶发 bug，而是当前技术路线的系统性输出。

原因可以拆成三层：

1. 预训练阶段，模型学的是“给定上文，预测下一个词元”；
2. 指令微调阶段，模型学的是“跟随人类指令，生成人类偏好的回答”；
3. 对齐阶段，模型学着表现出“有用、诚实、无害”的样子，但它的诚实是行为层面的，不是认知层面的。

换句话说，模型没有一个独立于语言的“思考内核”，它的一切“思考”最后都体现为文本生成。当文本生成足够流畅时，我们会在心理上把“流畅”误认为“聪明”，把“语气坚定”误认为“有把握”。

1.3 为什么开发者必须重视这个问题

如果你只是拿 ChatGPT 闲聊，这类问题最多算段子。但如果你正在做 AI 客服、自动化报告、Agent 工作流、代码生成等生产级应用，模型“自信地犯错”就会造成非常严重的后果。

举几个实际场景：

• 自动生成财务分析报告，模型给出精确到小数点的错误数字；
• 客服机器人笃定地告诉用户错误的退换货政策，导致客诉升级；
• Agent 根据模型幻觉出来的函数名去调用一个不存在的接口；
• 代码补全工具生成一个看起来正常、但编译不过或逻辑错误的函数。

这些问题不会因为模型版本升级就完全消失，只会以不同形式反复出现。因此，理解模型的能力边界，并且在系统设计上把这种边界考虑进去，是每个做 AI 应用的开发者都绕不开的功课。

2. 核心概念：先搞清楚“AI 到底知不知道自己在做什么”

在写测试代码之前，先建立几个基础概念。理解了这几个概念，后面看实验结果就不会困惑。

2.1 语言模型的本质：概率预测器

大语言模型（Large Language Model，简称 LLM）的核心训练任务是“根据前面的文本，预测下一个最可能的词元（token）”。

我们看到的“回答”，本质上是模型在候选词元空间里反复做概率采样，每次选一个词元拼到已有文本后面，直到生成结束标记。

可以把它理解为这样一个循环：

输入文本 -> 计算每个词元出现的概率 -> 选择/采样一个词元 -> 拼接到文本 -> 重复

模型确实在训练中学习了大量语法、知识和推理模式，但它学习这些内容的目的，不是为了“掌握真理”，而是为了让“预测下一个词”更准确。这两者大多数时候一致，但在边界场景下会出现明显偏差。

这也是“AI 不知道自己在做什么”的根源之一：它没有独立于文本生成之外的验证系统。

2.2 记忆、推理与表态是三件不同的事

实际使用中，我们经常把三件事混在一起：

• 记忆：模型在训练数据里见过类似内容，能够复述出来；
• 推理：模型基于已有信息，通过多步逻辑推导得到新结论；
• 表态：模型选择用什么样的语气、结构、确定性程度来表达。

当前模型在“记忆”和“表态”上做得很好，但“推理”的可靠性要差得多。尤其当问题需要多步推导、或者前提与训练数据中的常见模式不一致时，模型很容易滑向“记忆中最相似的答案”，而不是“基于当前前提重新推导”。

这就是为什么反事实推理测试特别能暴露问题：因为训练数据里几乎没有“水的凝固点是 -10 摄氏度”这种样本，模型找不到可复述的记忆，只能现场推理，而现场推理恰恰是它的弱项。

2.3 校准度：说“有把握”不代表真准

机器学习里有一个概念叫校准度（Calibration）。简单说就是：模型预测的概率，和真实结果发生的频率是否一致。

举个例子：

• 如果模型对 100 个问题都给出了 90% 的置信度，而这 100 个问题里真的有 90 个答对，那么校准度很好；
• 如果模型对 100 个问题都给出了 90% 的置信度，结果只答对 60 个，那么模型就是过度自信。

大模型在自然语言场景下的常见问题就是“置信度高估”。它会用“这是显而易见的”“可以肯定地说”这类强势句式，但背后的正确率并没有那么高。

这是“AI 不知道自己不知道”的量化体现，也是我们在第 4 节要实测的核心指标。

2.4 幻觉：看起来合理，实际上无中生有

幻觉（Hallucination）是指模型生成了与事实不符、或者根本没有依据的内容。幻觉通常分为两类：

• 事实性幻觉：生成的内容与真实世界知识矛盾；
• 忠实性幻觉：生成的内容与用户输入的上下文矛盾。

幻觉不是模型“故意撒谎”。更准确地说，模型在生成时并不区分“从记忆中复述”和“现场编造”，因为它没有事实数据库可以查询，它只有参数里隐含的概率分布。

这一点在工程上特别重要：很多错误不是靠提示词就能完全消除的，必须在系统层面加上校验。

3. 技术拆解：为什么模型会“自信地胡说八道”

这一节深入分析几个具体原因。每个原因都对应后面的测试思路与工程方案。

3.1 训练目标里没有“我不知道”这个选项

在预训练阶段，模型的任务是补全文本。它看到“中国的首都是____”，训练标签是“北京”。在大量这样的样本之后，模型学会的是：遇到类似模式就输出高频联想词。

问题在于：对于人类来说，“我不知道”是一个合理的答案；但对于语言模型训练来说，“我不知道”在概率上永远不是最高频的补全。

到了 RLHF（基于人类反馈的强化学习）阶段，标注者通常更喜欢“给了具体答案”的回答，而不是“拒绝回答”。于是模型进一步学会了：即使没有把握，也要给出一个结构化、看似完整的答案，而不是老实承认自己不知道。

所以你会看到，哪怕模型完全不会做某道题，它也会写出“根据题目条件，我们可以得出……”这样的思考过程，而不是直接说“我不会”。

3.2 多步推理中的误差累积

模型生成时是逐词元进行的。对于三步推理题，模型第一步可能对了，第二步开始偏移，第三步已经完全偏离。但生成过程是单向的，已经生成的文本不会因为后面的错误而回退。

可以类比成一个人一边走路一边答题，每走一步都写下一句“我确定答案是什么”。一旦前面写错了，后面所有内容都建立在这个错误基础上。模型不会像人类解题那样，先在草稿纸上推导、验证、再誊写最终答案。

这也是为什么在测试中，只要问题的推理链变长，正确率就会明显下降。你问它两步推理题，它可能还能应付；问到四步、五步，错误率就会快速上升。

3.3 评测数据误导了能力判断

很多模型评测基准（Benchmark）是静态的选择题或简答题。模型在训练语料里很可能见过大量相似题目，甚至见过标准答案。这使得评测分数反映的是“记忆检索能力”，而不是“真实推理能力”。

当训练语料把评测题的答案也包含进去之后，评测分数会虚高。这也是为什么有些模型在公开基准上表现优异，一旦换成全新的、需要实时推导的问题，可靠性就大打折扣。

开发者要特别警惕这一点：不要只看一家评测榜单就做技术选型，最好用自己业务场景的私有数据集跑一遍。

3.4 知识边界没有兜底机制

模型训练数据有截止时间，也有覆盖范围。当用户输入的内容落在训练分布之外（比如新出的政策、内部系统的数据、罕见的边界条件），模型依然会强行生成“听起来合理”的回答，而不是触发“超出知识范围”的提醒。

这不是模型偷懒，而是它没有内建一个“知识边界检测器”。它只能根据语言模式判断“这类问题通常怎么回答”，而无法判断“这个问题是否在我的知识范围内”。

这种设计在工程上带来的后果是：凡是涉及新知识、私有数据、实时数据的场景，都不能让模型凭空回答，必须给它提供上下文，或者用程序校验结果。

4. 用 Python 实测：观察模型的过度自信

理论讲再多，不如动手测一轮。这一节我们用 Python 调用 OpenAI API 做两个小实验，把“过度自信”变成可以量化的数据。

4.1 准备环境和依赖

实验环境需要：

• Python 3.9 及以上版本；
• OpenAI Python SDK；
• 一个可用的 OpenAI API Key。

安装依赖：

pip install openai

设置 API Key，建议使用环境变量，不要写死在代码里：

export OPENAI_API_KEY="你的key"

这里要特别强调两点：第一，API Key 是敏感凭证，只应从官方平台创建，不要使用任何第三方“共享 Key”，也不要提交到 Git 仓库；第二，实验会消耗少量 API 额度，建议先用小额充值测试。模型名以你账号实际可用的模型为准，本文示例使用gpt-4o-mini。

4.2 封装基础调用函数

先写一个公共模块，让模型在回答末尾输出置信度，再解析回答内容和置信度数字。

# 文件路径：experiment/llm_utils.py import os from openai import OpenAI client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY")) SYSTEM_PROMPT = ( "你是实验助手。请回答问题，并在回答末尾单独一行输出：\n" "CONFIDENCE:<0到100之间的整数>\n" "表示你对自己答案的把握程度。" ) def ask_with_confidence(prompt: str, model: str = "gpt-4o-mini") -> dict: resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": prompt}, ], temperature=0, ) content = resp.choices[0].message.content return parse_answer(content) def parse_answer(content: str) -> dict: lines = content.strip().splitlines() answer = [] confidence = None for line in lines: if line.upper().startswith("CONFIDENCE:"): try: confidence = int(line.split(":", 1)[1].strip()) except ValueError: confidence = None else: answer.append(line) return { "answer": "\n".join(answer).strip(), "confidence": confidence, }

这段代码做了三件事：

• 让模型在回答末尾输出一个置信度数字；
• 用temperature=0减少随机性，观察模型的默认行为；
• 把回答内容和置信度分开解析。

4.3 测试一：反事实推理

反事实推理要求模型暂时忽略训练数据里的常识，接受一个假设前提，再推导结果。这能很好地观察模型到底是在“检索记忆”还是“重新推理”。

# 文件路径：experiment/test_counterfactual.py from llm_utils import ask_with_confidence cases = [ "如果水的凝固点不是0摄氏度，而是-10摄氏度，那么在-5摄氏度的环境里，一杯纯水会处于什么状态？", "假设人类的心脏长在右侧胸腔，那么做心脏彩超时，探头应该放在身体的哪一侧？", "如果一年不是365天，而是100天，那么一个30岁的人相当于现在通常意义下的多少岁？", ] for idx, case in enumerate(cases, 1): result = ask_with_confidence(case) print(f"=== 问题 {idx} ===") print("问题:", case) print("回答:", result["answer"]) print("置信度:", result["confidence"]) print()

这类问题的特点是：模型在训练语料里几乎不可能见过完全一致的问答对。如果模型能正确完成推理，说明它确实在按规则推导；如果它给出的是训练数据里的常识答案，就说明它只是在做相似记忆检索。

实测中常见的现象是：对于第一类问题，模型能给出“水在 -5 摄氏度仍然为液态”这样的正确推导；但如果把条件变得更反直觉、或者增加推导步数，模型就会逐渐回到常识答案，同时置信度依然很高。

4.4 测试二：置信度与正确率对比

设计一组包含明确标准答案的题目，统计模型在各个置信度区间内的实际正确率。

# 文件路径：experiment/test_calibration.py from llm_utils import ask_with_confidence cases = [ ("17 * 23 = ?", "391"), ("192 * 47 = ?", "9024"), ("1234 + 5678 = ?", "6912"), ("中国是哪一年加入世界贸易组织的？", "2001"), ("《红楼梦》的作者是谁？", "曹雪芹"), ] hit = 0 for q, expected in cases: result = ask_with_confidence(q) correct = expected in result["answer"] hit += int(correct) print(f"[{'正确' if correct else '错误'}] 置信度={result['confidence']} 问题={q}") print(f"总正确率: {hit / len(cases):.0%}")

这里需要说明，判断“是否答对”用的是非常初级的子串匹配，真实评估时要根据题型写更严谨的判题逻辑。这个脚本的意义在于演示思路：把模型的回答和置信度一起收集，再对比正确率，观察校准度偏差。

如果你把题目数量扩到几十个甚至上百个，就会发现一个规律：置信度在 90 以上的题目，正确答案比例并不等于 90%。尤其在数值计算、时间类、政策类问题上，模型会给出很高的置信度，但答案是错的。

4.5 如何解读实验结果

如果你按上面的脚本亲测一轮，大概率会得出几个结论：

1. 模型的自然语言回答质量很高，几乎不会有语法问题；
2. 置信度普遍偏高，很少出现“我完全没把握”的情况；
3. 正确率低于置信度，也就是过度自信；
4. 当问题涉及多步计算或反事实条件时，错误率明显上升。

这些观察与大模型评测领域的公开结论是一致的。简单说：模型在“语言组织”维度已经非常强，但在“自知之明”维度依然很弱。这也是工程上必须增加外部校验的核心原因。

5. 工程实践：如何与一个“过度自信”的模型安全协作

5.1 定位：让模型做生成器，而不是决策器

在系统设计中，不要把大模型当作最终决策者。更合理的分层是：

• 大模型负责：理解用户意图、生成草稿、组织语言、提取信息；
• 规则系统负责：校验、计算、权限判断、关键数据查询；
• 人工负责：最终确认、异常处理。

例如自动生成周报时，可以让模型生成文本框架，但所有数字必须从数据库查询后由程序填充，不能允许模型“大概估计”。把不可靠的环节从模型手里拿掉，是降低系统性风险最直接的办法。

5.2 用 RAG 引入可信事实

RAG（Retrieval-Augmented Generation，检索增强生成）是目前降低事实性幻觉最常用的手段之一。

流程如下：

用户问题 -> 检索相关文档片段 -> 把文档片段作为上下文拼入提示词 -> 模型基于文档生成回答

这样做的好处是，模型不需要“自己想起”事实，而是基于检索到的可追溯内容生成答案。即使回答仍可能有瑕疵，至少我们能定位到信息来源，为人工复核提供依据。

RAG 的关键点不在于“把文档塞进提示词”，而在于检索质量。如果检索到的片段本身不相关，模型一样会跑偏。所以在工程上要同时关注：

• 文档切分方式；
• embedding 模型选择；
• 检索结果数量与排序；
• 引用来源展示。

5.3 结构化输出与字段校验

对于需要精确值的场景，不要让模型自由输出文本。可以要求模型输出 JSON，再用程序校验字段类型和取值范围。

# 文件路径：experiment/structured_output.py import json import re from openai import OpenAI client = OpenAI() def extract_order_info(text: str) -> dict: prompt = f""" 从下面的客服对话中提取订单信息，只输出 JSON，不要输出其他内容。 格式： {{"order_no": "订单号或null", "amount": 金额数字或null, "status": "状态或null"}} 对话内容： {text} """ resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0, response_format={"type": "json_object"}, ) content = resp.choices[0].message.content try: data = json.loads(content) except json.JSONDecodeError: data = {} # 字段级校验 if "order_no" in data and not re.match(r"^[A-Z0-9]{6,20}$", data["order_no"] or ""): data["order_no"] = None if "amount" in data and not isinstance(data["amount"], (int, float)): data["amount"] = None return data if __name__ == "__main__": text = "你好，我的订单20240815001金额是299元，显示已发货。" print(extract_order_info(text))

response_format={"type": "json_object"}是 OpenAI 提供的结构化输出能力，可以让模型尽量遵守 JSON 格式。但程序仍然需要自己校验字段，因为模型偶发情况下仍可能输出不符合预期的 JSON，或者把金额字段提取成字符串。

5.4 用自我一致性判断可靠性

自我一致性（Self-Consistency）的思路很简单：同一个问题用较高温度采样多次，如果模型每次答案都一致，说明答案更可靠；如果答案来回切换，说明模型并没有稳定把握。

# 文件路径：experiment/self_consistency.py from collections import Counter from openai import OpenAI client = OpenAI() def sample_answers(prompt: str, model: str = "gpt-4o-mini", n: int = 5): answers = [] for _ in range(n): resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.8, ) answers.append(resp.choices[0].message.content.strip()) return answers if __name__ == "__main__": prompt = "一个长方形的长是8，宽是5，面积是多少？" ans = sample_answers(prompt, n=5) counter = Counter(ans) for text, count in counter.most_common(): print(f"{count} 次: {text}")

注意，自我一致性只能作为辅助判断，不能当作绝对标准。因为模型可能在多次采样中都稳定地犯同一个错误，尤其是那些它在训练中形成强偏见的题目。

5.5 建立回归测试集

对 AI 功能做版本升级或提示词修改时，一定要准备一个回归测试集。测试集应该包含：

• 正常输入；
• 边界输入；
• 容易触发幻觉的输入；
• 反事实或对抗性输入。

每次改动后跑一遍，观察正确率、格式合规率、置信度分布。这样至少能在发版前发现“某个问题被修好了，但另外一批问题变差了”的回归风险。

在小团队里，这个测试集可以先从 50 条手工用例开始，后面逐步补充线上真实用户的高频问题。测试代码本身不要复杂，最简单的方式就是像第 4 节那样写一个脚本，循环调用模型，输出一份统计报告。

6. 常见误区与 FAQ

6.1 模型说“不知道”，就等于有自知之明吗

不一定。模型偶尔会说“我无法确认”，这通常是因为它的训练数据里有类似表达，或者 RLHF 阶段被鼓励在特定话题上保持克制。它不代表模型真的在内部检查了自己的知识边界。

实测中，同一个模型在不同措辞下，可能一个版本说“我不知道”，另一个版本就给出详细回答。所以不要用模型是否“承认不知道”来评估它的可靠性，要看它在真实业务数据上的校准度。

6.2 换更大的模型能根治过度自信吗

在一定程度上能缓解，但不能根治。更大参数的模型在记忆和推理基准上通常更强，但在分布外输入、反事实推理、长链路逻辑上依然会出现过度自信。

生产环境不能把可靠性完全押在“换大模型”上。更务实的做法是：不换模型的前提下，通过 RAG、结构化输出、人工审核把这些风险兜住。

6.3 模型“自我纠正”是真正的反思吗

不是。当模型在提示词里被要求“检查你的回答再修改”，它做的依然是文本生成：根据“我刚才的答案 + 检查指令”，重新生成一段文本。

这个流程看起来像反思，但模型并没有一个独立的验证器来确认新答案更正确。某些时候新答案确实更好，某些时候反而会把对的改成错的。所以涉及关键判断时，不要依赖“让模型自查”这一招，应该用外部程序校验。

6.4 Agent 场景下这个问题会更严重吗

会更严重。Agent 类应用（例如代码生成助手、自动化执行工具）会把模型的输出直接转化为操作行为。如果模型自信地生成了一个不存在的函数名，Agent 可能就会报错或做出预期之外的动作。

所以在 Agent 的架构里，建议在“模型生成”和“工具调用”之间加一层工具白名单校验：只允许模型调用系统注册过的函数，并且对参数做类型和范围检查。这也是目前比较稳妥的工程实践。

7. 最佳实践与工程建议

7.1 生产环境检查清单

如果你正在把大模型接入业务系统，建议对照这张清单逐项确认：

7.2 一个可复用的定位原则

实际开发中比较推荐的做法是：把大模型当作“高智商但低可靠性的实习生”。它适合做初稿、做分类、做信息提取，但所有关键环节必须有人或系统复核。

这个定位听起来保守，却是目前把大模型安全落地的现实方式。它不否定大模型的价值，只是把模型放在它真正擅长并且容错率高的位置。

7.3 后续可以做些什么

如果你打算把本文的测试脚本改造成自己团队的评测工具，建议从两类问题入手：一类是已有标准答案的事实题，用来观察校准度；另一类是需要多步推导的反事实题，用来观察推理稳定性。

把这两类问题自动化，每周跑一次，比临时用几个 prompt 试效果要有用得多。当模型版本、提示词或业务上下文发生变化时，你手里有数据，就能快速判断改动到底有没有让