企业官网建设流程全解析

• 示例工程

本文基于开源仓库 MLOps-Basics 的顶层 README.md 展开，系统梳理了一条从 0 到 9 的 MLOps 学习路径：以 BERT 二分类（CoLA 句子可接受性判断）为统一实验载体，逐周覆盖项目搭建、实验监控、配置管理、数据版本控制、模型打包、容器化、CI/CD、镜像仓库、无服务器部署与在线预测监控。读完本文，你将掌握一套可复制、可落地的模型全生命周期工程化方案，并能在仓库每个 week_* 目录中找到对应的可运行源码与配置文件。

该仓库的目标非常明确：理解 MLOps 的基础——模型构建、监控、配置、测试、打包、部署、CI/CD 等，而非追求 SOTA 效果（各子目录 README 均声明 "The purpose of the project to explore the libraries and learn how to use them. Not to build a SOTA model."）。全项目以 Google 的 BERT tiny 模型（google/bert_uncased_L-2_H-128_A-2）在 GLUE CoLA 数据集上做句子可接受性二分类为主线，每一周在上一周基础上叠加一项 MLOps 能力，最终形成从训练到监控的闭环。

仓库整体结构与 10 周学习路径

从仓库根目录看，项目按周组织为 10 个平级目录，每目录内部结构随周次逐步复杂化：

各周之间保持强连续性：week_0的train.py到week_2的train.py是同一份训练主入口的逐步演进（引入 Hydra 配置注入）；week_4开始新增convert_model_to_onnx.py与inference_onnx.py，后续 Docker、Lambda 均以 ONNX Runtime 推理为服务底座。

Week 0：项目搭建——数据、数据加载器、模型、训练与推理的最小闭环

Week 0 的目标是搭建一个最简单的文本分类工程，聚焦五个问题：如何获取数据、如何处理数据、如何定义 DataLoader、如何声明模型、如何训练与推理。对应源码在 week_0_project_setup 目录，共四个核心文件：data.py、model.py、train.py、inference.py。

数据模块：Huggingface Datasets + LightningDataModule

week_0_project_setup/data.py 用pl.LightningDataModule封装了数据生命周期，核心设计点：

• prepare_data()中通过load_dataset("glue", "cola")下载 CoLA 数据，并拆分为train_data与val_data；
• tokenize_data()使用AutoTokenizer对句子做截断（truncation=True）和定长填充（padding="max_length", max_length=512）；
• setup(stage)按阶段对数据批量map分词，并用set_format(type="torch", columns=["input_ids", "attention_mask", "label"])转换为 PyTorch 张量格式；
• 提供train_dataloader()（shuffle=True）与val_dataloader()两个标准方法。

注意tokenize_data的max_length=512是 BERT 类模型的上限；CoLA 句子通常很短，这个取值偏向保守，week_2 之后该参数被下移到配置文件中（max_length: 128）。

模型模块：LightningModule 封装 BERT 分类头

week_0_project_setup/model.py 定义ColaModel(pl.LightningModule)：

• 默认模型名google/bert_uncased_L-2_H-128_A-2（2 层、hidden size 128 的小模型，训练快、适合教学）；
• save_hyperparameters()自动记录超参（model_name、lr=1e-2）；
• forward()取 BERT 输出的[CLS]向量（outputs.last_hidden_state[:, 0]），过一个nn.Linear(hidden_size, 2)得到二分类 logits；
• training_step/validation_step分别计算交叉熵损失并记录train_loss、val_loss、val_acc（prog_bar=True使指标显示在进度条中）；
• configure_optimizers()返回 Adam，学习率从self.hparams["lr"]读取。

训练与推理入口

week_0_project_setup/train.py 组装了训练闭环：

• ModelCheckpoint(dirpath="./models", monitor="val_loss", mode="min")保存验证损失最小的权重；
• EarlyStopping(monitor="val_loss", patience=3, mode="min")防过拟合；
• pl.Trainer配置gpus=(1 if torch.cuda.is_available() else 0)、max_epochs=5、logger=TensorBoardLogger(...)，同时挂载两个回调。

week_0_project_setup/inference.py 定义ColaPredictor：

• 通过ColaModel.load_from_checkpoint(model_path)加载 checkpoint 并eval()+freeze()；
• 复用DataModule().tokenize_data()完成同一套预处理，保证训练/推理输入一致；
• predict(text)对 logits 做Softmax(dim=0)，输出[{"label": "unacceptable"/"acceptable", "score": ...}]格式。

