NASA 系外行星档案 — 确认与候选的两本账

NASA 系外行星档案（NASA Exoplanet Archive）是加州理工学院 IPAC 为 NASA 系外行星探索计划运营的关系型天体库。它把三件事放进同一个可查询的空间：已确认行星的轨道与物理参数、Kepler 与 TESS 两套候选名册、以及系外行星大气光谱。它不做观测，只做抽取与归并。

它的难点不在体量。四十万行级别放在今天算不上大。难在这份库同时维护着两套互不对齐的账：一套记「已经确认的行星」，一套记「还像行星的信号」，而这两套账的边界会随文献发表逐日移动。

本文取数日期为 2026-10-29。当日官方计数页读数：已确认行星 6,451 颗，宿主星 4,847 颗，TESS 候选 8,151 个。文中所有数字均为该日快照，第二天可能不同。

§1 它是什么：一份每天都在改答案的账本

§1.1 一句话定义

它是一份以行星为记账单位、把每篇同行评议文献里的测量值按统一字段口径拆解入库的天体档案，行星行附宿主星参数，另设候选名册与光谱表，全部通过一个 TAP/ADQL 端点对外服务。

换成操作语言：给定一个行星名，你能拿到它在若干篇文献下的若干组参数，每组参数带误差、上下限、原始字符串与文献标识，其中恰好一组被标为缺省。给定一个天区或一段参数区间，你能按任意字段组合筛出候选清单。给定一颗行星，你还能查到它有没有可下载的透射或发射光谱。

§1.2 它与一张普通表格的三处不同

把这份库当普通表格用，会在三个地方栽跟头，而这三处恰好是它区别于一般数据集的地方。

第一，行数不等于实体数。 行星级的主表有 40,350 行，对应 6,451 颗行星。差额来自两件事：同一颗行星在不同文献下有多组参数（HD 209458 b 有 23 行，51 Peg b 有 6 行），以及这张表还收了候选投递的行。任何不做筛选的 count(*) 得到的都是参数组数，不是行星数。

第二，状态是字段而不是事实。 「已确认」在这份库里不是一个不可变的属性，而是一个会随时间改写的取值。Kepler 项目组会把某个 KOI 从 CANDIDATE 改成 FALSE POSITIVE，档案随后把对应行星从确认表移出，并把这次移出记进一份单独的清单。你昨天跑出的标签，今天可能已经失效。

第三，同一行的各列来自不同文献。 一条 pscomppars 记录里，轨道周期可能引自 2024 年的一篇 RV 论文，半径引自 2019 年的一次凌星拟合，有效温度引自 2021 年的光谱分析。列与列之间不是同一次观测的自洽集合，而是官方从多篇文献中各取一项、拼出的缺省组合。这不是缺陷，是设计：它的目标是给出「当前最佳可用值」，而不是「某一次实验的完整读数」。

§1.3 三十秒决策卡：你的处境，它能帮你什么

你的处境	它能帮你什么
要做一个带物理约束的表格回归任务，测模型对单位与量纲的处理	399 个字段，每个量带误差、上下限与原始字符串，天然的多单位混合练习
要训练「信号 vs 假阳性」的分类器	KOI 累积表 9,564 条带三分类标签，TOI 表 8,151 条带六种处置码
要做光谱到大气参数的映射	spectra 表 1,875 条记录、510 个不同文献，每条含波长范围与数据文件路径
需要一批行星做系外行星大气研究的目标筛选	透射光谱度量与发射光谱度量已算好，直接按评分排序
要研究科学共识如何随时间收敛	候选表与确认表的状态字段，加上被移除目标清单，构成一条可回溯的判定轨迹
要一份稳定的、可复现的行星清单	做不到，除非你自己按日存档快照，见 §9.4

§1.4 不适合谁

如果需求是光变曲线或原始像素，这里给不了。档案存的是从光变曲线里拟合出来的参数，不是曲线本身。要曲线得去 MAST 取 Kepler 与 TESS 的灯曲线产品。

如果需求是恒星的完整样本，这里也不合适。宿主星表只有 4,847 颗，是「有行星的星」，不是「天空中的星」。做恒星统计要找 Gaia 这类全天星表。

如果需求是一个确定的、可以写进标注规范的行星总数，它会让你难受。这个数字每天变，而且不存在一个跨机构公认的值：不同星表各有收录标准，档案自己的标准页写明了它的取舍——质量或最小质量不超过 30 个木星质量、不是自由漂浮天体、后续观测足以排除假阳性、结果经过同行评议并已被接收。

如果需求是低频更新的静态基准，需要自己做版本冻结。档案不发布年度快照，也不保留历史版本的行星表；能查到的时间信息只有每行的 rowupdate。

§1.5 贯穿本文的案例：Kepler-1921 c 的两张身份证

这个案例值得在开头讲清楚，因为后文关于确认与候选的每一次讨论都会回到它。

在 KOI 累积表里查：

SELECT kepid, kepoi_name, kepler_name, koi_disposition,
       koi_period, koi_prad, koi_score
FROM cumulative
WHERE kepler_name = 'Kepler-1921 c';

返回一行：kepid 9117416，kepoi_name K03425.02，koi_disposition 为 CONFIRMED，koi_period 3.15722086 天，koi_prad 1.41 地球半径，koi_score 0.953。

再在行星表里查同一个名字、且 default_flag = 1 的那一行，soltype 字段写的是 Kepler Project Candidate (q1_q17_dr25_koi)。

同一个天体，同一份档案，一张表说它已确认，另一张表说它来自候选投递。这不是数据错误。koi_disposition 记录的是 Kepler 项目组对这条 KOI 的最新处置；soltype 记录的是这一行行星参数的来源投递。两者回答的是不同问题，只是恰好共用了同一个名字。

更麻烦的是，这颗行星同时出现在 pscomppars 里——也就是那份被普遍当作「确认行星表」的 6,451 行清单。它的存在说明：确认表里也有候选来源的行，靠表名判断状态并不可靠。

§2 数据构成：三层规模、六本账、一个行星

§2.1 三层规模要分开记

这份库有三层规模，混在一起就会算错。

第一层是行星：6,451 颗已确认行星，分布在 4,847 颗宿主星周围。超过一颗行星的系统占相当比例，2,683 颗行星处于多行星系统中。

第二层是参数记录：行星级表 40,350 行，合并表 6,451 行。前者是「行星 × 文献参数集」，后者是「一行一颗行星的缺省组合」。两张表的字段数也不同：ps 有 355 列，pscomppars 有 399 列，后者多了逐参数引用列与若干派生指标。

第三层是候选记录：KOI 累积表 9,564 条，TESS 候选表 8,151 条，K2 的行星与候选合并表 4,077 条。这三本账的记账单位是「信号」，不是「天体」。

按发现方法分列的统计可以和总数对上，这一点值得当作口径校验来做：凌星 4,785、视向速度 1,204、微引力透镜 292、直接成像 98、凌星时刻变化 29、食时刻变化 17、天体测量 6、脉冲星计时 8、脉动计时 2、轨道亮度调制 9、盘运动学 1。这十一项相加正好等于上面的行星总数，说明官方在这张表里用的是互斥归类：一颗行星若被多种方法探测，只记在发现方法名下。

