曲线分析系统领域知识扩展

与主笔记的关系

• 主笔记：[00 曲线分析系统领域知识](/00 曲线分析系统领域知识/)
• 本笔记：补充业务上下文、模型训练经验、查询优化经验和现场交付经验
• 原始来源：两篇已归档来源笔记

1. 数据对象与业务上下文

曲线分析要真正产生业务价值，必须把曲线放回业务上下文里看，而不是只看一组时序点。

常见需要一起关联的对象包括：

• 工件、车身或产品，作为质量追溯主键
• 设备、工位或轴，作为曲线来源和工艺位置
• 程序、配方或工艺参数，作为判定曲线是否合理的上下文
• 结果数据，包含最终扭矩、角度、压力、状态和判定
• 过程曲线，作为复盘和异常分析依据
• 特征数据，作为规则和模型输入

这意味着，曲线能不能被解释，往往先取决于业务主键是否齐全。

2. 典型应用场景

这类知识适合沉淀为通用的业务用途说明：

• 单件质量追溯
• 工位或设备稳定性分析
• 拧紧异常模式识别
• 工艺参数优化
• 面向报表和看板的质量统计

3. 样本选择与类别不平衡

在压装、螺柱焊和类似场景里，异常样本通常远少于正常样本，所以模型训练不能默认数据天然均衡。

比较值得保留的经验是：

• 训练前要先看正负样本比例
• 需要考虑正类权重
• 可以使用负样本采样或过采样
• 验证集划分要保留业务代表性
• 模型效果不能只看指标，还要看解释性

4. 分类粒度要服从业务解释

曲线或焊接数据可以按设备、枪号、焊点、工位等维度建模，但粒度不能只按算法方便来定。

更重要的是：

• 现场人员能不能理解这个粒度
• 现场人员能不能据此处理问题
• 这个粒度是否符合交付口径

也就是说，分类粒度是技术选择，更是交付选择。

5. 查询性能要从业务语义优化

曲线查询性能问题不应只靠数据库调参来解决，先要明确页面到底需要什么数据。

比较典型的业务语义是：

• 某模型最后一条记录
• 某工件的曲线详情
• 某设备或某工位的近期曲线

先把查询目标缩小，再决定数据集、索引和返回结构，通常比直接做笼统优化更有效。

6. 结果上报要支持诊断闭环

诊断结果不应该只停留在 OK / NOK。

更完整的结果上报通常应包含：

• 诊断批次
• 对象
• 时间范围
• TP / FP / FN / TN
• 准确率
• 异常明细
• 后续处理状态

这样才能把结果真正闭环到分析、标注、修正和复盘。

7. 现场部署适合清单化

现场问题经常不是算法问题，而是部署条件没有准备好。

建议单独形成检查清单，至少覆盖：

• 网络
• Node-RED 配置
• 数据库连接
• 定时任务
• IP 和网卡
• 远程工具准备

8. 适用范围说明

这组方法论不仅能用于拧紧，也能迁移到压装、螺柱焊以及其他以过程曲线为主的质量分析场景。

如果主笔记要保持“拧紧”为主线，这里可以作为扩展理解，不必改动主定义。