用 ML.NET 做文件内容分类，别碰 ONNX Runtime 手动推理
直接上结论：C# 里对文本文件做自动分类，优先用
ML.NET的
TextLoader+
SdcaMaximumEntropyBinaryClassifier（或多类）流程，而不是自己加载 ONNX 模型调
InferenceSession。前者封装了文本清洗、向量化、训练/预测全链路；后者要手动处理分词、停用词、TF-IDF 或 BERT tokenization，错一个环节就
Input shape mismatch或
NaN loss。
常见错误现象：
InvalidOperationException: Schema mismatch—— 多半是训练时用
LoadFromTextFile读 CSV，但没设
hasHeader: true，或列名和
TextLoader的
Column属性不一致；
NullReferenceException在
model.Predict()后出现，通常是输入
string为
null或空格串，
ML.NET默认不校验。 训练数据必须是结构化文本：每行一个样本，至少两列 ——
Label（字符串或数字）和
Text（原始内容），CSV 或 TSV 都行
TextLoader的
separatorChar要和实际文件一致，Windows 记事本保存的 CSV 默认是
,，但 Excel 有时导出带
;避免在
TextTransform阶段用自定义正则清理——
ML.NET内置的
FeaturizeText已含小写、去标点、n-gram 提取，额外清理反而破坏特征对齐
Label 列必须是 string 类型，别用 int 当类别名
ML.NET分类器（如
SdcaMaximumEntropyMultiClassifier）要求
Label字段是
string，哪怕你只有 “invoice”、“contract”、“email” 三类。如果训练数据里用的是
1、
2、
3，模型会当成回归任务，预测结果变成浮点数，且
Predict()返回的
PredictedLabel是乱码或空值。
使用场景：从邮件附件中识别合同 vs 报价单，标签列不能是数据库里的
category_id整数，得映射成可读字符串；OCR 后的 PDF 文本分类也同理，别把 “invoice” 存成
0再喂给模型。 读取 CSV 时，用
.LoadFromTextFile<myinput>(path, hasHeader: true)</myinput>，其中
MyInput.Label声明为
string如果原始数据只有数字 ID，训练前加一步转换：
data = data.Select(x => new MyInput { Text = x.Text, Label = IdToNameMap[x.LabelId] })
模型保存后，Predict()输出的
PredictedLabel是
string，可直接用于业务分支判断，不用再查表
小样本下优先用 SdcaMaximumEntropy，别硬上 FastTree
文件内容分类通常样本少（几百到几千份）、特征稀疏（关键词分散），
FastTreeBinaryClassifier容易过拟合，验证集准确率虚高，上线后一跑真实文件就崩。而
SdcaMaximumEntropy（逻辑回归变种）对文本特征更鲁棒，训练快，内存占用低，适合中小项目快速落地。
性能影响：1000 条训练样本下，
SdcaMaximumEntropyMultiClassifier训练耗时约 800ms（i7-10875H），
FastTree要 3.2s 且 AUC 低 0.12；兼容性上，
Sdca支持 .NET 6+，
FastTree在 ARM64 上有 JIT 问题，某些 Win11 设备会抛
PlatformNotSupportedException。 多分类用
SdcaMaximumEntropyMultiClassifier，二分类用
SdcaMaximumEntropyBinaryClassifier，别混用
NumberOfThreads设为
Environment.ProcessorCount - 1，避免训练时卡死 UI 线程 如果必须用树模型（比如已有特征工程 pipeline），改用
LightGbmMultiClassifier，它比
FastTree更稳，但需额外引用
Microsoft.ML.LightGBM
预测时别传整个文件路径，只传文件内容字符串
模型输入是纯文本，不是文件路径。常见错误是写
var prediction = model.Predict(new MyInput { Text = @"C:\docs\invoice.pdf", Label = "" }); —— 这样模型学的其实是路径规律（比如 “invoice.pdf” 里有 “invoice” 字符串），不是内容语义。真正该做的是先读取文件内容：File.ReadAllText(path)，再清理换行和控制字符，最后喂给
Predict()。
容易踩的坑：
ReadAllText默认用 UTF-8，但老系统导出的文件可能是 GB2312 或 ANSI，不指定编码会乱码，导致关键词匹配失败；PDF 或 DOCX 文件不能直接读，必须先用
iTextSharp或
DocX提取文本，否则传进去的是二进制垃圾。 文本预处理只要两步：
text.Replace("\r\n", "\n").Replace("\t", " ").Trim()，别加复杂正则
PDF 提取推荐 QuestPDF（轻量）或
PDFsharp（稳定），避免用
Spire.PDF（免费版有水印且线程不安全） 如果文件超大（>10MB），截断前 5000 字符即可，
ML.NET的
FeaturizeText默认只取前 10k n-gram，多余部分无意义
最常被忽略的一点：训练和预测时的文本清洗逻辑必须完全一致。哪怕只是预测时多 trim 了一次空格，特征哈希值就变了，模型输出就不可信。
