固定探针为何查不出模型偷换

固定用几道题检查模型有没有被掉包，可能只能证明供应商认真对待了这几道题。提示词、调用频率、账号和时段都可能暴露审计流量，转售商于是可以让探针走真模型，让业务请求走另一条路。

作者修正了自己此前的建议：检测模型替换，先要说清抽查覆盖了哪些请求，再讨论探针是否灵敏。这篇最有用的部分，是把「模型身份测试」变成了一套能对应业务流量、抽样误差和账单的审计方法。

探针全通过，为什么账单仍然可疑

作者此前提出过客户端探针和供应商侧证明两种办法。评论者 ahmetozel 指出，固定探针会形成一种可识别的流量类别：相同问题、相同节奏、相同账号，甚至相同调用时间。

如果转售商有意隐藏替换，就可以只对这类请求履约。因此，下面两个结论必须分开：

• 这个端点在这些输入下，运行了宣称的模型。
• 我付费购买的业务流量，运行了宣称的模型。

固定探针通过，不能直接推出业务流量也合规。

这不是提示词设计得不够刁钻，而是被检测的请求不代表实际购买的请求。继续扩充固定题库，仍然可能只是在扩大一个容易被识别的审计类别。

固定探针也有用途。输入保持完全一致，可以反复比较输出、用量等变化，便于发现回归；但要判断真实业务是否被替换，还得从业务请求里抽样。

「全部匹配」到底排除了多大的风险

假设被替换的流量比例是 f，均匀随机抽取 n 个请求，完全没抽到替换请求的概率是：

(1 - f)^n

要有 95% 的概率至少碰到一次替换，样本量需要满足：

n ≥ ln(0.05) / ln(1 - f)

反过来，如果 n 个样本都没有发现不匹配，可以用「三法则」估计：在 95% 置信水平下，真实不匹配率的上界约为 3/n。

作者给了两个很直观的例子：5 个样本零异常，上界约为 60%，几乎排除不了什么；300 个样本零异常，上界才降到约 1%。报告都可以写成「100% 匹配」，但能支撑的判断差得很远。

这里还有一个前提：抽样必须符合所用统计方法的假设，而且检测手段得能识别替换。抽中了却认不出来，样本量再漂亮也补不上这个缺口。

因此，报告至少要把样本量和匹配率放在一起，再说明它能排除多高的异常比例。只给一个百分比，对采购决策帮助有限。

从业务日志抽样，证据才有机会对应账单

作者提出了六个环节，没有提供实际部署后的对照结果，应把它们看作一套审计设计。

第一，记录完整请求总体，再从中抽样。日志包括路由标签、上下文长度区间、token 数量、request id 和时间戳。抽样框就是所有有资格被抽中的请求清单，不能拿预先写好的题库代替。

第二，把预算分给随机样本和固定对照。作者建议一种比例：90% 从真实流量随机抽取，10% 留给可以按字节完全一致地重跑的固定请求。前者扩大覆盖范围，后者依靠重复比较提高发现变化的能力。这个比例是建议，没有实验说明它适合所有团队。

第三，先分层再抽样。短请求占比高时，直接随机抽样容易漏掉低频长上下文请求，而后者恰好可能被藏着替换。作者建议按网关路由标签和上下文长度区间分层，每层公开总体数量 N_h、样本数量 n_h 和入样概率。

路由标签要取自网关实际路由日志。客户端打算调用的路由与网关记录不一致，本身就是调查线索。

第四，在任何归一化之前保存上游原始响应，保留 model 字段、usage 块、请求 ID 和时间戳。按别名对应的 tokenizer 计算后发现用量不符，可以提示回归，却不能直接判定掉包：网关追加 system message 或规范化提示词，也可能合法改变计数，需要同一请求下的可信基线。

第五，让双方能关联同一次调用。作者建议用 (client id, upstream id, timestamp) 的哈希生成关联 ID，减少对某一方维护映射表的依赖。

第六，分开报告两种数字：每层的匹配率、样本量和统计上界；再依据 N_h 计算带区间的流量加权估计。为了查清稀有路由而多抽了一些样本，不能直接把它在样本中的占比当作账单中的占比。

我的判断

作者最有价值的修正，是把「测到什么」与「能推断到哪里」分开了。与继续打磨固定题库相比，这套办法更适合回答付费流量是否履约，也让审计报告有了可核对的分母。

但它依赖几项条件。网关如果控制并伪造完整日志，抽样就会继承这个谎言，必须补上客户端采集或自控代理这样的独立观察点。低预算下，稀疏替换也很难被发现。作者没有给出这套设计相比其他方案的检出率、误报率或成本数据，不能替它背书。

关联 ID 的建议也没讲透。哈希不会自动让双方拥有相同输入；双方是否都能拿到两个 ID、时间戳如何统一，原文没有说明，落地时仍需约定。

这些检查提供的是异常线索，模型身份证明仍需要另一个信任来源。

作者把供应商侧证明视为证明路径，同时承认它依赖供应商实际运行证明机制。文末另有标注为「500 tokens」的 iLands Proof Audit 服务推广，但没有解释该数字的具体含义，也没有提供可供评价服务效果的结果。

我更认可作者最后的合同建议：抽样报告随发票附上，并列明样本量和覆盖分层。它至少能让「服务是否符合约定」成为有记录可查的账单问题。

能拿来做什么

• 如果你在 Node 网关接入模型转售服务，可以先保存上游原始响应、请求标识和实际路由记录，让后续抽查有据可依。
• 如果正在运行固定探针，可以保留它作为稳定对照，同时增加真实业务流量抽样，并按路由和上下文长度检查覆盖情况。
• 如果负责采购或核账，可以要求报告同时提供 N_h、n_h、匹配率及统计上界，避免把少量样本全通过当成全面履约。
• 如果用 tokenizer 用量差异报警，可以先核对 system message 和提示词处理方式，再调查模型替换，避免把正常网关行为误判为异常。