需要留意一个容易混淆的差别：凌星发现的行星是 4,785 颗，而当前正在凌星的行星是 4,815 颗。后者是 tran_flag > 0 的计数，包含了先由视向速度发现、后来又被观测到凌星的那批。两个数字差 30，谁也不能替代谁。

§2.2 六本账各自的记账单位

表名	行数	列数	一行是什么
ps	40,350	355	一颗行星在某篇文献下的一组参数，或一条候选投递
pscomppars	6,451	399	一颗行星的缺省参数组合，一行一颗
cumulative	9,564	153	一个 Kepler 感兴趣目标及其处置
toi	8,151	90	一个 TESS 感兴趣目标及其处置码
k2pandc	4,077	720	一个 K2 目标，行星与候选混编
td	36,477	128	一次阈值穿越事件，即候选的上一层原料
spectra	1,875	13	一条已发表的大气光谱及其文件路径
stellarhosts	48,101	136	一颗恒星及其参数，含非宿主星

行数读自 TAP 端点的 count(*)，列数读自 TAP_SCHEMA.columns，均为 2026-10-29 的返回值。

td 那一行值得单独说一句：36,477 条阈值穿越事件是候选的上游。一次穿越事件是光变曲线里一段「亮度掉下去了」的候选区间，经过筛选才成为 KOI 或 TOI。所以这份库实际上是一条四段流水线——穿越事件、候选、确认、参数——而每一段都有独立的表，彼此不是简单的包含关系。

k2pandc 有 720 列，是全库最宽的表。它的宽度来自 K2 战役的多次投递：每个战役一套参数，字段名里带战役编号，横向摊平后就成了这个宽度。这类「宽表」在机器学习里很诱人，但要先想清楚哪些列是同一物理量的不同版本。

还有两张表容易被忽略，却决定了这份库能不能被当作「实体库」使用。stellarhosts 有 48,101 行，覆盖的不只是 4,847 颗宿主星，还包括凌星巡天里被观测过但没有行星的恒星。它的存在意味着你可以构造负样本：同样经过观测、同样有光度与温度，但没有测到行星。这类对照在只取行星表的方案里是拿不到的。

object_aliases 有 3,892,385 行，是全库行数最多的表，作用是名称消歧。同一颗恒星在不同星表里有不同编号：HD、HIP、TIC、2MASS、Gaia DR2、Gaia DR3、以及各种巡天内部编号。别名表把这些编号挂到同一个实体上。没有它，跨表连接只能靠坐标匹配，而坐标匹配在密集星场里会错配。做数据整合时，这张表的价值往往超过它看起来的样子——它是三百万行的连接器，不是三百万行的数据。

§2.3 一条行星记录逐项解剖

取 51 Peg b 在 pscomppars 里的那一行，能看清它的构造。

pl_name 是「51 Peg b」，hostname 是「51 Peg」。这两个字段构成行星与恒星的连接。pl_orbper 给轨道周期，pl_rade 给半径，pl_bmasse 给质量，pl_eqt 给平衡温度，st_teff、st_logg、st_mass、st_rad 给宿主星的有效温度、表面重力、质量与半径。

每个量不是一个孤立的列，而是一个六列的小族。以轨道周期为例：pl_orbper 是值，pl_orbpererr1 与 pl_orbpererr2 是上下误差，pl_orbperlim 标记这个值是不是上限或下限，pl_orbperstr 存原始字符串（比如「4.230785 ± 0.000036」），pl_orbper_reflink 存文献引用。pscomppars 的 399 列里，60 个是 _reflink，60 个是 err1，62 个是 str，37 个是 lim，剩下的才是数值本身。

这个设计对机器学习的影响是直接的：有效特征数远小于列数。399 列里真正承载独立物理量的大约六十个，其余是它们的误差、边界与出处。把 399 列一股脑喂进模型，等于让模型在六十个物理量的六种冗余表示之间自己找关系，通常只会得到更差的泛化。

pl_bmassprov 是这一族里最容易被忽略的列。它标明质量是怎么来的：Mass 表示直接测得，Msini 表示只测到最小质量，M-R relationship 表示质量不是测出来的，而是由半径经质量—半径关系反推。全表 3,035 条属于最后一类，2,477 条是 Mass，924 条是 Msini，15 条是 Msin(i)/sin(i)。换句话说，接近一半的「行星质量」是插值产物，把它们和直接测得的质量放进同一个回归目标里，标签的噪声结构完全不同。

§2.4 与相邻资源的定位差异

这份档案的不可替代性在于行星级参数的归并。Gaia 给的是恒星的五参数解与光度，不含行星；MAST 给的是原始光变曲线与图像，不含拟合好的行星参数；ExoFOP 给的是 TESS 的后续观测协调，不是统一口径的参数表。档案做的事是把这三类上游产物里与行星有关的部分抽出来，按一套字段命名规则重新排列。

因此它与星表类数据的关系是「下游」而非「同类」。用它做恒星研究是绕路，用它做行星研究是正路——但也正因为它是下游归并，它的每一列都继承了上游文献的取舍，而这些取舍并不总是显式的。

§3 身份层：同一颗行星的两本户口

§3.1 「确认」是一个时间戳，不是一个布尔值

刚接触这份库的人往往想找到一个字段，满足「为真即行星、为假即不是」。这个字段不存在，原因不是官方没做好，而是「确认」在天文学里本身就是一个有版本的概念。

一颗行星被确认，通常意味着某篇同行评议论文给出了足够强的证据排除假阳性。此后可能发生三件事：更强的观测证实了它（状态不变）、更强的观测推翻了它（被移除）、或者出现了一个质疑但未被同行评议接受（状态不变，但被打上争议标记）。这三种情况在库里的表现完全不同：第一种不留痕迹，第二种进入被移除清单，第三种改一个标志位。

所以正确的读法是：任何状态字段都要连带问一句「截至哪一天」。计数页有日期，被移除清单有「最后更新」日期，每行有 rowupdate，候选表的处置码随 TESS 团队的发布节奏更新。把这几个时间对齐了，状态才有意义。

§1.5 的案例正是这种不同步的产物：KOI 表的处置已经走到 CONFIRMED，行星表里那一行的来源标注还停在候选投递。

§3.2 KOI 的三分类与 4,717 的来历

Kepler 的感兴趣目标表用的是三分类：CONFIRMED、CANDIDATE、FALSE POSITIVE。2026-10-29 的分布是 2,748、1,977、4,839，合计 9,564。

但计数页上还有一个 4,717，标为「Kepler Project Candidates」。它不是 1,977 的别名，而是「所有曾被 Kepler 项目组标为 CANDIDATE 的 KOI」，其中一部分后来被确认或验证。计数页的脚注写得很清楚：这个数包含已确认与已验证的行星。

于是同一批对象有了三种口径：

• 1,977 是仍未定性的候选，是最严格意义上的「待确认」。
• 4,717 是曾经是候选的全部对象，包含已经确认的。
• 4,781 是确认行星与 KOI 候选的并集，脚注特意提醒：有些确认行星从未被标为候选，所以并集大于任一部分。