运行方式（与子目录 README 一致）：Python 3.8 下conda create --name project-setup python=3.8 && conda activate project-setup，然后pip install -r requirements.txt安装依赖（pytorch-lightning==1.2.10、datasets==1.6.2、transformers==4.5.1、scikit-learn==0.24.2，见 requirements.txt），最后python train.py训练、更新 checkpoint 路径后python inference.py推理。若在 Jupyter 中运行，还需先conda install ipykernel并将虚拟环境注册为内核（python -m ipykernel install --user --name project-setup）。

Week 1：实验监控——Weights & Biases 全量接入

Week 0 的指标只落在 TensorBoard 和终端，Week 1 的目标是系统性地用 W&B 追踪每一次实验，解决“超参怎么调、模型怎么比、数据和模型之间的关联怎么看”的问题。对应源码在 week_1_wandb_logging。

训练侧：WandbLogger 替换 TensorBoard

week_1_wandb_logging/train.py 相比 Week 0 的关键改动：

• 引入WandbLogger(project="MLOps Basics", entity="raviraja")，直接作为pl.Trainer的logger；
• 指标命名改为分组式：train/loss、valid/loss、valid/acc等，方便 W&B 面板按前缀聚合；
• log_every_n_steps=10、deterministic=True保证可复现，并预留了limit_train_batches=0.25/limit_val_batches=0.25的快速验证开关。

指标计算：torchmetrics 全面替代手写

week_1_wandb_logging/model.py 把 Week 0 用sklearn.metrics.accuracy_score手算准确率的方式，升级为torchmetrics模块化指标，并首次使用AutoModelForSequenceClassification（输出自带 logits 与 loss）：

• 训练/验证准确率：torchmetrics.Accuracy()
• F1、宏平均/微平均精确率与召回率：torchmetrics.F1(num_classes=2)、Precision(average="macro"/"micro")、Recall(...)
• 每个验证 step 通过self.log(...)记录 6 类指标（loss、acc、precision_macro、recall_macro、precision_micro、recall_micro），并区分on_step与on_epoch两种聚合粒度。

三种图表上报方式

validation_epoch_end中演示了往 W&B 记录混淆矩阵的三种途径，其中主力是wandb.plot.confusion_matrix(probs=logits.numpy(), y_true=labels.numpy())，其余两种（wandb.sklearn.plot_confusion_matrix与 seaborn 热力图、ROC 曲线）以注释形式保留，可按需切换。

数据样本可视化回调

SamplesVisualisationLogger(pl.Callback)是一个重要工程模式：在on_validation_end时取一个验证 batch，把原始句子、真实标签、预测标签组装成pandas.DataFrame，筛出预测错误的样本（df[df["Label"] != df["Predicted"]]），再通过trainer.logger.experiment.log({"examples": wandb.Table(...)})上传为表格。这让你在 W&B 面板里直接查看模型“哪里错了”，建立数据与模型表现的直观关联。

训练结束后终端会输出wandb: Synced ... runs/xxx形式的同步信息（见 week_1_wandb_logging/README.md），跟进链接即可在 Dashboard 查看全部图表。至此，实验可追溯性（超参、指标、样本）全部打通。

Week 2：配置管理——Hydra 把硬编码参数全部外置

Week 2 解决的是 Week 0/1 中参数散落在代码里的问题：模型名、tokenizer、batch size、max length、epochs、日志频率、是否确定性、batch 限制比例等全部进入 Hydra 配置体系，实现配置与代码分离。对应源码在 week_2_hydra_config，配置目录为configs/。

配置目录结构

configs/ ├── config.yaml # 入口配置，声明 defaults 与日志覆盖 ├── model/default.yaml # 模型名、tokenizer ├── processing/default.yaml# batch_size、max_length └── training/default.yaml # max_epochs、log_every_n_steps 等

入口文件 configs/config.yaml 使用defaults列表组合各分组配置，并override hydra/job_logging: colorlog与override hydra/hydra_logging: colorlog启用彩色日志：

defaults: - model: default - processing: default - training: default - override hydra/job_logging: colorlog - override hydra/hydra_logging: colorlog

三个分组配置文件的具体内容：

