跳到主要内容

21 篇博文 含有标签「llm-evaluation」

查看所有标签

“无助但安全”的失败:为什么拒绝率是错误的安全性指标

· 阅读需 10 分钟
Tian Pan
Software Engineer

有一类 LLM 失败,既不会出现在安全仪表板上,也不会触发故障工单。模型委婉地表示拒绝,并引用了一个听起来合理的政策。它提供了一段长达四段的对冲陈述,而不是直接给出答案。用户关闭了标签页。事后分析中的信任评分显示“无事故”。然而,六周后的留存率图表却显示了另一番景象。

拒绝率是大多数安全团队首先部署的指标,因为它最容易定义。模型要么遵循了指令,要么没有,而你可以统计那些“没有”的情况。这种二元法对于捕捉一种特定失败非常有用——即模型在生产环境中生成有害内容。但在结构上,它无法捕捉相反的失败:模型在生产环境中没有产出任何有用的东西,但从各项安全指标来看,它的表现却完美无缺。这种第二类失败现在已成为 AI 功能流失的主要原因,这些功能通过了安全审查,却从未针对“有用性”进行过衡量。

强制一致性偏见:当模型将你的意图向分布众数取整时

· 阅读需 12 分钟
Tian Pan
Software Engineer

一名用户请求“一首关于 Postgres 复制的俳句”。模型返回了一首关于数据库的五行诗,其中提到了服务器和同步,听起来很有信心,读起来像模像样的英语,但并不是俳句。另一名用户请求“一个匹配 IPv6 地址但明确拒绝 IPv4 映射形式的正则表达式”。模型返回了一个匹配 IPv6 地址(包括它被要求拒绝的 IPv4 映射形式)的正则表达式,并用文字断言该正则符合规范。第三名用户请求“仅使用烹饪隐喻来解释 Monad(单子),不提及函数(function)或类型(type)”。模型给出了一个主要基于烹饪的解释,但其中使用了两次“函数”和三次“类型”。

这些都不是拒绝回答。这些也不是明显的幻觉。模型并没有说“我做不到”。它产生了一个自信、格式良好的响应,悄悄地放宽了请求中距离其训练分布众数最远的部分,而用户必须非常仔细地观察才能注意到。这种失效模式有一个值得使用的名称:强制符合偏见 (forced conformance bias) —— 模型将你的意图向典型答案“取整”,用户将结果视为忠实的响应,而本应捕捉到这一问题的评估套件本身也是从典型表述中提取的。

这在通常意义上并不是模型质量问题。模型正在做其训练推动它去做的事情。这是一个产品可靠性问题,如果评估团队的测试用例处于意图分布的众数位置,那么他们实际上只是针对其真实工作负载中简单的后半部分进行校准。

在 AI 功能感觉准备好之前就发布它

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数 AI 功能发布延迟,并不是因为它们有缺陷。它们延迟,是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升,评估指标持续向好。而"实验室表现"与"生产价值"之间的差距,却在悄悄扩大。

令人不安的事实是:最初的 500 名真实用户,在两周内发现的可操作问题,远比再花四周调优提示词要多。这不是在为发布劣质产品辩护,而是在说:你当前对"准备好了"的判断,几乎肯定是错误校准的——只有真实的使用数据才能纠正它。

当 LLM 为自己批改作业:打破 AI 评估中的反馈循环

· 阅读需 11 分钟
Tian Pan
Software Engineer

这是一个大多数 AI 团队都不愿面对的发现:在一项生成了超过 150,000 个评估实例、涵盖 22 个任务的大规模研究中,大约 40% 的 LLM 作为裁判(LLM-as-judge)的对比显示出可衡量的偏见。这种偏见并非随机噪声,而是系统性的、可复现的,并且与模型的训练方式相关。当你使用一个模型来生成评估集,然后使用同一个模型(或其近亲)来对其进行评分时,你测量的并不是质量,而是一个系统与其自身的一致程度。

合成评估数据之所以成为标准实践,是有充分理由的。人工标注速度慢、成本高且难以规模化。LLM 生成的测试用例让团队能够在夜之间生成数千个示例。问题出现在生成器和裁判拥有共同祖先时——在 2025 年,这几乎是常态。结果是一个评估流水线在自信地报告高分的同时,却隐藏了你构建它原本想要捕捉的失败模式。