三个数放在一起，任何人只要选错一个，报出来的「Kepler 待确认候选数」就会差两三倍。这不是学术争论，是纯粹的口径选择。

还有一层：KOI 表里 CONFIRMED 的 2,748 条，与行星表里「由 Kepler 发现」的 2,787 颗，也不是同一个集合。差 39。差额来自两侧各自的收录规则——有些 Kepler 场内的行星不是 Kepler 发现的，有些确认行星没有走过 KOI 流程。

§3.3 TOI 的六个处置码与 815 和 1,012 的差

TESS 的候选表用另一套编码，tfopwg_disp 字段有六个取值：PC（行星候选）、CP（确认行星）、KP（已知行星）、FP（假阳性）、FA（假警报）、APC（环境导致的候选）。当日分布：PC 4,820、FP 1,315、CP 815、KP 606、APC 490、FA 100，另有 5 条为空。

这里有一个必须解释的落差。计数页说「TESS 发现并已发表」的确认行星是 1,012 颗，而 TOI 表里 CP 只有 815 条。差的 197 条不是错误：计数页的 1,012 统计的是文献里已发表的、用 TESS 数据发现的行星，TOI 的 CP 统计的是TESS 项目组自己给出确认处置的信号。一颗行星可以先被论文确认，几个月后才在 TOI 表里被标成 CP；也可以被论文确认而项目组仍保留 PC 处置。

所以「TESS 确认了多少颗」这个问题，用 1,012 回答和用 815 回答都能自圆其说，但必须说明用的是哪本账。

KP 那 606 条更值得留意：它们是被 TESS 观测到的已知行星，即此前已由其他方式发现、TESS 只是补了一次凌星观测。把它们算进「TESS 发现」会重复计数。

§3.4 被移除的、被恢复的、卡在中间的

档案单设了一份「被移除目标」清单，最后更新于 2026-10-14。这份清单是判断「确认会反转」这一点的最直接证据。

清单上的近期条目包括：Kepler-1658 b（Winn & Stefánsson 2025）、HD 10700 e 与 HD 102365 b（Figueira 等 2025）、rho CrB d（Zhao 等 2026）、WASP-18 c（Salguneswaran 等 2026）、TOI-1272 c（Mancini 等 2026）、42 Dra b（Hatzes 等 2025）、HD 20794 c（Nari 等 2025）、K2-256 b、Kepler-488 b、K2-399 b，以及更早的 Kapteyn b、HW Vir b 与 c、K2-51 b、K2-67 b、K2-76 b。每一条都附了推翻它的文献。

同一份页面上还有「被恢复目标」：那些先被确认、再被质疑、又被新数据重新确认的天体，例如 LkCa 15 b、HD 5388 b，以及 Diaz 等（2015）之后恢复的一批。这意味着一颗行星的标签可以是「确认—移除—确认」的三段式，任何只存最终状态的快照都会丢掉中间那段。

最耐人寻味的是「值得注意的目标」一节。它写明：Kepler-468 b 与 Kepler-1415 b 被 Kepler 假阳性工作组在 DR25 补充发布中判为假阳性，但由于没有同行评议的正式推翻论文，档案仍将它们列为确认行星。同一页还写明 Kepler-452 b 需要特别留意；而 Proxima Centauri c 虽然被多篇文献讨论，因缺少同行评议的确认，在档案里挂的是「候选行星」处置。

这三条放一起，说明确认的标准是文献状态而非证据强度。一个信号可以被专业工作组判为假，但只要没有正式论文，它在库里就还是行星；反过来，一个被广泛讨论的信号，只要没有正式论文，它就不能是行星。这套规则对内一致，对外则必然与「科学事实」有偏差。

对下游的直接影响是：任何以这份库为正例来源的模型，都在隐式学习「哪些信号熬过了文献流程」，而不是「哪些信号是真的行星」。这两件事高度相关但不相等。被移除清单上的那些行星，在被移除之前一直是训练集里的正例；如果模型在它们被移除之前训练完成，它的评估结果里就带着这个时代错误。这不是模型的错，是标签随时间漂移的必然结果。

处理办法只有两种：要么在每次评估时重建标签（成本高，但诚实），要么在数据卡里固定标签版本并声明时效（成本低，但要接受结论只在某个时间窗内有效）。混着做——用旧标签训练、用新标签评估——会得到系统性偏低的指标，而且找不到原因。

§3.5 名字层面的撞车

行星命名规则是「宿主星名 + 小写字母」，字母按发现顺序分配。这条规则在小样本下没问题，在几千颗的规模下产生了两类麻烦。

第一类是候选名与行星名同形。TESS 的候选编号是「TOI-数字.两位序号」，比如 TOI-682.01。这个格式不会被误认成行星名。但在缺省行星集里确实存在 TOI-682.01 这样一条 pl_name，它来自 TESS 候选投递，却用了行星表的命名空间。仅凭名字，无法区分它是行星还是候选。

第二类是同一宿主星下的字母重排。当一颗恒星被确认有多颗行星，字母会按周期从内到外重排，早期文献里的「b」可能变成后来的「c」。档案以最新规则为准，但这意味着跨文献按名字连接会错配。

实践上的结论很直接：行星表的连接键应该是 pl_name 加 default_flag，候选表的连接键应该是 koi_name 或 toi，不要试图用行星名字把两本账连起来。跨账连接要靠坐标或 TIC 编号，并且要接受匹配率不会满。

§3.6 那 58 行官方自标的争议

pl_controv_flag 这个字段只有 0 和 1 两个取值，全表 58 行为 1。它标记的是「官方认为这颗行星的存在有争议」，但档案仍然收录它、仍然给它参数。

这个字段的存在本身就是一种诚实：它承认「已确认」这个集合内部还有分层。对做监督学习的人来说，这 58 行是需要单独处理的一小撮——它们既不该被当作正例的干净样本，也不该被直接删掉，因为删掉就等于替科学界做了判断。

一个务实的处理是把它当作样本权重或额外的二分类标签，在训练时保留、在评估时分组报告。这个决定要写进数据卡，因为下游使用者会关心。

§4 参数层：default_flag、空字符串与六十条引用

§4.1 default_flag：40,350 与 6,451 之间的距离

default_flag 是这份库里最重要的一个整数字段，重要到值得在每一段取数代码里都写一遍。

它的语义是：同一颗行星在同一张表里可能有多行，每行对应一组来自不同文献的参数，其中恰好一行的该字段为 1，表示这是官方选定的缺省参数集。选哪一组由官方按参数的数量与精度判断，规则写在收录标准页上：优先选报告参数多且精度高的那一组；如果一篇文献给的是区间而非中心值加误差，就取区间中值、取区间半宽作误差。

ps 全表 40,350 行，default_flag = 1 的恰好 6,451 行，与计数页的行星总数一致。这个等式是整个库的口径锚点：行星数 = default_flag 为 1 的行数。

但 §1.5 的案例提醒了一件事：这些行里有 73 行的 soltype 不是 Published Confirmed，而是各类候选投递。也就是说口径锚点给出的是「行星表认可的行星数」，不是「文献确认的行星数」。两个数字相差 73，官方选择了前者作为对外口径。

