RNAcentral — 六千万条非编码 RNA，四成是 rRNA

INFOBOX

项	值
全名	RNAcentral（非编码 RNA 统一序列库）
维护方	RNAcentral Consortium，EBI 托管
规模（官方索引 2026-10-15）	60,054,521 条序列
专家数据库	56 个
物种数	1,136,166 个
统一标识	URS（如 URS0000000001）
去重键	MD5（序列哈希）
主要类型	rRNA 39.6% / tRNA 24.8% / lncRNA 8.6% / circRNA 8.0%
带 QC 警告	14,725,607 条（24.5%）
许可	CC0
最大的坑	去重是按「序列相同」，不是按「同一个基因」——同一基因的不同片段是两个 URS

---

§0 E-E-A-T 信任声明与免责声明

我们是谁：千方病案医学编辑部，为中文医学 AI 社区整理可训练数据集的结构化说明。

本条目怎么来的：总数取自 2026-10-15 的 EBI Search indexInfos（官方声明值 60,054,521，索引 57 GB）。类型、数据库、物种、QC 分布取自同一索引的 facet（查询词 RNA，命中 58,782,024 条，约占全库 97.9%）。字段语义取自 api/v1/rna/URS0000000001 与其 xrefs 子资源的实际返回。

我们不做什么：本条目不提供二级结构预测、不评估任何序列的生物学正确性、不做 benchmark。§7.7 的口径矩阵只对比不同接口对"同一个数"的算法差异。

已知局限：

• facet 的查询词是 RNA，命中 58,782,024 条，不是全部 6,005 万条。 差额约 127 万条是描述里不含 “RNA” 三个字母的记录（多为 Gene 类型）。所以 §4.2 的比例是「97.9% 子集」的比例，不是全库精确比例。
• 官方索引数 60,054,521 与 facet 查询的 58,782,024 是两个不同口径，见 §7.7。
• 本篇没有下载 FASTA 全量（数十 GB），所有序列级结论都来自 API 与索引 facet。

---

§1 数据集概览

§1.0 📌 30 秒速览

RNAcentral 做的事情，一句话能说完：给每一个非编码 RNA 分子发一个身份证号（URS），然后把 56 个数据库里它对得上的所有编号都挂在它名下。

规模（官方索引 2026-10-15）：

指标	数值
序列总数	60,054,521
专家数据库	56
物种数	1,136,166
带 QC 警告	14,725,607（24.5%）

三个必须先知道的形状问题：

1. 它不产生序列，只做归并。60,054,521 条序列里，36,117,224 条（60.1%）直接来自 ENA，10,506,033 条（17.5%）来自 SILVA。这两个库贡献了 77.6%。RNAcentral 的价值不在"数据多"，在"把同一分子的十几个编号合成一个"。
2. rRNA 占 39.6%、tRNA 占 24.8%——近三分之二是核糖体 RNA 和转运 RNA。这两个类群之所以多，不是因为研究多，而是因为环境测序（16S/18S 扩增子）产出了海量片段。“6,000 万条非编码 RNA"听起来像"非编码 RNA 研究很繁荣”，实际是"微生物群落测序做了很多"。
3. 物种分布极度长尾。uncultured bacterium（未培养细菌）一个"物种"占 10,010,738 条（17.0%），加上 metagenome 与各种 uncultured 类群，环境样本贡献了大半。人类只有 2,141,462 条（3.6%）。做人类 lncRNA 研究时，这些环境序列全是噪声。

如果你要查"某个 lncRNA 在哪些数据库里有记录"、“这个 miRNA 的序列在其他物种里保守吗”、“这批小 RNA 测序结果比对到哪个已知家族”，RNAcentral 是唯一的选择；如果你要"这个 RNA 在肝脏里表达多少"，它一条都给不了（那要去 GTEx / Expression Atlas）。

§1.1 技术摘要

维度	值
序列总数	60,054,521
专家数据库	56
物种数	1,136,166
RNA 类型数	31 类（SO 对齐）
去重方式	MD5（序列哈希）
标识体系	URS（稳定、不复用）
序列格式	FASTA（FTP）/ JSON（API）
二级结构	由 Rfam 提供（has_secondary_structure：22,529,080 条 true）
基因组坐标	仅 578,451 条有（1.0%）
GO 注释	仅 12,539 条有（0.02%）
访问方式	REST API（分页）+ FTP 全量

「有基因组坐标的只有 1%」这个数字特别重要。绝大多数 RNAcentral 记录是孤立的序列片段——它们来自环境测序，没有基因组上下文。做"这个 lncRNA 在基因组上哪个位置"这类分析时，可用记录会掉到 1%。

§1.2 战略价值

第一，它解决了非编码 RNA 领域的"标识混乱"问题。 同一个 miRNA，在 miRBase 叫 hsa-miR-21-5p，在 Ensembl 叫 ENST00000384902，在 RefSeq 叫 NR_029493，在 ENA 里是一串 accession。做跨库整合时，这四套编号的映射关系是最大的工程负担。 RNAcentral 把这件事做完了——你查一次 URS，拿到全部编号。

第二，MD5 去重让"这个序列存在多少次"变成可查的。 一条 URS 的 count_distinct_organisms 告诉你它在多少个物种里出现。这是跨物种保守性的直接代理指标——不需要做多序列比对，直接看数。

第三，它覆盖了临床小 RNA 的完整谱系。 本站已收的医学数据集里，miRNA 与 lncRNA 一直是零散覆盖。RNAcentral 把 miRBase（83,642 条）、MirGeneDB（58,700 条）、TarBase（3,254 条实验验证的 miRNA-靶点）、LncBase（1,337 条）、NONCODE（644,595 条）、LNCipedia（136,869 条）全部收进来了。做肿瘤 miRNA 标志物研究时，这是查"这个 miRNA 是什么、在哪里被验证过"的入口。

第四，它的 QC 警告体系本身有价值。 qc_warning 有 7 类，包括 possible_orf（可能是编码序列）、Possible contamination（可能被污染）、Incomplete sequence（序列不完整）。这给了你一个"这条序列能不能信"的第一道筛子——而不是所有序列都一样可信。

§1.3 同类资源横向对比

资源	定位	与 RNAcentral 的关系
RNAcentral（本条）	ncRNA 统一序列索引	唯一做跨库归并的
ENA / GenBank / DDBJ（INSDC）	原始序列存档	上游最大来源（60.1%）；RNAcentral 从 ENA 导入
Rfam	RNA 家族与二级结构	提供二级结构与家族分类；7,409,783 条记录来自 Rfam
SILVA	rRNA 专用库	上游（17.5%），rRNA 的权威来源
miRBase	miRNA 权威库	上游；已停止更新，数据被 RNAcentral 固化
NONCODE / LNCipedia / LncBook	lncRNA 目录	上游；人类 lncRNA 的主要来源
GtRNAdb	tRNA 专用库	上游（242,314 条），tRNA 的权威来源
Ensembl / GENCODE	基因组注释	上游；提供基因组坐标与基因结构
RNAcentral 的邻居：Expression Atlas	表达数据	互补：RNAcentral 说"序列存在"，Expression Atlas 说"表达多少"
Rfam 单独的网站	家族层面	RNAcentral 是序列层面，Rfam 是家族层面

「miRBase 已停止更新」这一行值得展开：miRBase 从 2019 年 v22 之后基本停更，而 miRNA 领域的新发现仍在继续。这意味着做 miRNA 研究时，RNAcentral 里的 miRBase 部分是"2020 年前的知识快照"，不能当"当前最新的 miRNA 清单"用。新的 miRNA 要去 MirGeneDB 或直接从文献里找。

§1.4 版本时间轴

时间	事件
2013	RNAcentral 项目启动，第一篇 Nucleic Acids Research 论文（D590）
2014	首次公开发布，整合 10 余个专家库
2015	引入 URS 标识体系与 MD5 去重
2018	第二篇 NAR 论文（D335），专家库扩展到 20+
2020	引入 LitScan（文献挖掘的 RNA 提及）
2022	引入 QC 警告体系（ORF 检测、污染检测）
2026-10-12	索引更新日
2026-10-15	60,054,521 条（本篇引用的索引版本）

从 2013 到 2026 十三年，规模从约 700 万涨到 6,000 万，涨了 8 倍多。增长主要来自环境测序与长读长测序的普及——不是来自"发现了更多 ncRNA 类型"。这个增长曲线的形状，说明这个库的重心在微生物生态，不在人类功能基因组。

§1.5 典型应用场景

