MLOps Zoomcamp 课程项目实战端到端机器学习流水线的需求拆解、评估标准与仓库参考实现【免费下载链接】mlops-zoomcampFree MLOps course from DataTalks.Club. Register here to get notified about the next cohort项目地址: https://gitcode.com/GitHub_Trending/ml/mlops-zoomcamp本文以 MLOps Zoomcamp 课程最终项目文档 07-project/README.md 为主体完整拆解课程项目的问题陈述、数据集限制、技术选型空间与逐条评分细则并结合仓库中 03~06 模块的真实源码Makefile、Dockerfile、Terraform 部署脚本、监控 docker-compose说明每项评估标准对应的落地做法帮助读者在动手前就清楚项目要做什么、怎么被评分、代码该如何组织。一、课程项目目标把六个模块串成一条端到端流水线课程项目Course Project的目标是把整个课程学到的内容综合起来构建一个端到端end-to-end机器学习项目。根据 项目 README 中的 Problem statement完成项目需要依次覆盖以下六件事选择一个自己感兴趣的 dataset数据集来源见下文数据集选择与限制一节在该数据集上训练模型并全程跟踪实验experiment tracking创建模型训练流水线model training pipeline即把工作编排到 workflow orchestrator 中部署模型可选 batch批量、web serviceWeb 服务或 streaming流式三种方式之一或组合监控模型表现monitor the performance of your model遵循工程最佳实践testing、linting、Makefile、pre-commit、CI/CD 等。这六条正好对应课程模块 2Experiment Tracking、3Orchestration、4Deployment、5Monitoring和 6Best Practices的知识输出因此项目本质上是一次课程能力的集成验收。2025 cohort 的提交信息三次尝试机会、评审核查入口等记录在 cohorts/2025/project.md 中其中特别强调要判定项目通过必须完成 3 个同侪peer评审否则项目不被视为完成。二、数据集选择与限制项目允许自由选择感兴趣的数据集但文档明确设定了一条红线NYC taxi 数据集禁止用于项目。该数据集贯穿了课程各模块与作业homework项目必须挑选任何其他数据集。这一限制的用意很直接如果继续用课程里已经反复使用过的 NYC taxi 数据项目将沦为作业重做无法体现独立选型、独立建模的能力。仓库内 01~05 模块的代码如 05-monitoring/baseline_model_nyc_taxi_data.ipynb正是基于这套 taxi 数据的示例可作为流程参考但不能直接作为项目主体。关于候选数据集原文档指向课程团队维护的公共数据集清单外部仓库资源此处不展开外链。实操建议是优先选一份同时具备时间维度可用于数据漂移监控和明确目标变量可用于回归/分类评估的结构化数据这样能自然覆盖训练 → 部署 → 监控全链路。三、技术栈以课程工具为基线允许合理替换原文档给出了一份技术备选清单明确不强制限定于课程内使用的工具可以在每个环节选择等价替代方案环节课程默认工具允许的替代方案原文列举云CloudAWSGCP、Azure 等实验跟踪MLflowWeights Biases 等工作流编排Mage / Prefect / Airflow历年 cohort 不同Prefect、Airflow、Flyte、Kubeflow、Argo 等监控EvidentlyWhyLabs/whylogs 等CI/CDGitHub ActionsGitLab CI/CD 等基础设施即代码IaCTerraformPulumi、CloudFormation 等两条附加规则如果使用了课程未覆盖的工具必须在项目中解释该工具是什么、承担什么职责如果对某个工具的选择拿不准原文档建议在课程 Slack 中先提问确认。这一设计对评分的影响在于评估者会基于是否说清楚了为什么选它、它做什么来判断技术选型的合理性而不是单纯看用了哪个名字响亮的工具。四、评估标准Evaluation Criteria逐条详解以下完整继承自 07-project/README.md 的评分细则是项目规划时最重要的需求规格说明书。4.1 问题描述Problem description分值标准0 分没有描述问题1 分描述了问题但过短或不够清晰2 分问题描述充分能清楚看出项目解决的是什么问题4.2 云Cloud分值标准0 分未使用云全部在本地运行2 分项目在云上开发或使用了 localstack 之类的本地云模拟工具或部署到 Kubernetes 等容器管理平台4 分项目在云上开发并且使用 IaC 工具如 Terraform来开通基础设施注意 0 分和 2 分之间的关键区别只要基础设施不完全本地裸跑有云、有 localstack 模拟、或上了 K8s 容器平台就能拿到 2 分要拿到 4 分则必须叠加 IaC。仓库中 06-best-practices/code/infrastructure/ 目录提供了一个完整的 Terraform 参考实现见下文仓库参考实现一节包含 Kinesis、Lambda、S3、ECR 四个模块与 prod/stg 两套 tfvars。4.3 实验跟踪与模型注册Experiment tracking model registry分值标准0 分既没有实验跟踪也没有模型注册2 分二者只做了一件事跟踪实验或注册模型4 分实验跟踪与模型注册同时使用4.4 工作流编排Workflow orchestration分值标准0 分没有工作流编排2 分基本的流程编排如能跑通流程定义4 分完全部署fully deployed的工作流即编排工具本身部署在云/服务端并真实调度运行仓库 03-orchestration/README.md 给出的编排落地步骤选工具 → 本地跑通 hello world → 编排流水线各步骤 → 参数化调度月跑、训练/验证数据按月份切分→ 补数据 backfill → 可选的云端部署可以直接作为达到 4 分标准的操作清单。该文档还附带了 MLflow 服务器的 Dockerfile 与 docker-compose 片段用于把实验跟踪服务容器化。4.5 模型部署Model deployment分值标准0 分模型未部署2 分部署了但仅在本地4 分部署代码已容器化理论上可部署到云或使用了专门的模型部署工具关键动作是容器化。仓库 06-best-practices/code/Dockerfile 展示了一个完整的 Lambda 推理镜像构建过程可作为项目部署容器的参考FROM public.ecr.aws/lambda/python:3.9 RUN pip install -U pip RUN pip install pipenv COPY [ Pipfile, Pipfile.lock, ./ ] RUN pipenv install --system --deploy COPY [ lambda_function.py, model.py, ./ ] CMD [ lambda_function.lambda_handler ]要点先复制Pipfile/Pipfile.lock并用pipenv install --system --deploy锁定依赖--deploy要求 lock 文件与 Pipfile 一致保证可复现再拷贝代码最后指定入口lambda_function.lambda_handler。部署的三种形态web service、streaming、batch分别在 04-deployment/web-service/、04-deployment/streaming/、04-deployment/batch/ 目录下有完整示例代码。4.6 模型监控Model monitoring分值标准0 分没有模型监控2 分基础监控能计算并报告指标4 分全面监控指标越限时能发送告警或触发条件式工作流如自动重训练、生成调试 dashboard、切换到另一个模型2 分到 4 分的差距在于闭环从算指标、看报表升级为越限 → 告警/触发后续动作。仓库 05-monitoring/ 提供了一个 Evidently Grafana 的监控栈参考其 docker-compose.yml 将 evidently 指标计算、Grafana、数据源与 dashboard 配置config/grafana_datasources.yaml、dashboards/data_drift.json编排为一套可一键拉起的服务evidently_metrics_calculation.py 演示了指标如何被计算并暴露。项目里若要拿满 4 分需要在该栈之上补一层阈值 → 动作的逻辑。4.7 可复现性Reproducibility分值标准0 分完全没有运行说明数据缺失2 分有部分说明但不完整或说明清晰完整、代码可跑但数据缺失4 分说明清晰、代码容易跑通且确实能跑所有依赖都指定了版本这一条对应工程上的最低要求README 里的运行步骤必须真实可执行依赖必须锁定版本对应到具体实现就是Pipfile.lock/requirements.txt带版本号 /conda.yaml等。4.8 最佳实践Best practices——检查项式加分检查项分值单元测试unit tests1 分集成测试integration test1 分使用了 linter 和/或代码格式化工具1 分有 Makefile1 分有 pre-commit hooks1 分有 CI/CD 流水线2 分这一整节恰好与课程模块 6 的教学内容一一对应仓库 06-best-practices/code/Makefile 就是一份可直接对照的满分参考把上述检查项全部串进了构建链test: pytest tests/ quality_checks: isort . black . pylint --recursivey . build: quality_checks test docker build -t ${LOCAL_IMAGE_NAME} . integration_test: build LOCAL_IMAGE_NAME${LOCAL_IMAGE_NAME} bash integraton-test/run.sh publish: build integration_test LOCAL_IMAGE_NAME${LOCAL_IMAGE_NAME} bash scripts/publish.sh setup: pipenv install --dev pre-commit install从源码结构看这条链路体现了一个典型工程约束build依赖quality_checks和testpublish又依赖build和integration_test——即先过 lint/格式化、再跑单元测试、构建镜像、跑集成测试最后才允许发布任何一环失败都阻断发布。项目 README 里可以引用这种Makefile 驱动的发布门禁来说明自己最佳实践的组织方式。配套测试代码见 06-best-practices/code/tests/model_test.py集成测试编排见 06-best-practices/code/integration-test/run.sh 与 docker-compose.yaml。五、仓库参考实现把评估标准映射到真实代码除上述 Makefile / Dockerfile 外仓库中还有几处与项目评分标准强相关的参考实现可以推断出满分项目的技术形态大致如下云 IaCCloud 4 分档06-best-practices/code/scripts/deploy_manual.sh 展示了部署脚本的完整形态——设置 region 与 Terraform 生成的 bucket/stream/lambda 名称、从实验跟踪产物中取最新RUN_ID、同步模型产物、最后用aws lambda update-function-configuration更新 Lambda 环境变量。注意脚本内多处NOT FOR PRODUCTION!注释它明确说明生产环境中 RUN_ID 一般应来自 MLflow/DVC 等实验跟踪工具这正是评估标准第 4.3 条与 IaC 部署之间的衔接点。对应的 Terraform 模块位于 06-best-practices/code/infrastructure/modules/ecr、kinesis、lambda、s3 四个子目录环境区分由 vars/prod.tfvars 与 vars/stg.tfvars 承载。CI/CD2 分档06-best-practices/README.md 的 Part B 描述了基于 GitHub Actions 的完整流水线思路——ci-tests.yml在 PR 到 develop 时触发环境搭建、单测、集成测试、Terraform plancd-deploy.yml在 push 到 develop 时触发Terraform apply、构建并推送镜像到 ECR、更新 Lambda 配置概念说明见 06-best-practices/docs.md。历史 cohort 参考cohorts/2023/07-project 与 cohorts/2022/07-project 目录保留了往届的 project README原文档建议浏览社区完成的真实项目Projects Gallery来学习他人如何选题、组织代码与呈现结果。六、同侪评审Peer Review机制项目评估采用同侪评审制规则明确写在文档中要为项目拿到分数必须评审 3 个同侪项目每完成一次评审评审者额外获得 3 个积分。文档特别指出这是向彼此学习的机会。结合 cohorts/2025/project.md 的说明如果未完成 3 个 peer 评审项目本身不能被视为完成cant be considered complete——即评审义务是项目通过的必要条件而不是可选项。七、提交建议新项目仓库与 README 质量原文档以 NOTE 形式给出了两条高相关性的提交建议建议为项目单独创建一个新的仓库不要塞进已有仓库并起一个有语义的标题例如 Car Price Prediction、Music Genre Classification同时在 README 里写足细节README 写得越完整越容易满足 Evaluation Criteria 中问题描述与可复现性两节的要求README 为空或细节极少可能按评分标准被扣分。这条建议对求职场景同样成立一个结构完整、README 详尽的独立项目仓库本身就是作品集展示。八、动手前的自查清单综合 07-project/README.md 的完整要求可以把项目规划归纳为一张对照表确保开写代码前每项都有明确方案评估维度目标分需要交付的东西仓库参考位置问题描述2独立仓库 详尽 READMEcohorts/2025/project.md云4云环境 Terraform或等价 IaC06-best-practices/code/infrastructure/实验跟踪 模型注册4训练时跟踪实验并注册模型03-orchestration/README.mdMLflow 容器化片段工作流编排4完全部署的编排工作流含参数化与 backfill03-orchestration/README.md模型部署4容器化的 batch / web / streaming 部署06-best-practices/code/Dockerfile、04-deployment/模型监控4指标越限 → 告警/条件式工作流05-monitoring/、05-monitoring/docker-compose.yml可复现性4清晰运行说明 锁定版本的依赖各模块 Pipfile / requirements.txt最佳实践8单测、集成测试、linter、Makefile、pre-commit、CI/CD06-best-practices/code/Makefile、06-best-practices/README.md同侪评审必做评审 3 个同侪项目cohorts/2025/project.md需要说明的前提与限制以上仓库参考代码均基于课程示例场景NYC taxi 行程时长预测项目本身不得复用该数据集参考代码中部署脚本带有明确的NOT FOR PRODUCTION!标记仅演示流程不能直接当作生产部署方案照搬。技术栈清单云、实验跟踪、编排、监控、CI/CD、IaC允许替换为等价工具但必须在项目文档中解释所选用工具的职责。【免费下载链接】mlops-zoomcampFree MLOps course from DataTalks.Club. Register here to get notified about the next cohort项目地址: https://gitcode.com/GitHub_Trending/ml/mlops-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考