Upstream-Mentality-为什么-AI-ML-工程师必须超越模型思考

Upstream Mentality：为什么 AI/ML 工程师必须超越模型思考

原文：towardsdatascience.com/the-upstream-mentality-why-ai-ml-engineers-must-think-beyond-the-model/

你的 AI 系统在生产中完美运行了数周，突然一切都崩溃了。也许是因为你的 ML 模型的精度一夜之间下降，或者你的 LLM 代理未能预订肯定存在的航班。罪魁祸首？很少是模型本身。通常，是上游表中一个模式的更改，一个没有人告诉你的 API 重命名，或者一个永远没有更新的知识库。

你迅速添加了一个脆弱的 try/catch 修复来处理这个问题，确保数据符合你的系统期望。但几天后，它又发生了。不同的症状，同样的根本原因：出现空值，出现新的类别，API 响应格式发生变化——但你的脆弱补丁只能捕获你的特定修复。这是因为你没有考虑上游。

大多数 AI/ML 问题实际上并不是 AI 问题——它们是上游设计决策的下游后果。

如果你曾经因为一个关于 AI 系统故障的警报而醒来，花费数小时调试却发现是上游数据发生了变化，或者感觉陷入了持续的救火模式——无论你是机器学习工程师、AI 工程师、工程经理还是数据工程师——这篇文章就是为你准备的。

在这篇文章中，我们将探讨我开发的 Upstream Mentality 框架及其“归因翻转测试”，这两者都源自社会心理学概念。

---

反应式工程的隐藏成本

AI/ML 工程师面临着其他工程学科没有的独特三重威胁：基础设施问题、数据漂移以及 AI/ML 团队自身引入的变更的下游影响。这些团队通常为了优化模型性能而忽略了生产稳定性。当问题发生时，人们往往会迅速创建快速补丁，而不去问：这该如何预防？

这种反应式方法可能会因其即时影响而受到赞扬，但其隐藏成本是严重的。你的管道充满了 try/catches，每个补丁都创造了新的故障点，调试变得指数级困难。技术债务积累，直到重新审视代码感觉像是在解决一个谜团。

但技术债务不仅仅是一个工程问题，它是一个即将发生的商业危机。让我先说一个显而易见的事实：金钱。当你的模型无法生成预测时，你打破了与客户的 SLA（服务水平协议），更重要的是，你打破了他们的信任。即使你的模型在运行时表现异常出色，不一致的交付让你的整个产品看起来不可靠，使客户面临流失的风险。

现实世界的例子证明了这种影响。Stripe 通过修复“脆弱的编排和遗留脚本”，将正常运行时间从 84%提高到 99.9%，直接保护了收入和信任 (link)). Uber 用 Michelangelo，他们的标准化机器学习平台，替换了脆弱的、一次性的管道 (link)。

财务损失是显而易见的，但还有一个隐藏的成本：对工程团队的影响。研究证实了工程师们日常所经历的情况——持续的技术债务与“增加的倦怠、较低的满意度以及降低的系统稳定性信心”相关联 (link)。

反应式工程的隐藏成本。图片由作者提供

---

上游思维框架

那么，我们如何摆脱这种反应性循环呢？通过大规模构建机器学习系统，我注意到了我们处理问题的方式中存在的一种模式。借鉴我的心理学背景，我开发了一个心理框架，帮助我们识别我们是在修补症状，还是在真正重构代码以防止问题在源头产生。我称之为“上游思维”框架，这是一种主动的哲学，即在问题起源处解决问题，而不是在症状出现处。

这个框架起源于我对当时团队领导的一个简单功能建议：如果配置中声明的工件不存在，就防止模型配置部署。这发生在一位数据科学家部署了一个模型，其中一个工件名称有误，导致我们的推理服务失败之后。“为什么我们只能在错误发生时才被警告，而不能阻止它发生呢？”

上游思维模式告诉你需要系统地思考可能导致失败的情况。但实际如何识别它们呢？这个概念源于一个核心心理原则：基本归因错误。它的正式定义是：

一种认知归因偏差，其中观察者低估了情境和环境因素对行为者行为的影响，同时过分强调了性格或人格因素的影响。

我更喜欢从实际的角度来考虑：当你看到有人追赶公交车时，你认为“他们一定有很差的时间管理技能”（责怪个人）还是“公交车可能比预定时间早到”（检查情况）？大多数人本能地选择前者——我们倾向于责怪个人而不是质疑环境。我们在失败的 AI/ML 系统中犯同样的错误。

这种心理洞察力通过我所说的“归因翻转测试”——应用上游思维的实际方法变得可行。面对错误或系统故障时，经历三个阶段：

1. 归咎于它（归因于态度）

2. 翻转它（考虑情况：“是什么环境因素导致了这次失败？”）

