第10周：工具链与MLOps

本日概要

开发环境的目标是让实验可复现、让协作不踩坑。三件事必须做到：依赖锁定到具体版本并把锁文件纳入版本控制；数据与模型这类大文件不进代码仓库，用单独的存储加上版本标识引用；密钥永远不写进代码或笔记本，通过环境变量或密钥管理注入。笔记本适合探索但不适合作为交付物——它的执行顺序可以任意，输出会被保存进文件，很难做代码审查与自动化。合理的做法是探索用笔记本，稳定后的逻辑抽成模块并配上测试，笔记本只保留调用与展示。

学习目标

• 能建立带锁文件的隔离环境，并说明锁定版本对复现的意义
• 能设计数据与模型的存储与版本引用方式，避免大文件进入代码仓库
• 能用环境变量或密钥管理注入凭据，并说明为什么不能写进代码
• 能判断哪些逻辑应当从笔记本抽成模块，并为其补充测试

核心讲解

实践任务

为一个项目建立可复现的开发环境：锁定依赖、隔离大文件、配置密钥注入，并把一段笔记本逻辑重构为带测试的模块。

• 为项目创建隔离环境并生成锁文件，记录 Python 版本；若使用加速库，额外记录驱动与运行时版本。
• 把数据与模型移出代码仓库，改为通过路径加版本标识引用；在版本控制忽略规则中排除大文件与本地配置。
• 把一处硬编码的凭据改为从环境变量读取，验证缺少该变量时程序给出明确报错而非静默失败。
• 选一段笔记本中的核心逻辑抽成模块函数，为其写至少三条单元测试（正常、边界、异常各一），并让笔记本改为调用该模块。

自测与答案

今日完成标准

• 提交锁文件与环境重建说明，含 Python 及必要的驱动运行时版本
• 提交大文件隔离方案与版本引用方式，忽略规则覆盖大文件与本地配置
• 提交抽出的模块与至少三条单元测试，以及凭据改为环境变量后的报错验证

常见错误与纠正提示

• 只写依赖名不锁版本，几个月后无法重建环境
• 把数据、模型或凭据提交进代码仓库，历史记录中长期留存
• 把笔记本直接作为交付物，逻辑无法被审查与测试

分层任务

关联知识点

• AI开发工具链

延伸阅读

• MLflow Documentation（MLflow 官方文档）
• FastAPI Documentation（FastAPI 官方文档）

本日概要

实验管理解决的是「三周前那个效果最好的版本是怎么跑出来的」。需要被记录的至少有四类：参数（超参数与配置）、指标（训练与评估结果）、产物（模型文件、图表、报告）以及来源（代码版本、数据版本、环境信息）。MLflow 这类工具把这些组织成可检索的实验记录，让不同运行可以横向比较。关键不在于用哪个工具，而在于养成「每次运行都完整记录」的习惯——事后补记几乎总是不完整的。记录还应包含失败的运行，因为「这条路走不通」同样是有价值的信息。

学习目标

• 能列出一次实验运行必须记录的四类信息及其具体字段
• 能使用实验跟踪工具记录并检索多次运行，完成横向比较
• 能说明为什么失败的运行也应当被记录
• 能设计从实验记录到模型交付的过渡：哪些信息必须随模型一起归档

核心讲解

实践任务

为一组实验建立完整记录，包含参数、指标、产物与来源四类信息，并用记录回答一个具体的对比问题。

• 在训练脚本中加入自动记录，使每次运行上报参数、指标、产物与来源四类信息。
• 运行至少四组不同配置的实验（含至少一组明显失败的配置），确认全部被记录。
• 用记录界面完成一次横向比较，回答一个具体问题，例如「在相同数据版本下哪组超参数验证指标最好」。
• 为效果最好的一次运行编写模型说明：训练数据分布、评估集定义与结果、已知限制与不适用场景，并随产物归档。

自测与答案

今日完成标准

• 提交自动记录的实现，四类信息在每次运行中均被上报
• 提交至少四组运行记录（含失败组）与一次横向比较的结论
• 提交模型说明文档，含训练数据分布、评估集定义、已知限制与不适用场景

