把 AI 接入生产：版本、评测与可观测性

1. 明确“变化”来自哪里

AI 功能的输出会受多种因素影响：模型版本、采样参数、系统提示词、工具定义、检索索引、外部 API，以及用户输入分布。出现线上回归时，如果没有记录这些上下文，很难判断是模型变了、数据变了，还是应用逻辑变了。

最小实践是：对关键功能记录模型标识、主要参数、提示词版本、知识库/工具版本、请求时间和结果状态。注意对用户数据做脱敏与最小化保留。

2. 把评测放进发布流程

为高风险或高价值能力准备固定评测样本。每次修改模型、提示词、工具或检索配置时，执行同一组样本并比较：任务成功率、格式正确率、事实一致性、拒答质量、工具调用正确率和平均成本。

3. 灰度与回滚比“全量替换”更重要

模型或提示词更新后，先让小比例流量进入新版本，观察关键指标与人工反馈。若发生异常，应能快速回到上一套已验证的配置。将配置与代码一起版本化，回滚才不会依赖临时记忆。

4. 请求 ID 是排障的共同语言

一次用户请求可能跨越浏览器、应用服务、模型 API、工具和数据库。为入口请求分配唯一 ID，并在每个下游调用中关联它。用户反馈“刚才回答错了”时，才能快速定位完整链路，而不是在日志中猜测。

5. 设置成本与可用性的双重护栏

• 为单用户、单任务、单日设置 token、调用次数或金额上限。
• 对外部工具设置超时、退避重试和并发限制。
• 在模型或工具不可用时，返回清楚的降级说明，而不是伪造成功。
• 监控错误率、P95 延迟、单位任务成本、工具失败率与人工接管率。

6. 一个实用的发布前清单

1. 模型版本是否明确固定，还是允许浮动？
2. 此次变更是否通过关键评测集？
3. 是否有小流量灰度和一键回滚路径？
4. 是否能通过请求 ID 找到模型、工具与应用日志？
5. 敏感输入、输出和令牌是否按最小必要原则处理？

AI 系统的可靠性不是一次性配置出来的，而是由持续的评测、观测与回滚能力共同构成。把这些机制在早期建立起来，后续迭代会轻松得多。