简介面向中医AI应用开发者的JAVA舌诊接口示例代码包适用于需要快速接入舌象检测、体质辨识与健康指导功能的业务场景。项目采用Maven结构核心代码按src/main与src/test分层包含30个Java源文件、5张JPG与3张PNG示例舌象图以及Maven构建配置、yml运行配置、XML映射和说明文档压缩包仅3.57MB共41个文件。代码覆盖三十多种舌象特征检测与识别支持提取舌体区域、输出舌象特征属性描述并结合年龄、性别问诊交互进一步辨识体质和脏腑健康状态。已有1407人下载学习适合具备一定Java基础、希望参考完整接口调用链与特征识别流程的中高级开发者可作为中医数字化项目落地的可直接运行示例。1. 舌头照片背后的 Java 工程链路舌诊接口不只是“拍一张图调一个模型”一套中医舌诊系统做上线最容易被低估的不是模型精度而是图片入口和 Java 后端工程化。用户拿手机拍舌头光线一偏舌色就从淡红拍成了暗红模型训练用的是标准光源图线上图一进来接口返回的结果连中医师都摇头。我见过不止一个团队把人力全压在算法调优上最后发现瓶颈在采集规范、图像预处理、推理封装和数据映射这一整条链路。标题里说的“JAVA 中医舌诊接口使用示例代码”和“JAVA 舌象图特征人工智能识别代码”本质上是同一个落地问题怎么在 Java 服务里把一张普通舌头照片变成结构化特征字段比如舌色、苔色、齿痕、裂纹再把这些字段交给业务方去做辨证参考。适合谁看适合 Java 后端工程师、医疗信息化开发者和想接入舌诊能力的业务团队。这条链路我拆开讲按可复现的顺序走一遍。2. 舌象识别系统的整体链路与选型为什么生产环境不推荐裸调深度学习模型2.1 从舌头照片到诊断字段一条数据链路里的五个环节舌象特征检测与识别拆开看是连续五个环节任何一个环节出错都会污染后面的输出。第一环节是采集与上传App 或小程序拍照图片经过压缩后传到 Java 后端。第二环节是图像预处理把舌头区域从人脸或口腔背景里分割出来做颜色校正和尺寸统一。第三环节是推理分割用训练好的语义分割模型把舌头从图片中抠出来精确到像素级。第四环节是特征分类用另一个分类模型或者同一个多任务模型识别舌色、苔色、齿痕等属性。第五环节是业务映射把模型的概率输出换算成中医师能读的舌诊描述再落到体检报告或处方建议里。多数团队只在第三和第四环节上较劲忽略了前两步。实际上舌诊识别和通用图像识别的最大区别在于颜色敏感度舌色和苔色的差异经常是几个色阶的事而 JPEG 压缩率高了、白平衡偏了、甚至手机开了滤镜都会把输入数据推离训练分布。我在 Java 侧接舌诊模型时代码仓库里最先固定的不是推理代码而是图片预处理的参数和采集规范文档。模型可以迭代入口脏了谁也救不了。2.2 推理集成选型对比TensorFlow Java API、ONNX Runtime 与独立推理服务Java 项目里调用训练好的深度学习模型常见做法有三种。每种我都用过直接说结论。第一种是直接用 TensorFlow Java API 加载 SavedModel。优点是依赖简单一个 Maven 依赖搞定模型和业务代码同进程。缺点是 TensorFlow Java 的版本和 C 底层库强绑定升级模型格式时经常遇到原生库不兼容排障时还要看 JNI 层的报错非常难受。第二种是把模型转成 ONNX 格式用 ONNX Runtime 的 Java API 加载。我现在的主力方案就是这个。ONNX Runtime 对 Java 的支持成熟Maven 依赖com.microsoft.onnxruntime:onnxruntime下载即用跨平台的原生库被打包好了模型迭代时只需要替换.onnx文件Java 代码几乎不用动。第三种是包一层 Python 推理服务Java 通过 HTTP 或者 gRPC 调用。适合算法团队以 Python 为主、模型频繁迭代的场景。优点是解耦彻底算法那边自己管模型版本缺点是 Java 侧多一次网络开销推理服务的存活和超时都要纳入治理运维组件多了一个。三者的取舍我按项目阶段给一个参考表方案集成成本运行时依赖适合场景典型坑TensorFlow Java API低TF 原生库版本敏感小型项目模型常年不变版本不兼容时原生库崩溃ONNX Runtime Java API低单一 jar onnx 模型文件生产主力模型后续会迭代模型转换时算子丢失Python 推理服务中独立服务需部署和监控算法团队独立迭代模型网络超时服务雪崩如果让我给从零开始的团队一个建议直接走 ONNX Runtime不要犹豫。2.3 模块边界与部署形态把识别能力封装成舌诊接口的常见做法确定了推理引擎之后Java 工程里的模块边界也要定清楚。我不建议把图片上传、预处理、推理、业务映射全部揉在一个 Controller 类里那样前三个月看着爽后面模型迭代一次就改一次 Controller。我一般把工程拆成四层。第一层是入口层只做请求校验和参数接收第二层是预处理层专门负责图像解码、裁剪、颜色校正和归一化第三层是推理层封装对 ONNX 模型的加载和调用对外只暴露一个TongueFeature recognize(Mat image)方法第四层是业务映射层把模型输出转成诊断相关的字段结构。部署形态上舌诊接口对延迟的要求通常比通用图像识别更严。体检场景里用户拍完照等着看结果推理超过三秒体验就很差了。所以推理层要设计成无状态的、可通过水平扩展加副本的服务。模型文件挂在共享存储或镜像里实例启动时加载到内存请求进来只做计算。之前有个项目用 OpenShift 部署出现过内存不够把实例压崩的情况后来在启动参数里给 JVM 堆和线程池都做了上限控制才把问题压住。这里面涉及 Java 基础里的内存模型和线程管理不提前规划生产环境会拿血泪教训教你。3. 舌象图特征识别前的图像预处理OpenCV 裁剪、颜色校正与归一化参数3.1 舌头区域的自动提取从肤色分割到形态学操作模型输入不是整张照片而是裁剪后的舌头区域。原因很简单模型训练时看到的是舌头为主体的图线上传整图会让背景干扰分类结果。舌头区域提取的常见做法是结合肤色分割和形态学操作。第一步把原图从 BGR 转换到 HSV 颜色空间。舌体和面部肤色虽然接近但在 HSV 的 H 通道上舌头的红色饱和度通常比面部皮肤更高S 通道的分布也和皮肤有差异。这时可以用一个范围阈值做初筛。第二步做形态学开闭运算去掉噪点、填上孔洞。第三步找最大连通域把最大的连通区域作为候选舌头区域然后计算外接矩形并扩大 10% 到 15% 的边距把舌头边缘完整包进来。下面是一段我常用的 OpenCV 预处理代码用 Java 写的处理的是上传的原图import org.opencv.core.*; import org.opencv.imgcodecs.Imgcodecs; import org.opencv.imgproc.Imgproc; public class TonguePreprocessor { public Mat extractTongueRegion(String imagePath) { Mat src Imgcodecs.imread(imagePath); if (src.empty()) { throw new IllegalArgumentException(图片解码失败: imagePath); } Mat hsv new Mat(); Imgproc.cvtColor(src, hsv, Imgproc.COLOR_BGR2HSV); // 舌体区域在 HSV 下的大致范围具体阈值要根据训练集微调 Scalar lower new Scalar(0, 30, 80); Scalar upper new Scalar(20, 180, 255); Mat mask new Mat(); Core.inRange(hsv, lower, upper, mask); // 形态学操作先开运算去噪再闭运算填洞 Mat kernel Imgproc.getStructuringElement(Imgproc.MORPH_ELLIPSE, new Size(5, 5)); Imgproc.morphologyEx(mask, mask, Imgproc.MORPH_OPEN, kernel); Imgproc.morphologyEx(mask, mask, Imgproc.MORPH_CLOSE, kernel); // 找到最大连通域作为舌体区域 java.util.ListMatOfPoint contours new java.util.ArrayList(); Mat hierarchy new Mat(); Imgproc.findContours(mask, contours, hierarchy, Imgproc.RETR_EXTERNAL, Imgproc.CHAIN_APPROX_SIMPLE); double maxArea 0; Rect maxRect null; for (MatOfPoint contour : contours) { Rect rect Imgproc.boundingRect(contour); if (rect.area() maxArea) { maxArea rect.area(); maxRect rect; } } if (maxRect null) { throw new RuntimeException(没有检测到舌体区域请检查图片角度和光线); } // 矩形外扩 10%避免舌头边缘被切掉 int marginX (int) (maxRect.width * 0.1); int marginY (int) (maxRect.height * 0.1); int x Math.max(0, maxRect.x - marginX); int y Math.max(0, maxRect.y - marginY); int w Math.min(src.cols() - x, maxRect.width marginX * 2); int h Math.min(src.rows() - y, maxRect.height marginY * 2); return new Mat(src, new Rect(x, y, w, h)); } }这段代码的逻辑是先用颜色范围生成掩码再用形态学操作清理掩码噪点。需要重点说明的是下界和上界的设置lower (0, 30, 80)意味着色相在红色区域、饱和度不低于 30、亮度不低于 80。这个范围是我基于一批手机拍摄的舌象图调出来的如果你的线上图片偏暗或者偏黄可以在 10% 范围内微调 S 和 V 通道的阈值。注意不能把 H 上界调得太高否则会把嘴唇和口腔黏膜一并圈进来。在实际项目里如果图片有多个连通域比如舌头被牙齿挡住了一部分最大连通域可能只圈住半截舌头。这种情况的处理策略是判断候区域的长宽比正常伸舌头的照片里舌体区域接近 1:1 到 1.5:1如果长宽比超过 2:1说明大概率圈错了直接拒绝这张图而不是硬推理。3.2 颜色空间转换与舌色苔色校正光照不理想时的三个必调参数舌诊里最看重的就是颜色。舌色淡红、红、绛、紫苔色白、黄、灰黑差一个色阶辨证结论完全不同。手机拍照时光照条件不可控所以颜色校正比裁剪更影响最终识别质量。常见做法是引入一个标准色卡让用户拍照时把色卡放在舌头旁边然后算法根据色卡区域的实际颜色和标准颜色之间的偏移做全局颜色校正。这个方案准确但用户配合度低体验也一般。实际工程里更常用的是“灰世界假设”校正假设整张图里 RGB 三个通道的平均值接近灰色然后把三个通道的比例拉回 1:1:1。我用 OpenCV 实现灰世界校正时的三个必调参数给你一条条说清楚。第一是白平衡参考区域的选择。如果整张图做灰世界假设遇到舌尖红润、背景苍白的图片校正会把舌头颜色拉灰。我一般先裁剪舌头区域在舌头区域内做灰世界校正而不是对整图做。第二是通道增益的截断范围。三个通道的增益系数计算出来后如果某个通道的增益超过 2.0说明原图严重偏色这时要截断到 1.5 到 2.0 之间否则校正后的图会出现不自然的色斑。第三是输出颜色空间的选定。校正完成后要把 RGB 图转到 Lab 颜色空间再做归一化因为 Lab 空间的 L 通道和 a、b 通道分离了亮度与色度模型在反光、阴影等亮度变化下更容易保持稳定。这三个参数在代码里体现在一次颜色转换和一次手工增益计算中public Mat colorCorrectInTongueRegion(Mat tongueRegion) { // 分离通道计算舌头区域内的平均亮度 java.util.ListMat channels new java.util.ArrayList(); Core.split(tongueRegion, channels); Scalar meanB Core.mean(channels.get(0)); Scalar meanG Core.mean(channels.get(1)); Scalar meanR Core.mean(channels.get(2)); // 灰世界假设让三个通道的平均值对齐 double gray (meanB.val[0] meanG.val[0] meanR.val[0]) / 3.0; double gainB gray / (meanB.val[0] 1e-6); double gainG gray / (meanG.val[0] 1e-6); double gainR gray / (meanR.val[0] 1e-6); // 增益截断避免偏色图被过度校正 gainB Math.min(gainB, 1.8); gainG Math.min(gainG, 1.8); gainR Math.min(gainR, 1.8); Core.multiply(channels.get(0), new Scalar(gainB), channels.get(0)); Core.multiply(channels.get(1), new Scalar(gainG), channels.get(1)); Core.multiply(channels.get(2), new Scalar(gainR), channels.get(2)); Mat corrected new Mat(); Core.merge(channels, corrected); // 转到 Lab 空间后续归一化用 Mat lab new Mat(); Imgproc.cvtColor(corrected, lab, Imgproc.COLOR_BGR2Lab); return lab; }这段代码有两个值得注意的设计。一是增益系数的下限代码里没有限制下限意味着如果某个通道均值极低增益会非常大所以我加了一个统一的 1.8 上限这是经验值二是Core.multiply操作会原地修改通道数据在使用后要特别注意及时释放内存避免在批量图片处理时把 JVM 堆占满。我在实际项目里是直接在舌体区域内做增益计算区域外不做处理这样可以把脸部和背景的偏色影响降到最低。3.3 预处理输出格式与推理模型输入对齐的数据张量预处理做完后最终输出的数据张量必须和模型的输入层完全对齐。这里涉及到 OpenCV 的Mat对象如何转换成 ONNX Runtime 需要的float[]数组。假设模型输入是1x3x224x224的 RGB 图像每个像素归一化到[0, 1]。OpenCV 默认是 BGR 通道排列直接转会出问题所以要先做通道顺序转换。再有一个隐藏坑Mat里的数据排列是 HWC即高度×宽度×通道而 ONNX 模型普遍要求 CHW即通道×高度×宽度需要把数据重新排序。我就是在这里翻过车的前几次跑推理一直报维度不匹配后来逐维打印形状才发现是 HWC 和 CHW 的差异。下面的代码把这个转换处理得比较稳妥public float[] matToTensor(Mat lab, int width, int height) { // 缩放模型要求的输入尺寸 Mat resized new Mat(); Imgproc.resize(lab, resized, new Size(width, height)); Imgproc.cvtColor(resized, resized, Imgproc.COLOR_Lab2BGR); Imgproc.cvtColor(resized, resized, Imgproc.COLOR_BGR2RGB); float[] tensor new float[3 * width * height]; int channelSize width * height; for (int h 0; h height; h) { for (int w 0; w width; w) { double[] rgb resized.get(h, w); int index h * width w; tensor[index] (float) (rgb[0] / 255.0); tensor[index channelSize] (float) (rgb[1] / 255.0); tensor[index channelSize * 2] (float) (rgb[2] / 255.0); } } return tensor; }代码里的resized.get(h, w)每次都会返回一个double[]在 224x224 的尺寸下性能问题不大但如果图片需求是 512 或更高建议改成一次性取全部像素再手动换算索引避免逐像素调用 JNI 带来的开销。另外归一化用的是除以 255而不是 ImageNet 的均值方差归一化因为舌诊模型通常在自有数据上训练标准 ImageNet 参数并不适用。你在训练模型时用了什么归一化参数推理端必须严格对应这个要在模型交付文档里写清楚比代码本身更重要。4. 用 Java 调用训练好的舌象识别模型ONNX Runtime 推理代码与特征映射4.1 模型推理的最小代码加载模型、构造输入、执行会话ONNX Runtime 的 Java API 用起来比 TensorFlow Java 省心得多。加载一个.onnx模型并执行推理核心代码不到二十行。我先把最小可运行版本贴出来。import ai.onnxruntime.*; import java.util.Collections; public class TongueInference { private final OrtEnvironment env; private final OrtSession session; public TongueInference(String modelPath) throws Exception { this.env OrtEnvironment.getEnvironment(); OrtSession.SessionOptions options new OrtSession.SessionOptions(); // 开启 CPU 优化内联 内存优化 options.setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT); this.session env.createSession(modelPath, options); } public float[][] infer(float[] tensor, long[] inputShape) throws Exception { OnnxTensor inputTensor OnnxTensor.createTensor(env, tensor, inputShape); // 模型输入节点名用 Netron 查看模型后确定 OrtSession.Result result session.run(Collections.singletonMap(input, inputTensor)); OnnxValue value result.get(0); return (float[][]) value.getValue(); } public void close() throws Exception { session.close(); env.close(); } }这段代码里env全局应该只创建一次多个请求共用同一个OrtSession它是线程安全的。inputShape要和模型输入完全一致常见的是{1, 3, 224, 224}如果模型是分割模型输出形状可能是{1, 1, 224, 224}。session.run方法传入的是一个MapString, OnnxTensorkey 是模型的输入节点名value 是张量。节点名不能猜用 Netron 打开模型看一眼最保险。这里有一个容易被忽略的点OnnxTensor.createTensor在每次请求时都会创建如果创建频率很高建议用对象池或复用张量。但张量持有的是float[]的引用复用时要小心数据覆盖的问题。我现在的做法是每次推理创建新张量由 GC 回收配合后面的异步化设计性能完全够用。4.2 从模型输出到舌诊特征概率矩阵如何变成舌色、苔色与齿痕推理返回的裸张量不能直接给业务方看。分割模型输出的概率图需要还原成舌头区域掩码再反算舌色和苔色的统计特征分类模型输出的概率向量需要映射成中医术语。我在工程里定义了一个统一的特征对象把分类型的输出和分割型的输出组合成一份完整舌诊特征。下面这个类就是业务侧看到的数据结构public class TongueFeature { private String tongueColor; // 舌色淡红、红、绛、紫 private String coatingColor; // 苔色白、黄、灰黑 private double coatingThickness; // 苔厚指数 0.0~1.0 private boolean teethMark; // 是否有齿痕 private boolean crack; // 是否有裂纹 private double confidence; // 综合置信度 }特征映射的核心逻辑是分类模型输出一个 8 维概率向量分别对应预定义的 8 类舌色把这个概率向量按最大概率取类别同时记录概率值作为置信度。分割模型输出每个像素属于舌体、苔质、背景的概率把属于苔质的像素占比作为苔厚指数把舌体边缘的凹凸程度作为齿痕的判别依据。业务映射这一层很容易遇到 AI 模型和中医术语无法对齐的情况。模型训练时的标签是数据标注员给的标注员可能把“淡红”和“红”混为一谈也可能把“薄白苔”和“白苔”合并。所以我在特征映射层维护了一张标签映射表模型输出先转成内部标签再转成对外暴露的中医描述。这个表要在算法团队和数据标注团队之间反复确认不要在 Java 代码里写死。4.3 舌诊接口的异步化与超时控制让 Java 服务在高峰期不拖垮业务舌诊推理是 CPU 密集型操作在低并发时同步阻塞问题不大。但一旦接体检系统每天几千张图并发进来同步执行会让 Tomcat 的线程池被打满其他普通业务接口也跟着卡死。我在这里的调优做法是把推理任务丢到独立的线程池里执行用 Future 做超时控制。下面这段代码是服务层调用的典型写法import java.util.concurrent.*; public class TongueDetectService { private final ExecutorService processor new ThreadPoolExecutor( 8, 16, 30, TimeUnit.SECONDS, new ArrayBlockingQueue(200), new ThreadPoolExecutor.CallerRunsPolicy() ); public TongueFeature detectAsync(Mat image) { FutureTongueFeature future processor.submit(() - { Mat region preprocessor.extractTongueRegion(image); float[] tensor preprocessor.matToTensor(region, 224, 224); float[][] output inference.infer(tensor, new long[]{1, 3, 224, 224}); return featureMapper.map(output); }); try { // 推理超过 2 秒直接返回避免拖垮调用方 return future.get(2, TimeUnit.SECONDS); } catch (TimeoutException e) { future.cancel(true); throw new RuntimeException(舌象识别超时); } catch (Exception e) { Thread.currentThread().interrupt(); throw new RuntimeException(舌象识别失败: e.getMessage()); } } }线程池参数需要根据机器的 CPU 核数调整。核心线程数接近 CPU 核数通常 8 核左右最大线程数不要超过核数的两倍因为推理是计算密集型任务线程太多会因为 CPU 争抢而变慢。队列长度 200 是一个折中值队列太短会导致大量请求直接被拒绝太长则会让排队时间超过三秒体验同样糟糕。CallerRunsPolicy是最后的兜底策略当队列满了时由提交任务的线程自己执行推理至少不会丢数据。5. 舌象识别接入避坑与排查5 个高频问题从现象到根因5.1 同一个舌头在不同手机上颜色完全不一样现象用户在同一时间用两台手机拍同一舌头接口返回的舌色一个偏红一个偏白业务方认为是模型不稳定。原因手机厂商的相机 ISP 处理风格完全不同有的偏冷、有的偏暖白平衡算法也各有偏好。颜色校正只依赖灰世界假设时无法消除这一层偏色差异。解决在采集端做统一处理。常见做法是在拍照页面加一个“标准拍摄姿势”引导要求舌头自然伸出、光线均匀、不开启任何滤镜和美颜。还有更强的方案引入一张标准色卡随图上传在预处理阶段先定位色卡用色卡的真实颜色值反推图像的色彩映射关系再对舌头区域做校正。如果你的客户是体检机构可以推一套固定拍摄设备比任何算法都省事。5.2 模型训练时有齿痕线上怎么识别不出来了现象训练集里齿痕的样本 AUC 在 0.92线上却频繁漏报齿痕检出率不到五成。原因训练阶段用的齿痕图大多是舌头自然伸出、边缘清晰的图。线上真实照片里舌头边缘常被阴影遮挡分割模型算出来的边缘锯齿被当成齿痕而真正的齿痕因为舌体边缘不够锐利被当成噪声抹掉了。解决把齿痕检测从“整体分类”改成“分割后统计”。先用分割模型把舌体边缘提取出来对边缘的凹凸度做量化统计定义凹凸度阈值; 凹凸度超过阈值才认为是齿痕。阈值调参时不要只盯训练集要专门收集几十张线上真实阴影图做验证集用验证集的表现来确定最终阈值。5.3 推理结果偶发延迟接口超时把调用方打到雪崩现象平均耗时 300 毫秒但每 100 次请求里有几次耗时超过 3 秒调用方连续重试把后端线程池打爆。原因图片解码和 JNI 调用的耗时不稳定尤其是大图。用户上传的图片尺寸不固定一张 4000x3000 的图在预处理阶段做滤波和缩放时占用 CPU 明显更高。另外 JVM 发生 GC 时如果堆里有大量 Mat 对象等待回收暂停时间会进一步放大延迟。解决入口处限制上传图片的分辨率最长边超过 1600 像素直接等比缩到 1600对图片解码设置超时解码超过 1 秒直接拒绝并新增自定义中间文件。同时在做完预处理后立刻mat.release()释放 OpenCV 对象不依赖 GC。线程池超时后不再重试而是向调用方返回一个明确的“处理超时”错误码。5.4 模型文件加载失败Java 版本与原生库不兼容现象本地开发跑得好好的测试环境用 JDK 17 启动直接报UnsatisfiedLinkError一堆看不懂的 JNI 报错。原因ONNX Runtime 的二进制原生库和 JDK 版本有对应关系换了一个 Java 大版本后Maven 依赖没有跟着升到对应版本。解决这是最典型的 Java 环境变量配置问题。排查时先看 Maven 依赖的onnxruntime版本再看 JDK 的主要版本两者对照官方兼容矩阵调整。我这里踩过 JDK 8 升 17 的坑解决办法是把com.microsoft.onnxruntime:onnxruntime从 1.10.0 升到 1.14.0之后 JDK 17 正常。还要注意部署环境里JAVA_HOME是否正确指向了实际使用的 JDK别让构建用的版本和运行时的版本不一致。5.5 舌诊接口输出的概率很高但业务方不知道该怎么用现象模型返回了tongueColor红confidence0.94业务方和中医师讨论后说“这个结论没法直接用不同体质的人红舌意义不一样”。原因这是一个典型的业务映射问题。模型输出的舌象特征只是客观描述但中医辨证需要一个综合的判断要结合其他四诊信息。直接拿一个舌色特征开处方谁也接不住。解决接口设计上把“特征层”和“决策层”分开。舌诊接口只做特征输出不直接下结论决策层由业务系统自行实现结合问诊、脉诊等其他信息做综合判断。我在项目中建议业务方把舌诊接口的结果作为“辅助参考因子”而非“唯一依据”并在接口的返回结构里加上每个特征的置信度这样业务方可以根据场景自行调整权重而不是面对一个孤独的概率值无从下手。6. 把舌诊接口从“能返回概率”推到“能辅助决策”一个验证与落地的进阶技巧6.1 用 kappa 系数给舌诊接口做上线体检舌诊识别模型线下指标高不代表线上能落地。我建议在上线前做一次独立验证找两位有经验的中医师对同样一批测试图分别标注舌色和苔色再让接口对同一批图做识别。用标注一致性检验先算接口识别结果与医师 A 的一致率再算与医师 B 的一致率最后算两位医师之间的一致率。三位一致率放在一起看如果接口和医师的一致率明显低于两位医师之间的一致率说明模型还没达到需要的人工标注水平。实际的量化指标我用 kappa 系数而不是原始准确率。原始准确率会受类别分布不均影响比如 80% 的样本都是淡红舌模型全预测淡红舌也有 80% 的准确率kappa 系数剔除了随机一致的概率对分类器真正的判别能力更敏感。kappa 在 0.6 以上我才会放这个接口进灰度。6.2 灰度发布的量化观察设合理的阈值而不是拍脑袋灰度阶段我在接口返回里额外加一个source_version字段用于区分新旧模型的预测结果。观察三个核心指标调用方对结果的使用率判断业务方是否信任这个结果、同一用户重复拍照时结果的一致性判断接口的稳定性、以及两类典型偏色照片上的召回表现。这三个指标里重复拍照一致性最容易被忽视但恰恰是采集端工程化做得好不好的直接证明。设置阈值时我用舌色主类别的置信度 0.8 作为可用线低于 0.8 的结果会带上low_confidence标记业务方可以选择不展示给终端用户。这一层判断我放在接口内部实现外部调用方拿到的还是统一的数据结构不需要感知差异。6.3 一个习惯每次版本发布的回放验证我在这个项目里养成的习惯是每次模型迭代存一份当周的采样请求日志包含原图、预处理后的图、模型输出三个文件。一周后复盘时把三个文件放在一起对照看能很快定位是预处理变了、模型退化了还是业务映射错了。这个习惯帮我避开过两次算法团队换了模型文件但没同步更新归一化参数的事故。这套链路做下来最深的感受是舌诊接口在 Java 侧的难度从来不在写一个推理调用而在把图像入口的脏数据管住、把推理资源调优雅、把模型输出翻译成人能懂的结论。如果你打算做这个方向我建议先拿一百张真实舌象图把预处理参数定住再上模型。这是踩过坑之后的真心话希望帮到你。本文还有配套的精品资源点击获取