Millwright — 在 Rust 中实验端到端机器学习框架 [P]

我一直在开发一个名为 Millwright 的开源项目，旨在探索在 Rust 中端到端机器学习工作流可能的样子。https://millwright-rs.dev/ 这个项目始于我在 Rust 中学习和构建 ML 工具时。我不断发现功能强大的独立库，但它们之间也存在缺口。训练模型很少是问题，围绕它的构建工作流——预处理、模型选择、评估、可解释性、部署和监控——通常意味着集成多个不相关的 crate 和数据表示。我最初开始实现一些缺失的部分作为较小的独立 crate。最终，我意识到我对集成问题本身更感兴趣。这成为了 Millwright。当前的想法是覆盖经典的 ML 生命周期：摄取 → 探索 → 预处理 → 选择 → 拟合 → 评估 → 解释 → 导出 → 服务 → 监控，而不试图重新实现每个 ML 算法。相反，Millwright 在现有 Rust 库上提供一个通用抽象层，并使用适配器支持不同的 ML 后端。我正在实验的一个架构决策是让框架拥有一个小型的二维数据边界（Frame），而不是在整个 API 中暴露特定后端的 ndarray/dataframe 表示。这允许不同库支持的模型和组件参与同一个管道，代价是在后端边界进行转换。该项目目前包括的工作涉及：预处理和可组合管道、交叉验证和超参数优化、多个 ML 后端、集成、回归诊断、基于 SHAP 的可解释性、ONNX 导出、模型服务和注册表、漂移监控、时间序列工作流、增量学习、AutoML。还有 Python 绑定。我构建这个项目并不是基于 Rust 应该取代 Python 用于 ML 的假设。Python 的生态系统要成熟得多，仅仅用另一种语言重新创建 scikit-learn 几乎没有价值。我发现更有趣的问题是：Rust 能否在训练、推理和生产 ML 之间提供一个有用的通用执行层，同时仍然与现有的 Python/ONNX 生态系统互操作？我宁愿在太多决策变得难以更改之前挑战架构。我特别希望从从事 ML 系统工作的人那里得到想法：你认为 Rust 在经典 ML 生命周期中能真正增加价值的地方在哪里？相反，你认为这个架构的哪些部分应该保持独立，而不是统一在一个框架之后？我还对真实的工作流感兴趣，这些工作流可以作为有用的测试。如果在 sklearn 中有简单的事情，你认为这会暴露这种方法的弱点，我愿意尝试重现它。项目/文档：https://millwright-rs.dev/ 源代码：https://github.com/mi7plus/millwright