对于要做机器学习流水线的人，这意味着：default_flag = 1 是必要条件而非充分条件。要得到纯确认集，还得再筛 soltype，或者干脆用 pscomppars 加一次显式核查。

§4.2 一个参数占六列：值、两个误差、一个限、一个字符串、一个引用

上一节提过 399 列的构成。把它拆开看，一个物理量在库里的完整形态是这样的：

pl_orbeccen 是离心率的值；pl_orbeccenerr1 与 pl_orbeccenerr2 是上下误差，天文学里误差常常不对称，所以需要两个；pl_orbeccenlim 标记这个值是否只是上限或下限（比如「离心率小于 0.1」这种情况只能给上限）；pl_orbeccenstr 保留原始字符串，含单位与有效数字；pl_orbeccen_reflink 指向文献。

这个六元组不是冗余，是必要。原因在于天文测量的三类不对称：误差不对称、有些量只能给界限、不同文献的有效数字习惯不同。把这六列压成一个浮点数，会丢掉「这个值是上限」这一关键信息——而 lim 为真的行，其值不能参与任何均值计算。

lim 字段在全表有 37 个。它们的分布极不均匀：半径与质量的界限行很多（因为很多行星只有半径或只有最小质量），周期与半长轴的界限行很少。做特征工程时，对每个数值列都要先看对应的 lim 列，再决定这一行是否进入训练集。

str 那 62 列看起来最没用，实际上是最有用的调试工具。当数值列的行为反常时，回到原始字符串往往能立刻看出问题：单位是天还是年、是地球半径还是木星半径、有效数字被截断到几位。档案的字段名统一用后缀区分单位（pl_rade 是地球半径，pl_radj 是木星半径，pl_bmasse 是地球质量，pl_bmassj 是木星质量），但上游文献不一定，抽取时的一致性只能靠原始字符串验证。

§4.3 缺失是空字符串，不是 0，不是 NaN

这一点被写进过太多次，仍然值得再写一次，因为它违反直觉。

通过 TAP 以 CSV 格式取数时，缺失值表现为一个空字段。查一条已知缺轨道半长轴的记录：

curl -s -G "https://exoplanetarchive.ipac.caltech.edu/TAP/sync" \
  --data-urlencode "query=select top 5 pl_name,pl_orbincl from pscomppars where pl_orbincl is null" \
  --data-urlencode "format=csv"

返回的前两行形如：

pl_name,pl_orbincl
"HAT-P-13 c",
"HAT-P-17 c",

行星名后面直接跟一个逗号，没有值，没有 NaN，没有 0，也没有 NULL 字样。用 JSON 格式取同一批数据时，该字段是 null。

这个差异会导致两类静默错误。第一类：pandas 读 CSV 时默认会把空字段解析成 NaN，看起来没问题，但如果某个数值列全为空，整列会被推断成 object 类型，后续的 mean() 会抛错或者返回奇怪的结果。第二类更隐蔽：某些解析器把空字符串转成 0，于是「没有测量」变成了「测到零」，而 0 在物理上往往是一个有意义的值（离心率为 0 是圆轨道，质量为 0 是不可能的）。这类错误不会报错，只会让统计量悄悄偏移。

在 pscomppars 里，仅 pl_orbsmax 一列就有 495 行是空的。这不是小概率事件，是常态。

缺失的成因有三种，混在一起看会把它们当成同一种。第一种是没测：这颗行星只做了凌星观测，没有视向速度数据，于是质量相关的列全空。第二种是测不准：有观测但信噪比不足，官方不给出数值，只给上限。第三种是不适用：某些列对某些发现方法天然无意义，比如微引力透镜行星没有凌星深度。三种成因对应三种处理方式，而字段本身不区分它们。

唯一的间接线索是 lim 与 str 两列。lim 为真说明是第二种（有界限但无中心值）；lim 为假且值为空，多半是第一种或第三种，需要结合发现方法判断。所以「这个值为什么是空的」这个问题，必须回到该行的 discoverymethod 才能回答，单看一列看不出来。

§4.4 bibcode 藏在 HTML 锚点里

这是这份库对机器学习最不友好的一个设计，也是最容易在数据管道里被忽略的一个。

每个 _reflink 列的值不是 bibcode 本身，而是一段渲染好的 HTML。取 51 Peg b 的轨道周期引用：

<a refstr=CONT_ET_AL_2026 href=https://ui.adsabs.harvard.edu/abs/2026A&A...710A.345C/abstract target=ref>Cont et al. 2026</a>

bibcode 是 2026A&A...710A.345C，它藏在 href 的路径里。要拿到它必须做字符串提取。同样这一行的 pl_rade_reflink 值是另一种形态：

<a refstr=CALCULATED_VALUE href=/docs/pscp_calc.html target=_blank>Calculated Value</a>

CALCULATED_VALUE 不是文献，是一个伪引用，表示这个半径不是引用的，而是由其他量算出来的。

这两段文本说明了两件事。第一，溯源信息不是结构化字段，它是给人看的 HTML，机器读之前要先解析。第二，伪引用与真引用混在同一列，如果不区分 CALCULATED_VALUE，就会把「推算值」当成「有文献支持的值」。

为什么这件事重要？因为在大模型与 RAG 场景里，一条参数的可信度往往取决于它有没有文献支撑。60 个 _reflink 列是这份库最有价值的元数据之一，但它的形态决定了它不能直接进特征矩阵，只能进检索索引或作为质量分层依据。

§4.5 派生指标混在测量列里

pl_tsm 与 pl_esm 是两个容易被误当作观测量的字段。

pl_tsm 是透射光谱度量，pl_esm 是发射光谱度量。它们都是无量纲评分，用途是给 JWST 这类望远镜排观测优先级：分数越高，意味着这颗行星的大气越容易被测出信号。全库 4,618 行有 TSM 值。

这两个量的计算依赖行星半径、平衡温度、宿主星半径与星等，全部来自其他列。也就是说它们是函数值，不是独立测量。把它们放进一个「预测行星质量」的模型里当特征，会造成信息泄漏，因为质量往往也被用来算它们。

同一族里还有 pl_nobs_jwst_tran、pl_nobs_jwst_e、pl_nobs_jwst_di、pl_nobs_jwst_pc 四列，记录 JWST 已完成的观测次数。全库合计：透射 539 次、发射 185 次、直接成像 0 次。这几个数字是「已排期执行」的计数，会随观测计划推进而增长，属于典型的时效字段。

放在一张表里的三类东西——测量值、派生评分、观测计数——共享同样的列名风格，没有任何前缀区分。这是使用这份库时必须自己建立的一张分类表。

§5 取数层：三条路径与它们各自的代价

§5.1 三条路径一览

路径	适合什么	代价
TAP 同步端点（ADQL）	任意条件筛选、聚合、小批量取数	单次结果有行数上限，大查询会超时或被拒
批量下载（CSV 打包）	全表取回、离线分析	文件大、字段全、需要自己处理空值与编码
交互表格导出	快速看数据、确认字段含义	不适合自动化，导出格式随页面变化

三条路径读的是同一份库，字段名与语义完全一致，差别只在传输方式与筛选能力。

§5.2 TAP 同步查询：一条 curl 就够

TAP 的同步端点接受 ADQL（天文版的 SQL 子集），返回 JSON、CSV 或 VOTable。最小的可用查询是数行数：

