模型对比检测原理是什么：判定逻辑与典型应用场景

同一句提示词发给两家渠道，一个答得顺、一个答得怪，这算被掉包了吗？不一定。模型本身有随机性，温度、系统提示、版本快照都会让输出长得不一样。这篇讲的是对比检测的判定原理：用哪些探针、比什么维度、阈值怎么定，什么情况下结论不成立，以及这套方法在实际工作里能用在哪儿。

同一句提示词发给两家渠道，一个答得顺、一个答得怪，这算被掉包了吗？不一定。模型本身就有随机性，温度、系统提示、版本快照都会让输出长得不一样。真正能用的对比检测，不是靠某一次回答的感觉，而是靠固定探针、固定参数、固定采样节奏，把「不一样的幅度」量出来，再决定这个幅度算正常波动还是异常偏移。

这篇讲判定原理：比什么、怎么比、阈值从哪来、什么情况下结论不成立，以及这套方法在实际工作里能落在哪些场景。适合自己管着几个 API 渠道、需要判断上游有没有悄悄换模型或降级的技术读者。看完你至少能自己搭起一轮可复现的对比流程，而不是每次凭感觉吵架。

对比检测到底在比什么

很多人以为对比检测是「比谁更聪明」，其实不是。它比的是同一来源在不同时点、不同批次之间是否自洽。也就是把一家渠道当成一个被测对象，问的是：它今天的行为，跟它自己前几天的行为、跟官方基线的行为，偏移量大不大。检测对象是通道行为，不是模型权重。

核心假设只有一条：同一模型在固定条件下，输出分布应该稳定到能设一个阈值。这条假设是整个方法的命门。如果模型方频繁更新、或者中转层本身就不稳定，分布收敛不住，那任何阈值都是虚的，检测结果只能当参考不能当结论。

• 比的是通道行为：同一模型经不同转发层，加没加系统提示、有没有做缓存、节点路由到哪套后端，行为都可能变
• 比的是自洽性：自己的历史基线优先于官方基线，因为官方基线往往没有你可复现的采样条件
• 比的是可量化项：格式合规、拒答点、口癖词、采样分布，能算出来才叫证据
• 假设不成立就别硬测：上游频繁维护、模型快照天天换的时期，先记录再判定

探针怎么设计：固定一批、可复现、有区分度

探针不是随便找几道题。要成组设计：能力探针查基本功，风格探针查口癖，拒答探针查安全策略，格式探针查结构化输出。四类各来几条，加起来二三十条，一轮跑完十几分钟，这个成本是可以接受的。

每条探针的请求参数必须锁死：温度、max tokens、系统提示、是否流式、是否带工具，全部固定。只要有一个飘了，噪声就会盖过信号。跑之前把参数写进配置文件，跑之后连同请求体、响应体、时间戳、渠道标识一起存档，做不到回放就等于白测。

区分度靠筛选。一条探针如果所有模型都能答对，那它测不出任何差别，等于白测。筛选方法很简单：先拿你已知的两个来源跑一遍，把结果几乎相同的探针删掉，只留能拉开差距的。具体口径可以到站内质量检测页面核对当时的说明，别自己临时定标准。

比哪几个维度：从硬指标到软特征

维度分两层。硬指标是可以直接算的：格式合规率、拒答触发点、工具调用结构是否合法、首字耗时和总耗时。软特征是看起来主观、其实可以数出来的：口癖词出现频次、举例子的习惯、拒绝时的措辞模板、换行和符号偏好。两层都要看，只看一层容易误判。

还有一个容易被忽略的维度是一致性：同一条探针多次采样，看分布是否收敛在一个窄带内。收敛得好，说明通道稳定；忽宽忽窄，说明背后可能有多个后端在轮换。这个维度的价值在于，它比单次输出更能反映通道结构。

• 硬指标看合规：格式错误率超过你自己的基线区间，就先怀疑结构和参数
• 软特征看习惯：口癖词、拒绝模板、举例方式，换模型时往往先在这上面漏出来
• 一致性看分布：同一探针跑多次，统计出现频次而不是只看一次回答
• 推理型模型要换维度：思考过程本身就长，耗时维度失效，得改看思考长度分布
• 非适用提醒：如果你的业务只关心最终答案、不关心风格，那软特征权重就应该调低

判定逻辑：单点异常不算，成组偏移才算

判定顺序是先用基线定区间，再用新样本比区间。基线的建立方式是：对同一来源反复采样同一批探针，得到每一条探针的正常波动范围。这个范围不是拍脑袋定的，是你自己跑出来的。基线建好之后，任何新结果都放进这个区间里比，超出多少、超了几条，才是判断依据。

