模型识别置信度高，也可能认错对象

模型检测器给出「Model A：99.1%」，就能证明 API 背后跑的是 Model A 吗？作者的回答是：不能。这个百分比可能只表示，在检测器认识的几个候选里，Model A 最像；真正处理请求的模型，甚至可能根本不在候选名单中。

这篇文章拆解了高置信度背后的统计前提，也给出了更可靠的检测和报告方式。对接第三方 LLM API、做模型评测或采购验收的开发者，值得先弄清楚：你拿到的是相似度证据，还是足以确认身份的证据。

为什么 99.1% 也可能认错模型

通过 API 调用模型时，我们经常看到这样的字段：

{ "model": "model-a" }

它解决的是接口中的模型标识问题。要留意 model 这一行：它是服务商提供的声明，不能独立证明实际执行请求的模型身份。

作者列出了几种可能造成偏差的情况：请求被分配给不同版本，底层部署悄悄更新，部分流量交给较小模型，代理改写模型标识，或者推理参数与官方端点不同。这些是需要考虑的情形，文章没有证明某个具体服务商发生过这些问题。

黑盒指纹识别因此有了用途：向端点发送受控提示，提取回答中的统计特征，再与已知模型的参考样本比较。

问题出在最后一步。假设参考集包含 (K) 个候选：

[ \mathcal{R}={R_1,R_2,\ldots,R_K} ]

检测器把响应 (x) 转成特征 (z=f(x))，计算得分 (s_i=S(z,R_i))，然后用 softmax 归一化：

[ p_i=\frac{\exp(\tau s_i)}{\sum_{j=1}^{K}\exp(\tau s_j)} ]

这里的 (\tau) 控制分布有多集中。按这个公式，增大 (\tau) 通常会让领先候选拿到更高比例。

所有候选的概率之和必须等于 1。即使没有任何候选真正匹配，softmax 也得把概率分完。

所以，Model A：99.1%、Model B：0.6%、Model C：0.3%，未必表示真实身份有 99.1% 的概率是 Model A。它可能只是当前候选之间的相对结果。

候选中的第一名，不等于真实身份已经得到验证。

原文用 Claude、GPT、Gemini 举例：如果参考集只有这三个家族，一个从未进入参考库的模型，仍可能得到 Claude：97%、GPT：2%、Gemini：1%。更严谨的读法是：假定必须从这三个候选里选，Claude 的行为最接近。

这个条件不能省：

[ P(R_i\mid x,;y\in\mathcal{R})\neq P(y=R_i\mid x) ]

左边预设真实模型就在参考集中，右边试图判断真实身份。两者不是同一个问题。

检测器该展示哪些证据

作者给了两组分数：

• 第一组是 [10.0, 2.0, 1.0]。
• 第二组是 [-90.0, -98.0, -99.0]。

两组对应项都相差 100，在相同 (\tau) 下，softmax 输出完全相同。假如原始得分具有经过验证的绝对匹配含义，第一组可能匹配良好，第二组却可能全都不合格；归一化结果无法保留这种区别。

参考集变化也会影响百分比。加入或移除候选，会改变分母，即便输入和第一名的原始得分都没变，最终比例也可能变化。因此，单独展示一个大百分比，很容易让读者误判证据强度。

作者参与过 Oken 评估实验室的行为指纹系统。系统使用受约束、语义负担较低的生成任务，观察边际输出偏好、位置相关行为、转换幅度和局部序列结构，再与冻结的参考库比较。这里确实有实现经历，但文章没有提供准确率、样本量或对照实验，不能据此判断系统的实际识别能力。

作者建议，界面至少同时展示六类信息：

• 候选排名，让使用者看到第一名之外还有谁接近。
• 相对概率，并明确标注适用范围是当前参考集。
• 第一名与第二名的分差，即 (\Delta=s_{\text{top-1}}-s_{\text{top-2}})。
• 绝对兼容程度，例如到参考样本的距离、局部密度或类条件似然。
• 数据质量，包括有效观察数量、越界输出，以及已知的推理设置。
• 参考来源，包括参考库版本、采集日期、提示或协议版本、评分配置和相关推理参数。