curl -s -G "https://exoplanetarchive.ipac.caltech.edu/TAP/sync" \
  --data-urlencode "query=select count(*) as n from ps" \
  --data-urlencode "format=json"

返回 [{"n": 40350}]。把表名换成 pscomppars 得到 6,451，换成 toi 得到 8,151。

要验证缺省集的口径，用这条：

SELECT count(*) AS n FROM ps WHERE default_flag = 1;

要按发现方法核对总数，用这条：

SELECT discoverymethod, count(*) AS n
FROM pscomppars
GROUP BY discoverymethod;

注意 pscomppars 用的是 discoverymethod（无下划线），而 ps 里同一个概念也叫 discoverymethod，但两张表的其他字段名并不完全对齐：ps 有 soltype、rowupdate、releasedate，pscomppars 没有；pscomppars 有 60 个 _reflink 与 pl_tsm，ps 没有。跨表写查询前先看 TAP_SCHEMA.columns，不要假设字段通用。

ADQL 与标准 SQL 的差别需要提前知道：它不支持在 FROM 子句里写子查询（写成派生表会直接报「表不可用」），不支持 ORDER BY 聚合结果，分页用 TOP n 而非 LIMIT n。这些限制会让习惯 PostgreSQL 的人多写几轮。

§5.3 表名要先查，不要猜

这份库的表名不规则，猜错的成本很高。几个具体的坑：

KOI 累积表在 TAP 里叫 cumulative，不叫 koi_cumulative。写后者会返回「表不可用」，而不是「表不存在」，容易让人以为是权限问题。

大气光谱表叫 spectra，不叫 spec。它只有 13 列，是一个索引表——每条记录指向一个外部数据文件，而不是把光谱点存进表里。

同一个物理概念在不同表里的列名不一致。TESS 候选表用 tid 表示 TIC 编号，行星表用 tic_id；两者的类型还不一样，直接 join 会报数值转换错误，必须先转成字符串再比。

K2 的行星与候选在 k2pandc 一张表里混编，没有单独的「K2 确认表」。要取 K2 确认行星，得从行星表里按 disc_facility 筛。

查表清单的标准做法是查元数据表本身：

SELECT table_name, description FROM TAP_SCHEMA.tables ORDER BY table_name;

这条查询会返回三十多张表，其中包括各个 DR 版本的 KOI 历史投递（Q1_Q6、Q1_Q8、Q1_Q12、Q1_Q16、Q1_Q17_DR24、Q1_Q17_DR25 及其补充版）。这些历史版本是研究「候选如何演化」的好材料，但绝不能与最新版混用。

§5.4 批量下载与 API

批量下载提供打包好的 CSV，适合一次性取全表做离线分析。它的优势是字段完整、没有行数上限；劣势是文件大、需要自己处理编码与空值，而且下载的是「当时」的快照，没有版本号可回溯。

另有一套 API 面向程序化访问，返回 JSON，适合做轻量的单对象查询。它与 TAP 的差别主要在接口形态，数据源相同。

对机器学习流水线来说，比较稳妥的组合是：用批量下载取一次全量做基线，之后用 TAP 做增量核对。不要每天都拉全量——库在变，但变得没那么多。

§5.5 光谱不在主表里

spectra 表 1,875 条记录，13 列：行星名、光谱类型、作者、数据点数、仪器、设施、观测起止、波长范围、备注、bibcode、文件路径。

光谱类型只有三种：透射 989 条、食 801 条、直接成像 85 条。510 个不同的 bibcode 说明这 1,875 条记录来自五百多篇文献，平均每篇不到四条。

关键在 spec_path 这一列。它不是一个可以直接下载的 URL，而是一个指向档案内部文件系统的路径，需要通过档案的 spectra 服务拼接后才能取到实际数据。这意味着光谱数据不是一个可以直接 join 进表格的列，它是另一套分发机制。

同族的还有 emissionspec（2,361 行）与 transitspec（5,948 行），这两个表的行数比 spectra 大得多，因为它们的记账单位是「数据点级」或「观测级」，而不是「光谱级」。三个表名字相似、粒度不同，混用会得到差三倍的计数。

§5.6 大查询的代价

TAP 同步端点是共享服务，有并发与超时限制。全表扫描 ps 的 40,350 行不算大，但同时拉 399 列乘 6,451 行就会接近返回体积上限。稳妥的做法是先取列的子集，或者用批量下载。

还有一个隐性成本：这个端点位于加州理工的服务器上，跨太平洋访问的延迟不低。一条 count(*) 通常在一秒内返回，但返回 6,451 行乘 60 列的 JSON 可能要十几秒。在流水线里做频繁的小查询，比做一次大查询更划算。

§6 与库内其他条目的关系

这份档案与 Gaia DR3 构成一组上下游关系，而不是替代关系。

Gaia 提供的是恒星层面的一致解：位置、视差、自行、三波段星等、温度与重力，全天覆盖，18 亿个源。它不含行星，也不含任何与行星有关的拟合。系外行星档案提供的是行星层面的归并：轨道、半径、质量、平衡温度，以及宿主星的那一组参数——但那组宿主星参数是从各篇行星论文里抄来的，不是 Gaia 那种统一处理的全天解。

实际影响是：同一颗宿主星，在 Gaia 里和在系外行星档案里，有效温度可能不同。原因不是谁错了，而是来源不同——Gaia 用 BP/RP 光谱统一反演，档案用论文作者采用的文献值。要做恒星光度—行星半径的联合分析，必须先决定用哪一套恒星参数，并且全程一致。

两者的另一个差别是更新模式。Gaia 的发布是冻结的：DR3 发布后只出勘误，数据不再变。系外行星档案是流动的：每天都有新行星入库，每天都有候选改判。前者适合做可复现基准，后者适合做时效性任务。把两者放进同一个评测集，要分别标注「冻结」与「流动」，否则复现性无从谈起。

第三个差别在许可。Gaia 是 CC BY-NC 3.0 IGO，商业使用须事先申请；系外行星档案没有声明 SPDX 许可，只有致谢要求与一个数据集 DOI。这两种约束的性质不同：前者是法律条款，后者是学术惯例。对商业项目来说，前者明确禁止，后者则是灰区。

§7 质量与已知问题

§7.0 阅读本节前的一次认知校正

进入这一节之前，有一个前置判断需要先放下来：不要试图为这份库找一个「正确的行星总数」，然后把它当作标签基准。

这个念头之所以要放弃，是因为它预设了「行星集合是一个确定的集合」，而这份库的运作方式不支撑这个预设。它的集合边界由三件事共同决定：文献是否发表、官方是否收录、项目组是否改判。三者不同步，且各有各的时间表。任何一天读到的数字都是这三条线在那一刻的交点，而不是某个客观常量的逼近。

认知校正之后，评价这份库的标准也该换。不该问「它准不准」，该问「它在哪些维度上可追溯、在哪些维度上不可追溯，以及不可追溯的部分对下游任务是否致命」。下面按这个口径展开。

§7.1 逐条局限

