先说明一下，我也是被项目逼着从传统的 CRUD 业务转过来接触 ML.NET 的，最初真的以为它就是写给 .NET 程序员的一套“玩具级”机器学习库，直到我用它做完一个多类分类的实际项目，才彻底改观。这篇文章不打算讲那些已经被写烂的概念，而是围绕我自己的真实踩坑经历来聊：为什么选它、多类分类最容易掉进去的两个陷阱、以及我梳理出来的三个必学技巧。如果你正准备在 .NET 生态里做文本分类、日志归类、商品类目预测这类任务，这篇文章应该能帮你少走不少弯路。
1. 先搞清楚ML.NET多类分类的定位和适用边界
1.1 多类分类和二分类的本质差异
很多从二分类入门的人会想当然地觉得，多类分类无非就是“多几个标签而已”。实际完全不是这么回事。二分类你只需要一个决策边界就能把空间切分成两块，但多类分类面对的是多个类别之间的相互干扰，标签之间可能存在重叠、混淆，甚至类别数量本身就不均衡。举个例子，日志分类任务里，“内存溢出”和“连接超时”这两种日志在文本特征上很可能高度相似，分类器需要学习的不是某一个阈值，而是多个类别在高维空间中的相对位置关系。
ML.NET 里处理多类分类的口径也比较特殊，它把标签统一转成 KeyType 类型，也就是给每个原始标签分配一个整数键。这个过程是不可逆的，所以你在预测阶段拿到的是整数键，必须再做一次映射才能还原成原始标签。这个设计本身是为了兼顾训练效率和内存占用，但如果你没意识到这点，很容易在结果解读上栽跟头，后面我会详细说。
1.2 为什么在 .NET 生态里优先考虑它
我先说一个比较现实的问题：如果你们公司技术栈是 Java 或 Python，那你大概率会用 scikit-learn 或者 XGBoost，没 ML.NET 什么事。但如果你们是典型的 .NET 团队，比如内部服务全是 C# 写的，用 ML.NET 的最大优势不是它的算法有多强，而是不用额外引入一套跨语言的模型调用链路。
我再展开一点。Python 方案训练好模型之后，要么你开一个 Flask/FastAPI 服务让 C# 去调 HTTP 接口，要么用 ONNX 把模型导出，再在 .NET 里用 OnnxRuntime 跑推理。这两条路都可行，但都引入了额外的部署节点和运维成本。ML.NET 呢？它从数据加载、特征处理、模型训练到模型持久化，全都在 System.ML 这个 NuGet 包里搞定，你的训练代码和推理代码可以放在同一个解决方案里，甚至部署的时候直接把模型文件和 ASP.NET Core 服务打成一个镜像就完事。这种“单一技术栈闭环”的体验，对于预算少、人手紧的小团队来说太重要了。
当然，它也有明显的劣势，比如生态不如 Python 丰富、最新的算法支持有滞后、社区资料相对少。所以我的建议是：如果项目特征工程比较复杂，比如要用到预训练语言模型做 embedding，那 ML.NET 不是最佳选择；但如果你的任务是基于结构化特征或文本 TF-IDF 特征的多类分类，ML.NET 完全能打。
1.3 我实际用到的典型场景
我做过的项目里，最适合 ML.NET 多类分类的场景大致有三类。第一类是工单自动分类，比如客服系统里根据用户提交的描述自动分派给对应技术组；第二类是日志错误归类，把线上服务出现的异常日志自动归到内存、网络、配置、代码等几个大类；第三类是电商领域的商品品类预测，根据商品标题和属性字段预测应该挂在哪个类目下。
这三类场景有个共同点：特征以文本和离散枚举为主，类别数量在 10 到 100 之间，数据量在几万条这个量级。ML.NET 内置的文本处理管道和 Maximum Entropy / OneVersusAll 等算法，在这个区间内表现相当稳定。如果你的类别数量到了上万级，或者数据量到千万级，那 ML.NET 可能就不太合适了，需要转向更重量级的分布式方案。
2. 必须聊透的那个“1个库”：核心组件和管道机制
2.1 MLContext 是所有操作的起点
ML.NET 的一切操作都始于MLContext，你可以把它理解成一个“机器学习上下文容器”。它负责管理训练器的实例化、数据加载、模型保存和预测引擎的创建。千万不要在代码里到处 new 一个MLContext，而是应该在整个训练过程中只创建一个实例，因为这个对象内部有缓存和随机数生成器的状态管理。
var context = new MLContext(seed: 42);那个 seed 参数值得单独说说。如果你希望在多次训练之间保持结果可复现，一定要固定 seed。我之前调试时没有设置 seed，结果同一个数据集每次训练出来的指标都不一样，还以为是代码写错了，后来才发现是随机种子的问题。设置 seed 之后，数据打乱、初始化权重、抽样这些环节全都是确定性的，对排查问题帮助很大。
2.2 IEstimator 和 ITransformer 的管道哲学
ML.NET 的 Pipeline 设计深受 scikit-learn 影响，核心思想是：不直接写一串手动的数据处理步骤，而是把所有变换和最终的学习器组装成一个IEstimator链，然后调用Fit方法一次性完成训练。
var pipeline = context.Transforms.Text.FeaturizeText("Features", "Text") .Append(context.Transforms.Conversion.MapValueToKey("Label")) .Append(context.MulticlassClassification.Trainers.SdcaMaximumEntropy()) .Append(context.Transforms.Conversion.MapKeyToValue("PredictedLabel"));这条管道里每一步都实现IEstimator，Append方法把它们串联起来。当你调用Fit后，整条管道返回一个ITransformer。这个ITransformer就是可以直接保存的模型对象。管道的美妙之处在于：训练时怎么处理数据，预测时就会自动执行同样的处理，不需要你手动去记住每个预处理步骤。
这里我特别想强调一个新手容易忽略的点：特征处理和标签转换这些步骤，一定要放进管道里，而不是在外部用 C# 代码手工完成后再丢进去。原因很简单，一旦你在外部手工处理，预测阶段很容易漏掉其中某一步，造成训练和服务时数据分布不一致，模型表现直接崩掉。
2.3 多类分类训练器到底该选谁
ML.NET 里内置了多个多类分类训练器，我用下来觉得最值得记的有这几个：
| 训练器 | 适用场景 | 我的实际感受 |
|---|---|---|
| SdcaMaximumEntropy | 文本分类、高维稀疏特征 | 训练快，内存占用低，默认情况下表现就很好，适合大多数场景 |
| LbfgsMaximumEntropy | 特征维度适中、需要更精细收敛 | 比 SDCA 慢一些，但在某些数据集上准确率略高，可以当作对照组 |
| OneVersusAll | 把任意二分类器扩展成多分类 | 配合AveragedPerceptron等二分类器用，支持自定义，灵活性高 |
| NaiveBayes | 特征独立性较强的场景 | 词频特征下有时出奇地好，但特征相关性强时别用 |
我个人最常用的还是SdcaMaximumEntropy，它默认开启了 L2 正则化，对高维稀疏的 TF-IDF 特征特别友好。你不需要手动做太多特征选择，它会自动抑制掉那些信息量低的维度。如果你发现收敛太慢或者精度差一点，可以尝试调大MaximumNumberOfIterations，默认值好像偏保守。
2.4 DataView 数据抽象是真正的主角
ML.NET 里几乎所有数据源都会被转换成IDataView，这是一种惰性求值、行列式结构的数据抽象。它跟DataTable最大的区别是：IDataView不会把全部数据加载进内存，而是按需迭代读取。这对大文件友好，但也带来一个副作用——你不能像操作DataTable那样去随机访问某一行。
一开始我确实很不习惯，老想着 Console.WriteLine 看看里面的数据，结果发现直接打印不出来。后来习惯了才意识到，你真的不需要关心具体某一行，你需要的是整体统计量，比如某列分布、缺失值数量等。ML.NET 提供了Preview方法可以查看前若干行数据，调试时很好用。
3. 第一个陷阱：标签的 KeyType 转换与预测值错位
3.1 问题现场：所有预测都缺少一个标签
我最早做日志分类项目时，训练数据里有 4 类日志：内存、网络、配置、代码。模型训练完成后，我用测试集做评估，发现除了“代码”类之外，其他几个类别的预测结果总是差一截。更诡异的是，有些日志明明在测试集里被标成了“网络”，模型偏偏给预测成“内存”。我当时第一反应是特征没处理好，结果调来调去，指标纹丝不动。
后来我把预测结果拉出来看，才发现所有预测结果都被映射成了比原始标签键小 1 的值。也就是说，ML.NET 的ValueToKey转换默认从 0 开始给标签排序，而我的 C# 代码里枚举值是从 1 开始的，我在评估的时候直接用枚举值去比对，自然全错位了。
3.2 根因剖析：KeyType 和黄赌毒没有关系，是整数键
这个问题的根源在于 ML.NET 的标签处理机制。当你调用MapValueToKey时，ML.NET 会把原始标签（字符串或数字）转换成一个KeyType，本质是uint整数键。这个键是算法能够直接消费的数值形式，但它的序号顺序是按照数据里首次出现的顺序确定的，而不是你 C# 枚举里定义的顺序。
再叠加一个要命的细节：多类分类训练器输出的PredictedLabel也是一个KeyType，同样需要反向映射回原始标签。如果你在管道的最后加了MapKeyToValue，输出就是原始字符串了；如果没加，拿到的就是整数键，你需要自己维护一张映射表。但在评估阶段，Evaluate方法内部使用的是键值，看到的是整数。
这就是陷阱的全貌：训练时标签是字符串，被隐式编码成键；评估时直接拿键和原始标签比；部署时又可能把键当成枚举值用。三层错位，每一层都很隐蔽。
3.3 解决方案：统一用字符串标签，并且始终在管道内完成映射
我的建议是两条。第一，在所有对外接口和评估代码里，始终使用字符串形式的标签，不要用枚举。也就是说，模型的输入数据里Label列是字符串，预测结果里的PredictedLabel也是字符串，中间所有的键转换都在管道内部完成。
第二，如果你出于性能考虑，确实希望模型的输入输出用整数标签，那就自己显式维护一张字典，把整数键和原始标签对应关系打印出来，写到日志或者配置文件中。训练完成后，把这张映射表一起序列化保存，部署时加载后统一使用。千万不要靠“枚举定义顺序”去猜。
我现在的标准代码长这样：
// 训练管道：字符串标签 -> 键 -> 训练 -> 键 -> 字符串 var pipeline = context.Transforms.Conversion.MapValueToKey("Label") .Append(context.Transforms.Text.FeaturizeText("Features", "Text")) .Append(context.MulticlassClassification.Trainers.SdcaMaximumEntropy()) .Append(context.Transforms.Conversion.MapKeyToValue("PredictedLabel")); var model = pipeline.Fit(trainingData);这样的好处是：训练数据和预测数据都以字符串标签存在，管道的最后一步已经帮你把训练器输出的键映射回字符串，你永远不需要在应用层跟整数键打交道。
3.4 另一个次生坑：未知标签导致训练异常
跟标签相关的还有一个隐藏问题，就是在预测阶段如果出现了一个训练时没见过的原始标签值，ValueToKey会直接抛异常。尤其是做文本分类时，用户输入五花八门，你无法保证预测数据的标签一定在训练集里出现过。解决方案是在预测之前加一层过滤，或者自己写一个CustomMapping，遇到未知值就映射为-1并标记为“未知类别”。
4. 第二个陷阱：类别不平衡时的评估指标失真
4.1 问题现场：整体准确率 90%，但两个类别完全不可用
有一次我在做工单自动分类，数据是从历史工单里导出的，一共 20 万条。其中“咨询”类占了 80%，“退款”类 15%，“投诉”类 5%。训练完之后看整体准确率 92%，我当时还挺高兴，觉得这模型可以直接上线了。
结果一做细粒度评估，发现问题大了。“投诉”类的召回率只有 18%，也就是说大部分真正投诉的工单都被模型分到了“咨询”类里。整体准确率是被大类带起来的，模型实际上等于在无脑预测“咨询”。因为即使全预测成大类，准确率也有 80%，这个基线放在那里，任何一点对大类的小幅偏斜都会让整体准确率看起来“过得去”。
4.2 为什么准确率会骗人
机器学习里有个概念叫“准确率悖论”，在多类分类场景里尤其明显。当你面对严重不均衡的数据时，准确率=分类正确的样本数/总样本数，这个指标会被样本量最大的类别主导。想象一个极端情况：1000 个样本里 990 个是 A 类，10 个是 B 类，你只要永远预测 A，准确率就是 99%。但模型实际没有任何分类能力。
所以多类分类里，必须同时看微观准确率（MicroAccuracy）和宏观准确率（MacroAccuracy）。MicroAccuracy 就是我们常说的整体准确率，MacroAccuracy 是先分别计算每个类别的准确率再取平均，它对小类别更敏感，能让“小类被忽视”的问题暴露得特别明显。如果这两者差距过大，基本可以断定模型在牺牲小类。
另外还有 Precision 和 Recall 的类别级矩阵，我习惯把每个类别的混淆矩阵打印出来，直接看哪个类被混淆到了哪个类里，定位问题非常高效。
4.3 解决思路一：用采样策略改变数据分布
最直接的办法就是让数据样本均衡。ML.NET 提供了一个简单的FilterByColumn和BootstrapSample等操作，不过我更推荐的做法是使用Context.Data.DatasetShape去检查每类的分布，然后手动拆分采样。
常用策略有三种。第一种是欠采样，把大类里的样本随机去掉一部分，让每个类别数量接近，缺点是会丢弃大量数据。第二种是过采样，对少数类做随机复制，缺点是容易过拟合。第三种是 SMOTE 之类的合成采样，在特征空间里插值生成新样本，ML.NET 没有内置这个算法，但你可以先用其他工具生成好样本再导出 csv 喂给 ML.NET。
我自己用的比较多的是过采样和欠采样的组合：先把最大的类别上限设置为第二大类的 2 倍左右，多余的大类样本丢弃，然后对小类做轻度过采样。这样既保留了足够数据，又没有让小类样本大量重复。
4.4 解决思路二：换评估指标和损失权重
光改数据分布还不够，更有效的做法是在模型层面给少数类更高的权重。ML.NET 的SdcaMaximumEntropy支持通过ExampleWeight列来调整单个样本的影响。你可以构造一列权重，让少数类的每条样本权重是多数类的 3 到 5 倍。这样即使数据不均衡，损失函数里少数类的梯度贡献也更大，模型会更努力地去学会区分它们。
var pipeline = context.Transforms.Concatenate("Features", "FeatA", "FeatB") .Append(context.Transforms.Conversion.MapValueToKey("Label")) .Append(context.MulticlassClassification.Trainers.SdcaMaximumEntropy( new SdcaMaximumEntropyMulticlassTrainer.Options { // 降低正则化强度，让模型有更多自由度拟合少数类 L2Regularization = 0.01f, MaximumNumberOfIterations = 200 }));如果项目对少数类的召回率要求很高，建议直接把评估指标切成 Micro/Macro Precision、Recall、F1 的加权版本，不要再盯着整体准确率看。准确率只能用来做粗筛，决策要基于类别级指标。
4.5 实操心得：先看混淆矩阵再谈调参
我强烈建议你在拿到一个基线模型之后，第一件事不是调参，而是把混淆矩阵打出来。这一步能帮你快速知道模型到底在混淆哪些类。比如我在工单分类里发现“投诉”和“咨询”混淆严重，后来仔细看了样本，发现确实有很多投诉工单的开头写着“咨询”，模型被措辞误导了。这个信息是单纯看准确率永远发现不了的。
打印混淆矩阵可以用Context.MulticlassClassification.Evaluate返回的ConfusionMatrix属性，直接遍历里面的Counts数组即可。不要嫌麻烦，这个时间花得非常值。
5. 技巧一：特征工程必须在 Pipeline 内完成
5.1 为什么有人训练完模型一预测就崩
我见过不少这样的案例：某同事在训练时把原始特征做了归一化，然后训练模型效果不错。部署的时候，他直接拿原始的未归一化数据喂给预测引擎，结果输出全乱套。这就是典型的特征处理“训练预测不一致”问题。
ML.NET 的管道机制本来就是设计用来规避这个问题的，很多人没用对，是因为他们把太多逻辑写在了 C# 代码里而不是管道里。比如用 LINQ 对数据做筛选、归一化、编码，然后再丢给IDataView。训练时这样做没问题，但预测时你面对的是全新数据，你还要重复写一遍完全一样的处理逻辑，漏掉一步都不行。正确做法是让管道成为唯一的特征处理入口。
5.2 把归一化和编码都声明进管道
举一个电商商品分类的例子。假设特征包含商品标题文本、价格、是否包邮三个字段，你可以这样写：
var pipeline = context.Transforms.Text.FeaturizeText("TitleFeatures", "Title") .Append(context.Transforms.Concatenate("NumericFeatures", "Price", "IsFreeShipping")) .Append(context.Transforms.NormalizeMinMax("NumericFeatures")) .Append(context.Transforms.Conversion.MapValueToKey("CategoryLabel")) .Append(context.Transforms.Concatenate("Features", "TitleFeatures", "NumericFeatures")) .Append(context.MulticlassClassification.Trainers.SdcaMaximumEntropy()) .Append(context.Transforms.Conversion.MapKeyToValue("PredictedLabel"));注意Concatenate并不直接生成最终的特征列，我是先把数值特征拼接成一列做归一化，再跟文本特征拼成总的Features。这是很关键的一步。数值特征如果不归一化而是跟高维稀疏的文本特征混在一起，很容易让数值特征在距离计算中占据不当的主导地位。
5.3 Pipeline 内做特征工程的三点好处
第一，训练和预测天然一致。你保存的是整个管道转换器，部署时输入原始数据，输出直接是预测结果，中间每一步由模型自己执行。第二，可以方便地做条件特征组合实验。你可以一条一条追加新的转换器，就能快速测试“加了价格特征有没有用”。第三，配合 AutoML 或网格搜索时，所有转换步骤都会自动回放，不会出现漏步骤。
还有一个小技巧，如果你有某些类别特征，比如商品的品牌、类目ID，可以用OneHotEncoding转成稀疏向量再接进特征列。用OneHotHashEncoding可以在品牌数量特别多时控制维度爆炸，这个在很多项目里都是救命的。
6. 技巧二：用 CrossValidate 而不是手动切分数据
6.1 手动切分数据的痛点
很多初学者都会自己写一个for循环，按 80/20 切数据，训练模型，再在测试集上评估一遍。这种做法的问题在于：单次切分的评估结果方差很大，可能这次切分让测试集恰好躲开了难样本，下次又正好撞上，结果对模型真实效果的判断非常不稳定。
尤其是样本不太多的时候，一次切分根本代表不了模型的泛化能力。交叉验证的思想是把数据切成 K 份，每次用其中 K-1 份训练，剩下 1 份验证，循环 K 次，取平均指标。ML.NET 内置了CrossValidate方法，你不需要自己写 for 循环。
6.2 CrossValidate 的用法和参数
代码如下：
var cvResults = context.MulticlassClassification.CrossValidate( trainingData, pipeline, numberOfFolds: 5, labelColumnName: "Label"); foreach (var result in cvResults) { Console.WriteLine($"Fold {result.FoldIndex}: MicroAcc={result.Metrics.MicroAccuracy:0.000}, MacroAcc={result.Metrics.MacroAccuracy:0.000}"); }CrossValidate会自动完成数据分折、逐折训练、逐折评估这些事，最后返回一个CrossValidationResult数组。里面每个元素包含Metrics对象和该折训练出的Model。你可以把每一折的模型存下来，取指标最好的一折作为最终候选。不过我通常不会直接拿某一折模型当最终模型，而是先通过交叉验证判断特征和算法选型，确定后再用全部数据训练最终模型。
6.3 解读交叉验证结果时的两个经验
第一，关注所有折的平均指标和标准差。如果不同折之间的指标波动特别大，说明模型对数据切分很敏感，或者数据本身有某种顺序效应，这时候要检查数据是否按时间排列导致时间泄漏。第二，交叉验证结果不能和最终全量训练模型的评估指标直接对比。全量训练用的数据更多，模型效果通常会更好，但交叉验证更能反映“没见过的新数据”上的表现。
我在实际项目中通常会用 5 折交叉验证选特征和训练器，然后再用这 5 折里效果最好的一折对应的超参数组合去全量训练。这样做既控制了过拟合风险，又有足够的数据来训练最终模型。
7. 技巧三：模型持久化与 PredictionEnginePool 的高效推理
7.1 保存和加载模型的正确姿势
模型训练好之后，一定要把整个ITransformer连同它的输入 Schema 一起保存。ML.NET 的标准做法是用MLContext.Model.Save和Load：
context.Model.Save(model, trainingData.Schema, "model.zip");var loadedModel = context.Model.Load("model.zip", out var inputSchema);这里有个我踩过的坑：Load出来的模型必须配合原始的MLContext实例使用。你不能在一个新的MLContext里直接拿旧的模型去创建预测引擎，虽然代码上不报错，但行为不可预期。稳妥的说法是，加载模型和创建预测引擎，请使用同一个上下文实例。
7.2 PredictionEngine 不是线程安全的
创建预测引擎的标准做法是这样：
var engine = context.Model.CreatePredictionEngine<InputData, OutputData>(loadedModel); var prediction = engine.Predict(new InputData { ... });PredictionEngine本质是ITransformer针对单条数据的封装，内部有缓存，效率很高，但它不是线程安全的。如果你在 ASP.NET Core 里直接用一个静态的PredictionEngine实例处理并发请求，一旦请求量上来就会出现随机报错或者预测结果错乱。
正确做法是用PredictionEnginePool，这是微软官方针对多线程场景提供的扩展：
services.AddPredictionEnginePool<InputData, OutputData>() .FromFile("model.zip");然后在控制器里注入PredictionEnginePool<InputData, OutputData>，每次调用Predict方法即可。这个池化方案会自动管理引擎的生命周期和线程分配，实测下来简单高效。
7.3 输入输出数据类的字段命名要和 Schema 完全一致
另一个高频报错是输入类的属性名跟训练数据的列名对不上。ML.NET 在创建预测引擎时会把 C# 类属性映射到 DataView 的列上，如果名字不一致，它会直接抛异常，而且异常信息有时候比较晦涩。
我的建议是始终把输入输出类设计得非常简单，属性名和训练数据的列名完全一致。比如：
public class LogInput { public string Text { get; set; } } public class LogOutput { public string PredictedLabel { get; set; } public float[] Score { get; set; } }7.4 高效推理的进阶技巧：批量评分
如果你的场景不是在线实时 API，而是离线批量处理，比如每天凌晨跑一批日志分类，那不要用PredictionEngine一条一条预测，而是直接调用ITransformer.Transform一次处理整个IDataView，充分利用列式计算的批处理优化。批量评分可以把吞吐量提升数倍。
IDataView predictions = loadedModel.Transform(batchData);处理完后再把结果写入 CSV 或数据库里。这一步看起来简单，但很多刚开始用 ML.NET 的人不知道可以这么做，白白浪费了性能。
8. 常见问题排查实录与速查
8.1 模型总是预测同一个类别
遇到这种问题，先检查类别分布是否严重不平衡，如果某个类别占比超过 90%，模型大概率会偷懒。其次检查特征是否太弱，比如你只用了长度作为唯一特征，那它根本没有区分能力。最后一个隐蔽原因是正则化太强，模型被过度约束，只能输出先验概率最大的类。对症下药就是：平衡采样、增加特征、降低正则化系数。
8.2 预测阶段报 Schema 不匹配
这个问题的提示通常长这样：The given column is not present in the IDataView或Mismatch in Schema。原因一般是输入数据的列名、类型和训练时不一致。排查思路：用Preview方法打印训练数据的列，和预测时的列做一一比对。特别注意字符串列和数值列的系统自动类型推断差异，比如 CSV 里明明是整数，ML.NET 有时候会推断成 float，导致不匹配。
8.3 训练过程异常缓慢
多类分类训练慢，最常见的原因是特征维度爆炸。文本特征加上 One-Hot 编码后维度可能到几十万，SdcaMaximumEntropy虽然对高维特征友好，但也不是没有上限。可以先用Transforms.Text.FeaturizeText的输出维度做日志，观察维度数量。如果过高，考虑启用OneHotHashEncoding或者用WordEmbedding代替 BoW 特征。另外可以把数据先加载到内存中然后用Cache缓存，减少每次迭代的磁盘 IO。
8.4 训练和评估代码速查表
| 操作 | 推荐API | 备注 |
|---|---|---|
| 加载数据 | context.Data.LoadFromTextFile | 支持 CSV、TSV |
| 特征组合 | Transforms.Concatenate | 最终特征列必须叫 Features |
| 归一化 | Transforms.NormalizeMinMax | 数值特征建议使用 |
| 标签转换 | Transforms.Conversion.MapValueToKey | 输入标签变 KeyType |
| 反转换 | Transforms.Conversion.MapKeyToValue | 输出 KeyType 变回字符串 |
| 交叉验证 | Context.MulticlassClassification.CrossValidate | 建议 5 折 |
| 模型保存 | Context.Model.Save | 同时保存 Schema |
| 推理池 | PredictionEnginePool | Web 场景注意线程安全 |
8.5 搜遍全网都找不到排错日志怎么办
ML.NET 有个比较反直觉的地方，就是它的部分报错日志默认是关掉的，或者说你根本没开日志通道。你可以在创建MLContext时就注册一个自定义日志回调：
var context = new MLContext(seed: 42); context.Log += (sender, e) => { if (e.Kind == MessageBoxKind.Warning || e.Kind == MessageBoxKind.Error) { Console.WriteLine($"[ML.NET] {e.Message}"); } };这样一来训练过程中那些不被对外暴露的警告信息会全部打出来。很多莫名其妙的性能下降和精度异常，其实在日志里都有线索。用这个办法排查问题，比反复试参数高效得多。
9. 最后再分享一点个人体会
从我最早对 ML.NET 的轻视，到后来用它在生产环境扛住每天几十万条工单数据，这个过程里的教训实在太多了。如果你现在正要开始一个多类分类项目，我最想让你记住的话是：别急着一上来就调参数，先保证管道正确、特征合理、评估指标到类别级别。固定好随机种子，把标签映射处理干净，用交叉验证建立基线，这三个基础稳了，后面的优化才有意义。
另外我真心建议你在动手前多花点时间把数据集梳理一下。ML.NET 的调试成本不低，问题出在数据上的概率远远大于出在算法上的概率。把样本看一遍、画一下类别分布、算一下特征缺失率，这 20 分钟的时间能帮你省下后面几十个小时的返工。好工具也怕坏数据，把基本功做扎实，多类分类这事其实没有想象中那么难。
