结论先说： “降智”不是一个可以通过单道题直接确认的技术状态。更可靠的做法是固定模型、参数和题集，在不同时段重复采样，并把协议字段、Token、动态能力题、流式输出、工具调用和真实业务结果放在一起比较。
最短判断路径是：先保存当前正常结果作为基线，再在相同模型 ID、参数和题集下复测。多项关键能力持续变差，并且排除了限流、上下文截断、客户端配置和网络波动时，可以升级为“疑似能力降级”。如果响应 model、服务商公告或路由元数据出现直接变化，即使质量暂时稳定，也值得单独排查路由变化；但网关可能改写字段，因此这些信号仍不能证明底层模型身份。
打开大模型 API 中转站检测工具，可以先生成一份分项报告，再按本文方法补充业务题集。
模型降智检测怎么做？
先固定模型 ID、提示词、参数和业务题集，保存一次正常结果作为基线；之后在相同条件下比较模型声明、Token、动态题、SSE、工具调用和任务完成情况。只有关键能力在多轮、跨时段持续变差，并且已经排除限流、上下文截断、网络和客户端差异，才适合记录为“疑似能力降级”。单次低分、回答风格变化或模型自述不能单独证明降智。
这类模型质量测试适合回答“当前接口是否按声明工作”，不适合单凭一次结果证明底层模型身份。若你需要比较多个入口，请使用相同模型、参数和题集，并保存每次报告的请求时间与脱敏请求 ID。
先定义什么叫“降智”
用户感受到的“变笨了”，可能来自多个环节：模型路由发生变化、网关追加系统提示、上下文被截断、工具调用不兼容、请求参数被过滤、高峰期限流，或者模型本身的随机输出波动。黑盒检测只能发现结果与声明不一致，不能仅凭现象确定内部原因。
因此建议把问题拆成三层：
| 层级 | 需要回答的问题 | 主要证据 |
|---|---|---|
| 协议层 | 接口有没有按声明返回标准结构 | 状态码、model、usage、流式事件 |
| 能力层 | 关键任务是否稳定完成 | 动态题、工具调用、结构化输出、业务题集 |
| 时间层 | 同一配置是否发生持续漂移 | 多时段报告、延迟、错误率、Token 与结果变化 |
可重复的检测步骤
1. 固定请求条件
记录 Base URL、模型 ID、temperature、最大输出长度、系统提示和测试时间。比较两个中转站时，除了 API Key 和地址，其余条件应保持一致。否则结果差异无法归因。
2. 先检查结构化信号
优先检查认证、HTTP 状态、响应 model、请求 ID、usage 和 Token 算术。结构化字段异常不等于模型一定被替换，但能较快暴露网关兼容、计费透明度或路由声明问题。
需要特别注意：/models 不开放或返回 401、403、429，可能只是权限与限流策略，不能单独当成造假证据。
3. 再验证关键能力
至少覆盖以下三类：
- 服务端随机生成的动态题，避免供应商针对固定题预设答案。
- SSE 流式输出，检查事件格式、增量内容和结束标记。
- 工具调用，检查工具名、JSON 参数和随机 nonce 是否原样返回。
如果业务依赖代码、长文本、检索或结构化 JSON，还应加入自己的脱敏样本。通用动态题只能检查部分能力，不能代替生产任务。
4. 在不同时间复测
建议低峰和高峰各运行一次，并在次日复测。一次失败可能来自网络、限流或上游波动；多项关键能力持续下降，且同一条件下能够重复，才值得升级为高风险信号。
一组可以立即复测的业务小样本
下面是自建验收题，不是模型身份鉴定题，也不代表完整能力评测。先写好预期结果，再向待测接口发送相同输入；每轮同时保留成功与失败结果，不挑选最好的一次。
| 检查任务 | 固定输入示例 | 验收条件 |
|---|---|---|
| JSON 约束 | 将 banana、apple、banana 去重并按字母排序，只输出 JSON 数组 | 能解析为数组，元素依次为 apple、banana；不含解释文字 |
| 信息抽取 | 订单 A17 有 3 件单价 12 元的商品，订单 B08 有 2 件单价 7 元的商品；只输出订单编号与总价 | A17 为 36，B08 为 14；不添加不存在的订单 |
| 缺失信息处理 | 已知订单编号 C09，数量为 4，单价未提供；能否确定总价？ | 明确缺少单价，不能编造金额 |
同一轮对照中保持输入不变；新一轮可以更换编号、数量或词语，并先重新计算标准答案。固定公开例题适合检查配置回归，不能排除供应商针对题目优化；正式验收应补充未公开的脱敏业务样本。
分数变低以后怎么判断？
记录每类任务的通过次数和总次数，例如“JSON 约束通过 4/5”，而不是只写“80 分”。这是记录格式示例，不是本站或任何模型的测试结果。若提示词、模型 ID、参数或上下文长度不同，两批结果不能直接比较。
返回 401、429、超时或截断时，先作为鉴权、限流或完整性问题单列；获得完整响应但没有满足预先定义的条件，才计入该任务的质量失败。耗时变长与答案质量下降分开记录。短样本可以发现值得排查的变化，不能据此估算长期故障率或确认底层模型被替换。
业务依赖 SSE 或工具调用时，仍须分别测试流式结束、工具参数和工具结果回传；上面三道文本题无法覆盖这些能力。
哪些现象值得重点排查
先按故障现象分流，不把所有失败叫作降智
| 现象 | 优先核对 | 后续处理 |
|---|---|---|
| 请求返回 401 | 临时 Key、账号权限与认证头 | 密钥与认证排查 |
| 请求返回 429 | 余额、请求或 Token 限额、并发 | 额度与限流排查 |
| 普通回答正常，SSE 中途断开 | 流式事件、超时与代理缓冲 | 502 与断流排查 |
| 请求模型与响应 model 不同 | 服务商别名映射与路由说明 | 模型字段的证明边界 |
| 无 HTTP 错误，但业务任务持续变差 | 相同上下文、参数、题集与多轮基线 | 按同一记录模板复测 |
不要通过无限重试来提高检测通过率。认证问题应先修配置，限流问题应降低并发并按服务商规则退避；重复请求可能增加费用，也会污染可比性。
- 请求模型与响应
model长期不一致，且服务商无法解释别名映射。 usage持续缺失或 Token 算术明显不一致。- 原本可用的工具调用、流式输出或结构化结果持续失败。
- 同一业务题集的约束遵循率明显下降，而请求参数没有变化。
- 高峰期与低峰期的模型声明、能力结果或输出结构出现系统性差异。
这些信号说明“需要排查”，并不等于已经证明套壳或降智。网关升级、模型版本变更和客户端差异也可能产生类似现象。
不要只看总分
检测工具中的综合分衡量协议与关键能力的兼容程度，不是模型智力分，也不是厂商认证分。应先看失败项是否影响你的业务，再看多轮结果是否一致。
例如，工具调用失败对普通文本摘要影响有限，但对 Agent 任务可能是阻断问题；知识 cutoff 自述与输出风格属于弱信号，只适合长期对照，不应单独判定真假。
建议保存的对比记录
time, base_url, requested_model, response_model,
status, latency_ms, input_tokens, output_tokens,
dynamic_probe, sse, tool_call, business_suite, notes记录时不要保存完整 API Key、用户隐私或未脱敏提示词。出现异常后，使用同一题集复测并向服务商提供请求时间和脱敏请求 ID，比只说“模型变笨了”更容易定位。
下一步
先运行一次标准模型检测，再阅读检测报告判读方法。如果主要异常是请求模型与响应模型不一致，继续查看套壳与路由替换风险排查。