• model/default.yaml：name与tokenizer均指向google/bert_uncased_L-2_H-128_A-2；
• processing/default.yaml：batch_size: 64、max_length: 128（相比 Week 0 的 512 更贴合 CoLA 短句，训练更快）；
• training/default.yaml：max_epochs: 1、log_every_n_steps: 10、deterministic: true、limit_train_batches: 0.25，其中limit_val_batches: ${training.limit_train_batches}演示了Hydra 变量插值（Variable Interpolation）——验证 batch 比例直接引用训练配置的值。

代码侧如何消费配置

week_2_hydra_config/train.py 用@hydra.main(config_path="./configs", config_name="config")装饰main(cfg)，函数签名接收cfg对象：

• logger.info(OmegaConf.to_yaml(cfg, resolve=True))把解析后的完整配置打印出来，便于排查；
• DataModule(cfg.model.tokenizer, cfg.processing.batch_size, cfg.processing.max_length)、ColaModel(cfg.model.name)、max_epochs=cfg.training.max_epochs、log_every_n_steps=cfg.training.log_every_n_steps、deterministic=cfg.training.deterministic、limit_train_batches=cfg.training.limit_train_batches全部由配置驱动。

命令行覆盖与批量实验

无需改任何代码，即可在命令行覆盖配置并开展多组参数实验，这正是 Hydra 的核心价值：

# 覆盖单个参数 python train.py processing.batch_size=32 # 覆盖模型名，跑不同的预训练模型 python train.py model.name=bert-base-uncased # 覆盖训练轮数 python train.py training.max_epochs=10 # 覆盖插值来源：让训练与验证 batch 比例解耦 python train.py training.limit_val_batches=0.5

由于配置文件被拆分为 model / processing / training 三个维度，组合不同参数即可系统化扫参（如「模型 × batch size × epochs」），每次运行 Hydra 还会自动生成独立输出目录，配合week_1的 W&B 记录，实验对比与回溯变得非常轻松。

Week 3：数据版本控制——DVC 管理模型文件

Week 3 解决 Git 无法高效管理大文件的问题：经典代码版本控制不是为处理大文件设计的，克隆和存储历史会变得不切实际，而机器学习中模型、数据集又恰恰是大文件。对应源码与配置在 week_3_dvc。

学习路径上的关键动作

README 列出的 Week 3 主题为：DVC 基础、初始化 DVC、配置远端存储、保存模型到远端、模型版本化。仓库中保留了可直接研读的产物——dvcfiles/trained_model.dvc：

wdir: ../models outs: - md5: c2f5c0a1954209865b9be1945f33ed6e size: 17567709 path: best-checkpoint.ckpt

这份.dvc文件说明了 DVC 的工作模型：真正的模型二进制（约 17.5 MB 的best-checkpoint.ckpt）不进 Git，只把它的md5校验和、文件大小与wdir（相对路径）记录成一个小文本文件提交到 Git；DVC 通过 md5 判断内容是否变化，通过远端存储（如 Google Drive、AWS S3）保存实际对象。对应命令流程为：

dvc init # 初始化 DVC dvc remote add <name> <url> # 配置远端存储（如 Google Drive / S3） dvc add ../models/best-checkpoint.ckpt # 跟踪模型文件并生成 .dvc 文件 dvc push # 把模型对象上传到远端 # 切换版本时 git checkout <commit> # 切换 .dvc 文件的版本 dvc pull # 拉取对应版本的模型对象

通过「Git 管元数据 + DVC 管二进制」，模型版本与代码版本一一绑定，复现历史实验只需同时 checkout 代码与模型即可。

Week 4：模型打包——ONNX 与 ONNX Runtime 跨框架推理

Week 4 回答“为什么需要模型打包”：模型可能用 sklearn / TensorFlow / PyTorch 等任意框架训练，却要部署到移动端、Web、树莓派等不同环境，甚至希望“PyTorch 训练、TensorFlow 推理”。一个统一的、可被多种框架、工具、运行时和编译器消费的文件格式至关重要，这就是社区项目 ONNX。对应源码在 week_4_onnx。

转换脚本：torch.onnx.export

week_4_onnx/convert_model_to_onnx.py 演示了完整的 PyTorch → ONNX 导出：