分差回答「领先多少」，绝对兼容程度回答「这个样本到底像不像它」。前者很大，仍然无法排除真实模型不在参考集里的情况。

为什么加一个 UNKNOWN 按钮还不够

闭集分类预设所有样本都属于已知类别。开放集识别则要先判断样本是否落在参考库覆盖的分布里，再决定归给哪个候选。

作者提出的规则是：

[ \hat y= \begin{cases} \arg\max_i s_i,& A(x)\geq\lambda\ \text{UNKNOWN},& \text{其他情况} \end{cases} ]

其中 (A(x)) 是绝对接受统计量，(\lambda) 是用独立数据校准的阈值。

不能简单规定「第一名低于 60% 就返回 UNKNOWN」。未知模型照样可能得到 99%；已知模型也可能因为相邻版本难以区分、采样参数变化、系统提示影响、端点漂移或有效证据不足，只拿到 45%。

真正困难的是验证拒识规则。

测试前，需要冻结模型身份、参考样本、特征转换、评分规则、校准方法和拒识阈值，再揭示测试标签。测试集至少包含三组：参考库中的已知模型，但回答来自独立采集；故意排除的近邻未知模型，例如相邻检查点、微调版本或量化部署；以及参考库未覆盖家族的远端未知模型。

指标也不能只有 Top-1 准确率。还应报告已知模型真阳性率、未知模型误接受率、已知模型误拒绝率、指定真阳性率下的 FPR、开放集分类率，以及各家族的拒识表现。

概率校准还要单独验证。报告约 80% 的预测，在规定评估分布中应当约有 80% 判断正确；这不是套上 softmax 就能得到的性质。作者列出了 Expected Calibration Error、负对数似然、可靠性图和类别条件校准误差，并强调部署条件变化后需要重新检查。

百分比可以算得很精确，但它的含义必须靠独立实验支撑。

我的判断

作者最有价值的提醒，是把「行为接近」与「身份确认」分开。服务商标签、行为指纹、部署身份，分别代表不同来源的证据，不能因为界面上出现 99%，就把它们当成一回事。

不过，文章给出的是方法论和实现经验，没有展示 Oken 系统经过盲测后的误接受率，也没有说明哪种绝对兼容统计量最有效。它指出了应该怎样验证，却没有证明自己已经解决了未知模型拒识。

与直接相信服务商标签相比，行为指纹增加了一种可观察证据；与能力评测相比，它更关注输出模式是否接近参考分布。两者可以互补：模型像不像某个家族，与它能否稳定完成你的任务，仍需分别检查。

对多数 API 使用者，我更认同作者后半段的取舍：优先监测服务行为是否变化。固定协议后，比较当前表示 (z_t) 与参考表示、上一次表示的距离：

[ D(z_t,z_{\text{reference}}),\qquad D(z_t,z_{t-1}) ]

距离明显增加，可以触发进一步测试。但它不能自动证明服务商换了模型，系统提示、推理参数、后处理和协议遵循程度都可能影响结果。混合路由也只是需要调查的可能原因，不能从一次异常直接下结论。

能拿来做什么

• 如果你在 Node 服务中接入第三方 LLM API，可以保存固定协议下的行为样本，并记录已知推理设置和采集时间；后续按同一协议重复采集，先判断服务是否出现变化。
• 如果你负责评测后台或前端结果页，应同时展示候选排名、分差、绝对兼容程度和有效样本数，把百分比标为「当前参考集内的相对概率」，并提供「证据不足」的结果状态。
• 如果你要验收一个模型检测器，应要求它报告近邻未知模型和远端未知模型的测试结果，重点查看误接受率、误拒绝率及阈值选择依据，不能只看 Top-1 准确率。
• 如果你用检测结果追查 AI 编程接口的表现变化，应把指纹异常作为复测入口，再检查任务表现、系统提示和推理参数；只有相似度排名时，结论应停留在行为一致性层面。