最近一年“模型变笨了”这种抱怨就没断过。隔三岔五就有人截图说 ChatGPT 的回答开始胡说八道、前言不搭后语连小学算术都能算错。可你问具体哪些任务变差了、差到什么程度大多数人又说不清只能回一句“感觉不对”。我自己的看法是如果你想确定模型是不是真的降智不能靠“感觉”要靠“可复现的检测”。这篇就把我常用的四种快速检测方法完整拆给你看每个方法怎么操作、怎么判读、容易踩什么坑都会讲到。就算你不了解模型原理照着跑一遍也能在十分钟内得到比较靠谱的结论。1. 为什么大家都在说“降智”——先把检测基准弄清楚1.1 什么是降智准确说是能力波动“降智”这个词很形象但它不是一个严谨的技术指标。我在实际测试中理解的降智是模型在部分任务上的表现明显低于它历史最佳水平而且不是某一次偶发错误是在重复测试后依然稳定变差。这种波动可以体现在很多维度长文记忆丢失、逻辑推理中断、知识时效性退化、多轮对话前后矛盾还有回答风格变得机械。但这里有个前提容易被忽略不同时间点、不同入口看到的模型表现可能来自不同版本。模型厂商经常做小版本升级今天回答你的可能已经不是昨天那个模型。所谓“降智”有时候是版本回退有时候是负载高峰导致的推理不稳定也有时候是安全策略调整之后模型变得不敢多说话。把这些情况统统叫作降智其实不够准确但对普通用户来说你关心的不是版本号而是结果好不好用。所以检测的核心目标就是在不确定怎么变的情况下用一组固定题目反复测看它的能力水位是否有明显下滑。1.2 四种方法背后的检测逻辑既然要检测题目设计就不能随意。我推荐的四种方法分别盯住模型的四个不同能力面长程记忆能力、数理逻辑推理能力、知识时效性、逻辑一致性。这四块恰恰是模型在日常使用中最常被感知、也最容易退化的维度。为什么选这四个首先是长程记忆它直接对应多轮对话体验聊着聊着就忘事儿是降智最典型的表现。其次是数理逻辑这类任务有唯一正确答案可重复性最强模型强就是强、弱就是弱不容易被主观判断干扰。第三是知识时效性模型的知识有截止日期一旦能力下滑它更容易给出模糊、过时甚至凭空编造的信息。第四是逻辑一致性降智后的模型会变得更爱“讨好”用户你质疑它它就认错你诱导它它就顺着说稍微设计一点矛盾它就开始糊涂。这四个维度互相独立却又覆盖了日常使用的大部分场景。后面每一节我会给出一套可以直接抄的测试方法包含提示词模板、判读标准、复测次数和常见坑点。2. 方法一用“编故事连环提问”测长程记忆能力2.1 具体操作我一直在用的测试模板长程记忆测试的核心不是“让它记住一句话”而是“让它在连续多轮对话里准确调动前面埋下的多个信息点”。我会在开头给出一段模拟人物设定然后连续问五到六个问题每个问题都依赖前面的细节。比如我常用的提示词模板是这样的请记住以下信息小张是一名项目经理负责“某跨平台系统”开发团队有五个人数据库工程师、前端开发、后端开发、测试、UI设计。项目分三个阶段进行第一周做需求评审第三周做界面联调第五周提交测试报告。有一个风险点数据库工程师在第四周要请假三天。接下来我会连续提问你可以随时查考前面的信息。然后依次问项目团队里有哪几个人第二阶段做什么数据库工程师请假会影响第几周的工作如果想让测试提前到第四周开始需要和谁协调小张要在第五周提交什么全部回答后前三轮都没问题的模型通常会在第四、五轮出问题。原因是信息点越多、间隔越远模型越容易混淆或遗漏。降智严重的模型表现很典型回答越来越简短、突然改口、或者把“测试报告”错记成“测试计划”。我会把这些差别原样记录下来作为降智判断依据。2.2 判断标准与可疑信号判定是否算降智我一般看三个信号。一个信号是细节丢失。前期还记得数据库工程师请假的事问到第三轮开始含糊其辞说“好像有谁请假但记不清了”这种情况偶尔出现可以理解但如果每轮测试都这样那就说明长程上下文利用能力有明显问题。第二个信号是张冠李戴。把测试的阶段记错了把团队人员数量说错了这类错误属于信息污染往往出现在模型上下文管理出现异常时。第三个信号是回答风格突变。前一秒还在用详细列点的口吻回答后一秒突然变得极简只剩一句话。这不一定证明降智但结合内容错误大概率能说明当前的推理链路不太稳定。如果一轮测试出现一个以上的信号我会把可疑等级提高一档然后再用同一套题复测三次。三次里有一次出现同类错误属于波动三次里至少有两次都错我认为就可以认定能力下滑了。2.3 避坑心得同样的题目至少复测三次在我自己的测试里最容易犯的错误是拿一套新题只测一次就下结论。模型是概率输出同样的提示词每次生成都不一样个别一次的错误完全可能是随机波动并不代表整体降智。尤其是长程记忆这类主观性较强的测试必须通过重复来消除运气成分。我有两个具体建议第一同一套题连续跑三次每次之间隔一小段时间比如十几分钟。第二三次测试里答案完全正确但措辞变化也属于正常如果三次里结构都错同一种类型才算找到了稳定的问题模式。还需要注意一个冷知识模型对超长上下文的处理会随着整个输入内容的长度变化而变化。你的测试如果塞满了无关背景它有可能把注意力分散掉。所以模板信息要尽量精简别额外加一堆修饰语和无关数据让关键信息之间的间隔更短这样测出来的才是“正常状态下的记忆水平”。3. 方法二用数理逻辑题测推理链路稳定性3.1 设计一道不会被“背题”污染的算术题网络上的经典逻辑题、鸡兔同笼、约会问题模型很可能已经在训练数据里见过无数遍。你测试的时候它可能是背答案而不是真正推理。所以我的建议是自己现编题目保证题目结构简单、计算步骤明确但组合方式稍微绕一点点。举个例子一家文创店销售两款明信片A款每套卖三张、共十二元B款每套卖五张、共二十元小王一共买了四套花了五十六元请问他买的B款套数是多少这类题目网上很难撞到一模一样的原题同时它需要列方程或逐步试算能观察模型的步骤是否完整。正常的模型会先设未知数列出一个二元方程比如A套数加B套数等于四12A加20B等于56然后解得B等于一。降智版本用各种方式绕圈有的直接说答案却没有任何步骤有的列出错误方程有的算到一半忽然换了一种价格假设。我更建议把注意力放在步骤完整性上而不是只看最终数字。因为逻辑链短的模型即使答案对了也常会跳步或乱编中间推导。如果你想加大难度可以在题目后面加一句请分步骤说明并且在每一步后面写上使用了哪个已知条件。这个附加要求能逼着模型暴露它的推理过程。降智模型往往会在这里露出马脚比如明明没用到某个条件却说自己调用了它。3.2 代码类测试与可复现验证数理题之外代码题是另一个非常可靠的探针。因为它有硬性可验证标准代码能不能跑、输出对不对。我会用非常简短的自然语言出题比如请写一个函数输入一个字符串列表返回每个字符串的长度并按照长度从大到小排序如果长度相同则按字母顺序排序。这个问题不涉及复杂框架几乎任何正式版本都能完成但推理链路不稳时输出会变得非常拧巴。降智模型写出来的代码经常出现三种问题第一忘了长度相同时的次排序条件第二用了一个莫名其妙的 lambda 嵌套逻辑是对的但复杂度过高第三给出的解释和代码不一致注释说“先按字母排”代码实际却只跑了长度排序。测代码题还有额外好处可以把代码复制到本地跑一遍输出结果对不对一目了然。我建议每次测试时固定同一道题跑完后记录代码是否可直接执行、执行结果是否符合预期再对比之前几次的记录就能看出稳定性的变化。代码题适合在长程记忆测试之后做因为两者能覆盖模型能力的不同侧面。3.3 避坑心得别让它用计算器和现成库我踩过最深的坑是让模型随便调用现成库或者计算工具。你可以让它手算或者只允许它写纯逻辑代码禁止用外部库。我在题目里会明确写请直接手算不要使用任何工具写代码时不要使用排序库请自己实现排序逻辑。这样做不是想让它写出工程级方案而是想观察它内部推理是否健康。另一个容易被忽略的点是代码题的模型输出可能因为环境配置、版本差异而不同。你在自己电脑上跑通的结果换一个环境可能就报错。所以做代码题检测时最好提前固定语言版本比如 Python 3.12并且用最简单的运行方式不要引入虚拟环境依赖。否则你可能把无关的报错误判成模型降智那就太冤了。4. 方法三用带时间锚点的知识题测知识新鲜度4.1 为什么时间锚点能暴露模型状态模型的知识是有保质期的。它训练完成之后世界上的新事件、新标准、新工具它都不太清楚。所谓“知识时效性检测”就是用它训练截止日之后的新信息来试它。如果它表现正常说明至少已经完成了新知识的更新如果它表现得极其含糊、年代错乱或者直接编造细节那就说明它当前内部检索和知识组织出了比较大的问题这就是我们所说的“降智”。但这里要特别说明一个容易误判的地方很多用户问模型一个最新事件模型答不上来或者乱编这并不一定是降智可能是它训练数据的客观时效不足。所以时间锚点的核心作用不是测试它知不知道某个新事件而是测试它“面对未知知识时是否还能保持清醒的判断力”。正常模型如果不知道它会明确说训练数据截止日期、无法确认最新情况降智模型往往会编一个听上去合理的日期、人名和数据装作它见过。4.2 一组安全可靠的时间类问题模板为了既能测出时效性又避免涉及具体争议我通常不会问真实热点事件而是问行业里相对中性的变化。比如请举例说明某行业在2023年之后出现的一个新趋势并说明这个趋势可能带来哪些影响。再比如假设现在是2025年请列举一个你在训练数据中没有具体信息、但根据逻辑可以推断的行业发展方向并用“不确定”标注你的推测。这就是时间锚点的一种安全用法不是考事实而是考“模型是否清楚自己的知识边界”。降智模型会倾向于把推测说得斩钉截铁好像他真的看过相关资料状态正常的模型则会给出层次清晰的回答指出哪些是确定信息、哪些是推测、哪些需要去查阅最新资料。我建议大家测试时用这类中性的科普、技术、行业问题不要用容易引发争议的时事以免把“模型不知道”和“模型立场不对”混为一谈。4.3 避坑心得答案必须每次都人工核验知识题有一个硬伤如果你自己不知道正确答案你就没法判断模型说错了。所以我每次做时间锚点测试都会提前花钱花时间把标准答案查好甚至用两个独立的信息源交叉核对再拿着标准答案来对照模型输出。绝不直接拿模型输出当答案去验证另一个模型那样只会制造循环错误。还有一个很常见的坑是问题里带的具体时间写得太模糊。比如你问“最近发生过什么”模型可能理解成去年或者上周回答就会偏。更好的问法是明确写一个年份请谈谈某技术方向在2024年内出现的公开进展。年份越精确越容易判断它给出的是不是合理信息。最后补充一点心得知识时效性测试不适合作为唯一判断标准。因为模型版本更新频繁训练截止日期不等于某次更新后的真实知识覆盖范围。我通常只把知识题当作辅助证据如果长程记忆和逻辑题都明显变差知识题再出现编造那才坐实了降智判断。5. 方法四用“追问纠错”和“矛盾陷阱”测逻辑一致性5.1 追问纠错是怎么操作的追问纠错听起来很简单让模型回答一个问题然后故意反驳它的答案看它会怎么反应。但这背后其实藏着一个很重要的测试目标模型是否具备稳定的立场同时又不至于过度固执。降智后的模型常常会走向两个极端要么“你说不对我就不对”要么“完全听不进去用户的合理修正”。我的操作方式是这样的。第一步先问它一个确定性问题比如如果今天下雨公园里人少这是不是因为天气影响游客出行模型通常会给出一个分析。第二步我故意说不对我觉得天气根本不影响游客出行。看它的回应。正常模型会区分“事实”和“观点”可能解释天气影响是一个普遍经验但确实存在例外降智模型则可能迅速倒戈您说得对天气可能不影响出行是我之前的分析欠考虑。如果你连续质询三轮模型每一轮都毫无原则地道歉那基本可以判定它的逻辑一致性出了问题。因为它在使用的过程中本质上是被你的语气带偏了而不是真的理解了你的反馈。5.2 自相矛盾陷阱的设计除了追问纠错我还会用“自相矛盾陷阱”来做更严格的验证。思路是先让模型接受一个前提然后用含有矛盾信息的提问看它是否能察觉出来。比如在一段话里故意写小明每天跑步三十分钟但他最近因为伤病已经完全停止训练请分析他如何维持每天跑步的习惯。这个前提本身就是矛盾的状态正常的模型会主动指出矛盾告诉你“既然已经停止训练就无法维持每天跑步”降智模型可能会一本正经地分析“如何在停止训练的状态下继续每天跑步”整个过程完全无视逻辑。另一种陷阱是让模型复述规则再应用规则。我会说请记住在这个对话里所有“红色”都必须被理解为“蓝色”。然后提问如果一个苹果是红色的它实际应该是什么颜色正常模型会指出这是一个约定在你定义的范围内它应该算蓝色但现实中仍然是红色。降智模型则会简单结论“苹果是蓝色”并且不再做任何注解这说明它根本没有维护“双重语境”的能力知识点和规则被混成一团。5.3 避坑心得别把“太听话”当成正常表现我在实际测试里发现用户对“太听话”的容忍度非常高甚至觉得模型能接受纠错就是聪明。但从检测角度看无底线让步恰恰是很重要的异常信号。所以我会把“主动承认逻辑矛盾”“能区分事实与说法”当作正常标准而不是“顺着我说就是好”。另一个要留意的问题是有些模型在安全限制下刻意表现得更顺从回复里大量使用“您说得对”“我理解您的观点”。这些礼貌话术本身不是问题问题在于它后面是否还有实质分析。如果一段回答只有附和没有论证没有边界说明那它的逻辑能力基本可以认定在退化。我还会做一个小技巧把同一组矛盾问题里的否定词反过来再测一次比如把“完全停止训练”改成“维持训练”看模型会不会突然换一套答案逻辑。如果两次测试结论互相冲突那说明它连最基本的语境稳定性都很差。6. 综合成一个30分钟的快速排查流程6.1 四步连测的标准步骤上面四种方法单独拿出来都能用但最靠谱的用法是串成一条流程在半小时内完成这样有对比、有基线。我自己用的流程是这样的第一轮花八分钟做长程记忆测试用第一节的连环提问模板记录每轮答案是否正确、是否出现态度突变。第二轮再花八分钟做数理逻辑测试用自定义算术题加代码题把输出复制到本地跑一遍记录最终结果与代码执行情况。第三轮用八分钟做知识时效性测试问三个带明确年份的中性问题人工核对答案。第四轮用六分钟做追问纠错与矛盾陷阱记录模型对于反驳和矛盾前提的反应模式。四轮做完把所有记录汇总到一张表里。如果四轮中至少有三轮都出现了明显异常那就可以判断模型当前状态确实偏低需要调整任务分配或者等待恢复。如果只有一轮异常那大概率是随机波动不必过度反应。6.2 结果速查表什么情况算降智为了方便我整理成一张速查表你测试时可以直接对照检测维度测试内容正常表现疑似降智表现长程记忆连环提问五轮五轮细节基本正确三轮后开始遗漏、改口数理逻辑自定义算术与代码步骤完整、输出可运行跳步、乱解、输出无法运行知识时效带年份的中性问题区分已知与推测斩钉截铁地编造信息逻辑一致性追问纠错与矛盾陷阱指出矛盾并维持立场无原则道歉或无视矛盾表格只是参考不是绝对标准。因为不同模型、不同温度参数、不同提示词都可能影响结果。我建议你第一次测的时候就记录一份“正常基线”之后每次拿出来对照。没有基线就没有降智。6.3 长期记录给自己建一个能力基线库最后一个建议也是我认为最有价值的经验不要只在听说降智的时候才去检测而是平时就固定时间做一次记录。你可以建一个非常简单的表格或者文档写上日期、模型名称、任务类型、回答关键词、结论隔半个月测一次。长期积累之后你就能看出模型能力到底是持续上升、周期性波动还是真的一路向下。我个人会把测试模板保存在一个文本文件里凡是需要用到的提示词都复制粘贴不改动其中的关键限制条件。这样可以保证每次测试的输入基本一致比较才有意义。还有一个进阶玩法同一套题目分别在多个不同入口各测一次看哪边表现好。有些环境因为推理参数限制输出会被截断或者简化看起来像降智但实际上只是设置问题。这种情况下你只需要调整环境不必质疑模型本身。最后分享一点我的实际感受做这类降智检测最好的心态是把它当成“医疗体检”而不是“打假现场”。体检的意义在于尽早发现问题、调整使用策略而不是证明“这个模型出了问题我可以不用了”。我经历过好几次同一套测试题某天晚上测试结果惨不忍睹第二天早上再测又恢复正常基本可以确认是峰值负载导致的临时波动。所以我的习惯是第一次测出异常先不信复测三次再结合四维结果下结论。你如果不想自己设计题目把我的模板拿去直接用也行先测一轮把结果记录下来等模型状态有波动的时候再测一轮两相对照比什么都清楚。工具是死的判断能力才是你真正需要练出来的。
