S11：模型未变，AI 系统版本为什么仍会改变

内容类型：预习教材（不代表已完成）
日期：2026-12-03
阶段：P2 · AI Systems Engineering 90
总路线：Day 101 / 360
周次 / 节奏：W2 · 周四案例与连接
状态：教材已备；学习未完成
主题：prompt、index、policy、tool、composite release

一句话定义

AI 系统行为由模型与上下文、检索、工具、策略、路由及运行配置共同决定，因此任何高影响组件变化都应形成新的组合版本和可比较发布证据。

学习目标

1. 能画出一个 composite AI version 的依赖图。
2. 能分析 prompt、index、policy 或 tool schema 单独改变时的行为与风险。
3. 能区分接口兼容、行为兼容、数据兼容和权限兼容。
4. 能编写一个 release bundle 案例，而不虚构评测结果或上线事实。

核心知识

模型 API 只是系统的一部分。System prompt 改变任务约束；检索索引改变可见知识；tool schema 改变可执行能力；policy 改变允许范围；路由改变请求落到哪个 provider/model；解析器改变输出能否进入业务系统。即使模型 digest 相同，任一组件都可能改变端到端结果。

版本边界应按影响而非文件类型决定。一个文案空格可能无需独立发布，提示词中的授权约束变化则必须纳入。索引更新可能是日常数据刷新，也可能更换 embedding、chunking 或过滤规则；前者可按 snapshot 版本管理，后者还需行为回归观察。Tool API 增加可选字段可能结构兼容，但模型调用分布仍会变化。

兼容性至少有四层：schema 是否可解析；semantic 是否保持相同含义；behavior 是否在关键 slice 上可接受；permission 是否没有扩大副作用。发布证据应对应变化面：只改索引不能只看模型离线 benchmark，应观察检索覆盖、引用与敏感过滤。

机制与推导

把端到端输出表示为：

[ y=F(x;M,P,I,T,G,R,E) ]

其中 M 模型、P prompt、I index、T tools、G policy/guardrails、R routing、E environment。即使 M 固定，偏导式思考 Δy/ΔP 或 Δy/ΔI 仍可能很大。系统 bundle 是这些版本的笛卡尔组合，但不必穷举所有组合；实际发布固定一个被采用的组合并记录差异。

变更影响分析可写为 change → affected paths → evidence → rollback target。Rollback 也要考虑数据不可逆性：若新工具已执行外部动作，仅把 bundle 指回旧版不能撤销业务副作用。

最小练习或观察步骤

1. 选“合规问答助手”作为纸面案例，列出 M/P/I/T/G/R 七个组件。
2. 固定模型，只让索引 snapshot 从 v1 变 v2，写出可能改善和可能退化各两项。
3. 再让 tool schema 新增一个有副作用操作，检查 schema、behavior 与 permission 三层。
4. 为两个变更分别写最小观察证据，不建立大型测试矩阵。
5. 写出 bundle v1/v2 manifest diff 与明确 rollback target。

常见误区与边界

• 只用模型名称标识线上系统，无法解释 prompt/index 差异。
• 接口能解析就宣称向后兼容，忽略语义和权限扩大。
• 每次数据刷新都做重型流程，或反过来所有刷新都无版本记录。
• 发布证据与变更面不对应，例如索引变化只看语言模型通用分数。
• 认为 rollback alias 能撤销已经发生的真实副作用。

系统场景连接

金融政策助手的模型不变，若知识库加入尚未生效的政策、过滤器漏掉地区条件，答案便可能改变。交易调查 Agent 的 tool scope 扩大，则风险从文本质量变成真实副作用。Web3 场景中，链高度、地址标签与合约 ABI 版本也属于系统上下文。组合版本把这些变化纳入同一解释单位。

自检问题

1. 哪些模型外组件最可能改变端到端行为？
2. schema compatible 为什么不等于 behavior compatible？
3. 索引更新应关联哪些特有证据？
4. 为何 rollback bundle 无法自动补偿外部动作？

专业课程对齐

• 阅读 Full Stack Deep Learning 2022 的 deployment 与 testing/monitoring 内容，观察端到端服务包含哪些模型外组件。
• 阅读 MLflow 官方文档 的 artifacts、models 与 registry 概念，把 prompt/index/tool schema 当作可追踪 artifact 与模型引用组成 release bundle。
• 阅读 Stanford CS329S 的 system design、data management 和 deployment 主题，用系统边界而非模型分数分析变更影响。

深入学习提示

用“固定模型、逐个改变外围组件”的反事实方法学习。每改变一项，写出影响路径、需要观察的信号和可回退部分。精读课程案例时找出作者默认未写出的依赖，例如 preprocessing、schema 或 provider runtime。最后画一条副作用边界：哪些变化只影响回答，哪些会改变业务状态，从而连接后续 durable workflow。

学后填写区

• 案例中的组合组件：
• 选择分析的两个变化：
• 四类兼容性结论：
• 对应的轻量证据：
• rollback 不能解决的事项：