最近开发者社区里流传着一个很有意思的视频让 OpenAI 的模型回答一组看似简单的问题表面上一问一答非常流畅但把回答拆开细看会发现模型在关键推理节点上完全跑偏甚至前后矛盾却依然语气笃定。这类内容在英文社区被概括成一句话——“OpenAI just proved AI has no idea what its doing”。直译过来就是“OpenAI 刚刚证明了 AI 并不知道自己在做什么”。很多第一次接触这个结论的开发者会觉得很震撼但长期做大模型应用的人反而觉得这是意料之中当前的大模型本质上是一个概率化文本生成系统它的“流畅”来自大规模语言建模它的“笃定”来自对齐训练而它是否真的“知道自己在做什么”从来就不是训练目标。这篇文章不打算做情绪化讨论而是围绕这个现象做一次技术拆解先讲清楚模型能力边界背后的原理再用 Python 写一组小实验实际观测模型“过度自信但答错”的情况最后给出大模型落地时比较稳妥的工程处理方案。无论你是刚接触大模型开发的新手还是在做 Agent、客服机器人、自动化报告等生产级应用的开发者这篇文章都值得收藏备用。1. 背景这个视频实验暴露了什么问题1.1 现象本身流畅、笃定、但经不起推敲最近几个月开发者社区流传了大量针对大模型的“压力测试”视频和帖子。测试方式通常很简单不考专业知识只问一些接近常识、但需要模型真正确认“前提是否成立”的问题。比较有代表性的几类问题包括反事实推理把物理规则改成相反方向问结果会怎样自指类问题让模型评价自己上一条回答是否正确计数与字符级操作数一个单词里出现了几次某个字母常识边界问题直接询问模型“你真的确定吗”看它会不会修改答案。实验结果通常呈现同一个趋势模型回答的语法非常完整态度非常自信但答案的正确率远远低于它的自信程度。也就是说模型不是“答错了但知道自己可能错”而是“答错了还特别坚定”。这个现象正是标题所说“AI 不知道自己在做什么”的直接证据。注意这里说的“不知道自己在做什么”不是指模型像人类一样有自我意识却故意犯错而是指它在生成机制上缺少一个“我知道自己不知道”的判断通道。1.2 这不是偶然翻车而是系统性现象有些人把这类测试当成“AI 翻车集锦”来看觉得只要换一个更大的模型就能解决。但实际上这类错误不是偶发 bug而是当前技术路线的系统性输出。原因可以拆成三层预训练阶段模型学的是“给定上文预测下一个词元”指令微调阶段模型学的是“跟随人类指令生成人类偏好的回答”对齐阶段模型学着表现出“有用、诚实、无害”的样子但它的诚实是行为层面的不是认知层面的。换句话说模型没有一个独立于语言的“思考内核”它的一切“思考”最后都体现为文本生成。当文本生成足够流畅时我们会在心理上把“流畅”误认为“聪明”把“语气坚定”误认为“有把握”。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_keyos.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( modelmodel, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}, ], temperature0, ) 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, }这段代码做了三件事让模型在回答末尾输出一个置信度数字用temperature0减少随机性观察模型的默认行为把回答内容和置信度分开解析。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 如何解读实验结果如果你按上面的脚本亲测一轮大概率会得出几个结论模型的自然语言回答质量很高几乎不会有语法问题置信度普遍偏高很少出现“我完全没把握”的情况正确率低于置信度也就是过度自信当问题涉及多步计算或反事实条件时错误率明显上升。这些观察与大模型评测领域的公开结论是一致的。简单说模型在“语言组织”维度已经非常强但在“自知之明”维度依然很弱。这也是工程上必须增加外部校验的核心原因。5. 工程实践如何与一个“过度自信”的模型安全协作5.1 定位让模型做生成器而不是决策器在系统设计中不要把大模型当作最终决策者。更合理的分层是大模型负责理解用户意图、生成草稿、组织语言、提取信息规则系统负责校验、计算、权限判断、关键数据查询人工负责最终确认、异常处理。例如自动生成周报时可以让模型生成文本框架但所有数字必须从数据库查询后由程序填充不能允许模型“大概估计”。把不可靠的环节从模型手里拿掉是降低系统性风险最直接的办法。5.2 用 RAG 引入可信事实RAGRetrieval-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( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0, 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( modelmodel, messages[{role: user, content: prompt}], temperature0.8, ) answers.append(resp.choices[0].message.content.strip()) return answers if __name__ __main__: prompt 一个长方形的长是8宽是5面积是多少 ans sample_answers(prompt, n5) counter Counter(ans) for text, count in counter.most_common(): print(f{count} 次: {text})注意自我一致性只能作为辅助判断不能当作绝对标准。因为模型可能在多次采样中都稳定地犯同一个错误尤其是那些它在训练中形成强偏见的题目。5.5 建立回归测试集对 AI 功能做版本升级或提示词修改时一定要准备一个回归测试集。测试集应该包含正常输入边界输入容易触发幻觉的输入反事实或对抗性输入。每次改动后跑一遍观察正确率、格式合规率、置信度分布。这样至少能在发版前发现“某个问题被修好了但另外一批问题变差了”的回归风险。在小团队里这个测试集可以先从 50 条手工用例开始后面逐步补充线上真实用户的高频问题。测试代码本身不要复杂最简单的方式就是像第 4 节那样写一个脚本循环调用模型输出一份统计报告。6. 常见误区与 FAQ6.1 模型说“不知道”就等于有自知之明吗不一定。模型偶尔会说“我无法确认”这通常是因为它的训练数据里有类似表达或者 RLHF 阶段被鼓励在特定话题上保持克制。它不代表模型真的在内部检查了自己的知识边界。实测中同一个模型在不同措辞下可能一个版本说“我不知道”另一个版本就给出详细回答。所以不要用模型是否“承认不知道”来评估它的可靠性要看它在真实业务数据上的校准度。6.2 换更大的模型能根治过度自信吗在一定程度上能缓解但不能根治。更大参数的模型在记忆和推理基准上通常更强但在分布外输入、反事实推理、长链路逻辑上依然会出现过度自信。生产环境不能把可靠性完全押在“换大模型”上。更务实的做法是不换模型的前提下通过 RAG、结构化输出、人工审核把这些风险兜住。6.3 模型“自我纠正”是真正的反思吗不是。当模型在提示词里被要求“检查你的回答再修改”它做的依然是文本生成根据“我刚才的答案 检查指令”重新生成一段文本。这个流程看起来像反思但模型并没有一个独立的验证器来确认新答案更正确。某些时候新答案确实更好某些时候反而会把对的改成错的。所以涉及关键判断时不要依赖“让模型自查”这一招应该用外部程序校验。6.4 Agent 场景下这个问题会更严重吗会更严重。Agent 类应用例如代码生成助手、自动化执行工具会把模型的输出直接转化为操作行为。如果模型自信地生成了一个不存在的函数名Agent 可能就会报错或做出预期之外的动作。所以在 Agent 的架构里建议在“模型生成”和“工具调用”之间加一层工具白名单校验只允许模型调用系统注册过的函数并且对参数做类型和范围检查。这也是目前比较稳妥的工程实践。7. 最佳实践与工程建议7.1 生产环境检查清单如果你正在把大模型接入业务系统建议对照这张清单逐项确认风险点建议做法API Key 泄露使用环境变量或密钥管理服务禁止入库幻觉数据进入业务关键数据用 RAG 或数据库回填不允许模型直接生成用户输入注入对拼接进提示词的不可信内容做边界处理模型输出格式不稳使用 JSON 结构化输出 程序字段校验错误无法定位记录完整输入、输出、检索片段保留日志升级导致行为变化建立回归测试集发版前全量比对7.2 一个可复用的定位原则实际开发中比较推荐的做法是把大模型当作“高智商但低可靠性的实习生”。它适合做初稿、做分类、做信息提取但所有关键环节必须有人或系统复核。这个定位听起来保守却是目前把大模型安全落地的现实方式。它不否定大模型的价值只是把模型放在它真正擅长并且容错率高的位置。7.3 后续可以做些什么如果你打算把本文的测试脚本改造成自己团队的评测工具建议从两类问题入手一类是已有标准答案的事实题用来观察校准度另一类是需要多步推导的反事实题用来观察推理稳定性。把这两类问题自动化每周跑一次比临时用几个 prompt 试效果要有用得多。当模型版本、提示词或业务上下文发生变化时你手里有数据就能快速判断改动到底有没有让 大模型“自信地犯错”背后：原理拆解、Python实测与工程防护
最近开发者社区里流传着一个很有意思的视频让 OpenAI 的模型回答一组看似简单的问题表面上一问一答非常流畅但把回答拆开细看会发现模型在关键推理节点上完全跑偏甚至前后矛盾却依然语气笃定。这类内容在英文社区被概括成一句话——“OpenAI just proved AI has no idea what its doing”。直译过来就是“OpenAI 刚刚证明了 AI 并不知道自己在做什么”。很多第一次接触这个结论的开发者会觉得很震撼但长期做大模型应用的人反而觉得这是意料之中当前的大模型本质上是一个概率化文本生成系统它的“流畅”来自大规模语言建模它的“笃定”来自对齐训练而它是否真的“知道自己在做什么”从来就不是训练目标。这篇文章不打算做情绪化讨论而是围绕这个现象做一次技术拆解先讲清楚模型能力边界背后的原理再用 Python 写一组小实验实际观测模型“过度自信但答错”的情况最后给出大模型落地时比较稳妥的工程处理方案。无论你是刚接触大模型开发的新手还是在做 Agent、客服机器人、自动化报告等生产级应用的开发者这篇文章都值得收藏备用。1. 背景这个视频实验暴露了什么问题1.1 现象本身流畅、笃定、但经不起推敲最近几个月开发者社区流传了大量针对大模型的“压力测试”视频和帖子。测试方式通常很简单不考专业知识只问一些接近常识、但需要模型真正确认“前提是否成立”的问题。比较有代表性的几类问题包括反事实推理把物理规则改成相反方向问结果会怎样自指类问题让模型评价自己上一条回答是否正确计数与字符级操作数一个单词里出现了几次某个字母常识边界问题直接询问模型“你真的确定吗”看它会不会修改答案。实验结果通常呈现同一个趋势模型回答的语法非常完整态度非常自信但答案的正确率远远低于它的自信程度。也就是说模型不是“答错了但知道自己可能错”而是“答错了还特别坚定”。这个现象正是标题所说“AI 不知道自己在做什么”的直接证据。注意这里说的“不知道自己在做什么”不是指模型像人类一样有自我意识却故意犯错而是指它在生成机制上缺少一个“我知道自己不知道”的判断通道。1.2 这不是偶然翻车而是系统性现象有些人把这类测试当成“AI 翻车集锦”来看觉得只要换一个更大的模型就能解决。但实际上这类错误不是偶发 bug而是当前技术路线的系统性输出。原因可以拆成三层预训练阶段模型学的是“给定上文预测下一个词元”指令微调阶段模型学的是“跟随人类指令生成人类偏好的回答”对齐阶段模型学着表现出“有用、诚实、无害”的样子但它的诚实是行为层面的不是认知层面的。换句话说模型没有一个独立于语言的“思考内核”它的一切“思考”最后都体现为文本生成。当文本生成足够流畅时我们会在心理上把“流畅”误认为“聪明”把“语气坚定”误认为“有把握”。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_keyos.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( modelmodel, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}, ], temperature0, ) 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, }这段代码做了三件事让模型在回答末尾输出一个置信度数字用temperature0减少随机性观察模型的默认行为把回答内容和置信度分开解析。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 如何解读实验结果如果你按上面的脚本亲测一轮大概率会得出几个结论模型的自然语言回答质量很高几乎不会有语法问题置信度普遍偏高很少出现“我完全没把握”的情况正确率低于置信度也就是过度自信当问题涉及多步计算或反事实条件时错误率明显上升。这些观察与大模型评测领域的公开结论是一致的。简单说模型在“语言组织”维度已经非常强但在“自知之明”维度依然很弱。这也是工程上必须增加外部校验的核心原因。5. 工程实践如何与一个“过度自信”的模型安全协作5.1 定位让模型做生成器而不是决策器在系统设计中不要把大模型当作最终决策者。更合理的分层是大模型负责理解用户意图、生成草稿、组织语言、提取信息规则系统负责校验、计算、权限判断、关键数据查询人工负责最终确认、异常处理。例如自动生成周报时可以让模型生成文本框架但所有数字必须从数据库查询后由程序填充不能允许模型“大概估计”。把不可靠的环节从模型手里拿掉是降低系统性风险最直接的办法。5.2 用 RAG 引入可信事实RAGRetrieval-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( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0, 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( modelmodel, messages[{role: user, content: prompt}], temperature0.8, ) answers.append(resp.choices[0].message.content.strip()) return answers if __name__ __main__: prompt 一个长方形的长是8宽是5面积是多少 ans sample_answers(prompt, n5) counter Counter(ans) for text, count in counter.most_common(): print(f{count} 次: {text})注意自我一致性只能作为辅助判断不能当作绝对标准。因为模型可能在多次采样中都稳定地犯同一个错误尤其是那些它在训练中形成强偏见的题目。5.5 建立回归测试集对 AI 功能做版本升级或提示词修改时一定要准备一个回归测试集。测试集应该包含正常输入边界输入容易触发幻觉的输入反事实或对抗性输入。每次改动后跑一遍观察正确率、格式合规率、置信度分布。这样至少能在发版前发现“某个问题被修好了但另外一批问题变差了”的回归风险。在小团队里这个测试集可以先从 50 条手工用例开始后面逐步补充线上真实用户的高频问题。测试代码本身不要复杂最简单的方式就是像第 4 节那样写一个脚本循环调用模型输出一份统计报告。6. 常见误区与 FAQ6.1 模型说“不知道”就等于有自知之明吗不一定。模型偶尔会说“我无法确认”这通常是因为它的训练数据里有类似表达或者 RLHF 阶段被鼓励在特定话题上保持克制。它不代表模型真的在内部检查了自己的知识边界。实测中同一个模型在不同措辞下可能一个版本说“我不知道”另一个版本就给出详细回答。所以不要用模型是否“承认不知道”来评估它的可靠性要看它在真实业务数据上的校准度。6.2 换更大的模型能根治过度自信吗在一定程度上能缓解但不能根治。更大参数的模型在记忆和推理基准上通常更强但在分布外输入、反事实推理、长链路逻辑上依然会出现过度自信。生产环境不能把可靠性完全押在“换大模型”上。更务实的做法是不换模型的前提下通过 RAG、结构化输出、人工审核把这些风险兜住。6.3 模型“自我纠正”是真正的反思吗不是。当模型在提示词里被要求“检查你的回答再修改”它做的依然是文本生成根据“我刚才的答案 检查指令”重新生成一段文本。这个流程看起来像反思但模型并没有一个独立的验证器来确认新答案更正确。某些时候新答案确实更好某些时候反而会把对的改成错的。所以涉及关键判断时不要依赖“让模型自查”这一招应该用外部程序校验。6.4 Agent 场景下这个问题会更严重吗会更严重。Agent 类应用例如代码生成助手、自动化执行工具会把模型的输出直接转化为操作行为。如果模型自信地生成了一个不存在的函数名Agent 可能就会报错或做出预期之外的动作。所以在 Agent 的架构里建议在“模型生成”和“工具调用”之间加一层工具白名单校验只允许模型调用系统注册过的函数并且对参数做类型和范围检查。这也是目前比较稳妥的工程实践。7. 最佳实践与工程建议7.1 生产环境检查清单如果你正在把大模型接入业务系统建议对照这张清单逐项确认风险点建议做法API Key 泄露使用环境变量或密钥管理服务禁止入库幻觉数据进入业务关键数据用 RAG 或数据库回填不允许模型直接生成用户输入注入对拼接进提示词的不可信内容做边界处理模型输出格式不稳使用 JSON 结构化输出 程序字段校验错误无法定位记录完整输入、输出、检索片段保留日志升级导致行为变化建立回归测试集发版前全量比对7.2 一个可复用的定位原则实际开发中比较推荐的做法是把大模型当作“高智商但低可靠性的实习生”。它适合做初稿、做分类、做信息提取但所有关键环节必须有人或系统复核。这个定位听起来保守却是目前把大模型安全落地的现实方式。它不否定大模型的价值只是把模型放在它真正擅长并且容错率高的位置。7.3 后续可以做些什么如果你打算把本文的测试脚本改造成自己团队的评测工具建议从两类问题入手一类是已有标准答案的事实题用来观察校准度另一类是需要多步推导的反事实题用来观察推理稳定性。把这两类问题自动化每周跑一次比临时用几个 prompt 试效果要有用得多。当模型版本、提示词或业务上下文发生变化时你手里有数据就能快速判断改动到底有没有让