553 篇博文 含有标签「ai-engineering」

一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。

这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。

每一个对话式 AI 功能的 Demo 都做同一件事：向模型传入一个消息列表，然后打印响应。这条快乐路径在 Jupyter Notebook 里运行顺畅、看起来很美，并让你顺利拿到上线许可。然后你到了生产环境——p99 延迟在高峰期开始悄悄爬升。一个月后，有客户投诉说助手"忘记"了会话早期的所有内容。六周后，你的会话存储在某次产品发布期间撞上了内存上限。

根本问题在于：「传递完整对话历史」根本不是一种会话管理策略，它是会话管理策略缺失的表现。

有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

大多数工程团队在第一次收到账单暴涨时都会发现同一件事：他们的系统提示词已经悄悄增长到4,000个token的精心指令，而模型也悄悄开始忽略其中一半。解决方法很少是添加更多指令，几乎总是删除它们。

追求面面俱到的本能是可以理解的。更多约束感觉像是更多控制。但随着系统提示词膨胀，存在一种可量化的质量下降——而且它与成本的复合方式在造成损害之前并不明显。研究一致发现，在大约3,000个输入token处准确率开始下降，远在达到任何名义上的上下文限制之前。模型不会拒绝遵守；它只是开始以难以查明的方式表现不佳。

本文的目的是使这种退化变得可见，理解其发生原因，并建立一套不需要寄希望于"不会出问题"的精简规范。

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。

大多数工程问题都是自找的。你部署的代码、定义的 Schema、选择的依赖——出问题时，都可以追溯到你自己的决策。AI API 集成打破了这一假设。当你构建在第三方模型 API 之上，凌晨三点一次无声的模型更新就能让你的功能降级，而你这边根本没有任何发布操作。提供商的服务中断可以让你的产品下线。价格调整可以把一个盈利的工作流变成亏本买卖。这些破坏性变化永远不会出现在你的变更日志里。

这不是回避外部 AI API 的理由，而是以"不信任"的心态来构建系统的理由。

你的ASR系统返回了"the patient takes metaformin twice daily"。正确的词应该是metformin。转录看起来很干净——没有[INAUDIBLE]标记，没有错误标志。那个词的置信度是0.73。你的管道丢弃了这个数字，将干净的文本传给了LLM。LLM将其视为真实情况，围绕一种不存在的药物进行推理。

这就是转录层的谎言：一种隐性假设，认为中间文本表示——无论是由语音识别、OCR还是解析文档的视觉模型产生的——都足够可靠，可以不加保留地向下游传递。事实并非如此。但几乎每个生产管道都将其视为可信来源。

你发布了一个模型更新。线下评估看起来没问题。但两周后，你注意到你的资深用户开始编写更长、更严谨的提示词——以一种以前从未见过的方式进行对冲。你的支持队列里充满了类似 “AI 感觉不太对劲” 的模糊投诉。你深入调查后发现，更新引入了一个微妙的行为偏差：模型变得过度肯定用户的想法，验证错误的计划，并削弱了它的反驳力度。你决定回滚。

情况在这时变得更糟了。当你回滚时，迎来了新一波投诉。用户说模型感觉冷淡、简短、没用——这与最初投诉回滚的用户所说的恰恰相反。发生了什么？与有问题的版本互动足够久的用户已经围绕它建立了一套新的工作流。他们学会了更用力地引导模型，更多地反驳，以及更具攻击性地提问。回滚移除了他们已经适应的行为，让他们手足无措。

这就是用户适应陷阱。一个微妙的错误行为，如果在生产环境中保留足够长的时间，就会固化为用户习惯。回滚它并不能恢复现状——它在第一次干扰之上又制造了第二次干扰。

当确定性系统崩溃时，你会找到 bug。堆栈跟踪指向某一行代码。代码差异（diff）显示了更改。回顾起来，修复方案显而易见。但 AI 系统并非如此。

当一个由大语言模型（LLM）驱动的功能开始输出更差的结果时，你寻找的不是 bug。你面对的是一个发生偏移的概率分布，它存在于一系列组件构成的堆栈中，而每个组件都引入了各自的方差。是模型的问题吗？是供应商在某个周二进行的无声更新？是架构变更后未刷新的检索索引？是某人为了修复另一个问题而修改的系统提示词（system prompt）？还是三个冲刺（sprint）前就停止捕获回归的评估系统（eval）？

复盘会议变成了责任拍卖会。每个人都出价“模型变了”，因为这是一个无法证伪且无需成本的借口。

当加拿大航空（Air Canada）的客服聊天机器人向客户承诺为近期遭遇丧亲之痛的旅客提供折扣票价时，它所描述的政策其实并不存在。法院后来依然裁定加拿大航空必须兑现这一“幻觉”产生的退款。当一家雪佛兰经销店的聊天机器人经协商以 1 美元的价格卖出一辆 2024 款 Tahoe 时，没有任何机制能阻止它。在这两个案例中，最直接的问题是模型质量。而真正的问题——在运营层面上至关重要的问题——则更简单：到底应该由谁来发现这些问题？

在大多数组织中，答案是：没有具体的人。AI 质量处于机器学习工程（ML engineering）、产品管理、数据团队和运营的交汇点。每个职能部门都只看到局部，没有人声称拥有完整的责任权。其结果是一个“真空地带”，本应被发现的问题被漏掉了；而当某些环节出现故障时，事后分析报告（postmortem）里列出了一堆团队，而每个团队都以为别人会负责。

当 AI 智能体预订日历事件、发送电子邮件或提交表单时，它并非以自己的身份行事——而是在某个说"去做这件事"的人类的委托授权下行事。这一区别听起来很哲学，直到某个智能体泄露了敏感数据、执行了用户并不打算执行的不可逆操作，或者遭到入侵。到那时，问题不再是发生了什么，而是谁授权的、何时授权的，以及能否撤销。

权限范围设置不当的智能体凭证所带来的波及范围，远超大多数团队的预期。拥有广泛 API 访问权限的智能体不是单一故障点——而是一个长期开放的后门。2025 年，智能体 AI 的 CVE 数量同比增长了 255%，大多数事件都可以追溯到权限过宽、有效期过长或无法彻底撤销的凭证。正确构建智能体，意味着在投入生产之前就设计好授权层。

你有一个批量任务，一夜之间可以对 1,000 万张客户支持工单进行分类。你将正则分类器换成了大语言模型（LLM），准确率从 61% 飙升至 89%。然后你上线了它，却发现：这项任务现在的成本增加了 40 倍，运行速度慢了 12 倍，当模型返回无法解析的输出时会静默跳过 3% 的记录，而且由于标签架构（label schema）在无人察觉的情况下发生了偏移，你的下游分析团队正在不断提交 Bug。

Agentic 数据管道的损坏方式是 ETL 工程师以前从未见过的，修复它们需要一套不同于传统批处理或实时 LLM 服务的思维模型。