评估债务棘轮:靠感觉发布 AI 功能的团队如何被技术欠账所困

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个中型公司的团队在发布文档摘要功能三个月后,对提示词进行了优化。新提示词在他们手动测试的 5 个示例上表现更好。他们在周五下午部署了它。周一上午,Slack 里堆满了用户反馈:摘要现在会截断一半文档,却将截断后的内容呈现为完整版本。功能看起来没问题,变更通过了代码审查,没有人发现,因为根本没有评估机制——没有黄金测试集,没有回归基线,没有自动检查。棘轮已经悄悄转动了数月。

这就是评估债务最典型的表现形式。团队跳过评估并非因为粗心大意,而是因为为 AI 功能编写评估比听起来难得多,功能发布快且看起来运行良好,没有人想拖慢一个高速运转的团队。现在,他们正在偿还复利。

置信度描述而非评分:为什么 0.87 的徽章无法打动任何人

· 阅读需 12 分钟
Tian Pan
Software Engineer

产品团队在每个 AI 建议旁边都附带了一个置信度徽章。≥85% 为绿色,60–84% 为黄色,低于此数值为红色。六周后,他们运行了一次 A/B 测试,发现在任何阈值下用户行为都没有变化。置信度为 0.92 的误报被接受的比例与置信度为 0.61 的误报完全相同。团队的直觉是调整校准——拟合一个温度缩放层(temperature scaling layer),重新生成徽章,再次运行 A/B 测试。数据变了,但行为没变。

问题不在于模型没有校准好,尽管它几乎肯定没校准好。问题在于校准后的概率是错误的输出。用户可以据此行动的信号不是模型“有多确定”,而是“模型具体没检查什么”。一个 0.87 的徽章无法告诉用户任何可以验证的信息。“我对地址相当有信心,但我还没有核对单元号”则准确地告诉了他们该看哪里。

反事实日志:通过今天的充足记录,在明年的模型上重放昨天的流量

· 阅读需 14 分钟
Tian Pan
Software Engineer

每个 LLM 团队最终都会收到主管发来的同一封邮件:“Anthropic 发布了新的 Sonnet。用我们的流量跑一下测试,周五前告诉我是否应该切换。”团队打开生产环境的追踪(trace)存储,调取上个月的请求,并针对新模型排队运行——但在运行三小时后,有人发现工具调用环节的差异评分看起来非常离谱。答案是:没有人以原始形式捕捉工具的响应。追踪记录忠实地记录了模型的“回复”,并存储了每个工具返回内容的一行摘要。回放这些请求并不能回放旧模型实际看到的内容;它回放的是一段被严重压缩的投射。迁移评估并不是在衡量新模型,而是在衡量新模型如何与一个不同的现实对话。

这就是我想讨论的失败模式。大多数生产环境的 LLM 日志都是“以输出为导向”的:它们能很好地回答“模型说了什么?”,但只能模糊地回答“模型看到了什么?”。这种不对称性在你需要针对新模型回放历史数据之前是隐形的——到那时,它就成了整个问题的关键,因为日志记录与实际发送内容之间的差距,正是真实评估与虚假评估之间的差距。

称之为反事实日志(counterfactual logging):今天就捕捉那些你明天询问“如果用另一个模型处理这个完全相同的请求,它会做什么?”时所需的输入。标准不是“我们记录了请求”,而是“我们可以针对不同的模型重新执行该请求,并确信结果是有意义的”。

当你的评测结果不一致时:在数据互相矛盾时的一套信号优先级体系

· 阅读需 14 分钟
Tian Pan
Software Engineer

这是周二的早晨,也就是 Prompt 更改上线到一半流量后的那一周。你打开四个仪表板。LLM 评审员(LLM judge)评分的留存黄金集显示 +8%。每周对生产流量进行抽样的真人评估小组显示无变化。下游转化率的 A/B 测试显示 -2%。点赞率(thumbs-up rate)持平。四个信号,四个结论,而十五分钟后就有一个站会,会上有人会问你到底是发布这个 Prompt 还是回滚。

你很容易倾向于选择那个能证实你原本意图的数字——团队也会这样做,因为会议上没有人拥有一套关于哪个信号获胜的书面规则。这种不一致并非测量错误。这是一个在没有层级体系的情况下强行把四个评估器凑在一起的系统的必然产物。缺乏这种体系的代价是,每个发布周都会变成一场关于该信任谁的数据的辩论。

AI 审查 AI:代码审查智能体的非对称架构

· 阅读需 14 分钟
Tian Pan
Software Engineer

