车间里最不缺的就是数据最缺的是能用的数据。我在几个制造场景里做过深度学习项目从精密加工到电子组装最初的想法都很朴素产线上传感器那么多相机、振动、电流、温度、工艺参数全都有喂给一个足够大的网络精度不就上去了吗实际做完第一轮就明白了深度学习与大数据的融合这件事难点从来不在模型结构那几行代码而在于数据从产生到进入训练集这条路上有多少环节会悄悄把信息磨掉。智能制造这个概念被讲了很多年真正把它做出来的团队往往不是模型最强的而是数据管道最干净的。这篇文章想聊的是我在实际项目里踩出来的那套做法数据底座怎么搭、四类典型场景怎么选模型、边缘部署的时延怎么算、上线之后怎么发现模型在退化以及那五个让我返工重来的坑。适合正在做产线智能化的算法工程师、数据工程师也适合负责项目落地的工艺和生产管理人员——不需要你精通反向传播但需要你对数据是怎么来的有耐心。1. 车间里那堆数据为什么喂不饱一个模型1.1 数据体量很大但信息密度低得惊人先说一个反直觉的观察。某电子组装线做过一次统计全厂区一天产生的原始数据超过 4TB其中九成以上是工业相机拍的产品图像。听起来是大数据了可真正带标签、能用于监督学习的样本一个月攒下来不到三千张其中确认缺陷的只有两百多张。这就是制造业数据最典型的形态无标签数据海量有标签数据稀缺。我习惯用一张表来给数据做体检把有多少和能用多少分开看数据类型典型日增量有标签比例主要问题工业相机图像3~4 TB低于 1%存储成本高缺陷样本极稀振动/电流波形10~20 GB无采样率高但冗余大工艺参数温度、压力、节拍数百 MB与批次结果弱关联采样率低时间对齐难质检工单与维修记录数 MB全部有标签文字描述非结构化口径不一看这张表就能明白为什么很多团队一上来就搭 GPU 集群最后模型精度还是卡在 80% 上不去。模型不缺算力缺的是标签密度和时间对齐的准确性。大数据这一侧真正要解决的问题是把散落在 PLC、MES、质检系统、维修工单里的碎片拼成一条能对得上的时间线而不是把数据量堆到 PB 级。1.2 深度学习在产线上的能力边界在哪里我见过不少项目在立项时就写用深度学习实现全流程智能优化这种目标基本注定失败。深度学习擅长的东西其实很明确高维、非结构化、有大量样本的模式识别。图像缺陷检测、声音异常识别、复杂波形分类这几类它做得比传统方法好很多。反过来凡是需要强因果推断、强约束满足、小样本外推的任务比如排产优化、工艺窗口的物理边界深度学习往往不如运筹学方法加机理模型稳。我的经验是给任务做一次分类先判断该不该上深度模型任务答案依赖看和听的直觉判断 → 深度模型的主场视觉和音频分支优先。任务答案依赖明确的规则与约束 → 先用规则引擎或混合整数规划深度学习只做参数预测的辅助。任务答案依赖物理机理且样本极少 → 机理模型为主深度学习做残差修正。任务需要长期外推预测 → 深度学习单独用风险很大必须叠加统计基线做对照。这个分类看着朴素但它能挡掉至少三分之一的无效投入。我印象最深的是一个用 LSTM 预测刀具剩余寿命的尝试样本只有四十多条完整寿命记录模型在训练集上拟合得极好上线一周就开始乱报。后来改成机理公式加简单的回归修正反而稳定跑了半年。1.3 融合不是把数据丢进显卡是一条四段式链路把深度学习和大数据放一起很多人脑子里是一个箭头数据 → 模型。实际工程里它是四段闭环任何一段断了后面的都不成立。第一段是采集与对齐解决这条缺陷记录对应的是哪一秒钟的哪一段波形。第二段是治理与特征化解决原始信号怎么变成模型能吃的张量同时把工艺知识编码进去。第三段是建模与验证解决用哪个模型、用什么指标证明它真的有用。第四段是部署与回流解决模型在生产环境里怎么跑得动以及怎么知道它开始变差。这四段里我认为第一段的价值被严重低估。后面章节会反复提到时间戳错位是制造业机器学习项目最隐蔽的杀手它不会报错只会让模型安静地学到错误的东西。2. 数据底座怎么搭从传感器到特征库的可复现路径2.1 采集层协议选型与时间同步为什么最要命采集层的第一个决策是协议。车间的设备大致分三类老设备只有 Modbus RTU 或串口新一点的产线用 Modbus TCP 或 OPC UA高端控制器走 Profinet 或 EtherCAT。我的做法是不在设备侧做任何改造统一在边缘网关上做协议收敛网关往下用各自的原生协议读往上统一转成 MQTT 或直接写 Kafka。这里有个容易忽略的细节读寄存器的频率必须和设备的实际刷新周期匹配。曾经有个项目把 PLC 的模拟量按 100ms 轮询看着数据很密实际上 PLC 内部这个变量的刷新周期是 500ms等于同一份数据被重复采了五次。这种假高频会让后续所有基于频率的特征全部失真比如计算振动主频时会出现一堆虚假的谐波。时间同步更是关键。常用方案有三个层级方案同步精度适用场景代价NTP毫秒级1~10ms工艺参数、工单记录几乎为零PTPIEEE 1588亚微秒到微秒级振动、多相机协同需要支持硬件时间戳的交换机硬件触发线微秒级以内多相机同时曝光布线成本高判断标准很简单如果你的特征里包含跨设备的时间差或者高频信号的相位信息就必须上 PTP 或硬件触发NTP 那几毫秒的抖动足以毁掉相位特征。只做温度、压力、节拍这类慢变量的NTP 完全够用别为了先进多花钱。我个人还有一条硬规矩每条数据在采集时就打上两个时间戳一个是设备侧的产生时间一个是网关侧的接收时间。两个时间戳的差值长期监控一旦某个设备的差值分布发生偏移说明它的时钟在漂这个告警比模型精度下降要早得多。2.2 存储层别用一套系统装所有数据存储选型上我见过最常见的错误是把图像塞进关系型数据库或者把时序数据存成 CSV 堆在共享盘上。合理的分工是这样的时序数据走专门的时序库InfluxDB、TDengine、TimescaleDB 都行核心诉求是高写入吞吐和按时间范围标签的快速聚合。振动这类高频信号我倾向于在边缘侧先做降采样和特征提取只把原始波形按异常片段的方式存对象存储全量原始波形保留 7 到 15 天就够回溯用。图像走对象存储MinIO 之类自建的就很好按产线/工位/日期/批次做桶和前缀。必须配一套元数据索引把图片路径和批次号、工单号、质检结果关联起来否则后面找样本会找疯。结构化业务数据留给关系库MES 的工单、质检结论、维修记录都在这里。训练用的数据集版本单独管理用 DVC 或类似工具做版本化别让这个模型是用哪版数据训的变成悬案。算一笔存储账会更清楚。假设一条线有 10 个检测工位每工位每分钟过 60 件每件拍 2 张 200 万像素灰度图单张约 2MB那么一天的图像量大约是 10 × 60 × 2 × 2MB × 60分钟 × 20小时 ≈ 2.9TB。按全量存一年就是上千 TB成本不可接受。所以一定要做分级存储全量图保留 3 天用于问题回溯判定为缺陷的图永久保留正常样本按比例抽样保留比如每天抽 2%这样既能控制成本又不至于把训练集抽没了。2.3 特征层把工艺知识编码进去而不是让网络瞎猜特征工程这一层是大数据和深度学习真正握手的地方。纯粹端到端的做法在实验室很漂亮在产线上往往输不过手工特征 轻量模型。原因很实在产线的样本量撑不起一个大网络自己学出物理规律。我的做法是分两路走。一路是信号处理特征振动信号做时域均方根、峰值因子、峭度和频域FFT 后的频段能量、包络谱峰值特征电流信号做谐波分析这些特征可解释、稳定、计算便宜。另一路是深度特征用自编码器或预训练骨干网络把原始波形/图像压成一个低维向量。这两路特征最后拼在一起喂给下游模型。听起来土但效果确实好——在一个刀具磨损预测任务里纯深度特征的 F1 是 0.71纯手工特征 0.76拼接之后到了 0.84。原因不难理解手工特征把磨损会导致某频段能量上升这条已知规律直接告诉了模型模型就不用再从零样本里去发现它。特征的组织方式我建议上特征存储Feast 这类工具就够用。它的价值不在于技术多先进而在于让离线训练和在线推理用同一份特征定义避免训练时用的特征和线上算的不一样这种经典事故。这个坑我在第 5 章会详细讲。2.4 标签体系制造业最难的一环没有之一建模的难度被高估了打标签的难度被严重低估。制造业的标签有三个来源自动检测设备的判定、人工复检结论、下游工序的失效反馈。这三者经常不一致。我参与过的一个项目里同一批产品被三个班次的质检员判过一致率只有 82%。也就是说即使模型 100% 复现了某一个质检员的判断它在另一个质检员眼里也只有八成正确。这种情况下你追求的99% 准确率根本没有意义。处理办法有几条。一是建立标签置信度同一件产品至少两人判定一致的标为高置信不一致的进复核池训练时给不同置信度样本不同权重。二是优先用下游失效作为金标准因为那是客观发生的虽然延迟长但价值最高。三是记录判定依据让质检员在标注时勾选缺陷类型和大致位置这些信息在做弱监督时非常有用。还有一点标签的时间戳必须精确到这件产品是在哪个时刻被检测的。很多系统只记工单号和日期这在批次级的分析里够用但要和秒级的传感器数据对齐就彻底失效了。3. 四类典型场景的建模路线与参数取舍3.1 表面缺陷检测小样本和不均衡是常态视觉检测是智能制造里落地最多的场景也是最容易被实验室精度误导的场景。公开数据集上刷到 99% 的模型换到真实产线上经常掉到 70% 以下原因有三个缺陷形态和训练集差异大、光照和工装位置会漂、正负样本比例可能是一千比一。我的方案分两步。第一步先做无监督的异常检测打底用 PatchCore 或 EfficientAD 这类只学正常样本的方法好处是不需要收集缺陷样本新产线导入快。上线后靠它先把明显的异常捞出来同时积累真实缺陷样本。第二步等缺陷样本攒到每类两三百张再切换到有监督检测用 YOLO 系列做定位和分类。这里有个参数细节值得说图像分辨率的选择。很多人直接把相机原始分辨率喂进去比如 2448×2048显存吃不消只能把 batch size 压到 1训练极慢。我的做法是按最小缺陷尺寸反推需要的分辨率。假设最小的有效缺陷是 0.1mm视野是 100mm×100mm那么至少需要 1000×1000 的像素覆盖加上模型下采样的损失输入做到 1280 就够剩下的靠切片推理补。这个计算能帮你把显存需求降一半以上。切片推理也有讲究切片之间要有重叠重叠比例至少是最大缺陷尺寸的 1.5 倍否则跨切片的缺陷会被切断成两个不完整的形状检测不出来。我一般用 20% 到 30% 的重叠。3.2 设备预测性维护窗口、采样与评估口径时序建模这块参数选择的逻辑比模型结构重要得多。核心参数有三个采样率、窗口长度、预测提前量。采样率要满足奈奎斯特条件同时考虑特征需求。轴承早期故障的特征频率可能到 5kHz 以上采样率至少 20kHz 才能做包络谱分析。但 20kHz 采三轴振动一台设备一天就是 20k × 3 × 2字节 × 86400 ≈ 10GB一百台设备根本存不下。所以我的实际做法是边缘侧做两级处理原始波形只保留触发前后的片段比如异常告警前后各 30 秒平时的统计特征按秒级聚合上传。这样单台设备一天的上传量降到几百 MB。窗口长度取决于故障演化的时间尺度。做未来 7 天内是否会故障的预测窗口至少要覆盖一个完整的工况周期比如一个班次或一个加工循环。我通常取工况周期的 3 到 5 倍。预测提前量则要和维修响应时间匹配——如果备件采购要一周那预测 3 天等于没用。评估口径这件事值得单独强调。预测性维护不能用准确率评估因为正常样本占 95% 以上。我用的是一套组合指标在固定误报率下的召回率比如每天最多允许 2 次误报的前提下能召回多少真实故障、提前量分布预测发生在故障前多少小时、维修成本节省。最后一个才是老板真正关心的前面两个是工程语言。3.3 工艺参数寻优先从回归做起别急着上强化学习工艺参数优化的诱惑很大——给定目标质量反推应该设置什么温度、压力、速度。很多团队第一反应是强化学习或生成模型我建议先做回归 优化这条稳路。第一步训练一个从工艺参数到质量指标的回归模型XGBoost 或 LightGBM 就够别小看树模型它在几百到几万样本的表格数据上几乎总是赢过深度网络。这个模型的作用是当虚拟实验台让你在不实际开机的情况下评估任意参数组合的效果。第二步在这个代理模型上做贝叶斯优化或遗传算法搜索找到满足约束的最优参数。这里的关键是约束条件必须显式建模。工艺参数有大量物理边界温度不能超过材料极限、升温速率受设备功率限制、某些参数之间强耦合。把这些约束写成硬性条件搜索空间才不会跑到物理上不可能的区域。我见过一个项目搜出来的最优参数确实质量指标最高但升温速率要求 200℃/分钟设备根本做不到。另外一定要做外推检测。代理模型只在其训练数据覆盖的范围内可信搜索算法天生喜欢往边界跑很容易搜到一个模型很自信但实际没见过的区域。我的做法是给搜索空间加一个可信域约束用马氏距离或简单的分箱统计判断候选点是否落在历史数据覆盖范围内超出的直接剔除。3.4 排产与节拍预测混合建模比纯深度模型靠谱排产这件事我试过纯深度模型效果不如人意。原因在于排产本质上是一个组合优化问题约束多、解空间离散、目标函数还经常变。深度学习的正确用法是预测排产所需的参数而不是直接输出排产方案。具体来说深度学习可以负责两件事。一是工时预测给定产品型号、工艺路线、设备状态预测这道工序需要多长时间。这个任务有大量历史数据用梯度提升树或一个小型 Transformer 都能做得不错重点是把设备状态、班次、操作员等上下文特征放进去。二是扰动预测预测哪些订单有延期风险提前预警。真正生成排产方案的部分交给约束规划或启发式算法。深度模型给出的工时预测作为输入参数这样既利用了数据里的规律又保证了方案满足硬约束。节拍预测有个细节别把设备的名义节拍当特征。名义节拍是理论值实际节拍受换型、待料、小停机影响差异可能有 30%。要用历史实际的工序间隔时间做目标而且要把小停机单独识别出来否则模型会把这些异常段学成正常节拍。4. 从离线到在线边缘推理与模型运维的工程细节4.1 推理时延预算怎么算一次完整的数字推演模型在服务器上跑得好不代表能上线。产线的节拍是硬约束超时就丢帧丢帧就意味着漏检。我习惯在项目开始就把时延预算算清楚而不是等部署时再说。举个实际的例子。某检测工位节拍是 1.2 秒一件也就是每分钟 50 件。整条链路的时间预算是这样拆的相机曝光加传输约 25ms曝光 8ms千兆网传 2MB 图像约 16ms图像预处理解码、缩放、归一化约 12ms模型推理预算 60ms后处理NMS、阈值判定约 8ms结果通信与执行机构响应约 30ms预留余量约 65ms合计约 200ms相对 1200ms 的节拍有充足余量。但注意如果这条线要同时检测两个面或者要做多模型串联先分割再分类预算就会紧张。这时要么加算力要么优化模型要么改成异步判定 缓存剔除的策略——也就是产线不停判定结果延迟几个工位再执行剔除动作用缓存区吸收延迟。这里有个常被忽略的点尾延迟比平均延迟重要。平均 50ms 但偶尔飙到 300ms 的模型在产线上就是灾难。我会在上线前跑至少 10 万次推理看 P99 和 P999 延迟而不只看平均值。4.2 模型压缩与部署格式的选择逻辑边缘设备的算力有限模型压缩几乎是必选项。量化、剪枝、蒸馏三板斧我一般按这个顺序试量化最省事收益也直接。FP32 转 INT8 通常能带来 2 到 4 倍加速精度损失在视觉任务上往往小于 1 个百分点。但要注意量化需要校准集校准集必须能代表线上的真实分布用训练集的一小部分往往不够。我的做法是从最近一周的线上数据里抽 500 到 1000 张做校准效果比用训练集稳。剪枝要谨慎结构化剪枝对卷积网络友好非结构化剪枝在通用硬件上未必能加速。蒸馏适合大模型教小模型但需要足够的无标签数据这在制造业反而是优势——无标签数据管够。部署格式上我的选择逻辑是看硬件硬件平台推荐格式理由NVIDIA 边缘设备TensorRT融合算子多INT8 支持成熟Intel CPU/集成显卡OpenVINO对 x86 优化充分部署简单国产或通用 ARMONNX Runtime兼容性好社区支持广多模型统一调度Triton 之类的推理服务支持动态批处理和模型版本管理有一条经验导出格式前先在原框架里做等价性验证。ONNX 转换经常在某些自定义算子或动态 shape 上出问题转换后拿 500 张图对比输出余弦相似度低于 0.999 就要查原因别等到上线才发现结果对不上。4.3 数据漂移监控模型上线那天就开始退化模型不是一次交付是一条需要长期维护的产线设备。上线第一天它就在退化——光照会变、物料批次会换、设备会磨损、工装会松动。区别只在于退化速度。监控我分三层做。第一层是输入分布监控对每个关键特征算 PSI群体稳定性指数或做 KS 检验和训练集分布对比。PSI 超过 0.1 就要警惕超过 0.25 通常意味着需要重新训练。第二层是预测分布监控看模型的输出置信度分布、类别比例是否偏移。如果缺陷率突然从 1% 涨到 5%要么是产线真出问题了要么是模型开始误报两种都需要人介入。第三层是业务指标监控漏检率、复检率、客诉率这是最终裁判。这三层要联动看。我遇到过一次输入分布的 PSI 正常预测分布也正常但复检率悄悄涨了。查下来是相机镜头有轻微污渍导致图像整体对比度下降模型判定没变但置信度普遍降低了质检员看到低置信度的结果会倾向于人工复检。这种问题只有把三层指标放在一张看板上才能发现。监控告警的阈值不要拍脑袋定我一般用上线后前两周的数据算基线取均值的 3 倍标准差作为告警线之后每个月滚动更新。4.4 闭环让产线反馈回到训练集一个没有回流机制的模型系统本质上是一次性用品。回流机制要解决三个问题哪些数据值得回传、怎么标注、多久重训一次。回传策略上我不用全传而是定几条规则模型置信度落在中间区间比如 0.3 到 0.7的样本优先回传这些是模型的困难样本价值最高被判为缺陷的样本全部回传每天随机抽样一小批正常样本回传用于监控分布。标注这边尽量把标注嵌入现有流程而不是新增一道工序。比如让质检员在复检时顺手确认模型给出的缺陷类型和框位置点一下对或不对这样几乎不增加工作量却能持续产生高质量的弱标签。重训频率取决于数据漂移速度。视觉类任务我通常按月重训时序类按季度但每次重训必须做回归测试——在固定的历史测试集上对比新旧模型新模型不能在任何关键指标上明显退步。这个回归测试集要长期冻结不能因为数据太旧就换掉它是唯一的公平裁判。5. 踩坑复盘五个让我返工的真实问题5.1 时间戳错位模型学到了班次而不是缺陷这个坑最隐蔽。项目背景是预测某道工序的产品是否会出现尺寸超差。数据集里模型 AUC 到了 0.93所有人都很兴奋。上线后一周AUC 掉到 0.55。排查过程走了不少弯路。先怀疑过拟合加了正则化没用怀疑特征泄漏把可疑特征一个个剔除AUC 缓慢下降但还是有 0.85。最后把特征按重要性排序发现排名第一的是车间环境温度而且它的重要性与当前小时数高度相关——因为白班和夜班的环境温度分布不一样而夜班的超差率恰好更高。根因是环境温度的采集时间戳是网关接收时间而产品质量的判定时间用的是 MES 的工单完成时间两者相差几个小时。模型实际上学到的是这批产品是在哪个时段生产的而不是温度导致的物理效应。修复方案是把所有时间戳统一到设备侧的产生时间并且做了一次全链路的时间对齐审计随机抽 200 条记录人工核对从传感器到数据库每个环节的时间差。这个审计后来成了我们每个新项目的标准动作。5.2 标签噪声质检员之间的一致性问题前面提过一致率只有 82%但这个问题的影响比想象中大。我做过一个对比实验用原始标签训练测试集准确率 0.86把三个人判定不一致的样本全部剔除只留高置信样本量减少 18%准确率反而升到 0.91。这说明模型之前一直在拟合噪声。更进一步可以用标签平滑或者噪声鲁棒损失函数来处理但我更推荐从流程上解决对争议样本建立仲裁机制由资深人员终裁并把裁决理由记录下来。这些理由本身就是宝贵的领域知识能反过来指导特征设计。5.3 离线指标漂亮、上线就崩的三种来源除了时间错位还有三种常见原因。一是特征计算不一致离线用 pandas 算的分位数特征和线上用流式计算算出来的不完全一样尤其是涉及过去 N 条记录这种窗口特征边界处理很容易不同。解决办法就是特征存储一份定义两处复用。二是预处理参数漂移比如归一化用的均值方差是在训练集上算的但线上数据分布变了之后没有更新导致输入尺度不对。三是训练集和线上数据的采集条件不同训练集是专门搭的采集台拍的光照稳定、背景干净线上是真实工况。这个只能靠训练集必须来自真实产线这条铁律来防。5.4 过度追求精度忽略了节拍有个视觉项目团队花两个月把 mAP 从 0.88 提到 0.93用的办法是把输入分辨率翻倍加模型加深。结果部署时单帧推理要 280ms产线节拍只有 400ms加上前后处理直接超时。最后不得不回退到精度 0.89 的轻量版本。这件事让我改了一个习惯项目立项时就把时延预算和精度目标写在一起作为一对联合约束。精度提升如果要以超出时延预算为代价那就不算提升。实际做的时候我会先用一个能满足时延的基线模型跑通全流程再在这个预算内做优化而不是先追精度再想办法压缩。5.5 验收指标和业务指标错位最典型的是缺陷检测项目验收标准写的是准确率不低于 95%听起来很合理。但实际业务里漏检一个缺陷的代价可能是整批退货误报一次的代价只是多花两分钟复检。这两个错误的代价完全不对称。正确的做法是用代价敏感的指标给定漏检和误报的代价比画出不同阈值下的总成本曲线选成本最低的阈值。如果漏检代价是误报的 50 倍那阈值就应该压低宁可多报也别漏报。这个曲线我在项目验收会上一定会摆出来让业务方自己选工作点而不是让算法团队拍板。6. 团队与节奏一个可执行的落地建议6.1 第一阶段只做一件事把数据链路跑通如果让我重新开始一个智能制造项目第一阶段的三个月我不会碰模型。目标只有两个一是任选一条产线、一个工位把从传感器到特征库的链路完整打通数据延迟控制在秒级以内二是建立时间对齐的审计机制能随时回答这条记录对应哪件产品。这个阶段最容易犯的错是贪多想一次接入十条线。实际经验是一条线跑通带来的经验价值远大于十条线半通不通。而且链路的设计缺陷在一条线上暴露修复成本极低等到十条线都接进来再发现时间戳方案不对返工量是灾难性的。第一阶段结束时我希望能看到一张实时的数据健康看板各设备的上报延迟分布、缺失率、时间戳偏差、数据量趋势。这张看板是后面所有工作的地基。6.2 第二阶段选一个高频、有标签、影响可量化的场景切入选场景有三个筛选条件缺一不可。高频意味着样本积累快一个月能拿到足够的数据有标签意味着能形成监督信号哪怕是弱标签影响可量化意味着能算出投入产出方便争取后续资源。视觉缺陷检测通常最符合这三条所以大多数项目从这里起步是合理的。如果视觉已经有了我会选设备异常预警因为它同样有数据、有明确的价值口径减少非计划停机。这个阶段要刻意控制范围。我见过的一个失败案例是把缺陷检测 根因分析 参数推荐打包在一起做结果每个都做了一半。正确做法是先做检测检测稳定运行三个月、数据闭环跑起来之后再基于积累的缺陷数据做根因分析因为根因分析需要缺陷样本和对应工艺参数的完整配对这些数据只有检测上线后才有。6.3 人员的最小配置和职责边界一个能跑起来的小团队我认为最少四个人一个懂工艺的工程师负责定义问题和验收标准一个数据工程师负责采集链路和特征存储一个算法工程师负责建模和评估一个偏运维的工程师负责部署和监控。四个角色可以有人兼但职责边界要清楚。最容易出问题的是工艺工程师和算法工程师之间的接口。我的做法是强制要求工艺侧输出一份问题定义文档写清楚判定标准是什么、错误代价怎么算、当前人工方法的水平是多少。没有这份文档算法侧就没法设定合理的目标也没法判断模型是不是真的有用。反过来算法侧要定期给工艺侧讲模型的失败案例让他们知道模型在什么情况下不可靠这比讲精度数字有用得多。最后分享一个我自己一直在用的小习惯每个项目建一个事故簿把每次模型异常、数据异常、误报漏检的排查过程都记下来包括当时怀疑了什么、怎么排除的、最后根因是什么。这个本子在第二个项目里救过我很多次——很多坑是同一类问题的不同变体有记录就能几分钟定位没记录就得重新走一遍弯路。制造业的智能化改造周期长、变量多能积累下来的往往不是模型本身而是这套排查的方法论。