低成本监测 API 模型变更
来源：标题里的"1 个 Token 测出模型降级调包"，来自一篇中文二手整理，不是一手论文标题。
核心资料是一手论文：
两篇相关论文
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 个 token。
- 记录这个输出 token 的平均 logprob。
- 用统计检验比较一段时间前后的分布是否显著变化。
它的关键卖点有两个：
- 不需要生成长回答。
- 对很小的模型变化也敏感，论文说甚至能检测到"一步微调"级别的变化。
实验看到了什么
论文：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）：
- 找出合适的 border inputs。
- 持续向 API 重复发送这些输入。
- 只观察最终输出 token 的变化频率和统计分布。
- 用统计方法判断底层是否发生了漂移。
实验看到了什么
论文：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 也未必承诺长期版本冻结。技术上能发现变化，不等于商务上能阻止变化。
落地思路
- 确认供应商是否支持 logprobs。
- 有 logprobs，就优先看第一篇论文的路线。
- 没有 logprobs，再评估第二篇黑盒方法。
- 别把单次异常当结论，要看连续统计信号。
- 再把检测结果和你自己的业务回归集对齐。
这两篇论文的价值，不在"抓包供应商"，而在给调用方一个更现实的选择：别等大模型服务悄悄变了几周才靠体感发现，放一个便宜的探针。