RNN 退役了吗——它和 Transformer 在生信中的真实分工
RNN 退役了吗——它和 Transformer 在生信中的真实分工
在前面两篇文章中,我们分别讨论了 RNN/LSTM 为什么适合生物序列数据(开篇),以及它们在细胞轨迹推断中的角色(代表工作)。
这个批次的最后一节要回答一个很多人心里其实一直在想的问题:Transformer 不是已经赢了吗?RNN 还有存在的必要吗?
这个问题之所以值得认真回答,是因为它背后藏着一个更一般性的思考:在生物信息学中,技术演进的逻辑到底是什么——是”新的替代旧的”,还是”不同的解决不同的”?
先看 Transformer 做到了什么
Transformer 在生物信息学中的影响是真实的,不需要回避。
蛋白质语言模型是最成功的案例。ESM-2、ProtTrans 等模型在大规模蛋白质序列数据库上预训练后,可以在零样本条件下预测残基接触图、蛋白质功能、突变效应。这些模型不需要多序列比对(MSA),不需要标注数据,只靠一条氨基酸序列就能给出有生物学意义的预测。
DNA 语言模型——DNABERT、Nucleotide Transformer——在转录因子结合位点预测、剪接位点识别等任务上展示了比传统 CNN 更强的泛化能力。
单细胞基础模型——scGPT、scBERT——将基因表达谱视为”文本”,通过自注意力机制学习基因之间的共表达关系,在细胞类型注释和轨迹推断上表现出色。
AlphaFold2 虽然不完全是一个标准的 Transformer,但其核心的 Evoformer 模块大量使用了注意力机制,本质上借用了 Transformer 的全局建模能力。
这些成就不应该被低估。Transformer 的自注意力机制允许序列中任意两个位置之间直接通信,不受距离限制——这在需要全局上下文建模的任务上是一个巨大的优势。
但”赢了”不等于”替代了所有人”
说”Transformer 取代了 RNN”过于简化了。实际情况更像这样:不同的架构解决不同类型的计算挑战,Transformer 在某些任务上更强,但 RNN 在另一些场景下仍然有不可替代的优势。
具体来说,有几个 RNN/LSTM 仍然有竞争力的场景。
第一,时间序列和流式数据。 RNN 天然按时间步处理输入,维护一个累积的内部状态。当数据是按时间顺序到达的(比如实时监测的基因表达数据、在线的药物响应跟踪),RNN 可以逐个时间步处理,不需要把所有数据一次性加载到内存中。Transformer 的自注意力机制需要看到完整的序列才能计算任意位置之间的关系——这意味着它不适合真正的流式场景。
第二,计算资源受限。 标准 Transformer 的计算复杂度随序列长度呈平方增长(O(N²))。处理一个 1000 个残基的蛋白质序列还行,但处理一条几十万个碱基的 DNA 片段,内存和计算时间都会成为瓶颈。RNN 的计算复杂度是线性的(O(N)),在长序列场景下有明显的效率优势。
第三,某些序列模式天然适配 RNN。 在上一篇中讨论的轨迹推断就是一个例子——细胞状态的时间依赖关系和 RNN 的”逐步积累记忆”机制天然匹配。在剪接位点识别、基因表达时间序列预测等任务上,BiLSTM 的表现并不比 Transformer 差多少,但训练成本低得多。
第四,作为混合架构的组件。 很多当前最先进的模型并不是纯粹的 Transformer 或纯粹的 RNN。DanQ(2016)是 CNN+RNN,一些蛋白质功能预测模型是 Transformer+RNN 的混合。在这些架构中,RNN 承担的是 Transformer 不擅长的那部分工作——比如逐步处理、维护序列的顺序状态。
真正的分界线在哪里
如果要把 Transformer 和 RNN 的分工画一条线,大概可以这样描述:
Transformer 擅长的是”全局关系建模”。 它能同时看到序列中所有位置之间的关系,不需要按顺序处理。这使它在需要理解”整个序列的全局模式”的任务上非常强——比如蛋白质的整体结构预测、DNA 序列的整体功能注释、基因表达谱的整体模式识别。
RNN 擅长的是”顺序依赖建模”。 它按顺序处理输入,逐步积累上下文信息。这使它在需要理解”时间上的先后关系”或”流式处理”的任务上非常强——比如时间序列预测、在线学习、实时数据处理。
打个比方: Transformer 像一个站在山顶上的人,可以同时看到整个山谷的全貌。RNN 像一个在山谷中行走的人,一步一步地感受地形的变化。山顶的人视野广但感受不到脚下的细节,行走的人视野窄但对每一步的变化都很敏感。
在生物信息学中,有些问题需要”山顶视角”(全局模式),有些需要”行走视角”(顺序变化),有些两者都需要。
一个更诚实的图景
当前生物信息学中的真实图景是这样的:
Transformer 在”大模型”方向上已经确立了优势。 蛋白质语言模型、DNA 语言模型、单细胞基础模型——这些方向都在向更大规模、更强泛化能力的方向发展,而 Transformer 的并行计算能力和全局建模能力使它成为大模型的首选架构。
RNN/LSTM 在”专用工具”方向上仍然活跃。 针对特定任务的小型模型——比如特定疾病的基因表达时间序列预测、特定场景下的剪接位点识别、资源受限环境下的在线推断——RNN 仍然是一个成本效益很好的选择。
混合架构正在成为趋势。 很多研究不再纠结”Transformer 还是 RNN”,而是把两者结合在一起——Transformer 负责全局上下文,RNN 负责顺序依赖,CNN 负责局部模式。这种”按需组合”的思路,可能比”一种架构打天下”更务实。
一些新架构也在出现。 状态空间模型(SSM,如 Mamba)试图在保持线性计算复杂度的同时获得 Transformer 级别的全局建模能力。如果这类架构成熟,可能会进一步模糊 Transformer 和 RNN 之间的边界。
对不同读者意味着什么
如果你正在选择技术路线: 不要从”哪种架构最流行”出发,而要从”你的问题最核心的计算需求是什么”出发。如果问题是全局模式识别——用 Transformer。如果是时间序列或顺序依赖——用 RNN。如果两者都需要——用混合架构。如果数据量小、计算资源有限——可能一个简单的 BiLSTM 比一个大 Transformer 更实用。
如果你在跟踪技术趋势: Transformer 的热度确实更高,但这主要是因为大模型的方向恰好是 Transformer 最擅长的。技术演进不是一条直线——不是”旧的被淘汰”,而是”不同工具在不同场景下各自找到位置”。CNN 在 2016 年是热点,RNN 在 2018 年是热点,Transformer 在 2020 年之后成为热点。下一个热点可能是 SSM,可能是混合架构,也可能是一种今天还没出现的新范式。但无论什么成为热点,旧的架构不太可能完全消失——它们会在最适合自己的场景中继续工作。
如果你对这个系列感兴趣: 这三篇文章(开篇→代表工作→收束)讨论的核心不是”哪种架构更好”,而是一个更根本的问题:在生物信息学中,理解问题的计算特性比追逐技术潮流更重要。 生物数据有顺序性(→RNN 适合)、有空间结构(→CNN/GNN 适合)、有全局依赖(→Transformer 适合)、有时序动态(→RNN/SSM 适合)、有生成需求(→扩散模型适合)。不同的问题需要不同的工具,而好的研究者需要理解每种工具的原理和边界,才能做出好的选择。
系列小结
本批次讨论了 RNN/LSTM 在生物信息学中的角色:
- 开篇:为什么生物序列数据天然适合循环网络——顺序性是 RNN 最擅长处理的计算特征
- 代表工作:细胞轨迹推断中的循环网络——RNA velocity、最优传输、LSTM 时间序列建模的互补关系
- 收束:RNN 与 Transformer 的真实分工——不是替代关系,是不同场景下的不同选择
下一个批次将讨论生成式模型(GAN/扩散模型)在蛋白质设计和药物分子生成中的应用。
参考文献
Hochreiter, S., & Schmidhuber, J. (1997). Long short-term memory. Neural Computation, 9(8), 1735-1780.
Vaswani, A., et al. (2017). Attention is all you need. Advances in Neural Information Processing Systems, 30.
Lin, Z., et al. (2023). Evolutionary-scale prediction of atomic-level protein structure with a language model. Science, 379(6637), 1123-1130. (ESM-2)
Jumper, J., et al. (2021). Highly accurate protein structure prediction with AlphaFold. Nature, 596(7873), 583-589.
Quang, D., & Xie, X. (2016). DanQ: a hybrid convolutional and recurrent deep neural network for quantifying the function of DNA sequences. Nucleic Acids Research, 44(11), e107.
Gu, A., & Dao, T. (2023). Mamba: Linear-time sequence modeling with selective state spaces. arXiv preprint.