十个 AI 应用可以靠几位工程师逐个照看：提示词放在代码里，数据由项目成员手工整理，模型升级后抽查几条答案，出问题就在群里找熟悉的人。扩展到一百个场景后，同样的方法会迅速失效。
规模化增加的不只是请求数。业务部门更多，输入分布更杂，模型和提示版本更多，知识源更新频率不同，权限与人工审核链路也各不相同。一处公共组件的修改，可能同时影响几十个产品。因此，“从 10 到 100”本质上是从项目交付转向系统运营。
这里的数字是一种阶段比喻，并非企业必须达到的固定门槛。真正的判断标准是：新场景能否复用已有能力，变更能否批量验证，故障能否快速隔离，成本是否可以解释，团队是否敢于回退。
## 先区分复制和规模化
复制是把第一个应用的代码、提示和数据库再部署九十九次；规模化是把共性能力沉淀为平台，同时允许每个场景保留必要差异。前者上线快，却会产生一百套版本和一百种故障处理方式；后者前期多做一些边界设计，之后才可能持续迭代。
并非所有东西都应统一。身份认证、日志、模型网关、评测运行、配额、发布和回退适合共享；任务目标、权威数据、人工确认点和用户界面则往往属于具体业务。平台只管理真正稳定的共性，避免成为要求所有团队排队的巨型中间层。
## 把每个场景写成产品契约
AI 应用不应只用一句“帮用户写报告”来定义。一个可运营的契约需要说明输入来自哪里、输出供谁使用、哪些事实必须有证据、什么情况下拒答、允许调用哪些工具、哪些动作需要人工批准，以及什么指标代表成功。
契约不是一份静态说明书。它应和版本、测试集、负责人、依赖关系与回退方案放在一起。场景变化时，先改契约和验收样本，再改实现，避免模型行为在没有记录的情况下悄悄漂移。
## 共用评测骨架，保留领域答案
一百个场景不可能靠中央团队逐条阅读所有输出，但也不能只依赖一个通用“质量分”。较好的做法是分层评测。
公共层检查格式、引用、工具参数、拒答、延迟、成本和安全边界；场景层检查领域事实与任务完成度；线上层观察用户纠正、放弃、升级人工和实际流程时间。自动评分适合高频回归，关键样本仍需要领域人员复核。
Google 的 ML Test Score 将数据、模型、基础设施和监控拆成具体测试，核心启发是模型不能脱离管道接受验收。对生成式 AI 也是如此：即使模型答案没变，检索索引、工具接口或模板渲染出错，也会让最终任务失败。
每次发布只改变一个主要变量，并在固定样本上比较。模型升级、提示修改和知识库重切分若同时发生，结果变好或变坏都难以归因。
## 数据管道比模型名单更需要统一
研究原型常从一份干净文件开始，生产系统面对的却是持续变化的数据源。字段会新增，单位会改变，空值比例会上升，权限会撤回，上游团队也可能在不通知的情况下调整含义。
Google 的《Rules of Machine Learning》特别提醒训练与服务偏差：训练时使用的数据处理和线上处理不一致，会让离线指标失去意义。生成式应用也有相似问题，例如评测使用完整文档，线上解析器却漏掉附件；开发环境能调用工具，生产权限却拒绝访问。
因此应统一数据契约、版本和质量检查，而不是强求所有数据进入同一种存储。关键转换在训练、评测与服务侧尽量复用；异常值和缺失率超过阈值时，阻止新版本继续发布。
## 模型网关负责选择，不负责掩盖差异
统一网关可以处理认证、配额、重试、缓存、日志和供应商切换，也可以根据任务契约路由不同模型。但它不应假装所有模型行为完全一致。
不同模型支持的上下文、结构化输出、工具调用、图像输入和错误语义不同。网关应暴露一组明确能力，并让应用声明依赖。若某个备用模型不支持必要功能，故障时应降级到只读或人工处理，而不是偷偷输出较差答案。
## 容量规划要用真实流量形状
平均每秒请求数无法描述 AI 服务。长文总结、短分类、图片理解和多步代理消耗差异巨大；早晨批处理与白天交互请求还会争夺同一容量。规划时应记录输入输出长度、工具次数、缓存命中、并发和尾延迟。
压力测试要模拟突发，而不只是匀速发送。还要注入上游超时、限流、模型拒绝、检索失败和部分工具不可用，观察队列是否无限堆积。每条链路都需要超时、有限重试和熔断，避免一个缓慢依赖拖垮整个平台。
MLPerf Inference 展示了按场景和质量目标比较推理系统的思路，但公开基准不能代表企业流量。团队仍应使用自己的负载回放集比较质量、吞吐和尾延迟。
## 灰度发布比一次性切换更重要
模型具有统计性，单元测试通过也不能证明所有输入稳定。生产发布应从影子流量开始：新版本处理真实请求但不向用户返回结果，与旧版本比较后，再逐步开放给少量内部用户、低风险场景和小比例流量。
灰度期间同时看质量和系统指标。若新模型平均得分更高，却在某类长输入上超时，或把人工升级率推高，它仍不适合全量。每次扩容前写清停止条件，触发后自动或人工回退。
回退应覆盖模型、提示、检索索引、工具模式和数据版本。只回退模型权重，常常无法恢复整条链路。发布包最好携带这些依赖的精确版本，并能够重新运行当时的评测。
## 监控需要同时看四层
第一层是基础设施：可用性、吞吐、队列、延迟和资源。第二层是数据：字段、分布、新鲜度、权限与解析成功率。第三层是模型行为：任务通过率、无依据断言、拒答、工具错误和输出长度。第四层是产品结果：用户是否完成任务、是否频繁修改、是否转人工以及节省了多少时间。
Google SRE 的监控方法强调从系统是否真正为用户提供服务出发。AI 平台也不能因为 GPU 利用率正常就宣布健康。当答案质量下降但接口仍返回 200 时，传统可用性指标看不见问题。
告警应指向可执行动作。每个关键告警配有责任人、诊断入口和处置手册；没有行动办法的噪声告警会让值班人员麻木。事故结束后记录时间线、影响、根因和防复发措施，不把模型的随机性当成免责理由。
## 用“铺路队”和“应用队”分工
规模化团队常适合两层结构。平台团队建设网关、评测、数据契约、部署、监控和成本工具，像铺设公共道路；应用团队理解具体用户与数据，负责场景契约、黄金样本、体验和上线判断。
平台团队不替业务判断答案是否正确，应用团队也不重复制造日志和发布系统。双方通过服务目录、能力说明、版本通知和事故流程协作。对新场景，可以提供一条带默认评测与监控的“黄金路径”，但允许有证据地偏离。
## 成本应按“合格任务”计算
单次调用价格不能代表规模化成本。一个便宜模型如果频繁重试、需要更多人工审核或生成冗长内容，每个合格任务反而更贵。平台应把模型、检索、工具、存储、网络和人工复核共同计入。
优化顺序通常是先减少无价值请求，再压缩上下文和输出，复用稳定结果，最后才更换模型或硬件。对重复性高的任务，可以预计算或使用较小模型；复杂、低频且价值高的任务，再路由到更强配置。
## 结语：规模化的是反馈回路
AI 工业化并不是把十个演示复制十遍，而是建立一套能持续定义、测试、发布、观察和回退的反馈回路。模型只是链路中的一个组件，数据、工具、人员和运行机制共同决定结果。
当第一个新场景能够通过标准入口接入，使用自己的领域测试集完成验收，并在出错时被独立隔离，平台才真正具备了从 10 到 100 的能力。规模不再依赖少数人记住所有细节，而依赖可复用、可审计的工程系统。
## 参考资料