尾声

当产品、工作流程或机构开始依赖人工智能时，AI 就成了基础设施。判定标准是依赖关系，而不是新奇程度、模型规模或一次令人信服的演示。一旦系统承担了重要工作，就必须在输入、负载、供应商和要求不断变化的情况下得到持续维护。系统行为异常时，运营人员必须看得见；发布失败时，必须能够恢复；输出造成损害时，也必须有人说明原因并承担后果。这些责任属于完整的生产系统，而不是其中某个孤立组件。模型只是其中一个组件，与数据流水线、服务软件、检索、工具、身份系统、策略、界面、运营人员和物理设施共同构成服务。改进模型可以提升系统，却不能代替系统应当履行的责任。

本书反复使用的三个循环，可以帮助我们找到这些责任产生的位置。训练循环把受治理的数据、计算资源、优化目标和更新方法组合起来，生成新的模型工件。推理循环把模型工件、请求和运行时状态组合起来，在内存、延迟、吞吐量与成本限制下产生结果。智能体循环还能通过工具让结果改变外部状态，因此又引入授权、影响追踪、对账与恢复。三个循环各自保存不同的状态，也需要不同的控制措施，但它们彼此相连：训练生成推理使用的模型工件，推理可以提出行动，智能体执行留下的记录又可能进入后续评测。若把三者都笼统称为「模型」，证据、权限或责任究竟在哪一步发生变化就会被掩盖。

约束传导图是梳理这套系统的实用方法，它能显示一项局部选择如何形成下游责任。分词器会改变不同语言的表示成本与保真度。上下文窗口会改变内存需求、调度方式、检索设计，以及单次请求可能暴露的敏感信息量。基准测试会塑造发布声明，团队一旦围绕指标优化，它还会反过来影响训练激励。沙箱可以限制一部分外部影响，却不能判断某项行动是否获得授权。这些机制都不只是局部实现：它们把约束向上传递给产品与运营；延迟、隐私和恢复要求则把约束向下传回架构与硬件。只有看清这种双向传导，团队才能判断一次看似局部的调整会让谁承担新的工作。

因此，能力、效率与可信度构成一个系统层面的向量，而不是一份排名。能力关注的是：系统能否在声明适用的人群与场景中完成用户可见的任务。效率关注的是：得到一个可接受结果需要多少时间、能源、硬件、资金与人工审查。可信度关注的是：主张是否有充分证据，系统是否始终处在授权范围内，以及运营人员能否发现、遏制、解释故障并从中恢复。这三个维度互相影响。增加测试时计算可能提高能力，也可能拉长延迟；更便宜的模型可能扩大可及性，却在某个重要群体上失效；更强的行动策略可能完成更多工作，也可能扩大故障的影响范围。谈论进步时，必须说明改变的是哪个维度、对谁有效、在什么条件下成立，又付出了什么代价。

生产证据也需要同样严格的处理。生产事件首先是一条观测记录，不会自动成为标签，也不会自动成为训练数据。它同时受到线上模型、界面、策略、流量构成以及使用者选择的影响，有些人甚至没有选择不用系统的权利。采集之前，运营方需要明确采集目的，并制定与目的相称的保留政策；解释之前，需要说明抽样与纳入规则、评分准则或其他质量判定方法，还要交代缺失反馈与偏差；再次使用之前，则要分开评测集与训练集，落实使用权与删除控制，检查污染，并设置发布门禁。点赞、接受编辑或没有投诉，都可以提供有用证据，但任何一种信号都不应直接被当作事实标签。

技术改进可能只是转移瓶颈，而不是消除瓶颈。推理成本下降可以让更多人用上服务，也会让薄弱控制在更大规模上造成更高代价。上下文变长可以为决策提供更多相关证据，同时增加内存压力、隐私风险和提示注入暴露。模型裁判变强可以降低测量成本，也会让系统更加依赖裁判的评分准则、校准质量与盲区。合成数据能够增加某些任务的数据供给，也可能放大错误、压缩多样性或模糊来源。智能体能力提高后，瓶颈可能从生成答案转向验证、授权与审查。这些都是条件性压力，不是对未来的断言。它们在运营上是否重要，必须在主张实际适用的系统与人群中测量。

运营 AI 基础设施，也是在决定利益、成本和权力如何分配。架构、默认设置、合同、采购方式与数据权利，会影响谁获益、谁付费、谁被排除，谁拥有权限，以及失败后如何处理。托管服务与开放权重会让不同参与者承担不同形式的依赖。低价默认方案可以改善可及性，也可能把审查工作转嫁给用户；严格控制可以避免伤害，也可能阻止正当用途。系统并不会因为政策写进代码或指标就变得中立。相关的价值选择应当体现在系统承诺、访问规则、升级路径与补救措施中，使它们能够被审查，也能够被修改。

下一步

选择一个由你负责的系统，为它建立一份简洁、带版本的运营记录。先写清系统身份，包括模型与分词器版本、服务配置、工具、策略以及关键数据依赖；再写明用户承诺，以及承诺适用的人群。每项主张都要连接到对应的测量结果、不确定性和失效条件。记录延迟、成本、容量与审查预算，数据用途与保留期限，工具权限，租户隔离，回滚条件，事故等级与升级流程，以及每项决策负责人。最后把这些字段汇入发布记录，使每一种上线行为都能追溯到支持它的证据与审批。

要让这份记录保持有效，就要承认证据既有适用范围，也会过期。一项结果应明确对应的系统版本、适用人群、任务分布、测量方法与日期。某个机制关系重大时，先阅读一手资料，再检查本地实现它的代码、配置或评测框架。测试成功路径时，也要同样认真地测试超时、依赖不可用、工具响应格式错误、权限被拒绝、部分操作已生效、预算耗尽和回滚等失败路径。事故或评测改变团队认知后，应立即更新相关主张与控制措施。证据没有定论时，就记录不确定性，不要把它包装成肯定的发布声明。

分歧本来就是运营环境的一部分。推理方法、可解释性、自动评测、开放发布、市场集中、版权、隐私、安全与行业规则，都包含尚未解决的技术和制度问题。团队不必等到所有人达成共识才行动，但必须说明采用了什么假设，以及什么新证据会改变决定。在证据薄弱时，优先选择可逆的控制措施；明确记录已接受风险、有依据的不变更决定，以及获授权作出决定的人。在发布边界固化之前，就把法律、安全、隐私、领域专家和用户意见纳入工作范围。

系统采取行动后，人的责任并没有结束。目标、数据、默认设置、预算、权限、测量方法、发布门禁和停止条件，仍由人来选择。当工作跨越模型供应商、工具、团队与租户时，自动化尤其容易遮蔽这些选择。良好的基础设施会让责任链保持可见：系统获准做什么，实际做了什么，发布依据是什么，人如何对结果提出异议，运营人员又如何恢复安全状态。真正需要长期追问的，不是模型看起来有多自主，而是谁仍要为系统行动的条件负责。