---
url: https://ain.hmgf.hxcn.space/ai/model-downgrade-detection-202605.md
description: 从两篇 arXiv 论文出发，解释如何用极低成本监测 API 模型是否悄悄变化，并说明本地中文文章只是二手整理。
---

# 低成本监测 API 模型变更

来源：标题里的"1 个 Token 测出模型降级调包"，来自一篇中文二手整理，不是一手论文标题。

* 二手整理原链接：<https://mp.weixin.qq.com/s/ZelUviYX8UctyM_z_c71Yg>

核心资料是一手论文：

## 两篇相关论文

### Log Probability Tracking of LLM APIs

论文：<https://arxiv.org/abs/2512.03816>

### Token-Efficient Change Detection in LLM APIs

论文：<https://arxiv.org/abs/2602.11083>

这两篇论文讨论的是同一类问题：你通过 API 调用模型时，供应商有没有在你不知情的情况下换模型、做微调、改路由，或者让返回分布发生了足够大的变化。

这事对普通闲聊影响不一定大，但对下面这些场景影响很大：

* 自动化评测要复现结果。
* 线上 Agent 依赖固定输出风格。
* 回归测试默认"同样输入，分布不该突然变很多"。
* 安全审计希望尽早发现服务侧模型切换。

## 关注"调包"问题的原因

供应商不一定真的在做恶意"调包"，更多时候是：

* 升级了底模。
* 换了蒸馏版或更便宜的路由。
* 调了温度、拒答策略、系统模板。
* 对齐或安全层更新了。

但对调用方来说，关键不在动机，而在**你有没有办法低成本、持续地监测到变化**。

过去常见的办法有两类：

* 跑一整套评测集，比准确率和回答风格。
* 如果能拿到 logprobs，就比较输出分布。

问题是前者贵，后者又经常拿不到。两篇论文分别在这两个方向上往前推了一步。

## 第一篇论文：用 logprob 做连续监测

### 问题是什么

论文：<https://arxiv.org/abs/2512.03816>

这篇论文要解决的问题很直接：

* 很多 API 端点会变。
* 现有审计方法太贵，不适合天天跑。
* 结果是大部分模型更新都没有被持续监控。

论文的切入点是：虽然 log probabilities 本身带噪声、并不完全确定，但它们仍然能作为连续监测信号。

### 方法

论文：<https://arxiv.org/abs/2512.03816>

论文提出的是 **Log Probability Tracking**。核心思路很简单：

1. 选一组固定输入。
2. 每次只请求极少输出，甚至只取 **1 个 token**。
3. 记录这个输出 token 的平均 logprob。
4. 用统计检验比较一段时间前后的分布是否显著变化。

它的关键卖点有两个：

* 不需要生成长回答。
* 对很小的模型变化也敏感，论文说甚至能检测到"一步微调"级别的变化。

### 实验看到了什么

论文：<https://arxiv.org/abs/2512.03816>

按摘要说法，这个方法比已有方法**便宜约 1000 倍**，同时敏感度更高。论文还提出了 **TinyChange benchmark**，专门衡量审计方法在"小而真实的模型变化"面前能不能察觉。

这个实验设计很贴近现实，因为现实世界里很多变化都不是"GPT-4 突然换成另一个完全不同的模型"，而是更细的版本改动、对齐微调和服务策略调整。

### 这篇论文的结论

论文：<https://arxiv.org/abs/2512.03816>

如果 API 提供方愿意暴露 logprobs，那么低成本、连续、敏感的监测就是可行的。论文的意思也很克制：单次波动不该直接等同于调包，但即便 logprob 有随机性，它仍然足够有用，可以构成一套廉价的变化告警机制。

## 第二篇论文：黑盒条件下也想做低成本监测

### 问题是什么

论文：<https://arxiv.org/abs/2602.11083>

第二篇论文把约束又收紧了一层：

* 不能看权重。
* 不能看 logprobs。
* 只能看模型吐出来的 token。

这就是**严格黑盒**问题。很多商业 API 场景下，调用方就只拿得到最终文本输出。

### 方法

论文：<https://arxiv.org/abs/2602.11083>