如果代码审查流水线中的作者和审阅者都是在重叠语料库上训练的语言模型,那么它就不是一个质量关卡,而是一个信心放大器。作者编写的代码在 Transformer 看来是合理的,审阅者以同样的合理性视角阅读代码,双方最终达成“看起来没问题”的共识,于是代码变更带着一个绿色的勾合并了,而这对于变更是否真正正确毫无意义。最近的行业数据清楚地展示了这种不对称性:在同等规模下,与 AI 共同编写的 PR 产生的严重问题(critical issues)比人类编写的高出约 40%,重大问题(major issues)高出约 70%,其中逻辑和正确性错误占了差距的大部分。而为了捕捉这些错误而发布的审阅代理(reviewer agents),从构造上来说,恰恰是最不具备发现这些错误能力的。

那些从 AI 代码审阅中获得真实信号的团队已经不再将“审阅”视为“生成”的某种变体,而是开始将审阅设计为一种本质上不同的认知任务。生成式提示词(Generation prompting)要求模型产生连贯的内容。而审阅式提示词(Review prompting)则必须要求模型发现缺失的东西——去关注 Diff 中的负空间而不是正空间——这种反向思维比一行系统提示词所暗示的要难诱发得多。

辩论多样性坍塌:当三个智能体投出 3-0 只因它们读过同样的互联网

· 阅读需 13 分钟
Tian Pan
Software Engineer

架构图上写着“三个前沿模型集成、辩论与对齐、多数投票”。追踪记录显示,所有三个智能体在第一轮就达成了一致,并又花了两个回合礼貌地互相转述。评估结果显示比单次调用高出 0.4 分。账单显示成本是 4.2 倍。在这其中的某个环节,有人判定这个委员会运作良好。

多智能体辩论被宣传为一种获取分歧驱动推理的方法:三个大脑相互争论,以获得比其中任何一个单独达到的更好的答案。但这取决于智能体是否真的存在分歧。在重叠的网络语料库上训练、针对重叠的偏好数据集进行指令微调、并针对重叠的安全分类法进行对齐的前沿 LLM,其共享的先验知识远比架构图所承认的要多。在经过一轮“让我们达成一致”之后,你观察到的并不是三种观点向真理汇聚——而是来自同一个分布的三个样本向它们原本就相距不远的众数汇聚。

这种模式在最近的文献中有一个名字:当一个集成的投票分歧率趋于零且与问题难度无关时,你就遇到了辩论多样性崩塌(debate diversity collapse)。委员会仍在投票。但投票已不再携带任何信息。

确认与行动间的鸿沟:智能体的“明白了”并不等同于承诺

· 阅读需 12 分钟
Tian Pan
Software Engineer

Agent 对客户说:“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单,没有 API 调用,退款表中也没有记录。有的只是一段礼貌且自信的英语,以及随后成功的会话终止。

这就是确认与行动的脱节(acknowledgment-action gap),它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在,是因为让经过指令微调(instruction-tuned)的模型显得很能干的流利文字,与真正改变世界的结构化工具调用(tool calls)属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函,下游系统将其解读为承诺,几周后一份支持工单寄来,询问退款去了哪里。令人尴尬的不是模型撒了谎,而是系统被设计成去信任它所说的话。

基准测试泄露:你的评估集是如何悄悄加入训练语料库的

· 阅读需 13 分钟
Tian Pan
Software Engineer

你最信任的基准测试极有可能正是在对你撒谎。公开评估是一个闭环:你发布测试,有人抓取它,下一代模型在抓取的数据上进行训练,于是你信任的衡量标准的分数在没人触碰底层能力的情况下提高了 10 分。测量体系保持不动,而它所测量的对象却在下方发生了偏移,“模型在这个基准测试上表现更好”与“模型在这个任务上表现更好”之间的差距每个季度都在拉大。当这种分歧明显到足以引发争论时,该评估已经发布了六次排行榜更新和三个产品路线图,而这些都假设那个数字是有意义的。

这并非一种假设性的失败模式。非公开的预 RLHF 版 GPT-4 基础模型已被证明能够逐字重现 BIG-Bench 的 canary GUID,Claude 3.5 Sonnet 也是如此,这都表明原本应该被隔离的任务数据最终进入了训练。大约 40% 的 HumanEval 样本被确定为已污染,从 GSM8K 中移除污染子集后,测得的准确率下降了约 13 分。SWE-bench Verified 目前显示有记录的数据泄漏率为 10.6%,OpenAI 在 2025 年末其内部审计发现每个主要的前沿模型都能为某些任务逐字复现金标准补丁(gold patches)后,公开停止了对其的报告。我们用来比较模型的数字正越来越多地变成关于记忆力的数字,而不是能力的数字。