谁该为 AI 质量负责？导致生产系统崩溃的跨职能职责真空

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

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

这不是技术问题，而是组织架构问题。而且，与 GPU 成本或模型延迟不同，你无需等待供应商就能解决它。

责任扩散的剖析

在传统软件中，责任归属通常很明确。服务有值班表（on-call rotation），功能有产品经理，数据库迁移有负责的工程师。这些界限虽然不完美，但确实存在。

AI 系统默认并不具备这种清晰度。考虑一个典型的生产级 LLM 管道：ML 团队负责训练或微调模型，平台团队构建推理基础设施，产品团队编写提示词（prompts），数据团队负责检索管道，而运维（ops）团队监控生产指标。现在请问：“谁负责确保这个管道不会给用户错误答案？”

每个团队都有充分的理由声称拥有部分责任，也有充分的理由认为另一个团队应该承担主要责任。ML 团队说他们交付了一个经过评估的模型；平台团队说他们提供了所要求的架构；产品团队说他们不是 ML 专家；数据团队说检索质量取决于语料库，而那是业务问题；运维团队说他们监控的是延迟和错误率，而不是输出的语义。

没有人是错的。也没有人是负责的。这就是责任扩散（accountability diffusion）——组织层面的“旁观者效应”，即随着潜在行动者数量的增加，任何个人采取行动的可能性反而降低。

失败模式是可预见的。评估（Evals）没写，是因为产品团队缺乏专业知识，而 ML 团队认为这是产品范畴。行为回归（Behavioral regressions）直接上线，是因为没有负责回归测试的人。幻觉率漂移，是因为监控仪表板只跟踪技术指标（延迟、错误码），而不跟踪语义质量。当用户得到错误答案时，每个团队事后都能给出一个自洽的理由，解释为什么发现这个问题不是他们的工作。

全栈视角下的“质量”究竟意味着什么

责任扩散的部分原因在于“AI 质量”并非单一概念。它至少可以分为三个不同的层级，每个层级都有其天然的负责人——前提是你的组织已经明确指派了他们。

技术质量（Technical quality） 涵盖了 ML 工程师通常关注的指标：行为回归（新版本的模型对相同的测试案例是否给出一致的回答？）、输出一致性、延迟以及每次推理的成本。这是最容易实现工具化监控的层级，也是最可能已有负责人的一层。但仅有这一层是不够的。如果提示词改变了、检索语料库发生了漂移，或者任务分布发生了变化，即便模型在技术上与前一版本完全相同，依然可能无法满足用户需求。

产品质量（Product quality） 涵盖了系统是否满足了用户需求：任务完成率、用户满意度评分，以及输出在特定产品体验背景下是否连贯。这一层需要产品经理和领域专家来定义什么是“好”。这是最容易出现在路线图中（如“我们将提高响应质量”），但也最不容易拥有可衡量的退出标准（exit criteria）或负责衡量它的负责人。

安全与可靠性质量（Safety and reliability quality） 涵盖了有害、偏见或法律上有风险的输出——这是合规、法律和安全团队的领域。如果被忽视，这一层级会产生代价高昂的事故。它需要有人主动探测系统的失效模式，而不是坐等用户去发现。

生产环境中的大多数 AI 质量故障并非源于某个层级管理不善，而是源于层级之间的衔接处。没有哪个团队能清晰地横跨这三个层级，这意味着故障往往在这些缝隙中累积。

实践中的组织性失败表现

第一种典型的失败模式是从未得到维护的评估集（eval）。评估工作需要持续投入：随着产品的演进编写新的测试案例、校准评分函数、分拣新的失败模式，并决定发布所依据的阈值。这项工作既枯燥又是跨职能的——你需要 ML 专家来设计评估方法，需要领域专家来定义正确性，需要产品专家来权衡结果，还需要工程工作来将其集成到 CI/CD 中。

当没有团队负责这个生命周期时，评估集就会过时。它们是为测试最初的功能而编写的，而在提示词更改、用例扩展或底层模型更换时从未更新。等到发生质量事故时，评估套件甚至可能根本没有涵盖相关的行为。

第二种失败模式是交接间隙（handoff gap）。许多组织将 AI 质量视为一场接力赛：ML 团队构建并评估模型，产品团队编写提示词，平台团队部署，运维团队监控。每个团队完成自己的部分并交给下一个团队。但 AI 质量往往在交接时下降。ML 团队的评估是针对基础模型能力的，而不是针对产品团队使用的特定提示词和检索方法。产品团队编写提示词时，并不知道模型在分布漂移下的表现。运维团队的仪表板只显示基础设施健康状况，而不显示语义正确性。