3. 重构它（改变系统，而不是症状）

归因翻转测试流程图。图片由作者提供

关于优先级的说明：有时你需要先修补——如果用户在受苦，停止出血。但大多数团队失败的原因就是停止在这里。上游思维意味着始终返回修复根本原因。如果不优先考虑重构，你将永远修补修补。

---

真实案例研究：上游思维在行动中

由于上游思维框架和归因翻转测试可能感觉抽象，让我们通过展示如何应用它们的真实案例研究来使它们具体化。

案例研究 1：模型永远不会出错

不论是传统的机器学习模型给出糟糕的预测，还是突然停止正常工作的 LLM 代理，我们的第一反应总是相同的：责怪模型。但大多数“AI 失败”实际上并不是 AI 问题。

传统机器学习示例：您的欺诈检测模型已经以 95%的精确度捕获了数月的可疑交易。突然，它开始以惊人的速度将合法购买标记为欺诈。模型没有改变，代码没有改变，但显然出了问题。

LLM 示例：您使用 LLM 的产品搜索助手已经帮助用户以近乎完美的成功率找到目录商品数月了。突然，客户抱怨：当他们搜索“200 美元以下的无线降噪耳机”时，他们得到“没有找到结果”，尽管您的目录中存在数十个这样的商品。

让我们应用归因翻转测试：

1. 归咎于它：“模型退化”或“LLM 在幻想”

2. 翻转它：模型通常不会自行改变，但它们的输入会改变。在机器学习的情况下，您的数据工程团队将交易金额列从美元改为美分（1.50 → 150），而没有通知任何人。在 LLM 的情况下，产品数据库 API 发生了变化：“价格”字段被重命名为“list_price”，而没有更新搜索服务

3. 重构它：而不是在模型级别修复问题，修复系统——强制执行数据合约，防止部署模型使用时列发生变化，或在 API 和依赖服务之间添加自动模式合约测试

案例研究 2：由于数据未同步导致的训练-服务偏差

您的客户流失预测模型在离线评估中显示 89%的准确率，但在生产中表现糟糕——实际的流失率与每天生成的预测完全不同。这是因为增强特征来自一个每日批量表，有时在午夜实时推理运行时并未更新。

归因翻转测试：

1. 归咎于它：“这是后期特征的错！”工程师试图通过添加回退逻辑来修复这个问题：要么等待表刷新，要么在运行时调用外部 API 填充缺失的数据

2. 翻转它：情况是在数据未准备好时调用推理

3. 重构它：迁移到推送架构而不是拉取架构进行特征检索，或者确保模型不依赖于实时不可保证可用的特征

案例研究 3：无声的漂移

您的推荐引擎的点击率在三个月内缓慢下降，没有警报，这是由于其逐渐变化的特点。调查发现，合作伙伴公司悄悄更改了他们的移动应用界面，微妙地改变了用户行为模式。模型正确地识别了缓慢的变化，但我们只关注模型准确性，而不是输入分布。

归因翻转测试：

1. 归咎于它：“模型现在不好；重新训练它或调整阈值”

2. 翻转它：上游数据逐渐变化，我们没有及时捕捉到

3. 重构它：在特征分布上实现漂移检测，而不仅仅是模型指标

案例研究 4：RAG 知识老化

一个由 RAG（检索增强生成）驱动的客户支持代理已经准确回答产品问题六个月了。然后投诉开始涌入：机器人自信地提供过时的定价，将已停售的产品称为“我们的热销产品”，并提供两个季度前的退货政策。用户非常愤怒，因为错误信息听起来如此权威。

归因翻转测试：

1. 归咎于它：“LLM 在幻想；需要细化提示/上下文以更好地获取向量”

2. 翻转它：自第二季度以来，向量数据库没有更新新的产品文档。产品团队一直在 Confluence 中更新文档，但没有人将此与 AI 系统的知识库联系起来

3. 重构它：将知识库更新集成到产品发布流程中——当功能发布时，文档会自动流向向量数据库。将知识更新作为产品团队定义的“完成”的必要步骤

---

为什么在 AI 系统中进行归因翻转测试更难

与传统的机器学习管道相比，在处理 AI 系统时，归因翻转测试变得更具挑战性。理解这一点需要检查它们架构的根本差异。

传统的机器学习系统遵循相对线性的流程：

传统的机器学习数据流。图由作者绘制

这个简单的管道意味着故障点通常是可识别的：如果有什么东西坏了，你可以系统地追踪每个步骤。数据转化为特征，输入到你的模型中，并产生预测。当出现问题时，它们通常表现为明显的错误或明显错误的输出。

AI 系统，尤其是涉及 LLM 的系统，操作起来要复杂得多。以下是一个典型的 LLM 系统架构的示例：

