大模型为何越用越笨：质量波动排查与治理指南

一、先区分“体验下降”与“模型能力下降”

在代码开发和实验分析中，智能助手的质量波动往往比普通问答更容易被察觉。昨天还能梳理完整依赖关系，今天却只修改表面报错；上一轮能够遵守实验约束，下一轮又遗漏随机种子、数据边界或结果验证。用户很容易据此得出结论：模型被悄悄降低了能力。

但从工程角度看，“结果不如预期”只是现象，不足以直接证明底层模型发生了替换，也不能证明服务方主动减少了推理投入。

一次智能任务的实际效果，可以概括为：

任务效果＝模型能力、输入信息、运行配置、外部工具、执行流程与验收机制共同作用的结果。

这个表达不是可直接计算的数学公式，而是一种排查框架。它提醒我们：即使底层模型没有变化，只要其中一个环节出现偏差，最终输出也可能明显变差。

因此，正确的问题不是先问“是不是被降级了”，而是：

• 哪类任务的质量下降了？
• 下降发生在哪个环节？
• 在相同条件下能否稳定复现？
• 哪些证据能够支持或排除某种解释？

只有把主观体验转换为明确指标，排查才有起点。

二、固定问答前缀能做探针，但不能当作能力鉴定

一种常见做法，是要求助手在每次回复前先回答一道固定问题，再输出正式内容。例如，先回答一个与当前人物任职有关的问题，并把答案放在回复开头。

这种方法成本低、容易观察。当助手没有输出预期前缀时，用户会立即意识到执行过程可能发生了变化。但它能说明的问题，比直觉中要少。

1. 时效性知识不等于推理能力

人物任职、机构负责人等事实会随时间变化。模型是否回答正确，可能受知识更新范围、对话中的日期信息、检索能力以及已有上下文影响。

一个模型可能擅长复杂代码推理，却不知道最新人事变动；另一个模型也可能知道最新事实，却无法正确处理跨文件修改。两者不是同一个能力维度。

因此，用一道时效性问题判断整体能力是否下降，容易把知识新旧误认为推理强弱。

2. 前缀缺失首先是指令遵循信号

固定前缀没有出现，可能意味着：

• 注入逻辑没有运行；
• 请求走了不同处理路径；
• 当前组件没有收到相关指令；
• 输出受到更高优先级要求约束；
• 回复在传输或展示阶段被截断；
• 模型没有稳定遵守格式要求。

这些现象值得调查，但都不能单独证明底层模型被更换。

反过来，前缀出现也不能证明整条链路正常。助手可能完成了简单前缀任务，却在后续代码分析中遗漏关键条件。

3. 每轮追加检查会改变被测对象

如果每条用户消息后面都附加额外指令，模型实际处理的就不再是原始任务，而是“原始任务加附加约束”。

重复内容会增加上下文占用，干扰输出格式，并可能与结构化结果、工具调用要求发生冲突。在长会话中，这种影响会更加复杂。

更合理的做法是：把固定前缀仅用作低成本的链路检查；把能力评估放到独立、稳定、可重复的测试任务中。不要让监测机制本身持续污染业务提示。

三、遇到服务过载，能够推断什么

服务返回过载信息，能够直接支持的结论通常是：当前请求在某个服务环节遇到了容量、排队或资源限制。

它不能直接证明系统切换了模型，也不能证明系统减少了推理投入。

1. 过载可能导致显式失败

请求可能被拒绝、等待超时，或者返回可重试错误。此时主要问题是可用性，而不是已经完成的回答质量。

2. 重试可能改变实际执行条件

应用为了完成任务，可能在失败后重试。但如果重试没有完整保留消息、附件、工具状态或约束条件，即使再次请求成功，结果也可能不同。

因此，应重点检查：

• 重试是否携带了完整上下文；
• 是否重复执行了有副作用的操作；
• 是否遗漏了上一轮工具结果；
• 是否触发了应用自行配置的备用处理路径；
• 多次尝试是否共用了不一致的中间状态。

尤其在代码修改和实验任务中，重复写文件、重复提交任务或重复覆盖结果，比单纯回答错误更危险。

3. 负载高峰与复杂任务可能同时出现

团队集中使用系统时，往往也正处于发布、实验或批量处理阶段。此时任务更复杂、输入更长、工具调用更多，质量问题自然更容易暴露。

时间上的同时发生，不等于因果关系。应当在高负载与正常负载期间运行相同评测，再结合错误、耗时、重试记录分析差异。

如果服务没有提供明确的执行元数据，就应保留不确定性，而不是仅凭回答风格推断底层发生了什么变化。

四、长上下文是“越用越笨”的常见来源

会话持续增长时，重要信息并不会自动获得更高关注。相反，关键约束可能被大量历史讨论、失败尝试和过期结论包围。

1. 历史信息多，不代表有效信息足

一个开发会话可能同时包含旧版设计、已经废弃的修复方案、临时实验参数，以及后来被否定的判断。若这些信息没有清楚标注状态，助手可能把旧结论当成当前事实。

建议把上下文整理为四类：

• 当前目标；
• 已确认事实；
• 必须遵守的约束；
• 尚待验证的假设。

同时，明确指出哪些历史方案已经失效。相比不断堆积原始对话，这种整理更有利于稳定执行。

2. 自动摘要也可能丢失关键细节

长会话可能需要压缩或摘要，但摘要并不保证保留所有重要条件。例如，“优化实验脚本”这样的概括，可能遗漏“不得改变数据划分”和“必须保留原始基线”这类决定正确性的限制。

因此，关键约束应独立维护，并在关键操作前重新核对。不能把完整性完全寄托于历史会话摘要。

