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

一家航空公司的客服 AI 告诉一位旅客，他可以先购买全价机票，事后再申请丧亲优惠折扣。旅客信以为真，飞行后提交了申请，却遭到公司拒绝。仲裁庭最终判决公司须赔偿 650 美元——因为法律上并无区分人类员工与聊天机器人所给建议的规定。那个聊天机器人并未崩溃，没有任何告警触发，p99 延迟也未见异常。系统在「正常运行」。

这正是 AI 事故的典型特征：应用程序并未报错——它成功地、自信地、大规模地生成了错误输出。 而当你坐下来撰写事后分析报告时，经典的工具箱便彻底失灵了。

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

大多数AI产品团队上线一个点赞/点踩组件，就称之为满意度度量系统。他们确实在度量某些东西——只是那不是满意度。

一个因为函数签名错误而对Copilot建议点踩的开发者，和一个因为建议虽然优秀但当前不适用而点踩的开发者，产生的是完全相同的信号。与此同时，那个悄悄重新生成了四次最终放弃的开发者，根本没有产生任何显式信号。而那个缺失的信号，比评分组件捕获的任何东西都更能预测用户流失。

用户在使用AI产品时留下的隐式行为记录，比他们自愿输入或点击的任何内容都更丰富、更真实、更可操作。本文介绍该收集哪些信号、为何这些信号优于显式反馈，以及防止AI专项遥测污染通用产品分析的埋点方案。

Phil Karlton有句名言——"计算机科学中只有两件难事：缓存失效和命名"——这句话诞生于语言模型进入生产之前。将AI加入技术栈后，缓存失效不只是变得更难；它在每一层同时变得更难，而且每一层的原因从根本上不同。

传统缓存存储的是确定性输出：数据库行、渲染的HTML、计算出的价格。当源数据变化时，你使该键失效，下一个请求获取新数据。契约很简单，因为答案是一个事实。

AI缓存存储的是不同的东西：对查询的响应，而这些响应的"正确"答案取决于上下文、时效性、模型行为以及模型所获取的源文档。这里的"陈旧"不意味着过时——它意味着在语义上出错，而你的监控不会发现，直到用户注意到为止。

每个部署过分布式系统的工程师都曾直面CAP定理并做出抉择：当网络分区时，你是继续提供陈旧数据（可用性），还是拒绝服务直到获得一致的答案（一致性）？该定理告诉你，二者不可兼得。

AI智能体面临着同样的权衡，然而几乎没有人在明确地做出这一选择。当你的LLM调用超时、工具返回垃圾数据、下游API不可用时——你的智能体会怎么做？在大多数生产系统中，答案是：它会猜测。悄无声息地。信心满满地。而且往往是错的。

故障模式并不戏剧化。日志中没有异常。智能体"回答"了用户。两周后才有人问起，为什么系统订了错误的航班、提取了错误的实体，或者自信地告诉客户一个已不存在的价格。

大多数关于 RAG 质量的讨论都聚焦在错误的地方。团队在争论嵌入模型的选择、微调检索的 top-K、以及尝试各种提示词模板——然而在数据摄取阶段做出的一个架构决策，却悄然决定了系统能力的上限。这个决策就是分块策略（chunking strategy）：即在索引之前，你如何将文档切分成片段。

一项 2025 年的基准研究发现，分块配置对检索质量的影响，甚至比嵌入模型的选择还要大。然而，团队通常会选择默认配置——通常是 512 个 token 的 RecursiveCharacterTextSplitter——然后花上几个月的时间去思考，为什么他们的检索精度总是差强人意。问题在索引时就已经埋下了。更换模型无法解决这个问题。

演示表现完美。法务部门已经批准。销售团队已经在向客户承诺该功能将在下个季度上线。接着，第一次生产环境故障发生了——模型言之凿凿地起草了一个引用了并不存在的合同条款的条文，销售将其发给了客户，法务部门花了三周时间进行损害控制。

这不是一个关于坏模型的故事，而是一个关于沟通失误的故事。工程团队知道模型可能会产生幻觉。法务假设它不会。销售假设任何故障在到达客户之前都会被拦截。运维假设有其他人在专门监控这一点。没有人撒谎。每个人都在基于同一个系统的不同心理模型工作。