场景一：跨库编号映射。 手上有一批 miRBase ID，要转成 Ensembl 或 RefSeq 的编号做下游分析。这是 RNAcentral 最高频的用法——一次 URS 查询拿到全部映射。

场景二：小 RNA 测序的注释。 测序得到一批短序列，要先判断"这是已知 miRNA / tRNA 片段 / rRNA 降解片段 / 还是新序列"。RNAcentral 的 MD5 索引让这一步可以精确查表，不用做比对。

场景三：跨物种保守性筛查。 用 count_distinct_organisms 直接排序，找出在多个物种中出现的序列——这是保守性的粗筛，成本极低。

场景四：lncRNA 目录整合。 人类 lncRNA 分散在 NONCODE、LNCipedia、LncBook、GENCODE、PLncDB 等库，彼此重叠但不完全一致。RNAcentral 把它们归并后，能看出"这个 lncRNA 被几个库收录了"——收录数越多，可信度通常越高。

场景五：rRNA 污染检测。 做 RNA-seq 时，大量 reads 会落在 rRNA 上。用 RNAcentral 的 rRNA 子集（23,778,768 条）建索引，可以做污染率估计。

---

§2 非编码 RNA 序列库的科学前提

§2.1 一条 RNAcentral 记录到底是什么

一条 URS 记录的语义，可以概括为：

一个特定的核苷酸序列，以及它在 56 个专家库中的所有对应编号。

注意这个定义里没有"基因"这个概念。这是理解 RNAcentral 的第一道门：

概念	RNAcentral 的处理
分子（molecule）	不建实体，只有序列
基因（gene）	部分记录（364,364 条 Gene 类型）有，其余没有
序列（sequence）	唯一实体，用 MD5 定义
片段（fragment）	单独的 URS——一个 200 bp 的 16S 片段与完整的 1,500 bp 16S 是两个 URS

所以"同一个基因"在 RNAcentral 里可能是几个、几十个甚至几百个 URS。一个 lncRNA 的不同剪接产物、不同加工中间体、不同测序片段，全部是独立记录。

这决定了一件事：RNAcentral 的"6,000 万条"绝不能读成"6,000 万个非编码 RNA 基因"。真实基因数远小于此，可能小两个数量级。

§2.2 为什么需要 MD5 去重

在 RNAcentral 之前，非编码 RNA 的重复是灾难性的：

• 同一个 tRNA，在 GtRNAdb 里有、在 Ensembl 里有、在 ENA 里有、在 Modomics 里有——四处各一个编号。
• 同一段 16S rRNA，在 SILVA 里有、在 Greengenes 里有、在 RDP 里有、在 ENA 里有——四套分类体系。
• 同一个 lncRNA，在 NONCODE、LNCipedia、LncBook、GENCODE 里各一个 ID，彼此映射不全。

后果：任何"统计非编码 RNA 数量"的尝试都会严重高估；任何"跨库合并"的分析都要先解决映射，而这个映射表本身就是个研究项目。

RNAcentral 的做法很粗暴但有效：

1. 从每个专家库拿序列。
2. 去除非字母字符（如 gaps）、统一大小写（U→T 或 T→U）。
3. 算 MD5。
4. 同 MD5 的所有来源合并为一个 URS。

这个做法的优点：不需要任何本体对齐、不需要人工判断"这两个 ID 是不是同一个东西"，纯机械、可复现、零歧义。

这个做法的缺点：它认为"序列相同 = 同一个分子"。这在多数情况下成立，但有两个反例：

• 同一基因的不同物种同源序列，序列可能相同（尤其在保守区），会被合并成一个 URS，导致 count_distinct_organisms 很大。
• 序列相同但基因组位置不同的两个拷贝（如两个相同的 tRNA 基因），会被合并成一个 URS——丢失了"有两个拷贝"这个信息。

这两个反例是理解 count_distinct_organisms 字段的关键：它统计的是"这个序列在多少个物种里出现"，不是"这个序列有多少个拷贝"。前者反映保守性，后者反映基因家族大小。两者不能混用。

§2.3 从序列到功能：中间缺了什么

RNAcentral 给你序列，但从序列到功能之间有几层缺失：

层次	RNAcentral 有吗	缺了要怎么办
序列	✅ 全部	—
二级结构	⚠️ 部分（22,529,080 条有，由 Rfam 提供）	用 Rfam / ViennaRNA 自己算
基因组坐标	❌ 只有 1.0%（578,451 条）	用 Ensembl / UCSC 比对
表达量	❌ 完全没有	用 Expression Atlas / GTEx
靶点	⚠️ 少量（TarBase 3,254 条实验验证）	用 TargetScan / miRDB 预测
功能注释	⚠️ 极少（GO 只有 12,539 条 = 0.02%）	靠文献或同源推断
疾病关联	❌ 没有	用 MalaCards（109,052 条记录里有交叉引用）

这张表说明：RNAcentral 是"序列层"的索引，不是"功能层"的注释库。它的价值在于"查得到这个序列是谁"，不在于"这个序列干什么"。

§2.4 五十六个专家库是怎么分工的

56 个专家库按贡献量排序（前 20）：

专家库	记录数	占比	专长
ENA	36,117,224	60.1%	INSDC 原始序列
SILVA	10,506,033	17.5%	rRNA（16S/18S/23S/28S）
Rfam	7,409,783	12.3%	RNA 家族与二级结构
Ensembl	2,991,462	5.0%	脊椎动物基因组注释
circAtlas	2,646,680	4.4%	环形 RNA
CIRCpedia	2,529,821	4.2%	环形 RNA
MGnify	1,134,643	1.9%	宏基因组
Ensembl Metazoa	1,025,713	1.7%	后生动物
Greengenes	1,013,030	1.7%	16S 参考数据库
PLncDB	979,777	1.6%	植物 lncRNA
GeneCards	678,558	1.1%	人类基因卡片
NONCODE	644,595	1.1%	lncRNA
PirBase	480,881	0.8%	piRNA
Ensembl/GENCODE	346,600	0.6%	人类/小鼠注释
LncBook	332,023	0.6%	lncRNA
Expression Atlas	327,253	0.5%	表达数据
GtRNAdb	242,314	0.4%	tRNA
RefSeq	137,938	0.2%	NCBI 参考序列
LNCipedia	136,869	0.2%	人类 lncRNA
MIRBASE	83,642	0.1%	miRNA

这张表的读法：

• 前两名（ENA + SILVA）占 77.6%，说明这个库的绝对主体是环境测序与 rRNA。
• circRNA 类（circAtlas + CIRCpedia）合计 5,176,501 条（8.6%），比 lncRNA 还多。这是因为环形 RNA 的预测算法（从 RNA-seq 的 back-splice reads 里找）产出量极大，而验证量极小。
• miRBase 只有 83,642 条，是"miRNA 只有几千个基因"这个事实的反映——miRNA 的记录数少，不代表不重要。

注意这些数相加远超 60,054,521，因为一条 URS 可以来自多个专家库。所以"占比"这一列的含义是"该库贡献的来源记录占全部来源记录的比"，不是"占 URS 总数的比"。这是读这类多来源库时最容易搞错的一点。

§2.5 为什么序列层索引对医学 AI 重要

因为临床小 RNA 检测的报告格式，本质上是个映射问题。

一个真实的临床流程：患者做 miRNA 表达谱检测，报告上写"miR-21-5p 上调 3.2 倍"。这句话要变成可计算的，需要：

1. miR-21-5p 对应哪个序列？（→ miRBase / MirGeneDB）
2. 这个序列在别的数据库里叫什么？（→ RNAcentral 的 xrefs）
3. 有没有实验验证的靶点？（→ TarBase，3,254 条）
4. 这个 miRNA 在哪些物种保守？（→ count_distinct_organisms）

这四步里，第 1、2、4 步都由 RNAcentral 一次查询解决。 没有它，做多中心 miRNA 数据整合时，光统一命名就要耗掉整个项目一半的时间。

这就是它被一个医学数据集站收录的理由：它不是疾病数据，但它是把零散的临床小 RNA 数据变成可计算格式的那一层胶水。

§2.6 质量标准的边界：RNAcentral 保证什么、不保证什么

保证	不保证
序列与其 MD5 一致	序列本身是否正确（测序错误照样收）
URS 稳定且不复用	序列有完整的基因组上下文
标出 QC 警告	有警告的序列不能用（多数仍可用）
提供跨库映射	映射是 100% 完整（有些库的 ID 没被收录）
提供 Rfam 家族归属	家族归属一定正确