状态字段与物理事实之间有制度性延迟。 被移除清单上的每一个条目都对应一篇推翻论文，但收录标准决定了只有同行评议的正式论文才能触发移除。Kepler-468 b 与 Kepler-1415 b 被专业工作组判为假阳性却仍在确认表里，就是这条规则的直接后果。延迟的长度不可估计，因为它取决于有没有人愿意写那篇论文。

多来源参数拼接导致行内不自洽。 一条行星记录的周期、半径、质量可能来自三篇不同文献、三个不同年份。官方按「参数多且精度高」选缺省组，但每篇文献各自的样本与假设不同。做物理一致性检验（比如用周期与质量反推行星密度，再和表里的密度列比）时会发现对不上，这不是计算错，是数据本身如此。

近半数质量是推出来的。 pl_bmassprov 为 M-R relationship 的 3,035 条，其质量由半径经经验关系反推。这些值不该与直接测量的质量混在同一个回归目标里，因为它们的误差结构与测量值完全不同：测量误差是观测噪声，推算误差是关系式的系统偏差。

光谱覆盖极稀疏。 1,875 条光谱记录覆盖的行星数量远小于行星总数，且集中在少数明亮目标上。想做「行星大气」的端到端任务，样本量会立刻成为瓶颈，而且这个稀疏不是随机稀疏——亮星、近距离、大半径的行星更容易被观测，这是一个强选择效应。

没有版本号，也没有历史快照。 官方不发布「2024 年版行星表」这样的冻结产物。每行的 rowupdate 只告诉你这一行何时最后一次变动，不告诉你变动前的值。要复现某一天的库，只能自己在那一天存档。

同一颗行星在不同表里的数值可能不一致。 行星表的缺省组与候选表的记录来自不同的投递批次，一套按文献更新，一套按项目组发布更新。Kepler-1921 c 的状态分歧是显性的，参数分歧则是隐性的：周期、半径这类量在两张表里的小数位常常不同。做交叉验证时，两边对不上不一定是算错，先确认取的是同一批次。

候选表没有统一的命名空间。 KOI 用 kepid 加 kepoi_name（形如 K03425.02），TOI 用 TIC 编号加 toi（形如 682.01），K2 用 campaign 加 EPIC 编号。三套编号互不通约，跨任务做统一分析必须先过一遍别名表，而别名表本身也不覆盖全部候选。

许可状态不明确。 致谢页给出了标准致谢文本、数据集 DOI（10.26133/NEA45）与建议引用的论文，但没有 SPDX 标识，也没有 CC 条款。这不是拒绝授权，也不是明确授权，而是一种学术共同体的默认惯例。把它当成「随便用」和当成「不能用」都不准确。

§7.2 三组能自己做的对照

判断一份数据是否可信，最实用的办法是找三组可以独立复算的对照。这份库至少有三组。

第一组：计数页与 TAP 的对照。 计数页说已确认行星 6,451，TAP 里 ps 加 default_flag = 1 也是 6,451。两者一致说明计数页不是手工维护的孤立数字。若不一致，说明有一侧滞后，这时以 TAP 为准，因为它是库本身。

第二组：发现方法分项与总数的对照。 十一种发现方法的分项相加应等于行星总数。这个加法能立刻暴露口径问题：如果某一项被重复计入，总和会超出；如果某一类被漏掉，总和会不足。这是一条一分钟就能跑完的自检。

第三组：候选表内部的一致性。 TOI 表的六个处置码相加应等于 8,151（含 5 条空值）。KOI 表的三分类相加应等于 9,564。这两个等式都成立，说明候选表的行没有丢失也没有重复。但它们不构成对「候选是否真的是行星」的任何保证——那只由后续观测决定。

§7.3 DAIMS 评估：把它当数据管理对象看

DAIMS（Data and Information Management Standards）本是为生物医学数据设计的成熟度框架，套在这份天体档案上会显出它的性格：溯源能力极强，状态一致性中等，许可清晰度低。

DAIMS 维度	成熟度	依据
唯一标识	中	pl_name 在 ps 中不唯一，须配合 default_flag；候选表各有独立编号体系
元数据描述	极高	399 个字段全部有说明与单位，TAP_SCHEMA 可机器读取
数据溯源	极高	60 个逐参数引用列，可把任一数值追到具体文献与 bibcode
数据质量声明	高	单设被移除目标清单、争议标记字段、收录标准页，规则写得很明白
版本管理	低	无版本号、无历史快照，只靠 rowupdate 单列时间戳
许可清晰度	低	无 SPDX、无 CC 条款，只有致谢文本与 DOI
商业可用性	不明	未声明限制，也未声明授权，处于灰区
机器可读格式	高	统一 TAP/ADQL，多格式返回，但引用列是 HTML 片段
可复现性	低	数据每日变动且不留旧版，复现依赖使用者自行存档
文档可达性	高	文档站结构清晰，收录标准、致谢、被移除清单均可直接访问

综合判断：作为「可检索、可追溯的天体参数库」，它的成熟度很高，尤其是逐参数引用这一点，在同级资源里少见。作为「可以随取随用的机器学习数据集」，它在版本管理与许可两项上有明显缺口，而这两项恰好是工业流水线最在意的。

这张表对实际工作的意义是：如果项目需要向合作方证明数据来源可信，溯源那一行是强项，可以把任何一列追到论文。如果项目需要长期可复现，版本管理那一行就是必须先自己补上的洞——官方不会替你补。

§8 版本与生态：它为何能持续

§8.1 更新节奏

这份库没有「版本」这个概念，只有「今天的状态」。计数页顶部写的是当日读数，没有版本号；行星表没有发布批次；候选表跟着 TESS 与 Kepler 团队各自的发布节奏走。

从数据本身能看到节奏的痕迹。disc_year 的范围是 1992 到 2026：最早的是脉冲星行星系统，1995 年之后才是主序星行星的常规发现。最近几年的条目里，TESS 贡献了大部分新增。被移除清单的最后更新日期是 2026-10-14，说明清理工作是持续进行的，不是一次性动作。

1992 这个起点值得说一句，因为它解释了为什么库里会有一批「绕脉冲星转的行星」。那批天体是脉冲星计时观测推断出来的，质量下限只有地球量级，发现时间早于 51 Peg b，也早于任何凌星观测。它们的参数结构与后面几千颗完全不同：没有半径，没有凌星深度，只有周期、质量下限与离心率。把它们与凌星行星混在一个数据集里，会发现大量列对它们天然为空——这不是数据缺失，是观测方式不同。

这种「无版本、连续更新」的模式对使用者的要求很具体：要么接受数据会变，要么自己冻结。没有第三条路。

§8.2 它为何能持续：三个刚性

第一层刚性是它填补的位置没有替代品。行星参数必须有人归并，而这件事只有少数机构在做：一个在美国（这份档案），一个在瑞士（系外行星百科全书）。前者提供可查询的关系型接口，后者提供人工维护的百科条目。要做批量计算只能用前者。

第二层刚性是它的上游是分散的。行星发现分散在几百个课题组、几十台望远镜、上百篇每年的论文里。没有任何一个课题组有能力维护一份全局清单。归并这件事必须由一个中立机构做，而这个机构的成本又只能由公共资金承担。