常见错误与纠正提示

• 依赖运行后手工填表，实际执行率低且信息不准
• 只记录成功运行，团队反复重试已被验证不可行的方向
• 交付模型时不附已知限制与不适用场景，使用者误用

分层任务

关联知识点

• MLOps
• AI开发工具链

延伸阅读

• MLflow Tracking（MLflow 官方文档）
• MLflow Documentation（MLflow 官方文档）

本日概要

把模型变成服务，首先要明确服务的形态与指标。大模型推理服务通常提供与常见接口兼容的形式，便于客户端切换；关键指标包括首词元延迟、单词元生成延迟、整体吞吐与并发数，四者互相牵制：增大批处理提升吞吐但抬高单请求延迟。部署前必须确定服务等级目标——延迟的分位数指标（如百分之九十五分位）比平均值更能反映真实体验，因为平均值会被大量快速请求掩盖长尾。此外，模型权重的加载时间、显存占用与健康检查方式，都要在部署方案中写清楚。

学习目标

• 能说明首词元延迟、生成延迟、吞吐与并发之间的相互制约关系
• 能用分位数而非平均值描述延迟，并解释原因
• 能设计压测方案，得到不同并发下的延迟与吞吐曲线
• 能为服务定义可承诺的服务等级目标，并说明超出时的降级策略

核心讲解

实践任务

部署一个推理服务并压测，绘制不同并发下的延迟分位数与吞吐曲线，据此确定可承诺的服务等级目标。

• 部署一个推理服务，记录模型加载时间、显存占用与健康检查方式，区分进程存活与模型就绪两种状态。
• 设计压测方案，覆盖至少四个并发档位，每档记录首词元延迟与整体延迟的中位数、九十五分位与九十九分位，以及吞吐。
• 绘制并发与延迟分位数、吞吐的关系曲线，找出延迟开始明显上升的拐点。
• 据此定义服务等级目标（含测量窗口与统计口径），并写出触及上限时的降级策略与开关方式。

自测与答案

今日完成标准

• 提交服务部署记录，含加载时间、显存占用与两种健康检查状态的区分
• 提交四个并发档位的延迟分位数与吞吐数据及关系曲线
• 提交含测量窗口与统计口径的服务等级目标，以及可开关的降级策略

常见错误与纠正提示

• 用平均延迟承诺服务质量，长尾问题长期不被发现
• 健康检查只检测进程存活，模型未就绪时流量已被打入
• 未定义降级策略，超载时只能临时决定并造成更大波动

分层任务

关联知识点

• AI开发工具链
• 大模型训练

延伸阅读

• vLLM: OpenAI-Compatible Server（vLLM 官方文档）
• Google SRE Book: Service Level Objectives（Google SRE Book 官方页面）

本日概要

把模型包装成接口，工程要求与普通后端服务并无二致：输入校验、超时控制、错误语义、并发模型、可观测性缺一不可。特殊之处在于三点：请求处理时间长且方差大，因此流式返回与取消传递很重要；模型调用通常是等待外部结果的操作，用异步方式承接可以显著提升并发能力，但如果在其中混入阻塞式的重计算，反而会拖垮整个事件循环；输入直接来自用户，必须做长度与内容校验，防止超长输入耗尽资源。接口设计上应当把「模型输出」与「服务状态」分开表达，让客户端能区分是模型没答上来还是服务出了故障。

学习目标

• 能为模型接口设计输入校验规则，包含长度上限与内容约束
• 能实现流式返回与客户端取消，并说明取消未传递会造成什么浪费
• 能区分异步与阻塞操作，并解释混用为什么会拖垮并发
• 能设计清晰的错误语义，让客户端区分模型未答出与服务故障

核心讲解

实践任务

用异步框架把模型包装成带流式返回、超时与错误语义的接口，并压测验证阻塞操作对并发的影响。

