中转站纯度测试怎么做：把「掺水」测出来的几种手法

你花钱买的是某个模型的接口，可返回的结果总觉得哪儿不对：答得浅、风格飘、速度忽快忽慢。这时候光靠「感觉像」没法下结论，也没法拿去跟站长对质。这篇不讲模型原理，只讲怎么设计一次低成本抽样：掺水通常以哪几种形态出现、每种形态在实际调用里会留下什么痕迹、请求怎么设计才好判定、结果怎么记下来才算证据。

你花钱买的是某个模型的接口，可返回的结果总觉得哪儿不对：答得浅、风格飘、速度忽快忽慢。这时候光靠「感觉像」没法下结论，也没法拿去跟站长对质。这篇不讲模型原理，只讲怎么设计一次低成本抽样：掺水通常以哪几种形态出现、每种形态在实际调用里会留下什么痕迹、请求怎么设计才好判定、结果怎么记下来才算证据。

先说清一个前提：纯度测试不是去抓现行，而是让你手里的怀疑变得可描述、可复现。你不需要当侦探，只需要在几次调用里攒出一组能摆到桌面上的对照材料。做到这一步，剩下的判断和沟通才有依据。

掺水常见的四种形态，分别改了什么

很多人一上来就问「是不是被换成便宜模型了」，但掺水不止一种手法。同样是「答案不对味」，背后可能是完全不同的改动，对应的验证动作也不一样。先把形态分清楚，后面测什么、看什么才不会乱。

• 换便宜模型：请求发出去、答案也回来了，但整体表达习惯会变，读几段就能感觉到「不像它平时说话的样子」
• 换小模型：短问短答基本看不出来，一旦要求多步推理或长约束，就开始漏条件、少步骤
• 路由到低配渠道：模型标识没变，表现却是随机性的，今天好明天差，重复跑也复现不了
• 限速降质：这类问题不表现为答错，而是慢、短、被截断，容易被误当成网络问题

分形态的意义在于：不同形态要用不同的题去逼它露馅。想测换模型，就得用能体现能力下限的题；想测渠道波动，就得靠重复调用看离散度。用错方法，测试结论会互相干扰。

每种形态留下什么可观测信号

掺水不会写在返回里，但它一定会在某些可观测维度上留下偏移。关键是分清哪些信号是单次的、不可靠的，哪些是重复出现的、能当证据用的。下面这几类信号，优先级从高到低。

• 看指令遵循：给一条带硬性格式约束的请求，正常模型会稳定照做，低档模型更容易只做一半
• 看上下文利用：把关键信息放在长输入的中段，让它只依据这段回答，被替换或截断时更容易漏掉
• 看波动模式：单次差异说明不了问题，要同一请求在不同时间点多跑几次，看偏差是偶发还是稳定出现
• 看响应元信息：返回里的模型标识、用量字段、结束原因可以对照，但这些字段本身也可能被中转层改写，只能当参考不能当铁证

还有一个容易被忽略的信号是响应长度分布。换小模型之后，答案往往变短、变套路化，尤其在开放问题上不再展开。这个变化单看一两次没意义，但如果你把一批同类请求的响应字数排出来，分布明显整体左移，那比单看内容更客观。

怎么设计一次可判定的抽样请求

纯度测试最怕的就是题出得没法判。你用开放式闲聊去测，出来的差异只能靠口味解释，站长一句「模型本来就随机」就把你顶回来了。所以请求设计要围绕「可判定」两个字来做。

1. 挑可判对错的题用有唯一正确答案或明确格式要求的题，比如固定字段的抽取、指定结构的输出，别用「写个故事」这种没法判定的任务
2. 控制变量同一份请求内容、同样的参数、同样的时间间隔跑一轮，中途不要改温度、不要改长度上限，否则波动归因不清
3. 分两层测一层测能力下限，上复杂推理和长指令；一层测稳定性，同一请求重复几次看离散度，两层分开记录
4. 留一个对照手上有官方渠道或其他家同模型结果时就用它当基准，比自己凭空感觉靠谱得多

如果条件允许，把对照请求写成固定脚本，参数全部写死，每次跑完把原始响应落到文件里。这一步不复杂，但能让你的测试从「我觉得」升级成「我有记录」，后面无论是自查还是找站长沟通，都省很多口舌。

怎么记录，什么结果算异常

记录方式决定了你的测试有没有价值。截图一段结论最省事，但也最没用，因为它不可复现、无法对比。真正要留下的是能重新跑一遍的东西。

请求原文

完整的输入内容和全部参数，不含省略

完整响应

原样保存，不要只截一段或改写后再贴

调用时间与延迟

记录发生时点和耗时，用于排趋势和排查时段性问题

重复次数

同一请求跑了几遍，决定了这次测试的可信度

判定之后别急着说「这个站掺水」。先排除自己这边的原因：并发是不是打满了、有没有走缓存、参数是不是写错了。这些都会造成和掺水一模一样的表象。排除完再去站内做交叉验证，比如到工具目录里的测试工具重跑一遍，或去看这个站的其他维度记录，把结论建立在多来源上。

纯度测试的产出不是一句「它掺水了」，而是一组别人能重跑、能对照的记录。