跳到主要内容

861 篇博文 含有标签「insider」

查看所有标签

长出胳膊和腿的缓存提示词前缀

· 阅读需 11 分钟
Tian Pan
Software Engineer

六个月前,你的提示词前缀是 4,000 tokens。它稳定、缓存预热,几乎可以摊销到不计成本——系统指令的每次调用附加费,相比每次响应的成本,只是一个舍入误差。今天那个前缀变成了 11,000 tokens,你的缓存命中率从 92% 滑到了 31%,你的推理账单上升了 4 倍。团队里没有人能指出是哪个 PR 干的。没有一条 commit message 写着"将提示词增加 7,000 tokens"。每一次修改都很小,每一次修改都有理有据,每一次修改都干干净净地合入了。

提示词前缀长出胳膊和腿,就像地下室积攒纸箱一样。一个团队需要注入用户的订阅等级,这样 agent 才能解释套餐限制。另一个团队需要用户时区的今天日期,这样"明天提醒我"才能工作。第三个团队把当前 A/B 变体名硬塞进去,这样 eval traces 才能切片。市场团队加进了当前促销 banner,这样 agent 才能适时提及它。合规团队加进了功能标志清单,这样模型才能拒绝那些不在灰度名单里的用户访问 beta 功能。每一条都是一行的添加。每一条单独看都站得住脚。但加起来摧毁了你的缓存。

在用户说"是"之前就已提交的流式响应

· 阅读需 11 分钟
Tian Pan
Software Engineer

用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。

Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。

这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?

当评估指标全看“感觉”时,你的 A/B 测试无法区分两个模型

· 阅读需 9 分钟
Tian Pan
Software Engineer

你在实验中上线了一个模型替换。两周过去了,控制面板只变动了 0.1%,读数显示“无显著差异”。你得出结论,新模型与旧模型基本相同,然后继续进行其他工作。

它们并不相同。你的指标从未敏感到足以区分它们。

提示词 Diff 隐藏了自身的爆炸半径

· 阅读需 10 分钟
Tian Pan
Software Engineer

一个 PR(合并请求)进入了你的评审队列。Diff 显示系统提示词(system prompt)中修改了三个词:Output strictly valid JSON 变成了 Always respond using clean, parseable JSON。这看起来就像是一次文案润色。你快速浏览了一下,CI 检查勾标是绿色的,于是你点击了批准。总耗时:90 秒。

六个小时后,下游解析器开始拒绝带有尾随逗号和缺失字段的响应。结构化输出的错误率从接近零飙升至两位数,一个创收工作流陷入停滞。Diff 中没有任何迹象预示到这一点。Diff 中也不 可能 预示到这一点,因为 Diff 衡量的是错误的东西。

这就是评审提示词变更的核心问题:提示词 Diff 的大小完全无法说明其影响范围的大小。三五个词的修改与三段话的重写都只是文本,而文本 Diff 以相同的视觉权重呈现它们,就像对待任何其他编辑一样。但提示词并不是 描述 行为的文本 —— 它是 导致 行为的文本,而一次编辑所产生的因果爆炸半径在你评审的产物中是不可见的。

重提率:你的评估流水线从未提取出的失败信号

· 阅读需 11 分钟
Tian Pan
Software Engineer

只要翻开任何足够长的生产环境对话记录,你都会发现有用户会将同一个问题问上三遍。每一轮的措辞都会稍微改变——代词换成了名词,加上了限定词,到第三次尝试时,那些客气的委婉话也消失了——但底层的请求是完全相同的。他们不是在问三个问题。他们是在问同一个问题,而智能体没能给出答案,用户希望这一次表达的方式能产生不同的效果。

这里的对话记录级信号是如此响亮,以至于近乎显而易见。用户已经通过他们的键盘敲击告诉你,之前的回答没有帮助。他们不需要填写调查问卷,不需要点踩。他们通过再次输入问题直接告诉了你。而在大多数生产环境的 AI 技术栈中,这个信号被评估流水线默默丢弃了,因为这些流水线孤立地对每一轮对话评分,而满意度调查仅在会话结束时触发——到那时,那些重复提问三次的用户通常已经流失,永远不会进行任何评分。

Shadow Replay 会惩罚那些本可以改变对话走向的模型

· 阅读需 11 分钟
Tian Pan
Software Engineer

我在上季度合作的一个团队将一个新模型部署到了影子回放(shadow replay)中,结果发现其针对现有模型的胜率仅为 47%。同样的提示词,同样的检索,而该模型在厂商自带的评估中明显排名更高。影子测试框架获取了上周的生产流量,将其通过候选模型运行,把两者的响应都交给 LLM 裁判进行打分,最后宣布这次升级基本上就像掷硬币一样。团队当时差一点当场就回滚了。

问题不在于模型。问题在于回放中的每一条用户消息都已经受限于旧模型的上一轮对话。候选模型在第一轮写出了更好的回答,但日志中的用户是针对一个已不再存在的不同回答做出的回应,从第二轮开始,裁判评估的其实是一段根本没有发生的对话。一个真正更好的、能够改变用户后续行为的模型,是无法与已有的基准真相(ground truth)进行对比评分的。回放机制在潜移默化中奖励了那些停留在旧轨迹上的行为。

