2. InterProScan基础知识回顾：数据库与算法简介
开始讲批次偏差之前，我觉得有必要先带大家把InterProScan的内核捋一遍。你想想看，连它用什么库、怎么比对都不清楚，后面讨论偏差从哪来、怎么治，根本就是空中楼阁。
InterProScan本质上是个集成工具。它不自己发明算法，而是把十几个主流蛋白功能数据库和它们的搜索引擎打包在一起，统一输入输出。说白了，你给一条序列，它帮你问一圈“这玩意儿是干啥的”。
2.1 背后的数据库家族
InterPro联盟维护的数据库，我按自己的习惯分成三大类。这样分类，在实际排查问题时会很有用。
| 类别 | 代表数据库 | 核心内容 | 搜索方法 |
|---|---|---|---|
| 序列同源性 | Pfam, SUPERFAMILY, TIGRFAMs | 多序列比对构建的隐马尔可夫模型 | HMMER3 |
| 结构域/模体 | PRINTS, PROSITE Patterns, SMART | 短而保守的氨基酸指纹或正则表达 | fscan, patmatmotifs |
| 蛋白质家族 | CATH-Gene3D, PANTHER | 进化关系与结构分类 | HMMER3 / 专有方法 |
关键认知：
- Pfam是使用率最高的库，但它的模型更新频率可能落后于专业数据库。
- 对短序列或非模式物种，PROSITE Patterns的表现往往比HMM模型更稳定。
- 我建议不要只依赖一个数据库的结果，交叉验证是基本功。
数据库之间不是孤立的。InterPro把这些模型组织成层级关系：一个Entry对应一个蛋白家族，一个Family下面可能挂多个Domain，Domain里又包含各种保守Motif。我见过有人直接拿Pfam Domain结果就下结论，结果漏掉了更上游的Family信息——这种错误最常见于自动化流程。
另外，每个数据库有自己独特的版本号和版本历史。这一点在批次分析时特别重要。你在2022年跑了第一轮，2024年跑了第二轮，结果库版本变了，比对模型更新了——你说这个偏差是蛋白表达差异，还是数据库差异？
⚠ 版本锁定的重要性
我曾经在一个跨年度的项目里发现，两个批次的Pfam匹配率差了12%。排查了两天，最后发现是数据库版本从35.0升级到了35.1，20万个模型参数有微调。自那以后，凡是涉及批次对比的项目，我都会锁定InterProScan版本和数据库版本。
# 锁定版本的推荐做法：创建独立环境并指定数据库版本
# 推荐使用interproscan官方提供的数据库下载脚本抓取特定版本
wget ftp://ftp.ebi.ac.uk/pub/software/unix/iprscan/5/5.60-92.0/alt/interproscan-data-5.60-92.0.tar.gz
tar -xzf interproscan-data-5.60-92.0.tar.gz
# 运行时不使用自动更新
./interproscan.sh --disable-precalc -i input.fasta -o output.gff3
2.2 核心算法：HMMER 与 模式匹配
算法层面，我不打算讲得太深，但你要理解两种搜索范式的根本差别。
HMMER3：这是现在的主力。它用profile隐马尔可夫模型来表示一个蛋白家族。输入的序列跟这个模型比对，算出一个似然分数。HMMER3的核心优势是敏感度高——能抓到序列一致性低于20%的远程同源。代价是什么？计算量大。虽然迭代速度已经比HMMER2快了两个数量级，跑全库搜索还是要花时间的。
💡 我的实践经验
HMMER3的E-value阈值默认是1.0。但实际项目中，我建议对批次间差异分析收紧到0.01。默认值太宽松，会把许多噪音匹配带进来。你想想，几万条序列每一条都带一堆低置信注释，批次间的波动自然就大了。
模式匹配（Pattern Matching）：PROSITE和PRINTS就是这类。它们不是建模型，而是用正则表示式或短指纹。搜索速度极快，但覆盖面窄。遇到序列上有几个氨基酸突变，模式匹配就直接跳过了。它不是真正的“打分”，是非黑即白的命中模式——中了就中了，没中就拉倒。
就是这两种算法的差异，埋下了批次偏差的另一种可能：同一批序列，在不同版本库中因为模式规则的扩充或收缩，匹配数会发生突变。
2.3 InterProScan的工作流
理解了这个流程，你才能判断偏差可能出现在哪个环节。
从图上你能看到，一条序列进了系统，不是直接出一个答案就完了。它要经过预处理——有时候长序列会被切成几个窗口分别跑，然后再合并。这个分割逻辑在不同版本间可能调整过，我踩过这个坑：同样的核糖体大亚基序列，在5.55版里被切成两段跑，在5.60版里整条跑，得到的结果谱完全不一样。
接着进入并行分发。每个成员数据库有自己的算法进程。这意味着什么呢？你跑的是同一台机器，但不同进程打开的是不同版本的数据库文件。如果一个库的文件在跑批A时是v35.0，跑批B时被系统更新成了v35.1——
嗯，这里的问题就出来了。
2.4 命令行与输出格式
很多人只关心参数怎么调，不关心输出结构。但我告诉你，输出解析的差异也能导致“伪偏差”。
# 基础运行命令
./interproscan.sh -i sequences.fasta \
-f GFF3 \
-o results.gff3 \
--cpu 8
# 常用过滤参数
./interproscan.sh -i sequences.fasta \
-f TSV \
--iprlookup \
--goterms \
-pa \
--seqtype p
--iprlookup参数，把匹配结果映射到InterPro Entry。如果你批A加了这参数，批B没加，输出的字段数量差两列，下游解析逻辑就错了。这不是生物学偏差，这是流程偏差。
输出格式方面我建议统一用GFF3。它结构严谨，适合后续用工具如bedtools来按位置合并比对结果。TSV虽然可读性好，但多级嵌套的注释数据它表达不了。
💡 输出规范技巧
每个批次跑完之后，立刻对输出做一次字段完整性校验。我写过一个简单的awk脚本，检查行数、检查InterPro Accession格式、检查对应GO条目数。只要发现一行格式异常，我就把这部分序列标记出来重新跑。
好了，基础知识就回顾到这里。数据库、算法、工作流、命令行，这四个块是理解后续所有偏差分析的前提。玩转InterProScan，从理解这些组件开始。下一步，就是实战了。