4、根因分析基本框架：问题定义、数据采集、假设验证、根本原因定位
多组学质控失败，说白了就是数据"不对劲"。但具体哪儿不对劲，为什么不对劲，你得有一套系统化的打法去拆解。我做了这么多年数据分析，见过太多次"拍脑袋猜原因"然后绕一大圈又回到原点的案例。后来我养成一个习惯——不管多急，都按一个固定框架来走。
这个框架就四个环节：问题定义 → 数据采集 → 假设验证 → 根本原因定位。一环扣一环，缺一个都不稳。
核心原则：别跳步。每次有人说"我觉得就是样本污染"，我都让他们先走完前两步再说。很多"直觉"在数据面前根本站不住脚。
4.1 问题定义——把"不对劲"变成一句话
问题定得清楚，分析就成功了一半。很多人一上来就说"质控没过"，这不算问题定义，这只是个状态描述。真正的问题定义要包含：什么数据、什么指标、偏离了多少、在哪儿发生的。
拿我去年处理的一个项目举例。当时合作方说"RNA-seq质控失败"，我追问了三轮才拿到有效信息：
- 什么数据：某批次的肿瘤组织FFPE样本，共24例
- 什么指标：RNA完整性评分（RIN值）低于阈值
- 偏离了多少：RIN中位数只有4.2，预期≥7.0
- 在哪儿发生的：集中在该批次的后12例样本
你看，这样才叫"问题定义"。反过来，如果只说"质控没过"，你连该查哪个方向都摸不着头脑。
我的习惯：每次接手分析前，先用一句话把问题写在便签上贴在屏幕边。写不出来，说明还没想透。
问题定义阶段要交付的是一份问题陈述表：
| 维度 | 问题要素 | 示例 |
|---|---|---|
| 数据对象 | 哪批样本、哪种组学 | FFPE肿瘤组织RNA-seq |
| 偏离指标 | 哪个QC指标异常 | RIN值、比对率、dup率 |
| 偏离程度 | 数值/统计量 | RIN 4.2 vs 阈值7.0 |
| 时空范围 | 批次/跑样时间/位置 | 后12例，Day 2上机 |
4.2 数据采集——别拍脑袋，先翻数据
问题定义清楚了，下一步就是"找证据"。数据采集不是简单地把QC报告拉出来看一眼，而是有目标地收集可能与问题相关的所有数据层。
我个人习惯把数据分成三个层次去采集：
- 样本层：样本类型、保存条件、提取时间、浓度、纯度（A260/A280）
- 实验层：建库试剂盒批次、PCR循环数、文库浓度、片段分布
- 测序层：上机时间、Flowcell号、Cluster密度、Q30、比对率
为什么要分三层？因为根因可能藏在任何一层里。我曾经遇到一个案例，QC提示比对率异常低，大家第一反应都是"样本有问题"。结果我翻了实验层数据才发现，是某批次连接酶的效价下降，文库接头连接效率不够导致的。
注意：数据采集阶段最容易犯的错是"够用就行"。多组学数据之间的关联复杂，你少采一个维度，可能就漏掉了真正的根因。宁多勿少。
数据采集阶段我建议用结构化的清单来管理，避免漏项：
# 数据采集清单（示例）
样本层:
- 样本类型 / 保存方式 / 冻融次数
- 提取试剂盒 / 批次号
- 浓度 (ng/µL) / A260/A280 / A260/A230
实验层:
- 建库试剂盒 / 批次号 / 版本
- 投入量 (ng) / PCR 循环数
- 文库浓度 (nM) / 插入片段峰值 (bp)
测序层:
- 测序平台 / 试剂版本 / Flowcell ID
- Cluster 密度 (K/mm²) / 通过率 (%)
- Q30 (%) / 比对率 (%) / 重复率 (%)4.3 假设验证——一个一个排除，别一次猜多个
数据拿到手了，开始找原因。这里面有个常见的坑——一次提了好几个假设，然后一股脑去验证，结果哪个都没验证透。
我建议的做法是：每次只提一个假设，设计一个验证方案，拿到结果后再决定下一步。这样逻辑链是清晰的，不会把自己绕进去。
假设验证的核心是"形成对比"：
- 对照组 vs 问题组：同一批次通过质控的样本 vs 没通过的样本
- 时间前后对比：问题发生前 vs 问题发生后
- 试剂批次对比：正常批次 vs 可疑批次
举个例子，还是上面那个RIN值偏低的案例。我当时列的假设和验证方案是这样的：
| 假设 | 验证方案 | 数据来源 |
|---|---|---|
| 样本在提取后放置过久 | 比较提取时间与上机时间的间隔 | 样本跟踪表 |
| 提取试剂盒有批次问题 | 对比不同批次试剂盒的RIN分布 | 提取记录 + QC报表 |
| 样品保存温度异常 | 查看冻存管转移记录、冰箱温度日志 | 温度监控系统 |
你看，每个假设都可以用已有的数据来验证，不需要额外做实验。这也是为什么数据采集阶段要尽量全面的原因——省得后面再去补数据，浪费时间。
关键原则：假设验证的结果只有两种——"支持"或"不支持"，没有"好像支持"。如果数据模棱两可，就说明验证方案设计得不够敏感，需要调整而不是强行下结论。
4.4 根本原因定位——找到那个"如果改掉就能解决问题"的点
假设验证走完一轮或几轮之后，你手上应该有几条"被排除的假设"和一条"剩余假设"。这时候要做的是把剩余假设收敛到根因。
我自己对"根因"的定义很简单：如果把这个因素改了，同样的质控失败不会在同样的条件下复现。换句话说，根因是那个"可干预的杠杆点"。
定位根因时要确认三点：
- 可重现性：同条件下是否反复出现？
- 方向性：改变该因素是否导致QC指标朝预期方向变化？
- 排他性：其他可能因素是否已经被排除？
说实话，第三步排他性最难。因为你永远不可能穷举所有因素。我自己的做法是：把可能性最高的3-5个假设都验证完，如果只剩下一个没被排除，那就把它当作根因来处理。然后在后续的批次中持续监控，看看修复后问题是否真的消失了。
小技巧：每次定位完根因，我都会写一段"回顾笔记"，记录当时的数据证据链。几个月后再看这些笔记，经常能发现当初遗漏的线索。这也帮我不断优化自己的分析框架。
最后，根因定位的输出要形成一份根因结论书，包含：
- 问题回顾（一句话）
- 关键证据（哪个数据、哪个对比）
- 根因陈述（什么因素、在哪个环节、如何导致的）
- 修复建议（改什么、怎么改、谁来改）
根因找到了，不等于问题就解决了。但有了清晰的问题定义、完整的数据采集、严谨的假设验证和精准的根因定位，你就有了让所有人都信服的结论，接下来的修复和改进才有真正的依据。