跳到主要内容

861 篇博文 含有标签「insider」

查看所有标签

检索流水线的数据驻留:那些跨境而去的 Embedding,以及并未跨境的 LLM 调用

· 阅读需 11 分钟
Tian Pan
Software Engineer

交付 “面向欧盟客户的 AI” 的团队通常只交付一种驻留控制:锁定在欧盟地区的推理端点。采购团队拿到 DPA,架构图在 “模型托管在法兰克福” 旁边打上绿色对勾,接着发布。架构图中没显示的是:客户的原始查询在前往模型的途中被美国托管的嵌入 API 向量化;查询与之匹配的向量存储的运维平面位于 us-east-1;重排序模型是部署在供应商自选地区的第三方 SaaS;提示词缓存在命中的情况下是按地区键入的,而在未命中的情况下则是全局的;记录检索块的追踪存储有一个 30 天的保留期存储桶,并为了冗余进行跨区域复制。

推理层遵守了驻留规定。而检索流水线甚至不知道自己也是参与者。

这就是大多数 “符合 GDPR” 的 RAG 部署在面临团队甚至没意识到会到来的审计时失败的缺口。修复方案不是针对模型调用增加另一个控制 —— 而是意识到数据驻留是客户字节所接触的每个组件的属性,并且拥有 “LLM” 的团队最多只拥有涉及到的六个表面中的一个。

以 Token 数量而非结果驱动的 A/B 测试

· 阅读需 14 分钟
Tian Pan
Software Engineer

我曾合作过的一个团队发布了一次 prompt 变更,将输出 token 减少了 22%。实验仪表盘上一片绿意——方差极小,p 值非常清晰,外推后的成本节省每年高达六位数。两周后,一位研究转化漏斗的产品分析师指出,在同一时间段内,下游任务完成率下降了 11%。较短的输出省略了一个澄清步骤,而用户一直默默依赖该步骤来了解下一步该点击哪里。

实验平台没有撒谎。它报告的正是团队配置的核心指标,而且该指标确实朝着正确的方向移动了。问题在于,该指标衡量的是团队实际上并不关心的东西。Token 统计成本低,实验基础设施对其有现成的集成,而衡量结果却很难——因此团队选择了平台提供的便捷方案。结果是仪表盘上的完胜,却是产品层面的退化。

那个批准了“单次调用成本”却从未衡量“单次解决任务成本”的智能体预算

· 阅读需 11 分钟
Tian Pan
Software Engineer

在部署后的一个季度,AI 团队报告单次 API 调用平均成本降低了 25%。支持团队报告 AI 分流工单的平均处理时间从 4 轮增加到了 7 轮。这两个数字都是正确的。两个团队都在测量他们被要求优化的系统。夹在中间的财务团队无法核对仪表盘,因为这两个指标都不是以客户实际支付的东西来衡量的:一个已解决的工单。单次调用成本下降了,而单次任务解决成本上升了 40%。由于没有团队负责这个指标,所以没人注意到它的变动。

这是我在智能体(agentic)部署中见到的最常见的单位经济效益(unit-economics)失败,而且这不是一个测量上的 Bug,而是一个定义上的 Bug。供应商的价格页面展示了单次调用成本,因为这是他们计费的单位。由于电子表格的单元格刚好放得下,这个单位就被继承到了表格中。工程团队针对给定的单位进行优化。等到 API 经济与业务经济之间的鸿沟变得清晰可见时,这种影响已经累积了一个季度,而智能体整个时间都在基于错误的损失函数(loss function)被悄悄训练。

你的客户成功团队无法消化的智能体发布节奏

· 阅读需 12 分钟
Tian Pan
Software Engineer

客户将智能体的回答粘贴到支持聊天中,并要求人工代表进行确认。代表看着同一款产品,却给出了相反的说法。那天,客户并没有对智能体失去信心。他们是对公司失去了信心,因为公司的两个部门在同一个小时内告诉了他们两件截然不同的事情。