AI 代理（LLM）典型数据流。图由作者提供

注意，这是一个简化的表示——真实的 AI 系统通常有更复杂的流程，包括额外的反馈循环、缓存层和编排组件。这些组件的指数级增加意味着潜在的故障点也呈指数级增加。

但复杂性不仅仅是架构上的。AI 故障是“伪装”的：当一个 LLM 出错时，它会给出礼貌、合理的解释，比如“我找不到那些日期的航班”，而不是明显的错误，比如“JSON 解析错误。”你认为 AI 感到困惑，而不是一个 API 在上游发生了变化。

也许是更重要的是——我们像对待人类一样对待 AI。当一个 LLM 给出错误答案时，我们的本能是认为“它需要更好的指令”或“让我们改进提示”，而不是问“哪个数据源出了问题？”这种心理偏差使我们完全跳过了上游调查。

---

实施上游思维

当归因翻转测试帮助我们解决问题时，真正的上游思维更进一步：它关乎构建防止这些问题发生的系统。测试是你的诊断工具；上游思维是你的预防策略。让我们探讨如何从第一天开始将这种主动方法融入你的系统。

第 1 步：绘制你的数据血缘图

考虑你的模型（无论是 LLM、传统 ML、查找模型还是其他任何东西），并了解哪些数据源为其提供数据。通过向上绘制它的“家谱”：特征是如何创建的？哪些管道为特征工程管道提供数据？这些管道何时被摄取？

从底部开始创建一个简单的图表，并绘制指向每个数据源的箭头。对于每个来源，问：这从哪里来？继续向上直到你达到一个完全超出你控制的人类流程或外部 API。

下面是一个基于 LLM 的系统的“反向树”示例，展示了用户上下文、知识库、提示模板和各种 API 如何流入你的模型。注意有多少不同的来源贡献了一个单一的 AI 响应：

典型 AI 代理的数据血缘图。图由作者提供

第 2 步：评估风险

一旦你对最终导致你的模型输入的数据管道有了清晰的了解，你就迈出了向更安全的生产模型迈出的第一步！现在评估每个管道崩溃的风险：它是否完全在你的控制之下？它是否可以在你不知情的情况下发生变化？如果是的话，是由谁引起的？

查看你的图并着色编码风险：

• 红色：外部团队，无变更通知（风险最高）

• 黄色：共同拥有，非正式沟通（中等风险）

• 绿色：完全控制，正式变更管理（风险最低）

以下是一个使用传统机器学习模型数据链路的示例，其中我们已将每个上游依赖项着色编码。注意，其结构与上面提到的 LLM 示例不同——机器学习模型通常具有更结构化的数据处理流程，但风险模式相似：

传统机器学习模型的数据链路图。图片由作者提供

首先集中精力在上游预防措施上，针对红色和黄色依赖项。

第 3 步：优先处理源数据修复

一旦你确定了崩溃点，首先优先在源头修复它们。你能与上游团队建立数据合同吗？你能被添加到他们的变更通知中吗？你能在他们的部署过程中构建验证吗？这些上游解决方案可以完全防止问题发生。

只有在你无法控制上游源时，才应该退回到监控。如果管道 X 由另一个团队控制，并且他们不会将你添加到他们的变更流程中，那么是的——监控其漂移并在异常发生时发出警报。但始终先尝试上游修复。

在 AI/ML 工程的世界里，协作是关键。通常，没有哪个团队拥有完整的视图，因此团队 A 对其数据摄取所做的更改可能会最终损害团队 D 的下游模型。通过全面探索和理解你的上游，并帮助其他团队理解他们的上游——你创造了一种文化，其中上游思维成为默认。

---

前进方向：从反应性到主动性

下次你的 AI 系统出现问题时，不要问“我们如何修复这个问题？”，而要问“我们如何预防这个问题？”因为上游思维不仅仅是一种调试哲学，它是一种转变，将反应性工程团队转变为主动的系统构建者。

你（并且应该）从今天开始实施上游思维。对于现有和新项目，首先绘制建议的上游图，并问自己：

• “什么外部依赖可能会在明天破坏我们的模型？”

• “哪个团队可能会在不告诉我们的情况下更改某些内容？”

• “如果[特定的上游系统]崩溃了，我们如何知道？”

意识到并持续思考上游将确保你的系统正常运行时间保持一致，你的业务伙伴保持满意，你的团队能够有时间探索和推进系统，而不是不断地扑灭本可以预防的火灾。

上游思维不仅仅关乎构建更好的 AI/ML 系统，它还关乎构建更好的工程文化。这种文化中，预防胜过英雄主义，上游原因得到解决而不是下游症状，并且你的模型既具有韧性又准确。

从明天开始：选择你最重要的模型，花上 15 分钟绘制其上游图。你会发现一些意想不到的东西。