最需要强调的一条是「URS 稳定且不复用」。这意味着：

• 已发布的 URS 永远指向同一条序列，不会因为版本更新而改变含义。
• 但 URS 可以被标记为 is_active: false——当发现同一序列有两个 URS（早期去重漏洞）、或序列被撤回时。

这个设计对可复现性极其重要。对比 GBIF（每日快照，记录可变）与 NeuroVault（活库，记录可改），RNAcentral 的 URS 是三者里最稳固的标识——你三年前在论文里写的 URS 现在还能查到同一条序列。

---

§3 数据规格与通道抉择

§3.0 三条通道

通道	地址	适合	限制
API 单条	rnacentral.org/api/v1/rna/<URS>/?format=json	查少量 URS	一次一条，字段有限（只给链接，不给展开）
API 分页 + 过滤	rnacentral.org/api/v1/rna/?format=json&page_size=N&<filter>	推荐：按条件筛	过滤只支持少数几个字段（见 §6.5 坑点 1）
FTP 全量	ftp.ebi.ac.uk/pub/databases/RNAcentral/current_release/	要全量 FASTA	数十 GB；按 RNA 类型分文件

API 的一个重要设计特点：单条查询返回的 xrefs 与 publications 是子资源的 URL，不是嵌在返回里的数据。要看交叉引用，必须再发一次请求（/rna/<URS>/xrefs?format=json）。这意味着一万条记录的完整展开，需要两万次请求。 批量场景下应该走 FTP，不走 API。

§3.1 字段地图

/api/v1/rna/<URS>/ 返回的字段（实测 15 个）：

字段	说明
rnacentral_id	URS 标识
md5	序列哈希（去重主键）
sequence	序列本体
length	长度
rna_type	RNA 类型（SO 对齐）
description	自由文本描述
is_active	是否活跃
count_distinct_organisms	出现在多少个物种
distinct_databases	被多少个专家库收录
distinct_organisms	子资源 URL（物种清单要另请求）
xrefs	子资源 URL（交叉引用要另请求）
publications	子资源 URL（文献要另请求）
url	自身的 API 地址

distinct_databases 是个被低估的字段。它是"这个序列被多少个独立数据库收录"的计数，可以作为可信度的粗代理：

• 只被 1 个库收录 → 可能只有单一来源，可信度一般
• 被 5+ 个库收录 → 多个独立团队都确认过，可信度高
• 被 10+ 个库收录 → 通常是经典分子（如人类 28S rRNA）

注意：distinct_databases 与"专家库数 56"不是同量纲。多数记录只来自 1-3 个库，56 是理论上限，不是平均水平。

§3.2 下载预算

目标	体积	说明
单条记录 JSON	约 700 B	不含 xrefs
单条完整（含 xrefs）	约 3-10 KB	需 2-3 次请求
全部元数据（API 分页）	约 60-100 GB	6,000 万条 × 平均 1-1.5 KB
FASTA 全量	数十 GB	按类型分文件
rRNA 子集 FASTA	十几 GB	最大的单类
人类子集（2,141,462 条）	约 1-3 GB	最常用的切片

结论：不要试图用 API 拉全量（会跑几周）。要全量就走 FTP；要特定切片就走 API 过滤（taxid=9606 这类是支持的）。

§3.3 版本机制

RNAcentral 有明确的发布节奏，这与前面几个库不同：

• FTP 上按 current_release/ 与历史 release_XX/ 组织，每个发布有编号。
• 官方索引有 Last modification date（2026-10-15）与 Update date（2026-10-12）。
• URS 跨版本稳定，不会因为重新发布而改变。

这是本篇里最值得称赞的版本设计：URS 稳定 + 发布编号 + FTP 归档。做可复现实验时，只要写"RNAcentral release XX"，三年后还能拿到完全相同的数据。

对比 NeuroVault（无版本号，活库）与 Complex Portal（只有 current 目录），RNAcentral 的可复现性设计是三者里最好的。

§3.4 技术栈与溯源链

56 个专家库（ENA / SILVA / Rfam / Ensembl / miRBase / ...）
   ↓ 定期导入
序列清洗（去非字母、统一大小写）
   ↓
MD5 计算 → 同 MD5 合并 → 分配 URS
   ↓
Rfam 比对（二级结构 + 家族）→ QC 检查（ORF / 污染 / 完整性）
   ↓
[FTP FASTA] [API JSON] [EBI Search 索引]
   ↓
下游：Expression Atlas / 小 RNA 测序注释 / 跨库映射 / 本文

这条链里最脆弱的一环是「MD5 合并」：如果两个生物学上不同的分子恰好序列相同（如同一基因的两个拷贝），它们会被合并，这个错误在后续所有版本里都会保留（因为 URS 不复用）。RNAcentral 承认这一点，用 distinct_organisms 字段让用户自己判断。

---

§4 记录结构与字段字典

§4.1 一条记录的解剖

URS0000000001 的完整返回：

{
  "rnacentral_id": "URS0000000001",
  "md5": "6bba097c8c39ed9a0fdf02273ee1c79a",
  "sequence": "AUUGAACGCUGGCGGCAGGCCUAACACAUGCAAGUCGAGCGGUAGAGAGAAGCUUGCUUCUCUUGAGAGCGGCGGACGGGUGAGUAAUGCCUAGGAAUCUGCCUGGUAGUGGGGGAUAACGCUCGGAAACGGACGCUAAUACCGCAUACGUCCUACGGGAGAAAGCAGGGGACCUUCGGGCCUUGCGCUAUCAGAUGAGC",
  "length": 200,
  "rna_type": "rRNA",
  "description": "uncultured bacterium rRNA",
  "is_active": true,
  "count_distinct_organisms": ...,
  "distinct_databases": ...,
  "xrefs": "https://rnacentral.org/api/v1/rna/URS0000000001/xrefs?format=json",
  "publications": "https://rnacentral.org/api/v1/rna/URS0000000001/publications?format=json"
}

这条记录本身就是一个教学样本：

• length: 200 且 rna_type: rRNA——这是一段 200 bp 的 16S rRNA 片段，不是完整的 1,500 bp。这正是"片段也是独立 URS"的直接证据。
• description: uncultured bacterium rRNA——来自环境样本，物种未培养。
• xrefs 展开后有 11 条（见 §4.6），来自 ENA 等多个库。

§4.2 RNA 类型的真实分布

全库 31 类（facet 查询 RNA，命中 58,782,024 条）：

RNA 类型	记录数	占比
rRNA	23,778,768	40.5%
tRNA	14,922,509	25.4%
lncRNA	5,189,289	8.8%
circRNA	4,826,506	8.2%
misc RNA	3,784,159	6.4%
ncRNA	1,425,277	2.4%
pre miRNA	773,327	1.3%
snoRNA	679,415	1.2%
SRP RNA	590,483	1.0%
snRNA	514,709	0.9%
piRNA	506,633	0.9%
tmRNA	369,629	0.6%
Gene	364,364	0.6%
RNase P RNA	279,724	0.5%
hammerhead ribozyme	238,768	0.4%
miRNA	193,243	0.3%
other	132,044	0.2%
antisense RNA	75,727	0.1%
siRNA	44,689	0.1%
ribozyme	33,093	0.1%
Y RNA	29,371	0.0%
scaRNA	12,272	0.0%
RNase MRP RNA	4,307	0.0%
precursor RNA	4,141	0.0%
vault RNA	3,088	0.0%
telomerase RNA	1,898	0.0%
guide RNA	1,866	0.0%
scRNA	1,225	0.0%
autocatalytically spliced intron	1,140	0.0%
rasiRNA	325	0.0%
sgRNA	35	0.0%

这张表最需要读出来的三件事：

• rRNA + tRNA = 65.9%。这两个类群决定了整个库的性质——它是"环境微生物测序的副产品集合"，不是"非编码 RNA 功能目录"。
• miRNA 只有 193,243 条（0.3%），但它是临床价值最高的那一类。这种"数量占比"与"临床重要性"的严重不匹配，是使用这个库时最容易产生的错觉。
• circRNA 4,826,506 条（8.2%）超过了 lncRNA。这是近年环形 RNA 预测算法爆发的结果，但验证过的极少——circAtlas 与 CIRCpedia 都是基于计算的预测库。

注意这里的 rRNA 是 40.5%，而 INFOBOX 里写的是 39.6%。两个数的差异来自分母不同：39.6% 用官方总数 60,054,521 做分母，40.5% 用 facet 命中数 58,782,024 做分母。见 §7.7 的口径矩阵。