3. 无关日志会稀释有效证据

把全部运行日志交给助手，不一定比提供经过筛选的日志更好。大量重复信息、历史错误和无关输出，会增加识别真正异常的难度。

更好的输入应包括：最小复现步骤、首次异常位置、相关配置、期望结果与实际结果。原始日志可以保留为证据，但不必全部进入每次推理请求。

五、多智能体任务为什么更容易出现质量落差

在多智能体工作流中，主助手会把任务交给若干子任务执行单元。用户看到的通常是统一回复，但内部执行条件未必一致。

1. 主任务约束不会必然自动继承

如果主助手只传递“修复这个错误”，却没有传递“不得修改公开接口”“不得调整实验数据划分”等限制，子任务即使完成了局部修复，也可能破坏整体目标。

对子任务的输入应明确包含：

• 具体目标与允许修改的范围；
• 必须保留的不变量；
• 必要文件和背景；
• 可使用的工具权限；
• 验收条件与证据要求；
• 失败或信息不足时的处理方式。

2. 局部正确不代表整体正确

一个子任务可能修复了函数内部逻辑，却破坏了调用方约定；另一个子任务可能提升了运行速度，却改变了统计口径。

因此，多智能体的关键不是并行数量，而是任务边界、接口约束与集成验证。每个执行单元都应返回修改内容、验证方法、验证结果和未解决风险。

3. 主助手不能只转述“已经完成”

“已修复”“测试通过”属于结论，不是充分证据。主助手应核对执行记录，确认测试是否真正运行、覆盖范围是否足够，以及是否存在未被验证的环境条件。

没有执行过的测试，应明确标注为未执行，而不是根据代码外观推断通过。

六、用可复现评测替代单点猜测

判断质量是否变化，最可靠的方法是建立与真实业务相关的小型回归测试集。

1. 按能力维度设计任务

测试集至少可以覆盖：

• 指令遵循：是否保留禁止修改的内容；
• 代码理解：能否识别跨文件依赖；
• 缺陷定位：能否找到根因而非只消除症状；
• 工具执行：能否正确使用工具并处理失败；
• 长上下文：能否遵守早期关键约束；
• 事实可靠性：能否区分已知、未知与需要检索的信息。

这些任务应使用可验证答案，避免仅凭语言流畅程度打分。

2. 固定可控条件

对比时应尽量固定输入、文件版本、工具权限、运行环境和输出要求。对于存在生成随机性的任务，应重复运行并观察结果分布。

如果某次回答失败，而后续多次都成功，只能说明存在波动，不能直接说明能力持续下降。

3. 分开衡量质量与可用性

建议分别记录：

• 任务完成率；
• 测试通过情况；
• 约束违反情况；
• 无依据结论的出现情况；
• 工具执行失败情况；
• 请求耗时、超时与重试情况；
• 人工返工量。

一次请求可能响应很快，但没有正确完成任务；也可能耗时较长，却最终给出了可靠结果。混合成单一“体验分”，容易掩盖真正的问题。

还应记录评测样本数量和判定规则，避免把少量样本的偶然差异解释为稳定趋势。

七、建立最小可观测链路

能力探针只能提示异常，链路记录才能帮助解释异常。

每次任务至少应关联请求标识、会话标识、任务类型、提示模板版本、工具调用结果、重试次数、终止原因和验收结果。

对于服务实际提供的执行信息，可以如实记录；对于服务未提供的信息，不应自行推断或补全。例如，不能根据回答变短就断言推理资源减少，也不能把应用请求中填写的配置直接视为底层执行事实。

一个中立的检查流程可以表示为：

接收任务
  → 检查必要信息是否齐全
  → 保存当前输入与配置快照
  → 执行任务并关联工具记录
  → 区分服务错误、工具错误与质量错误
  → 按验收条件验证产物
  → 记录结果并决定是否重试或转人工

日志中还应对敏感信息进行脱敏，限制访问权限与保存期限。可观测性不是无限保存全部输入，而是在合规前提下保留足够的排查证据。

八、生产环境如何降低质量波动的损失

1. 对高风险操作设置验证门槛

代码提交、数据删除、实验参数覆盖、权限变更等操作，不应仅凭模型自然语言确认就执行。应增加差异检查、自动测试或人工审批。

2. 重试必须有条件、有上限

容量不足、短暂连接失败可以考虑受控重试；缺少上下文、需求冲突或工具权限不足，则应先解决根因。

对于可能产生副作用的操作，应通过幂等机制或执行状态检查，避免重复操作。

3. 备用路径必须可见

如果应用配置了替代执行路径，应记录触发原因、实际使用的路径和能力限制。重要任务可以暂停等待，而不是在用户不知情的情况下输出未经同等验证的结果。

4. 为实验保留恢复点

在修改实验脚本或配置前，应保存代码、参数、环境信息和已有结果。实验结论还需要检查数据划分、随机性控制、评价口径和重复验证，不能以“脚本能够运行”作为唯一验收标准。

结语：真正可靠的不是“暗号”，而是证据闭环

固定问答或回复前缀可以帮助发现异常，却无法独立证明模型被替换、能力被降低，或者某家服务存在特定处理策略。

面对“越用越笨”的体验，更有效的路径是：先定义失败，再固定条件；先检查上下文与执行链路，再分析服务侧因素；最后用回归评测确认变化，并通过验证门槛、受控重试和恢复机制降低损失。

对于开发者和企业团队，最重要的不是让智能助手反复证明自己“还是原来的能力”，而是让每次关键任务都有明确输入、可追踪过程和可检查结果。只有这样，质量波动才能从难以解释的感受，变成可以治理的工程问题。