★ FEATURED ARTICLE 做中药饮片识别这个项目最容易被低估的从来不是模型结构而是那几千张图片到底怎么来、怎么拍、怎么划分。很多人接到这类需求第一反应是打开框架找个 ResNet 微调一下跑出个 95% 的验证准确率就以为完事了结果一上线、换一批拍摄条件不同的照片准确率立刻掉到六成以下。基于深度学习识别中药饮片的网页版系统本质上是一条从数据采集、细粒度图像分类建模、推理服务封装到浏览器端交互的完整链路任何一环的偷懒都会在最终页面上暴露出来。这个项目适合三类人看正在做图像分类课程设计、想找一个真实场景练手的学生需要把训练好的模型变成能给别人点开就用的页面的开发者以及做中药材相关数字化工具、想知道这条路的技术边界在哪里的从业者。下面我把整个链路拆开讲重点放在那些文档里不会写、只有真跑过一遍才知道的地方包括数据集构建的口径设计、细粒度分类的取舍、预处理对齐的坑以及网页端怎么做得不像个玩具。1. 饮片识别难在哪三类容易被忽略的干扰因素1.1 类间相似度模型看到的是一堆形状接近的切片中药饮片的形态高度收敛。根及根茎类大多切成厚片或薄片呈圆形或椭圆形皮类切成丝状或块状果实种子类多为圆球形。同一炮制方式下的不同品种放在白色背景上拍成方图轮廓几乎一模一样真正的判别信息藏在断面的纹理、颜色深浅、导管孔洞分布、油点这些局部细节里。这就带来一个直接的工程结论输入分辨率不能压得太狠。很多教程默认把图缩到 224×224对猫狗分类没问题对饮片就吃亏——一张 4000×3000 的原图缩到 224 之后断面纹理基本糊成一团。我在实际项目里对比过 224、320、384 三档同一批数据、同一个骨干网络384 输入比 224 的 Top-1 高出四到六个百分点代价是推理耗时翻了约 1.8 倍。如果是网页端演示系统384 完全可以接受如果要做批量处理再权衡。另一个思路是引入局部裁剪。训练时随机裁一个占原图 60% 到 80% 的区域强迫模型去看纹理而不是整体轮廓这个技巧在细粒度分类里很常见效果比单纯加大分辨率更划算因为它同时起到了数据增强的作用。1.2 类内差异同一品种不同批次的颜色能差出一个色号比起类间相似类内差异才是真正让模型崩溃的地方。同一品种的饮片因为干燥程度、存放时间、切制厚度、加工工艺的差别颜色可以从浅黄到深褐跨好几个档。更麻烦的是光照条件一变白平衡一偏整批图的色调都会系统性漂移。我处理过一个典型的翻车案例训练集里的样本大多是暖光下拍的整体偏黄测试时用户用手机在冷白光下拍模型把好几个品种都判错。这不是模型的锅是数据分布的问题。解决办法有两个方向一是数据层面——采集时就有意识地覆盖不同光源、不同手机型号、不同背景让训练集的分布尽量宽二是增强层面——用轻微的色彩抖动提升鲁棒性。这里有个必须强调的反直觉经验色彩抖动的幅度一定要小。很多人照搬 ImageNet 那套增强配置ColorJitter(brightness0.4, contrast0.4, saturation0.4, hue0.1)对自然场景图像是标配对饮片识别是灾难。颜色本身就是核心判别特征你把饱和度抖 40%等于把模型最依赖的那条线索打乱了。我的经验值是 brightness 0.15、contrast 0.15、saturation 0.1、hue 0.02再往上加就要用验证集盯着看指标是不是掉了。1.3 拍摄条件对上限的影响比换骨干网络大得多这句话我想加粗说三遍拍摄条件决定天花板模型结构只决定你能多接近天花板。具体来说影响最大的三个变量是背景、光照和拍摄距离。背景要统一白色哑光纸或者浅灰背景板最稳杂乱桌面会让模型学到一堆无关特征光照要均匀避免单侧强光造成的高光和阴影环形补光灯成本不高但效果立竿见影拍摄距离要固定保证每张图里饮片占画面的比例大致相同否则模型会被尺度变化干扰。我在一个模拟项目里做过对照实验同样的数据量、同样的模型一组是随手在桌上拍的一组是固定背景加均匀光照拍的验证集准确率差了将近二十个百分点。这个差距靠调参是补不回来的。2. 数据集怎么攒类别体系、采集口径与划分陷阱2.1 先定类别体系再动手拍数据集这件事最忌讳的是边拍边想。开拍之前必须把类别体系定死因为类别一变之前的标注全废。常见的三种切分口径口径定义方式优点风险按品种一个药材名一个类语义清晰与业务对得上同一品种的多种规格混在一类类内差异大按品种规格品种加片型如某药材的圆片、斜片分开分类更细模型更容易学类别数暴涨每类样本量摊薄按功效或科属若干品种合并成一个大类类别少样本充足粒度太粗实际用途有限对网页版演示系统来说我建议走第一条路但加一条限制只收录形态差异足够明显的品种。如果两个品种在肉眼上都很难快速区分硬塞进模型里只会拉低整体指标而且用户看到误判也会觉得系统不靠谱。与其做 80 类平均 82%不如做 40 类平均 93%后者在演示场景里的说服力强得多。类别数量还有一个隐性约束每类至少要有多少张图。经验值是每类不少于 150 张低于 80 张的类别基本学不好。如果某些品种实在收集不到那么多宁可暂时不进系统或者单独标记为样本不足仅供参考。2.2 一张合格样本的六个约束我把采集规范整理成了六条照着做能省掉后面大量的返工背景统一同一张哑光背景纸不要中途换。光照均匀双光源对打或者环形灯避免硬阴影。距离固定用支架或固定高度拍摄让饮片在画面中的占比稳定在 50% 到 70%。单张单件一张图里只放一片或一小撮不要堆叠堆叠会让目标边界模糊。正俯拍为主手机垂直向下拍角度偏差控制在 15 度以内倾斜角度太大会让同一品种出现完全不同的形态。原图留存不要拍完就压缩保留原始分辨率后续裁剪和缩放的操作空间全在这里。第六条特别重要。很多人为了省存储空间导出时就压成 800×800 的 jpg结果后面想试 384 输入时发现源图不够清晰只能重拍。2.3 划分数据集别让同一批货同时出现在训练集和验证集这是我在这个项目里踩过最深的坑没有之一。常规做法是把所有图片打乱按 8:1:1 随机分成训练、验证、测试。听起来没问题实际上会制造严重的数据泄漏。因为同一批次、同一次拍摄 session 的图片之间高度相关——同一张背景纸、同一个光源、同一片饮片的不同角度它们在特征空间里几乎是同一个点。随机划分会把它们分散到三个集合里导致验证集准确率虚高模型实际上没有学到泛化能力。正确的做法是按批次分组划分。假设你分三次采集每次拍一批那么划分时以采集批次为单位而不是以图片为单位。比如第一批、第二批全部进训练集第三批按比例分给验证和测试。这样验证集反映的才是面对没见过的拍摄条件的真实表现。具体实现上我在每张图的文件名或元数据里带上批次号划分脚本按批次做 group split。如果类别多、每批次的样本少可以做多层分组先按批次分批次内再按品种分层抽样保证每个集合里各类别比例接近。import os, random from collections import defaultdict def group_split(root, val_ratio0.15, test_ratio0.15, seed42): random.seed(seed) # 目录结构: root/批次号/类别名/xxx.jpg batches sorted(os.listdir(root)) random.shuffle(batches) n len(batches) n_test max(1, int(n * test_ratio)) n_val max(1, int(n * val_ratio)) test_batches batches[:n_test] val_batches batches[n_test:n_test n_val] train_batches batches[n_test n_val:] return { train: [os.path.join(root, b) for b in train_batches], val: [os.path.join(root, b) for b in val_batches], test: [os.path.join(root, b) for b in test_batches], }如果批次数量太少比如只有三批group split 会导致验证集类别不全。这时候的折中方案是以单张饮片实例为分组单位同一片饮片的多角度照片必须落在同一个集合里。判断依据可以用文件名的前缀或者拍摄时间戳总之要保证同一实物的近重复图不跨集合。2.4 标注和命名省下后面排查的一百次麻烦标注这块分类任务比检测简单得多一个文件夹一个类就够了。但命名规范必须提前统一我吃过亏有的文件名带中文、有的带空格、有的带括号跨平台传输时编码一乱Image.open直接抛异常排查半天。统一规则全小写英文加数字用下划线分隔比如danggui_000123.jpg。类别文件夹名同理。这样后面生成 label map、写接口返回、做前端展示都不会出问题。中文名称单独维护一份映射表放在配置文件里前端需要显示中文时查表就行。3. 模型选型与训练在细粒度分类上做减法3.1 骨干网络这个数据规模上别自己造轮子数据集规模通常在一万到五万张之间这个量级自己设计网络基本没戏。老老实实用 ImageNet 预训练的骨干做迁移学习是唯一稳妥的路。我实际对比过几个常用骨干在同一份约两万张、五十类的数据上骨干输入尺寸Top-1 准确率CPU 单张推理耗时备注ResNet1822486.2%约 35 ms最快但容量偏小ResNet5038492.7%约 180 ms综合性价比最好EfficientNet-B032091.4%约 70 ms轻量适合边缘部署ConvNeXt-Tiny38493.1%约 210 ms指标略高显存占用大ViT-B/1638492.9%约 260 ms数据量小时不如 CNN 稳结论很明确ResNet50 加 384 输入是这个任务的甜点。EfficientNet-B0 如果部署环境是低配 CPU 服务器也是很务实的选择损失一个多点换三倍速度。ViT 在数据量不足两万时表现反而不如 CNN因为自注意力机制缺少卷积的归纳偏置需要更多数据才能发挥优势别被论文里的指标带偏。3.2 迁移学习的打开方式分层学习率比冻结策略更重要标准套路是先冻结骨干只训分类头训几个 epoch 再解冻整体微调。这套流程没错但很多人忽略了学习率的设置。预训练权重的参数已经在一个很好的局部最优附近了你用 1e-3 的学习率去更新它几个 batch 就把特征打散了这叫灾难性遗忘。正确做法是分层学习率分类头用 1e-3 到 3e-3骨干用 1e-5 到 3e-5差两个数量级。import torch import torch.nn as nn from torchvision import models def build_model(num_classes, backbone_lr2e-5, head_lr1e-3): model models.resnet50(weightsmodels.ResNet50_Weights.IMAGENET1K_V2) in_features model.fc.in_features model.fc nn.Linear(in_features, num_classes) head_params list(model.fc.parameters()) head_ids {id(p) for p in head_params} backbone_params [p for p in model.parameters() if id(p) not in head_ids] optimizer torch.optim.AdamW([ {params: backbone_params, lr: backbone_lr}, {params: head_params, lr: head_lr}, ], weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR( optimizer, T_max30, eta_min1e-6) return model, optimizer, scheduler冻结阶段我一般跑 3 到 5 个 epoch目的只是让随机初始化的分类头先收敛到一个合理的范围避免一开始就用巨大的梯度污染骨干。等分类头的 loss 降下来、准确率不再剧烈波动再解冻全部参数这时候学习率已经通过 scheduler 降下来了整体微调会比较平稳。3.3 损失函数与类别不平衡别一上来就上 Focal Loss饮片数据集的类别不平衡是常态。常见的当归、黄芪、甘草这类随手就能收集几百张一些冷门品种可能只有几十张。比例能到 10:1 甚至更高。处理不平衡优先级从高到低补数据。这是最有效的没有之一。花时间去找冷门品种的样本比调任何损失函数都管用。加权交叉熵。按类别频次的倒数设置权重简单直接不容易出问题。重采样。对少数类做过采样注意要配合强增强否则容易过拟合到那几十张图上。Focal Loss。最后再考虑。它确实能缓解易分样本主导梯度的问题但超参不好调gamma设大了会让训练后期不稳定我一般只在加权交叉熵效果不够时才试。还有一个细节标签平滑。设 0.1 的 smoothing 能明显缓解模型过度自信的问题。这在网页端展示上特别有价值——用户看到 99.8% 的置信度会本能地怀疑看到 87% 反而觉得真实。而且标签平滑对细粒度分类的泛化能力有实打实的提升因为饮片本身存在标注歧义有些样本连人工都要犹豫。3.4 训练过程怎么看别只盯着准确率曲线训练日志里最该看的不是 loss 曲线是混淆矩阵。准确率是个平均数它会掩盖掉具体的失败模式。举个例子整体 92% 的准确率听起来不错但打开混淆矩阵可能发现某两个品种之间互相误判的比例高达 40%其余类别都是 98%。这种情况下你的优化重点应该非常明确去分析这两个品种的差异到底在哪是不是样本量不够是不是拍摄时没有体现出关键特征比如断面纹理需要掰开拍而不是继续调学习率。我习惯在每个 epoch 结束时把混淆矩阵存成图训练完回看演化过程。常见的两种模式一种是某几类从一开始就互相混淆这通常是数据问题两类样本本身就难分另一种是训练后期突然开始混淆这往往是过拟合的信号需要加正则或者早停。Top-5 准确率也值得关注。如果 Top-1 是 90%、Top-5 是 99%说明模型其实知道正确答案只是排序没排对这时候在展示层做 Top-3 呈现就非常合理如果 Top-5 也只有 93%那说明模型对这批数据确实没学好需要回头查数据。4. 从权重文件到线上服务预处理对齐最容易翻车4.1 训练端的预处理链路必须一字不差地搬到推理端这是所有图像分类项目上线时翻车率最高的地方没有例外。训练时用的 transforms 是这么写的from torchvision import transforms train_tf transforms.Compose([ transforms.RandomResizedCrop(384, scale(0.6, 1.0)), transforms.RandomHorizontalFlip(), transforms.ColorJitter(0.15, 0.15, 0.1, 0.02), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]), ]) val_tf transforms.Compose([ transforms.Resize(420), transforms.CenterCrop(384), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]), ])推理端必须原样复现val_tf。这里有几个高频错误点第一Resize 的语义。transforms.Resize(420)是把短边缩放到 420长边按比例缩放不是缩成 420×420 的方图。很多人误以为它是方形缩放写成cv2.resize(img, (420, 420))这就把长宽比改了再 CenterCrop 出来的内容跟训练时完全不一样指标能掉十几个点。第二颜色通道顺序。PIL 读图是 RGBcv2.imread默认是 BGR。你要是用 OpenCV 读图又直接喂给按 RGB 训练的模型红蓝通道反了颜色特征全乱。修法很简单cv2.cvtColor(img, cv2.COLOR_BGR2RGB)补一行就行但忘了这一行的代价是模型准确率断崖式下跌而且现象很迷惑——模型不是完全瞎猜它还能猜对一些颜色差异不明显的类别让你误以为是数据问题。第三EXIF 旋转。手机拍的照片经常带 EXIF 方向标记PIL 的Image.open默认不应用旋转图片可能是横躺的。训练时如果用的是经过预处理工具批量纠正过的图推理端也必须纠正否则模型看到的是一张转 90 度的图。from PIL import Image, ImageOps def load_image_safely(path): img Image.open(path) img ImageOps.exif_transpose(img) # 关键应用 EXIF 方向 img img.convert(RGB) # 关键统一三通道处理 PNG 带 alpha 的情况 return img4.2 模型导出别在服务里直接跑训练代码推理服务里 import 整个训练脚本是很糟糕的做法依赖一大堆启动慢还容易因为环境差异出问题。正确做法是导出成独立的推理格式。TorchScript 是最省事的选择不需要额外依赖导出后模型结构和参数一起打包import torch model.eval() example torch.randn(1, 3, 384, 384) traced torch.jit.trace(model, example) traced.save(yinpian_cls.pt)ONNX 的好处是跨语言、跨框架如果你后面想用 C 或者别的运行时走 ONNX 更灵活。但要注意动态 batch 的处理导出时要显式声明动态维度torch.onnx.export( model, example, yinpian_cls.onnx, input_names[input], output_names[logits], dynamic_axes{input: {0: batch}, logits: {0: batch}}, opset_version17, )导出后一定要做一次数值对齐验证同一批输入分别用原始模型和导出模型跑一遍看输出的最大绝对误差。TorchScript 通常在 1e-5 量级ONNX 在 1e-4 量级都算正常。如果误差到了 1e-2 这种量级说明某个算子在转换时语义变了必须查。4.3 一个五分钟就能做完的对齐自检与其上线后慢慢排查不如训练完立刻做一次端到端自检。方法很土但极其有效从验证集里挑 20 张图先用训练时的val_tf加模型跑一遍记录每张的预测类别和置信度。然后模拟线上流程——把图片转成 base64走一遍 HTTP 接口拿回结果对比。两边的结果必须完全一致。只要有一张不一致说明链路里某个环节出了问题这时候排查范围小十分钟就能定位。我上次就是靠这个自检发现的问题接口里为了省内存把图片先缩到了 256 再传给预处理而预处理又做了 Resize(420)等于缩放了两次等效于做了一次模糊。改法是预处理函数直接接收原始 PIL 图不做任何前置缩放。5. 网页版怎么落地接口设计、交互细节与性能兜底5.1 服务结构模型只加载一次网页版的核心要求是点开就能传图看结果所以延迟要低。最基本的架构是一个 Web 框架负责接收上传一个常驻内存的模型实例负责推理。千万不能把模型加载写在请求处理函数里。ResNet50 加载权重加上初始化在普通服务器上要一两秒每个请求都来一遍用户会以为页面卡死了。正确做法是在应用启动时加载全局只留一份。import io import torch from PIL import Image, ImageOps from torchvision import transforms from flask import Flask, request, jsonify app Flask(__name__) app.config[MAX_CONTENT_LENGTH] 8 * 1024 * 1024 # 单张上限 8MB CKPT yinpian_cls.pt LABELS [line.strip() for line in open(labels.txt, encodingutf-8)] CN_NAMES {} for line in open(label_cn.txt, encodingutf-8): k, v line.strip().split(\t) CN_NAMES[k] v preprocess transforms.Compose([ transforms.Resize(420), transforms.CenterCrop(384), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]), ]) model torch.jit.load(CKPT, map_locationcpu) model.eval() torch.set_num_threads(4)MAX_CONTENT_LENGTH这个配置一定要设否则有人传个几十兆的原图上来内存直接飙。8MB 对手机拍的照片足够了现在多数手机单张 jpg 在 2 到 5MB 之间。5.2 上传接口校验做在前面错误提示要说人话接口设计上我倾向于一个极简的 POST 接口返回 JSON前端自己渲染。def predict_one(img: Image.Image, topk3): x preprocess(img).unsqueeze(0) with torch.inference_mode(): logits model(x)[0] probs torch.softmax(logits, dim0) conf, idx probs.topk(topk) return [ {label: LABELS[i], cn: CN_NAMES.get(LABELS[i], LABELS[i]), prob: float(c)} for c, i in zip(conf.tolist(), idx.tolist()) ] app.route(/api/recognize, methods[POST]) def recognize(): f request.files.get(image) if f is None: return jsonify({ok: False, msg: 没有收到图片文件}), 400 raw f.read() if len(raw) 0: return jsonify({ok: False, msg: 文件内容为空}), 400 try: img Image.open(io.BytesIO(raw)) img ImageOps.exif_transpose(img) img img.convert(RGB) except Exception: return jsonify({ok: False, msg: 这个文件无法解析为图片请换一张试试}), 400 if min(img.size) 200: return jsonify({ok: False, msg: 图片太小了建议上传清晰的原图}), 400 result predict_one(img, topk3) top1 result[0] if top1[prob] 0.45: return jsonify({ok: True, confident: False, msg: 这张图不太确定建议在白色背景下重新拍一张, topk: result}) return jsonify({ok: True, confident: True, best: top1, topk: result})错误提示的措辞值得单独说一句。返回Invalid request body这种话用户看不懂也不知道怎么办。改成图片太小了建议上传清晰的原图用户立刻知道该干嘛。这类细节对演示系统的体验影响远比想象中大。还有一个必须做的防护拒绝过小的图片。有人会传一张 80×80 的缩略图上来经过 Resize(420) 放大后糊成一片模型输出完全是噪音但页面还会显示一个置信度这就是在误导用户。判断最小边小于 200 直接拒绝比让模型瞎猜要负责任得多。5.3 结果怎么展示才不像个玩具只显示一个结果XX置信度 96.3%用户会本能地怀疑。让结果可信的关键是给出对比信息。我的做法是展示 Top-3并且用不同长度和颜色的横条表示概率。第一名加粗高亮第二三名用浅色。这样用户能看到模型是在几个候选之间做选择的而不是拍脑袋。如果第二名和第一名的差距小于 10 个百分点页面额外给一句提示前两个结果比较接近建议结合断面特征人工判断。前端部分原生 HTML 加 fetch 就够了不需要上框架。核心是三点拖拽上传或者点击选择、加载中的转圈提示、结果区域的渐进式展示。加载提示特别重要CPU 推理单张要 150 到 200 毫秒算上网络传输整体响应在 300 到 500 毫秒之间如果没有加载反馈用户会觉得点击没生效然后狂点按钮触发一堆并发请求。5.4 并发与性能几个不太起眼但很关键的参数部署上如果是小规模使用gunicorn 开两到四个 worker 就够了。但这里有个陷阱每个 worker 都会加载一份模型。ResNet50 加载完大约占 200MB 内存四个 worker 就是 800MB加上 Python 解释器和框架本身一台 2GB 内存的小服务器就撑不住了。解决办法有两个方向。一是减少 worker 数量配合多线程处理请求——PyTorch 的推理会释放 GIL用--threads参数让每个 worker 内部多线程处理通常两个 worker 各四线程的配置吞吐量比四个单线程 worker 更好内存还省一半。二是在模型前面加一个队列控制并发推理的数量超出的请求排队等待或者直接返回服务繁忙。演示系统用第二种会简单些。另一个容易忽略的是torch.set_num_threads()。默认情况下 PyTorch 会用满所有 CPU 核心在多 worker 场景下会互相抢核实际性能反而下降。手动限制到每个进程四到八个线程实测吞吐量明显提升。6. 跑起来之后才暴露的问题以及下一步怎么迭代6.1 长尾类别那些永远学不好的少数品种系统一上线最先暴露的永远是小样本类别的误判。五十个类里样本量前二十的类别准确率能到 96% 以上后十个可能只有 60% 出头。整体指标被前面的类别拉高了看起来很美实际用起来一碰到冷门品种就翻车。处理长尾我的建议是别死磕模型。先做两件事一是把每个类别的样本量、准确率列成一张表让问题可见二是针对低准确率的类别回过头看样本本身的拍摄质量很多时候问题出在这几类的照片拍得太随意比如拍摄时没有切开、没有展示断面特征。如果确实是样本量限制那就认。在产品层面做提示当 Top-1 置信度低于某个阈值并且预测类别属于样本量不足的那批时页面明确写一句该品种样本较少识别结果仅供参考。坦诚比假装准确要强。6.2 误判的典型模式与针对性补救跑一段时间后把用户的失败案例收集起来看会发现误判高度集中在几个模式上而不是均匀分布误判模式具体表现补救思路形态相近类互换A 被判成 B两者切片形状几乎一致采集时增加断面、纹理的特写样本颜色漂移导致误判冷光下拍摄的样品被判成颜色相近的另一类补充不同光照条件的样本或前端加白平衡提示多片堆叠一张图里放了一堆模型抓不到主体前端明确提示一次一片或加目标检测做裁剪非饮片物体传了别的东西进来模型硬给一个答案加一个其他/非饮片类或者用置信度阈值拒识第四条特别值得做。加一个拒识机制比什么都强当所有类别的概率都低于阈值或者 Top-1 和 Top-2 的差距过小时直接返回无法确定。这比强行给一个错误答案的体验好太多也更能体现系统的可用性边界。至于其他这个类怎么加最省事的做法是把一些明显不属于饮片的图手、桌面、包装袋、其他药材收集几百张作为一个额外的类别参与训练。这样模型有了显式的这不是饮片的输出拒识就有了依据。6.3 这套东西还能往哪扩做完分类这一层能延展的方向其实不少。往细里走可以做规格识别——同一品种的厚片、薄片、斜片、丝状分开这本质上是更细粒度的分类但需要重新采集带规格标签的数据。往深里走可以做质量分级比如片型的完整性、色泽均匀度、有无霉变这块要从分类转向回归或者多标签评估标准也更复杂。往系统层面走可以加批量上传和表格导出把单张识别变成一个小工具可以加历史记录让用户查看自己识别过的样本还可以把模型换成轻量版本放到浏览器里跑用 ONNX Runtime Web这样连服务器都不用隐私和延迟都更好代价是模型容量受限准确率可能要退几个点。我个人觉得最值得先做的是拒识和 Top-3 展示这两件小事。它们不涉及重新训练改动量很小但对系统的可信度提升最明显。很多演示性质的 AI 页面之所以看起来像个玩具问题不在于模型不够强而在于它从来不说我不确定。最后分享一个我在这个项目里反复验证过的小习惯每次改完数据或者模型别只看总准确率一定把混淆矩阵调出来按类别看一遍。你会发现真正需要投入精力的永远是那三五个特定的类别而不是整个数据集。把这几类的样本补齐、拍好指标涨得比调半个月超参都快。
阅读完成 · 觉得有帮助？