结论分三级。疑似：一到两条探针偏移，先观察。可疑：同一维度多条探针同时偏移，值得复检。确认：跨维度成组偏移，而且重复采样还稳定复现。跨维度是关键，能力、风格、拒答、格式四个维度里至少两个同时偏，才有说服力。单点异常永远不算数。

什么情况不下结论：样本量不足、探针本身版本变过、上游刚做过维护。这三种情况都只能观察不能定性。还有一种是你自己改了参数忘了，排查顺序永远是先排本地再排上游，这一点在后面落地步骤里会展开。

误判从哪来：五种常见假阳性

假阳性比假阴性更常见，因为大家容易把「变化」直接等同于「掉包」。实际上模型官方换快照、缓存路由、参数没锁死、系统提示被污染、语言长度混排，都会让输出看起来不一样，但渠道本身没问题。分清这几种，能省下大量无效投诉。

判断方式是逐项排除。模型更新通常伴随整体行为一致地变，风格探针集中偏移；缓存路由则表现为同一渠道不同时间结果跳变；参数没锁死是随机波动，多次采样能看出来；系统提示污染会让风格探针全灭但能力探针正常；语言和长度问题是分布性的，不会集中在某类探针上。

• 模型更新：官方换快照，行为整体变，渠道无辜，等基线更新即可
• 缓存与路由：同渠道不同节点命中不同后端，跳变明显但不稳定
• 温度与采样：参数没锁死，同模型两次回答本就不同，先检查配置
• 系统提示污染：客户端或中转层偷偷加了前缀，风格全偏能力正常
• 语言与长度：中英混排、超长输出稳定性本来就差，别拿它当证据

典型应用场景：这套方法能用在哪儿

第一个场景是采购前试水。用同一组探针跑几家候选渠道，看谁的行为更贴近你手里的官方基线。这不是选最便宜的，而是选行为最稳的。价格数字到站内价格追踪页面核对当时的报价，别用记忆里的数比价，那没有意义。

第二个场景是换源后验收。迁移完先跑一轮完整探针，确认不是换了个便宜货。第三个场景是日常巡检，固定节奏抽样，观察有没有悄悄降级。第四个场景是团队共用，多人多项目共用一把 Key 时，用探针区分「是模型变了」还是「同事改了参数」。

还有一类是合规相关的检测，探针里别塞真实业务数据。要测安全策略边界，就用构造的样例，别拿线上日志去跑。数据边界这块，站内安全页面有说明，动手前先看一遍。

落地步骤：一次跑完的排查顺序

1. 锁参数把温度、max tokens、系统提示、流式开关写进配置文件，跑之前确认没被人改过
2. 建基线对已知正常的来源跑多轮探针，统计每条探针的波动区间，存成基线文件
3. 换源重跑对目标来源跑同一批探针，参数完全一致，记录请求体、响应体、时间戳
4. 同维度对比按能力、风格、拒答、格式四类分别比，先看单维度内的偏移条数
5. 重复采样单次结果先丢，重复跑几轮，看偏移能不能稳定复现，不能复现的不算
6. 跨维度交叉至少两个维度同时偏才算成组偏移，一个维度偏只能算观察线索
7. 排除干扰先查本地参数和网络，再查上游维护公告，排除完再写结论
8. 写结论写「观察到的偏移」和样本量、时间窗口，不写「一定是掉包」，留复检余地

这套步骤的关键在于顺序不能乱。很多人先下结论再补证据，结果就是反复打脸。把重复采样和跨维度交叉放在结论之前，能挡掉大部分误判。

边界与不适用：什么时候这套逻辑会失灵

第一种失灵是新模型没有基线可建。你手上只有一条样本，没法算波动区间，只能做相对比较，不能做绝对判定。第二种是高度同源的模型族之间，探针区分度可能不够，硬比只会得出噪声结论。这两种情况下，方法本身没错，是数据条件不支持。

第三种是上游刻意做行为对齐。如果中转层专门针对常见探针做了风格模仿，单靠输出特征很难抓到，这时候要把用量口径和计费口径一起看，行为像不代表计量口径也像。具体怎么交叉，可以到站内质量监控页面看追踪思路。

• 没基线的新模型：只能相对比较，不能做绝对判定
• 同源模型族：探针区分度不够，硬比得出的是噪声
• 刻意行为对齐：结合用量与计费口径交叉看，别只看输出
• 合规场景：探针里别放真实业务数据，用构造样例
• 采样成本高时：降低探针数量可以，但四类探针至少要各留一条