§4.3 物种分布：环境样本主导

全库 1,136,166 个物种，前几名（facet TAXONOMY）：

物种	记录数	占比
uncultured bacterium	10,010,738	17.0%
Homo sapiens 人类	2,141,462	3.6%
metagenome	1,672,445	2.8%
Sus scrofa 猪	1,206,251	2.1%
soil metagenome	1,017,228	1.7%
Mus musculus 小鼠	886,728	1.5%
uncultured eukaryote	481,690	0.8%
uncultured organism	369,051	0.6%
Triticum aestivum 小麦	306,831	0.5%
Escherichia coli 大肠杆菌	260,548	0.4%
uncultured prokaryote	216,846	0.4%
uncultured archaeon	197,342	0.3%
Pseudomonas sp.	118,534	0.2%
uncultured fungus	115,362	0.2%
Acanthosepion pharaonis 鱿鱼	93,525	0.2%
Salmonella enterica 沙门氏菌	93,516	0.2%
Klebsiella pneumoniae 肺炎克雷伯菌	84,826	0.1%
Staphylococcus aureus 金黄色葡萄球菌	80,978	0.1%
uncultured soil bacterium	63,368	0.1%

四个观察：

• “uncultured + metagenome” 类合计超过 1,400 万条（24%+）。这些记录的"物种"字段本质上是"未知"——uncultured bacterium 不是一个物种，是一句"我不知道这是什么菌"。
• 人类占 3.6%，已经算高了。原因是人类 lncRNA 与 circRNA 目录（NONCODE、LNCipedia、GENCODE）都汇入了。
• 猪（Sus scrofa）1,206,251 条超过小鼠，这个反常现象的原因很可能是某个大型测序项目（如猪的转录组或某个农业项目）的批量提交。这是"数据量反映项目投入，不反映生物学重要性"的又一个例子。
• Acanthosepion pharaonis（一种鱿鱼）93,525 条——同样来自某个特定项目的批量提交。

所以「RNAcentral 有 113 万物种」这句话，实际含义是「有 113 万个物种标签」，其中几十万个标签是 uncultured / sp. / metagenome 这类"未定种"。 真正有分类学意义的物种数远小于此。

§4.4 人类侧的类型构成

单独看 Homo sapiens（2,248,745 条 facet 命中，含少量亚种）：

RNA 类型	记录数	占人类比例
circRNA	1,326,375	59.0%
lncRNA	604,753	26.9%
Gene	128,340	5.7%
piRNA	109,362	4.9%
ncRNA	27,036	1.2%
rRNA	18,375	0.8%
SRP RNA	12,511	0.6%
miRNA	4,596	0.2%
pre miRNA	4,212	0.2%
tRNA	4,041	0.2%
misc RNA	2,894	0.1%
snoRNA	2,729	0.1%
snRNA	2,375	0.1%
Y RNA	812	0.0%
antisense RNA	253	0.0%
其余 13 类	合计约 300	0.0%

人类侧专家库来源（前 15）：

专家库	记录数
CIRCpedia	848,889
GeneCards	784,479
circAtlas	599,010
LncBook	409,743
Ensembl	242,866
NONCODE	240,724
Ensembl/GENCODE	232,438
LNCipedia	191,367
Expression Atlas	167,957
ENA	166,540
MalaCards	117,641
PirBase	109,379
RefSeq	27,379
RFAM	23,315
HGNC	17,445

这张表最重要的一条是「circRNA 占人类的 59%」：

• 这不是因为人类有 130 万个环形 RNA 基因，而是因为环形 RNA 的预测算法每个样本能报出几千到几万个候选。
• circAtlas 与 CIRCpedia 都是计算预测库，把它们汇入后，人类侧的 circRNA 数量就爆发了。
• 真正经过实验验证的 circRNA，数量在几百到几千量级——比 132 万小三个数量级。

所以「人类有 132 万个 circRNA」这句话，正确的说法是「人类有 132 万条被算法预测为环形的序列」。 这个区别在做任何下游分析时都必须记住。

另一个观察是 MalaCards 贡献了 117,641 条。MalaCards 是疾病数据库，它的记录汇入说明 RNAcentral 的"疾病关联"信息其实是通过 MalaCards 的 xref 间接提供的——但 RNAcentral 自己不建疾病字段。

§4.5 QC 警告：四分之一带问题

qc_warning 有 7 类（全库 facet）：

警告	记录数	含义
No Rfam problems detected	39,206,656	无问题
Incomplete sequence	13,657,430	序列不完整（片段）
possible_orf_stopfree	3,092,654	可能存在无终止密码子的开放阅读框
missing_rfam_match	1,580,448	未匹配到 Rfam 家族
possible_orf_tcode	1,281,907	可能存在使用替代遗传密码的 ORF
possible_orf	699,682	可能存在 ORF（疑似编码序列）
Possible contamination	142,551	可能被污染

qc_warning_found 的汇总：True 14,725,607 / False 9,326,737（这是 rRNA 子集的统计，全库比例见下）。

四个必须理解的警告：

• Incomplete sequence 占最大头（1,365 万条）。这是片段化测序的必然结果——一条 200 bp 的 16S 片段，相对完整的 1,500 bp 就是"不完整"。这不是错误，是数据本质。 但做"全长序列分析"时必须排除。
• possible_orf 三类合计 507 万条。这说明相当一部分"非编码 RNA"其实可能编码短肽。近年 micropeptide / sORF 研究的热点正来自这里。做 ncRNA 功能研究时，这三类警告是必须筛掉的。
• Possible contamination 14 万条。这个比例很小（0.2%），但污染序列如果混入训练集，会造成严重的假阳性。
• missing_rfam_match 158 万条。这说明它们不属于任何已知 RNA 家族——可能是新家族，也可能是噪声。这是发现新 ncRNA 家族的候选池。

这张表的实用价值在于：它给了你一个「按用途选子集」的现成标准。做全长分析 → 排除 Incomplete；做 ncRNA 功能 → 排除 possible_orf 三类；做家族归属 → 排除 missing_rfam_match。

§4.6 交叉引用：一条记录能展开成十一行

URS0000000001 的 xrefs 返回 count: 11，每条的结构是：

{
  "upi": "URS0000000001",
  "database": "ENA",
  "is_active": true,
  "first_seen": "2026-09-23 00:00:00",
  "last_seen": "2026-09-23 00:00:00",
  "taxid": 77133,
  "accession": {
    "id": "GU794138.1:1..200:rRNA",
    "parent_ac": "GU794138",
    "seq_version": 1,
    "feature_start": 1,
    "feature_end": 200,
    "feature_name": "rRNA",
    "description": "uncultured bacterium partial 16S ribosomal RNA",
    "rna_type": "rRNA",
    "species": "uncultured bacterium"
  }
}

这个结构里有四个宝藏字段：

• first_seen / last_seen——这条记录在该专家库里第一次和最后一次被看到的时间。last_seen 老旧的记录，说明源库可能已把它删了（RNAcentral 只是没跟着删）。这是判断记录新鲜度的唯一字段。
• feature_start / feature_end——这条序列在源记录里的起止位置。1..200 说明它是从 GU794138 的第 1 到 200 位截出来的。这个字段让你能回溯到原始记录的完整上下文。
• parent_ac——父记录号。一条长序列可以被切成几十条 RNAcentral 记录，parent_ac 是把它们重新拼起来的钥匙。
• accession.id 的格式 GU794138.1:1..200:rRNA——这是 RNAcentral 的"复合 accession"，包含了父记录 + 版本 + 坐标 + 特征类型。这个格式很啰嗦，但信息完整。

parent_ac 这个字段解释了「为什么一个基因有几百个 URS」：一个 1,500 bp 的 16S 全长序列被切成 200 bp 的片段，每个片段一个 URS，但它们共享同一个 parent_ac。做去重时，按 parent_ac 合并比按 URS 合并更接近"分子"概念。

顺着 parent_ac 还能做一件更有用的事：重建原始记录。 如果你拿到了一批 URS，想还原它们各自的完整来源，正确的步骤是：

1. 从每个 URS 的 xrefs 里取出 parent_ac 与 feature_start / feature_end。
2. 按 parent_ac 分组，同一父记录下的所有 URS 归到一组。
3. 用 feature_start 排序，就能看出这些片段在父序列上的排列顺序——是首尾相接的完整覆盖，还是大量重叠，还是只覆盖了一小段。
4. 如果某个父记录下的一批片段首尾相接且无重叠，说明有人把一条长序列系统性地切碎提交了；如果片段大量重叠，说明是多次独立测序的产物。

