TriALS-Report — 多中心腹部非增强 CT 诊断与报告生成基准

INFOBOX — TriALS-Report 一屏速览

维度	内容
本质	1,254 例多中心腹部非增强期（NCCT）CT 基准：诊断（232 项影像所见多标签）+ 报告生成（跨相位推理）双任务
团队	Ain Shams University（埃及，4 人）+ HKUST（2 人，通讯 Marawan Elbatel）+ University of Catania + Universitat de Barcelona，共 8 作者 4 机构
论文	A Multi-Center Benchmark for Abdominal Disease Diagnosis and Report Generation from Non-Contrast CT（arXiv 2606.16991，2026-06-15 v1）；MICCAI 2026 Early Accept（top ~9%）+ Spotlight
数据	1,254 例 NCCT 体积：Center 1 内部 1,085（训 760 / 验 106 / 测 219）+ Center 2 外部测试 169；512×512、面内 0.875×0.875 mm、层厚 1.07 mm
标签	232 项影像所见二值多标签，从同患者增强期放射报告自动提取；词典 53 病 × 16 器官（另有 15/51 排除 Multi-organ 口径）
双任务	① 232 维多标签诊断（frozen encoder + linear probe）；② 报告生成：增强期报告文本为参考、仅输入非增强图像（跨相位推理）
评估	5 种编码器架构；AUC 双口径：摘要 69.1%（internal）/63.1%（external）vs README 71.1%/66.2%；zero-shot DAMO RADAR 单病变 AUC 67.61-92.42
许可	CC BY-NC 4.0；HuggingFace gated: manual（非商业学术声明制）；无 checkpoint 发布
获取	huggingface-cli download marwankefah/TriALS-Report --repo-type dataset（需先申请获批）
库内关系	姊妹条目 trials(661)（TriALS 肝病变分割基准，同团队）；近邻 trialbench(46)、aact(230)、synthrad(671)

TriALS-Report（读取为「Tri-ALS Report」，与三期增强腹部 CT 的 triphasic 一语相关，官方材料未对命名作明确释义）是一个发表于 MICCAI 2026 的多中心腹部 CT 基准数据集，由埃及 Ain Shams University 与香港科技大学（HKUST）牵头的四机构团队构建，论文于 2026 年 6 月 15 日首次公开于 arXiv（编号 2606.16991），获 MICCAI 2026 Early Accept（约前 9%）与 Spotlight 报告资格。数据集的核心设定是：医院里最容易拿到、辐射剂量最低、不需要注射对比剂的腹部非增强 CT（NCCT），能不能承担起原本依赖增强 CT（CECT）才能完成的疾病诊断与结构化报告任务。

为实现这一目标，作者们设计了一条「借报告」的监督通路：每位患者同时拥有三期增强检查（triphasic CT）的非增强期体积与放射科医生针对增强期图像书写的报告文本，研究者从报告中提取 232 项影像所见（findings）作为二值多标签，把「增强期报告」当成「非增强图像」的监督信号——诊断任务由此变为 232 维多标签分类，报告生成任务则要求模型在只看非增强图像的条件下产出与增强期报告对齐的文本，即「跨相位推理（cross-phase reasoning）」。

数据规模上，TriALS-Report 收录 1,254 例：Center 1 为内部数据集（训练 760 / 验证 106 / 测试 219，合计 1,085 例），Center 2 为外部独立测试集（169 例）。词典层组织为 53 种疾病 × 16 个器官（论文另一处口径为排除 Multi-organ 类后的 15 器官/51 病，本条目在 §5 与附录中双口径存照）。数据以 CC BY-NC 4.0 许可发布于 HuggingFace（marwankefah/TriALS-Report），采用 gated: manual 访问制——申请者须填写姓名、机构、国家、身份并勾选非商业学术使用承诺，由作者人工批准后下载。

本条目面向医学影像 AI 研究者、报告生成团队与数据集方法学研究者，按「是什么—怎么构成—怎么标注—怎么评估—怎么获取—怎么避坑」的顺序展开，并在 §10 给出八条避坑清单、在 §9 给出与本库（千方病案医数集）相近条目的互链与去混淆说明。

条目写作与核验说明：本条目全部硬数字经三源互证（arXiv / HuggingFace / GitHub，轨迹见附录 I），双口径冲突（AUC、词典规模）逐条存照于 §9.3 并在正文对应位置（坑 3、坑 4）给出引用话术；截至 2026-10-09 无法核验的事项（Center 2 来源属性、MICCAI 2026 具体会期等）一律以「遗留疑点」标注而非推断补齐。成稿不含任何未注明出处的数字——读者若发现数字与官方材料不符，以官方材料为准并向本库反馈。

§0 导读

0.1 这篇条目适合谁

• 医学影像 AI 研究者：需要腹部 CT 多标签诊断基准、关注 frozen encoder + linear probe 范式与 organ-level AUC 评估协议者；
• 报告生成团队：关心「平扫输入 × 增强期参考文本」这一跨相位报告生成设定与其监督来源者；
• 多中心数据集构建者：想复用「从既有放射报告自动提取标签」的蒸馏式标注流水线，需要了解其噪声来源与验证缺口者；
• 基础模型评测者：需要 abdomen-specific（Pillar-0）、chest-specific（Merlin）与 general-purpose multimodal（DAMO RADAR）三类编码器的横向对比协议者；
• 数据工程与合规人员：需要确认 CC BY-NC 4.0 + gated: manual 的获取流程与非商业边界者。

0.2 三分钟速览

1. 一条监督通路：同患者三期增强检查中，增强期放射报告（文本）→ 提取 232 项影像所见（多标签）→ 监督非增强期图像（NCCT 体积）。标签不是人工逐例标注，而是报告文本的结构化蒸馏，这是效率来源，也是噪声来源。
2. 两个任务：诊断 = 232 维多标签二分类（threshold 0.5，BCEWithLogitsLoss）；报告生成 = 以增强期报告为参考文本、仅输入非增强图像的跨相位生成。
3. 三层数据组织：体积层（NIfTI .nii.gz，512×512、0.875×0.875 mm 面内、1.07 mm 层厚）→ 标签层（labels.csv：patient_id/center/split/image + 232 个 finding 列）→ 词典层（label_dictionary.csv：column/organ/question，53 病 × 16 器官）。
4. 两中心一内外：Center 1 内部 1,085 例（760/106/219），Center 2 外部 169 例仅作测试，用于泛化评估。
5. 五个编码器一次比武：chest-specific、abdomen-specific（Pillar-0）、general-purpose multimodal（Merlin、DAMO RADAR 等）五架构在同一协议下比较；诊断用 organ-level AUC/F1 + 1,000 次 patient-level bootstrap。
6. 两个口径要分清：主结果 AUC 有摘要口径（69.1%/63.1%）与 README 口径（71.1%/66.2%）之别；词典有 53/16 与 51/15 之别。引用前先看 §10 坑 3 与坑 4。
7. 一个许可边界：CC BY-NC 4.0 + HF gated: manual，非商业学术用途声明制；无预训练 checkpoint 发布。

0.3 与库内相近条目的差异

• 与 trials（rid 661）：名称极度相似但是两个不同数据集——trials 是同一团队（xmed-lab / marwankefah）的 TriALS 肝病变分割基准（MICCAI 2024/2025 系，arXiv 2605.16572），TriALS-Report 是其延伸出的腹部多器官诊断+报告生成基准（MICCAI 2026，arXiv 2606.16991）。姊妹工作、非别名，详见 §9.1 去混淆。
• 与 trialbench（rid 46）：TriALBench 是放射影像通用基准集，覆盖任务面更宽；TriALS-Report 聚焦腹部 NCCT 的诊断与报告双任务。
• 与 radgraph（rid 561）、radgraph2-radiology-reports(622)、radialog-instruct-dataset(625)、radvlm-instruction-dataset(624)：那些条目的标注/指令来自胸部或通用放射报告；TriALS-Report 的 232 项 findings 提取自腹部增强期报告，且监督对象是 CT 体积而非纯文本。
• 与 synthrad（rid 671）：SynthRAD 用合成增强 CT 补平扫信息缺口（图像到图像）；TriALS-Report 用增强期报告文本补平扫监督缺口（文本到图像），同一问题（NCCT 信息不足）的两条互补路线，详见 §8.2。

0.5 条目使用地图（按目的跳转）

你的目的	直接跳转	配套阅读
判断这是不是我要的数据集	§1 Q1/Q2、INFOBOX	§0.2 速览
下载与安装	§6.2-6.3、附录 D 决策树	坑 6、Q14/Q15
理解标签从哪来、可信度多大	§4.3、§4.5	坑 1、Q2/Q25
跑通诊断基线并对齐官方数字	§4.2、§5.2、附录 F	坑 2/坑 3、§2.7
设计报告生成实验	§4.4、§5.4	坑 8、Q10/Q11
写论文的方法/局限段落	附录 G 模板、§9.3 存照	坑 3/坑 4
找相似数据集/定位生态位	§9.2、附录 H	Q19/Q28/Q31
核对本条目每个数字的出处	附录 C 证据链、附录 I 核验存照	§9.3

0.6 如何引用本条目与数据集

• 本条目：千方病案医数集 AI-Ready Wikipedia，条目 trials-report，https://www.qianfanghub.com/ai-ready-dataset/trials-report/941。
• 数据集（论文 BibTeX 原样）：