• @hydra.main复用 Week 2 的配置体系（cfg.model.tokenizer、cfg.processing.batch_size、cfg.processing.max_length），证明配置管理与模型打包可以无缝衔接；
• 从models/best-checkpoint.ckpt加载训练好的ColaModel；
• 从训练 DataLoader 取一个真实样本作为导出用的 dummy 输入（input_ids、attention_mask各加 batch 维度）；
• 核心调用torch.onnx.export，关键参数：
  • export_params=True导出训练好的权重；
  • opset_version=10指定 ONNX 算子集版本；
  • input_names=["input_ids", "attention_mask"]、output_names=["output"]为模型输入输出命名；
  • dynamic_axes把第 0 维声明为动态batch_size，使导出模型支持变长 batch 推理；
  • 输出保存为models/model.onnx。

ONNX Runtime 推理

week_4_onnx新增的 inference_onnx.py（后被week_5~week_9复用）定义ColaONNXPredictor：通过onnxruntime.InferenceSession加载.onnx模型，session.run(output_names, {input_names: tensors})完成推理，并沿用 Week 0 的 tokenize 预处理与 softmax 后处理，输出与ColaPredictor一致的 label/score 结构。这意味着推理服务从此不再依赖 PyTorch 与 Transformers 运行时，仅需 ONNX Runtime 即可，为后续 Docker 精简镜像、Lambda 冷启动优化奠定基础。

Week 4 的学习主题还包括“Comparisons”——即对比 PyTorch 原生推理与 ONNX Runtime 推理在延迟、依赖体积、跨平台能力上的差异，仓库代码结构（inference.pyvsinference_onnx.py并存）即为可复现对照实验的两个入口。

Week 5：容器化——FastAPI + Docker + Docker Compose 一键部署

Week 5 解决经典难题——“It works on my laptop/system”。他人运行你的应用时，常因依赖或操作系统差异失败；手动配置主机环境既繁琐又易错。容器技术将应用连同环境一起打包，可在任意云平台获得托管服务、自动扩缩容与高可靠性，而最主流的工具就是 Docker。对应源码在 week_5_docker。

FastAPI 推理服务

week_5_docker/app.py 用 FastAPI 封装 ONNX 推理：

from fastapi import FastAPI from inference_onnx import ColaONNXPredictor app = FastAPI(title="MLOps Basics App") predictor = ColaONNXPredictor("./models/model.onnx") @app.get("/") async def home_page(): return "<h2>Sample prediction API</h2>" @app.get("/predict") async def get_prediction(text: str): return predictor.predict(text)

两个端点：/提供健康检查页，/predict?text=...接受文本并返回[{"label": ..., "score": ...}]。由于推理层已切换到 ONNX Runtime，服务不再依赖训练框架。

Dockerfile 与 Docker Compose

week_5_docker/Dockerfile 采用分层构建：

FROM huggingface/transformers-pytorch-cpu:latest COPY ./ /app WORKDIR /app RUN pip install -r requirements_prod.txt ENV LC_ALL=C.UTF-8 ENV LANG=C.UTF-8 EXPOSE 8000 CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

• 基础镜像选用 CPU 版 Transformers/PyTorch 镜像，避免携带 GPU 驱动与 CUDA 库；
• COPY全部代码后RUN pip install -r requirements_prod.txt安装推理专用依赖（注意是requirements_inference.txt这一精简清单，见 week_5_docker/requirements_inference.txt）；
• EXPOSE 8000声明端口，CMD直接以uvicorn app:app启动服务。

week_5_docker/docker-compose.yml 把编排简化到一行命令：

version: "3" services: prediction_api: build: . container_name: "inference_container" ports: - "8000:8000"

使用方式：

docker build -t mlops-basics-app . # 构建镜像 docker-compose up # 或直接编排启动 curl "http://localhost:8000/predict?text=The boy is sitting on a bench"

至此，模型被封装成一个可随处运行的标准 HTTP 服务，为后续 CI/CD 与云部署提供统一交付物（镜像）。

Week 6：CI/CD——GitHub Actions 自动训练、测试与部署

CI/CD 是一套编码理念与实践集合：持续构建、测试并部署迭代中的代码变更，从而降低“基于错误旧版本开发新功能”的风险，并最大限度减少人工干预。对应目录为 week_6_github_actions。

学习要点与配套工具