第三种失败模式是从试点到生产的断崖（pilot-to-production cliff）。在试点阶段，由于团队规模小且沟通直接，责任归属通常管理得较好。当试点规模扩大——覆盖更多用户、更多用例、更多地区时——最初紧密合作的团队分散到了各个职能部门，而没有人明确重新分配责任。这就是 61% 的 AI 项目据报道失败的原因：不是因为技术不成熟，而是因为在大规模维持质量的组织模式从未被定义。

大规模团队如何解决这个问题

那些做对了这个问题的组织往往会汇聚成一种混合模式：一个中心化的平台团队负责评估基础设施和框架，而产品及领域团队则负责评估案例和验收标准。

这种区分至关重要。基础设施所有权意味着：构建和维护运行评估的工具，将评估运行集成到 CI/CD 流程中以阻断部署，提供团队可以组合的评分原语（Scoring Primitives），以及维护使回归检测成为可能的历史基准数据。这确实是一个平台关注点——它需要规模、一致性和共同投资。

评估案例所有权意味着：定义特定用例的“正确”标准，编写反映真实用户行为的测试用例，设定合格评估的阈值，以及在发生评估失败时进行分流处理（Triaging）。这确实是产品和领域的关注点——它需要平台团队所不具备的业务上下文知识。

当这些职责没有清晰划分时，会出现两种失败模式之一：要么是平台团队包揽一切并成为瓶颈（每项新的产品功能都需要平台参与来编写新的评估），要么是产品团队各自为政，最终导致工具不统一、测试套件过时且缺乏共享标准。

那些已经解决这个问题的公司——即在生产环境中运行大规模智能体（Agentic）和 LLM 系统的公司——通常会将他们的 AI 工作流封装在足够的基础设施中，使得评估失败会像传统软件工程中的测试失败一样阻断发布。评估成为了部署流程中一等公民的一部分，而不是团队在记得时才运行的可选步骤。

揭示你的组织是否真正解决该问题的三个决策

与其抽象地询问“谁负责 AI 质量？”，不如通过三个具体的决策来揭示所有权是真实存在的还是名义上的：

谁来设定验收标准？ 每个部署的 AI 功能都应该有明确的阈值：什么样的幻觉率是可以接受的，需要达到什么样的任务完成率，期望什么样的响应一致性。如果答案是“我们还没有设定明确的阈值”或“由 ML 团队决定”，那么你就存在差距。验收标准应该由产品经理（了解用户需求）、技术负责人（了解什么是可实现的）和风险负责人（了解哪些失败是不可接受的）共同拥有。

谁来批准影响模型行为的变更？ 提示词（Prompt）变更、检索变更、模型版本提升以及系统消息修改，都有可能在大规模范围内改变行为特征。如果这些变更可以在没有结构化评审和评估运行的情况下进行，那么你就存在差距。答案应该是一个被指定的个人或团队，他们有权限也有义务运行相关评估并签字确认。

当输出质量下降时，谁来调查？ 当用户开始反馈输出变差，或者自动化质量指标出现偏移时，应该有一个明确的轮值（On-call）职能来响应——而不是进行跨团队讨论这到底是谁的问题。如果答案是“我们会想办法解决”，那真正的答案就是没人负责。

构建轻量级的所有权结构

对于尚未解决这一问题的团队，最务实的方法是制定一份评估章程（Eval Charter）：这是一份简短的文件，每季度更新一次，明确指定 AI 质量每个维度的负责人。

章程不需要面面俱到。它需要回答五个问题：我们在衡量什么？谁负责衡量它的基础设施？谁编写测试用例？谁批准部署？质量下降时谁负责轮值？

一份只有半页纸长、相关团队每个人都读过并在事故期间被引用的章程，其价值远高于存在于没人看的 Wiki 里的复杂治理框架。

章程下的组织结构并不如明确的、指定的所有权存在重要。在各种模式下，都有团队交付了可靠的 AI 系统——无论是嵌入式 AI 工程师、中心化平台团队，还是混合型的卓越中心（Center-of-Excellence）安排。与失败相关的并不是具体的模式，而是任何模式的缺失，以及填充真空的弥散责任。

本周要问的一个令人生畏的问题

生产环境中的大多数 AI 质量失败主要并不是由糟糕的模型引起的。它们是由在没有“谁来负责？”的明确答案下构建和部署 AI 系统的团队造成的。当出现问题时——政策被幻觉化、用户收到有害输出、行为回归在未察觉的情况下发布——根本原因几乎总能追溯到所有权缺失，而不是模型的局限性。

问题不在于你的组织是否足够成熟到能做好这件事。而在于你是否就谁负责什么做出了明确的决策，以及这些决策是否体现在你的部署流程、轮值表和发布标准中。

如果你还没有进行过那场对话，风险就不在模型上。而在你的组织架构图上。