• 实现接口的输入校验：长度上限、必填字段与内容约束，验证超限请求在接口层即被拒绝并返回明确原因。
• 实现流式返回，并把客户端断开信号传递到推理调用处；构造一次中途断开，验证服务端确实停止了生成。
• 在异步处理函数中故意加入一次阻塞式重计算，压测记录并发能力的变化；改为放入线程池后重新压测并对比。
• 设计四类错误的语义与返回结构，为每类写出客户端应有的反应；构造样例请求验证每类都能被正确触发。

自测与答案

今日完成标准

• 提交输入校验实现与超限请求被拒绝的验证记录
• 提交流式返回与中途断开后停止生成的验证记录
• 提交阻塞操作前后的并发压测对比，以及四类错误语义的定义与触发样例

常见错误与纠正提示

• 在异步处理函数中直接执行阻塞操作，压测时才发现并发上不去
• 不传递取消信号，用户离开后服务端仍在消耗算力
• 所有失败返回同一种错误，客户端盲目重试放大故障

分层任务

关联知识点

• AI开发工具链

延伸阅读

• FastAPI Documentation（FastAPI 官方文档）
• FastAPI: Deployments Concepts（FastAPI 官方文档）
• vLLM: OpenAI-Compatible Server（vLLM 官方文档）

本日概要

机器学习系统与普通软件的关键差别在于：即使代码一行没改，效果也会随时间下降，因为数据分布在变。因此运维体系必须包含三类监控——服务层（延迟、错误率、饱和度）、数据层（输入分布是否偏移、缺失率是否上升）、以及效果层（业务指标与抽样人工评估）。只监控服务层是最常见的疏漏：接口全部返回二百，效果却已经退化数周。此外，模型与数据都需要版本化，回滚要能在几分钟内完成；上线应采用灰度而非全量切换，并预先约定回滚触发条件。

学习目标

• 能说明机器学习系统效果随时间衰减的原因，并列出三类必要监控
• 能设计数据分布偏移的检测方式与告警阈值
• 能设计效果层的抽样人工评估流程，并说明抽样比例的确定依据
• 能为模型上线设计灰度与回滚方案，包含触发条件与执行步骤

核心讲解

实践任务

为一个已部署模型设计三层监控与回滚方案，并用注入的分布偏移验证告警是否按预期触发。

• 为已部署模型定义三层监控的具体指标：服务层至少三项、数据层至少三项、效果层至少两项，逐项写出采集方式与告警阈值。
• 实现数据层的分布偏移检测，向线上流量中注入一批分布明显不同的输入，验证告警是否按预期触发并记录延迟。
• 设计人工抽样评估流程：抽样方式、比例、评分标准与记录格式，并完成一轮试评估。
• 编写灰度上线与回滚方案：放量步骤、每步观察指标与时长、回滚触发条件与执行步骤，并演练一次回滚记录耗时。

自测与答案

今日完成标准

• 提交三层监控的指标清单，逐项含采集方式与告警阈值
• 提交分布偏移注入实验的告警触发记录与检测延迟
• 提交人工抽样评估流程与一轮试评估结果，以及灰度回滚方案与一次回滚演练耗时

常见错误与纠正提示

• 只监控服务层，效果退化数周后才由业务方发现
• 全量切换新模型，出问题时影响面已经是全部流量
• 回滚依赖重新部署，耗时过长导致故障持续扩大

分层任务

关联知识点

• MLOps

延伸阅读

• OpenTelemetry: Signals（OpenTelemetry 官方文档）
• Google SRE Book: Service Level Objectives（Google SRE Book 官方页面）
• MLflow Documentation（MLflow 官方文档）

本日概要

大模型应用引入了传统应用没有的攻击面。提示注入是其中最典型的一类：攻击者把指令藏在模型会读到的内容里——用户输入、检索到的文档、网页、甚至图片中的文字——诱导模型执行非预期动作。它之所以难防，是因为模型本质上无法可靠区分「指令」与「数据」。因此防御不能依赖模型自觉，必须落在系统设计上：外部内容始终标记为数据、工具调用在执行侧独立校验、有副作用的操作需要人工确认、输出在返回前做校验。OWASP 针对大模型应用整理了常见风险清单，可作为设计评审的检查表。