一切都没有出错。AI 团队在周二通过特性标志(feature flag)发布了一个提示词更改,到周四已推行至 100%,然后便继续下一项工作了。客户成功(CS)团队的赋能周期是按月进行的 —— 以前每个产品特性都是这样落地的,而且没人针对 AI 重新协商这一流程。CS 代表队列中的宏(macro)和公共网站上的 FAQ 文档描述的仍然是之前的行为。智能体是对的。代表根据他们掌握的文档也是对的。但公司表现得各说各话。

CTO 已拨款但安全团队拒绝让你上线的 AI 功能

· 阅读需 12 分钟
Tian Pan
Software Engineer

事后分析报告(post-mortem)会说“我们发现安全问题太晚了”。但实际的调查结果应该是:安全团队发现你的时间很准时,是你的流程发现安全问题太晚了。

这是一个在 1 月份就通过了预算审批的 AI 功能,因为 CTO 和 CFO 都认为公司需要一个“AI 高光时刻”。3 月份它通过了初步的法务审查,因为当时还只是一个原型。整个第二季度,工程团队都按照商定的规范进行开发。7 月底,发布前的安全审查启动了,结果第一天威胁模型(threat model)就反馈了阻碍性问题:身份验证范围(auth scopes)、数据泄露路径、模型供应商的数据驻留(residency)政策,以及提示词注入(prompt-injection)的攻击面。团队整个季度的时间现在都花在了重新架构上,以解决那些本该在最初规范中就被明确的问题。两个季度的进度延迟,一份关于“流程改进”的高管备忘录,以及在下一个规划周期中悄然决定“降低 AI 深度集成的优先级”。

发布失败并不是因为安全团队动作慢,而是因为安全团队在功能形态已经固化之后才介入。

那些你团队的人员已悄然停止阅读的标注队列

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的评估流水线每周会产生 800 条 trace 供人工审核。你的标注人员每周大约有 90 分钟的预算来处理这些数据。他们打开队列,对前三条进行打分,再将其余几条标记为“跳过”,然后就关闭了标签页。你在周一早上盯着看的排行榜,现在只是反映了哪些 trace 碰巧排在了列表顶部,而不是对系统质量的真实衡量。

这不是一个标注问题。这是一个披着质量问题外衣的吞吐量问题,也是评估项目退化最隐蔽的方式之一。Trace 仍在流动。仪表板仍在渲染。数值仍在变动。你没看到的是,你的“人工评分评估得分”的分母已经悄然缩减到了寥寥几项,而这些项是由一个没人刻意设计的排序函数挑选出来的。

用户习以为常的“你确定吗?”确认步骤

· 阅读需 11 分钟
Tian Pan
Software Engineer

确认对话框是 AI agent 工具箱中最廉价的安全层。它由一个字符串、一个按钮和一个回调函数组成。提议增加这一功能的项目经理在散会时,坚信该 agent 现在是安全的。开发它的工程师用一个下午就把它发布上线了。负责审计的合规检查员勾选了通过选项。而那天早上第七次看到它的用户,在眼睛还没读完标题之前,鼠标就已经移到了“确认”按钮上。

不到一周,确认步骤就不再是一个决策点,而变成了一种节奏。Agent 问:“你确定要发送这封邮件吗?”,用户回答“是”,就像别人打喷嚏时随口回一句“保重”一样自然。终有一天,Agent 会提议一个真正错误的动作——错误的收件人、错误的金额、错误的语气——而用户会带着之前确认那六个正确动作时同样的自动化反应去确认它。邮件发出后,团队写下一份事后分析,称之为“用户操作失误”。

这不是用户错误。这是系统误把“点击”的存在当成了“同意”的存在。

那些被你的智能体“触发并遗忘”的异步工具调用

· 阅读需 11 分钟
Tian Pan
Software Engineer

智能体工具调用抽象失效最明显的标志是:追踪记录(trace)显示该步骤已标记为完成,而下游系统却显示什么都没发生。模型调用了一个工具,收到了一个任务 ID 返回值,将该任务 ID 视为答案,然后继续执行。三分钟后,实际工作要么在无人监听的情况下成功,要么失败并产生一条记录在无人查看的日志中的错误。用户看到的是一份自信的总结;而操作队列看到的却是一个搁浅的任务。

