为何推荐在.py文件而非Jupyter Notebook中使用MLflow？使用会有隐患吗？

• 可重复性难以保证：Jupyter Notebook的单元格支持随意调整执行顺序，很容易出现先跑训练、再回头改预处理代码重跑的情况，MLflow记录的参数、日志和实际执行的逻辑完全不匹配，后续根本没法复现当时的训练流程。
• 版本控制太麻烦：.ipynb文件是JSON格式，包含大量输出、格式信息，用Git做版本控制时，diff对比会一团乱，很难追踪MLflow相关代码的变更；而.py是纯文本，版本差异一目了然，团队协作和代码迭代都更顺畅。
• 生产部署门槛高：MLflow的模型打包、批量推理、调度运行等功能，天生更适配脚本化的.py文件。用Notebook的话，部署到生产环境要么得手动导出成脚本（容易漏逻辑），要么直接依赖Jupyter环境跑，稳定性和效率都远不如执行.py脚本。
• 实验追踪易混乱：Notebook里重复执行同一个单元格，MLflow会重复创建实验运行（run），导致日志里堆满冗余条目，没法快速区分有效实验和测试性的重复运行。而且单元格输出会和MLflow日志混在一起，整理分析实验结果很费劲。

• 实验记录杂乱无章：单元格乱序、重复执行会让MLflow的实验记录里充满无效或错误的run，后期筛选、对比实验结果时得花大量时间清理。
• 复现实验基本无望：别人拿到你的Notebook按顺序执行，结果很可能和你不一样——因为你实际运行时的单元格顺序和Notebook显示的顺序不一致，MLflow记录的参数对应的代码逻辑早就变了。
• 部署环节容易踩坑：要把Notebook里训练的模型通过MLflow部署成服务，必须先把Notebook转成脚本，这个过程很容易遗漏单元格代码，或者处理不好依赖环境，导致部署失败。
• 团队协作效率低下：Notebook的版本冲突比.py文件难解决得多，MLflow的配置、代码变更没法清晰沟通，很容易出现团队成员的实验记录不一致的情况。

内容的提问来源于stack exchange，提问作者Laura