ML.NET 实战解析：从数据加载到模型部署的完整流程
1. 为什么选择ML.NET？
如果你是一名.NET开发者，想要在自己的应用中快速集成机器学习能力，ML.NET可能是最顺手的工具。我最早接触ML.NET是在一个电商价格预测项目中，当时团队需要在两周内完成从数据清洗到模型上线的全流程。用Python生态虽然资源丰富，但和现有.NET系统集成成本太高。ML.NET让我们直接用熟悉的C#就完成了所有工作，连运维同事都能轻松看懂代码。
ML.NET最大的优势在于无缝融入.NET生态。你不需要为了机器学习额外搭建Python环境，所有操作都能在Visual Studio里完成。框架自带的AutoML功能更是让我印象深刻——只需要定义输入输出，它就能自动尝试多种算法并给出最佳模型。有次我临时需要处理用户评论情感分析，从零开始到获得可用模型只用了不到3小时。
2. 数据准备实战技巧
2.1 数据加载的多种姿势
实际项目中数据源往往比CSV复杂得多。最近帮某零售客户做库存预测时，我们需要同时处理SQL Server里的销售记录和Excel里的促销计划。ML.NET的DataView系统完美解决了这个问题：
// 从SQL加载数据 var sqlData = mlContext.Data.LoadFromSqlServer<SalesRecord>( connectionString, "SELECT * FROM Sales WHERE Date > @cutoff", parameters: new[] { new SqlParameter("@cutoff", DateTime.Now.AddMonths(-6)) }); // 从Excel加载数据 using var excelData = new ExcelPackage(new FileInfo("promotions.xlsx")); var promoData = mlContext.Data.LoadFromEnumerable( excelData.Workbook.Worksheets[0].ConvertSheetToObjects<Promotion>());踩坑提醒：混合不同数据源时一定要注意时间字段的时区统一。有次我们凌晨3点收到报警，发现预测结果突然异常，最后发现是促销数据用的UTC时间而销售记录用的本地时间。
2.2 数据清洗必备三板斧
真实数据永远比教程里的脏得多。建议在构建管道时优先加入这三个转换器：
var pipeline = mlContext.Transforms .ReplaceMissingValues("Price", replacementMode: MissingValueReplacingEstimator.ReplacementMode.Mean) // 处理缺失值 .Append(mlContext.Transforms.NormalizeMinMax("Price")) // 归一化数值 .Append(mlContext.Transforms.Text.FeaturizeText("CleanComment", "UserComment")); // 文本特征化特别提醒处理文本字段时，ML.NET 2.0新增的TextFeaturizer比旧方案快3倍以上。上周处理20万条用户反馈时，原来需要2分钟的特征工程现在40秒就能完成。
3. 模型训练与调优
3.1 算法选择指南
ML.NET提供的算法可能没Python生态丰富，但覆盖了80%的常见场景。这张表是我整理的快速选型参考：
| 问题类型 | 首选算法 | 适用场景 | 训练速度 |
|---|---|---|---|
| 二分类 | LightGbm | 特征维度高、需要高精度 | ★★★★ |
| 多分类 | SdcaMaximumEntropy | 样本量中等（<10万） | ★★★☆ |
| 回归预测 | FastTree | 非线性关系明显的数据 | ★★★☆ |
| 推荐系统 | MatrixFactorization | 用户-物品交互数据 | ★★☆☆ |
实测经验：LightGbm在电商场景下经常比FastTree表现更好。上个月我们A/B测试了两个算法，在点击率预测任务中LightGbm的AUC高出0.03，但训练时间只多了15%。
3.2 超参数调优实战
ML.NET的AutoML虽然方便，但手动调参往往能获得更好效果。这是我的调参模板：
var options = new LightGbmBinaryTrainer.Options { NumberOfLeaves = 31, // 典型值范围20-100 MinimumExampleCountPerLeaf = 20, // 防止过拟合 LearningRate = 0.1, // 常用0.05-0.3 NumberOfIterations = 100 // 迭代次数 }; var pipeline = mlContext.Transforms .Concatenate("Features", featureColumns) .Append(mlContext.BinaryClassification.Trainers.LightGbm(options));调参时建议先用小规模数据快速验证方向。有次我花了6小时在完整数据集上调参，最后发现最优参数组合其实在10%数据上就能确定。
4. 模型部署与监控
4.1 模型打包最佳实践
ML.NET 1.7开始支持的ONNX格式极大简化了部署流程。这是我常用的导出代码：
// 训练完成后保存模型 mlContext.Model.Save(model, trainTestSplit.TrainSet.Schema, "model.zip"); // 转换为ONNX格式 using var stream = File.Create("model.onnx"); mlContext.Model.ConvertToOnnx(model, trainTestSplit.TrainSet, stream);部署技巧：对于Web应用，建议将模型加载放在Application_Start中。最近优化一个ASP.NET应用时，把模型加载从每次请求改为全局单例，QPS直接从120提升到350+。
4.2 生产环境监控方案
模型上线只是开始，我们团队吃过没监控的亏。现在标准做法是在预测API里加入这样的监控逻辑：
public class PredictionService { private readonly PredictionEnginePool<ModelInput, ModelOutput> _engine; private readonly ILogger _logger; public PredictionService(PredictionEnginePool<ModelInput, ModelOutput> engine, ILogger logger) { _engine = engine; _logger = logger; } public ModelOutput Predict(ModelInput input) { try { var prediction = _engine.Predict(input); _logger.LogInformation($"Prediction success: {JsonSerializer.Serialize(prediction)}"); return prediction; } catch (Exception ex) { _logger.LogError(ex, $"Prediction failed for input: {JsonSerializer.Serialize(input)}"); throw; } } }关键要监控三方面：预测耗时、输入数据分布变化（可以用Prometheus记录）、异常预测结果。上季度我们就是通过监控发现某商品价格预测出现系统性偏差，及时排查出是原料价格字段采集出了问题。