第三层刚性是它的下游是共享的。系外行星研究、大气建模、宜居性评估、乃至科普内容，都从同一份清单出发。清单一旦分裂成多个互不兼容的版本，整个领域的数字就对不上。这种共享需求形成了一种自我强化的稳定性：即使用户对某些设计不满，也很难不用它。

三层叠起来，就是它活过三十年的原因。不是因为技术先进，而是因为位置不可替代、上游分散、下游共享。

§8.3 引用与署名

官方致谢页给出的做法很具体：在任何使用了档案服务的出版物里加入标准致谢文本，说明该档案由加州理工学院在 NASA 合同下运营、属于系外行星探索计划；如果用了具体文献的数据，还要直接引用那篇文献。

作为学术引用，官方建议引 Christiansen 等（2025）的论文，它取代了 2013 年的 Akeson 等人的旧文献。数据集本身还有一个 DOI：10.26133/NEA45。AAS 的设施关键词里也有对应条目，LaTeX 里写 \facility{Exoplanet Archive}。

这套安排的特点是：它把「怎么用才合规」写成了操作步骤，而不是法律条款。对学术用户够用，对商业用户不够——商业用户需要的是许可类型与使用范围，而这两项官方没有给。

§9 使用指引：三类角色与一条最小流程

§9.1 三类角色

做基准的人关心的是稳定性。可行做法是取一次全量，冻结成自己的版本，在数据卡里写明快照日期与取数 SQL。之后所有实验都基于这份冻结副本，新版本作为对照而非替换。

做模型的人关心的是标签质量。可行做法是先确定任务边界：是行星/非行星的二分类，还是候选信号的六分类，还是参数回归。三种任务的标签来源完全不同，不能共用一份清洗脚本。前者用确认表加被移除清单，中者用候选表的处置码，后者用参数表加 lim 过滤。

做检索的人关心的是元数据。可行做法是把 60 个 _reflink 列抽出来做成引用图谱，把行星、文献、仪器三者连起来。这份库在这方面的信息密度很高，但需要先做 HTML 解析。

§9.2 最小可运行流程

一条从零到可用数据集的路径，六步。

第一步，确认口径。跑一次行星计数与候选计数，把当天的数字记进日志。

SELECT count(*) AS planets FROM ps WHERE default_flag = 1;
SELECT count(*) AS toi_all FROM toi;

第二步，取确认集。用 pscomppars 而不是 ps，因为前者一行一颗行星，省掉 default_flag 的重复判断；取完再核一次行数是否等于第一步的行星数。若不等，说明有行星只有候选来源的参数，回到 §1.5 的案例看那 73 条。

第三步，剔除界限行。对每个要用的数值列，检查对应的 lim 列，把「只是上限」的值单独存起来，不参与回归。

第四步，处理缺失。把空字符串显式转成缺失标记，不要用 0 填充，也不要用列均值填充——缺失在这里携带信息（没测过 vs 测不准）。

第五步，标注质量分层。用 pl_controv_flag、pl_bmassprov、soltype 三个字段组合出至少四层：干净确认、推算质量、有争议、候选来源。

第六步，写数据卡。写明快照日期、取数端点、筛选条件、缺失处理方式、以及「行星总数会变」这一条。

§9.3 在 AI 流程中的位置

这份库在机器学习流程里通常出现在两个位置。

第一个位置是结构化先验。做天文图像或光谱的模型时，行星的周期、半径、平衡温度是有物理含义的条件变量，可以用来做条件生成或约束解码。这份库提供的是这些量的权威取值，比从论文里逐个抄要可靠。

第二个位置是科学共识的时序数据。候选表的状态字段、被移除清单、争议标记，三者合起来构成一条「某个信号如何从候选变成行星、又如何被推翻」的轨迹。这类数据在科学社会学、科研传播、乃至模型的不确定性校准研究中都有价值，而且很少有替代来源。

不适合的位置是大规模的纯视觉预训练。这里的样本量是千级，不是百万级，任何需要海量样本的任务都不该从这里取数。

§9.4 一个每日快照的做法

既然库每天在变，复现就只能靠自己。一个够用的做法是每天定时取一次缺省集的关键列，存成带日期的分区文件：

D=$(date +%F)
curl -s -G "https://exoplanetarchive.ipac.caltech.edu/TAP/sync" \
  --data-urlencode "query=select pl_name,hostname,disc_year,discoverymethod,pl_orbper,pl_rade,pl_bmasse,soltype,pl_controv_flag from ps where default_flag=1" \
  --data-urlencode "format=csv" \
  -o "ps_${D}.csv"

这样积累几个月，就得到了一份「行星清单如何演化」的时间序列：哪些行星新出现，哪些消失，哪些从候选来源转成确认来源。这份副产品在公开渠道拿不到，只能自己攒。

§10 AI 使用声明

项目	说明
性质	文献归并的测量记录，非标注数据集
建议用途	参数回归、候选分类、光谱目标筛选、科学共识演化研究
不建议用途	当作静态基准；把 ps 行数当行星数；把候选与确认相加；把推算质量当直接测量
伦理	无个人数据，无一例对应自然人；天体命名不涉及个人隐私
引用	致谢文本照官方原文；论文引 Christiansen 等（2025）；数据集 DOI 10.26133/NEA45
版本	无版本号，读数日期 2026-10-29；复现须自行冻结快照
状态	持续更新，每日变动；目标会被移除，也会被恢复
再分发	官方未声明 SPDX 许可，再分发应保留致谢与 DOI

§11 常见误读（避坑清单）

常见说法	实际情况	证据
「这库有六万五千颗行星」	把 ps 的 40,350 行当成了行星数，行星数要看 default_flag = 1	TAP 计数：全表 40,350，缺省集 6,451
「pscomppars 就是确认行星表」	里面有 73 条候选来源的行，TOI-682.01 与 Kepler-1921 c 都在其中	缺省集中 soltype 非 Published Confirmed 的 73 行
「KOI 是行星候选，加进确认数就是总数」	KOI 与 TOI 是信号名册，且与确认集有交集，相加会重复计数	计数页脚注：并集 4,781，小于两部分之和
「TESS 确认了 815 颗」	815 是 TOI 表的 CP 处置数，文献确认数是 1,012，两者口径不同	计数页与 toi 表 tfopwg_disp 分布
「缺失值填 0 就行」	缺失在 CSV 里是空字符串、在 TAP 里是 null，填 0 会把「没测」变成「测到零」	导出 pl_orbincl 为空的记录，值为空字段
「pl_bmasse 都是测出来的质量」	3,035 条来自质量—半径关系推算，占近半	pl_bmassprov 分布
「pl_tsm 是一个观测值」	它是由半径与平衡温度算出的观测优先级评分，用它会引入信息泄漏	字段说明与 4,618 条有值记录
「确认了就不会变」	有专门的被移除清单，2026 年仍在下架行星	被移除目标页，最后更新 2026-10-14
「候选表里 disposition 为 CONFIRMED 就是确认行星」	KOI 表说 CONFIRMED，行星表同一名字的 soltype 仍可能是候选投递	Kepler-1921 c 两表对照
「表名叫 koi_cumulative」	TAP 里叫 cumulative，写错会返回「表不可用」	TAP_SCHEMA.tables 清单
「光谱数据在 spec 表里」	表名是 spectra，且它只是索引，实际数据要靠 spec_path 另取	spectra 13 列结构
「引用列直接读就是 bibcode」	值是 HTML 锚点，bibcode 藏在 href 里，还混着 CALCULATED_VALUE 伪引用	51 Peg b 的 pl_orbper_reflink 原文