大多数 AI 项目失败的根本原因不在于 AI 本身。根据兰德公司（RAND Corporation）对失败的 AI 计划的分析，“对问题定义的误解”——包括对能力限制的沟通误导——是单一最常见的原因。70% 到 95% 的企业 AI 计划未能交付预期成果，而技术本身很少是限制因素。限制因素在于，你组织中的每个团队都在悄悄地构建关于你的 AI 系统能做什么的不同理论，而没有人明确地纠正过其中任何一个。

你的 Agent 在隔离测试中表现完美。你对每个步骤都做了基准测试，测量得到每步精确率为 95%。向利益相关者演示时效果很好。然后你上线了，用户反映几乎有一半时间它都会失败。

这个失败不是任何单个组件的 bug，而是数学。

大多数 AI 流水线故障并非模型问题。模型运行正常，输出看起来也是 JSON，但下游阶段却悄然崩溃——原因可能是字段被重命名、类型发生变化，或者嵌套对象新增了一个下游阶段根本不知道如何处理的必填属性。流水线执行完毕并报告成功，而某个数据仓库里的数字已经悄悄出错。

这就是 AI 流水线的契约测试问题，也是生产 AI 系统中最被忽视的可靠性风险之一。根据近期基础设施基准数据，企业 AI 系统平均每月发生近五次流水线故障，每次解决耗时超过十二小时。主要原因并非模型质量差，而是数据质量和 Schema 契约违规：64% 的 AI 风险存在于 Schema 层。

大多数多轮 LLM 应用将对话历史存储为消息数组。这在演示（demo）中表现良好。但在生产环境中，它会以需要数天才能诊断出的方式崩溃，因为这些故障看起来更像是模型的问题，而非基础设施的问题。

用户在对话中途断开连接，并重新连接到不同的服务器实例——会话消失了。智能体（agent）在处理复杂任务时进入第 47 轮，载荷悄无声息地超过了上下文窗口——没有报错，只有错误的回答。产品经理问道：“我们可以让用户从第 3 步开始尝试不同的方法吗？”——而工程侧的回答是“不，按照我们的构建方式不行”。这些都不是极端情况，而是将对话状态视为瞬态数组（transient array）而非一等资源（first-class resource）的必然结果。

一家电信公司花了数月时间调优其客服聊天机器人的 Prompt。他们反复迭代系统指令、Few-shot 示例和思维链格式，但幻觉率始终顽固地维持在 50% 以上。后来他们审计了知识库，发现其中充斥着已下线的服务套餐、过时的账单信息，以及相互矛盾的重复政策文件。修复数据之后——而不是修改 Prompt——幻觉率骤降至接近零。Prompt 工程无法解决的问题，三周的数据清理就做到了。

这就是数据质量天花板：当 LLM 系统的输入数据存在噪声、过时或前后矛盾时，会出现一道性能硬墙，任何 Prompt 迭代都无法突破。这是生产环境 AI 最常见的失效模式之一，也是最被系统性低估的一种。撞上这堵墙的团队，往往还在不停拨弄 Prompt 旋钮，而问题的根源其实在上游。

2026年，大多数构建AI系统的工程团队都知道欧盟《人工智能法》的存在。但很少有人真正理解它要求他们构建什么。该法规对高风险AI系统的核心义务——自动事件日志记录、人工监督机制、风险管理系统、技术文档——并非法律团队能在截止日期前生产的政策文件。它们是工程交付物，需要在项目启动时做出架构决策，而非在合规审计前的最后一个冲刺阶段。

硬性截止日期是2026年8月2日。在欧盟部署的高风险AI系统必须完全符合第9至15条的规定。在就业筛选、信用评分、福利分配、医疗优先级、生物特征识别或关键基础设施管理领域部署AI的组织均在适用范围内。如果你的系统在这些领域做出实质性影响欧盟居民的决策，它几乎肯定属于高风险。而现实的合规实施周期需要8至14个月——这意味着如果你还没有开始，已经落后了。