这就是函数调用(function-calling)抽象悄然允许的失效模式。JSON Schema 描述了参数和返回类型,但它们无法区分“此工具返回一个结果”与“此工具返回一个操作回执,你稍后需要查询其结果”。模型对两者一视同仁,因为在规划器(planner)看来,它们看起来是一样的——都是一个带有非错误负载的成功工具调用。

那个在行动已发出后才生效的预算上限

· 阅读需 10 分钟
Tian Pan
Software Engineer

一个超级用户在第三天早上 9 点就耗尽了你的月度 token 预算。熔断机制(kill-switch)准确触发——网关返回 429,模型停止调用,账单停止增长。与此同时,智能体(agent)已经订好了机票,发送了确认邮件,并将支持工单标记为已解决。仪表盘显示“支出已停止”。用户却问:“为什么要为我从未要求的行程扣费?”两者都没错。预算上限阻止了模型思考,但它没能阻止世界的改变。

这是几乎每个智能体预算护栏都会携带的失效模式:上限信号位于 支出 平面,但损害发生在 行动 平面,而这两个平面在连接时并没有共享的事务边界。告诉模型停止并不等同于告诉世界撤销模型刚刚所做的一切。

针对你已不再提供服务的模型版本的 Bug 报告

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的,或者根本不符合预期,并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端,得到了一个清晰、合理的回答。就系统目前的状态而言,这个 Bug 并不存在。

Bug 是存在的,但产生这张截图的模型已经不在了。自从客户提交工单以来,你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量,一次是为了优化成本——而原始的检查点(checkpoint)已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言,支持团队既无法确认它,也无法关闭它。

这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题,而非客户可见的产品合约的必然结果。终端 URL 是稳定的,但它背后的产物(artifact)却不是。在你的支持流程、保留策略和客户合约承认这一差距之前,每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。

会话摘要抹掉了用户授予你的同意标志

· 阅读需 12 分钟
Tian Pan
Software Engineer

在第 3 轮,你的用户点击了“不要保留我的代码”。在第 7 轮,他们关闭了“使用我的对话来改进模型”。在第 12 轮,他们选择了退出跨会话记忆。到第 40 轮时,你的上下文预算耗尽了。压缩过程将第 1-30 轮折叠成一个简洁的 200 token 摘要,读起来非常顺畅:它捕捉了用户的提问、你的智能体做了什么以及结果如何。在第 41 轮,你的智能体——带着那份摘要和最近的 10 轮对话——自信地将用户的代码写入了一个用户在第 7 轮就已经选择退出的存储库中。

你的审计日志现在包含一个在 t=3 时的授权事件,一个在 t=41 时的违规操作,而两者之间是一段没有任何字段说明为什么该操作被允许的文本。摘要生成器经过训练是为了压缩对话,而不是为了转发控制状态。没有人告诉它那个授权开关是承重的(load-bearing)。也没人能告诉它,因为授权信息并不在对话中——它存在于对话旁的一个结构化字段里,而这个结构化字段没能熬过摘要化的过程。

那个定价模型假设提示词由人类编写的数据标注商

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的每美元标签(labels-per-dollar)仪表盘是团队评审中最亮眼的一行,但它在对你撒谎。分母是你 2023 年与标注供应商谈妥的按任务计费率,那时人类研究负责人会亲手编写每个标注提示词(prompt),修改两次,请同事审阅,一周可能才提交 40 个提示词。分子是通过 API 返回的已完成任务数量。在过去的三个月里,你的团队悄悄停止了手动编写提示词,转而使用大语言模型(LLM)生成。LLM 每两秒就能生成一个提示词,边际成本几乎为零。你的每美元标签指标在上升,而唯一知道这个指标毫无意义的人是供应商的客户经理,他正看着利润率被压缩,并准备发送一份采购团队会将其视为涨价的合同修正案。

这种错位并不是供应商的问题。这反映出合同中关于工作流的假设已不再成立。这些假设与你当前行为之间的差距,正是一方在静默吸收的剩余价值,直到续约周期迫使双方进行价格发现(price-discovery)对话。先注意到错位的一方将决定新的价格。