§12 FAQ

Q1：为什么官方计数页的数字和我查到的对不上？

最常见的原因是查询没加 default_flag = 1，或者查的是 ps 而不是 pscomppars。其次是时间差：计数页是动态刷新，你查的那一刻可能已经比页面缓存新。第三是口径差，比如「TESS 确认」有 815 与 1,012 两个数，分别对应项目组处置与文献确认。

Q2：我要做行星分类模型，正例和负例该怎么取？

正例用确认集（pscomppars 或 ps 加 default_flag = 1），负例用 KOI 表里 koi_disposition = 'FALSE POSITIVE' 的 4,839 条，或 TOI 表里 FP 与 FA 的合计。注意负例的观测来源与正例不同，直接混用会学到「哪台望远镜看的」而不是「是不是行星」。稳妥做法是同一个来源内部分正负，比如只用 Kepler 数据。

Q3：被移除的行星要不要从训练集里删掉？

取决于任务。如果任务是「复现历史判断」，保留，因为当时它确实在表里；如果任务是「预测当前真相」，删掉，但要在数据卡里记录删了多少、依据哪份清单。两种做法都能自洽，不能自洽的是悄悄删掉不写。

Q4：pl_name 能不能当主键？

在 pscomppars 里可以，一行一名。在 ps 里不行，同一名字有多行。跨表时更不行，因为候选表用的不是这套命名。要跨表连接，用坐标或 TIC 编号，并接受匹配率损失。

Q5：为什么有的行星只有半径没有质量？

因为凌星法测的是半径比，视向速度法测的是质量。只做了凌星观测的行星只有半径。全库有半径的 4,826 颗，有质量的 2,197 颗，有最小质量的 1,101 颗。这个不对称是观测方法的直接结果，不是数据缺失。

Q6：lim 字段为真时，数值还能用吗？

能用于筛选，不能用于统计。比如「半径小于 2 地球半径」是一个有效约束，但把它当 2 代入均值计算会系统性高估。正确做法是把这类行单独标记，在回归里作为区间删失样本处理。

Q7：光谱表只有 1,875 条，够训练大气反演模型吗？

作为独立训练集不够。它更适合当验证集或先验来源。真正的大气反演训练集要靠 JWST 与 Hubble 的归档数据自行组装，这份表的价值在于它给了统一的索引与文献归属。

Q8：这份库和系外行星百科全书有什么区别？

档案是可查询的关系型库，字段统一、可按条件筛、有 TAP 接口，适合批量计算。百科全书是人工维护的条目页，图文并茂、解释充分，适合查单颗行星的背景。做批量任务用前者，做背景阅读用后者。

术语表

术语	含义
已确认行星	经同行评议文献确认、且满足档案收录标准的行星。这不是一个永久状态
KOI	Kepler Objects of Interest，Kepler 的感兴趣目标，是信号不是行星
TOI	TESS Objects of Interest，TESS 的感兴趣目标，编号形如 123.01
TCE	Threshold Crossing Event，阈值穿越事件，候选的上游原料
缺省参数集	同一行星多组参数中被官方选中的那一组，default_flag 为 1
bibcode	ADS 的文献标识码，形如 2026A&A...710A.345C，内嵌年份、刊名、卷页与作者首字母
假阳性	信号真实存在但非行星所致，如背景食双星、仪器系统误差
假警报	信号本身不成立，多为噪声或处理伪影
平衡温度	假设行星黑体平衡时算出的温度，依赖恒星光度与轨道半长轴
透射光谱度量	由半径与平衡温度算出的观测优先级评分，非测量值
TAP	Table Access Protocol，虚拟天文台的表访问协议，ADQL 是其查询语言

附录 A 速查卡

要查什么	用哪张表	关键条件
行星总数	ps	default_flag = 1
一行一颗行星	pscomppars	无需额外条件，共 6,451 行
Kepler 候选处置	cumulative	koi_disposition 三分类
TESS 候选处置	toi	tfopwg_disp 六分类
有争议的行星	pscomppars	pl_controv_flag = 1，58 行
质量是推算的	pscomppars	pl_bmassprov = 'M-R relationship'
有大气光谱	spectra	1,875 条，靠 spec_path 取数据
参数出处	pscomppars	60 个 _reflink 列，需解析 HTML
表结构	TAP_SCHEMA.columns	按 table_name 筛

附录 B 表清单与规模

表名	行数	列数	记账单位
ps	40,350	355	行星 × 参数集，含候选投递
pscomppars	6,451	399	行星
cumulative	9,564	153	Kepler 感兴趣目标
toi	8,151	90	TESS 感兴趣目标
k2pandc	4,077	720	K2 目标，行星与候选混编
td	36,477	128	阈值穿越事件
ml	915	442	微引力透镜行星
spectra	1,875	13	光谱索引
emissionspec	2,361	—	发射光谱观测
transitspec	5,948	—	透射光谱观测
stellarhosts	48,101	136	恒星
object_aliases	3,892,385	—	名称别名
nexolist	763	—	大气观测清单

行数与列数均为 2026-10-29 从 TAP 端点返回值；未标列数的表以官方文档描述为准。

编辑说明

核验时间：2026-10-29。核验方式：抓取官方计数页、收录标准页、致谢页、被移除目标页、馆藏页与文档索引页原文；通过 TAP 同步端点实际执行 ADQL 查询，逐一取得 ps、pscomppars、cumulative、toi、k2pandc、td、ml、spectra、emissionspec、transitspec、stellarhosts、object_aliases、nexolist 的行数与列数，并核对 default_flag、soltype、pl_bmassprov、pl_controv_flag、tfopwg_disp、koi_disposition 的取值分布；以 CSV 与 JSON 两种格式各取一次含空值记录，确认缺失值的表现形式；对 Kepler-1921 c 在两张表中的记录做了逐字段比对。未能核实：批量下载的实际打包体积与文件数；spec_path 指向的内部文件系统在归档外的可达性；商业使用的具体边界，官方未给出可引用的条款。版本说明：全文数字为 2026-10-29 快照，该库每日变动，引用时应重新取数。

---

相关数据集导航

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

• soilgrids — 共享标签：多模态 / 评测基准 / 图像分类
• randolph-glacier-inventory — 共享标签：多模态 / 评测基准 / 图像分类
• gaia-dr3 — 共享标签：多模态 / 评测基准 / 图像分类
• cern-cms-opendata — 共享标签：多模态 / 评测基准 / 图像分类
• sdss-dr20 — 共享标签：多模态 / 评测基准 / 图像分类
• esa-worldcover — 共享标签：多模态 / 评测基准 / 图像分类
• alma-archive — 共享标签：多模态 / 评测基准
• opentme — 共享标签：多模态 / 评测基准 / 图像分类
• qmugs — 共享标签：多模态 / 评测基准
• cornorb — 共享标签：多模态 / 图像分类

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