跳到主要内容

6 篇博文 含有标签「model-evaluation」

查看所有标签

量化质量悬崖:当 int4 通过中位数评估却在长尾场景失效时

· 阅读需 13 分钟
Tian Pan
Software Engineer

一个团队将 fp16 模型更换为 int4 量化模型,以将推理成本减半。评估套件在精心挑选的测试集上的得分与原始模型相比差距不到一个百分点。于是,在“基准测试表现无差异”的理由下,模型正式发布。六个星期后,支持团队收到了受监管客户关于灾难性故障的反馈——生成的代码完全是胡言乱语,低资源语言的回复漂移到了另一种文字,多步算术运算自信地给出了偏差一个数量级的数字。基准测试没有撒谎。它只是测量了中位数,而量化并不是对中位数的均匀征税,它是对长尾分布的非均匀征税。

这就是量化质量悬崖:你的评估套件、发布纪律和成本节约叙事同时崩溃,因为你用来批准更换的指标,对于你所摧毁的能力完全没有信号反馈。最近的基准测试让这种影响变得具体。在长上下文任务中,8-bit 量化保留了准确性,仅下降了约 0.8%,而 4-bit 方法在相同工作负载下损失高达 59%——这种退化对于任何没有对长尾输入进行过采样(oversample)的测试集来说都是不可见的。中位数移动了一个点,而长尾移动了十五、三十甚至五十个点。

权重中的幽灵:预训练残留如何在生产环境中破坏你的微调模型

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的微调模型在评估套件上达到了 93% 的准确率。你将其上线。三周后,一位客户发来截图:模型以十足的自信回答了一个从未出现在训练数据中的问题——而且答错了。这并非通常意义上的幻觉,而是一段记忆。一种在预训练阶段烙入权重的模式,在微调从未覆盖的分布上死灰复燃。这就是预训练残留(pretraining residue),也是生产微调中最容易被忽视的故障模式之一。

微调调整的是权重,而不是从头重新训练模型。在万亿 token 规模预训练期间形成的模式——校准机制、置信度信号、世界模型先验——依然留存于权重之中。无论你的微调数据集多么精心策划,它都只是叠加在更深层先验之上的薄薄一层。当输入落在你的微调分布之外时,模型不会说"我不知道",而是回溯到预训练,自信地给出答案。

你的供应商模型卡没有告诉你的事

· 阅读需 11 分钟
Tian Pan
Software Engineer

模型卡会告诉你该模型在 MMLU 上得分 88.7 分。但它不会告诉你:该模型会系统性地将责任归咎于可能性列表中最先出现的技术,导致约 10% 的归因答案在事实正确的情况下语义却是错误的。它不会告诉你:在系统提示中加入"你是一个有帮助的助手",与留空系统提示相比,会降低结构化推理任务的性能。它不会告诉你:在高负载下第 99 百分位延迟是中位数的 4 倍,也不会告诉你:模型在法律和金融查询上的行为,会因你是否包含合规免责声明而发生明显变化。

这些内容都不在模型卡里。你需要将系统部署到生产环境,然后亲眼看着问题出现,才能学到这些。

能力激发差距:升级到更新模型为何会破坏你的产品

· 阅读需 10 分钟
Tian Pan
Software Engineer

你升级到了最新模型,结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高,能处理更难的问题,拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力?退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出,而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感,现在像是在自动驾驶。

这就是能力激发差距:模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环,这个差距系统性地扩大。

校准差距:你的 LLM 说有 90% 的把握,但实际上只有 60% 的准确率

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的语言模型告诉你,它有 93% 的把握认为 Geoffrey Hinton 在 2010 年获得了 IEEE Frank Rosenblatt 奖。然而实际的获奖者是 Michio Sugeno。这不是传统意义上的幻觉——模型生成了一个听起来合情合理的答案,并给它附上了一个高置信度分数。问题在于,这个置信度数字本身就是谎言。

这种声称的置信度与实际准确率之间的断层,就是所谓的校准差距。它是生产 AI 系统中被严重低估的故障模式之一。那些在原始模型置信度分数之上构建路由逻辑、升级触发器或用户可见置信度指示的团队,是在沙滩上建楼。

能力探测:在用户发现之前绘制模型的能力边界

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数团队发现模型局限性的方式和用户一样 —— 在生产环境中,通过工单。客户反映提取流水线悄悄丢失了嵌套地址。内部用户注意到摘要器在超过 8,000 个 token 后开始虚构日期。合规审查发现分类器自信地为模糊案例打上标签,而不是选择放弃判断。

这些都不是意外。它们是一直存在的能力边界,只是在等待合适的输入来暴露它们。你要么在部署前绘制这些边界,要么让用户替你绘制 —— 一次一个事故。

系统性地发现这些边界的方法就是能力探测 —— 语言模型的故障注入。你不会在没有对接缝进行负载测试的情况下交付一座桥梁。同样的逻辑适用于任何面向用户的模型。