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

每个部署过分布式系统的工程师都曾直面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个月——这意味着如果你还没有开始，已经落后了。

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。

你见过的每一个 Agent 演示都以干净的结果收尾。工具调用返回了模型预期的数据，响应在两秒内到达，最终答案清晰准确。那是演示。生产环境则是另一回事。

在生产环境中，工具会超时。API 会返回 403，因为某个服务账户上周二被轮换了。第三方数据丰富端点返回 200，但响应体写着 {"status": "degraded", "data": null}。OAuth 令牌在周六凌晨 3 点过期。这些不是边缘案例——这是任何与真实世界交互的 Agent 的正常运行状态。失败模式是可预见的。问题在于，大多数 Agent 架构将它们视为事后补救，而大多数 Agent UI 根本没有向用户传达这些失败的词汇。

大多数AI团队能告诉你他们的遏制率——AI在不转交给人工的情况下处理的交互比例。但很少有团队能告诉你这个数字是否合理。

升级标准是AI增强团队中最重要的设计文档，而大多数团队根本没有这份文档。他们有一个埋藏在YAML文件中的阈值，以及一个隐含的假设：AI知道自己什么时候卡住了。这个假设在两个方向上都是错误的：阈值过高，人工就要花时间返工AI的工作；阈值过低，用户在没有任何补救措施的情况下承受AI的错误。两种失败都是隐性的，直到它们积累成大问题。

当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。

你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。

系统还在运行。目前如此。但你无法安全地修改任何东西。