这个检查在质控上很实用：一条 16S 全长序列如果被 30 个独立研究各测了一段，会形成 30 个 URS、30 条 xrefs，但它们共享一个 parent_ac。你会以为"这个序列很常见"，实际上是"这个序列被研究了很多次"。 这两件事在生物学上含义完全不同，而 parent_ac 是唯一能把它们分开的字段。

---

§5 检索、抽样与泄漏分析

§5.0 四条可用的检索路径

一、按 URS 精确取

curl -s "https://rnacentral.org/api/v1/rna/URS0000000001/?format=json" | jq .

二、按 MD5 精确取（比对到已知序列时最常用）

curl -s "https://rnacentral.org/api/v1/rna/?format=json&md5=6bba097c8c39ed9a0fdf02273ee1c79a" | jq '.results[] | {rnacentral_id, rna_type, length}'

md5 过滤是精确命中（实测返回 1 条），这是 RNAcentral API 里唯一一个"精确查询"入口。做小 RNA 测序注释时，算出每条 read 的 MD5 然后逐个查，比做序列比对快几个数量级——前提是 read 与参考序列完全一致。

三、按分类学筛

curl -s "https://rnacentral.org/api/v1/rna/?format=json&page_size=100&taxid=9606" | jq '.results[].rnacentral_id'

四、按 RNA 类型筛

curl -s "https://rnacentral.org/api/v1/rna/?format=json&page_size=100&rna_type=rRNA" | jq '.results | length'

五、拿交叉引用

curl -s "https://rnacentral.org/api/v1/rna/URS0000000001/xrefs?format=json" | jq '.count, .results[].database'

坑点提醒：rna_type=rRNA 这类过滤在 API 上是有效的，但 rna_type 的取值必须是小写且与内部编码一致（rRNA 而不是 rrna，misc_RNA 而不是 misc RNA）。facet 里显示的是 misc RNA（带空格），API 里要用 misc_RNA（带下划线）——这是最容易出错的一处。

§5.1 抽样策略：先按物种切，不要先按类型切

6,000 万条里，做任何研究都要先切。推荐的切法顺序：

顺序	切法	理由
1	按 taxid 切	把 113 万"物种"降到 1 个物种，噪声立即消失
2	按 rna_type 切	去掉 rRNA / tRNA 这些占 66% 但不关心的类
3	按 QC 警告切	去掉 possible_orf / Possible contamination
4	按 is_active 切	去掉已废弃记录
5	按 distinct_databases 排序	优先用多库共识的

为什么"先按物种"而不是"先按类型"：

• 先按类型（如取全部 lncRNA 5,189,289 条），里面混着几十个物种的 lncRNA，跨物种的序列不能混在一个训练集里。
• 先按物种（如人类 2,141,462 条），再取 lncRNA（604,753 条），得到的是干净的人类 lncRNA 集。

§5.2 四类真实泄漏，按危害排序

第一类：同源序列跨侧（最严重）

RNAcentral 的 MD5 去重是按序列完全相同，但不同物种的同源序列只是相似、不完全相同。如果按记录随机划分，训练集里的人类 tRNA 与测试集里的小鼠 tRNA 高度相似，模型学到的是"tRNA 的保守结构"而不是"物种特异性"。

正确做法：按 Rfam 家族分组——同一家族的序列整组进训练或整组进测试。

第二类：同 parent_ac 的片段跨侧（隐蔽）

一个 1,500 bp 的 16S 被切成 10 个 200 bp 片段，10 个 URS 共享同一个 parent_ac。按 URS 随机划分，这 10 个片段会跨侧。更糟的是它们互为子串——模型如果在训练集见过前半段，测试集的后半段就是"送分题"。

正确做法：按 parent_ac 分组，或直接按"序列是否互为子串"做去重。

第三类：circRNA 预测重叠（中等）

circAtlas 与 CIRCpedia 是两个独立的预测算法，它们对同一个 back-splice junction 会各报一个 circRNA。如果按记录划分，同一个真实 circRNA 会在两个库里各出现一次，跨侧。

正确做法：按 back-splice 坐标（如果拿得到）或按序列 MD5 去重后再划分。

第四类：类型标签泄漏（做类型预测时）

description 字段里直接写着类型（如 uncultured bacterium rRNA）。如果任务是"预测这条序列是哪种 RNA"，把 description 当特征就是直接泄漏。

正确做法：类型预测任务的输入只能是序列本身，description、rna_type、xrefs 全部排除。

§5.3 结构泄漏：从元数据本身推断出的信息

length 泄漏类型。tRNA 通常 70-90 nt、miRNA 约 22 nt、rRNA 几百到几千 nt。光看长度就能猜对大部分类型。

md5 泄漏来源。如果两个记录的 MD5 前缀相同（哈希碰撞前几位），说明序列高度相似。

count_distinct_organisms 泄漏保守性。这个字段本身就是"保守性"的代理，做保守性预测时不能当输入。

distinct_databases 泄漏知名度。被多库收录的序列通常是"经典分子"，模型能靠这个认出"这是 tRNA"。

处置：做序列层面的任务时，只用 sequence 作为输入，其余字段全部排除或作为评估分层依据。

§5.4 一个不该做的划分：按 RNA 类型切

看似合理（“用 rRNA 训练，预测 tRNA”），实际引入严重偏倚：

• 不同 RNA 类型的长度分布完全不重叠（miRNA 22 nt vs rRNA 数千 nt），模型学到的是长度阈值，不是序列模式。
• 不同类型的碱基组成差异巨大（tRNA 有大量修饰位点对应的保守 motif，miRNA 有 seed 区）。
• 结果：准确率很高，但学到的不是"RNA 是什么"，而是"它有多长"。

如果确实要测跨类型泛化，正确做法是：在同一长度区间内跨类型切（如都是 60-100 nt 的 tRNA vs snoRNA vs SRP RNA），强迫模型学序列而非长度。

---

§6 AI 就绪指南

§6.1 最小可用 Pipeline

# 1. 从 FTP 拿人类子集（不要用 API 拉全量）
#    先看 current_release 目录结构
curl -s "https://ftp.ebi.ac.uk/pub/databases/RNAcentral/current_release/" | grep -o 'href="[^"]*"'

# 2. 或者用 API 按 taxid 分页（适合几千到几万条）
for p in $(seq 1 20); do
  curl -s "https://rnacentral.org/api/v1/rna/?format=json&page_size=100&page=$p&taxid=9606" \
    > "human_$p.json"
done

import json, glob

def load_human(paths):
    rows = []
    for f in paths:
        for r in json.load(open(f))['results']:
            rows.append({
                'urs':    r['rnacentral_id'],
                'md5':    r['md5'],
                'seq':    r['sequence'].upper().replace('U', 'T'),
                'len':    r['length'],
                'type':   r['rna_type'],
                'desc':   r['description'],
                'active': r['is_active'],
            })
    return rows

# 关键：序列统一成 DNA 字母表（T 而非 U），否则同一条序列会有两种表示

replace('U','T') 这一行是必做的。RNAcentral 的序列用 U，但下游工具（比对器、k-mer 统计）多数期望 T。不统一会导致同一序列被当成两条。

§6.2 构建训练样本

任务一：RNA 类型分类（序列 → 31 类）

# 输入：仅 sequence
# 标签：rna_type
# 划分：GroupKFold by Rfam family（不是随机）
# 注意：长度分布差异太大，必须做长度分层抽样，否则模型学的是长度

任务二：家族归属预测（序列 → Rfam 家族）

# 输入：sequence
# 标签：从 xrefs 里的 RFAM 记录取 family
# 只有 7,409,783 条有 Rfam 归属，其余要排除

任务三：编码潜力判别（序列 → 是否 possible_orf）

# 输入：sequence
# 标签：是否带 possible_orf / possible_orf_stopfree / possible_orf_tcode 警告
# 这个任务有实际价值：它能帮你筛出"伪非编码"序列

三个任务共同的坑：必须按 parent_ac 或 Rfam 家族分组划分，否则片段互为子串导致泄漏。

§6.3 评价指标

任务	主指标	为什么
类型分类（31 类）	macro-F1 + 每类召回	类别极不平衡（rRNA 4,000 万 vs sgRNA 35）
家族预测	top-1 准确率 + top-5 准确率	家族多（数千），top-5 更实用
编码潜力判别	AUPRC（不是 AUROC）	正例（possible_orf）只占 8%
跨物种泛化	按物种留一交叉验证	唯一能反映真实泛化的设置