README 列出的 Week 6 主题包括：GitHub Actions 基础、第一个 Action、创建 Google Service Account、授权 Service Account、配置 DVC 使用该账号、配置 GitHub Action。仓库为此新增了 week_6_github_actions/parse_json.py——一个把下载的凭据文本（如 Google Service Account 的 key 文件内容）解析为 JSON 的小工具，用于在 CI 中把 DVC 远端（Google Drive）凭据注入为环境变量/文件。

在仓库中的落地形态

week_6_github_actions目录与 Week 5 结构完全一致（含app.py、Dockerfile、docker-compose.yml、ONNX 相关文件），说明 CI/CD 阶段复用并持续集成此前全部成果。典型工作流逻辑为：

1. 代码 push 触发 workflow；
2. 使用 Service Account 凭据配置 DVC 远端，dvc pull拉取被版本控制的模型；
3. 运行测试/构建检查；
4. 构建 Docker 镜像并推送，供后续部署消费。

basic_flow.png中的流程即可作为设计 CI 流水线的参照：事件 → Job（Setup → DVC Pull → 构建 → 推送）→ 部署。

Week 7：容器镜像仓库——AWS S3 与 ECR

Week 7 引入容器镜像仓库概念：镜像仓库是存放容器镜像的地方，镜像由多层文件构成，可单实例执行应用；集中托管让用户能随时提交、识别和按需拉取镜像。同时引入 S3——面向互联网的大容量低成本存储服务。对应目录为 week_7_ecr。

README 列出的主题为：S3 基础、S3 编程访问、配置 AWS S3 为 DVC 远端、ECR 基础、配置 GitHub Actions 使用 S3 与 ECR。仓库内该目录保留了 Week 5/6 的完整交付物（Dockerfile、app.py、docker-compose.yml、parse_json.py等），说明这一周的核心是把已有能力绑定到 AWS 基础设施上：

• S3 作为 DVC 远端：与 Week 3 的dvc remote add流程一致，只是 URL 指向 S3（如s3://my-bucket/dvc-store），AWS 访问密钥经环境变量（AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY）或 IAM 角色注入；
• ECR 托管镜像：docker build后用aws ecr get-login-password登录、docker tag打上 ECR 仓库地址、docker push上传；
• CI 联动：在 GitHub Actions 中配置 AWS 凭据，让流水线自动完成 S3 拉模型 → 构建镜像 → 推送 ECR 的完整链路。

Week 8：无服务器部署——AWS Lambda + API Gateway

Week 8 引入无服务器架构：无需管理基础设施即可构建和运行应用——应用仍运行在服务器上，但所有服务器管理交给 AWS，开发者不再需要预置、扩缩容和维护服务器，可聚焦核心产品。对应目录为 week_8_serverless。

Lambda Handler 实现

week_8_serverless/lambda_handler.py 是推理服务的无服务器封装：

inferencing_instance = ColaONNXPredictor("./models/model.onnx") def lambda_handler(event, context): if "resource" in event.keys(): # 经 API Gateway 触发：从 body 中解析句子 body = json.loads(event["body"]) response = inferencing_instance.predict(body["sentence"]) return {"statusCode": 200, "headers": {}, "body": json.dumps(response)} else: # 直接调用测试：event 本身即输入 return inferencing_instance.predict(event["sentence"])

设计要点：

• 在模块顶层实例化ColaONNXPredictor（复用 Week 4 的 ONNX Runtime 推理器），这样 Lambda 容器被复用时无需重新加载模型，显著降低冷启动开销；
• 处理两种调用形态："resource" in event.keys()判断是否为 API Gateway 代理触发（解析event["body"]并返回标准 HTTP 响应），否则视为直接调用（返回裸预测结果）；
• __main__中提供{"sentence": ...}的本地冒烟测试，便于不登录 AWS 也能验证 handler 逻辑。

学习路径上的主题

README 列出的动作包括：Serverless 基础、AWS Lambda 基础、用 API Gateway 触发 Lambda、用 Lambda 部署容器、用 GitHub Actions 自动化部署到 Lambda。这一周同时展示了两种部署形态：直接把 handler 打包上传，或沿用 Week 5 的镜像走「容器部署」。自动化层面，CI 中把镜像推送到 ECR 后即可触发 Lambda 函数更新（aws lambda update-function-code），完成从提交到上线的全自动链路。

Week 9：预测监控——CloudWatch + ElasticSearch + Kibana