那个把上周 Slack 消息当成昨天消息来读的智能体

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的运营 Agent 通过引用一条内容为 “我们明天发版” 的 Slack 消息,回答了一个关于即将到来的发布会的问题。Agent 将其视为当前的计划,并开始撰写沟通稿。然而,这条消息是六周前发布的。发版早就完成了。检索流水线(retrieval pipeline)根据你衡量的每一项指标——与 “发布日期” 的语义相似度、高于阈值的 top-1 置信度、与项目匹配的来源频道——抓取到了正确的文本块(chunk),而 Agent 基于一句仅在编写时的会议语境下才有意义的话制定了计划。

这里的 Bug 不在模型本身。Bug 在于,“明天” 并不是一个日期。它是一个指向时钟的指针,而该消息编写时的时钟并不是 Agent 阅读时的时钟。你的检索流水线索引了消息的正文,却丢弃了其框架(frame)。

演示成功是因为有人在看:会话长度是你的评测套件遗漏的那个维度

· 阅读需 11 分钟
Tian Pan
Software Engineer

你发布会幻灯片上的可靠性数字,来自一些和用户实际使用的会话完全不像的对话。演示是五轮的:打开、提问、看到一个干净的回答、再细化一次、然后在高音上收尾。而你的核心用户昨天跑的那个会话有三十一轮长,包含两次工具失败(智能体用乐观主义掩盖了过去),最后用户放弃并提交了一张工单。两个会话出自同一个模型。第一个发了新闻稿。第二个被归档为"边缘情况"。

会话长度是评测的一个维度,而演示文化系统性地低估了它。我们衡量单轮准确率,是因为单轮准确率能放进幻灯片里,然后当单会话成功率从一个我们从未在任何图表上画过的悬崖上掉下来时,我们感到惊讶。这个悬崖既不是随机的,也不是尾部事件——它是误差累积、注意力漂移以及那些模型不会重新审视的已承诺假设的可预测后果。每个团队应该问的问题不是"这个模型有多好",而是"在我们已经在第一到第二十七轮说过那些话之后,这个模型在第二十八轮有多好"。

语义过时的 Embedding:当向量不再理解当下

· 阅读需 10 分钟
Tian Pan
Software Engineer

你曾在十八个月前嵌入了知识库。模型没变。分块(chunks)没变。索引很健康,延迟也正常,召回率仪表盘是一条 0.86 的水平线。然而,客服团队正悄无声息地在工单回复中粘贴错误的文章链接,销售机器人在潜在客户询问新产品时不断翻出已弃用的 SKU,而一名内部用户刚告诉你助手“感觉变笨了”,却说不出具体原因。

一切都没坏。是你的嵌入(embeddings)老了。在你的领域中,“post”一词以前指的是博客文章;现在,语料库中有一半的地方用它指代 Slack 帖子、论坛帖子和职位发布(job posting),而你那十八个月前的向量仍将其视为同一个概念。编码这些向量的模型从未见过这些新含义,从未见过新的产品名称,从未见过品牌重塑,也从未见过引入了三个新术语的监管规定——而你的客户现在正不假思索地使用这些术语。检索系统回答了它知道如何回答的问题,但这已不再是你的用户正在提出的问题。

填充式工具调用:当智能体在表演勤奋而不是真正干活

· 阅读需 11 分钟
Tian Pan
Software Engineer

打开任何一个生产环境智能体的 trace,看一看在用户提问和第一个真正有用的动作之间到底跑了哪些工具调用。你会看到一个 get_user_profile 返回了一个根本没人用的名字、一个 check_status 返回绿色然后再也没被引用、一个 list_recent_orders 的结果被总结成"ok"然后直接丢掉。这些调用没有一个改变了最终答案。但每一个都花了真金白银的钱、真实的延迟,以及在 trace 里真实占一行。你的智能体已经学会了表演勤奋——而表演勤奋如今是你最大的单一浪费来源。

这就是填充式工具调用:智能体发出一个动作,不是因为它需要那个结果,而是因为"先想一想,再行动"的整体模式在训练时被反复奖励,多到模型现在会把"显得周全"当作回答任何问题的副作用来执行。这是一个 LLM 版本的初级分析师,故意打开五个根本不会读的标签页,好让坐在对面的高级同事看到自己很忙。区别只在于:初级分析师会累。智能体永远不会。

聚合指标隐藏的首次用户断崖

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的 AI 功能看起来很健康。周活跃用户持平或微涨,满意度评分为正,仪表板告诉你应该多做这类功能。PM 在下一轮规划会议上引用了这个指标,工程主管点头同意,路线图上又多了一个相邻功能。

然后有人按用户使用时长对图表进行分段,画面瞬间反转。老用户——那些在功能上线时就已存在的用户——每天都在深度使用它。首次用户在两次交互内就跳出了。那条"持平"的曲线其实是两个队列在相互抵消:一条向上倾斜的幂律曲线,和一条向下倾斜的流失曲线,加总成一个谎言。

你的智能体没读过的那条休假自动回复

· 阅读需 9 分钟
Tian Pan
Software Engineer

凌晨两点,你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢,然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后,另一支团队的人偶然发现这个未读会话已经堆了六十条消息,才手动去把值班的人叫醒。

智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串,不是一个角色。这个字符串不知道什么叫 PTO。