📚 课程目录第3章偏差的定义与分类

3. 偏差的定义与分类

说到偏差，很多人第一反应就是“出问题了”。

其实，在生物信息学审计里，偏差是个中性词。它只是描述一个实际情况与预期之间的差异。我做了这些年审计，见过太多人一听到“偏差”就紧张得不行，恨不得把所有偏差都定性成重大缺陷。这种做法，说实话，反而容易掩盖真正的问题。

今天我们就来把偏差的类型掰开揉碎了讲清楚。

一、先搞清楚“偏差”到底是什么

官方定义我就不照本宣科了。用我的话说，偏差就是“该怎么做”和“实际怎么做了”之间的差距。

比如你的生信分析流程规定必须用GATK Best Practices做变异检测，结果某个项目用了FreeBayes。这就是偏差。

再比如SOP要求每次运行都要做质控，结果有一次跳过了。这也是偏差。

关键在于：偏差本身不可怕，可怕的是没人发现、没人记录、没人纠正。

我的习惯：每接手一个新项目，我会先翻翻历史偏差记录。如果记录里一片空白，我反而要警惕——要么是记录制度形同虚设，要么是团队根本没有识别偏差的能力。这两种情况，都比几个偏差本身严重得多。

二、偏差的分类框架：两条轴

我个人习惯把偏差的分类看成一张二维表。一条轴是“可预测性”，另一条轴是“影响程度”。

三、第一条轴：计划内 vs 计划外偏差

这条轴很多人会忽视，但它直接影响后续CAPA启动的急迫性。

3.1 计划内偏差

说白了，就是你提前知道会有偏差，并且制定了处理方案。

典型场景：某个试剂批次停产，需要更换供应商。你提前做了验证，写了偏差申请，批准备案。
特点：有预案、有审批、风险可控。
审计重点：审核记录是否完整，处理方案是否合理。

注意：计划内偏差不等于“理所当然”。我对团队的要求是——即使你提前知道要跑偏，也要正式记录。口头同意是审计的红线，千万不要碰。

3.2 计划外偏差

这个就好理解了：突然发生的、没有提前预判的情况。

典型场景：服务器突然宕机导致分析中断，某个样本的测序数据量低于质控阈值。
特点：突发、需要紧急响应、影响评估是关键。
审计重点：响应速度、补救措施、根本原因分析。

我曾经遇到过一家公司，一年报了几百个计划外偏差，但仔细一看，有超过一半都是同一个问题反复出现——测序仪的液流系统故障。这就不是真正意义上的“计划外”了。而是设备管理和预防性维护出了问题。嗯，这里要特别注意。

四、第二条轴：关键 vs 主要 vs 次要偏差

这条轴决定的是“这件事到底有多严重”。不同公司对这三个等级的定义可能略有不同，但大逻辑是一致的。

等级	定义	常见例子（生信领域）	处理要求
关键偏差	直接影响数据完整性、患者安全或合规性	分析流程关键步骤被跳过且未发现；数据被错误地覆盖或删除；结果报告依据了错误的分析版本	立即启动CAPA，召回受影响的结果，全面根因调查
主要偏差	可能影响部分数据质量或流程效率，但不造成系统性风险	使用的参考基因组版本与SOP不一致但经核实结果不受影响；某一步的质控指标略低于阈值	启动CAPA，评估影响范围，制定纠正措施
次要偏差	对数据质量和流程影响极小，多为操作或文档问题	分析日志中一条警告信息未记录；记录的运行时间与实际有几分钟误差	记录偏差，现场纠正即可，可不启动正式CAPA

避坑指南：我曾经见过一个团队，把所有偏差都写成“次要偏差”，以为这样审计风险就小了。结果审计师一看就发现问题了——关键偏差被降级处理，这意味着整个偏差管理体系形同虚设。那次的整改可把大家折腾得不轻。记住：分级不是为了“大事化小”，而是为了把资源用在最该用的地方。

五、按对象分类：数据完整性、流程、系统偏差

这是我在实际操作中最常用的分类方式。它直接告诉你：到底是什么东西出了偏差。

5.1 数据完整性偏差

生信人的命根子。数据一旦出了问题，后面的所有分析都是垃圾。

典型表现：
- FASTQ文件中序列和碱基质量信息不匹配
- BAM文件索引丢失或损坏
- metadata（如样本编号、性别信息）与原始记录不一致
- 版本控制混乱导致使用了错误的数据集

我的一个经验：对于数据完整性偏差，一定要追溯到底。不要只看表面现象。比如有一次我们发现某个样本的性别与临床记录不符，看起来就是个metadata错误。结果追下去发现是样本标签贴错，从取样环节就错了。这种偏差，级别立刻从“主要”拉到了“关键”。

5.2 流程偏差

指操作过程没有严格按照标准作业程序（SOP）执行。

典型表现：
- 跳过了某个质控步骤
- 使用了与SOP规定不同的参数组合
- 运行顺序调整（比如本应BWA在前，结果先做了GATK的步骤）
- 多人合作时交接记录不完整

为什么流程偏差要单独分类？因为流程是可控的。你想想看，流程偏差往往反映出培训不到位、SOP写得不清、或者监督机制缺失。这些问题，通过改进制度是可以彻底解决的。

5.3 系统偏差

这类偏差和人的操作无关，是“系统的锅”。但别以为系统偏差就可以不管。

典型表现：
- 服务器负载过高导致分析任务被意外终止
- 存储空间不足导致重要输出文件写入不完整
- 软件版本更新后，旧版本的pipeline出现兼容性问题
- 配置文件权限错误导致脚本无法读取正确参数

系统偏差的根因分析往往需要IT团队和生信团队一起做。我曾经处理过一个案例，某个分析任务总是每小时崩溃一次，一开始以为是人操作问题。后来查了三个月才发现是cron job和一个后台进程冲突了。这种偏差，不追到根因，永远别想真正解决。

# 一个常见系统偏差的日志示例
[ERROR] 2025-06-15 14:23:45,671 main run_pipeline.py:87
Process killed: Out of memory (exit code -9)
Current step: variant_calling (gatk4)
Peak memory usage: 112.7 GB / 128.0 GB allocated

# 这不是操作错误，而是系统配置不合理
# 需要检查资源分配策略

小结：偏差的分类不是为了写报告时填个表格，而是为了指导你接下来怎么处理。计划内/计划外交给不同流程，关键/主要/次要交给不同级别的响应，数据/流程/系统类型的偏差需要不同专业背景的人去分析。分得清楚，才能处理得明白。

六、实际应用小技巧

最后分享一个我一直在用的方法：

日常记录阶段：先按“对象”分类（数据/流程/系统），因为判断起来最快
初步评估阶段：再按“影响程度”给严重级别（关键/主要/次要）
制定CAPA阶段：最后看“可预测性”，决定是走计划内修正还是启动紧急调查

这样分层下来，头脑会很清晰，不会乱。好了，这就是偏差分类的全部内容。记住一句话：分类是为了更好地下判断，不是为了分类而分类。