必须报告的分层：按 length 分箱。不分层的话，任何模型都会在长序列上表现好、短序列上表现差，而平均值会掩盖这个差异。

§6.4 MLOps：怎么钉住版本

dataset:
  source: RNAcentral
  release: "<从 FTP current_release 目录读取的编号>"
  index_date: "2026-10-15"
  update_date: "2026-10-12"
  counts:
    total: 60054521
    human: 2141462
  filters:
    taxid: 9606
    rna_type: ["lncRNA", "miRNA", "circRNA"]
    exclude_qc: ["possible_orf", "possible_orf_stopfree", "possible_orf_tcode", "Possible contamination"]
    is_active: true
  urs_list: "<写入实际用到的 URS 列表，这是最可靠的锚点>"

urs_list 是这套配置里最关键的一行。因为 URS 跨版本稳定，把用到的 URS 列出来，即使未来 release 变了、记录被标为 inactive，你仍能精确重建当时的数据集。这是 RNAcentral 相比其他活库的最大优势——它给了你一个可以永久引用的锚点。

§6.5 六个坑点

坑点 1：API 的过滤字段有限，且类型名格式不同

• 症状：?rna_type=misc RNA 返回错误，或 ?rna_type=misc_RNA 也不对。
• 原因：API 的 rna_type 取值是内部编码（下划线形式），而 facet 里显示的是可读形式（带空格）。misc RNA ↔ misc_RNA、pre miRNA ↔ pre_miRNA。
• 解决：先 GET /api/v1/rna/?format=json&page_size=1 看实际返回的 rna_type 值，按那个格式传。

坑点 2：单条查询不含 xrefs，要发第二次请求

• 症状：拿到 URS 记录，发现 xrefs 是一个 URL 字符串，不是数组。
• 原因：API 设计是"主资源只给链接，子资源单独取"（RESTful 风格）。
• 解决：批量场景下不要用这种方式——1 万条记录要 2 万次请求。应该走 FTP 的注释文件。

坑点 3：序列用 U 不用 T

• 症状：拿序列去做比对或建 k-mer 索引，结果对不上已知序列。
• 原因：RNAcentral 是 RNA 库，序列里用 U；多数比对工具与参考库期望 DNA 字母表用 T。
• 解决：读入后立即 seq.upper().replace('U','T')，全流程统一用 T。

坑点 4：count_distinct_organisms 不是"拷贝数"

• 症状：用它当"这个 tRNA 基因有多少个拷贝"，得到几万的荒谬数字。
• 原因：这个字段统计的是"这条序列在多少个物种里出现"，不是"在同一个基因组里有多少拷贝"。
• 解决：要做基因家族大小分析，必须用带基因组坐标的记录（只有 1% 有），去 Ensembl/UCSC 里查。

坑点 5：is_active: false 的记录仍可查询

• 症状：查到一个 URS，数据看起来正常，但它是已废弃的。
• 原因：RNAcentral 不删除废弃记录，只把 is_active 置为 false（保持 URS 永久可解析）。facet 里 active: Active 23,946,003 / True 106,341 也显示了这种混杂。
• 解决：所有下游查询都要加 is_active == true 过滤。

坑点 6：description 里混着物种与类型，不能当干净标签

• 症状：想从 description 里抽 RNA 类型，结果 uncultured bacterium rRNA 这种文本解析出错。
• 原因：description 是自由文本，格式不统一（有的是"物种 + 类型"，有的是完整句子）。
• 解决：类型一律用 rna_type 字段（受控词表），description 只用于人读。

§6.6 反模式清单

反模式	为什么错	正确做法
把 6,000 万条当 6,000 万个基因	一个基因可以有几十个 URS（片段）	按 parent_ac 或 MD5 前做分子层去重
用 API 拉全量	6,000 万条 × 2 请求 = 1.2 亿次	走 FTP
按记录随机划分	片段互为子串，泄漏严重	按 parent_ac / Rfam 家族分组
混用 U 和 T	同一序列被当两条	读入即统一为 T
忽略 is_active	废弃记录混入	强制过滤 is_active == true
把 circRNA 数量当真实数量	132 万是人类侧的预测数	只取有实验验证的少量

---

§7 质量评估、DAIMS 与口径交叉核对

§7.1 记录级质量

RNAcentral 的质量控制是本站已收条目里最系统的一个，有七个维度：

维度	字段	判读
序列完整性	qc_warning: Incomplete sequence	1,365 万条带此标记（片段）
编码潜力	possible_orf 三类	507 万条带标记，做 ncRNA 研究要排除
家族归属	missing_rfam_match	158 万条无家族归属
污染	Possible contamination	14 万条
二级结构	has_secondary_structure	22,529,080 条 true
保守结构	has_conserved_structure	23,946,003 条 true
活跃状态	is_active	区分当前/废弃

这套体系的优点：它是"多标签"而不是"单一评分"——一条序列可以同时带"片段"和"可能编码"两个警告，你可以按用途选不同的排除组合。

它的局限：这些检查都是基于序列的机械规则，不能判断"这条序列在生物学上是不是真的"。一条完全没有警告的序列，仍然可能是测序错误、嵌合体或污染——只是它没触发规则。

§7.2 抽样声明：本条目数字的边界

数字类别	来源	边界
60,054,521	EBI Search indexInfos	官方声明值，准确
类型分布（rRNA 40.5% 等）	facet 查询 RNA（命中 58,782,024）	分母是 97.9% 子集，不是全库
物种分布	同上 facet	同上
专家库贡献	同上 facet	同一 URS 可多库贡献，各项相加 > 总数
人类侧 2,248,745	facet 查询 Homo	含少数亚种（neanderthalensis 97 条等）
QC 警告	facet，rRNA 子集的完整分布	rRNA 子集的分布，不能直接外推到全库

最需要注意的一条：专家库贡献的那张表，各项之和远超总数。这不是错误，是"一条序列可来自多个库"的必然结果。看到"ENA 60.1% + SILVA 17.5% + Rfam 12.3% = 89.9%，但还有 56 个库"这种表述时，不要试图让它们加起来等于 100%。

§7.3 三个必须知道的生物学效度问题

第一，"非编码"这个标签在 RNAcentral 里是不可靠的。 507 万条记录带 possible_orf 系列警告，说明相当一部分"ncRNA"可能编码短肽。近年的 micropeptide 研究正是从这个缺口长出来的。做 ncRNA 功能注释时，"不编码"这个前提必须自己验证。

第二，多数记录没有基因组上下文。 只有 1.0%（578,451 条）有基因组坐标。这意味着"这个 lncRNA 的启动子是什么"、"它的剪接位点在哪"这类问题，对 99% 的记录无法回答。

第三，环境序列的分类标签没有生物学意义。 uncultured bacterium（1,001 万条）、metagenome（167 万条）、uncultured eukaryote（48 万条）加起来超过 1,200 万条。这些记录的"物种"字段本质是"未知"。做物种层面的统计时，必须把这些条目单列，不能当物种用。

§7.4 偏倚清单（可核查）

偏倚	证据	影响
测序技术偏倚	rRNA 40.5% + tRNA 25.4%	短读长扩增子测序的产物主导了库
环境样本偏倚	uncultured + metagenome > 24%	微生物组研究的投入反映在数据量上
预测算法偏倚	circRNA 482 万条，多数来自预测库	人类侧 59% 是 circRNA，但验证极少
源库停更偏倚	miRBase 83,642 条，2020 后基本停更	miRNA 部分是"旧知识快照"
片段化偏倚	Incomplete sequence 1,365 万条	大量记录是部分序列，不能做全长分析
物种标签偏倚	猪 120 万条 > 小鼠 88 万条	反映项目投入，不反映生物学重要性

§7.5 数据完整性核查表

动手前的五分钟检查：

• [ ] 序列是否已统一成 T（不是 U）？
• [ ] 是否过滤了 is_active == false？
• [ ] 是否按用途排除了对应 QC 警告（片段 / 编码潜力 / 污染）？
• [ ] 分类学是否排除了 uncultured / metagenome 类标签？
• [ ] 划分是否按 parent_ac 或 Rfam 家族分组？
• [ ] 是否记录了 release 编号与 URS 列表？
• [ ] rna_type 用的是下划线格式还是空格格式？

§7.6 DAIMS 24 项逐项评分

