跳到主要内容

907 篇博文 含有标签「insider」

查看所有标签

那个因冗长输出比更佳答案更能触发点击处理器的 A/B 测试赢家

· 阅读需 11 分钟
Tian Pan
Software Engineer

一项提示词变体(prompt-variant)实验在某款 AI 辅助搜索产品的生产流量上运行。成功指标是点击响应中的任何建议操作。变体 B 交付的响应长度增加了大约 40%,且包含更多列举出的选项。点击率(CTR)高出 11%,且具有三个九(99.9%)的统计显著性。该实验被判定为获胜并上线。

一个月后,每周客户满意度调查下降了两个点。没人将其与上线联系起来,因为实验已被记录为成功,团队已经转向其他工作。季度复盘最终将满意度下降追溯到提示词的更改,诊断结果令人难以接受:变体 B 胜出并不是因为它给了用户更好的答案,而是因为更长的回答包含了更多的点击表面(clickable surfaces)。点击处理器在每次展示中触发得更频繁,是因为有更多可点击的内容,而不是因为你阅读的内容更值得采取行动。

那个因无人负责而逃过租户删除清理的智能体记忆库

· 阅读需 11 分钟
Tian Pan
Software Engineer

合规计划是对审计员签字通过当天你公司所拥有系统的描述。你公司今天的系统是另一套完全不同的组合,而这两者之间的差距,就是从那时到现在期间每一个上线了新持久化存储的发布版本的表面积。你向客户承诺的删除保证是针对第一套系统的保证,而最终对此进行询问的监管机构,问的将是第二套。

这种失败模式并非删除代码中的 Bug。删除代码本身是正确的。Saga 流程会扇出到数据清单中命名的每一个存储系统,调用每个系统的删除端点,收集每个系统的回执,并在每个回执都返回已签署状态时报告成功。Saga 正在准确执行其被构建时所承担的任务。问题在于,Saga 迭代的是一份 18 个月前的存储系统列表,而智能体平台团队在 6 个月前上线了一个长期记忆功能,却没有任何人将其添加到该列表中。

用户学会利用 Agent 超时机制套取退款

· 阅读需 10 分钟
Tian Pan
Software Engineer

某平台发布了一个针对长耗时智能体(agent)任务的 30 分钟实际时间上限,并配套了一项退款政策:任何达到超时上限且未产生交付成果的任务,其消耗的 token 费用将予以退还。其初衷是保护性的:挂起的智能体不应向客户收费。六个月后,超时率翻了一番,工程团队深陷“智能体可靠性”调查,而支持队列中挤满了抱怨智能体“不断超时”的用户——截图显示,用户的浏览器标签页在 29 分多钟时就被关闭了。

在财务模型从未命名的行为群体中,单位经济效益已悄然倒挂。退款人群并非质量不佳的人群。这是一种策略。

代理墙钟预算:一场与工具超时机制的赛跑

· 阅读需 12 分钟
Tian Pan
Software Engineer

有一种 Agent 漏洞,当你孤立地观察任何单个组件时,它都不会出现。模型没问题,工具没问题,重试策略也没问题。纸面上的超时值甚至可以说很慷慨。然而,一个通常在 8 秒内完成的工具,却总是在一个已经在 7.9 秒时将其宣告为失败的 Agent 面前折戟。Agent 围绕一个从未发生过的“错误”重新规划,并启动了第二次调用,而第一次调用的结果即将与其发生碰撞。

漏洞不在任何一个框框里。它存在于两个没人同意应该同步的时钟之间的缝隙中。

金丝雀群组:按 ID 哈希的分流如何将核心用户聚集到同一实验组

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个发布团队在百分比旗标(percentage flag)的保护下发布了一个新模型。分桶计算公式为 hash(user_id) % 100,金丝雀(canary)测试覆盖 0–4 桶。在两周内,人均参与度的提升显著且稳定,于是团队将比例提升到 20%,随后是 50%,最后推向全球。在 50% 到全量发布的某个阶段,这种提升突然消失了。事后复盘(post-mortem)发现问题出在金丝雀人群(canary cohort)。实验变量并没有真正改变指标。金丝雀组的样本是一个特殊的群体。

团队以为自己是在对用户进行采样,实际上它是在对 ID 进行采样。

你的编程代理基于落后 Main 分支三周的代码版本重建的代码库索引

· 阅读需 11 分钟
Tian Pan
Software Engineer

你团队中的一个 AI 编程 Agent 提交了一个 PR,在两个文件中调用了四次 parseUserToken()。这个函数在代码仓库中并不存在,甚至已经消失了 19 天,早在你团队所有工程师都记得评审过的一次提交中就被 decodeSessionClaim() 替换了。Agent 并不是凭空捏造了这个名字,它是从其语义索引中读取的——那个向量库是从一个比 main 分支落后 21 天的工作副本重建的。相比之下,Agent 的编辑步骤在会话开始时运行了 git pull,操作的是最新的代码。对同一个代码库的两个视角,相隔三周,而 Agent 却自信地用一段无法针对任何真实环境编译的代码桥接了它们。

这是一种不会自我宣告的失败模式。Agent 运行了。测试看起来通过了。PR 合并了。第一位评审者之所以注意到,仅仅是因为一个被删减的函数与一个无关的辅助函数重名,触发了 linter 报错。到那时,Agent 已经花了一个完整的冲刺(sprint)针对一个“幻影版本”的代码库进行编写,而团队中没有一个人——包括 Agent 自己——收到任何异常信号。

