AI 项目从演示进入日常运营后，会出现一类传统软件不常见的变化：代码没改，模型版本变了；模型没变，知识库更新了；接口都正常，回答质量却悄悄下降。若团队仍靠群聊、个人经验和临时检查，上线越多，维护越混乱。
“标准运营”不是追求一套适合所有公司的厚重流程，而是为反复发生的动作建立共同口径：谁接收需求，什么算通过，版本怎样发布，异常如何发现，何时回退，以及怎样判断投入仍有价值。
## 先建立 AI 服务目录
许多团队只有模型清单，却不知道模型支撑了哪些业务任务。服务目录应以用户可感知的能力为单位，例如工单分类、知识问答、文档抽取或销售摘要，而不是“某某大模型接口”。
每项服务记录负责人、使用者、输入输出、依赖模型、知识源、工具、更新频率、流量、目标指标和回退路径。模型可以替换，服务身份保持稳定。这样发生供应方故障或版本退化时，团队能迅速知道受影响的业务。
目录还要标出服务等级。实时客服需要低延迟，夜间文档处理更关心吞吐，内部试验允许人工检查。不同等级采用不同的监控和发布强度，不必让所有项目承受相同成本。
## 把“效果好”改写成服务目标
传统站点可用率只说明接口是否响应，不能说明 AI 是否完成任务。服务目标应同时覆盖系统、模型和业务三层。
系统层包括成功率、延迟、超时和资源使用；模型层包括答案正确、引用有效、格式合格、工具参数正确和必要时拒答；业务层关注端到端完成率、人工修改时间、返工和每个合格结果成本。
Google SRE 的服务级别目标思路强调，用可测指标定义期望水平，并用错误预算平衡可靠性与变更速度。AI 服务也可以采用类似做法：质量或可用性低于目标时，暂停新功能，优先修复数据、提示或基础设施。
## 为每次变更设置评测门禁
AI 版本不只是模型权重。一个可发布版本至少包含代码、模型、系统提示、示例、检索配置、索引快照、工具接口和解码参数。任何一项变化都可能改变输出。
门禁从固定评测集开始。样本来自真实任务，包含正常、边界、信息缺失、冲突资料和工具失败。每次候选版本与当前生产版本在同一条件下运行，只有关键指标没有越过退化阈值，才进入小流量试验。
开放式任务可结合规则、模型评审和人工抽样，但评审方法也要先与人工标注对齐。不要让同一个候选模型既生成答案又给自己打分。
## 版本号要覆盖整个工作流
若只记录模型名称，线上结果仍难以复现。一次请求应关联服务版本，其中包含模型 ID、提示版本、知识库版本、检索器、工具 Schema 和应用提交号。
知识更新也作为正式发布。新手册入库后先运行检索回归，检查旧问题是否仍能找到正确片段，再切换索引别名。提示修改同样经过评测和审批，而不是直接粘贴到生产控制台。
版本记录需要机器可读，并与发布日志关联。用户报告问题时，运维人员能用请求 ID 找到当时完整组合，而不是用今天的系统猜测昨天发生了什么。
## 小流量发布并保留回滚
通过离线评测不等于适合真实流量。新版本先处理少量请求，或以影子模式运行而不影响用户，再比较质量、延迟、成本和错误类型。
发布应固定观察窗口和停止条件。例如格式错误率明显上升、关键任务失败、工具调用次数异常或成本超限时自动停止扩量。团队事先决定谁能回滚，避免故障发生后还在等待多人表态。
Kubernetes 的滚动更新、状态查看和回退机制提供了基础设施范式。AI 服务还需要把模型、提示与索引作为同一发布单元，否则代码回退了，知识和配置却仍留在新版本。
## 可观测性要贯穿一次任务
OpenTelemetry 将遥测分为 trace、metrics 和 logs。一次 AI 任务可以作为 trace，检索、模型生成、工具调用和人工确认分别作为 span；指标观察整体趋势，结构化日志保存关键事件。
每个 span 记录耗时、状态、版本和必要的统计量。模型步骤可记录输入输出词元、重试和停止原因；检索步骤记录查询、文档 ID 和分数；工具步骤记录接口状态与经过筛选的错误信息。
监控面板不应只显示 GPU 和请求量。团队还要看到任务完成率、无引用回答、人工改写、异常长输出和单位结果成本。技术信号与用户结果关联后，告警才有运营意义。
## 告警必须能触发明确动作
一个好的告警说明哪个服务、哪类用户、哪项指标发生了什么变化，并附上可操作入口。若所有波动都通知全员，很快就会形成告警疲劳。
为每项核心指标设置警告与紧急两级阈值。缓慢成本上升可以进入工作日排查，支付或发送动作错误则需要立即停止相关工具。告警关联运行手册，列出检查版本、上游数据、供应方状态、最近变更和回退命令。
对质量问题，可用线上抽样评测、用户反馈和规则异常共同发现。单个差评不一定代表系统退化，但同类错误短时间集中出现，应触发样本聚类和版本对比。
## 事件响应先恢复再解释
AI 事件可能表现为接口故障、答案质量下降、知识过期、工具误调用或成本激增。值班人员首先降低影响：切换备用模型、关闭有副作用工具、退回稳定索引，或让系统只返回原始资料。
恢复后再沿 trace 检查故障点。时间线记录首次异常、告警、人工发现、缓解动作和恢复时间。讨论聚焦系统条件，不把问题简单归咎于某个操作员或一次提示修改。
复盘必须产生可验证改进，例如新增一个回归样本、一个自动检查或一个回退步骤。只写“加强观察”无法改变下一次结果。
## 知识库需要独立运营节奏
RAG 系统的内容会过期、重复和冲突。文档负责人决定哪些资料有效，数据管道记录来源、版本、生效时间和解析状态，模型团队不应独自判断业务事实。
运营任务包括监测新增与删除、索引失败、检索空结果和旧版本引用。每次资料更新抽取一组受影响问题重新评测，确认召回片段与答案都已变化。
热门问题没有结果时，不要让模型用常识填空。系统返回缺失状态并创建内容待办，知识团队补充资料后再关闭问题。
## 人工反馈要结构化
点赞和点踩只能告诉团队用户情绪，不能直接指出修复方式。反馈界面应允许选择原因，例如来源不对、遗漏字段、格式不合适、内容过时或工具动作失败。
人工修改保留差异，但不自动进入训练集。先去重、验证和归类，再决定更新提示、知识、工具还是微调数据。经过确认的失败样本加入评测集，下一版本必须证明已经修复且没有破坏其他任务。
运营团队定期查看高频失败簇，而不是逐条追逐孤立案例。相同根因一次修复，通常比不断重写单个答案更有效。
## 成本按合格任务核算
词元价格只是成本的一部分。一次任务可能包含检索、多个模型、工具、重试和人工复核。把这些成本相加，再除以通过验收的任务数，才能比较不同方案。
每周观察输入长度、输出长度、缓存命中、模型路由、重试率和人工用时。某项成本突然增长时，先定位流量结构或版本变化，而不是一律换成更小模型。
预算可以设在服务层。接近限额时先降低非关键批任务优先级、缩短无效上下文或启用低成本回退，而不是让全部请求突然停止。
## 建立日、周、月三级节奏
每日查看紧急告警、服务状态、异常成本和待处理人工任务。每周复盘质量趋势、失败簇、知识更新和即将发布的变更。每月审查服务目标、真实收益、容量和是否仍需保留低使用率项目。
会议不需要重复念面板。会前自动生成变化摘要，会议只处理需要决策的异常、资源冲突和改进项。每个行动有负责人、截止时间和验收方式。
运营节奏的目的不是增加仪式，而是让隐性经验变成稳定循环，使小团队也能管理越来越多的 AI 服务。
## 一个六周落地方案
第一周盘点服务和负责人，第二周为两项核心服务定义系统、模型与业务目标。第三周整理真实评测集并建立版本清单，第四周接入端到端追踪和关键告警。
第五周实现小流量发布、停止条件和完整回退，第六周举行一次模拟故障与复盘。选择一个模型超时、一个知识版本错误和一个工具失败场景，验证运行手册是否真的能用。
完成后再复制到其他服务。模板可以统一，阈值和评测必须根据任务调整。
## 标准化最终服务于变化
AI 系统不会因为建立流程就停止变化。标准运营的价值恰恰是让团队敢于变化：每次调整都有基线、有观察、有退出路径，问题发生后能够复现并修复。
先从服务目录、评测门禁、版本组合、端到端追踪和回滚五件事开始。它们形成最小闭环后，AI 才从少数人的实验变成可以长期交接的生产能力。
## 参考资料