学习目标

• 能说明提示注入的原理，并区分直接注入与来自外部内容的间接注入
• 能列出至少四项不依赖模型自觉的系统级防御措施
• 能识别数据泄漏风险，包括输出泄漏与日志泄漏
• 能用公开的风险清单对一个应用完成结构化的安全评审

核心讲解

实践任务

对一个检索增强应用做一次安全评审，构造三类注入尝试并验证防御措施是否生效。

• 对一个检索增强应用绘制数据流图，标出所有外部内容进入上下文的位置，以及所有模型可触发的动作。
• 构造三类注入尝试：直接在用户输入中注入、在被检索文档中注入、在工具返回结果中注入；分别记录系统行为。
• 针对未被拦截的尝试补充系统级防御（标记、权限、校验、最小暴露中的相应项），重新验证并记录。
• 用公开风险清单逐项评审，为每项记录「是否存在、当前措施、是否已验证」，形成带责任人与时间点的整改清单；同时检查日志是否包含敏感信息并给出脱敏方案。

自测与答案

今日完成标准

• 提交数据流图，标出全部外部内容入口与模型可触发的动作
• 提交三类注入尝试的行为记录，以及补充防御后的复验结果
• 提交按公开风险清单逐项评审的结果与带责任人和时间点的整改清单，含日志脱敏方案

常见错误与纠正提示

• 把防注入完全寄托于系统提示的措辞，不做系统层限制
• 只考虑用户输入这一个入口，忽略检索内容与工具返回结果
• 为排查问题保存完整请求响应日志，未脱敏且访问控制宽松

分层任务

关联知识点

• AI安全与对齐

延伸阅读

• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）
• NIST AI Risk Management Framework（美国国家标准与技术研究院官方页面）

本日概要

本周收尾把从开发到运维的完整工具链串起来，并明确每一环的交付物。链路是：环境与依赖（可复现的起点）→ 实验管理（可追溯的过程）→ 模型与数据版本（可回滚的产物）→ 服务化（可承诺的接口）→ 监控（可发现的退化）→ 安全评审（可控的风险）。每一环都应当有明确的交付物与验收标准，否则工具链会退化成一堆各自为政的脚本。评估一个团队的成熟度，最直接的问题是：能否在十分钟内回答「线上跑的是哪个模型、用哪版数据训练的、当前效果如何、出问题怎么回滚」。

学习目标

• 能画出从环境到安全评审的完整工具链，并说明各环之间的依赖关系
• 能为每一环定义具体的交付物与可检查的验收标准
• 能用一组具体问题评估当前实践的成熟度并识别薄弱环节
• 能制定分阶段的改进计划，说明每个阶段的投入与预期收益

核心讲解

实践任务

为一个项目绘制完整工具链图，为每一环写出交付物与验收标准，并用四个问题自测团队成熟度。

• 绘制从环境到安全评审的完整工具链图，标出各环之间的依赖关系与必须提前预留的接口。
• 为每一环写出交付物与可检查的验收标准，验收标准必须是他人可独立判定的。
• 用四个自测问题评估当前项目，逐题记录能否在十分钟内答出、答不出时缺的是什么。
• 制定分阶段改进计划，每阶段写明投入、预期收益与完成的判定标准，并按收益成本比排序。

自测与答案

今日完成标准

• 提交工具链图，标出各环依赖与必须提前预留的接口
• 每一环有交付物与他人可独立判定的验收标准
• 提交四问自测结果与分阶段改进计划，每阶段含投入、收益与完成判定标准

常见错误与纠正提示

• 堆砌工具却没有约定每环的交付物与验收标准
• 等出问题后才补埋点，缺少历史数据无法对比
• 改进计划只列愿望不写投入与判定标准，长期无法排期

分层任务

关联知识点

• MLOps
• AI开发工具链

延伸阅读

• MLflow Documentation（MLflow 官方文档）
• OpenTelemetry: Signals（OpenTelemetry 官方文档）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）
• Google SRE Book: Service Level Objectives（Google SRE Book 官方页面）