Week 9 回答“生产环境中模型预测出问题怎么办”。监控系统能让我们确信系统平稳运行，并在故障时快速定位根因。训练与推理阶段的监控关切点不同：训练时关心 loss 是否下降、模型是否过拟合；推理时则要确信模型在做正确预测。对应目录为 week_9_monitoring。

模型预测失败的三类典型原因

README 明确列举了推理阶段模型“有效但无用”的三种场景：

1. 数据分布漂移：底层数据分布随时间变化，推理数据特征与训练数据特征不再一致，模型已过时；
2. 边缘情况：推理数据流包含训练时未见过的边角样本，模型表现差甚至报错；
3. 生产配置错误：模型在生产部署中被误配置（配置问题很常见）。

在上述任一场景下，模型从服务角度仍可能“成功”返回预测，但预测结果基本不可用。监控的价值在于及早发现这类情况并介入（如触发重训练/重部署流水线），这正是训练监控（Week 1）与预测监控（Week 9）的分工。

监控链路的搭建步骤

README 列出的主题为：CloudWatch Logs 基础、创建 ElasticSearch 集群、配置 CloudWatch Logs 对接 ElasticSearch、在 Kibana 创建 Index Patterns、创建 Kibana 可视化、创建 Kibana Dashboard。典型数据流为：

Lambda 预测日志 → CloudWatch Logs → Logstash/订阅流 → ElasticSearch 集群 → Kibana 索引与可视化

• CloudWatch Logs：Week 8 的 Lambda 每次推理都会写入日志（如Got the input: ...与预测结果），这些日志进入 CloudWatch Log Group；
• ElasticSearch 集群：创建一个 ES 集群作为日志的聚合与检索后端；
• 对接配置：将 CloudWatch Logs 通过订阅/流式传输配置到 ES，让结构化日志（句子、预测标签、分数、时间戳）可被全文检索与聚合；
• Kibana Index Patterns：定义索引模式，把日志字段（句子、label、score、timestamp）映射为可查询、可聚合的字段；
• Kibana Visualisations 与 Dashboard：基于索引构建图表（如预测标签分布、不可接受句子的比例随时间变化、各分数段的计数），拼装成 Dashboard，用于监控预测质量与数据漂移信号。

从 Week 0 到 Week 9 的完整闭环

把各周串联起来即是一条完整的模型生产化流水线：

Week0 数据/模型/训练/推理 → Week1 W&B 实验监控 → Week2 Hydra 配置管理 → Week3 DVC 数据/模型版本控制 → Week4 ONNX 跨框架打包 → Week5 Docker 容器化服务 → Week6 GitHub Actions CI/CD → Week7 S3/ECR 存储与镜像仓库 → Week8 Lambda 无服务器部署 → Week9 Kibana 预测监控

生产侧（服务与监控）依赖 ONNX Runtime 推理器（inference_onnx.py）与模型产物（models/model.onnx、DVC 跟踪的 checkpoint），开发侧依赖 Hydra 配置（configs/）与 W&B 记录——这正是「配置 → 训练 → 版本化 → 打包 → 部署 → 监控」可复现、可审计、可回滚的工程化范式。

快速开始：从本仓库起步

若想从零跑通这套流水线，推荐按周递进操作：

1. 克隆仓库后进入 week_0_project_setup，创建 Python 3.8 虚拟环境并pip install -r requirements.txt，python train.py完成首个训练闭环；
2. 依次进入后续目录，每个目录都是上一周的增量版本：观察train.py如何逐步引入 W&B、Hydra，inference.py如何演进为inference_onnx.py，app.py/lambda_handler.py如何复用同一个推理器；
3. 需要联网能力的周（W&B、DVC 远端、AWS、Kibana）请按对应 README 配置凭据与环境变量；仅做代码研读时，week_4之前的所有步骤在本地 CPU 即可完成；
4. 各周目录内均附带experimental_notebooks/data_exploration.ipynb探索性笔记与完整requirements.txt，可在 Jupyter 中对照学习。

需要注意的是：本项目定位是 MLOps 基础教学（明确声明 "Not to build a SOTA model"），所有周次均使用小规模 BERT 模型与受限训练轮数/数据比例（如max_epochs: 1、limit_train_batches: 0.25）保证可复现、低门槛运行；将同一套工程模式迁移到生产项目时，应根据数据规模与算力资源调整这些配置。

• 示例工程