论文的核心概念是 **Border Inputs**，可以理解成一类"边界输入"：

* 对这类输入，模型最可能输出的 top token 不止一个。
* 输出分布处在比较敏感的边缘地带。
* 一旦底层模型有变化，这些输入的输出结果更容易翻转或偏移。

在这个基础上，论文提出 **B3IT（Black-Box Border Input Tracking）**：

1. 找出合适的 border inputs。
2. 持续向 API 重复发送这些输入。
3. 只观察最终输出 token 的变化频率和统计分布。
4. 用统计方法判断底层是否发生了漂移。

### 实验看到了什么

论文：<https://arxiv.org/abs/2602.11083>

摘要里给出的结论有三点：

* 对非推理类端点，border inputs 比较容易找到。
* 在严格黑盒条件下，它的效果能接近最好的灰盒方法。
* 成本比现有方法再降大约 **30 倍**。

这篇论文的意义在于，它把"没有 logprobs 就做不了审计"这件事往前推了一步。虽然效果依赖输入选择，但至少证明了：**只看输出 token，本身也能形成可部署的变化检测。**

### 这篇论文的结论

论文：<https://arxiv.org/abs/2602.11083>

严格黑盒、低成本、可扩展的 API 变化检测是可能的。重点不在单次问答内容，而在一组精心挑选输入上的长期统计信号。

## 两篇论文放在一起看

它们解决的是同一问题的两种可观测条件：

| 条件 | 2512.03816 | 2602.11083 |
| --- | --- | --- |
| 能否看 logprobs | 可以 | 不可以 |
| 观测粒度 | token logprob | 输出 token |
| 核心方法 | 平均 logprob 统计检验 | border inputs + 黑盒统计检测 |
| 成本优势 | 约 1000 倍更便宜 | 约 30 倍更便宜 |
| 适用定位 | 灰盒连续审计 | 严格黑盒连续审计 |

如果你能拿到 logprobs，第一篇通常更直接，也更敏感。
如果你拿不到，只能退到第二篇的思路，用特殊输入去放大变化信号。

## 那"1 个 Token"到底是什么意思

容易误解的地方有两个。

第一，它不是说"问一句、回一个 token，就能百分之百断言被调包"。
第二，它也不是说"只靠一条样本就能下结论"。

更准确的理解是：

* 单次请求可以只取极短输出，成本非常低。
* 判断来自**很多次重复观测后的统计检验**。
* 论文追求的是"持续监测的单次成本极低"，不是"神奇的一发必中"。

所以标题党里的"1 个 Token 测出模型降级"，读成"**把每次采样的探针成本压到 1 个 token 量级，再用统计方法做连续监控**"会更接近原意。

## 这类方法能发现什么，不能发现什么

### 能发现的

* 服务端底模切换。
* 微调后输出分布变化。
* 某些对齐或系统策略更新。
* 路由改动导致的长期漂移。

### 不一定能直接解释的

* 变化到底来自底模、系统提示、采样参数，还是安全层。
* 变化对真实业务指标的影响究竟多大。
* 推理模型、强随机端点、重写层很多的服务，是否仍有同样效果。

它更像**告警器**，不是法医鉴定报告。

## 读论文之外，还要保留一点现实感

本地中文文章把这件事讲得很抓眼球，传播上没问题，但如果拿去做工程判断，还是得回到一手论文。

* 二手整理可以帮你快速知道"有这回事"。
* 能不能上线，要看你的 API 能拿到什么观测信号、成本预算多少、误报容忍度多高。

还有一个现实问题也别漏掉：就算你检测到了"模型变了"，很多商业 API 也未必承诺长期版本冻结。技术上能发现变化，不等于商务上能阻止变化。

## 落地思路

1. 确认供应商是否支持 logprobs。
2. 有 logprobs，就优先看第一篇论文的路线。
3. 没有 logprobs，再评估第二篇黑盒方法。
4. 别把单次异常当结论，要看连续统计信号。
5. 再把检测结果和你自己的业务回归集对齐。

这两篇论文的价值，不在"抓包供应商"，而在给调用方一个更现实的选择：**别等大模型服务悄悄变了几周才靠体感发现，放一个便宜的探针。**