#	维度	判定	说明
1	数据集有唯一标识	✅	URS 稳定、不复用，这是最强项
2	有版本信息	✅	明确 release 编号 + 索引日期
3	有许可声明	✅	CC0
4	有引用规范	✅	NAR 论文 + 每条记录可通过 URS 引用
5	有数据来源说明	✅	xrefs 逐条列出源库与 accession
6	有采集方法说明	✅	从 56 个专家库导入的流程有文档
7	有预处理说明	✅	去重规则（清洗 + MD5）有明确说明
8	有标注规范	✅	SO 本体对齐的 rna_type + Rfam 家族
9	有标注者信息	⚠️	源库有，RNAcentral 层不重复记录
10	有标注一致性	❌	无 inter-annotator agreement
11	缺失值有标记	✅	qc_warning 七类明确标记
12	有数据类型定义	✅	rna_type 受控词表（31 类）
13	有单位说明	✅	长度以 nt 计
14	有样本量说明	✅	官方索引计数 + facet
15	有群体描述	✅	物种分布可查（113 万标签）
16	有划分建议	❌	无
17	有基线	❌	无
18	有评价指标	❌	无
19	有伦理审查	⚠️	不适用个体数据，无显式声明
20	有隐私保护	✅	不涉及
21	有可复现性	✅	release 归档 + URS 永久稳定，最强项
22	有更新机制	✅	定期从 56 库重新导入
23	有联系方式	✅	团队邮箱 + GitHub
24	有多语言/多格式	✅	FASTA + JSON API + FTP 分文件

得分：19 项 ✅ + 3 项 ⚠️ + 2 项 ❌ → 19 + 1.5 = 20.5 / 24 = 85.4%

这是目前已评九篇里的最高分（超过 Complex Portal 79.2%）。主要优势在「标识稳定性」与「可复现性」——URS 不复用这个设计，是数据工程上很硬的一条承诺。失分只在「无划分、无基线、无指标」这三点，而这是所有参考型数据库的通病（它们不是为机器学习造的）。

§7.7 口径交叉核对矩阵（不是模型性能验证）

第一组：总数 vs facet 命中

口径	数值	含义
EBI Search indexInfos	60,054,521	官方声明总数
facet 查询 RNA 的 hitCount	58,782,024	描述中含 “RNA” 的
差额	1,272,497	描述中不含 “RNA” 的记录
facet 查询 sequence 的 hitCount	58,418,969	描述中含 “sequence” 的

这 127 万条差额是什么：多为 Gene 类型（364,364 条）与部分 misc RNA 类记录，它们的 description 是基因名或简短描述，不含 “RNA” 三个字母。

所以 §4.2 的类型分布，严格说是「描述含 RNA 的 5,878 万条」的分布，不是「全部 6,005 万条」的分布。 误差约 2.1%，对结论影响不大，但引用时必须说明。

第二组：rRNA 占比的两种算法

分母	rRNA 占比
官方总数 60,054,521	39.6%
facet 命中 58,782,024	40.5%

两个数都对，只是分母不同。 本篇正文用 40.5%（因为那张表的所有行都来自同一 facet，分母一致才可加），INFOBOX 用 39.6%（因为那是"占全库"的表述）。

第三组：专家库贡献之和 > 100%

项	数值
ENA	36,117,224（60.1%）
SILVA	10,506,033（17.5%）
Rfam	7,409,783（12.3%）
前 20 库相加	约 7,000 万
全库 URS 总数	6,005 万

相加超过总数，是因为一条 URS 可以来自多个库。 这不是数据错误，是多来源归并库的必然特征。任何"各库占比相加必须等于 100%"的期待都是错的。

第四组：active 字段的两个值

facet 显示 active: Active 23,946,003 / True 106,341（在 rRNA 子集里）。这两个值的语义重叠——Active 与 True 都是"活跃"，但存在两个不同的字面值。这是索引层的编码不一致，做筛选时应该用 is_active in (True, 'Active') 而非单一值匹配。

---

§8 生态位与相邻资源

§8.1 RNAcentral 在网络里的位置

原始序列层：ENA / GenBank / DDBJ（INSDC）
   ↓
专题专家库：SILVA（rRNA）/ GtRNAdb（tRNA）/ miRBase（miRNA）/ Rfam（家族）
   ↓
统一索引层：RNAcentral（本条） ←── 唯一的跨库归并
   ↓
功能注释层：Rfam（二级结构）/ Expression Atlas（表达）/ TarBase（靶点）
   ↓
应用：小 RNA 测序注释 / 跨库映射 / 保守性筛查 / 本文

§8.2 与本站已收条目的关系

条目	关系
ENA（#133）	最大上游（60.1%）。ENA 存原始序列，RNAcentral 按 MD5 归并
IMGT（#129）	互补。IMGT 专注免疫相关基因（TCR/BCR/MHC），RNAcentral 覆盖全部 ncRNA
MGI（#126）/ Alliance（#128）	互补。它们给基因与表型，RNAcentral 给非编码转录本的序列
Complex Portal（#135）	无直接重叠，但都涉及"分子机器"。Complex Portal 的复合物常含 RNA 组分（如核糖体），可用 RNAcentral 查 rRNA 序列
GBIF（#134）	结构类比：都是"聚合多来源"的库。GBIF 聚合出现记录，RNAcentral 聚合序列。GBIF 用 occurrenceID 去重（不彻底），RNAcentral 用 MD5 去重（彻底但会误合）
NeuroVault（#136）	无直接关系，但都是"派生/汇总型"资源

与 GBIF 的类比值得展开：两个库的核心问题都是**“如何去重”**，但选择了相反的策略：

• GBIF：靠各机构提交的 occurrenceID，保守（宁可重复也不误合），结果是高估 1-5%。
• RNAcentral：靠 MD5 机械哈希，激进（宁可误合也不重复），结果是同一基因的多拷贝被合并。

两种策略各有代价，而代价的方向相反。这提示一个通用规律：多来源聚合库的去重策略，必然在"假阳性"与"假阴性"之间选一边站。

§8.3 为什么一个"医学数据集站"要收 RNA 序列库

因为临床分子诊断报告里的 RNA 类标志物，需要一层统一的命名底座。

三条具体的链路：

1. 肿瘤 miRNA 标志物。血清 miR-21、miR-155、miR-210 是大量肿瘤研究的候选标志物。不同试剂盒、不同文献用的命名不统一（有 miR-21、hsa-miR-21-5p、MIMAT0000076 三种写法）。RNAcentral 是把这三者对上的地方。
2. 融合基因的转录本。白血病里的 BCR-ABL1 融合，其转录本序列来自两个基因的拼接。这类序列在常规基因注释里查不到，但可能在 RNAcentral 里有一条独立记录。
3. 病原体小 RNA。病毒 miRNA（如 EBV 的 miR-BART 系列）在感染与肿瘤发生中起作用。这类序列分散在病毒学专用库里，RNAcentral 提供了一个统一查询口。

这就是它被收录的理由：它不是疾病数据，但它是把临床 RNA 检测结果翻译成可计算格式的那一层。

---

§9 许可、伦理与合规

§9.1 许可结构

RNAcentral 的数据采用 CC0 1.0：

• ✅ 可商用
• ✅ 可修改、可再分发
• ❌ 无需署名（学术界仍建议引用）

但有一层需要注意：RNAcentral 的数据来自 56 个专家库，各库自己的许可可能不同。 多数 INSDC 与 EBI 系库是开放许可，但个别专家库可能有额外限制（尤其是一些商业机构维护的库）。

处置建议：做商业产品时，对关键切片做一次来源核查——从 xrefs 看这条记录的来源库，确认该库的条款。CC0 是 RNAcentral 对其汇编作品（compilation）的声明，不必然覆盖每个上游库的单条数据。

§9.2 CC0 与上游条款的落差

这与 NeuroVault 的 CC0 问题同类，但机制不同：

库	CC0 声明的问题
NeuroVault	上传者可能无权以 CC0 发布（原始数据有 DUA）
RNAcentral	汇编作品 CC0，但上游单个库的条款可能更严

实务上的判断：RNAcentral 作为 EBI 托管的公共基础设施，其 CC0 声明在学术与多数商业场景下可以信赖。但如果产品涉及专利性用途（如药物靶点专利），建议只使用明确标注 INSDC 来源的记录。

§9.3 病原体序列的双用途边界

RNAcentral 包含病原体序列，且没有访问控制。这涉及"双重用途研究关切"（DURC）：

• 病毒基因组片段、细菌 rRNA（可用于鉴定菌种）
• 这些序列本身是公开的（来自 INSDC），RNAcentral 只是做了索引
• 不构成新的风险，但降低了检索门槛