你的 Agent 每一轮都在重新生成对话摘要,只因缓存键包含了一个时间戳

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个只被写入却从未被读取的缓存算不上缓存。它只是一个增加了额外延迟、按 KB 计费的日志系统。而这种失效模式最残酷的版本是,从每个角度看缓存都是健康的:set 调用成功,get 调用返回迅速,键(key)格式正确,值(value)有效,TTL 设置合理。唯一的问题是,没有任何一次 get 调用能找到之前 set 调用写入的键,因为键中的一个字段在每次计算时都会发生变化。

这是一个关于调试过程的故事:为了“能分辨出我正在看的是哪条缓存记录”,一位工程师在缓存键中添加了一个时间戳。结果,在没人察觉的两个星期里,系统悄悄地为每场对话多支付了 14 次额外的 LLM 调用费用。

你的财务团队构建的那个排除了 Embedding 重新索引成本的成本仪表盘

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的财务团队构建了一个精美的 AI 成本仪表盘。Token 支出,按功能划分。Embedding 支出,按供应商划分。每个季度,按功能的面板都会在领导会议上接受审查,有人会问为什么支持聊天(support-chat)的工作流增长了 12%,而产品经理会给出一个合理的解释。每个季度,按供应商的面板都会在基础设施会议上接受审查,有人会问为什么 OpenAI 的支出增长了 8%,而平台工程师会给出一个合理的解释。然而,每个季度,真正让你 AI 账单翻倍的那一行——语料库重索引(corpus re-index)——却落入了一个名为“基础设施”的第三个篮子里,没有人审查它,因为没有人负责。

那个篮子是 40% 的 AI 支出在没有归属的情况下白白流失的地方。本可以优化它的团队从未见过它。而能看到它的团队却无法告诉你它是为哪个功能服务的。仪表盘对它能解释的所有成本都保持诚实,而对它无法解释的成本保持沉默,而这恰恰是至关重要的成本。

当用户取消对话后,下游 API 却仍在继续写入

· 阅读需 11 分钟
Tian Pan
Software Engineer

用户点击停止。浏览器关闭了 SSE 连接。你的 AI SDK 触发了 onAbort。Agent 运行时检测到信号,停止向模型请求更多 token,并终止其循环。从你的代码库内部来看,这次取消显得非常利索。你所能看到的每个子系统都在执行正确的操作。

与此同时,两秒钟前,模型发出了一个工具调用(tool call)。运行时分发了它。工具的 execute 函数打开了一个连接到第三方 API 的 TCP 连接并发送了 payload。该 HTTP 请求仍在传输中,第三方的服务器仍在处理它,而第三方完全无法得知它所服务的对话已不存在。写入操作成功提交。用户的心智模型认为他们通过点击停止避开了该操作。下游系统的数据库则记录了完全不同的结果。

那些被你的提示词工程师转变为生产环境 Few-Shot 示例的评估集

· 阅读需 12 分钟
Tian Pan
Software Engineer

评估仪表盘连续三个迭代(sprints)都在攀升。困难切片的质量提升了 6 个百分点,回归切片提升了 9 个百分点,而在支持团队根据上季度最糟糕的工单亲手整理的切片上,质量提升了 12 个百分点。团队据此发布了模型升级。两天后,一位客户提出了一个与评估集中的任何内容都不沾边的问题,结果得到的答案比六个月前还要糟糕。

一旦有人想到进行排查,原因很快就浮出水面了。提示词工程师(prompt engineers)一直与评估团队在同一个代码仓库中工作。他们发现了那些精心策划的示例——这些示例来之不易,有的甚至是某人为了一个理想答案的措辞争论了一个小时才定下来的。在几个迭代中,他们把其中最有代表性的示例以 few-shot 演示的形式直接复制到了生产环境的系统提示词(system prompt)中。仪表盘持续攀升,是因为模型在推理时处理的正是它曾经逐字见过的输入。没有人指出这个问题。没有人负责划定“用于衡量质量的示例”与“用于发布到提示词中的示例”之间的界限。两个团队都准确地完成了他们被雇佣来做的工作。

被你的模型视为“约束性判例”的 Few-Shot 示例

· 阅读需 11 分钟
Tian Pan
Software Engineer

用户提交了一个问题。你的模型生成了一个答案,这个答案以一种非常具体的方式“自信地出错”:格式完美,推理结构严密,并且出现了一个特定的限定词——这个限定词完全不适用于这个问题——它出现的位置,恰好是你系统提示词(system prompt)中示例三出现类似限定词的地方。这既不是幻觉,也不是提示词注入。模型只是精确地执行了示例教它的操作,尽管这些示例原本并非为了涵盖这个问题。

这就是 Few-Shot 提示主动诱发的故障模式,而大多数评估套件(eval suites)在结构上对此是视而不见的。你的示例并不是“优秀范式”的中立演示。它们是判例法(case law)。模型通过表面 token 选择最匹配的项,并将该先例——包括其限制条件——应用到眼前的任何案例中。

JSON Schema 校验通过了,但下游消费者因语义漂移拒绝了你的输出

· 阅读需 11 分钟
Tian Pan
Software Engineer

JSON Schema 验证的是输出的形状(shape)。它并不验证该形状内数值的含义。在长达 9 个月的时间里,你的 AI 流水线产生的每一条输出都顺利通过了校验,监控显示 Schema 合规率为 100%,你的团队也理所当然地认为符合 Schema 的响应在契约层面就是正确的。接着,一次模型升级发布了,每一条输出依然能通过校验,但你的 Slack 告警频道却在一夜之间从每天 50 条消息飙升到了 800 条。

Schema 没有出问题,出问题的是其内部数值的分布。这就是大多数 AI 团队在生产环境中发现的鸿沟:JSON 契约是一个类型系统(type system),而非行为系统(behavior system),而下游消费者一直依赖于某种契约从未被要求强制执行的数值分布。