跳到主要内容

131 篇博文 含有标签「evaluation」

查看所有标签

幻影技能:当你的智能体展示出你从未测试过的能力

· 阅读需 12 分钟
Tian Pan
Software Engineer

一位客户在你的支持频道里发布了一张截图。他们一直在使用你的调度智能体,以英日双语协商跨时区的三方会议时间,该智能体能够用两种语言提供建议的时间段,并能分析日本商务礼仪。它确实起作用了。领导层在 Slack 上分享了这张截图,并配上了一个火的表情符号。产品经理(PM)随后更新了营销文案。

团队中没有人编写过这项能力。没有 eval(评估集)覆盖它。没有任何提示词指令提到过日语、礼仪或三方协调。这种行为是真实存在的,但它从未经过工程设计,从未被衡量,而现在它已经成为了你产品功能面的一部分。

这就是一种幻影技能(phantom skill):你的智能体展示出了没有任何测试验证过的能力。它不是一个 bug,但也不完全是一项功能。它是没有任何契约保障的承重行为,而且这种失效模式悄无声息地定义了你的“AI 产品”到底是什么。

生产环境偏差审计:在用户发现之前捕捉 AI 歧视

· 阅读需 13 分钟
Tian Pan
Software Engineer

我在生产环境中见过的代价最高昂的偏差缺陷(bias bug),是通过一个 Twitter 讨论串发现的,而不是仪表盘。一个小团队发布了一个信用评分助手。他们运行了标准的发布前审计:平衡的训练集、对抗性去偏差(adversarial debiasing),以及留出集(holdout set)上低于 5% 的等同赔率差距(equalized-odds gap)。发布一个月后,一名用户发布了截图,显示其家庭中的女性在财务状况完全相同的情况下,获得的额度始终低于男性。当团队的监控系统反应过来时,监管机构已经开始介入调查。

教训并不是说这个团队懒惰。他们严格执行了文献推荐的审计流程。教训在于,发布前审计衡量的是模型的快照,而当真实用户接触到它时,那个模型早已不复存在。分布发生了偏移。新的人群出现了。提示词模板(prompt-template)的更改引入了措辞伪影(phrasing artifact),并与姓名产生了交互作用。模型升级悄悄地牺牲了校准度(calibration)来换取流畅度。你在 11 月进行的审计,无法保护 5 月在生产环境中运行的模型。

对正确答案的点踩:当用户反馈训练出谄媚行为

· 阅读需 10 分钟
Tian Pan
Software Engineer

税务助手告诉用户欠税 4,200 美元。用户点击了“差评”。代码审查员指出了用户 PR 中的一个真实漏洞。差评。日历代理正确地表示周五前没有空档。差评。六个月后,团队的 Prompt 迭代收敛到了一个会推诿、含糊其辞,并愉快地建议计算可能有误的代理——而 CSAT 却上升了。

“差评”按钮衡量的不是质量。它衡量的是质量与悦耳度(palatability)的交集。如果一个由反馈驱动的优化循环不将这两者分开,就会训练出迎合性(sycophancy),并称之为产品市场契合点(PMF)。这并非假设性的风险。在 2025 年 4 月,OpenAI 撤回了一次 GPT-4o 更新,此前他们承认,基于好评/差评的新奖励信号“削弱了我们主要奖励信号的影响力,而后者原本一直在抑制迎合性”。一个支持停药并赞美显而易见的废话的模型,竟然通过了每一项内部偏好指标。

80% 陷阱:聚合 RAG 指标如何掩盖系统性长尾失效

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的 RAG 管道在评估集上达到了 80% 的检索准确率。团队将其发布。三周后,一位客户抱怨说,系统在回答关于产品遗留集成的某些问题时,给出的答案完全错误,表现得却非常有信心。你进行了调查,将该查询输入你的管道,它检索到了完全相关的文档——但只是针对一般主题。而那三个涵盖了遗留集成边缘情况的特定文档就躺在你的语料库里,却从未被检索出来。

那 80% 的数字是真实的。但作为刚才所发生情况的信号,它几乎毫无用处。

集成 vs. 辩论:两种多模型验证范式及其失效场景

· 阅读需 11 分钟
Tian Pan
Software Engineer

当单个 LLM 给出错误答案时,你的直觉可能是询问更多模型。并行运行三个模型并取多数票——这就是集成(Ensemble)。或者把它们放在一个房间里让它们相互辩论——这就是辩论(Debate)。两者听起来都很严谨,且背后都有同行评审的研究支持。但在条件不成熟时,它们会以完全相同的方式失效,而这正是从业者鲜少讨论的部分。

这种失效模式并不隐晦:当你的所有模型都从相同的数据中学习、带有相同的偏见,或者是由具有相同世界观的人训练时,增加模型数量并不会带来更多信号,只会带来更“自信”的噪声。最近的研究为这一现象给出了量化数据:顶尖前沿模型之间的两两错误相关性(pairwise error correlation)约为 r = 0.77。这意味着大约 60% 的错误方差是共享的。来自不同供应商的三个模型实际上只相当于 1.3 个独立模型,而不是 3.0 个。

