1. 质控与阈值概念
1.1 质量控制Pipeline概述
大家好，欢迎来到这门课。
我叫什么不重要，重要的是我在自动化质控这个领域摸了快十年。从最早的手动跑脚本，到后来搭完整的自动化Pipeline，踩过的坑说多不多，说少也不少。
说到自动化质控Pipeline，你想想看，它本质上是什么？
说白了，就是把原本需要人工盯着看的质量检查步骤，变成一套自动执行的流水线。数据进来，经过一个个检查站，最后输出一份报告——哪项合格，哪项不合格，一目了然。
我刚开始带团队的时候，有位老兄问我：“为什么非得搞个Pipeline？我手动跑几个命令不也一样？”
嗯，当时我是这么回答的：你手动跑，一次两次还行。当你的数据量从几百条变成几百万条，当你的检查项从3个变成30个，你再试试看？
一个典型的自动化质控Pipeline，通常包含这几个阶段：
- 数据采集：从源系统或文件中拉取原始数据
- 数据清洗：处理缺失值、异常格式、重复记录
- 特征提取：计算关键指标，比如均值、标准差、分布特征
- 规则检查：用预设的阈值和规则判断数据质量
- 结果输出：生成通过/失败报告，触发告警或后续动作
我个人习惯把Pipeline的每个阶段比作一条生产线上的质检工位。每个工位都有明确的检查标准，数据流过时，合格就放行，不合格就踢出来。
关键点：没有Pipeline，你就是质检员。有了Pipeline，你变成了设计流水线的工程师。两者的工作量，天差地别。
1.2 阈值定义与作用
好，Pipeline有了，那阈值到底是什么？
阈值的定义很简单——它就是一条分界线。线这边，数据算合格；线那边，数据算异常。
举个例子，你要求某个字段的缺失率不能超过5%。这个“5%”就是阈值。
为什么阈值这么重要？我经历过一个项目，开发兄弟拍脑袋设了个阈值，结果上线第一天，告警风暴直接把群里所有人都炸醒了。你以为数据出问题了？不，是阈值设得太严，正常波动都被当成了异常。
反过来，阈值设太松又会怎样？数据质量烂得一塌糊涂，Pipeline全绿，直到下游模型训练崩了，才发现上游数据早就烂了。
阈值的作用，我归纳为三点：
- 判定基准：给质量对错一个明确的数字分界
- 告警开关：超过阈值触发通知，低于阈值保持静默
- 流程控制：决定Pipeline是否继续往下走，还是中断处理
这三点缺一不可。你想想看，如果没有阈值，你的Pipeline怎么知道什么时候该叫停？什么时候该放行？
阈值按照作用方式，大致可以分为这几类：
| 类型 | 说明 | 常见例子 |
|---|---|---|
| 硬阈值 | 固定的数值界限，不可调整 | 缺失率 < 5% |
| 软阈值 | 可浮动的界限，通常带上下缓冲 | 均值 ± 3σ |
| 动态阈值 | 根据历史数据自动调整 | 月度统计分布更新 |
| 多级阈值 | 分多个等级，不同等级触发不同动作 | 警告(90%)、严重(95%)、致命(99%) |
我在实际项目中遇到最多的坑，就是团队只设了硬阈值，发现数据波动稍微大一点就反复误报。后来改成多级阈值，情况才好转。
避坑指南：我曾经因为阈值设得太死板，导致Pipeline每周误报3次，运维兄弟恨不得顺着网线过来打我。后来我养成了一个习惯——无论是什么指标，先跑两周的历史数据看看真实分布，再决定阈值设在哪儿。这个习惯救了我很多次。
那么，阈值从哪里来？
常见的来源有两种：一是业务规则驱动，比如行业标准规定某个指标不能低于多少；二是数据驱动，通过统计历史数据算出一个合理的范围。
我个人倾向于两者结合。先用业务规则定一个基线，再用历史数据校准。这样既不会脱离实际业务场景，也不会无视数据的真实分布。
小技巧：当你不确定阈值该设多少时，先设一个宽松的值跑起来，持续观察一周。如果完全没有告警，说明可能太松了；如果天天告警，说明阈值太严或者数据本身有问题。这个方法虽然土，但非常实用。
好了，既然提到了阈值的重要性，我们来看看它在Pipeline里到底长什么样。下面这张图展示了Pipeline的完整流程和阈值所处的位置：
从上图可以看得很清楚：阈值是整个Pipeline的「法官」。数据完成特征提取后，阈值在规则检查环节给出判决，决定走通过路径还是失败路径。
为什么阈值选得好不好，直接决定了Pipeline的生死？
因为阈值太主观，Pipeline就是个摆设。阈值太死板，运维团队全员崩溃。阈值没有动态调整机制，数据一换场景就失效。
我个人习惯在Pipeline设计阶段，就把阈值策略作为一等公民来对待。不做规划直接设阈值，就像不看地图直接开车——到了哪儿全靠运气。
好，这一章我们聊了Pipeline的整体结构，也明确了阈值到底是什么、有什么用。下一块内容，我们会深入讨论不同场景下阈值选择的具体方法和实战经验。不过那是后面的事了，先把基础打牢。