合规表述：RNAcentral 不含任何受控的病原体数据（如 Select Agent 清单内的高危病原体全基因组），它索引的是已经公开的序列。

§9.4 引用与致谢

用途	建议写法
学术论文	引用 RNAcentral 最新 NAR 论文 + 写明 release 编号 + 列出关键 URS
商业产品	“Non-coding RNA sequences: RNAcentral (CC0), release XX”
模型训练	在 model card 写明 release、taxid 过滤、QC 排除项

§9.5 引用规范

@article{rnacentral,
  title   = {RNAcentral: a comprehensive database of non-coding RNA sequences},
  author  = {RNAcentral Consortium},
  journal = {Nucleic Acids Research},
  note    = {release indexed 2026-10-15; 60,054,521 sequences; accessed 2026-10-23}
}

---

§10 复用边界与跨条目协作手册

§10.1 决策树：什么时候该用 RNAcentral

你要找「某个非编码 RNA 的序列」？
├── 是 → RNAcentral（按 URS 或 MD5 查）
└── 否 → 继续

你要做「跨库编号映射」？
├── 是 → RNAcentral 的 xrefs（唯一一次拿全的方案）
└── 否 → 继续

你要「这个 RNA 表达多少」？
├── 是 → 不要用 RNAcentral，去 Expression Atlas / GTEx
└── 否 → 继续

你要「这个 RNA 的基因组位置」？
├── 是 → 先查 RNAcentral 有没有坐标（只有 1%），没有就去 Ensembl/UCSC
└── 否 → 继续

你要「小 RNA 测序的注释」？
├── 是 → RNAcentral 的 MD5 查表（比比对快）
└── 否 → 用 Rfam 的家族模型

§10.2 与 ENA 的配对（原始序列场景）

ENA 与 RNAcentral 是"原始 vs 归并"的关系：

• ENA 存 INSDC 的原始提交记录（一条 accession 一个条目）。
• RNAcentral 从 ENA 导入后按 MD5 归并（一条 URS 可能对应多条 ENA accession）。

联合使用的正确姿势：

1. 从 RNAcentral 拿到 URS 与它的 xrefs。
2. 从 xrefs 里取 parent_ac（如 GU794138）。
3. 去 ENA 查这个 accession 的完整记录（含全长序列、注释、提交者）。
4. feature_start / feature_end 告诉你这条 RNAcentral 记录是父记录的第几位到第几位。

注意别做反了：不要从 ENA 出发去"找所有 RNAcentral 记录"——ENA 的一个 accession 可能对应几十个 URS（如果它含多个 RNA 特征）。方向应该是 URS → parent_ac → ENA。

§10.3 与 Rfam 的分工（家族场景）

场景	用哪个
要具体序列	RNAcentral
要家族模型（协方差模型）	Rfam
要二级结构	Rfam（RNAcentral 的 has_secondary_structure 就是 Rfam 给的）
要这个序列属于哪个家族	先查 RNAcentral 的 xrefs 里有没有 RFAM 记录
要新家族的发现	Rfam（RNAcentral 的 missing_rfam_match 是候选池）

关键差别：Rfam 是"家族层"的库（几千个家族），RNAcentral 是"序列层"的库（6,000 万条）。 一个家族对应成千上万条序列。两者不是竞争，是不同粒度。

§10.4 许可梯度对照

库	许可	商用	需署名
RNAcentral（本条）	CC0	✅	❌
NeuroVault（#136）	CC0	✅	❌
Complex Portal（#135）	CC BY 4.0	✅	✅
GBIF（#134）	混合（CC0 11.9% / BY 71.2% / NC 16.9%）	⚠️	⚠️
ENA（#133）	依提交者	⚠️	⚠️
MGI（#126）	自定义	⚠️	✅

§10.5 三个"不要做"

1. 不要把 6,000 万条当 6,000 万个非编码 RNA 基因——一个基因可以有几十个片段记录。
2. 不要用 count_distinct_organisms 当拷贝数——它是物种数，不是拷贝数。
3. 不要在没排除 possible_orf 的情况下做 ncRNA 功能研究——507 万条可能编码短肽。

§10.6 一句话总结

RNAcentral 不发现序列，它只做一件事——给 56 个库里的同一个 RNA 分子发一个 URS，然后把所有别名挂在它名下；60,054,521 条序列里 66% 是 rRNA 与 tRNA，真正有临床价值的那一小部分藏在 0.3% 的 miRNA 里。

---

附录 A：本篇数字速查

项	数值	来源
序列总数	60,054,521	EBI Search indexInfos
索引大小	57 GB（61,350,109,192 B）	同上
索引更新时间	2026-10-15	同上
更新日（数据）	2026-10-12	同上
facet 命中（RNA）	58,782,024	facet hitCount
专家数据库	56	facet total
物种数	1,136,166	TAXONOMY facet total
rRNA	23,778,768（40.5% of facet）	facet
tRNA	14,922,509（25.4%）	同上
lncRNA	5,189,289（8.8%）	同上
circRNA	4,826,506（8.2%）	同上
misc RNA	3,784,159（6.4%）	同上
miRNA	193,243（0.3%）	同上
Gene 类型	364,364（0.6%）	同上
有二级结构	22,529,080	facet has_secondary_structure
无二级结构	1,523,264	同上
有基因组坐标	578,451（1.0%）	facet has_genomic_coordinates
无基因组坐标	23,473,893	同上
有 GO 注释	12,539（0.02%）	facet has_go_annotations
有 QC 警告	14,725,607	facet qc_warning_found
Incomplete sequence	13,657,430	facet qc_warning
possible_orf（三类合计）	5,074,243	同上
Possible contamination	142,551	同上
missing_rfam_match	1,580,448	同上
人类（Homo 查询）	2,248,745	facet
人类 circRNA	1,326,375（59.0%）	同上
人类 lncRNA	604,753（26.9%）	同上
uncultured bacterium	10,010,738（17.0%）	TAXONOMY facet
最大专家库 ENA	36,117,224（60.1%）	expert_db facet
SILVA	10,506,033（17.5%）	同上
Rfam	7,409,783（12.3%）	同上
miRBase	83,642	同上
TarBase	3,254	同上
单条记录大小	约 700 B	API 实测
URS0000000001 的 xrefs	11 条	xrefs API
URS0000000001 类型	rRNA，200 nt	记录
DAIMS	20.5 / 24 = 85.4%	§7.6

---

附录 B：五个可复制的查询

一、拿官方总数与索引信息

curl -s "https://www.ebi.ac.uk/ebisearch/ws/rest/rnacentral?format=json&size=1" \
  | jq '.domains[0].indexInfos'

二、按 URS 取记录

curl -s "https://rnacentral.org/api/v1/rna/URS0000000001/?format=json" \
  | jq '{rnacentral_id, rna_type, length, description, is_active}'

三、按 MD5 查（小 RNA 注释的入口）

curl -s "https://rnacentral.org/api/v1/rna/?format=json&md5=6bba097c8c39ed9a0fdf02273ee1c79a" \
  | jq '.results[] | {rnacentral_id, rna_type, length}'

四、拿某条记录的交叉引用（看它在哪些库里）

curl -s "https://rnacentral.org/api/v1/rna/URS0000000001/xrefs?format=json" \
  | jq '.count, [.results[] | {db: .database, ac: .accession.parent_ac, range: "\(.accession.feature_start)-\(.accession.feature_end)"}]'

五、拿全库 RNA 类型分布（facet）

curl -s -G "https://www.ebi.ac.uk/ebisearch/ws/rest/rnacentral" \
  --data-urlencode "query=RNA" --data-urlencode "format=json" \
  --data-urlencode "size=0" --data-urlencode "facetcount=40" \
  | jq '.facets[] | select(.id=="rna_type") | .facetValues[] | "\(.label)\t\(.count)"'

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• rfam — 共享标签：基因组学与多组学 / 多模态 / 医学问答与基准
• complexportal — 共享标签：基因组学与多组学 / 多模态
• neurovault — 共享标签：多模态 / 医学问答与基准
• cpic — 共享标签：基因组学与多组学 / 医学问答与基准
• gmai-mmbench — 共享标签：多模态 / 医学问答与基准
• ehrxqa — 共享标签：多模态 / 医学问答与基准
• microvqa — 共享标签：多模态 / 医学问答与基准
• mimic-iv-ext-cardiac-disease — 共享标签：多模态 / 医学问答与基准
• hra-knowledge-graph — 共享标签：基因组学与多组学 / 多模态
• radnli-report-inference — 共享标签：多模态 / 医学问答与基准

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。