[控场AI]
· 5 分钟阅读· 2,578 字

免费模型可信吗?先跑个A/A测试再下结论

免费模型可信吗?先跑个A/A测试再下结论

用A/A测试先测LLM采样噪声,再决定免费模型能否用于评测。

文章指出,用免费模型替换付费接口后跑一次测试套件就下结论,忽略了单次运行只是非确定性系统的一个样本。正确做法是先做A/A测试:用同一提示词重复调用k次,对归一化文本取SHA256指纹,统计modal_share(最常出现答案占比)和distinct(不同答案数),衡量框架自身的噪声水平。temperature=0并不保证确定性,共享推理栈的批处理、归约顺序和模型轮换都会引入方差。文章给出一张基于modal_share的分诊表,说明不同一致性区间分别支持哪些评测方式,并强调高一致性不等于高质量,A/A安静后才能跑B/B测试判断正确性。

免费模型A/A测试

用免费模型替换付费接口,跑一遍测试套件,然后发博客宣布“行”或“不行”——这种评测模式忽略了一个前提:单次运行非确定性系统得到的只是一个样本,而非测量结果。如果免费层和付费层的采样方式不同,两个样本的比较就如同两次抛硬币,却被当成了实验证据。

A/A测试:在比较之前先测量噪声

A/B测试只有在测试框架本身安静时才有意义。A/A测试就是那个对照组:它告诉你框架自身有多吵。如果五次相同的调用返回五段不同的文本,那么基于diff的回归套件测量的其实是采样噪声,却被当成了回归。

温度设为0并不能解决这个问题。共享推理栈会批处理和重排任务,内核以不同顺序做归约,不少供应商还会在稳定别名背后悄悄轮换模型。temperature=0下的确定性只是一个常见假设,不是保证。

这个特性反过来也是礼物:指纹探针同时是一种绊线。如果未变更的输入突然导致一致性崩塌,说明上游有东西变了,而且不是你的提示词。

探针脚本

整个实验只需要一个小脚本:一个提示词、k次重复、一行JSON输出。它假设OpenAI兼容的/chat/completions接口。

核心逻辑是:对每次返回的文本做归一化(小写、去标点、压缩空白),然后取SHA256指纹。用collections.Counter统计指纹分布,输出modal_share(最常出现答案的占比)和distinct(不同答案数)。归一化刻意粗放,因为要测的是行为,不是措辞。

SHA256指纹在这里的作用是把一段任意长度的归一化文本映射为固定长度的十六进制串,且碰撞概率可忽略。对评测而言,它的价值不在于加密安全,而在于做"精确相等"的高效代理:两条返回文本只要归一化后完全一致,指纹就一致;只要有一个字符不同,指纹几乎必然不同。这让你能用Counter直接统计"有多少次调用返回了完全相同的那一段文本",而不必做逐字符比较或语义相似度计算。需要注意的是,指纹只捕捉字面一致性,不捕捉语义等价——两个指纹不同不代表答案在语义上不同,这正是归一化要尽量粗放(小写、去标点、压缩空白)的原因:先把无关的格式差异抹掉,剩下的差异才更可能反映真实的采样分歧。

让它成为一周记录

一次探针运行只能说明共享硬件上某个瞬间的情况。按计划运行才有价值:得到框架诚实度的时间序列。

脚本用sha256sum对提示词文件取哈希并写入每条记录。提示词一改动,指纹历史就在那个版本处干净断裂,而不是在底下悄悄漂移。这和冻结配置哈希是同一种纪律:运行必须先挣得比较的资格。

这类任务适合放在笔记本之外的地方运行——这正是免费层的用武之地。MonkeyCode提供免费模型访问和免费服务器选项,足够托管一个探针循环并在你忙别的事时收集样本。(披露:本文为MonkeyCode产品推广的一部分。)

但共享服务器有个警告:不要对着它跑延迟基准测试,然后把数字当作模型的属性来报告。你测的是邻居的负载。

非确定性系统指在相同输入下可能产生不同输出的计算系统。对于LLM推理,非确定性来源包括:GPU并行归约的浮点加法顺序不固定、批处理调度导致不同请求共享不同的计算图路径、以及采样温度大于零时的随机采样。即便temperature=0,浮点运算的结合律不成立也会让logits出现微小差异,进而在接近的候选token之间翻转argmax结果。共享推理栈进一步放大了这一点:连续批处理(continuous batching)会把不同用户的请求动态拼进同一批次,矩阵乘法的分块与归约顺序随批次组成变化,导致同一提示词在不同时刻可能落到不同的计算路径上。因此,把单次API调用视为对模型行为的"测量",在统计上是不成立的——它只是一个带噪样本。

读自己的数字:一张分诊表

以下是基于modal_share(temp 0, k=5)的建议启发式,不是实测常数,请用你自己的负载校准后再引用:

  • 1.0:支持精确文本回归diff;不支持任何语义等价判断。
  • 0.8–0.99:支持k≥3的pass@k和可diff的错误分类;不支持单次运行的通过/失败门禁。
  • 0.4–0.79:支持多提示词上的聚合分数;不支持任何逐提示词裁决。
  • < 0.4:仅适合起草、头脑风暴、分诊;不适合评测、CI门禁或任何可审计场景。

高一致性不是质量信号。模型可以完全一致地持续犯错——那是B/B测试要解决的问题,而B/B测试必须等A/A安静了才能跑。一致性是地基,不是你要报告的分数。

pass@k是代码生成评测中常用的指标:对同一问题采样k次,只要其中任意一次通过单元测试,就算该问题通过。它衡量的是"模型在k次尝试内解决问题的概率",而不是单次准确率。这与本文的A/A框架直接相关:pass@k本身就承认了单次运行是随机样本,因此它要求k≥3才有统计意义。但pass@k成立的前提是各次采样相互独立且分布稳定——如果modal_share只有0.5,k次采样中"至少一次正确"的概率估计会极不稳定,跨运行比较pass@k就失去了意义。换句话说,pass@k是建立在"采样噪声已被表征"之上的指标,而不是用来表征噪声的工具。

哪里会失效,谁该走开

Token核算是薄弱环节。如果接口不返回usage块,你用本地分词器测的token数可能和服务器不一致,跨两个不匹配的分词器做预算比较比不比较还糟。要么两边都测usage,要么彻底放弃token列并明说。

这个方法也不适合所有人。需要固定模型版本、正常运行时间承诺或亚秒级p99延迟的场景,共享免费层就是错误的工具——不是因为它差,而是那些是合同问题,不是实验问题。受监管的产品更需要警惕:一个方差尚未表征的评测系统,是一个带仪表盘的负债。

真正要带走的心得比“试试免费层”更窄:一个方差特征已知的免费模型,比一个你从未探测过的付费模型更有用,因为只有前者能让你区分回归和重掷。无论最终选哪边,先跑一周探针——你得到的一致性率,才是真正的起跑线。

#A/A测试#免费模型评测#LLM一致性#modal_share#模型回归测试#temperature=0#采样噪声#模型探针
分享:

相关推荐