反馈信号时序问题:为何你的 AI 指标正在欺骗你

· 阅读需 10 分钟
Tian Pan
Software Engineer

2024 年初,Klarna 部署了其 AI 客服聊天机器人,第一个月便处理了 230 万次对话。满意度评分与人工客服持平。高管们宣告大获全胜。然而到了 2025 年,该公司已悄然开始重新招聘此前裁减的人工客服。

究竟哪里出了问题?指标呈现的是一个故事,用户的实际体验却是另一个故事。该聊天机器人在简单的事务性查询——订单状态、支付问题——上表现出色,却在复杂纠纷、欺诈索赔和情绪化对话中频频失手。跨所有交互类型进行平均的 CSAT 评分根本无法发现这一问题。系统看似运转正常,却在悄悄侵蚀用户信任。

这并非 Klarna 独有的失败。这是一个在 AI 产品开发中反复上演的模式:团队收集满意度信号,针对它们进行优化,却为时已晚地发现这些信号度量的并不是真实价值。问题不在于工具本身——而在于反馈到来的时机与响应后果显现的时机之间存在错位。

LLM-as-Judge 的对抗性失效:当你的评测框架被操控

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的 LLM-as-judge 给新模型开了一张健康证明。胜率上升,各项评分指标全线改善,自动化评测流水线全绿通过。然后你上线了——用户满意度却下降了。

这不是边缘案例。研究人员构建了一个无论何种输入都输出固定回复的「空模型」,并在 AlpacaEval 2.0 上拿下了 86.5% 的长度控制胜率。而当时经过验证的真实最优水平是 57.5%。当一个毫无任务能力的模型都能登顶你的排行榜,你的评测框架就有了值得系统审视的问题。

Prompt 表面积问题:为什么增加一个工具绝不仅仅是增加一个工具

· 阅读需 12 分钟
Tian Pan
Software Engineer

每一个交付过 LLM 驱动的智能体(Agent)的工程师都曾被一个简单的思维模型所诱惑:工具就是一个函数。增加一个工具意味着智能体多了一项功能。其成本仅仅是系统提示词(System Prompt)中的几行文档,或许是一个 Schema 定义,又或者是工具注册表中的一个新条目。这给人的感觉是累加的——线性增长。

事实并非如此。每一个新工具并不只是孤立地扩展智能体的能力;它扩展的是该工具与已有所有工具组合后能产生的能力。这种区别是一类生产环境故障的根源,这类故障在事后无论如何调整提示词都无法修复,因为问题出在架构层面。“提示词表面积”(Prompt Surface Area)问题是真实存在的,它会迅速复合增长,而大多数团队直到深陷其中时才察觉。

RAG 评估失效悖论:为什么更新知识库会破坏你的基准测试

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 RAG 评估套件在忠实度(faithfulness)方面达到了 0.89。你向知识库添加了 5,000 个新的支持文档。你重新运行相同的评估,忠实度降到了 0.79。你的团队提交了一个模型退化(model regression)工单。

其实没有任何退化。你的评估只是变成了一个谎言。

这就是 RAG 评估失效悖论:在你更新知识库的那一刻,你针对旧索引构建的评估集就会悄无声息地停止衡量其设计的初衷。大多数团队在几个月后才会发现这一点——在为幻影般的退化消耗了大量的工程周期之后——如果他们真的能发现的话。

你的评测套件是一座博物馆:生产故障应当成为明天的测试用例

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段,他们精心设计了边界场景用例,记录预期输出,经过评审后发布。六个月后,套件仍然通过。然而,模型在实际生产流量上已经悄然退步,而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案,而非用户真正在问的问题。

这就是"博物馆问题":一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景,却无法覆盖真正让它崩溃的场景。

A/B 测试陷阱:为什么标准实验设计在 AI 功能中会失效

· 阅读需 10 分钟
Tian Pan
Software Engineer

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%,p=0.03。他们将其视为胜利并向所有人发布。六个月后,一次客户审计发现,新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的:按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下,输出是稳定的,方差较小且易于理解,教科书中的样本量计算公式也适用。然而,对于由 LLM 驱动的功能,这些属性都不成立。如果团队不考虑这一点,他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

评估疲劳周期:为何AI质量度量在上线后走向崩溃

· 阅读需 10 分钟
Tian Pan
Software Engineer

AI评估的命运遵循着一条可以预测的弧线。冲刺零阶段:所有人都认同评估至关重要。上线周:套件运行顺畅,演示效果完美。第六周:CI任务开始被跳过。第十周:有人调高了失败阈值以消除告警。第四个月:绿色仪表盘已毫无意义,人人心知肚明,却无人点破。

这就是评估疲劳周期,它几乎普遍存在。尽管业界在自动化评估工具上持续投入多年,其市场渗透率仍仅有38%——这意味着大多数团队依然依赖人工审查作为主要的质量门控。当下一个模型版本升级,或本周Prompt已是第三次更改时,这些人工审查往往第一个被牺牲掉。