API里的AI，真是它本人吗？
你在第三方 API 里选了一个大模型，页面写着某个名字，就能确定背后真是它吗？答案没那么简单：模型会按系统提示自报身份，网关还可能改模板、换后端。刚上线的一篇研究提出“四阶段审计法”，重点不是套话测性格，而是寻找服务链路更难伪装的证据。

第0步：还原上线时配置
先查模型刚发布时的网页存档和目录记录，记下上下文长度、最大输出、推理开关、输入模态。为什么不是只看今天的页面？预览版到生产版可能改参数，用新配置倒推旧模型会误判。

第1步：做配置指纹
把这些字段与平台完整模型目录比对，先缩小候选池。论文的旗舰案例中，仅用上下文和输出上限，就把422个目录项压到6个；加入模态后出现唯一匹配。但模态声明也可能提前或滞后，所以它是强信号，不是最终判决。

第2步：测跨长度 tokenizer 差分
让匿名端点和候选模型处理相同的短提示、长中文、长英文，比较返回的 prompt_tokens 差值。只有差值跨长度严格恒定，才支持“共享 tokenizer 家族”。只测一句“你是谁”很危险：研究记录的3个非同家族模型在短提示上出现碰撞，长文本一上场就露馅。

第3步：行为只做佐证
再检查模态能力、推理控制和知识边界。如果行为与前两层冲突，应触发警报或输出“无法归因”，而不是硬猜一个名字。

这套方法最值得收藏的边界是：tokenizer 相同，最多支持家族或代际判断，不能证明精确 checkpoint、量化方式、硬件和部署变体。论文回顾的10个已知案例只验证了“平台声明是否一致”；真正事前盲测并等官方揭晓的旗舰案例目前只有1个，因此不能把它包装成通用识别率。

实用检查表：采购 API 前保存模型页快照；记录每次上下文与输出上限变化；关键业务同时保留官方端点作对照；遇到证据冲突就降级或停用。模型身份不是八卦，而是数据条款、能力预期和供应链风险的入口。

资料：arXiv:2608.31142
AI安全 大模型 API 模型审计