@misc{elbakry2026multicenterbenchmarkabdominaldisease,
      title={A Multi-Center Benchmark for Abdominal Disease Diagnosis and Report Generation from Non-Contrast CT},
      author={Mariam Elbakry and Aliaa Sayed Sheha and Salma Hassan Tantawy and Aya Yassin and Xiaomeng Li and Concetto Spampinato and Karim Lekadir and Marawan Elbatel},
      year={2026},
      eprint={2606.16991},
      archivePrefix={arXiv},
      primaryClass={cs.CV},
      url={https://arxiv.org/abs/2606.16991}
}

• 数据仓库：HuggingFace Datasets marwankefah/TriALS-Report；代码仓库：GitHub xmed-lab/TriALS-Report。
• 评估工具链：RATE-Evals（marwankefah/rate-evals）与 rad-vision-engine / RAVE（yalalab/rave）。

§1 十问十答

Q1：TriALS-Report 的数据规模到底多大？

1,254 例腹部 CT 体积（patients/volumes），全部为非增强期。内部 Center 1 共 1,085 例，按 760（训练）/ 106（验证）/ 219（测试）三分；外部 Center 2 共 169 例，仅作测试。标签侧每例携带 232 个二值 finding 列；词典层为 53 种疾病 × 16 个器官（另一处口径 15 器官/51 病，系排除 Multi-organ 类后的净口径，见坑 4）。注意：HF 仓库 tags 标注 size 为 1K<n<10K，与 1,254 一致；downloads 数（抓取时点 26 次，截至 2026-10-09）仅为热度参考、与数据质量无关。

Q2：232 项影像所见是什么、从哪来？

232 项 findings 是从同一患者增强期放射报告文本中自动提取的影像所见条目，覆盖肝脏（10 种疾病）、胰腺（3 种疾病）等 16 个器官。每项在 labels.csv 中是一列，取值为二值（阳性/阴性），诊断任务即对这 232 维做多标签分类。器官-疾病分布示例：肝脏包括肝细胞癌（HCC）、肝转移瘤、肝囊肿等 10 类；胰腺包括胰腺肿瘤等 3 类；另有 Multi-organ 跨器官类别（不同口径计数差异即源于此）。完整逐项结构见附录 B。关键方法论特征：这些标签没有逐例人工复核存证，报告里漏写或表述含糊的所见会直接变成标签噪声（见 §4.3 与坑 1）。

Q3：诊断任务具体怎么做？

输入非增强期 CT 体积，输出 232 维多标签二分类。官方协议：冻结编码器（frozen encoder），在其特征上接线性探针 nn.Linear(D, 232)，损失为 BCEWithLogitsLoss（按类别频率加 pos_weight），Adam 优化器 lr 1e-3，batch size 8192，最多 1,000 epochs，推理阈值 0.5。评估按器官层聚合 AUC 与 F1，用 1,000 次 patient-level bootstrap 估置信区间。五个对比架构横跨 chest-specific、abdomen-specific（Pillar-0）与 general-purpose multimodal（Merlin 等）三类。

Q4：报告生成任务为什么叫「跨相位推理」？

因为监督文本与输入图像来自不同的增强相位：参考文本是放射科医生看着增强期图像写的报告，模型却只能看到非增强期图像。模型必须从平扫征象推断增强期才能确认的所见（或承认不可见），并把 232 项所见组织成结构化报告文本。这一设定同时带来两个后果：一是任务有原理性上限——部分病变（如富血供转移灶的强化模式）在平扫上不可见或不典型；二是参考文本天然含「报告写作惯例噪声」，评估需借助 RATE-Evals / RAVE 工具链（见 §5.4）。仓库未随数据发布报告生成 checkpoint，复现需自行训练（坑 8）。

Q5：AUC 主结果到底是 69.1% 还是 71.1%？

两个口径都官方，但语境不同，必须注明出处再引用。arXiv 摘要口径：internal 69.1%、external 63.1%；GitHub README 口径：71.1%、66.2%（README 表格：internal Pillar-0 69.92 / Merlin 71.05，external Pillar-0 65.71 / Merlin 66.24）。官方解释：论文 runs 固定 1,000 epochs、无验证、未设随机种子；代码版设了 seed 且按验证集挑 epoch，因此数字略高。引用建议：引论文结论用摘要口径，引开源复现基线用 README 口径并说明种子与早停差异。详见 §5.2 与坑 3。

Q6：怎么获取数据？

三步：① 在 HuggingFace 数据集页 marwankefah/TriALS-Report 申请访问——仓库 gated: manual，需填写 Full name / Institution / Country / Role 并勾选「仅用于非商业学术研究」承诺框，等待作者人工批准；② 获批后 huggingface-cli download marwankefah/TriALS-Report --repo-type dataset（网络受限环境走 hf-mirror.com）；③ 仓库含两个 config：labels（splits: center1 / center2）与 label_dictionary。注意 HF 原始 raw 端点对 gated 仓库有锁定（未登录拿不到文件树），获批后经 CLI 下载不受影响。

Q7：能商用吗？

不能。许可为 CC BY-NC 4.0（NonCommercial），HF gated 表单亦要求勾选非商业学术用途承诺。衍生模型、论文与教学用途通常可用，任何商业部署（含商业产品集成、商业服务后端）均超出许可边界。注意 CC BY-NC 4.0 同时要求署名（BY）：引用论文 + 标注数据来源。未提供「商业授权另谈」通道的公开信息。

Q8：与库内 trials(661) 是同一个数据集吗？

不是，是姊妹工作。trials(661) = TriALS：肝病变分割基准，MICCAI 2024/2025 系工作，arXiv 2605.16572；TriALS-Report = 腹部多器官诊断+报告生成基准，MICCAI 2026，arXiv 2606.16991。两者共享团队（xmed-lab / marwankefah，HKUST Marawan Elbatel 系）、共享「TriALS」品牌词根、GitHub 组织同为 xmed-lab，极易混淆。区分锚点：看任务（分割 vs 多标签诊断+报告生成）、看 arXiv 号、看器官范围（肝 vs 16 器官）。详见 §9.1。

Q9：数据是怎么组织的（文件结构）？

仓库两层：词典层 label_dictionary.csv（列：column / organ / question，把 232 个 finding 列名映射到器官与问句）；数据层 Center 1/ 与 Center 2/ 同构——labels.csv（patient_id / center / split / image + 232 个 finding 列）+ ct/<patient_id>.nii.gz（每例一文件）。HF Datasets 配置为 labels（center1/center2 splits）与 label_dictionary 两个 config。Center 2 的 labels.csv 与 Center 1 同构，split 列标外部测试。逐字段说明见 §2.3。

Q10：最大的坑是什么？

八条避坑清单见 §10，最要紧的三条：坑 1——标签是报告蒸馏不是人工标注，直接拿来当 ground truth 要先想清楚噪声预算；坑 3——AUC 双口径（摘要 vs README）引用前必须注明；坑 4——词典双口径（53/16 vs 51/15）计数引用前必须注明。其余（Center 2 来源不明、gated 等批、raw 端点锁定、无 checkpoint、包名易混）见 §10 全表。

§2 数据构成：三层组织一次讲清

2.1 一张图看懂数据流水线

TriALS-Report 的每个样本都锚定一次三期增强腹部 CT 检查（triphasic CT），从中拆出两条轨：

一次腹部三期增强检查
├── 图像轨：非增强期（NCCT）体积 ──────────► 模型输入（512×512，0.875×0.875 mm 面内，1.07 mm 层厚）
└── 文本轨：放射科针对增强期书写的报告 ──► 自动提取 232 项影像所见 ──► 多标签 + 报告生成参考文本

诊断任务的监督信号、报告生成任务的参考文本，都来自文本轨；而模型能看到的只有图像轨。这个「文本监督图像、跨相位对齐」的结构是整个数据集的设计核心，也是所有方法学争议（噪声、上限、口径）的根源。

2.2 体积层：NCCT 体积（NIfTI）

• 格式：每例一个 NIfTI 压缩文件 ct/<patient_id>.nii.gz，患者 id 即文件名主键；
• 矩阵：512 × 512（轴向面内分辨率）；
• 面内间距：0.875 × 0.875 mm；
• 层厚：1.07 mm；
• 相位：全部为三期增强检查中的非增强期（plain/NCCT）。动脉期、静脉期等增强相位图像不在发布范围内——发布的是「平扫图像 + 增强期报告」的组合，这正是跨相位推理设定的物化形态。

体积层不含增强期图像这一点有两层含义：其一，想训练「平扫→增强」图像翻译的团队应转向库内 synthrad（rid 671）一类条目；其二，任何试图用本数据验证「平扫征象能否替代强化信息」的实验，参考答案只有报告文本而非增强图像本身（见 §8.2）。

2.3 标签层：labels.csv 字段逐个说明

Center 1/labels.csv 与 Center 2/labels.csv 同构，每行一位患者：

字段	含义	备注
patient_id	患者主键	与 ct/<patient_id>.nii.gz 一一对应
center	来源中心标识	Center 1 内部 / Center 2 外部
split	划分标签	Center 1 内 train 760 / val 106 / test 219；Center 2 全部为外部测试
image	图像引用	指向对应 NIfTI 体积
232 个 finding 列	每列一个影像所见	二值标签（阳性/阴性），列名经 label_dictionary 映射到器官与问句

三个 split 的规模与用途：

split	例数	用途
Center 1 train	760	训练 linear probe / 微调 / 报告生成训练
Center 1 val	106	模型选择（代码版口径按验证集挑 epoch，见坑 3）
Center 1 test	219	内部测试（internal AUC 口径）
Center 2 test	169	外部测试（external AUC 口径），不参与任何训练

设计上的两个注意点：① 划分是患者级的，评估置信区间也用 1,000 次 patient-level bootstrap，避免同一患者多检查造成的泄漏；② 232 列直接平铺在一张表里，做多标签分析时建议先 melt 成长表再接词典。

2.4 词典层：label_dictionary.csv 与疾病-器官分类

label_dictionary.csv 三列：column（labels.csv 中的 finding 列名）、organ（所属器官）、question（该所见对应的临床问句表述）。它把 232 个扁平标签组织成53 种疾病 × 16 个器官的分类体系（主口径）。

器官-疾病分布的已存证样例：

• 肝脏（10 种疾病）：包括肝细胞癌（HCC）、肝转移瘤（hepatic metastasis）、肝囊肿等 10 类；
• 胰腺（3 种疾病）：以胰腺肿瘤（pancreatic tumor）为核心的 3 类；
• Multi-organ（跨器官）：覆盖不限定单一器官的所见。

口径提示（坑 4 预告）：材料中另有一处 15 器官 / 51 病的计数，为排除 Multi-organ 类后的净口径——53−51 = 2、16−15 = 1 的差额对应 Multi-organ 类与其疾病归属。两种口径都出自官方材料，引用时必须注明含不含 Multi-organ（详见 §10 坑 4 与 §9 存照）。

2.5 HF 仓库形态：configs 与 tags

HuggingFace Datasets 仓库 marwankefah/TriALS-Report 提供：

• config labels：主体标签数据，含两个 splits——center1 与 center2；
• config label_dictionary：232 项所见的词典表；
• 仓库 tags（抓取时点）：size 类 1K<n<10K（与 1,254 例一致）、format csv、task image-classification 等；
• gated 状态：gated: manual，附 extra_gated 表单（Full name / Institution / Country / Role 四字段 + 非商业学术用途 checkbox），作者人工审批后放行。

仓库元数据快照：createdAt 2026-09-21，lastModified 2026-09-22，downloads 26（截至 2026-10-09 抓取，热度参考值、随时间变化）。raw 端点坑：HF 原始 raw 端点对 gated 仓库锁定，未登录状态拿不到文件树；获批后走 CLI 下载不受影响（见坑 6）。

2.6 代码仓库与论文的对应关系

GitHub xmed-lab/TriALS-Report（repo id 1246590622）承载训练与评估代码：linear probe 训练脚本、232 维探针定义、organ-level AUC/F1 与 bootstrap 评估、报告生成评估对接 RATE-Evals / RAVE。仓库 README 的结果表格与论文摘要数字存在系统性差异（README 略高），官方归因于「论文 runs 无种子无验证、代码版有种子有验证选 epoch」——这是开源复现场景里少见地被作者主动解释的双口径（详见 §5.2、坑 3）。

2.7 使用前数据体检清单（下载完成后第一天做）

拿到数据后不要直接开训，先跑一遍体检，把口径问题挡在实验之前：

1. 完整性：Center 1/ct/ 与 Center 2/ct/ 的 .nii.gz 数量应分别为 1,085 与 169，且与各自 labels.csv 行数一致；文件名与 patient_id 列一一对应，无孤儿文件；
2. split 核对：Center 1 labels.csv 的 split 列计数应为 train 760 / val 106 / test 219；Center 2 的 split 应全为测试属性；任何重组 split 的行为都会破坏与官方数字的可比性；
3. 词典对齐：labels.csv 的 232 个 finding 列名与 label_dictionary.csv 的 column 列完全对齐（多列/少列/改名都会让 organ-level 聚合错位）；
4. 头信息抽检：随机抽 20 例读 NIfTI 头，核对面内间距 0.875×0.875 mm、层厚 1.07 mm 的实际值——材料口径与个别例的头信息可能存在漂移，预处理前以头信息为准并记录例外清单；
5. 标签分布速览：按器官分组统计阳性率，识别极端稀疏的 finding 列（pos_weight 已内置缓解，但训练前仍应知道哪些列几乎全阴/全阳）；
6. gap 预案：Center 2 无 val 分割，若你的方法需要二段调参，只能用 Center 1 val，绝不在 Center 2 上做任何选择（坑 2 的前半条）。

体检结果建议写入你自己的复现 README，与官方口径的差异（如头信息例外）逐条存照——这正是本条目 §9.3 存照风格的个人版。

2.8 与库内近邻条目的规模与形态对照

条目（rid）	模态/任务	与 TriALS-Report 的关系
trials（661）	腹部 CT / 肝病变分割	同团队前作；本集无掩码，分割需求导流至此
trialbench（46）	放射影像多任务基准	任务面更宽的泛基准；本集聚焦腹部 NCCT 双任务
rad-chestct（819）	胸部 CT + 报告配对	「体积+报告」同构范式的胸部版本
synthrad（671）	头颈/胸部/腹部 合成增强 CT	NCCT 信息缺口的图像路线对照（§8.2）
radgraph（561）	放射报告 token 级结构化	「报告→结构化」的文本精标注端（附录 A.3）

对照读法：本集在库内的独特位置 = 腹部 + 平扫 + 图像级多标签 + 跨相位文本监督四要素同时成立的唯一条目；任何一个单独要素都有更专门的条目，组合要素是它不可替代的原因。

§3 多中心设计与采集背景

3.1 两中心分工：一内一外

TriALS-Report 采用「内部开发 + 外部验收」的经典两中心设计：

• Center 1（内部）：1,085 例，是唯一可训练的中心，train/val/test = 760/106/219。模型开发、超参选择、阈值设定全部在此完成；
• Center 2（外部）：169 例，仅作测试。它模拟「换一家医院、换一台扫描仪、换一批读片医生」后的性能衰减，对应 external AUC 口径。

这种设计让「internal 69.1% / external 63.1%（摘要口径）」的落差成为数据集方法论叙事的一部分：跨中心泛化损失约 6 个百分点（README 口径约 5 个百分点），是腹部 NCCT 任务跨站点鲁棒性的实证参考值。

3.2 三期增强检查：监督文本从哪一期来

每位入选患者都做过三期增强腹部 CT（triphasic CT）——即包含非增强期与多个增强期位的完整检查。放射科医生的报告针对增强期图像书写（这是临床常规：强化模式是腹部诊断的关键证据）。数据集把报告文本「搬」给非增强期当监督，等价于假设：增强期报告里的所见集合，是平扫图像任务的合理目标。

这一假设的强度因所见而异，可按「平扫可见性」三级分层：

强度层	所见类型举例	跨相位假设的合理性
稳	囊肿、结石、器官形态异常、占位存在性	平扫直接可见或高度可推断
中	病变边界、大小变化、部分鉴别诊断	平扫部分可见，需间接征象推断
弱	富血供 vs 乏血供强化模式、HCC 强化廓清	平扫原理性信息不足，标签含「不可确认」成分

对「弱」层所见的模型输出应保留解释余地——它们是 232 维里天然最不确定的部分，也是 §4.5 抽检 SOP 中「无法判断」比例的预期高发区。

3.3 患者级组织与防泄漏设计

• 主键唯一：patient_id 贯穿 labels.csv 行、ct/*.nii.gz 文件名与 bootstrap 重采样单元；
• split 隔离：Center 2 与 Center 1 天然隔离；Center 1 内部三分亦按患者划分；
• 评估单位：organ-level AUC/F1 的置信区间用 1,000 次 patient-level bootstrap——重采样在患者层而非标签层进行，避免同一患者的 232 列相关性造成区间过窄；
• 外部集「只测不调」：Center 2 无 val 分割，任何在 Center 2 上的选择行为（挑阈值、挑 epoch）都会破坏其外部性质，复现时应保持其纯测试身份。

3.4 外部中心的信息缺口（遗留疑点）

可获取的官方材料（论文、HF 卡、GitHub README）未明示 Center 2 的来源国别与机构，仅以「外部中心」指代。这带来两个实际影响：其一，评估「外部泛化」时无法判断外部中心的人群/设备/协议差异方向；其二，跨中心结论的适用范围（同区域泛化 vs 跨洲泛化）无法标定。本条目将此列为遗留疑点存照（§9.3），引用外部结果时建议只述「外部测试集 169 例」而不推断其来源属性。

3.5 患者级数据模型（文本版 ER 图）

label_dictionary.csv (column, organ, question)   ← 词典层：232 行
        │ column 名作为连接键
        ▼
Center 1/labels.csv (patient_id, center, split, image, f_001...f_232)
Center 2/labels.csv (同构，split=外部测试)         ← 标签层：每行一患者
        │ patient_id 作为连接键
        ▼
Center 1/ct/<patient_id>.nii.gz
Center 2/ct/<patient_id>.nii.gz                   ← 体积层：每患者一文件

HF Datasets 映射：
  config=labels           → 两张 labels.csv（splits: center1 / center2）
  config=label_dictionary → 词典表

三条完整性不变式（体检与使用全程都要守）：

1. labels.csv 行数 = ct/ 下 .nii.gz 文件数（Center 1 为 1,085，Center 2 为 169）；
2. labels.csv 的 finding 列集合 = label_dictionary 的 column 集合（双向无差集）；
3. patient_id 在 split 间不重复（患者级划分不被打破）。

3.6 与「多中心」叙事相关的方法学细节

• 词典（53 病/16 器官）对两中心统一，Center 2 沿用 Center 1 的 232 列，保证外部评估标签空间一致；
• 232 项所见的提取流水线对两中心一致（同一报告解析设定），不存在「外部集用另一套标签规则」的问题；
• 体积预处理参数（512×512、0.875 mm、1.07 mm）为数据集口径，两中心一致呈现于材料；个别中心原始采集参数是否完全同质未逐层披露，复现预处理时以 NIfTI 头信息为准。

§4 任务定义与标注方法学

4.1 双任务总览

TriALS-Report 在同一份数据上定义两个互补任务：

任务	输入	输出	监督来源	官方协议
诊断（Disease Diagnosis）	NCCT 体积	232 维多标签二值向量	增强期报告提取的 findings	frozen encoder + linear probe，BCE，阈值 0.5
报告生成（Report Generation）	NCCT 体积	结构化放射报告文本	增强期报告文本（作参考文本）	跨相位推理；评估经 RATE-Evals / RAVE 工具链

两个任务共享同一监督源头（增强期报告），差别只在监督的形态：诊断任务把报告离散化为 232 个二值标签，报告生成任务保留报告的文本形态。因此诊断任务的标签噪声会以不同方式传导进报告生成任务（漏写的所见既缺标签也缺文本描述）。

4.2 诊断任务：232 维多标签分类

• 标签空间：232 项影像所见，每项独立二值；词典层将其组织为 53 病 × 16 器官（主口径）。器官级聚合评估的意义在于：单项 finding 样本量可能很小，器官层 AUC/F1 比逐项指标更稳，也更贴近「腹部这个器官系统整体诊断能力」这一临床问题。
• 官方基线协议（代码仓库实现）：
  1. 编码器冻结（frozen encoder），只取其全局特征向量（维度 D）；
  2. 线性探针 nn.Linear(D, 232)，输出 232 维 logits；
  3. 损失 BCEWithLogitsLoss，按类别频率设 pos_weight 缓解正例稀疏；
  4. 优化器 Adam，学习率 1e-3；
  5. batch size 8192（特征级训练，非端到端 CT 训练，故 batch 可极大）；
  6. 最多 1,000 epochs；代码版按验证集选最优 epoch 并设随机种子，论文版固定 1,000 epochs、无验证、无种子（双口径根源，坑 3）；
  7. 推理阈值 0.5。
• 指标：organ-level AUC 与 F1，1,000 次 patient-level bootstrap 给出区间。

对使用者的含义：这套协议是**特征评测（feature evaluation）**而非端到端训练基准——它衡量「编码器的腹部 CT 特征里有多少诊断信息可被线性读出」，非常适合基础模型横向比较；想端到端微调的团队需要自行设计 3D 训练管线，数据集本身不限定。

4.3 标注方法学：报告蒸馏的收益与代价

TriALS-Report 的标签不是标注员逐例勾选的，而是从放射报告文本**自动提取（蒸馏）**的。这条路的选择逻辑很现实：1,254 例 × 232 项 = 近 29 万个标注决策，人工逐例复核成本极高；而腹部增强检查的报告是临床必产文书，天然大规模存在。

收益：

• 规模可行：232 个标签位全覆盖，无需分批标注；
• 语义对齐临床：标签体系以「报告里实际会写的所见」为单位（label_dictionary 的 question 列即问句化表述），而非教科书式疾病清单；
• 可扩展：同型流水线可迁移到其他报告语料（同团队姊妹工作即用于赞比亚宫颈癌 CT 报告场景，MICCAI 2026 Workshop AFRICAI）。

代价（也是使用前必须接受的前提）：

• 无逐例复核存证：232 项提取质量未提供逐条人工验证的公开材料；报告漏写 → 假阴性标签；表述歧义/简写 → 提取歧义；
• 阴性标签是「未提及」而非「确认阴性」：报告未提某所见，可能是阴性，也可能是遗漏——蒸馏式多标签的经典困境；
• 跨相位错位：报告描述增强期表现，标签却用于监督平扫模型，个别所见存在原理性不可见（坑 1 展开）。

使用建议：把 232 维标签当作「报告一致性的弱监督」而非金标准；对高风险应用（如 HCC 筛查）先在小样本上人工复核感兴趣子类的标签精度，再决定信任程度。

4.4 报告生成任务：跨相位推理

• 设定：模型输入仅 NCCT 体积；参考文本（reference）为增强期报告。模型输出需在内容上与参考报告对齐，但写作条件劣于报告作者（作者看得到增强期）。
• 与诊断任务的一致性：232 项所见同样是报告生成的内容清单——诊断探针读出的概率向量，理论上可作为报告生成的结构化中间表示，两条任务线可在同一编码器特征上耦合。
• 评估工具：官方把报告生成评估接入 RATE-Evals（marwankefah/rate-evals）与 rad-vision-engine / RAVE（yalalab/rave），覆盖临床域指标与文本指标的组织（具体指标权重以两工具仓库文档为准）。
• 无现成 checkpoint：仓库未发布训练好的报告生成模型；复现者需自备报告生成头（如基于 LLM 的解码器）并在 Center 1 train 上训练（坑 8）。

4.5 标签质量抽检 SOP（补官方缺口的自助动作）

官方材料未提供 232 项提取质量的逐条人工复核存证（§4.3 已述）。把数据用于高风险场景前，建议自行补一个最小抽检闭环：

1. 分层抽样：按 16 个器官 × 高/中/低阳性率三层，抽 100-200 例-所见对（Center 1 test 内抽，别动 Center 2）；
2. 双人独立判读：两名有腹部 CT 阅片经验者对照平扫图像判断该所见「可见/不可见/平扫无法判断」三类；
3. 三个一致性数：标签与图像的一致率（提取精度下界）、「无法判断」比例（跨相位原理性上限的实证大小）、双人 Kappa（你自己的复核质量）；
4. 产出物：一份器官 × 所见的信任度表——高信任子集直接用，低信任子集降权或排除，并在论文里声明抽检范围。

这套 SOP 不改变数据集本身，但把「报告蒸馏弱监督」从口头 caveat 变成可引用的量化证据，也顺手量化了跨相位上限（§4.2 假设的强弱分布）。

4.6 诊断协议代码骨架（协议忠实化伪代码）

以下骨架逐项对应 §4.2 的官方协议参数（nn.Linear(D, 232)、BCEWithLogitsLoss+pos_weight、Adam lr 1e-3、batch 8192、≤1,000 epochs、threshold 0.5），供复现者对照官方仓库时核对参数完整性：

import torch
import torch.nn as nn

# 1) 特征预提取：冻结编码器前向，逐患者落盘特征（避免端到端显存压力）
#    feats = encoder(ct_volume)            # 编码器权重全程 requires_grad=False
#    D = feats.shape[-1]                   # 特征维度因编码器而异

probe = nn.Linear(D, 232)                  # 2) 线性探针：232 维多标签
loss_fn = nn.BCEWithLogitsLoss(
    pos_weight=pos_weight_tensor           # 按训练集类别频率设定（§2.7 体检第 5 项产出）
)
optimizer = torch.optim.Adam(probe.parameters(), lr=1e-3)

for epoch in range(1000):                  # 3) 最多 1,000 epochs
    for feat_batch, label_batch in loader(feats_train, y_train, batch_size=8192):
        logits = probe(feat_batch)         #    (B, 232)
        loss = loss_fn(logits, label_batch.float())
        loss.backward()
        optimizer.step(); optimizer.zero_grad()
    if use_val_early_stop:                 # 4) README 口径：按 Center 1 val 选 epoch + seed
        evaluate(probe, feats_val, y_val)
    # 论文口径：跑满 1,000 epochs、无验证、无种子（坑 3 双口径来源）

probs = torch.sigmoid(probe(feats_test))   # 5) 推理：threshold 0.5 二值化
preds = (probs > 0.5).int()
# 6) 评估：按词典 organ 列分组算 organ-level AUC/F1（§5.8 骨架）

使用声明：骨架用于参数核对与教学，非官方代码复制件；逐行实现以 GitHub xmed-lab/TriALS-Report 为准。

§5 评估基准：五个编码器、两种口径与一个 zero-shot

5.1 五架构同协议比武

论文在统一协议（§4.2 的 linear probe 设定）下比较 5 种编码器架构，按预训练域分三类：

类别	代表	预训练域
chest-specific	Merlin（HF: stanfordmimi/Merlin）	胸部 CT
abdomen-specific	Pillar-0（HF: YalaLab/Pillar0-AbdomenCT）	腹部 CT
general-purpose multimodal	DAMO RADAR（HF: alibaba-damo-academy/damo-radar）等	通用/多模态

这一横向设计回答的问题很聚焦：预训练域与目标域（腹部 NCCT）的匹配度值多少 AUC。答案（见 5.2）是 abdomen-specific 占优，但优势幅度因内外部集而异，且 chest-specific 与 general-purpose 在部分器官上并未全面落败——对「选底座模型」的团队是直接的参考证据。

底座选择的实操建议：追求与官方数字直接可比 → 用 Pillar-0 或 Merlin（官方表格覆盖的两枚）；追求单点性能 → 按 §5.6 四层解读选你的子任务最优者；追求 zero-shot 快速原型 → DAMO RADAR（无需训练）。三条诉求不可兼得，先明确你要哪一个。

5.2 诊断主结果与双口径 AUC（存照）

README 表格口径（代码版：设种子、按验证集选 epoch）：

集合	Pillar-0（abdomen）	Merlin（chest）
Center 1 internal	69.92	71.05
Center 2 external	65.71	66.24

arXiv 摘要口径（论文 runs：1,000 epochs 固定、无验证、无种子）：internal 69.1%、external 63.1%；GitHub README 复述口径：71.1% / 66.2%。

官方解释（原样存照）：论文 runs 固定 1,000 epochs、无验证、未设 seed；代码版设 seed 且按验证集挑 epoch，故数字系统性略高。

本条目引用建议：论文语境引 69.1%/63.1%；开源复现/基线对比语境引 README 表格值并注明「seed + 验证集早停口径」。两口径差 1-3 个百分点，量级不影响结论方向（abdomen-specific ≥ chest-specific、external < internal），但会让逐位对比失真——任何「我的方法比官方高 0.5 个点」类结论在此数据集上都不具备口径免疫力（坑 3）。

外部落差也有方向性信息：摘要口径下 external 比 internal 低 6.0 个点（69.1→63.1），README 口径低约 4.9-5.4 个点——腹部 NCCT 诊断的跨中心衰减量级在 5-6 个 AUC 点，可作为同类任务的先验预期。

5.3 zero-shot 参照：DAMO RADAR 的单病变 AUC

作为「不看 TriALS-Report 训练数据」的参照系，论文给出 DAMO RADAR 在 388 个测试体积上的 zero-shot 单病变分类 AUC：

病变	zero-shot AUC
肝细胞癌（HCC）	92.42
胰腺肿瘤（pancreatic tumor）	91.26
肝转移瘤（hepatic metastasis）	87.12
结肠相关所见（colonic）	67.61

metastatic 子任务（n=92）的横向对比：Pillar-0 71.06 / Merlin 71.63 / DAMO RADAR 68.56——zero-shot 通用多模态模型在该子任务上未胜过有监督 linear probe，但差距不大（2-3 个点），提示通用模型的腹部先验已相当可用。

解读要点：HCC/胰腺肿瘤 90+ 的 zero-shot 数字对应的是单病变二分类（子集内正负较平衡的检测任务），不能与 232 维全标签空间下的 organ-level AUC 直接比较——后者的难度来自类别稀疏与阴性标签噪声。跨表引用属口径错误（坑 5）。

5.4 报告生成评估与工具链

• RATE-Evals（marwankefah/rate-evals）：同团队维护的放射报告评估工具集，承担报告生成结果的指标计算；
• RAVE / rad-vision-engine（yalalab/rave）：rad-vision-engine，报告与影像的视觉-文本评估引擎；
• 评估素材：Center 1 test（219 例）与 Center 2（169 例）的增强期报告文本作为 reference。

实践提示：报告生成的 reference 本身是「增强期视角」的文本，自动指标（无论 n-gram 还是 learned metric）衡量的是与增强期报告的相似度；平扫合理的「信息性省略」可能被指标惩罚——这是跨相位设定的评估哲学问题，论文以「跨相位推理」正视它，复现者解读分数时应保留这一层。

5.5 复现要点清单

1. 先跑诊断线（linear probe，特征级，算力门槛低）对齐 README 表格，再碰报告生成线；
2. 设 seed、按 Center 1 val 选 epoch——否则你的数字会落在论文口径而非 README 口径，对照时错位；
3. organ-level 聚合时用词典的 organ 列分组；bootstrap 重采样单元是 patient_id；
4. zero-shot 对比只引用同子任务（单病变二分类）数字，不跨表比较；
5. 报告生成评估走 RATE-Evals/RAVE 官方工具链，避免自定义指标造成不可比。

5.6 五架构结果的解读框架（读到数字之后想什么）

拿到 organ-level AUC 表后，按四层递进解读，避免「只看总分」：

1. 域匹配层：abdomen-specific（Pillar-0）对 abdomen 目标域的先验优势是否兑现？README 口径下 internal 上 Merlin（chest）71.05 反高于 Pillar-0 69.92，external 亦然——「域近 wins」直觉在此不成立，说明编码器预训练配方（数据、目标、尺度）比域标签更重要；
2. 内外落差层：external 落差 5-6 个 AUC 点（两口径）是跨中心稳定性的基准线，你的方法若声称鲁棒性改进，对照线在此；
3. 子任务层：metastatic n=92 的三值对比（71.06/71.63/68.56）显示有监督与 zero-shot 差距仅 2-3 点——通用多模态先验在转移瘤检测上已接近有监督线性读出；
4. 单病变层：HCC 92.42 / 胰腺 91.26 的高位 vs colonic 67.61 的低位，提示 zero-shot 能力按病变类型高度不均（结肠所见更依赖部位定位与视野上下文）。

5.7 organ-level AUC + patient-level bootstrap 计算骨架

import numpy as np
from sklearn.metrics import roc_auc_score, f1_score

# y_true/y_pred: (N_patients, 232)，词典 df_dict 提供 column→organ 映射
organ_groups = df_dict.groupby("organ")["column"].apply(list)

def patient_bootstrap(y_true, y_prob, organs, n_boot=1000, seed=2026):
    rng = np.random.default_rng(seed)
    N = y_true.shape[0]
    idx_all = np.arange(N)
    aucs, f1s = [], []
    for _ in range(n_boot):
        take = rng.choice(idx_all, size=N, replace=True)   # 患者级有放回重采样
        aucs.append(organ_macro_auc(y_true[take], y_prob[take], organs))
        f1s.append(organ_macro_f1(y_true[take], (y_prob[take] > 0.5), organs))
    return np.percentile(aucs, [2.5, 97.5]), np.percentile(f1s, [2.5, 97.5])

def organ_macro_auc(y_t, y_p, organs):     # 器官层：先器官内平均，再器官间宏平均
    per_organ = []
    for cols in organs:
        per_organ.append(np.nanmean(
            [safe_auc(y_t[:, j], y_p[:, j]) for j in cols]))
    return np.nanmean(per_organ)

要点：重采样单元是患者（不是所见列）；nan-safe 处理单 bootstrap 内无正例的列；organ 聚合顺序（器官内平均 → 器官间平均）需与官方仓库核对一致，聚合顺序不同数字会不同。

§6 获取与许可

6.1 许可条款：CC BY-NC 4.0 的边界

数据集以 CC BY-NC 4.0（署名-非商业性使用 4.0 国际） 发布。对本数据集的具体含义：

• 可以：学术研究、论文复现、教学演示、非商业产品原型验证（前提是无商业部署）、基于数据的衍生研究发表（附署名）；
• 不可以：任何商业目的使用——商业产品集成、收费服务后端、以数据或其衍生物直接牟利的训练；商用需另行获得权利人许可（材料未提供商业授权通道）;
• 必须：署名——引用论文（arXiv 2606.16991 / MICCAI 2026）并标明数据来源 HuggingFace marwankefah/TriALS-Report。

HF 仓库的 extra_gated 表单以 checkbox 方式二次确认「仅用于非商业学术研究」，构成访问契约的一部分；获准后改变用途仍受许可约束。

6.2 gated: manual 申请流程（逐步）

1. 登录 HuggingFace 账号，访问数据集页 https://huggingface.co/datasets/marwankefah/TriALS-Report；
2. 在 gated 提示区填写四个字段：Full name（全名）、Institution（机构）、Country（国家）、Role（身份）；
3. 勾选承诺框：「I will use TriALS-Report for non-commercial academic research only」；
4. 提交后等待作者人工批准（manual 制，无自动放行；审批时长取决于作者响应，材料未承诺时限）；
5. 获批后该账号获得下载权，CLI/库调用随账号 token 生效。

注意事项：申请信息应真实填写（机构与身份可核查，虚假声明违反访问契约）；一个账号获批后团队内共享下载违反表单精神，宜各自申请。

6.3 下载与加载

获批后命令行获取：

huggingface-cli download marwankefah/TriALS-Report --repo-type dataset

• 网络受限环境：HF 主站在部分沙箱/地域不可达，可走镜像 hf-mirror.com（设置 HF_ENDPOINT 后同一命令可用）；
• HF Datasets 库加载：config labels（splits: center1 / center2）与 config label_dictionary；CSV 与 NIfTI 混合形态，建议 CLI 落盘后自管文件结构（labels.csv + ct/*.nii.gz）而非流式加载；
• raw 端点：gated 仓库的 raw 文件端点对未授权会话锁定（匿名请求拿不到文件树），属平台行为而非仓库异常；获批后走 CLI 不受影响（坑 6）；
• 体积预估：1,254 个 .nii.gz（512×512 × 数十至上百层）+ 两套 CSV，GB 量级（HF tags 口径 1K<n<10K 样本）；预留磁盘与下载时长。

6.4 合规与引用清单（拿到数据后第一时间做）

• [x] 引用论文 BibTeX（§0.4 原样给出）；
• [x] 标注许可 CC BY-NC 4.0 于衍生仓库/论文数据声明；
• [x] Center 2 仅作测试，不参与训练/调参；
• [x] 患者级 split 不打乱重组；
• [x] 引用 AUC 数字注明口径（摘要 69.1/63.1 或 README 71.1/66.2）；
• [x] 引用词典规模注明口径（53/16 含 Multi-organ 或 51/15 不含）。

6.5 等待审批期的替代工作流（不空转）

manual 审批等待期长短不可控，期间可推进：

1. 读代码不读数据：GitHub 仓库的协议代码不 gated，可先行搭建训练/评估脚手架并自测（合成数据冒烟测试）；
2. 备好体检脚本：§2.7 六项体检写成脚本，获批当天即可执行；
3. 预注册实验设计：把 §5.5 复现要点、坑 2/坑 3 的口径决策写成实验预注册文档，避免拿到数据后临场决定；
4. 用近邻条目热身：rad-chestct(819) 的「体积+报告」结构与本集同构，可先在其上验证你的报告生成管线；
5. 评估工具链预装：RATE-Evals / RAVE 的依赖环境提前配好跑通 demo。

6.6 获取渠道速查

渠道	形态	前置条件
HF 主站	gated: manual 申请 → CLI 下载	账号 + 表单 + 作者批准
hf-mirror.com 镜像	同一 CLI 命令（HF_ENDPOINT 指向镜像）	同上（token 有效）
raw 端点	单文件直取	获批 token；匿名锁定（坑 6）

§7 生态位：模型资产与工具链

7.1 数据集挂靠的模型资产

资产	HF 标识	在本基准中的角色
Pillar-0	YalaLab/Pillar0-AbdomenCT	abdomen-specific 编码器，internal 69.92 / external 65.71（README 口径）
Merlin	stanfordmimi/Merlin	chest-specific 编码器，internal 71.05 / external 66.24（README 口径）；metastatic 子任务 71.63
DAMO RADAR	alibaba-damo-academy/damo-radar	general-purpose multimodal，zero-shot 单病变 AUC 67.61-92.42

7.2 评估工具链

• RATE-Evals（GitHub marwankefah/rate-evals）：放射报告评估工具集，报告生成线官方指标出口；
• RAVE / rad-vision-engine（GitHub yalalab/rave）：视觉-文本评估引擎，与 RATE-Evals 共同覆盖报告生成的多维评估。

7.3 同团队工作图谱

同一作者网络（xmed-lab / marwankefah，HKUST Marawan Elbatel 系）的相邻产出，均与 TriALS-Report 形成方法学互证：

• TriALS（库内 trials，rid 661）：肝病变分割基准，MICCAI 2024/2025 系（arXiv 2605.16572）——TriALS-Report 的腹部影像前作；
• 赞比亚宫颈癌 CT 报告工作（MICCAI 2026 Workshop AFRICAI，OpenReview fpyn7ytdQj）：同型「报告→标签」蒸馏流水线在低资源场景的延伸；
• RATE-Evals / RAVE：评估基础设施。

§8 方法学启示：从 TriALS-Report 能带走什么

8.1 「报告蒸馏标签」范式的复制清单

TriALS-Report 是「既有放射报告 → 结构化标签」蒸馏式标注的又一实证样本。复制该范式前先回答四个问题：

1. 报告语料与图像是否患者级对齐（本集：同一检查的报告与体积）；
2. 标签体系是否问句化、可回溯（本集：label_dictionary 的 column/organ/question 三列，每个标签可追溯到一个临床问句）；
3. 阴性语义是否可接受（本集：未提及 = 阴性，属弱监督前提）；
4. 验证预算怎么留（本集：未公开逐条人工复核材料——复制时应做得更好，抽样复核 + 标注 Kappa 存证）。

四问自评打分（每问 0-2 分，≥6 分再动手复制该范式）：对齐有把握吗 / 问句化做得到吗 / 阴性语义可接受吗 / 复核预算留了吗——任何一问 0 分都意味着你的复制版本会把本集的缺口原样继承甚至放大。

8.2 NCCT 信息缺口的两条互补路线

「只有平扫、想要增强期信息」是腹部 AI 的共性难题，库内两条路线对照：

• 图像路线（synthrad，rid 671）：合成增强 CT，图像到图像，产物可直接喂给依赖强化形态的下游模型；
• 文本路线（本条目）：不合成图像，而是把增强期报告的结论蒸馏给平扫模型——监督在语义层而非像素层。

两者不互斥：文本路线提供「该报什么」，图像路线提供「看起来该是什么样」。混合监督（平扫图像 + 合成增强图像 + 增强期报告蒸馏标签）是值得尝试的组合，TriALS-Report 的 232 维标签与 synthrad 的配对体积在患者层面不可拼接（不同队列），但方法学可组合。

8.3 特征评测协议的参考价值

「frozen encoder + 线性探针 + 器官级聚合 + patient-level bootstrap」这套协议，把基础模型评测从「端到端刷点」拉回「特征里有多少可线性读出的信息」，且计算成本低（batch 8192 的特征级训练）。任何 3D 医学影像数据集都可复用此骨架，只需替换标签维度与器官分组表——这是 TriALS-Report 对评测方法学的可迁移贡献。

8.4 给数据集构建者的十条 checklist（从本条目正反经验提炼）

1. 双口径在成稿阶段就统一或显式并存（本集 AUC、词典两处双口径都是事后解释，成本高于事前统一）；
2. 自动化标注流水线至少留一份抽样人工复核存证（本集最大缺口）；
3. 外部测试集的身份信息（来源属性）要么披露要么说明不可披露原因；
4. gated 表单字段即合规契约，直接把许可边界写进 checkbox；
5. patient 级主键贯穿图像文件名/标签表/重采样单元，防泄漏从数据模型做起；
6. 词典表带问句列（question），让每个标签可回溯到临床语义；
7. 评估协议写成「可复制清单」（编码器/损失/优化器/epochs/阈值/种子逐项给出）；
8. 代码版与论文版实验配置差异主动解释（本集官方解释双口径是加分动作）；
9. 评估工具链独立成仓（RATE-Evals/RAVE 模式），指标可被第三方复跑；
10. README 与论文数字的关系（复述/独立实验）写明，避免读者当第三套结果。

8.5 VLM 视角：TriALS-Report 在多模态谱系中的位置

把本集放进「放射影像 × 语言」的多模态谱系看，它的形态是图像级弱监督 + 报告参考文本：

• 相对 radvlm-instruction-dataset(624)/radialog-instruct-dataset(625) 这类指令微调条目：本集的 question 列（词典层）可程序化生成图像级 VQA 对（image + question + 二值答案），但密度与多样性不及专门指令集——适合做腹部域的预对齐或评测，不适合做指令多样性主力；
• 相对 radgraph(561) 系的报告结构化路线：本集把结构化产物（findings）反向用作图像监督，是「报告→结构化→再监督图像」链条的中段实证；
• 相对 vqa-rad(240) 这类封闭问答基准：本集 232 问句版词典（question 列）是一个规模更大、器官更全的腹部问答骨架，但答案分布受蒸馏噪声影响（坑 1 在问答形态下同样成立）。

对做多模态团队的实用建议：诊断线产出的 232 维概率向量是天然的多模态中间表示——文本侧用 LLM 读报告、图像侧用编码器读体积、两侧在对齐目标上互查，是本集数据模型直接支持的最小多模态系统形态。

§9 库内关系与互链建议

9.1 与 trials(661) 的去混淆（重点）

维度	trials（rid 661）= TriALS	trials-report = TriALS-Report
任务	肝病变分割	232 维多标签诊断 + 报告生成
器官范围	肝脏	16 器官（腹部多器官）
会议线	MICCAI 2024/2025 系	MICCAI 2026（Early Accept + Spotlight）
arXiv	2605.16572	2606.16991
团队	xmed-lab / marwankefah（HKUST 系）	同团队 + Ain Shams 一作团队

识别口诀：同名根「TriALS」，分割是前作（trials），诊断加报告是续作（trials-report）。两库内条目应互相链接并在各自 §9/导语放置去混淆提示。

9.2 建议互链条目（rid 已核）

库内条目	rid	互链理由
trials	661	同团队姊妹作，名称去混淆第一优先
trialbench	46	放射影像通用基准集，任务面参照
clinicaltrials-gov	556	试验登记数据，试验（trials）语义近邻
aact	230	试验衍生分析数据集，名称近邻去混淆
radgraph	561	报告结构化标注范式同源（胸部/通用）
radgraph2-radiology-reports	622	报告语料近邻
radvlm-instruction-dataset	624	放射 VLM 指令数据，报告生成任务近邻
radialog-instruct-dataset	625	放射对话指令数据
rad-chestct	819	CT 体积 + 报告配对范式（胸部）
vqa-rad	240	放射问答基准，诊断问答参照
synthrad	671	NCCT→CECT 信息补偿的图像路线对照

9.3 本条目存照与遗留疑点

双口径存照：

1. AUC 双口径：arXiv 摘要 69.1%（internal）/63.1%（external）vs GitHub README 71.1%/66.2%；README 表格 Pillar-0 69.92/65.71、Merlin 71.05/66.24。官方解释：论文 runs 固定 1,000 epochs、无验证、未设 seed；代码版设 seed 且按验证集选 epoch。两口径均为官方出处，引用必须注明（坑 3）。
2. 词典双口径：53 病/16 器官（主口径，含 Multi-organ）vs 15 器官/51 病（排除 Multi-organ）。差额对应 Multi-organ 类。引用注明口径（坑 4）。
3. README 摘要与表格的关系：71.1%/66.2% 为表格两编码器值的复述级汇总，非第三套实验。

遗留疑点（截至 2026-10-09 抓取）：

1. Center 2 外部测试集来源国别/机构未在可获取材料中明示；
2. MICCAI 2026 主会具体会期未抓取（Early Accept + Spotlight 身份已存证）；
3. HF raw 端点对 gated 仓库锁定，文件树明细以获批后 CLI 实拉为准；
4. downloads 26 与仓库时间戳（createdAt 2026-09-21 / lastModified 2026-09-22）为抓取时点快照，随时间变化；
5. 数据集命名「TriALS-Report」的官方命名释义未明示，本条目仅陈述与 triphasic 的字面关联并存疑。

§10 避坑清单：八坑全解

速查表（每坑一行，详解放后）：

坑	一句话版	详节
坑 1	蒸馏标签 ≠ 金标准，引用带弱监督限定	§10 坑 1
坑 2	Center 2 只终评，不做任何选择	§10 坑 2
坑 3	AUC 双口径逐次注明出处	§10 坑 3
坑 4	词典 53/16 与 51/15 别混写	§10 坑 4
坑 5	zero-shot 与 organ-level 不跨表	§10 坑 5
坑 6	gated 要等批，raw 端点匿名锁	§10 坑 6
坑 7	与 trials(661) 等近名条目三锚点定身份	§10 坑 7
坑 8	无 checkpoint，报告生成自备	§10 坑 8

坑 1：把报告蒸馏标签当金标准（最高频误用）

现象：直接把 232 列二值标签当 ground truth 训练/评估，在论文里写「supervised by expert annotations」。
事实：标签从增强期放射报告自动提取，无逐例人工复核存证；阴性 = 「报告未提及」，混合真阴性与漏报；跨相位错位使部分所见原理性存疑。
后果：在提取噪声大的子任务上，你的模型上限被标签噪声封顶；审稿人复看数据卡即可发现表述失实。
处置：表述统一为「distilled from contrast-phase radiology reports」；高风险子任务先跑 §4.5 抽检 SOP；引用时带上「弱监督」限定语。

坑 2：在 Center 2 上做任何选择

现象：在 Center 2（169 例）上挑 epoch、调阈值、选 checkpoint，然后报告 external AUC。
事实：Center 2 是纯外部测试集，无 val 分割；官方协议中它只出现在最终评估。
后果：external 数字被污染，与官方口径（internal 69.1 / external 63.1，摘要口径）不可比，且属方法学硬伤。
处置：所有选择行为限制在 Center 1 train/val；Center 2 只跑一次终评；需要二段调参时回到 Center 1 val。

坑 3：AUC 双口径引用错位

现象：把 README 的 71.1%/66.2% 与论文摘要的 69.1%/63.1% 混在同一段对比里，或声称「复现掉了 2 个点」。
事实：两口径都官方——摘要为论文 runs（固定 1,000 epochs、无验证、无种子），README 为代码版（设种子、按验证集选 epoch）；README 表格 Pillar-0 69.92/65.71、Merlin 71.05/66.24。
后果：1-3 个点的口径差淹没真实方法差异，跨口径对比全部失真。
处置：论文语境用摘要口径；复现对比用 README 口径并注明「seed + val 早停」；引用时逐次标注出处。

坑 4：词典规模口径混用

现象：同一篇稿子里一句「53 diseases across 16 organs」、另一句「51 diseases across 15 organs」。
事实：主口径 53/16（含 Multi-organ 类）；排除 Multi-organ 后为 51/15。差额 = Multi-organ 类及其疾病归属。
后果：数字自相矛盾，审稿必问。
处置：全文统一主口径 53/16；需要排除跨器官类时明确写「excluding the Multi-organ category（51 diseases / 15 organs）」。

坑 5：zero-shot 数字与 organ-level AUC 跨表比较

现象：宣称「DAMO RADAR zero-shot 92.42 超过有监督基线 71.05」。
事实：92.42 是 HCC 单病变二分类子任务的 zero-shot AUC（388 测试体积）；71.05 是 Merlin 在 232 维全标签空间下的 organ-level AUC。任务、样本集、聚合层三不同。
后果：结论方向可能恰好说反，暴露未读协议。
处置：zero-shot 只与同子任务比（metastatic n=92：Pillar-0 71.06 / Merlin 71.63 / RADAR 68.56 是同子任务可比组）；organ-level 与 organ-level 比。

坑 6：gated 卡住下载（manual 审批 + raw 端点锁定）

现象：匿名抓 raw 端点拿不到文件树，或提交申请后立即跑 CLI 失败，判定「数据集不可用」。
事实：gated: manual 需作者人工批准；未授权会话的 raw 端点被平台锁定；获批前 CLI 必然 403。
后果：误判数据集状态，或用镜像缓存残缺版本。
处置：按 §6.2 五步走：填表（Full name/Institution/Country/Role）→ 勾选非商业承诺 → 等批 → 获批后 CLI 下载；受限网络走 hf-mirror.com 且仅限 API/raw 端点镜像口径；下载后跑 §2.7 体检。

坑 7：与 trials(661) 等近名条目混淆

现象：把 TriALS-Report 的数字、许可或任务写到 TriALS（trials，rid 661）头上，或反之；把 trialbench(46)、aact(230) 当作同一物。
事实：trials = TriALS 肝病变分割基准（MICCAI 2024/2025 系，arXiv 2605.16572，同团队前作）；TriALS-Report = 腹部多器官诊断+报告生成（MICCAI 2026，arXiv 2606.16991）；trialbench 是另一放射基准集；aact 是临床试验聚合数据，与影像无关。
后果：跨条目串数据是入库验收的高频拦截项。
处置：以 arXiv 号 + 任务 + 器官范围三锚点定身份（§9.1 对照表）；两条目互相链接而非互相代写。

坑 8：期待现成模型与开箱即跑

现象：假设仓库附带报告生成 checkpoint 或端到端训练脚本，clone 后发现没有就判「开源不完整」。
事实：官方未随数据发布任何 checkpoint；诊断基线是特征级 linear probe（低成本）；报告生成评估依赖外接工具链（RATE-Evals / RAVE），生成模型需自备。
后果：复现计划错估（把特征级成本当端到端成本，或反之）。
处置：按 §5.5 顺序：先跑诊断线对齐 README 表格，再规划报告生成线；预算里给报告生成头（LLM 解码器）训练单列算力；评估指标走官方工具链保证可比。

§11 总结

TriALS-Report 用 1,254 例多中心腹部非增强 CT 与 232 项报告蒸馏所见，把「平扫能承担多少增强期任务」这一临床问题变成可测量的基准：诊断线给出 frozen encoder + linear probe 的五架构横向协议与内外双集 AUC（摘要口径 69.1%/63.1%），报告生成线给出跨相位推理设定与官方评估工具链。它的方法论价值与它的缺口同源——报告蒸馏带来规模可行性与临床对齐的标签，也带来无逐例复核的噪声前提与双口径的评估现场；gated: manual 守住非商业边界，也把获取门槛从技术问题变成流程问题。

给三类读者各留一句话收束：

• 跑实验的：先体检（§2.7）再训练，先定口径（坑 3）再对比，Center 2 留到最后一刻；
• 写论文的：引用数字带口径注（附录 A.4 话术），局限声明可直接改写附录 G 模板，标签一律称蒸馏/弱监督；
• 建数据集的：本集正反两面是现成教材——蒸馏换规模、问句化词典换语义对齐是正面课；双口径、外部集身份缺失、复核存证缺口是反面清单（§8.4 十条即由此提炼）。

对本库读者，三句话收束：引用数字先问口径（坑 3/坑 4），使用标签先想蒸馏（坑 1），谈起名字先分姊妹（坑 7）。以此条目为起点，可沿 §9.2 的互链网络进入 trials(661) 的分割前作、trialbench(46) 的任务全景、radgraph(561) 系的报告结构化谱系与 synthrad(671) 的图像补偿路线——它们共同构成「放射影像 × 报告文本」在库内的方法学地图，TriALS-Report 是这张地图上腹部平扫一角的坐标原点。

FAQ 高频问答

Q1：名字里的 TriALS 指什么？

与三期增强腹部 CT（triphasic CT）的「Tri」同根，也是团队腹部影像工作系列的系列名（前作 TriALS 为肝病变分割基准，库内 trials，rid 661）。官方材料未给命名释义，「Report」后缀点出报告生成任务。本条目按字面关联陈述并存疑（§9.3 遗留疑点 5）。

Q2：数据是真实医院数据吗？含 PHI 吗？

来自真实临床检查（两中心、三期增强检查的平扫期），发布形态为 NIfTI 体积 + CSV 标签。材料未披露去标识化流程细节；使用时按机构伦理要求自查，衍生发表时注明数据经官方渠道获取且遵守 CC BY-NC 4.0。

Q3：为什么只有非增强期？增强期图像在哪？

设计如此：发布「平扫图像 + 增强期报告」组合，不发布增强期图像——跨相位推理设定的物化形态。想要「平扫→增强」图像对的人应看 synthrad（rid 671）路线（§8.2）。

Q4：232 项所见是怎么确定的？

词典层 53 病 × 16 器官（主口径）组织，每个 finding 对应 label_dictionary 里的一个 column/organ/question 三元组，问句化表述对齐报告语言。总列数 232 为标签表实际列数，两个口径（53/16 与 51/15）见坑 4。

Q5：诊断任务输入是 2D 切片还是 3D 体积？

数据本体是 3D 体积（NIfTI）；官方诊断协议为 frozen encoder 取全局特征后接线性探针（特征级），编码器侧的 2D/3D 处理由所选模型决定。想做端到端 3D 训练需自建管线，数据不限定。

Q6：batch size 8192 怎么做到的？

因为 linear probe 只训 232 维线性层，前向特征可预计算后离线大 batch 训练，显存压力极小。端到端训练场景下该 batch 不可复制，也不必复制。

Q7：linear probe 和端到端微调，该用哪个？

评测编码器特征质量、对标官方数字 → linear probe（唯一有官方口径可比）；追求任务性能上限 → 端到端或高级微调，但放弃与官方数字的直接可比性。两条路线结论不可混写。

Q8：验证集 106 例会不会太小？

偏小但可用：模型选择方差大时，坑 3 的双口径差（种子与选 epoch 带来 1-3 个点）部分即源于小验证集敏感性。自行复现时建议多次重复取均值再对比。

Q9：external 63.1% 是不是说明不能用于跨中心场景？

不是「不能用」，是「有 5-6 个点泛化衰减」的先验。63.1% 是 232 维全标签空间 organ-level AUC 的摘要口径，任务难度含稀疏类别与弱监督噪声；跨中心部署决策应结合目标子任务与 §4.5 抽检结果，而非只看总分。

Q10：报告生成有官方 baseline 模型吗？

数据集未附带 checkpoint（坑 8）；评估协议与工具链（RATE-Evals / RAVE）是官方的。生成模型需自备并在 Center 1 train 上训练，评估时保持 reference 为增强期报告文本。

Q11：RATE-Evals 和 RAVE 什么关系？都要用吗？

同团队的姊妹评估工具：RATE-Evals（marwankefah/rate-evals）为放射报告评估工具集，RAVE（yalalab/rave）为视觉-文本评估引擎。论文评估链路涉及两者；最低配置至少用其一保证指标可复现，具体分工以两仓库文档为准。

Q12：能用来训练商业产品吗？

不能。CC BY-NC 4.0 + gated 表单非商业承诺双重约束，商业部署需另行取得权利人许可（无公开授权通道）。

Q13：能发布基于它的衍生模型权重吗？

学术发布通常可行：模型权重不属于数据集本体，但衍生品应遵守许可精神——注明来源与 NC 边界，避免以「模型服务」形式变相商用。发布页建议附论文引用与数据许可声明。

Q14：gated 申请没响应怎么办？

manual 制依赖作者人工审批，无承诺时限。可做：确认表单四字段完整、邮箱可收信；隔 1-2 周礼貌跟进 HF 账号消息；同时评估库内替代条目（§9.2）推进不阻塞主线。不要重复刷申请或绕过 gating。

Q15：受限网络怎么下载？

走 hf-mirror.com 镜像（设 HF_ENDPOINT），获批 token 有效时同一 huggingface-cli download marwankefah/TriALS-Report --repo-type dataset 命令可用；镜像仅覆盖 API/raw 端点行为，网页交互仍以主站为准（§6.3、坑 6）。

Q16：Center 2 是哪个国家/机构的数据？

官方材料未明示（遗留疑点 1）。只知其为外部测试集（169 例）、与 Center 1 独立。引用时写「外部测试集」即可，勿推断国别。

Q17：能重新划分 split 吗？

技术上可行、比较上不可行：任何重划都会失去与官方 AUC 的可比性。如确需重划（如 k-fold），请在结果表中与官方协议双轨呈现并明示划分差异。

Q18：232 类里很多稀有类别，怎么办？

官方已用 pos_weight 缓解（BCEWithLogitsLoss）；使用者可叠加 focal 变体、按器官聚合评估（官方指标即 organ-level）、或对极端稀疏列做置信度截断。评估仍按 organ-level 口径报告，避免逐类指标的选择性呈现。

Q19：能与 TriALS（分割）数据联合使用吗？

任务互补（分割前作 → 诊断/报告续作），团队同源、方向连续，方法学可组合；但两者是不同数据集（不同 arXiv、不同队列规模），患者层面是否重叠无公开说明，不可假设可按患者拼接。

Q20：有 DICOM 格式吗？

发布格式为 NIfTI（.nii.gz）+ CSV，无 DICOM。需要 DICOM 的团队自行转换并保留头信息映射记录（§2.7 体检第 4 条）。

Q21：引用 AUC 怎么写不踩坑？

模板：「organ-level AUC X%（口径：arXiv 摘要 69.1/63.1 或 GitHub README 71.1/66.2，含 seed 与验证集早停差异说明）」。一次引用一个口径，绝不混排（坑 3）。

Q22：zero-shot 92.42 是 SOTA 吗？

它是 DAMO RADAR 在 HCC 单病变二分类子任务的 zero-shot AUC（388 体积子集），与 232 维 organ-level 主表不可比（坑 5）。若你的任务是同口径单病变检测，它是有力的 zero-shot 参照；否则不构成 SOTA 声明。

Q23：数据会更新吗？有版本管理吗？

HF 仓库 lastModified 2026-09-22（抓取时点快照）；材料未承诺更新节奏或版本号方案。复现时记录下载日期与仓库快照（§9.3 存照 4），以自证所用版本。

Q24：发现数据问题向谁报告？

官方渠道：HF 数据集页 Discussion 区与 GitHub xmed-lab/TriALS-Report Issues。报告时附 patient_id/所见列名/复现步骤，勿在公开区贴原始图像与报告文本（合规与隐私双重考虑）。

Q25：能用它做图像分割吗？

不能直接做：标签是图像级所见（二值），无像素级或掩码标注。分割任务请用同团队前作 TriALS（库内 trials，rid 661，肝病变分割）或其他分割基准；两数据集患者层面是否重叠无公开说明，勿假设可拼接。

Q26：能用这 760 例训练集做自监督预训练吗？

量级偏小（1K<n<10K 档），从零预训练不现实。官方协议的立场恰是「评测既有预训练编码器」——用 Pillar-0/Merlin 等，TriALS-Report 当评测场而非预训练语料。想在腹部 CT 上做预训练，需另行汇集更大队列。

Q27：报告文本是什么语言？

官方材料为英文报告体系（国际多中心产出）。中文临床场景复用需自建翻译/适配层，且词典问句（question 列）的语义对齐要在中文语境下重新验证。

Q28：与 RadGraph 范式是什么关系？

同属「放射报告 → 结构化」大方向但标注对象不同：RadGraph（库内 radgraph，rid 561）系对报告文本做 token 级实体关系标注；TriALS-Report 把报告蒸馏成图像级所见标签、监督对象是 CT 体积。做报告结构化引用前者，做平扫诊断引用本集。

Q29：有人口统计学明细（年龄/性别/剂量）吗？

可获取材料未披露人口统计学与扫描参数明细；本库 patient_tags 口径为「成人」。引用人群画像时只写「两中心腹部 CT 患者（明细未披露）」，勿推断年龄分布或剂量水平。

Q30：最常见的错误用法 Top 5？

① 蒸馏标签当金标准（坑 1）；② Center 2 上调参（坑 2）；③ AUC 双口径混排（坑 3）；④ 词典口径混用（坑 4）；⑤ 与 trials(661) 串数据（坑 7）。逐条处置见 §10。

Q31：能与 EHR 或临床试验数据联动吗？

数据集本体无 EHR 字段、无患者级外部链接。试验语义的近邻见库内 clinicaltrials-gov(556) 与 aact(230)（注意 aact 是临床试验聚合数据，与影像无关，勿因名称近邻混淆）。联动只能在研究设计层（队列定义、纳入标准对照），不能在数据层做患者级 join。

Q32：本条目信息截至何时？

2026-10-09 抓取快照。动态字段（downloads、仓库时间戳、HF 页面状态）随时间变化；静态字段（规模、协议、许可）以论文与仓库为准。条目内已标注快照时点者以标注为准。

Q33：CT 是薄层还是厚层？重排过吗？

发布口径层厚 1.07 mm、面内 0.875×0.875 mm（512×512）；原始采集与重排细节未逐层披露。预处理前以 NIfTI 头信息为准（§2.7 体检第 4 条），对层厚敏感的任务（小病灶检出）先做重采样敏感性检查。

Q34：一个患者会出现在多个 split 吗？

不会：患者级划分是数据集的组织不变式（§3.6 不变式 3）。体检若发现 patient_id 跨 split 重复，属数据异常，应上报官方（Q24 渠道）而非自行「修复」。

Q35：能只用肝脏子集做单器官研究吗？

可以：按词典 organ 列筛出肝脏 10 病所在 finding 列即可。但注意与 trials(661)（肝分割）任务不同；且子集化后 organ-level 口径变成单器官口径，与官方全器官数字不可比，引用时需声明子集化。

Q36：报告生成的评估指标有哪些选项？

官方链路是 RATE-Evals + RAVE（§5.4）。常见替代（BLEU/ROUGE/BERTScore/RadGraph-F1 类）可自行叠加，但与官方数字的可比性即断——对比实验内自洽可以，跨论文对标不行。

Q37：训练报告生成模型需要多少算力？

数据集侧不限定（无官方生成基线可参照）。量级参考：编码器侧同诊断线（冻结特征可预提取），解码器侧取决于你选的 LLM 头（1B-7B 级单卡至多卡）。先在 Center 1 val 上小规模验证再放量。

Q38：数据集有引用格式要求吗？

论文 BibTeX 见 §0.4（@misc{elbakry2026…}）。HF 页若另有 CITATION.cff 以其为准；衍生品同时注明数据许可 CC BY-NC 4.0。

Q39：审稿人常挑战的三个问题是什么？

① 标签噪声对你的结论影响多大（备好 §4.5 抽检数据）；② 为什么用 README 口径而非论文口径（或反之——备好坑 3 解释）；③ 跨相位上限是否被低估（备好「无法判断」类所见的统计或文献对照）。提前准备这三个答案的论文少返工。

Q40：我想贡献改进标签/补充标注给官方，可以吗？

许可层面对衍生标注无禁止（NC 边界内），官方接受与否取决于作者意愿：HF Discussion / GitHub Issues 提出贡献意向（Q24 渠道），注明抽检方法与一致性指标。贡献前明确署名与许可归属，避免衍生数据权属模糊。

事实清单（逐条来源可溯）

1. 数据集伴随论文官方名 A Multi-Center Benchmark for Abdominal Disease Diagnosis and Report Generation from Non-Contrast CT——arXiv 摘要页 https://arxiv.org/abs/2606.16991
2. arXiv v1 提交日期 2026-06-15——arXiv 2606.16991 页面
3. MICCAI 2026 Early Accept（top ~9%）+ Spotlight——arXiv 页面备注与作者口径（三源核验存照见附录 I）
4. HuggingFace 数据仓库 marwankefah/TriALS-Report，gated: manual——HF 数据集页
5. 代码仓库 GitHub xmed-lab/TriALS-Report（repo id 1246590622）——GitHub API
6. 总规模 1,254 例（patients/volumes）——论文摘要与 HF 数据卡
7. Center 1 内部 1,085 例 = 训练 760 / 验证 106 / 测试 219——论文数据节
8. Center 2 外部测试 169 例——论文数据节
9. CT 矩阵 512 × 512——论文数据节
10. 面内间距 0.875 × 0.875 mm——论文数据节
11. 层厚 1.07 mm——论文数据节
12. 影像所见 232 项（多标签二值）——labels.csv 结构与论文
13. 词典主口径 53 种疾病 × 16 个器官——论文
14. 排除 Multi-organ 口径 15 器官 / 51 病——论文另一处表述（双口径存照）
15. 肝脏 10 种疾病（含 HCC、肝转移瘤、肝囊肿等）——论文/词典
16. 胰腺 3 种疾病（含胰腺肿瘤）——论文/词典
17. 标签来源 = 同患者增强期放射报告自动提取（蒸馏），非人工逐例标注——论文方法节
18. 词典文件 label_dictionary.csv（column / organ / question 三列）——HF 仓库文件树
19. 标签表 labels.csv（patient_id / center / split / image + 232 finding 列）——HF 仓库文件树
20. 图像文件 ct/<patient_id>.nii.gz（每例一文件）——HF 仓库文件树
21. HF Datasets configs：labels（splits: center1 / center2）+ label_dictionary——HF 数据卡
22. 许可 CC BY-NC 4.0——HF 数据卡与论文声明
23. extra_gated 表单：Full name / Institution / Country / Role + 非商业学术用途 checkbox——HF gated 配置
24. HF tags：size 1K<n<10K、format csv、task image-classification 等——HF API 快照
25. HF createdAt 2026-09-21 / lastModified 2026-09-22——HF API 快照
26. downloads 26（截至 2026-10-09 抓取，热度快照）——HF API 快照
27. 诊断协议：frozen encoder + nn.Linear(D, 232)——GitHub README/代码
28. BCEWithLogitsLoss + pos_weight；Adam lr 1e-3；≤1,000 epochs；batch 8192；threshold 0.5——GitHub README/代码
29. 评估：organ-level AUC/F1 + 1,000 次 patient-level bootstrap——论文与代码
30. AUC 摘要口径 69.1%（internal）/ 63.1%（external）——arXiv 摘要
31. AUC README 口径 71.1% / 66.2%；表格 Pillar-0 69.92/65.71、Merlin 71.05/66.24——GitHub README
32. 双口径官方解释：论文 runs 固定 1,000 epochs 无验证未设 seed；代码版设 seed 且按验证集选 epoch——作者官方解释
33. zero-shot DAMO RADAR（388 测试体积）：HCC 92.42 / 胰腺肿瘤 91.26 / 肝转移 87.12 / 结肠 67.61——论文
34. metastatic 子任务（n=92）：Pillar-0 71.06 / Merlin 71.63 / RADAR 68.56——论文
35. 评估工具链 RATE-Evals（marwankefah/rate-evals）+ RAVE（yalalab/rave）——GitHub
36. 未随数据发布任何 checkpoint——HF/GitHub 仓库核查
37. 8 作者 4 机构：Ain Shams University 4 人（Mariam Elbakry、Aliaa Sayed Sheha、Salma Hassan Tantawy、Aya Yassin）、HKUST 2 人（Xiaomeng Li、Marawan Elbatel）、University of Catania（Concetto Spampinato）、Universitat de Barcelona（Karim Lekadir）——arXiv 作者栏
38. 通讯作者 Marawan Elbatel（HKUST）——arXiv 与 HF 提交者记录
39. 姊妹工作：赞比亚宫颈癌 CT 报告（MICCAI 2026 Workshop AFRICAI，OpenReview fpyn7ytdQj）——OpenReview
40. 编码器资产：Pillar-0 = YalaLab/Pillar0-AbdomenCT；Merlin = stanfordmimi/Merlin；DAMO RADAR = alibaba-damo-academy/damo-radar——HF 模型页

术语表（30 条）

术语	释义（本条目语境）
triphasic CT	三期增强腹部 CT：一次检查含非增强期与多个增强期位
NCCT（non-contrast CT）	非增强（平扫）CT，本数据集唯一图像模态
CECT（contrast-enhanced CT）	增强 CT；本集报告的书写对象、图像不发布
finding（影像所见）	报告中的病灶/征象条目；本集 232 项，二值化后作标签
multi-label classification	多标签分类：每例可同时命中多个所见
label dictionary	词典表：232 列名 → 器官 → 问句的映射
report distillation	报告蒸馏：从报告文本自动提取标签的弱监督标注范式
cross-phase reasoning	跨相位推理：输入平扫、参考增强期报告的任务设定
report generation	报告生成：从图像产出结构化放射报告文本
frozen encoder	冻结编码器：特征不参与梯度更新
linear probe	线性探针：在冻结特征上训练线性分类头
BCEWithLogitsLoss	二分类交叉熵（带 logits 融合 sigmoid），232 维多标签的损失
pos_weight	正类权重：缓解正例稀疏的类别不平衡手段
organ-level AUC	器官层聚合 AUC：按词典 organ 列分组后计算
F1	精确率与召回率的调和平均，器官层与 AUC 并报
patient-level bootstrap	以患者为重采样单元的自助法（1,000 次）估置信区间
split	划分：train 760 / val 106 / test 219（Center 1）+ 外部 169
external validation	外部验证：Center 2 仅测试，模拟跨中心泛化
zero-shot	零样本：不在本数据集上训练的直接推理评估
HCC（hepatocellular carcinoma）	肝细胞癌，肝脏 10 病之一
hepatic metastasis	肝转移瘤；metastatic 子任务 n=92
pancreatic tumor	胰腺肿瘤，胰腺 3 病之一
NIfTI（.nii.gz）	神经影像常用 3D 体数据格式，本集图像载体
spacing / slice thickness	体素间距与层厚（本集 0.875×0.875 mm / 1.07 mm）
gated: manual	HF 访问制：申请表单 + 作者人工批准
extra_gated fields	gated 表单字段：姓名/机构/国家/身份 + 承诺框
CC BY-NC 4.0	署名-非商业 4.0 国际许可
HF config	HF Datasets 的数据配置单元（labels / label_dictionary）
RATE-Evals / RAVE	官方报告评估工具链（两 GitHub 仓库）
AFRICAI	MICCAI 2026 的非洲医学影像工作坊，姊妹论文发表于此

附录 A：词典层结构与已存证样例

A.1 三列结构：column → organ → question

label_dictionary.csv 的每一行把一个标签列钉到临床语义上：

• column：labels.csv 中的实际列名（232 个之一），是标签表与词典的连接键；
• organ：该所见归属的器官（16 选 1，或 Multi-organ 跨器官类）；
• question：问句化表述——把「有没有这个所见」写成自然语言临床问句，是「报告语言 → 标签语义」的显式桥。

三列设计的方法学含义：任何一列标签都能回答「它在问什么身体部位、什么临床问题」，评估聚合（organ-level）、错误分析（按器官切片）、问句化指令构造（喂 VLM）都直接消费这张表——它是数据集的「语义索引」。

A.2 已存证的器官-疾病样例

器官	已存证疾病数	已存证样例
肝脏（liver）	10	肝细胞癌（HCC）、肝转移瘤（hepatic metastasis）、肝囊肿等
胰腺（pancreas）	3	胰腺肿瘤（pancreatic tumor）等
Multi-organ	跨器官	不限定单一器官的所见（两口径差额来源）
其余 13 器官	—	逐项清单未在可获取材料中完整披露（遗留疑点）

口径差额说明：主口径 53 病/16 器官；排除 Multi-organ 后 51 病/15 器官。差额即 Multi-organ 类及其疾病归属（53−51 = 2、16−15 = 1 对应关系以官方材料为准，勿自行拆分）。

A.3 问句化机制的使用建议

• 构造 VQA/指令数据：question 列直接可用作问句模板，配合 image 字段与二值标签即得图像级问答对；
• 错误分析：模型在低 AUC 器官上的错例按 question 语义聚类，可区分「图像证据缺失」与「标签噪声」两类根因；
• 与 radgraph 系对照：RadGraph 的结构化单位是报告内 token 级实体，本集是图像级所见——两者可分别作为「文本精标注」与「图像弱标注」的两端参照。

A.4 双口径的引用话术对照（拿来即用）

场景	推荐话术
论文相关工作节引主结果	「TriALS-Report reports organ-level AUC of 69.1% (internal) and 63.1% (external) on 1,254 abdominal NCCT volumes」
复现对比表	「baseline: 71.1%/66.2%（GitHub README 口径，seed + 验证集早停）；本文方法与该口径对齐比较」
词典规模	「232 findings organized as 53 diseases across 16 organs (including a Multi-organ category)」
排除跨器官类的分析	「excluding the Multi-organ category (51 diseases / 15 organs)」
zero-shot 引用	「zero-shot single-lesion AUC of 92.42 (HCC) on a 388-volume subset」
同时引两口径	「69.1%/63.1% (paper runs, fixed 1,000 epochs, no seed) vs 71.1%/66.2% (released code, seeded, val-based epoch selection)」

原则：一句话内只出现一个口径；两口径并陈时必须带各自语境注释（坑 3 话术版）。

附录 B：DAIMS 评估全表

维度	评分（1-10）	依据
D 可发现性	7	arXiv + MICCAI 2026 + HF 数据卡三入口可索引；但「TriALS-Report」与库内 trials(661)、TriALBench(46) 近名，检索易串
A 可获取性	5	公开直链存在但 gated: manual 人工审批，等待时长不可控；raw 端点匿名锁定
I 可互操作	7	NIfTI + CSV 通用格式，HF Datasets 双 config 标准；无 DICOM、无官方 DICOM 转换脚本
M 元数据质量	6	协议参数完备（尺寸/间距/层厚/split/词典三列）；但 Center 2 来源未披露、人口统计学缺失、双口径两处（AUC、词典）需读者自辨
S 可持续性	6	HF + GitHub 双平台稳定；manual 审批依赖作者响应为单点风险；无版本号方案、无更新承诺
综合评级	6.2/10（中上）	任务设计与协议透明度高于均值；可获取性被 manual gating 拖低，元数据被双口径与披露缺口压分

附录 C：逐项证据链自证

关键数字/事实	来源	位置
1,254 例 / 760/106/219 / 169	论文数据节 + HF 数据卡	arXiv 2606.16991 / HF 页
512×512 / 0.875×0.875 mm / 1.07 mm	论文数据节	arXiv 全文
232 findings / 53 病×16 器官	论文 + labels.csv 结构	arXiv / HF 文件树
15 器官/51 病（排除 Multi-organ）	论文另一处表述	arXiv 全文
gated: manual + extra_gated 四字段 + checkbox	HF gated 配置	HF 数据集页
CC BY-NC 4.0	HF 数据卡许可字段	HF 页
createdAt 2026-09-21 / lastModified 2026-09-22 / downloads 26	HF API 快照	2026-10-09 抓取
nn.Linear(D, 232) / BCE+pos_weight / Adam 1e-3 / batch 8192 / ≤1000 epochs / threshold 0.5	GitHub README 与代码	xmed-lab/TriALS-Report
organ-level AUC/F1 + 1,000 patient-level bootstrap	论文评估节 + 代码	arXiv / GitHub
摘要口径 69.1% / 63.1%	arXiv 摘要	arXiv 页
README 口径 71.1% / 66.2%；表格 69.92/65.71、71.05/66.24	GitHub README 结果表	GitHub 页
双口径官方解释（种子/验证集早停）	作者官方解释	GitHub README 备注
zero-shot 92.42/91.26/87.12/67.61；metastatic n=92 三值	论文 zero-shot 节	arXiv 全文
MICCAI 2026 Early Accept（top ~9%）+ Spotlight	arXiv 备注/作者口径	三源核验
8 作者 4 机构名单	arXiv 作者栏	arXiv 页
姊妹工作 OpenReview fpyn7ytdQj（AFRICAI Workshop）	OpenReview	openreview.net
无 checkpoint 发布	仓库文件核查	HF/GitHub
repo id 1246590622	GitHub API	api.github.com

附录 D：数据获取决策树

你的需求是什么？
├── 只要 AUC 数字做引用/对比
│   ├── 论文语境 → 摘要口径 69.1%（internal）/ 63.1%（external）
│   └── 复现对比 → README 口径 71.1%/66.2%（注明 seed + val 早停）
├── 要跑诊断基线
│   ├── 1) gated 申请（四字段 + 非商业承诺）→ 等人工批准
│   ├── 2) 获批后 huggingface-cli download（受限网络走 hf-mirror）
│   ├── 3) 跑 §2.7 体检（数量/split/词典对齐/头信息/标签分布）
│   └── 4) frozen encoder + linear probe 对齐 README 表格
├── 要做报告生成
│   ├── 前置：诊断线先对齐（编码器与特征复用）
│   ├── 自备生成头（LLM 解码器）在 Center 1 train 训练
│   └── 评估走 RATE-Evals / RAVE，reference 为增强期报告
├── 只想用 232 标签做弱监督研究
│   └── 先跑 §4.5 抽检 SOP，产出器官×所见信任度表再用
├── 想要增强期图像或图像配对
│   └── 本集不含（坑 6 前置认知）→ 改道 synthrad(671) 图像路线
└── 想做分割
    └── 本集无掩码 → 改道同团队前作 trials(661)

附录 E：来源清单（本条目全部外链）

来源	URL	用途
arXiv 论文页	https://arxiv.org/abs/2606.16991	论文正文/摘要/作者/BibTeX
HF 数据集页	https://huggingface.co/datasets/marwankefah/TriALS-Report	数据卡/gated 表单/configs
GitHub 代码仓	https://github.com/xmed-lab/TriALS-Report	协议参数/README 结果表
Pillar-0 模型页	https://huggingface.co/YalaLab/Pillar0-AbdomenCT	abdomen-specific 编码器
Merlin 模型页	https://huggingface.co/stanfordmimi/Merlin	chest-specific 编码器
DAMO RADAR 模型页	https://huggingface.co/alibaba-damo-academy/damo-radar	zero-shot 参照模型
RATE-Evals	https://github.com/marwankefah/rate-evals	报告评估工具集
RAVE	https://github.com/yalalab/rave	视觉-文本评估引擎
姊妹论文（AFRICAI）	https://openreview.net/forum?id=fpyn7ytdQj	蒸馏流水线延伸证据
本条目站内页	https://www.qianfanghub.com/ai-ready-dataset/trials-report/941	条目规范 URL

附录 F：30 分钟快速上手 checklist

1. （分钟 0-5）确认身份：arXiv 2606.16991 = TriALS-Report = 腹部 NCCT 诊断+报告生成；不是 trials(661) 的分割数据；
2. （分钟 5-10）提交 gated 申请：四字段如实填写 + 勾选非商业承诺；等待期先读论文评估节与 GitHub README；
3. （分钟 10-15）搭环境：PyTorch + nibabel + HF CLI；受限网络设 hf-mirror 端点；
4. （分钟 15-20）获批后下载，跑 §2.7 六项体检并记录结果；
5. （分钟 20-28）复跑诊断基线：任选 Pillar-0/Merlin 之一抽特征，linear probe（§4.2 参数），Center 1 test 出 organ-level AUC，对照 README 表格同编码器值；
6. （分钟 28-30）登记口径：在实验记录里写死「我引用的是哪个口径的官方数字、我的实验对应哪个口径」，后续所有对比以此为准。

附录 G：论文局限声明模板（引用本数据集时可直接改写）

本研究中 TriALS-Report（arXiv 2606.16991）按 CC BY-NC 4.0 许可自 HuggingFace 获取（2026 年 X 月获批）。232 项影像所见标签自对比期放射报告蒸馏而来，未经逐例人工复核，我们将其视为弱监督信号；我们在 Center 1 测试集上抽样复核了 X 例-所见对（一致性 X%），未见跨相位不可判断率达 X%。所有模型选择仅使用 Center 1 训练/验证分割，Center 2（n=169）仅用于最终评估。性能数字引用 GitHub README 口径（随机种子 + 验证集早停），与 arXiv 摘要口径（固定 1,000 epochs）的系统性差异已知（README 值高 1-3 个 AUC 点）。词典规模按主口径 53 种疾病 × 16 器官报告（含 Multi-organ 类）。

模板使用规则：X 处按你的实际抽检与获取时间填写；删除「未见」或「率达」中不适用的分句时保持句子完整；不要把模板里没有的声明（如「经伦理审批」）无据添加。

附录 H：库内互链逐条对照

库内条目	rid	关系类型	互链落点建议
trials	661	同团队姊妹作（分割前作）	双向去混淆框（§9.1）
trialbench	46	放射基准集近邻	双方 §9 互链
clinicaltrials-gov	556	试验登记近邻（trials 语义）	本集 §9.2
aact	230	试验聚合数据（名称近邻去混淆）	本集 §9.2 + FAQ Q31
radgraph	561	报告结构化范式参照	本集 FAQ Q28 + §9.2
radgraph2-radiology-reports	622	报告语料近邻	本集 §9.2
radvlm-instruction-dataset	624	放射 VLM 指令数据	本集 §9.2 + 附录 A.3
radialog-instruct-dataset	625	放射对话指令数据	本集 §9.2
rad-chestct	819	CT 体积+报告配对（胸部）	本集 §9.2
vqa-rad	240	放射问答基准	本集 §9.2 + 附录 A.3
synthrad	671	NCCT→CECT 图像路线对照	本集 §8.2 + §9.2

附录 I：核验过程存照（三源互证轨迹）

本条目按纪律包 §1 完成存在性核验，三源互证轨迹如下（截至 2026-10-09）：

1. 源一（arXiv）：论文页 https://arxiv.org/abs/2606.16991 实抓——标题、作者 8 人 4 机构、v1 日期 2026-06-15、摘要口径 AUC、MICCAI 2026 Early Accept + Spotlight 备注、BibTeX 原文；
2. 源二（HuggingFace，经 hf-mirror.com）：数据集 API/页面实抓——gated: manual、extra_gated 四字段与承诺框、configs（labels: center1/center2 + label_dictionary）、tags（1K<n<10K / csv / image-classification）、createdAt/lastModified/downloads、许可 CC BY-NC 4.0；raw 文件端点因 gated 锁定（遗留疑点 3）；
3. 源三（GitHub）：仓库 xmed-lab/TriALS-Report 实抓（api.github.com，repo id 1246590622）——README 协议参数（linear probe 全套）、README 结果表（双口径另一套）、官方双口径解释、工具链两仓库指针；
4. 交叉印证：1,254 例与 760/106/219/169 在论文与数据卡一致；232 与词典结构在论文、README、文件树三方一致；AUC 双口径在摘要与 README 各自自洽且官方解释唯一；
5. 查重：库内 DB 查询 url_name ILIKE '%trials%' 命中 trials(661)/trialbench(46) 等，无 trials-report 同名；ls writing/ 无同名目录；租约锁 .lock 为本代理（agent-c-trialsrepo 2026-10-09T01:27:53）；
6. 姊妹工作核验：OpenReview fpyn7ytdQj（AFRICAI Workshop）证实同团队蒸馏流水线的第二落点。

核验结论：数据集真实存在、规模/许可/获取方式三源可查证，通过存在性核验。遗留疑点（Center 2 来源、MICCAI 会期、raw 端点锁定、命名释义）已存照于 §9.3，均不影响成稿硬数字的成立。

附录 J：错误表述对照表（写作自检用）

错误表述	为什么错	正确表述
「1,254 例经专家标注的腹部 CT」	标签是报告蒸馏，非人工逐例标注（坑 1）	「1,254 例腹部 NCCT，232 项所见标签自增强期放射报告蒸馏」
「在 Center 2 上选择了最优模型」	外部集只能终评（坑 2）	「Center 2 仅用于最终评估」
「模型达到 71.1% 的 AUC（论文报告）」	71.1% 是 README 口径，论文是 69.1%（坑 3）	「README 口径 71.1%（seed + 验证集早停）」或「论文摘要口径 69.1%」
「覆盖 51 种疾病、15 个器官」与同文另一处「53 病 16 器官」	两口径混写（坑 4）	全文统一主口径 53/16，或显式声明排除 Multi-organ 口径 51/15
「zero-shot AUC 92.42，超过所有有监督基线」	跨表比较（坑 5）	「HCC 单病变子任务 zero-shot AUC 92.42（388 体积）」
「TriALS-Report 是 TriALS 数据集的报告扩展标注」	两数据集两任务，非标注扩展关系（坑 7）	「同团队姊妹工作：TriALS 为肝分割基准，TriALS-Report 为腹部诊断+报告生成基准」
「提供预训练模型权重」	无 checkpoint 发布（坑 8）	「提供数据与训练/评估代码，无预训练权重」
「数据集包含增强期图像」	仅发布平扫体积（§2.2）	「仅含非增强期体积；增强期仅以报告文本形态存在」
「标注者为放射科医生」	提取自医生写的报告，标注动作是自动提取（§4.3）	「标签蒸馏自放射科医生书写的增强期报告」
「可用于商业场景」	CC BY-NC 4.0（§6.1）	「CC BY-NC 4.0，限非商业学术用途」

附录 K：复现实验记录模板（与 §5.5/附录 F 配套）

=== TriALS-Report 复现记录 ===
[版本快照]
下载日期：________   HF 快照日期：________（对照 §9.3 存照 4）
体检结果：§2.7 六项 → 完整性 □ / split □ / 词典对齐 □ / 头信息 □
          标签分布 □ / gap 预案 □（例外清单附页：________）

[口径声明（实验前写死）]
我引用的官方口径：□ arXiv 摘要 69.1/63.1   □ README 71.1/66.2
我的实验对应口径：□ 论文式（1000 epochs 固定/无种子）
                  □ README 式（seed=____ / val 选 epoch）
词典口径：□ 53/16（含 Multi-organ）  □ 51/15（排除）

[诊断线]
编码器：□ Pillar-0（YalaLab/Pillar0-AbdomenCT）  □ Merlin（stanfordmimi/Merlin）
        □ 其他：________（不可与官方表格直接对比，需注明）
特征维度 D：____   训练 epochs 实际：____   最终 epoch 来源：□ 固定 □ val 选择
Center 1 test organ-level AUC：________（官方同编码器对照：________）
Center 2 organ-level AUC：________（仅终评次数：____）
bootstrap：1,000 次 patient-level，95% CI：[________, ________]

[报告生成线（如做）]
生成头：________（自备，无官方 checkpoint）
评估工具：□ RATE-Evals  □ RAVE  □ 自定义（注明与官方不可比）
reference：增强期报告文本（Center 1 test / Center 2）

[红线自检（交稿前）]
□ 未把蒸馏标签称为金标准/专家标注
□ Center 2 无任何选择行为
□ 全文单一 AUC 口径（或显式双口径注明）
□ 词典口径全文一致
□ 无 zero-shot 与 organ-level 跨表比较
□ 身份锚点（arXiv 2606.16991）未与 trials(661)（2605.16572）混淆

模板与附录 J 对照表、§10 八坑共同构成本条目的「防错三件套」：写作用 J，跑通用 K，投稿前过 §10。

附录 L：从 TriALS-Report 出发的三条学习路径

L.1 诊断评测路径（医学影像 AI 新手 → 完成一次规范评测）

1. 读 §0.2 速览 + §4.2 协议，明确 frozen encoder + linear probe 范式；
2. 提交 gated 申请（§6.2），等待期读论文评估节并 clone 官方仓库读协议代码；
3. 获批后下载、跑 §2.7 六项体检、写口径声明（附录 K 模板）；
4. 用 Pillar-0 抽特征，按 §4.6 骨架训探针，Center 1 test 出 organ-level AUC；
5. 对照 README 表格同编码器值，偏差 >1 点时排查聚合顺序与口径（附录 P）；
6. 加跑 Merlin 重复第 4-5 步，写出双编码器对比小结——即完成一次与官方可比的规范评测。

L.2 报告生成路径（有多模态基础 → 搭最小跨相位生成系统）

1. 前置：诊断线先对齐（第 1-5 步同 L.1），特征与探针复用；
2. 设计生成头：LLM 解码器 + 体积特征注入方案（数据集不限定，坑 8 自备）；
3. 在 Center 1 train 训练、val 选择，reference 固定为增强期报告文本；
4. 接入 RATE-Evals / RAVE 出官方可比指标（§5.4）；
5. Center 2 终评一次，同时报告诊断探针与生成指标，分析两者的所见级相关性；
6. 写局限段：跨相位上限（§3.2 弱层所见）与蒸馏噪声传导（§4.3）双声明。

L.3 方法学复制路径（数据集构建者 → 设计自己的蒸馏式标注）

1. 精读 §4.3 收益/代价清单与 §8.1 四问自评，≥6 分再启动；
2. 盘点自有报告语料：患者级对齐、书写一致性、覆盖的疾病谱；
3. 起草词典：column/organ/question 三列结构照搬（附录 A），问句化由临床合作者审校；
4. 先抽 100 例做提取流水线试点，人工复核 + Kappa 达标后再全量；
5. 预留验证预算：逐条复核做不到就分层抽样存证（本集的最大缺口，别复制它）；
6. 发布前过 §8.4 十条 checklist 与附录 J 对照表。

附录 M：开源资产清单与定位

资产	仓库/页面	定位与使用时机
TriALS-Report 数据	HF marwankefah/TriALS-Report	主体数据；gated 获批后使用（§6）
TriALS-Report 代码	GitHub xmed-lab/TriALS-Report	协议参数权威出处；不 gated，先读先搭
Pillar-0	HF YalaLab/Pillar0-AbdomenCT	abdomen-specific 编码器；对标官方表格首选
Merlin	HF stanfordmimi/Merlin	chest-specific 编码器；官方表格另一枚
DAMO RADAR	HF alibaba-damo-academy/damo-radar	通用多模态；zero-shot 参照
RATE-Evals	GitHub marwankefah/rate-evals	报告评估工具集；报告线必接
RAVE	GitHub yalalab/rave	视觉-文本评估引擎；与 RATE-Evals 互补
TriALS（前作）	库内 trials(661) / arXiv 2605.16572	肝分割任务导流处；非本集数据源
hf-mirror.com	镜像站	受限网络下载通道（§6.3），不改仓库行为

资产使用顺序建议：代码仓（不 gated）→ 模型页（确认下载卡）→ 数据仓（等批）→ 评估工具（报告线才需要）。

附录 N：本条目核验快照记录

项	值
核验日期	2026-10-09（本库快照，随时间会失效）
源一	arXiv abs/2606.16991 页面（标题/作者/日期/摘要口径/BibTeX）
源二	HF Datasets API 与数据卡（经 hf-mirror.com；gated 配置/configs/tags/时间戳/许可）
源三	GitHub API api.github.com/repos/xmed-lab/TriALS-Report（repo id 1246590622；README 协议与结果表）
交叉印证	规模与 split 三源一致；232 与词典三方一致；AUC 双口径各自自洽且有唯一官方解释
未核事项	Center 2 来源属性、MICCAI 2026 具体会期、命名官方释义、逐条提取精度（§9.3 遗留疑点）
复核建议	读者引用动态字段（downloads 等）前自行重抓；静态字段以论文与仓库最新版为准

附录 O：库内任务矩阵（本集位置一表看清）

条目（rid）	图像分类/多标签	分割	报告生成	报告结构化	体积+文本配对
trials-report（本条目）	●（232 维器官级）	—	●（跨相位）	—	●（NCCT+增强期报告）
trials（661）	—	●（肝病变）	—	—	—
trialbench（46）	●	●	●	—	●（多任务面）
rad-chestct（819）	—	—	—	—	●（胸部 CT+报告）
synthrad（671）	—	—	—	—	●（平扫↔合成增强）
radgraph（561）	—	—	—	●（token 级）	—
radgraph2-radiology-reports（622）	—	—	—	●	—
radvlm-instruction-dataset（624）	—	—	●（指令形态）	—	●
radialog-instruct-dataset（625）	—	—	●（对话形态）	—	●
vqa-rad（240）	●（问答形态）	—	—	—	●（图像+问题）
clinicaltrials-gov（556）/ aact（230）	—	—	—	—	—（试验文本数据，无影像）

读法：● 为该条目覆盖的任务形态。本集的差异化组合 = 232 维器官级多标签 + 跨相位报告生成 + 平扫体积与增强期报告的跨相位配对，三者同时成立仅此一条；单任务需求可沿矩阵行找到更专的条目。

附录 P：常见错误与排查表

症状	可能原因	处置
CLI 下载 403	gated 未获批 / token 失效	核对批准状态与账号（§6.2）；勿重复刷申请
raw 端点匿名访问 404/403	gated 仓库平台锁定（坑 6）	属预期行为；获批后走 CLI
labels.csv 行数 ≠ ct/ 文件数	下载中断 / 解压不全	重跑 CLI 校验后补拉（§2.7 体检第 1 项）
finding 列与词典对不上	config 混用 / 版本错位	确认 labels 与 label_dictionary 来自同一仓库快照
organ-level AUC 对不上官方	聚合顺序 / split 用错 / 口径混排	按 §5.7 核对聚合顺序；确认 test 用 Center 1 的 219 例；核对坑 3 口径
复现值比 README 低 1-3 点	未设种子 / 未按 val 选 epoch（落进论文口径）	对照 §4.6 骨架第 4 步；这是口径差不是 bug
bootstrap 区间异常窄	重采样单元错在标签层	改回患者级（§5.7）
pos_weight 报错或全阴列 NaN	极稀疏列未处理	§2.7 体检第 5 项识别后 nan-safe（§5.7 safe_auc）
Center 2 调参后 external 虚高	污染外部集（坑 2）	回滚，Center 2 仅终评一次
引用被质疑数字来源	双口径未注明（坑 3）	按 Q21 模板补注出处
想找增强期图像找不到	本集不发布增强期（§2.2）	改道 synthrad(671) 或自行申请原始采集
误用了 trials(661) 的数据	近名混淆（坑 7）	三锚点核身份：arXiv 号 + 任务 + 器官范围

附录 Q：字段与变量速查

字段/变量	所在文件	类型	说明
patient_id	labels.csv / 文件名	字符串主键	贯穿标签、图像、bootstrap 单元
center	labels.csv	类别	Center 1（内部）/ Center 2（外部）
split	labels.csv	类别	train 760 / val 106 / test 219（Center 1）；Center 2 全测试
image	labels.csv	引用	指向 ct/<patient_id>.nii.gz
232 个 finding 列	labels.csv	二值	列名经词典映射；未提及=阴性（弱监督前提）
column	label_dictionary.csv	键	与 labels.csv finding 列名一致
organ	label_dictionary.csv	类别	16 器官 + Multi-organ；organ-level 聚合依据
question	label_dictionary.csv	文本	问句化临床表述；VQA/指令构造原料
体积	ct/*.nii.gz	NIfTI	512×512、面内 0.875×0.875 mm、层厚 1.07 mm
D	编码器输出	数值	特征维度（因编码器而异，探针输入）
pos_weight	训练配置	向量(232)	按训练集阳性率设定
threshold 0.5	推理配置	标量	概率二值化阈值
n_boot = 1,000	评估配置	标量	patient-level bootstrap 次数

---

相关数据集导航

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

• headline — 共享标签：医学影像 / CT / 医疗NLP / 多模态
• revapo — 共享标签：医学影像 / 医疗NLP / 多模态 / 评测基准
• ms-cxr-t — 共享标签：医学影像 / 医疗NLP / 多模态 / 评测基准
• vlm3d — 共享标签：医学影像 / CT / 多模态 / 评测基准
• osic-pulmonary-fibrosis — 共享标签：医学影像 / CT / 多模态 / 评测基准
• bic-mac — 共享标签：医学影像 / CT / 多模态 / 评测基准
• omnimedvqa — 共享标签：医学影像 / 医疗NLP / 评测基准
• gmai-mmbench — 共享标签：医学影像 / 医疗NLP / 多模态
• pathvqa — 共享标签：医疗NLP / 多模态 / 评测基准
• reflacx-xray-localization — 共享标签：医学影像 / 医疗NLP / 多模态

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