YouTube··7 天前
你的智能体修复改坏了别的东西——Sofia Jakovcevic,Arize AI
Your Agent Fix Just Broke Something Else - Sofia Jakovcevic, Arize AI
Arize AI 的前置部署工程师 Sofia Jakovcevic 以一处一行提示词改动使客服智能体安全性提高 17 个百分点、完成任务能力下降 17 个百分点为例,说明智能体是在运行时而非在代码中失败。她介绍一套基于生产追踪数据构建的五步回归流程:整理数据集、用评估器打分、运行基线实验、比较改动、在 CI 中卡住合并,并演示如何用编码智能体读取追踪数据自我修复。
- 分级
- 值得看
- 收录时间
- 2026-10-26
推荐阅读
AI 工程师现在做什么?——Aparna Dhinakaran,Arize AI
What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI
Arize AI 的 Aparna Dhinakaran 讨论在领域从编写功能转向运行智能体工厂的过程中,AI 工程师的实际工作是什么,认为当前的任务是构建闭环:评估非确定性工作的评测、智能体消费的遥测,以及据此行动的智能体。她介绍 Arize 如何构建常驻智能体 Signal,用于读取追踪数据、记住以往问题并提交 PR,内容涉及触发条件、沙箱、持久状态以及如何评估评估器。
没有基准时如何测试 AI 代理——Air Canada 的 Nathanael Weill
How to Test AI Agents When No Benchmark Exists — Nathanael Weill, Air Canada
演讲者带领 Air Canada 的 AI 代理团队,面对任务过于具体、没有公开基准且领域专家无暇评分的问题,他的做法是“先写答案”:从已知答案出发生成输入,再看代理能否找回该答案。这使一个 RAG 项目从每周一次专家评分测试提升到每天数十次自动化测试;随后他把方法用于供应商合同审查代理,给出五种构建测试集的方式:过往决策、植入规则违规、删除条款、不应产生影响的变化,以及填空式合同模板。他还解释了为何在代码能校验答案时避免使用 LLM 评审。
“难以评估”是一种产品缺陷信号
“It's Hard to Eval” Is a Product Smell
作者 Hamel Husain 基于三年做 AI 评估的经验,认为“我们的产品很难评估”这一常见说法本身反映了产品设计问题:用户难以验证的输出,用户往往同样难以验证,最坏情况下只能从头重做一遍。文章主张在设计评估之前,应先把产品做成易于验证的形式,并通过他参与顾问的三个产品案例,配以改动前后的设计草图来说明原则,最后讨论如何把这一模式应用到其他产品。文中第一个例子是 AI 数据代理,指出只输出最终答案会导致用户无法核对。适合负责 AI 产品设计与评估的人阅读。
Claude 抓到了 Claude 在浪费 token
Claude caught Claude wasting tokens
一篇 r/ClaudeAI 社区帖子,作者自建了一个语音触发 CLI 工具(STT→服务器→Claude Code→TTS),某次测试后由另一个 Claude 会话读取日志,发现模型首轮运行 72 秒、输出约 8000 个 token 的纯文本,内容几乎全是零宽 Unicode 字符,没有工具调用,因此用户什么也没听到。帖子记录了该轮日志约 8002 个输出 token、估算成本约 0.24 美元。适合用 Claude Code 搭建语音代理或关心 token 消耗排查的人阅读。
别轻信你的 AI 智能体,像科学家一样测试它们——Stephanie Jarmak,Omni Analytics
Don't Trust Your AI Agents. Test Them Like a Scientist — Stephanie Jarmak, Omni Analytics
讲者 Stephanie Jarmak 曾在 Sourcegraph 构建大型编码基准,现于 Omni Analytics 做评测工作。她在演讲中指出多数智能体评测容易被误读,例如仅更换评测框架就让结果变化 30%;主张把公开基准用于初筛而非决策,并像做实验一样设计自建评测:真实任务、重复运行、完整追踪和与关注目标匹配的度量。还涉及质量门禁、人工复核瓶颈以及生产环境才是最终检验等话题。
1368 起 AI 失败案例及其对评估的启示 — Vishal Srivastava(纽约人寿)& Tanmay Sah
1,368 AI Failures and What They Teach About Evals — Vishal Srivastava, New York Life & Tanmay Sah
这是一段会议演讲录像,讲者分析了公共 AI 事故数据库中的 1368 起事件,考察真实失败能为 AI 系统测试方式提供什么启示。他们把失败归入技术能力、部署管控和业务影响三个维度及 13 个子类别(覆盖约 98% 的事故),指出人工复核、监控等部署管控薄弱与危害关联最紧密,并介绍了按风险大小排序用例、检验评估器本身、以及用“构建—攻破—修复”循环主动找系统错误的方法,最后以一家航空公司聊天机器人给出错误退款政策为例。材料未说明适合谁读。