HISTAI — 11 万张全切片+47,279 例临床元数据的研究用非商用病理语料

INFOBOX — HISTAI 一屏速览

维度	内容
本质	hist.ai 发布的多器官 WSI + 临床文本语料，独立采集队列（不是 TCGA 子集）
论文	arXiv:2505.12120v1（2025-05-17），3 作者，纯数据集公告，无期刊卷期、无实验
规模	论文口径 60,110 张 / 26,142 例 / 8 子集；仓库现状 112,801 张 / 47,279 例 / 9 子集（差一个 mixed）
组织	皮肤 b1+b2、结直肠 b1+b2、乳腺、胸科、胃肠、血液；皮肤占约 47.4% 病例
元数据	病例级 JSON，11 字段：诊断/结论/鉴别/Micro/补充/年龄/性别/ICD-10/专科/case_mapping/大体
标注	无像素级、无 patch 级、无官方划分——只有图像 + 临床文本
许可	CC BY-NC 4.0，研究用非商用；商用须另洽 models@hist.ai
获取	HF 全部 gated=manual 人工审批，10/10 仓库；无镜像、无 Kaggle/Zenodo 版本
质量审计	Kather 组 2026：conclusion 与 diagnosis 仅 20.7% 一致、27.1% 冲突；8 例诊断错误
库内互链	TCGA（rid 566，≠上游）、PANDA（560）、LEOPARD（636）、SICAPv2（328）

HISTAI 是一个"反向"的病理数据集：它不来自某个公开竞赛或国家项目，而是由一家商业数字病理公司（hist.ai）把自己能拿到的多器官切片整理出来，以 CC BY-NC 4.0 挂上 HuggingFace，用一道人工审批的门把它挡在研究用途之内。它的价值不在标注深度——这里没有一张像素级掩码、没有官方划分、论文里也没有一个实验——而在于规模与模态组合：十万级全切片配上病例级临床文本、ICD-10 编码和大体描述，构成计算病理学少见的"图像 + 报告"配对语料。

它同时也是一份被公开检视过的数据集。2026 年 4 月，Kather 团队在《The Journal of Pathology: Clinical Research》发表 Letter，对其中 328 例做病理医生主导的审计，发现报告 47,279 例里只有 44,564 个唯一病例、年龄性别仅 55% 可得、诊断列与结论列只有两成一致、198 例细读中 30.3% 结论模糊且 8 例诊断错误。这篇"valuable dataset with a valuable lesson"的标题，几乎可以作为阅读本条目的总纲。

导语读法三则：

1. 只想下数据：直奔 §6——全部仓库都是 gated，先看审批话术与许可边界，别指望 load_dataset 一把梭。
2. 想做模型：直奔 §4 与 §5——这里没有官方标签，conclusion 才是临床金标准，diagnosis 是临床申请单上的入诊印象，两者不是一回事。
3. 想引用规模：直奔 §3 的双口径表——论文说 60,110，仓库说 112,801，差的是 mixed 子集，引用时必须带抓取日期。

§0 导读：这个数据集解决什么问题

计算病理学的公共数据长期呈"哑铃形"：一端是竞赛型数据集（CAMELYON、PANDA、MIDOG），标注精、规模小、单一器官；另一端是 TCGA 这类国家级队列，规模大、癌种多，但切片来自少数机构、以肿瘤冰冻/石蜡样本为主，而且临床文本字段有限。中间地带——十万级、多器官、日常诊断级样本、带完整病理报告文本——长期空缺。

HISTAI 的定位正是填补这一段。论文开篇把动机讲得很直白：公开 WSI 数据集"缺乏足够的规模、组织多样性与完整临床元数据"，限制了 AI 模型的鲁棒性与泛化能力；于是他们发布一个"大型、多模态、开放获取"的 WSI 集合，每例配诊断、人口学、病理注释与标准化诊断编码。README 里的说法更豪迈——“112,000+ 张切片，覆盖多个器官系统与病理专科”。

这个定位带来的三个后果，构成了本条目后半部分的全部张力：

第一，规模是滚动增长的，论文追不上仓库。 arXiv v1 自 2025 年 5 月上线后从未更新，表 1 停在 60,110 张 / 26,142 例；而仓库在 2025 年 9 月做了一次批量更新，加入了 mixed 子集，总量变成 112,801 张 / 47,279 例。两个数字都真实，但指的不是同一个时点。

第二，"开放获取"是有条件的开放。 论文只写了 open-access 与一个 GitHub 链接，真正的门在 HuggingFace 上：10 个仓库全部 gated=manual，需要登录、提交申请、等待人工审批。数据集卡的说明甚至写着，如果申请者不支持（不点赞、不收藏）他们的仓库，他们保留拒绝的权利。

第三，元数据是真实临床文本，因此也带着真实临床文本的全部噪声。 字段来自医院病理系统的原始记录，不是结构化的金标准标签。Kather 组的审计把这个代价量化了出来：要从这些文本里取出可用标签，需要病理医生逐例复核。

§0 读法三则：

1. 本条目处理的是一份公告型论文 + 持续演进的仓库，凡涉及数字，一律给出"论文口径/仓库口径/抓取时点"三要素（§3）。
2. 它与库内 TCGA（rid 566）没有任何数据血缘——论文提到 TCGA 只是放在 Related Work 里做对比（坑点 1）。
3. 想用它做监督学习的人，请先读 §4.3 与 §5.3：conclusion 与 diagnosis 的冲突率是 27.1%，这决定了你的标签工程要做多少工作。

§1 数据集速览：十七问十七答

Q1：HISTAI 到底是什么？谁做的？
一份多器官全切片图像（WSI, whole slide image）语料，由商业公司 hist.ai 发布。论文作者三人：Dmitry Nechaev、Alexey Pchelnikov、Ekaterina Ivanova，联系邮箱分别为 dmitry@hist.ai、alex@hist.ai、kate@hist.ai。它不是医院、学会或国家项目发布的，这一点决定了它的许可与治理方式。

Q2：到底有多少张切片、多少个病例？
取决于你问哪个时点。论文（2025-05-17）说 60,110 张、26,142 例、8 个子集；GitHub README 与 HuggingFace 仓库现状（2026-10 抓取）说 112,801 张、47,279 例、9 个子集。差额完全由新增的 HISTAI-mixed 子集（52,691 张 / 21,137 例）解释。

Q3：覆盖哪些组织？
9 个子集：hematologic（血液/淋巴结）、gastrointestinal（胃肠）、breast（乳腺）、thorax（胸部/肺）、skin-b1、skin-b2（皮肤，两个批次）、colorectal-b1、colorectal-b2（结直肠，两个批次）、mixed（混合）。论文只用 8 个，mixed 是后来加的。

Q4：有标注吗？
有标注，但不是图像标注。每例有一条 JSON 元数据记录，11 个字段：diagnosis、conclusion、diff_diagnosis、micro_protocol、additional_info、age、gender、icd10、specialization、case_mapping、grossing。没有像素级掩码、没有 patch 级类别标签、没有官方 train/val/test 划分。

Q5：许可是什么？能商用吗？
CC BY-NC 4.0，明确"仅用于研究目的"。GitHub README 原文：“licensed under CC BY-NC 4.0 and intended for research purposes only. For commercial use, contact models@hist.ai.” 商用必须另签协议。

Q6：怎么拿到数据？
在 HuggingFace 申请 histai/HISTAI-metadata 及各子集仓库的访问权限，等待人工审批，通过后用 snapshot_download 或 git lfs clone 拉取。全部 10 个仓库都是 gated=manual，没有免审入口。

Q7：图像规格？
以 20× 为主（README 口径 110,338 张，论文口径 57,647 张），40× 为 2,463 张；染色以 H&E 为主（README 口径 92,536 张），另有 IHC 16,920 张、其他 3,345 张（论文只笼统写"H&E 58,282 / 其他 1,828"）。扫描仪以 Leica Aperio GT450 与 AT2 为主，部分 Hamamatsu 与 3DHISTECH；论文明确"无法确定单张切片的扫描仪型号"。

Q8：它的标签可信吗？
这是本条目最重要的一问。第三方病理医生主导的审计（Hewitt 等，J Pathol Clin Res 2026;12(3):e70089）给出：conclusion 与 diagnosis 仅 20.7% 一致、27.1% 冲突；198 例细读中 30.3% 结论模糊，8 例诊断错误；55 例成人弥漫性胶质瘤无一符合 WHO CNS5。结论是：可用，但必须先做临床校验。

Q9：有官方基准或评测吗？
没有。论文是纯数据集公告，没有实验、没有 baseline、没有 leaderboard。社区对它的"评测"实际上是 2026 年那篇数据质量审计，评的是数据而不是模型。

Q10：怎么和 TCGA 区分？
TCGA 是美国 NCI/NHGRI 的国家级项目，约 33,500 张 H&E 诊断切片、11,000 患者、33 个癌种，主要来自美国机构。HISTAI 是 hist.ai 的商业来源队列，论文只在 Related Work 列举 TCGA 作对比。二者无重叠、无血缘，引用时不可互换。

Q11：数据来自哪个国家、哪家医院？
未公开。 论文没有列作者机构，也没有列数据采集机构；README 同样不提。这是本数据集最实质的信息缺口，也是 Kather 组批评的"溯源记录有限"所指。任何"来自某某医院"的说法都是猜测。

Q12：有没有伦理审查编号？
未公开。 论文没有 Ethics 章节，没有 IRB 批号，没有知情同意方式的说明。使用者若在本机构申请研究伦理豁免或审查，HISTAI 不提供支持材料，需要自行说明数据来源的合规性。

Q13：单张切片多大？全量下载要多少空间？
未公开。 论文与 README 都没有给出单张体积或总体积；HF API 只暴露仓库文件数，不暴露 LFS 对象总大小（metadata 仓库除外，约 59.6 MiB）。工程上建议先下最小子集试跑（见附录 E）。

Q14：怎么复现论文里的数字？
论文没有实验，所以"复现"只能指复现数据统计。可行路径：申请 metadata 仓库 → 按 case_mapping 统计各子集病例数 → 对比表 1 的 26,142。切片数可直接用 HF API 的 siblings 计数减 2 复现，已在本条目逐个子集做过（附录 A）。

Q15：有没有中文资料或中文社区实践？
未检索到。 本条目在检索中未发现中文论文、中文博客系统介绍 HISTAI 的使用经验。中文语境下常见的是数据集清单类文章，多转述 arXiv 摘要的 “60,000+ slides”，通常不提及 112,801 的仓库现状，也不提 gated 审批——这两点恰恰是最容易让人误判的地方。

Q16：如果我只想要一部分，最小的可用单元是什么？
按仓库粒度申请。最小的是 HISTAI-colorectal-b2（94 张 / 62 例）与 HISTAI-gastrointestinal（202 张 / 120 例）。但要注意：小仓库的统计功效极低，通常只适合作管线联调，不适合建模。做研究建议的最低配置是 HISTAI-breast（1,925 张 / 1,692 例，病例数够、体积适中）。

Q17：能不能用它做病理基础模型的预训练？
可以，这是它设计上的主要用途。但四个前提必须满足：一、通过审批；二、接受 CC BY-NC 的商用限制；三、有足够的存储与 IO（十万级全切片）；四、接受无标签（只能自监督或图文对齐）。历史上有团队用 TCGA 全集做同类自监督预训练，HISTAI 的定位与之相近。

§2 数据构成与规格

2.1 九个组织子集

HISTAI 的组织结构是"子集即仓库"：每个组织子集在 HuggingFace 上是一个独立数据集仓库，可以单独申请、单独下载。这样做的好处是研究者不必为研究皮肤病而拉几十万张无关切片；代价是元数据被切散在 9 个仓库加 1 个总元数据仓库里。

子集仓库	论文口径 slides	论文口径 cases	仓库实测 TIFF 数	观察
HISTAI-skin-b2	43,757	20,621	43,757	规模主体，占全部病例 43.6%
HISTAI-skin-b1	7,710	1,778	7,710	皮肤另一批次
HISTAI-colorectal-b1	5,379	998	5,379	结直肠主批次
HISTAI-breast	1,925	1,692	1,925	每例切片数最少（≈1.14）
HISTAI-thorax	829	657	829	胸部/肺
HISTAI-hematologic	214	214	214	一例一片
HISTAI-gastrointestinal	202	120	202	论文中唯一 slides>cases 但仅 1.68 的子集
HISTAI-colorectal-b2	94	62	94	极小批次
论文合计（8 子集）	60,110	26,142	60,110	与表 1 逐行吻合
HISTAI-mixed	—	—	52,691	论文未收录，README 新增
仓库合计（9 子集）	112,801	47,279	112,801	README 口径

"仓库实测 TIFF 数"一列是本条目在 2026-10-17 通过 HuggingFace 镜像 API 对每个仓库的文件树计数所得（扣除 .gitattributes 与 README.md 两个非切片文件）。8 个子集的实测值与论文表 1 逐行完全一致——这是三源互证中最硬的一环：论文的数字不是估算，而是可枚举的文件计数；它也说明 2025 年 9 月的那次更新没有改动这 8 个子集的内容。

2.2 规模双口径：60,110 还是 112,801

两个数字并存的原因很单纯，但引用时极易出错。

口径 A（论文，2025-05-17）：60,110 张 / 26,142 例 / 8 子集。arXiv v1 只有一版，从未更新，因此这个数字停在数据集首次公开的状态。

口径 B（仓库，2026-10 抓取）：112,801 张 / 47,279 例 / 9 子集。差额 52,691 张 / 21,137 例，恰好等于 HISTAI-mixed 子集的文件数。

两个数字的关系是加法而非替换：

112,801 - 60,110 = 52,691（= mixed 的 TIFF 数）
47,279 - 26,142 = 21,137（= mixed 的病例数）

也就是说，README 的"112,000+ 切片"不是对论文的更正，而是 8 个子集再加一个 mixed 子集的合计。这一点在 GitHub README 的统计表里写得很清楚——mixed 与其余 8 行并列，总计栏写 112,801 / 47,279。

引用建议：学术写作中若引用论文，写 60,110 / 26,142 并注明 arXiv:2505.12120（2025）；若描述可实际下载的数据量，写 112,801 / 47,279 并注明抓取日期。两者混用会导致"某人下载了 11 万张却说用了 6 万张数据集"这类无法复现的表述。

2.3 病例与切片的结构

文件命名遵循 README 规定的两种形式之一：

histai/<subset>/case_<case_id>/slide_<stain>_<slide_number>.tiff
histai/<subset>/case_<case_id>/slide_<magnification>_<stain>_<slide_number>.tiff

实测（skin-b2 仓库文件树）为 case_00000/slide_H&E_0.tiff、case_00002/slide_H&E_1.tiff 这样的形式；病例目录号从 case_00000 起连续编号。当倍率不是标准 20× 时，文件名会显式带上倍率段，这是论文 3.1 节的约定——“以其他倍率（主要为 40×）拍摄的切片在文件名中显式注明倍率”。

每例切片数分布很不均匀：breast 平均 1.14 张/例（大量单切片病例），skin-b2 平均 2.12 张/例，整体 2.39 张/例（README 口径）。这意味着病例级任务（如报告生成、病例分类）必须自己做切片聚合，数据集不提供病例级图像表示。

病例编号是重排后的连续整数，不带医院前缀、不带年份信息。这一点直接影响可追溯性：仅凭目录名无法判断某例来自哪家医院、哪一年。

2.4 图像技术规格

属性	规格	口径来源
主要倍率	20×（110,338 张）	README
次要倍率	40×（2,463 张）	README / 论文一致
主要染色	H&E（92,536 张）	README
其他染色	IHC（16,920 张）、其他（3,345 张）	README
论文染色口径	H&E 58,282 / 其他 1,828	论文 3.4 节（仅 8 子集）
扫描仪	Leica Aperio GT450、AT2 为主；部分 Hamamatsu、3DHISTECH	论文 3.1 / README
单张扫描仪型号	不可确定	论文原话：we can’t determine the exact model of the scanner for individual slides
文件格式	TIFF（全切片金字塔格式）	仓库文件树
空间分辨率	未公开（μm/px 未在论文或 README 中给出）	—

两个细节值得单独记下。其一，IHC 的存在是 HISTAI 相对多数病理公开集的差异化资产：TCGA 以 H&E 为主，IHC 极少；PANDA、CAMELYON 等竞赛集全是 H&E。16,920 张 IHC 切片意味着可以做 H&E-IHC 配对检索、染色迁移或免疫组化预测等任务——前提是同一病例的 H&E 与 IHC 切片都能取到，而 case_mapping 字段正是为此设计的。其二，倍率与染色的口径在不同文档里不一致：论文的 58,282/1,828 只覆盖 8 个子集，README 的 92,536/16,920/3,345 覆盖全部含 mixed。这不是冲突，是两个统计范围，但极易被误读成"论文写错了"。

2.5 子集偏斜：一份"皮肤病数据集"的自我认知

按病例数计算（README 口径，47,279 例）：

归并类别	病例数	占比
皮肤（skin-b1 + skin-b2）	22,399	47.4%
结直肠（colorectal-b1 + b2）	1,060	2.2%
乳腺	1,692	3.6%
胸部/肺	657	1.4%
胃肠	120	0.3%
血液	214	0.5%
mixed	21,137	44.7%

8 个具名组织中，皮肤接近一半。若只看具名子集（排除 mixed），皮肤占比高达 85.6%。这个偏斜有两个来源：一是真实来源机构以皮肤病理业务为主，二是"b1/b2"这种分批发布的组织方式会让高频业务自然累积成主子集。

第三方审计从另一个角度印证了这种偏斜：Kather 组报告皮肤病病理占 47.1%、胃肠病理占 24.0%（注意后者与本文按子集算出的 0.3% 差异极大——说明 mixed 子集内部的组织构成并非均质，胃肠病例大量沉淀在 mixed 里）。更关键的发现是：专科字段只对 39.6% 的病例显式标注，因此这个偏斜在元数据层面是"被掩盖"的——你不能靠 specialization 字段做分层抽样，因为一半以上的样本没有这个字段。

2.6 mixed 子集：一个未定义的黑箱

HISTAI-mixed 是理解本数据集全部规模争议的关键，但它也是文档最薄的一块。

已知事实：52,691 张 TIFF、21,137 个病例目录、2025-09-23 上线、仓库下载量 8,521（抓取时点）、likes 83。

未知事实：它与 8 个具名子集是否互斥。README 没有说明 mixed 是"从尚未分类的病例中抽出的补充集"还是"对全部病例的合并视图"。如果后者，112,801 就是一个含重复计数的总量，“11 万张"的说法就需要打折。Kather 组的核账给了间接证据：报告 47,279 例，实际唯一病例 44,564 例——缺掉的 2,715 例被解释为"缺失条目与重复记录”。这个差值（5.7%）远小于 mixed 的占比，说明重复不是全量重叠，但确实存在。

对使用者的实操含义：在 mixed 与具名子集之间做去重之前，不要合并使用。可用的去重线索是 case_mapping 字段（指向 histai/HISTAI-xxx/case_13384 形式的具体仓库路径），但它在 mixed 里的填写率未公开。

2.7 病例编号的含义与可追溯性边界

病例目录从 case_00000 起连续编号，每个子集独立编号。这一设计带来三个具体的检索后果，值得在数据字典里写清。

其一，编号不可跨子集寻址。 skin-b1/case_00000 与 skin-b2/case_00000 是两个完全不同的病例。若脚本只按 case_00000 建索引，跨子集合并时会静默覆盖。稳妥做法是以 (subset, case_id) 二元组作主键，或直接用 case_mapping 字段里的完整路径。

其二，编号不携带时间与机构信息。 真实医疗数据的病例号往往编码了年份与科室，HISTAI 重排后这些信息全部丢失。这意味着无法做"按年代分层"的时序分析，也无法判断某一批切片是否集中来自同一台扫描仪。论文说"无法确定单张切片的扫描仪型号"，与这个重排设计是一体的两件事。

其三，连续编号暗示存在未被收录的病例。 如果编号从 0 连续到 N-1 而无空洞，说明子集是完整的一段连续分配；若有空洞，说明中途剔除过病例（原因未公开）。这一点只能在获得授权后枚举目录才能验证，属于"拿到数据后第一小时该做的事"。

实操建议：建索引时同时记录三个量——目录总数、编号最大值、编号空洞数。三者与元数据记录数三方对齐，才能确认这一子集没有残缺。

§3 时间线与版本演进

3.1 一条没有期刊卷期的时间线

HISTAI 的论文形态需要单独说明：它不是期刊论文，而是 arXiv 预印本（eprint 2505.12120），只有 v1，提交时间为 2025-05-17 18:59:32 UTC，篇幅 25 KB（PDF 文件），学科分类 eess.IV 与 cs.CV 双挂。arXiv 页面没有 “journal-ref” 字段，也就意味着截至抓取时点，这份公告没有被任何期刊接收。DOI 为 arXiv 自动分配的 10.48550/arXiv.2505.12120，属于 DataCite 注册，不是出版商 DOI。

这在计算病理学圈内并不罕见——数据集公告常以预印本形式发布，配套的"正式文献"交给社区去写。HISTAI 的特殊之处在于，这个位置确实被一篇第三方 Letter 占据了（见 §3.3），但那是批评性审计，不是数据集作者自己的技术报告。

时间	事件	可核来源
2025-05-06	histai/HISTAI-metadata 仓库在 HF 创建（createdAt）	HF API
2025-05-17	arXiv v1 上线；GitHub license 文件同日提交	arXiv 页面 / GitHub 提交记录
2025-06-04	GitHub README 最后一次更新（扩到 112,801 口径）	GitHub 提交记录
2025-09-23	8 个组织子集仓库 lastModified 统一刷新（批量更新）	HF API 各仓库
2026-04-15	Kather 组审计 Letter 在线发表	TU Dresden 门户
2026-05	该 Letter 正式卷期（12 卷 3 期）	Wiley 书目
2026-10-16	HISTAI-metadata 仓库 lastModified（抓取前一日）	HF API

时间线上最值得注意的是 2025 年 5 月至 6 月之间的口径切换：论文在 5 月 17 日发布时写的是 60,110；README 在 6 月 4 日已经把总数改成 112,801 并列出 mixed 子集。也就是说，论文从上线起就已经落后于仓库，这个时间差不是后来的漂移，而是发布当时就存在的不同步。

3.2 版本链：没有版本号，只有时间点

HISTAI 没有 v1.0、v2.0 这样的版本标记，也没有 changelog。版本信息只能从仓库的 lastModified 时间戳反推：

• 8 个组织子集：lastModified 统一为 2025-09-23（skin-b2 11:06、colorectal-b1 11:08、breast 11:05、skin-b1 11:06 等），说明当天做过一次贯通所有子集的批量操作——很可能是补入 mixed 时的连带刷新。
• HISTAI-mixed：lastModified 2025-09-23 11:05。
• HISTAI-metadata：lastModified 2026-10-16，是唯一在 2026 年仍被改动的仓库，且改动发生在抓取前一日。

metadata 仓库的持续更新是个信号：临床元数据仍在补录或清洗。但因为是 gated 仓库，外部无法看到具体改了什么——文件树匿名查询返回 Access to dataset histai/HISTAI-metadata is restricted。

引用规范建议：引用时写 “HISTAI (hist.ai), accessed 2026-10-17, HuggingFace histai/HISTAI-metadata”，并注明"规模随仓库演进，论文口径见 arXiv:2505.12120"。这个写法在数据集论文中很常见，也比编一个不存在的版本号更诚实。

3.3 2026 年的那道分水岭：Kather 组审计

HISTAI 在学术界的"第二次出场"来自一篇它自己没参与的论文。

书目信息：Hewitt KJ, Reitsam NG, Foersch S, Erber R, Zeng Q, Kather JN. “HISTAI: a valuable dataset with a valuable lesson.” The Journal of Pathology: Clinical Research. 2026;12(3):e70089. doi:10.1002/2056-4538.70089。在线 2026-04-15，卷期 2026 年 5 月，共 8 页，同行评议。作者机构包括 Else Kröner Fresenius 数字健康中心（TU Dresden）、美因茨大学医学中心、雷根斯堡大学、海德堡 NCT 与利兹大学。

研究设计：病理医生主导，对 328 例抽样做标签准确性、元数据完整性与数据集构成的评估；另对 198 例做重点细读。

核心发现（原文数字）：

维度	发现
病例计数	报告 47,279 例，去缺失与重复后 44,564 唯一病例
人口学字段	年龄与性别仅 55% 病例可得
组织构成	皮肤病理 47.1%、胃肠病理 24.0%（但专科仅 39.6% 显式标注，掩盖了偏斜）
诊断列 vs 结论列	仅 20.7% 一致；27.1% 相互冲突
结论质量（198 例）	30.3% 模糊或歧义；其中 8 例诊断本身错误
分子标注	分析的肺癌与结直肠癌病例中仅 18.9% 含分子信息
胶质瘤	55 例成人弥漫性胶质瘤无一符合 WHO CNS5；仅 15 例报告 IDH 状态
溯源与伦理	数据溯源与伦理监督"记录有限"（limited documentation）

标题的含义：“a valuable dataset with a valuable lesson”——有价值的资源，也有价值的一课。这一课的对象不是 HISTAI 作者，而是整个社区：规模大不等于标签可用，临床文本不等于结构化的 ground truth。

对使用的直接含义：把 HISTAI 当作"带标签数据集"使用会犯错。正确姿势是把它当作带原始临床文档的图像语料，标签需要从 conclusion 列重建，并且需要病理医生抽样复核。Kather 组的建议原文是 “careful clinical validation and close collaboration between computational researchers and pathologists”。

3.4 第三方评估在学术谱系上的位置

Kather 组的审计不是孤立事件，它属于计算病理学近年一个逐渐成熟的研究范式：数据集审计（dataset audit）。理解这个范式，有助于判断 HISTAI 的审计结论该如何使用。

审计范式的三个特征：以病理医生为主导（而非工程师）；抽样而非全量；关注标签而非模型。Kather 组这次对 328 例抽样、198 例细读，正是这套做法。同类工作还包括对 TCGA 部分子集的诊断复核、对若干公开皮肤病理集的标签质量评估等。

审计结论的三条使用边界：

1. 不能外推到全量。 328 例相对 47,279 例是 0.69% 的抽样。作者报告的是"在这 328 例里观察到…“，而非"全数据集有 27.1% 冲突”。引用时应保留"在抽样中"这一限定语。
2. 不能替代逐例校验。 审计告诉你"问题存在且不罕见"，不告诉你"你用的那 1,000 例里哪几例有问题"。后者只能自己在目标子集上重做。
3. 不能作为"数据无用"的判决。 审计的结论原文是"valuable open-source resource"+“careful clinical validation”——即"有价值，但要小心用"。把它读成"这数据集不能用"是过度解读。

一个反向的观察：这篇 Letter 的存在本身是 HISTAI 的一项隐性资产。多数公开病理数据集从未被独立审计过，使用者对其标签质量只能猜测。HISTAI 至少有一份公开的、同行评议的、带具体数字的评估报告，这让使用者在知情的前提下做出选择——知道坑在哪，比不知道要好。

3.5 时间线上的三个空白

按时间顺序排列已知事件后，有三段时间完全空白，值得标注出来：

空白一：数据采集期。 论文没有说明这些切片是何时扫描的。从"20× 为主、含 40×"的混合倍率看，采集期可能跨越了扫描仪更新的若干年，但具体区间未知。这个空白影响"数据是否反映当前诊断实践"的判断。

空白二：2025 年 5 月至 9 月。 论文 5 月发布时是 8 子集 60,110 张；9 月 23 日所有仓库 lastModified 刷新、mixed 上线。这四个月里发生了什么、mixed 的 21,137 例从哪来，全部未公开。

空白三：2025 年 9 月至 2026 年 10 月。 8 个组织子集在这段时间没有变动（lastModified 停在 2025-09-23），但 metadata 仓库在 2026-10-16 仍有改动。说明这一年多里在持续维护元数据，但改了什么无法得知（gated 仓库）。

这三个空白的共同含义：HISTAI 的可追溯性停留在"版本时间戳"层面，无法下钻到"内容变更"。这正是 §9 里 D6 治理与溯源只给 1.0 分的原因——不是没有时间线，而是时间线只有刻度没有内容。

§4 元数据体系与标签工程

4.1 十一个字段

元数据以 JSON 提供，每例一条，字段与 README 的定义如下：

字段	语义	示例（README 原例）
diagnosis	来诊临床记录（incoming clinical notes）	Benign skin neoplasms
conclusion	最终病理结论	Intradermal melanocytic nevus of the skin
diff_diagnosis	鉴别诊断记录（如有）	—
micro_protocol	镜下描述	Skin: Intradermal melanocytic nevus
additional_info	补充临床/病理说明	A repeat review of histological specimens was performed…
age	患者年龄（岁）	37
gender	性别	f
icd10	ICD-10 编码	D22
specialization	医学专科或器官系统	Skin
case_mapping	指向切片图像的引用	histai/HISTAI-skin-b2/case_13384
grossing	大体检查描述	Head and neck: One fragment, 2×4 mm, gray, firm…

论文把这 11 个字段归纳为 8 大类：Diagnosis、Conclusion、Differential Diagnosis、Micro Protocol、Additional Information、Patient Demographics（age、gender）、ICD-10 Codes、Gross Examination Details。README 比论文多列了 specialization 与 case_mapping——后者是结构性字段而非临床字段，specialization 则是组织归属的显式标注（也正是审计发现只有 39.6% 填写率的那个字段）。

4.2 从字段到任务：四种可用形态

因为没有任何图像级标注，HISTAI 的任务价值全部来自"字段 × 图像"的组合。可操作的四种形态：

形态一：图像-文本对齐（vision-language）。conclusion 与 micro_protocol 是天然的图像描述文本，粒度比一般图文数据集更细——镜下描述往往包含细胞形态、排列方式、间质反应等细节，正好对应切片内容。适合 CLIP 式对比学习、报告生成、图文检索。

形态二：ICD-10 多标签分类。icd10 是标准化编码，可直接作为监督信号训练图像分类器。这一条的优势在于标签体系外部可验证——ICD-10 有公开的层级结构，模型输出可以映射回疾病大类。风险是：标签来源是 diagnosis 还是 conclusion，会显著改变类别分布（见 4.3）。

形态三：跨器官泛化与域适应。9 个组织子集天然构成域划分，可以测"皮肤训练的模型在结直肠上的迁移"。但要注意 §2.5 的偏斜：跨器官实验的样本量在胸科（657 例）、胃肠（120 例）、血液（214 例）上非常薄。

形态四：H&E–IHC 配对。有 16,920 张 IHC 切片，若同一病例的 H&E 与 IHC 都能通过 case_mapping 关联，则可做染色迁移或 IHC 结果预测。这条路径的可行性取决于配对率，而配对率未公开。

论文自己列出的用途与这四条基本重合：诊断模型开发与基准、跨组织与临床情境的泛化研究、整合临床元数据的多模态病理模型、域适应与迁移学习。

4.2.1 四种文本策略的取舍

四条形态在工程成本与科学价值上差异很大。下面把每条形态的成本与产出摊开，便于按团队能力选择。

形态	前置条件	工程量	主要风险	适合团队
图像-文本对齐	长文本清洗 + 切片-句子配对	高（需要文本编码器与切片编码器双塔）	文本描述与切片内容的对齐粒度不明（一段镜下描述可能跨多张切片）	有 VLM 经验的组
ICD-10 多标签分类	icd10 填写率 ≥ 60%	中（标签现成，只需清洗编码）	编码粒度不均（有的编码到亚型，有的只到系统）	多数入门团队
跨器官泛化	至少两个 ≥ 500 例子集	中（主要是划分与评测设计）	小器官子集统计功效不足	做迁移学习或域适应的组
H&E–IHC 配对	case_mapping 能关联同病例多染色	高（需配对率探查，可能大比例缺失）	配对率未公开，可能做完才发现可用样本太少	有临床合作资源的组

为何把 ICD-10 分类排在入门推荐位：标签现成、外部可验证、评测指标成熟（宏平均 AUROC、F1）。它的主要不确定性是填写率——这一项用一条 SQL 或一段 Python 就能算出来，属于"低成本试错"。

为何图文对齐虽然是卖点却不宜先做：HISTAI 的文本是整份病理报告，不是逐张切片的描述。一份报告可能对应多张切片——整体平均 2.39 张/例，breast 平均 1.14 张/例，皮肤子集多为 2 张以上。把报告与切片配成对，本身就是一个未解决的对齐问题：报告讲的是整例的诊断，而某一张切片可能只包含病变的一角。这一点在文献中通常用「多实例学习」（multiple instance learning）绕开，但那已经不是纯粹的图文对齐。

为何 H&E–IHC 配对要慎重：IHC 有 16,920 张，看着很多，但配对的前提是同一病例同时有 H&E 与 IHC 切片，且 case_mapping 能把它们关联起来。这两个条件的满足率都未公开。建议先申请一个小仓库（如 thorax）做配对率探查，再决定是否投入。

4.3 标签工程的真正难点：两列诊断

本条目最需要读者带走的一条事实：HISTAI 里有两个"诊断"字段，而它们经常互相矛盾。

diagnosis 是来诊时临床医生填写的记录（“incoming clinical notes”），示例为 “Benign skin neoplasms”——一个宽泛的临床印象。conclusion 是病理科出具的最终结论，示例为 “Intradermal melanocytic nevus of the skin”——具体到疾病实体。

Kather 组的量化结果是：两列完全一致仅 20.7%，明确冲突 27.1%（其余为缺失或部分重叠）。冲突的典型形态是宽泛 vs 具体（“良性皮肤肿瘤” vs “皮内痣”）、临床怀疑 vs 病理否定（临床按恶性送检、病理判良性）。

对建模的三个推论：

1. 不要用 diagnosis 做标签。它反映的是送检时的临床怀疑，不是诊断结果，用作监督会系统性地把"良性皮肤肿瘤"与"皮内痣"这类上下位关系当成同类或异类。
2. 用 conclusion，但要先做实体归一。conclusion 是自由文本，疾病名称写法不统一（同义词、缩写、俄英混写），ICD-10 映射需要 NLP 工序。
3. 做多标签而非单标签。病理结论常含多个并列诊断（如"慢性胃炎伴肠上皮化生"），强行压成单标签会丢失信息。

4.4 缺失率的实际分布

审计给出的缺失率只有两处确切数字：人口学字段 55% 可得、专科字段 39.6% 填写。其余字段的缺失率未逐一公布。

可以推知的分布特征：

• age 与 gender 的缺失是成对出现的可能性较高（同一张病理申请单上，两者通常同时填或同时空）。
• diff_diagnosis 在 README 中标注"if available"，缺失率应当远高于其他字段。
• grossing 在小标本（皮肤活检、内镜活检）中常缺失，在大标本（切除标本）中较完整——这意味着该字段的可得性与组织类型强相关，不是随机缺失。
• icd10 的完整性直接决定形态二是否可行，但论文与 README 都未给出填写率。这是使用前必须自查的第一个指标。

实操建议：拿到数据后先做三张表——字段非空率表、conclusion 与 diagnosis 的一致/冲突/缺失三分表、specialization 与子集目录的交叉表。三张表做完，才知道这个子集能不能支撑你的任务。特别是第三张表：如果某子集的 specialization 全是空，说明该子集的病例在元数据层面无法按器官分层。

4.5 一条可执行的标签重建方案

把上面的原则落成工序，建议按以下五步走。这不是唯一方案，但每一步都有明确的失败判据，便于尽早止损。

步骤 1：抽取与分层。按 specialization 与子集目录做分层抽样。若目标子集的 specialization 缺失率高，改用目录层级（skin-b2、colorectal-b1 等）作为分层变量——目录名至少是可靠的，因为它是物理路径。

步骤 2：结论抽取。用规则 + 词典先跑一遍：疾病名多半出现在 conclusion 末句，“符合”、“考虑”、“伴”、"倾向"等中文/俄文连接词可作为切分锚点。不要一上来就上大模型——先用规则跑出 200 例样本，看错误类型，再决定要不要用 LLM 辅助。

步骤 3：实体归一。把抽取到的疾病名映射到 ICD-10。这一步的难点在同义词（“皮内痣” / “intradermal nevus” / "复合痣"的上下位关系）与复合诊断（一例含两个并列疾病）。建议产物是一张"病例 → 疾病集合"的多对多表，而不是单标签表。

步骤 4：病理医生抽样复核。按 5% 起步，若冲突率 > 15% 扩大到 10-20%。复核表要包含：原文结论、模型抽取结果、医生判定（正确/部分正确/错误/无法判断）。Kather 组的 30.3% 模糊率可作为基线预期——如果你的抽样模糊率远低于此，说明抽样偏了。

步骤 5：冻结与版本化。标签表定稿后打版本号（如 histai-labels-v1.0-2026xx），记录抽样比例、一致率、医生名单（可匿名化）、以及所用元数据仓库的 lastModified 时间。后者很重要：metadata 仓库在 2026-10-16 还有更新，说明元数据仍在变。

四条失败判据（命中任一条就应重估是否继续）：

判据	阈值	含义
icd10 非空率（目标子集）	< 60%	ICD-10 分类路线不可行，改用自由文本抽取
conclusion 非空率	< 80%	缺乏金标准来源，只能转向无监督预训练
抽样医生一致率（Cohen’s κ）	< 0.6	标签体系本身不可靠，需重新定义类别粒度
同一病例跨子集重复率	> 10%	必须先做全局去重，否则划分会泄漏

§5 组织、治理与伦理

5.1 三作者、一家公司、零机构信息

论文作者栏只有三人，全部署 .hist.ai 域名邮箱，论文正文没有列任何机构隶属。GitHub 组织页为 histai，与邮箱域名一致。这是一份典型的"公司主导发布"的数据集公告：没有大学实验楼的门牌号，没有医院病理科的致谢，也没有基金编号。

它带来的直接后果是：无法从论文判断数据来自哪个国家、哪家医院、哪套伦理审查流程。Kather 组的评论把这一点写进了结论——“limited documentation of dataset provenance and ethical oversight”（数据溯源与伦理监督的记录有限）。对一个含 47,279 例真实患者临床文本的数据集来说，这是个实质性的治理缺口，不只是文档瑕疵。

5.2 商业模型：CC BY-NC 这道门

许可结构很简单，但设计意图需要看懂：

• 研究用途：CC BY-NC 4.0，免费、可修改、可再分发（须署名、非商用、相同方式共享）。
• 商业用途：必须单独谈判。GitHub README 与数据集卡都指向 models@hist.ai。
• 申请门槛：gated=manual，人工审批。

这三层叠起来的商业逻辑是：用宽许可的"非商用"吸引学术引用与模型生态，用 gated 门控制数据流出，用"商用另洽"把下游变现握在手里。数据集卡里那句"You’re accessing a dataset that would cost millions of dollars to build"把成本叙事摆得很直白。

对研究者的三条实务提醒：

1. CC BY-NC 会传染到模型吗？ 这是法律问题而非技术问题，不同法域判例不同。保守做法是：用 HISTAI 训练的模型若用于商业产品，应事先与 hist.ai 确认。README 只说"data"需商用授权，未说明衍生物。
2. 再分发要带许可。CC BY-NC 4.0 的 SA 条款意味着你若基于它构建并公开衍生数据集，衍生集也要用 CC BY-NC 4.0——这会影响你后续的许可选择。
3. 审批话术要读懂。数据集卡原文：“We reserve the right not to approve the request if you don’t support our efforts.”（若你不支持我们的工作，我们保留拒绝申请的权利。）配套要求是 like 与 upvote 仓库。这在学术数据共享中不常见，但确实是当前的申请条件。

5.3 伦理与合规：已知与未知

事项	状态
伦理审查（IRB/伦理委员会）	未披露（论文无 Ethics 章节）
知情同意方式	未披露
去标识方法（是否去除姓名/ID/日期）	未披露
采集机构与国家	未披露
年龄/性别保留	部分保留（55% 可得），说明未做完整去标识化
文本中是否含可识别信息	未评估——自由文本字段（additional_info、grossing）理论上可能含人名、地名、日期
数据主体撤回机制	未披露

其中"文本中是否含可识别信息"是最需要使用者自行承担的风险：additional_info 与 grossing 是自由撰写文本，README 示例里就有 “Head and neck: One fragment, 2×4 mm, gray, firm…” 这类大体描述，真实数据中可能包含部位、手术方式甚至姓名缩写。在把这些字段用于任何公开演示、论文附录或模型训练日志之前，必须做 PII（个人可识别信息）扫描。

5.4 与姊妹项目的关系

hist.ai 在 GitHub 上维护三个仓库：

• HISTAI：本数据集（WSI + 元数据）。
• SPIDER：多器官监督数据集，带 patch 级标注，arXiv:2503.02876。
• Hibou：面向数字病理的基础视觉模型，arXiv:2406.05074。

三者构成"预训练图像 → 标注数据 → 基础模型"的产品线。对使用者的含义是：HISTAI 的定位是预训练语料，不是评测集——评测的活由 SPIDER 承担，模型由 Hibou 提供。这也解释了为什么 HISTAI 没有官方划分与基准：它就没打算做那个角色。

理解这层产品定位，能避免一个常见误用：有人拿 HISTAI 跑 zero-shot 评测，然后发现没法和其他论文比数字——因为没有任何论文在它上面定义过协议。

5.5 许可合规的四个场景

CC BY-NC 4.0 的条款本身不长，但落到具体使用场景上，判断并不总是显然。以下四个常见场景按风险从低到高排列，判断依据是许可原文与 README 表述，不构成法律意见。

场景一：高校课题组做学位论文研究。 风险最低。属于典型的非商业研究使用，只要署名、保留许可声明、不转售即可。注意学位论文若由企业资助且成果用于资助方产品，可能被认定为商业用途，需提前确认。

场景二：发表论文并公开代码与模型权重。 需要分两层看。数据本身不能再分发（除非同时按 CC BY-NC 再许可）；模型权重是衍生物还是独立作品，许可未作规定。保守做法是在论文中声明训练数据来源与许可，模型权重单独给出许可（如研究用途限定），并注明本模型受训练数据许可约束。更保守的做法是发布前与 hist.ai 确认。

场景三：企业内部研发或产品原型。 高风险。README 只说 for commercial use 请联系 models@hist.ai，这里的 commercial use 覆盖企业内部研发的可能性很大，哪怕产品尚未上市。建议先谈判取得书面许可再动手，不要用还没上线作为理由。

场景四：再分发或构建衍生数据集。 最高风险。CC BY-NC 4.0 含 ShareAlike 条款，衍生数据集须以相同许可发布，且不得商用。如果你的衍生集打算用更宽松的许可（如 CC BY 4.0）发布，或提供给商业伙伴，就需要单独授权。

四条通用纪律：

纪律	具体要求	依据
署名	引用 Nechaev 等 2025（arXiv:2505.12120）并注明 hist.ai	CC BY 署名条款
保留许可	随数据与衍生品附带 CC BY-NC 4.0 声明与链接	CC BY 条款
不商用	任何直接或间接商业收益的使用都需另行授权	README 与 NC 条款
相同方式共享	衍生数据集须用 CC BY-NC 4.0 发布	SA 条款

一个容易被忽略的细节：许可标签分布在 10 个仓库上，每个仓库的 cardData.license 都是 cc-by-nc-4.0。如果只申请了某个子集，你获得授权的范围也只是那个子集——不能因为政策一样就把一个仓库的授权当成全部。

5.6 数据治理的三项建议

对使用 HISTAI 的机构，建议在内部建立三项记录，理由是这份数据集的治理记录本身薄弱，使用者需要自己补齐链条。

建议一：建立审批与下载台账。记录谁在何时申请了哪个仓库、审批结果、下载日期、文件数核对结果。这份台账有两个用途：一是应对机构伦理或合规审查（HISTAI 不提供 IRB 材料，你只能自证来源合法）；二是应对许可到期或政策变更（若 hist.ai 将来收紧条款，台账能证明你获取时的授权状态）。

建议二：给本地副本打指纹。下载完成后计算每个子集的文件列表哈希并留存。理由很实际：metadata 仓库在 2026-10-16 仍在更新，说明上游数据会变；若你的实验结果无法复现，指纹能证明你用的是哪个时点的数据。

建议三：标签表独立版本化。把从 conclusion 重建的标签表当作独立资产，与原始数据分离存储、独立版本号。原因是标签表凝结了病理医生的复核工时，是真正稀缺的部分；而原始数据受许可限制，未来可能无法继续使用。分离之后，即使数据源不可用，标签表的方法学价值仍然保留。

§6 获取、许可与版本链

6.1 完整获取路径（逐步骤）

HISTAI 没有"直接下载"的路，全部走人工审批。完整流程如下：

第一步：准备账号与用途说明。需要一个 HuggingFace 账号（gated 仓库必须登录并绑定邮箱）。申请时通常需要填写机构、用途、是否商业用途。数据集卡暗示的一个隐性条件是"支持"仓库（点赞/收藏）。

第二步：申请 metadata 仓库。官方 README 把它标为 START HERE——先拿元数据，再按需拿图像。这样做的合理性在于：metadata 只有约 60 MB（仓库 usedStorage 62,510,560 B），可以先看字段与病例分布，再决定申请哪个子集。

第三步：按子集申请图像仓库。9 个组织子集各自独立审批。如果只做皮肤研究，就只申请 histai/HISTAI-skin-b2 与 histai/HISTAI-skin-b1，不必过其他子集的审批。

第四步：下载。两种方式：

from huggingface_hub import snapshot_download

snapshot_download(
    repo_id="histai/HISTAI-skin-b2",
    repo_type="dataset",
    local_dir="/local_path",
)

git lfs install
git clone https://huggingface.co/datasets/histai/HISTAI-skin-b2

第五步：核对清单。下载后比对文件数——例如 skin-b2 应为 43,757 个 TIFF（外加 .gitattributes 与 README.md）。这是最省事的数据完整性校验，比算哈希快得多。

6.2 十个仓库的现状（2026-10-17 抓取）

仓库	gated	TIFF 数	downloads	likes	lastModified
histai/HISTAI-metadata	manual	—（仅 README）	176	141	2026-10-16
histai/HISTAI-skin-b2	manual	43,757	10,197	53	2025-09-23
histai/HISTAI-skin-b1	manual	7,710	3,498	未取	2025-09-23
histai/HISTAI-mixed	manual	52,691	8,521	83	2025-09-23
histai/HISTAI-colorectal-b1	manual	5,379	1,158	未取	2025-09-23
histai/HISTAI-colorectal-b2	manual	94	未取	未取	2025-09-23
histai/HISTAI-breast	manual	1,925	646	未取	2025-09-23
histai/HISTAI-thorax	manual	829	未取	未取	2025-09-23
histai/HISTAI-gastrointestinal	manual	202	未取	未取	2025-09-23
histai/HISTAI-hematologic	manual	214	未取	未取	2025-09-23

“downloads” 是 HF 统计的下载次数，反映的是"有人拉了"而不是"有人获批"——gated 仓库的 download 计数在获批用户拉取时累加。skin-b2 的 10,197 次远高于其他子集，说明皮肤病子集是社区最常用的入口；这与它的规模占比一致。

“likes” 一列中 metadata 141、mixed 83 明显高于组织子集，恰好呼应了申请门槛里的"点赞"要求——用户先点赞 metadata 再申请，是标准路径。

所有 10 个仓库的 gated 字段均为 manual，无一例外，包括只含 README 的 metadata 仓库。这一点的实践意义是：连字段说明都要过审批才能看到。本条目对字段的描述全部来自 GitHub README（公开）与 arXiv 论文，而不是 HF 数据集卡。

另需注意下载量的量级差异：skin-b2 与 mixed 两个仓库合计占了全部下载的绝大部分，而 thorax、gastrointestinal、hematologic、colorectal-b2 四个子集在抓取时点没有出现在 API 的高频统计里。这不代表没人用，只说明这些小子集的申请量低——对做小样本器官研究的人来说，一个副作用是社区几乎没有可对标的公开结果。

6.3 许可的三个层次

层次	内容	依据
数据本体	CC BY-NC 4.0，署名 + 非商用 + 相同方式共享	GitHub README License 节；HF 10 个仓库的 license:cc-by-nc-4.0 标签
商业授权	需单独谈判，联系 models@hist.ai	同上
代码/工具	仓库未声明代码许可（GitHub HistAI/HISTAI 只有 license 文件，内容即数据许可）	GitHub 仓库根目录

第三层值得提醒：很多使用者会误以为 GitHub 上的 license 文件是代码许可（如 MIT/Apache）。在 HISTAI 仓库里，这个文件声明的就是数据集许可本身。仓库里也没有任何代码，只有 README——它是一个"入口页"而非软件项目。

6.4 获取不到时的替代路径

如果申请被拒或等待过久，有三条替代思路（都不是官方镜像）：

1. 用 hist.ai 的姊妹项目起步。SPIDER（多器官 patch 级标注）与 Hibou（预训练模型权重）是独立仓库，通常比 HISTAI 本体容易拿到。先用这些验证方法，再等 HISTAI 审批。
2. 用 TCGA 做"穷人版"替代。TCGA 有切片与部分临床字段（但无病理报告全文），可以模拟"图像 + 有限文本"的任务形态；缺点是文本字段远比 HISTAI 薄。
3. 缩小到单子集重试。部分申请被拒的原因是申请范围过大或用途描述模糊。改为只申请一个子集、并写清具体研究问题，通常更容易通过。

没有 Kaggle、Zenodo、PhysioNet 或任何第三方镜像版本。网上出现的"HISTAI 下载"教程若指向非 HF 地址，基本上是把 gated 仓库的申请流程写错了，或者是从获批用户处转手的副本——后者的合规性取决于 CC BY-NC 的再分发条款，且需自行承担溯源风险。

6.5 版本链：一句话说清

HISTAI 没有版本号。判断"你手上的是哪一版"，唯一可靠的方法是记录下载日期 + 各仓库 lastModified + 文件数。三者之中，文件数最有用：它能把你的副本精确对应到某个规模的时点（8 子集 = 60,110 的时点；9 子集 = 112,801 的时点）。若将来 mixed 被拆分或新增子集，文件数会立刻暴露差异。

这个做法听起来原始，但对 HISTAI 这种"论文停更、仓库在动"的数据集是唯一稳妥的。一个具体的建议是：在实验仓库的 README 里写一行"— data: histai 9-subset snapshot, 112,801 tiffs, accessed 2026-10-17"。审稿人或同事据此可以判断你的结果对应哪一版数据。

§7 坑点清单（十个）

坑点 1：把 HISTAI 当成 TCGA 子集或 TCGA 衍生集。
这是本条目最需要防范的误读，也是任务派发时最容易发生的混淆。事实是：HISTAI 论文的 Related Work 一节确实提到了 TCGA——“The Cancer Genome Atlas (TCGA) was a landmark initiative by the NIH and NCI… approximately 33,500 H&E-stained diagnostic WSIs from 11,000 patients were digitized across 33 tumor types”——但这句话是对比，不是来源说明。论文全文没有任何"数据来自 TCGA"的表述，README 也没有。二者的来源、机构、许可、癌种构成完全不同：TCGA 是美国国家级项目的 33 个癌种，HISTAI 是商业公司整合的多器官诊断样本。误把二者混为一谈会导致许可判断错误（TCGA 是公共领域开放，HISTAI 是 gated + 非商用）。库内 TCGA 条目（rid 566）与本条目是两个独立条目，互链但不重叠。

坑点 2：只读论文就引用规模，写出 60,110，但实际下载到 11 万张。
论文 arXiv v1 从未更新，停在 2025-05-17 的 8 子集口径。README 与 HF 现状是 9 子集。正确的写法是双口径并列并注明时点。反过来的错误同样常见：只读 README 写 112,801，却在参考文献里引 arXiv 论文——读者按论文去核对数字会发现对不上。

坑点 3：以为有图像标注。
论文摘要里出现了 “detailed pathological annotations”，这个措辞极具误导性。它指的是病理报告中的文字注释（镜下描述、结论），不是图像上的区域标注。数据集里没有一个掩码、没有一个 patch 标签文件。冲着"像素级标注"来做分割的人会白跑一趟——要去 SPIDER。

坑点 4：把 diagnosis 当金标准标签。
diagnosis 是来诊临床记录，conclusion 才是病理结论。两者仅 20.7% 一致。用 diagnosis 训练会学到一个"临床怀疑分布"而不是"疾病分布"。这是 Kather 组审计里最实用的单条结论。

坑点 5：以为 gated 仓库只是点一下"同意"。
gated=manual 是人工审批，不是 gated=auto 的自动同意条款。有等待期、有被拒可能，且数据集卡明写保留拒绝权。做项目排期时要把这段等待算进去。另外，被拒后可以补充材料重新申请，但 HF 没有公开的申诉渠道。

坑点 6：申请了图像仓库却拿不到字段说明。
很多人先申请 skin-b2 就直接开始拉 TIFF，结果发现不知道 JSON 字段的含义——因为 metadata 仓库是独立的、也要审批。正确顺序是先 metadata 后图像。这个顺序在 README 里用 [START HERE] 标了出来，但很容易被忽略。

坑点 7：把 112,801 与 60,110 的差额当成"数据被删了"或"论文虚报"。
差额精确等于 mixed 子集的 52,691，是加法不是替换。也不能反过来认为 mixed 一定是全新病例——mixed 与具名子集是否互斥未公开，Kather 组核出的 5.7% 重复说明至少存在部分重叠。

坑点 8：引用倍率/染色数字时混用两个范围。
论文的 57,647 张 20×、58,282 张 H&E 只覆盖 8 个子集；README 的 110,338 张 20×、92,536 张 H&E 覆盖 9 个。看到两个不同的 H&E 数字不等于有人写错。

坑点 9：以为有官方 train/val/test 划分。
没有。也没有病例级的官方分组标签（例如同一患者的多次取材）。做交叉验证必须自己做病例级划分，且要防泄漏——同一病例在 skin-b1 与 skin-b2 中重复出现的可能性未被作者排除。

坑点 10：直接拿自由文本字段做公开演示。
additional_info 与 grossing 是医院原始自由文本，可能含部位、日期、人名缩写等可识别信息。数据集未披露去标识流程。任何公开材料（论文插图、demo、日志）在使用前都必须做 PII 扫描。

7.1 十个坑点的自检清单

把上文的十条压成一张可打印的核对表，用于稿件投稿前或项目立项前的自查。每条给出"错误写法"与"正确写法"，对照即可判断自己是否踩坑。

编号	错误写法	正确写法	触发场景
1	“HISTAI 是 TCGA 的衍生队列”	“HISTAI 是 hist.ai 独立整合的多器官队列，与 TCGA 无数据血缘”	写相关工作、做数据集综述
2	“HISTAI 含 60,110 张切片”	“论文（2025-05）口径 60,110 张 / 26,142 例；仓库（2026-10）112,801 张 / 47,279 例”	论文摘要、方法节
3	“HISTAI 提供病理注释”	“HISTAI 提供病理报告文本元数据，不含图像级标注”	数据集简介
4	“标签取自 diagnosis 字段”	“标签取自 conclusion 字段（diagnosis 为来诊临床记录）”	方法节、标签工程说明
5	“数据集可直接下载”	“需在 HF 逐个申请，gated=manual 人工审批”	数据获取节、复现说明
6	“下载了图像就够用”	“先取 metadata 仓库，确认字段后再取图像子集”	实验记录、README
7	“共 112,801 张独立切片”	“112,801 张含 mixed 子集 52,691 张，与具名子集是否互斥未公开”	数据量陈述
8	“H&E 58,282 张”（当描述全仓库时）	“全仓库 H&E 92,536 张；论文 8 子集口径为 58,282 张”	数据描述节
9	“按官方划分训练/验证/测试”	“无官方划分，自行按 case_id 做病例级划分”	实验设置
10	论文附录直接贴报告原文	先做 PII 扫描，必要时人工脱敏后再引用	附录、demo、补充材料

这张表的价值在于它把"注意事项"变成了"可判定的错误"。审稿人看到第 1 条或第 2 条的写法，基本可以断定作者没读过 README 或没核对过论文——这两条是最常见的标识性错误。

7.2 坑点之外：三个"看似坑但不是坑"的问题

有些被广泛流传的说法，实际核对后并不成立。单独列出，是为了避免读者把注意力放在错误的地方。

其一：“HISTAI 的数据是爬取的公开论文图片。” 不成立。论文与 README 都把它描述为一个"open-source WSI dataset"，图像是全切片 TIFF（gigapixel 级金字塔文件），不是论文插图。公开论文图片不可能提供这种格式与规模。但要注意：数据来源机构确实未公开，这与"爬取"是两个不同的问题——前者是信息缺失，后者是方法不端。

其二：“论文没有实验，所以数据集没价值。” 不成立。数据集公告类论文本来就不做实验（TCGA 的原始论文也没有模型实验）。没有实验影响的是"论文的说服力"，不影响"数据是否存在"。真正的风险在别处：没有实验意味着没有任何已发表的基线，你做出的结果无处对标。这才是"没实验"的实际代价。

其三：“CC BY-NC 意味着科研免费、一切随便用。” 不成立。NC 限制的是商业用途，BY 要求署名，SA 要求衍生品同许可。三条都在约束下使用者的行为。把它理解成"免费"是常见的误读，且误读的后果通常在成果转化阶段才暴露——那时改许可往往已经太晚。

其四（常被误认为坑）：“用例数 47,279 而切片数 112,801，说明平均每例 2.39 张——比 TCGA 少。” 这不是坑，是事实差异。TCGA 的病例通常有多张切片（不同蜡块、不同染色），HISTAI 是诊断活检为主，切片数天然较少。切片数少对弱监督学习是劣势（监督信号更稀疏），对图文配对反而是优势（一例一报告，配对歧义更小）。

§8 同类数据集对照

8.1 与 TCGA 的边界（库内 rid 566）

维度	HISTAI	TCGA
发布主体	商业公司 hist.ai	美国 NCI / NHGRI 国家级项目
规模	112,801 张 / 47,279 例（仓库）	约 33,500 张 H&E / 11,000 患者 / 33 癌种
癌种/组织	9 个子集，以皮肤为主（47.4%）	33 个癌种的肿瘤样本
文本字段	病理报告全文 11 字段（含大体、镜下、鉴别）	结构化临床表（分期、生存、治疗），报告文本有限
染色	H&E 92,536 + IHC 16,920 + 其他 3,345	以 H&E 为主，IHC 稀少
许可	CC BY-NC 4.0 + gated + 商用另洽	公共领域开放（GDC 门户）
获取	HF 人工审批	GDC 直接下载
标注	无图像级标注	无图像级标注（部分子项目有）

一句话概括：TCGA 是"癌症队列 + 结构化临床表"，HISTAI 是"诊断样本 + 病理报告文本"。前者适合生存分析、分子分型，后者适合图文对齐、报告生成与跨器官泛化。两者的关系是并列的两种资源形态，不是上游与下游。

8.2 与前列腺/竞赛型数据集的关系

库内的 PANDA（rid 560）、PANDA-PLUS、SICAPv2（rid 328）、LEOPARD（rid 636）都是单器官、带任务定义的数据集：PANDA 是 Gleason 分级挑战，LEOPARD 是复发预测挑战，SICAPv2 是像素级前列腺分级。它们与 HISTAI 的差别不是规模，而是角色：

• 竞赛集：有标签、有划分、有 leaderboard，做的是"在既定任务上比高低"。
• HISTAI：无标签、无划分、无基准，做的是"给基础模型喂预训练语料"。

把 HISTAI 放进这两类之间比较"谁更好"是范畴错误。正确的比较是：HISTAI 与 TCGA、与 WSI 级预训练语料（如用 TCGA 全集做自监督的那类工作）比规模与模态；与 PANDA 系列比任务深度则毫无意义——一边是原料，一边是考卷。

8.3 与库内其他病理条目的能力矩阵

把库内主要病理条目按四种能力打点，可以看出 HISTAI 占的是哪个格子。表中"●“表示强、”○"表示有但弱、"空"表示无。

条目	规模（WSI 量级）	多器官	图像级标注	报告/临床文本
HISTAI	●（11 万）	●（9 子集）	空	●（11 字段）
TCGA（rid 566）	●（3.3 万）	●（33 癌种）	空	○（结构化临床表）
PANDA（rid 560）	○（1 万级）	空	空（切片级标签）	空
PANDA-PLUS	○（546）	空	●（像素级）	空
SICAPv2（rid 328）	空（patch 级）	空	●（像素级）	空
LEOPARD（rid 636）	○	空	空	空
Lizard（rid 238）	○	空	●（核实例）	空
NuCLS（rid 248）	○	空	●（核分类）	空
TIGER（rid 26）	○	空	●（TIL 区域）	空

矩阵揭示的两个事实：

第一，"多器官 + 临床文本"这个格子只有 HISTAI 与 TCGA 占着，而 TCGA 的文本是结构化临床表（分期、生存、治疗），不含病理报告的镜下描述与大体所见。HISTAI 在这一格上确实稀缺。

第二，"多器官 + 图像级标注"这个格子是空的。想要跨器官的像素级标注，目前只能拼接多个单器官数据集（如 PANDA-PLUS + Lizard + NuCLS），这正是 SPIDER 想做的事，也是 HISTAI 不适合做分割的直接原因。

8.4 论文 Related Work 自述的定位

论文在 Related Work 里对既有数据集给了一个总体判断，值得原样保留：

“Many organs and cancer types are underrepresented, IHC and other non-H&E stains are rarely available at scale, and few datasets provide multimodal annotations suited for generalization studies.”

这三点正是 HISTAI 自我宣称的三项改进：器官覆盖更广、IHC 成规模、多模态注释（即临床文本）。第一点在数据上站得住（9 个组织子集），第二点成立（16,920 张 IHC），第三点则有争议——临床文本确实是多模态，但它不是"注释"，而是原始记录；把两者混为一谈，正是坑点 3 与坑点 4 的根源。

8.5 选用决策树

你的任务需要像素级/区域级标注？
├─ 是 → 不要用 HISTAI，去 SPIDER / SICAPv2 / PANDA-PLUS / Lizard / NuCLS
└─ 否 → 继续
   你的任务需要图文配对（报告生成/检索/CLIP）？
   ├─ 是 → HISTAI 是少数十万级选项；但先确认能过 gated 审批
   └─ 否 → 继续
      你的任务需要在既定任务上对比 SOTA？
      ├─ 是 → 去有 leaderboard 的竞赛集（PANDA/LEOPARD/MIDOG）
      └─ 否 → 你的任务是预训练或跨器官泛化 → HISTAI 合适
              但需自行做划分、标签重建与 PII 扫描

8.6 与纯文本病理报告数据集的关系

还有一类资源值得说清：从病理报告抽取的纯文本数据集（用于命名实体识别、信息抽取、报告结构化）。HISTAI 与它们的关系是"原料与半成品"：

类型	代表	输出	与 HISTAI 的关系
原始报告 + 图像	HISTAI	图像 + 未结构化文本	上游原料
标注文本	各类病理 NER 语料	实体与关系标注	可用 HISTAI 文本抽取，但需自行标注
结构化标签	ICD-10 映射表	病例 → 编码	HISTAI 自带 icd10，无需二次映射

这条谱系解释了一个常见困惑：为什么 HISTAI 的文本"看起来质量一般"却仍被使用。因为它提供的是真实工作流中的文本，包括错别字、缩写、上下位混用——这类噪声在人工构造的标注语料里是没有的。若研究目标是"报告结构化模型的鲁棒性"，这种噪声反而是必需的真实性。

反过来，若研究目标是"高质量标签下的分类精度"，HISTAI 的噪声就是纯负担。同一份数据在两类研究中的价值判断完全相反，这是选型时最需要先想清楚的问题。

§9 DAIMS 就绪度评估

DAIMS（Data and AI Maturity/Readiness framework，数据与 AI 就绪度框架）从六个维度评估一个数据集"能不能直接喂进 AI 流水线"。HISTAI 的评分呈明显的不均衡：在规模与模态上强，在标注与可及性上弱。

维度	评分	评分理由
D1 规模与代表性	3.5 / 5	11 万张切片在公开病理集中属第一梯队；但组织构成严重偏斜（皮肤 47.4%），胸科/胃肠/血液各不足 1%，代表性打折
D2 标注质量与粒度	1.5 / 5	无图像级标注；临床文本字段存在 27.1% 内部冲突、30.3% 结论模糊、8 例诊断错误，需病理医生重建标签
D3 元数据完整度	2.5 / 5	字段设计丰富（11 字段含大体、镜下、鉴别），但人口学仅 55% 可得、专科仅 39.6% 标注、肺癌结直肠癌分子信息仅 18.9%
D4 可及性与许可	2.0 / 5	CC BY-NC 4.0 研究用；全部仓库 gated=manual 人工审批且保留拒绝权；商用需另签；无第三方镜像
D5 技术规范性	3.5 / 5	标准 TIFF 金字塔格式、规范的文件树与命名约定、独立子集便于按需下载；但空间分辨率未公开、单张扫描仪型号不可确定、无校验清单文件
D6 治理与溯源	1.0 / 5	论文无 Ethics 章节、无 IRB 编号、无采集机构、无去标识方法说明；第三方审计明确点出溯源与伦理监督"记录有限"
加权总分	2.33 / 5	若任务为图文预训练，D1/D3 权重上浮，可到约 2.9；若任务为监督分类，D2 权重上浮，降到约 1.9

评分口径说明：本表为本条目的编辑判断，非官方评分。评分锚点为：5 = 业界最佳实践（如 TCGA 的开放获取、PANDA-PLUS 的详细标注文档），3 = 可用但需额外工序，1 = 存在阻断性问题。

三个评分背后的关键事实：

1. D2 的 1.5 分不是因为"没有标注"那么简单，而是因为已有的文本标注本身不可靠。一个完全没有标注的数据集至少是诚实的（当预训练语料用），而一个有 27.1% 内部冲突的标注体系，会诱导使用者做出错误的监督假设。
2. D4 的 2.0 分要拆开看：许可本身是标准的 CC 协议（不难读），但 gated=manual 让它无法进入自动化流水线。任何依赖"定时重新拉取最新数据"的 MLOps 流程都必须人工介入。
3. D6 的 1.0 分是本表最低项，也是最能区分"可发布"与"可合规使用"的一项。对涉及患者数据的研究，这一项通常由所在机构 IRB 独立审查，HISTAI 不提供任何支持材料。

AI-Ready 光谱定位：HISTAI 属于"规模已就绪、标注未就绪、治理待补齐"的类型。它不是那种 load_dataset 之后就能 model.fit() 的数据集，而是那种"拿到之后要先做一个月数据工程"的数据集。这不必然是缺点——大规模原始语料的价值恰恰在于它的原始性——但使用者必须清醒地知道自己买的是原料而非半成品。

9.1 六维评分的详细依据

9.1.1 D1 规模与代表性（3.5 / 5）

规模这一项几乎没有争议：112,801 张切片在公开病理 WSI 中属于第一梯队。可比的参照是 TCGA 约 33,500 张 H&E 诊断切片——HISTAI 大约是它的 3.4 倍。即便只看论文口径的 60,110 张，也接近两倍。

扣分的全部原因在"代表性"。三点与真实临床的偏离需要在使用时明确声明：皮肤占病例 47.4%、胸科/胃肠/血液各不足 1.5%；specialization 字段仅 39.6% 标注，导致偏斜在元数据层面被掩盖；mixed 子集占 44.7% 病例，但其组织构成未公开，实际上是"未知科室"的一大块。

如果把 mixed 按未知处理，8 个具名子集的代表性就完全由皮肤决定——这不是"多器官数据集"，而是"带若干小组织子集的皮肤病数据集"。这个判断不是贬损，而是选型时的关键约束：想在 HISTAI 上做跨器官泛化的结论，须限定在至少 500 例以上的子集之间比较，否则差异主要来自样本量。

9.1.2 D2 标注质量与粒度（1.5 / 5）

这一项的分数最低，理由也最具体：

证据	数值	后果
conclusion 与 diagnosis 冲突	27.1%	两个"诊断"字段不能互相替代
conclusion 与 diagnosis 一致	20.7%	过半病例两者既不一致也不明确冲突（多为上下位关系或部分重叠）
198 例细读中结论模糊	30.3%	约三分之一病例的结论不足以直接作为标签
其中诊断错误	8 例（占 198 的 4.0%）	存在事实性错误，非仅表述问题
成人弥漫性胶质瘤符合 WHO CNS5	0 / 55	该病种的标注完全不可用于现代分型任务

"诊断错误 8 例"这个数字要谨慎解读：它来自 198 例的细读子样本，不能直接外推到 47,279 例。但它足以说明错误率不是零，且不是罕见的个案。

对分数的一个可能反驳是："它本来就不是标注数据集，不该按标注标准打分。"这个反驳部分成立——所以本表的 D2 权重在本文的加权总分中并未上调。但保留这一维度是必要的，因为论文摘要用了 “detailed pathological annotations” 这一措辞，客观上会造成预期错位。

9.1.3 D3 元数据完整度（2.5 / 5）

字段设计本身是加分的：11 个字段覆盖了从临床申请（diagnosis）、镜下观察（micro_protocol）、大体检查（grossing）到最终结论（conclusion）的完整链路，这在公开病理数据集中少见。多数公开集的临床字段是结构化表格（分期、分级、生存），不含描述性文本。

扣分在填充率：人口学 55%、专科 39.6%、肺癌与结直肠癌分子信息 18.9%。三项都是建模常用字段，缺失都不随机（与科室、标本类型、年代相关），意味着不能简单按完整案例删除（listwise deletion）——那样会系统性地丢掉某些科室的样本。

一个实操上的建议是：把"字段是否非空"本身当作一个特征或分层变量。例如 age 缺失的病例可能集中在某类小标本，这时年龄缺失本身携带了标本类型信息。

9.1.4 D4 可及性与许可（2.0 / 5）

许可条款本身是标准的（CC BY-NC 4.0），照章执行即可。真正扣分的是获取机制：

• 10/10 仓库 gated=manual，无免审入口；
• 数据集卡明示保留拒绝权，且附带"支持仓库"的要求；
• 无第三方镜像、无 API 直连、无版本固定的 URL（如 Zenodo DOI 那种永久标识）。

最后一点常被忽略但影响很大：CC 协议本身不要求提供稳定标识，但科研复现通常需要引用一个"不会变"的地址。HISTAI 的地址会变（仓库内容在更新），所以复现性依赖于使用者自己记录快照信息（见 §6.5）。

9.1.5 D5 技术规范性（3.5 / 5）

加分项：标准 TIFF 金字塔、清晰的文件树与命名约定（case_<id>/slide_<stain>_<n>.tiff）、子集独立便于按需获取、元数据与图像通过 case_mapping 显式关联。

扣分项：空间分辨率（μm/px）未公开——这直接影响物理尺寸相关的定量分析（如细胞密度/mm²）；单张扫描仪型号不可确定——影响扫描仪偏差分析；无校验清单文件（manifest）——无法在不下载全量的情况下核对完整性。

"空间分辨率未公开"这一条在实践中比看起来严重：多数病理管线在做 patch 抽取时需要知道 μm/px 才能对齐不同来源的倍率。HISTAI 只能靠"20×/40×"这个相对倍率做近似，跨扫描仪的一致性无法保证。

9.1.6 D6 治理与溯源（1.0 / 5）

最低项。缺的不是某一份文档，而是整条治理链：谁采集、在哪个机构、经哪个伦理委员会批准、如何取得知情同意、如何去标识、数据主体能否撤回——六问全部未答。

第三方审计用的措辞是 “limited documentation of dataset provenance and ethical oversight”，这是学术评论中相当克制的说法。对使用者而言，这意味着合规责任整体转移到了使用方：你所在的机构需要独立判断这份数据能否用于你的研究，HISTAI 不提供任何支撑材料。

9.2 与同类数据集的就绪度对比

维度	HISTAI	TCGA	PANDA-PLUS	CAMELYON16
规模	112,801	~33,500	546	400
标注深度	无图像标注	无图像标注	像素级	像素级
文本丰富度	高（报告全文）	中（结构化表）	无	无
获取难度	高（人工审批）	低（开放）	中（掩码需申请）	低（开放）
许可自由度	低（NC）	高（公共领域）	中（分层）	中
治理记录	低	高	中	中
综合就绪度	2.33	约 3.6	约 3.2	约 3.4

（TCGA、PANDA-PLUS、CAMELYON16 的分数为本条目按同一口径给出的参照值，未经独立评审，仅供定位使用。）

这张表想传达的判断很简单：HISTAI 的强项是"规模 + 文本"，弱项是"标注 + 治理 + 可及性"。它不是一份"更差的 TCGA"，而是一份不同类型的资源——TCGA 回答"这些肿瘤的分子与临床结局如何"，HISTAI 回答"病理医生在真实工作中怎么写报告、看什么图"。

§10 使用路线图与互链

10.1 从零到可训练的四阶段

阶段一：审批与清点（1-3 周，取决于审批速度）
申请 metadata + 目标子集 → 等待审批 → 下载 → 按文件数核对完整性 → 建立本地病例索引（case_id → 切片列表 → 元数据记录）。

验收标准：三个数字对得上——仓库声明的 TIFF 数、本地实际 TIFF 数、元数据记录的病例数。

阶段二：元数据体检（约 1 周）
做 §4.4 提的三张表：字段非空率、conclusion/diagnosis 一致率、specialization 与子集目录的交叉表。这一步的产出决定后续任务形态——如果 icd10 填写率低于 60%，ICD-10 分类路线基本不可行。

验收标准：能明确回答"我的目标子集里，可用标签覆盖多少病例"。

阶段三：标签重建（2-4 周，含病理医生工时）
从 conclusion 抽取疾病实体 → 同义词归一 → 映射到 ICD-10 或自定义类别体系 → 病理医生抽样复核（建议按 5-10% 抽样，冲突率超过阈值就扩大抽样）→ 形成标签表。

验收标准：抽样一致率达到可接受水平（建议 Cohen’s κ ≥ 0.8），且冲突病例有处置记录。

阶段四：划分与训练
病例级划分（同一 case_id 不跨集）→ 若使用 mixed，先做与具名子集的去重 → 切片级 → 病例级聚合（可选）→ 训练。

验收标准：验证集与测试集的器官分布、标签分布与整体分布的可比性已检查并记录。

10.2 五个"不要"

1. 不要在未做去标识扫描的情况下把 additional_info / grossing 的原文贴进论文附录。
2. 不要用 diagnosis 训练分类器然后声称"分类了病理诊断"。
3. 不要把 mixed 与具名子集直接拼接当作 11 万张独立样本。
4. 不要在引用里写"HISTAI 提供 60,110 张切片"却不注明年份——2026 年之后这句话就过时了。
5. 不要把 CC BY-NC 理解为"非商业研究随便用"——再分发、衍生数据集的许可、模型商用都仍需单独判断。

10.3 建议互链点（库内条目）

条目	rid	与 HISTAI 的关系	互链理由
TCGA 癌症基因组图谱	566	独立队列，非子集，无数据血缘	同为大规模多癌种 WSI 语料，最常被拿来比较；本条目的坑点 1 专门处理这组混淆
TCGA 癌症基因组图谱 AI-Ready 数据集	25	独立队列，非子集（与 rid 566 为同一主题的另一版本条目）	同上
PANDA	560	同为 WSI 级数据，但带任务定义	"预训练语料 vs 任务数据集"的对照样本
PANDA-PLUS	—	像素级重标注升级版	反向案例：HISTAI 无图像标注，PANDA-PLUS 以像素标注为核心卖点
SICAPv2	328	单器官像素级分级	说明"任务深度"与"数据规模"的取舍
LEOPARD	636	前列腺复发预测挑战	有 leaderboard 的竞赛集代表
Lizard	238	结直肠核实例分割	HISTAI 有结直肠子集但无核标注，可作"同器官不同标注深度"的对照
NuCLS	248	乳腺核分类	同上，对应 HISTAI-breast
TIGER	26	乳腺癌 TIL 挑战	乳腺子集的标注型对照
RCC-AID	964	TCGA 衍生的肾癌 CT 分割	提醒"TCGA 衍生"这一类别与 HISTAI 无关

互链写作建议：与 TCGA（566）的互链必须写明"独立队列，非子集"，否则会把坑点 1 的误解扩散到两个条目；与 PANDA-PLUS 的互链则应强调"标注深度谱系的两端"。

10.4 外部生态锚点

资源	地址	用途
GitHub 主仓库	github.com/HistAI/HISTAI	README、许可声明、子集链接（唯一免审批的信息源）
论文	arXiv:2505.12120	规模表、元数据字段、Related Work
元数据仓库	huggingface.co/datasets/histai/HISTAI-metadata	字段实例（需审批）
图像子集	huggingface.co/datasets/histai/HISTAI-	9 个组织子集，各自审批
第三方审计	doi:10.1002/2056-4538.70089	标签质量与元数据完整度的唯一独立评估
姊妹数据集	github.com/HistAI/SPIDER（arXiv:2503.02876）	带 patch 级标注的多器官监督集
姊妹模型	github.com/HistAI/hibou（arXiv:2406.05074）	病理基础视觉模型

10.5 检索关键词建议

目标	推荐查询式	预期命中
论文本体	“HISTAI” AND “whole slide” AND (“hist.ai” OR Nechaev)	arXiv:2505.12120
数据质量评论	HISTAI AND (label accuracy OR metadata completeness OR Kather)	J Pathol Clin Res 12(3):e70089
实际使用它的论文	“HISTAI” AND (pretraining OR “vision-language” OR foundation)	引用该数据集的第三方工作
规模核对	site:huggingface.co histai	10 个仓库
反例（勿用）	“HISTAI-TCGA”（作为数据集名）	无命中——二者无血缘（坑点 1）

检索卫生：一、HISTAI 的规模数字在 2025 年 6 月之后应以 README 为准，论文为准的写法必须带日期；二、凡看到"60,110"与"112,801"并列的二手材料，先确认它是否解释了 mixed 子集，没解释的说明作者没读 README；三、Kather 组的评论标题里带 “valuable lesson”，用这个短语搜比用作者名更快命中。

10.6 六个常见实施陷阱

在把 HISTAI 接进实际项目时，容易在流程层面踩的六个坑，与前文 §7 的内容层坑点互补。

陷阱一：把审批当成一次性动作。 每个仓库单独审批，且授权不跨仓库。团队里有人批了 skin-b2，不代表你也能用 mixed。建议由一个人统一管理申请记录，避免"以为团队里有人批过"的误判。

陷阱二：用 load_dataset 直接加载。 HISTAI 的仓库结构是"一个目录一棵树 + 一堆 TIFF"，不是 Parquet/Arrow 格式，load_dataset 无法直接构造 DataLoader。正确做法是 snapshot_download 落盘，再用 OpenSlide 按需读取。

陷阱三：在切片级随机划分。 同一病例有多张切片（平均 2.39 张），切片级随机划分会让同一病例同时出现在训练集与测试集，指标虚高。必须按 case_id 划分。

陷阱四：忽略 b1/b2 的批次效应。 皮肤与结直肠都有两个批次。如果训练用 b1、测试用 b2，性能下降可能来自扫描批次或来源差异，而非泛化能力不足。做跨批次实验时要把这个因素显式建模，而不是当噪声。

陷阱五：把 specialization 当可靠的器官标签。 只有 39.6% 填写。用它做分层抽样时，剩余 60.4% 会被无差别归入"缺失"层，导致抽样比例失控。更可靠的分层变量是仓库目录名。

陷阱六：忘记检查 TIFF 金字塔层级。 来源扫描仪不统一（Aperio GT450/AT2、Hamamatsu、3DHISTECH），部分切片可能只有单层。若管线假定存在多个降采样层级，会在这批切片上出错。建议在数据加载器里做一次 level_count 分布统计，把异常切片单独标记。

这六个陷阱的共同点是：它们都不涉及"数据对不对"，只涉及"流程顺不顺"。踩中的代价通常不是结论错误，而是白跑几周。提前知道，就能省下这几周。

10.7 一个最小可行方案（MVP）

如果要在两周内做出一个能跑通端到端的结果，建议按下面的最小配置做，不要一上来就碰全量数据。

项目	选择	理由
子集	HISTAI-breast（1,925 张 / 1,692 例）	病例数够做划分，体积适中，病变类型集中
任务	ICD-10 多标签分类（icd10 → 图像）	标签标准化，无需重建自由文本
切片处理	20× 下抽 5-10 个 224×224 patch，均值池化	避免弱监督复杂化
划分	病例级 8:1:1	防泄漏
指标	宏平均 AUROC + 每类样本数	类别不均衡必须看宏平均
复核	随机 100 例人工核对 icd10 与 conclusion 一致性	预估标签噪声上限

这个方案的产出不是"好结果"，而是"知道这份数据到底有多难用"。跑完之后你会得到三个数字——icd10 填写率、icd10 与 conclusion 的一致率、宏平均 AUROC——这三个数字决定了是否值得投入全量数据。

不要做的三件事：不要先拉 skin-b2（43,757 张，磁盘与时间都撑不住）；不要先做报告生成（需要先解决文本质量，周期至少翻倍）；不要先申请全部 9 个子集（审批周期不可控，且多数子集用不上）。

---

10.8 两周执行甘特（可打印）

下表把 10.7 的 MVP 拆到天，用于向导师或主管汇报排期。假设审批在第一天提交、两周内通过。

天	动作	产出	风险点
D1	提交 metadata + breast 两个仓库申请	申请记录	审批可能超期，需备选子集
D2-D3	准备读取管线：OpenSlide、patch 抽取、特征缓存	可跑的脚本骨架	依赖环境可能需要 GPU 驱动
D4	审批通过后下载 metadata，跑三张体检表	字段非空率、一致率、交叉表	icd10 填写率可能低于 60%
D5-D6	下载 breast 子集并核对 1,925 个 TIFF	本地副本 + 指纹	带宽与磁盘
D7	病例级划分 + 标签表生成	train/val/test 划分与 case_label 表	多标签拆分的边界情况
D8-D10	基线与两个变体训练	三组指标	类别不均衡导致少类指标抖动
D11	人工复核 100 例	标签噪声上限估计	需要病理医生工时
D12-D13	汇总与决定下一步	一页结论 + 是否投入全量	结论可能是否定的

关于"结论可能是否定"：这不是悲观，而是这类数据集的正常结果。很多团队在两周后得出的结论是"标签噪声高于预期，需要先做标注治理"——这本身就是一个有价值的结论，比强行训出一个数字好看但不可解释的模型要好。

10.9 库内互链的写作规范

本条目与库内其他条目的互链需要在正文里落成可读的句子，而不是只放一串 rid。三条写法建议：

写法一（对照型）：先给共同点，再给差异点。“与 TCGA（rid 566）同属十万级以下的病理 WSI 语料，但 HISTAI 是独立采集队列而非其子集，文本字段也更接近真实病理报告。”

写法二（谱系型）：说明在标注深度谱系中的位置。“若把病理数据集按标注深度排序，PANDA-PLUS 处于像素级一端，HISTAI 处于零图像标注的另一端，二者之间的中点是 PANDA 的切片级标签。”

写法三（选型型）：直接给出替代关系。“需要像素级前列腺分级标注时应选 SICAPv2（rid 328）而非 HISTAI；需要前列腺切片级分级挑战与 leaderboard 时应选 PANDA（rid 560）。”

避免的写法：只写"参见 XXX（rid N）"而不说明关系。读者点过去之后仍然不知道两个数据集是什么关系，互链就失去了意义。

10.10 本条目未覆盖的内容

为免读者误以为本条目已穷尽，明确列出未覆盖的部分：

• SPIDER 与 Hibou 的细节：只提及名称与 arXiv 编号，未核实其规模、标注体系与许可。
• 实际使用 HISTAI 的第三方论文：未做引用追踪，因此无法给出"用 HISTAI 训练的模型达到了什么性能"的参照。
• TIFF 文件内部结构：未获取任何一张实际切片，金字塔层级、压缩方式、色彩空间均未验证。
• 元数据实际内容：受 gated 限制，未读取任何一条真实记录，字段说明全部来自 README 与论文。
• 不同子集之间的病例重叠：受 gated 限制，无法做跨子集 ID 比对。

这五项中的任一项，都需要先通过审批拿到数据才能推进。本条目在现有公开材料范围内已做到三源互证；其余部分如实留白，不以推测填充。

尾注

本条目为 AI-Ready Wikipedia 数据集条目，成稿于 2026-10-17。事实来源限于三类一手材料：arXiv:2505.12120v1（论文口径的全部规模、字段与用途表述）、GitHub HistAI/HISTAI README（许可、仓库结构与 README 口径规模）、HuggingFace histai 组织 10 个仓库的 API 元数据（gated 状态、文件树计数、下载量与更新时间，经 hf-mirror.com 镜像读取）。标签质量问题全部引自 Hewitt 等在 The Journal of Pathology: Clinical Research 2026;12(3):e70089 的公开摘要与书目记录。

文中所有"未公开"标注均为核验后确认无公开来源的字段，未作推测填充：单张切片的空间分辨率、采集机构与国家、IRB 编号、去标识方法、mixed 子集与具名子集的重叠关系、H&E–IHC 配对率，均属此类。规模数字的双口径（60,110/26,142 与 112,801/47,279）已在 §2.2 给出完整差额推导，并确认差额精确等于 mixed 子集。

条目与库内 TCGA（rid 566）、PANDA（rid 560）、LEOPARD（rid 636）、SICAPv2（rid 328）、Lizard（rid 238）、NuCLS（rid 248）、TIGER（rid 26）等条目互链，构成"预训练语料—任务数据集—标注深化版"三层的完整检索面。与 TCGA 的互链特别标注"独立队列、非子集"，以防止来源混淆在条目网络中被放大。

后续维护触发点：一、arXiv 若出现 v2 并更新规模表，§2.2 双口径需重新对齐；二、hist.ai 若调整许可或取消 gated，§6 三层许可表需修订；三、若出现 HISTAI 上的官方 benchmark 或 leaderboard，§5.4 的"预训练语料定位"判断需复核；四、Kather 组若发布后续审计（针对 mixed 子集或更深抽样），§3.3 的发现表应扩充。

---

附录 A：核验时点与来源清单

本条目全部事实均在 2026-10-17 当日抓取并核对。下表列出一手来源与用途，便于复核。

编号	来源	类型	用于核实	抓取状态
S1	arxiv.org/abs/2505.12120	论文摘要页	题名、三作者、v1 提交时间 2025-05-17 18:59:32 UTC、doi:10.48550/arXiv.2505.12120、GitHub 地址	正常
S2	arxiv.org/html/2505.12120v1	论文全文	表 1 八个子集规模、倍率 57,647/2,463、染色 58,282/1,828、元数据 8 大类、扫描仪型号不可确定、无 Ethics 章节	正常
S3	github.com/HistAI/HISTAI	仓库 README	112,801/47,279/9 子集、CC BY-NC 4.0、商用邮箱、11 字段表、下载命令、文件命名约定、姊妹项目	正常
S4	hf-mirror.com/api/datasets/histai/*	HuggingFace API（镜像）	10 个仓库的 gated 状态、license 标签、createdAt/lastModified、downloads/likes、usedStorage、文件树计数	正常
S5	cris.fau.de/publications/362340774	机构库书目	Kather 组 Letter 的全部数字（44,564 例、55%、20.7%、27.1%、30.3%、8 例、18.9%、55 例胶质瘤、39.6%）	正常
S6	fis.tu-dresden.de 门户	机构库书目	发表状态（同行评议、2026-04-15 在线）、卷期 12(3)、e70089、6 位作者与机构	正常

未能直读的来源：histai/HISTAI-metadata 的 raw README 返回 “Access to dataset histai/HISTAI-metadata is restricted”，因此字段说明一律引自 S3（GitHub README 与论文一致），而非 HF 数据集卡。这一限制本身也是结论的一部分——见坑点 6。

三源互证矩阵（核心数字）：

数字	S2 论文	S3 GitHub	S4 HF 实测	结论
skin-b2 切片数	43,757	43,757	43,757	三源一致
skin-b1 切片数	7,710	7,710	7,710	三源一致
colorectal-b1	5,379	5,379	5,379	三源一致
breast	1,925	1,925	1,925	三源一致
thorax	829	829	829	三源一致
hematologic	214	214	214	三源一致
gastrointestinal	202	202	202	三源一致
colorectal-b2	94	94	94	三源一致
8 子集合计	60,110	60,110	60,110	三源一致
mixed	未收录	52,691	52,691	两源一致（论文缺）
总计	60,110	112,801	112,801	双口径
40× 切片	2,463	2,463	—	两源一致

附录 B：元数据字段速查

字段名	中文	类型	缺失情况	建模可用性
diagnosis	来诊临床记录	自由文本	未公布	低（非金标准，见坑点 4）
conclusion	病理结论	自由文本	未公布	高（金标准来源）
diff_diagnosis	鉴别诊断	自由文本	README 标 “if available”，缺失率高	低
micro_protocol	镜下描述	自由文本	未公布	高（图文对齐的正文）
additional_info	补充说明	自由文本	未公布	低（含 PII 风险）
age	年龄	数值	与 gender 合计仅 55% 可得	中
gender	性别	字符（f/m）	同上	中
icd10	ICD-10 编码	编码字符串	未公布	高（标准化标签）
specialization	专科/器官系统	短文本	仅 39.6% 填写	中（分层抽样用）
case_mapping	切片引用路径	路径字符串	未公布	结构性字段（关联图像）
grossing	大体描述	自由文本	与标本类型相关（非随机缺失）	低（含 PII 风险）

字段读取的三条实务规则：

1. 任何字段的缺失率都应当先自查再建模。上表"未公布"的格子不是作者没填，而是论文与 README 都没给统计。
2. age、gender 缺失极可能成对出现（同一张申请单同时填或同时空），插补时应联合处理，不要各自插补。
3. case_mapping 是唯一能把 JSON 记录与 TIFF 文件对上的字段。如果它缺失，该病例的元数据实际上无法与图像关联——这是拿到数据后第一个要检查的完整性指标。

附录 C：子集速查卡

子集	中文	规模量级	研究价值	使用注意
skin-b2	皮肤（第二批）	43,757 张 / 20,621 例	皮肤病分类、痣与黑色素瘤鉴别	体量最大，downloads 最高；类别极不均衡
skin-b1	皮肤（第一批）	7,710 张 / 1,778 例	与 b2 互补，可做批次效应研究	与 b2 是否同源未公开
colorectal-b1	结直肠（第一批）	5,379 张 / 998 例	结直肠癌分型、腺癌 vs 腺瘤	与 Lizard 同器官可对照（但无核标注）
breast	乳腺	1,925 张 / 1,692 例	乳腺病变分类，病例数第二多	平均 1.14 张/例，几乎一例一片
thorax	胸部/肺	829 张 / 657 例	肺癌分型，可测分子标注缺失问题	分子信息仅 18.9%
hematologic	血液/淋巴结	214 张 / 214 例	淋巴瘤亚型分类（小样本）	一例一片，无同病例多切片
gastrointestinal	胃肠	202 张 / 120 例	胃/食管病变	规模最小之一，统计功效低
colorectal-b2	结直肠（第二批）	94 张 / 62 例	补充批次	规模过小，仅适合并入 b1
mixed	混合	52,691 张 / 21,137 例	未分类病例的补充集	与具名子集是否互斥未公开

批次命名之谜：b1/b2 的"b"含义在论文与 README 中均未解释。可观察的线索是：skin-b1 与 skin-b2 规模相差 5.7 倍，colorectal-b1 与 b2 相差 57 倍，说明"b"不是均分批次（如"第二次发布"），更像是不同来源批次的标记。使用建议：把 b1/b2 当成独立域而非同分布的重复抽样——这反而让它们成为研究批次效应的现成素材。

附录 D：常用操作代码

D.1 核对文件数（下载后第一步）

import os

def count_tiffs(root):
    n = 0
    for dirpath, _, files in os.walk(root):
        n += sum(1 for f in files if f.lower().endswith(('.tiff', '.tif')))
    return n

# 期望值见附录 C；skin-b2 应为 43757
print(count_tiffs("/local_path/HISTAI-skin-b2"))

D.2 建立病例索引

import json, os

def build_index(meta_json_path):
    """把 metadata JSON 转成 case_id -> 记录 的字典"""
    with open(meta_json_path, encoding="utf-8") as f:
        records = json.load(f)
    index = {}
    for r in records:
        cid = r.get("case_mapping", "").split("/")[-1]  # 形如 case_13384
        index[cid] = r
    return index

D.3 标签一致性体检

def label_audit(records):
    """统计 conclusion / diagnosis 的一致、冲突、缺失三分"""
    same = diff = miss = 0
    for r in records:
        c, d = r.get("conclusion"), r.get("diagnosis")
        if not c or not d:
            miss += 1
        elif c.strip().lower() == d.strip().lower():
            same += 1
        else:
            diff += 1
    total = len(records)
    return {"total": total, "same": same, "diff": diff, "missing": miss,
            "same_rate": round(same / total, 4), "diff_rate": round(diff / total, 4)}

注意 D.3 只做字面比较，因此得到的"一致率"会低于 Kather 组报告的 20.7%（他们做了语义判断）。字面比较的用途是快速摸底，不是复现审计结论。

D.4 病例级划分（防泄漏）

import random

def case_level_split(case_ids, ratios=(0.8, 0.1, 0.1), seed=42):
    ids = sorted(case_ids)
    random.Random(seed).shuffle(ids)
    n = len(ids)
    a, b = int(n * ratios[0]), int(n * (ratios[0] + ratios[1]))
    return ids[:a], ids[a:b], ids[b:]

关键约束：划分单位必须是 case_id，不是切片。同一病例的多张切片（breast 平均 1.14 张，skin-b2 平均 2.12 张）必须落在同一侧，否则验证分数会虚高。

附录 E：数字化规格与工程约束

项目	数值/说明	影响
单张 WSI 典型体积	未公开（需授权后枚举 LFS 大小）	无法预估存储与带宽；按常见 20× 全切片经验值，单张通常数百 MB 至 1 GB+
全量下载量级	未公开	若按 112,801 张估算，TB 至数十 TB 量级；建议按子集分批
metadata 仓库体积	62,510,560 B（≈59.6 MiB）	可先下载，几乎无成本
文件格式	TIFF（金字塔）	需 OpenSlide / tiffslide / cuCIM 读取
金字塔层级	未公开	影响 patch 抽取的缩放倍率选择
色彩空间	未公开（推测为 RGB，但无文档确认）	影响染色归一化流程
压缩方式	未公开	影响读取速度
空间分辨率（μm/px）	未公开	无法做物理尺寸相关的定量分析
切片间分辨率一致性	未公开	不同扫描仪（Aperio/Hamamatsu/3DHISTECH）可能不一致

工程建议：由于体积信息全未公开，第一次下载应只取最小子集（colorectal-b2，94 张或 hematologic 214 张）做管线试跑，确认读取、切 patch、存储的可行后再拉大子集。直接拉 skin-b2 的 43,757 张很可能在磁盘上撞墙。

读取示例：

import openslide

slide = openslide.OpenSlide("case_00000/slide_H&E_0.tiff")
print(slide.level_count, slide.level_dimensions)  # 确认金字塔层数
patch = slide.read_region((0, 0), 0, (224, 224)).convert("RGB")

如果 level_count 为 1，说明该切片是单层 TIFF，需在本地自建金字塔——这在混合扫描仪来源的数据集中并不罕见。

附录 F：与 SPIDER / Hibou 的关系

hist.ai 的三条产品线在数据形态上互补，用途上分工明确：

项目	内容	规模	标注	典型用途
HISTAI	多器官 WSI + 临床文本	11 万张 WSI	无图像级标注	自监督预训练、图文对齐
SPIDER	多器官 patch 集	未在本条目核实	patch 级多任务标注	监督训练、分割/分类基准
Hibou	视觉基础模型	—	—	特征提取、下游微调

使用顺序建议：Hibou 做特征提取 → HISTAI 做域适应/图文预训练 → SPIDER 做监督微调与评测。这条链路是作者设计产品时的隐含路径，也让"为什么 HISTAI 没有标注"变得容易理解——标注的活交给了 SPIDER。

注意：本条目只对 HISTAI 做了完整核验。SPIDER 与 Hibou 的规模、许可、标注体系均未在本条目中核实，引用时需另行查证（SPIDER 对应 arXiv:2503.02876，Hibou 对应 arXiv:2406.05074）。

附录 G：估算推导过程

本条目出现的所有派生数字，推导过程如下，便于复核。

G.1 规模差额

112,801（仓库总切片） - 60,110（论文 8 子集） = 52,691
 52,691 与 HISTAI-mixed 的 TIFF 实测数 52,691 完全相等
47,279（仓库总病例） - 26,142（论文 8 子集） = 21,137
 21,137 与 README 所列 mixed 病例数 21,137 完全相等

两个差额同时精确相等，是"mixed = 增量"这一判断的最强证据。

G.2 病例占比

皮肤病例 = 20,621（b2） + 1,778（b1） = 22,399
皮肤占比 = 22,399 / 47,279 = 47.37% ≈ 47.4%
（Kather 组独立报告 47.1%，差异源于其核账后的 44,564 例分母与去重口径）

G.3 其余占比（分母 47,279）

结直肠 = 998 + 62 = 1,060 → 2.24%
乳腺   = 1,692        → 3.58%
胸科   = 657          → 1.39%
胃肠   = 120          → 0.25%
血液   = 214          → 0.45%
mixed  = 21,137       → 44.71%
以上合计 47,279（100%）

G.4 平均切片数

论文口径：60,110 / 26,142 = 2.299 ≈ 2.30 张/例
仓库口径：112,801 / 47,279 = 2.386 ≈ 2.39 张/例
breast  ：1,925 / 1,692  = 1.138 ≈ 1.14 张/例
skin-b2 ：43,757 / 20,621 = 2.122 ≈ 2.12 张/例

G.5 HF 文件树计数口径

HF API 返回的 siblings 数组包含仓库内全部文件（含 .gitattributes 与 README.md）。因此"TIFF 数 = siblings 长度 − 2"。以 skin-b2 为例：43,759 − 2 = 43,757，与论文一致。8 个子集逐一验证通过（见附录 A 矩阵），说明该换算口径可靠。

附录 H：术语对照

英文	中文	说明
WSI (whole slide image)	全切片图像	整张玻片的高分辨率数字化图像，通常为金字塔 TIFF
gated dataset	受限访问数据集	需申请/同意条款后方可下载
gated=manual	人工审批门控	有审核人逐份审批，非自动通过
patch	图块	从 WSI 裁出的小块图像，常用于训练
stain / staining	染色	H&E 为苏木精-伊红，IHC 为免疫组化
ICC	免疫细胞化学	细胞学样本的免疫染色（HISTAI 未单独统计）
ICD-10	国际疾病分类第十版	标准化疾病编码体系
grossing	大体检查	对标本肉眼观察的描述（大小、颜色、质地）
micro protocol	镜下描述	显微镜下观察的组织学描述
ground truth	金标准	用作监督信号的权威标签
kappa (κ)	一致性系数	衡量两位评定者一致程度，已校正随机一致
PII	个人可识别信息	姓名、日期、地址等可定位到个人的信息
IRB	伦理审查委员会	机构内审查人体研究伦理的委员会
provenance	溯源	数据从采集到发布的完整来源记录
self-supervised learning (SSL)	自监督学习	无需人工标签的预训练方式
domain shift	域偏移	训练与测试数据分布不一致

附录 I：快照对照表

下表把论文口径、README 口径与 HF 实测三者并置，便于一次性核对。凡出现"未取"的格子，表示该项在本次抓取中没有从 API 读到（并非数据不存在）。

项目	论文（S2）	GitHub README（S3）	HF 实测（S4）
子集数量	8	9	10（含 metadata）
总切片	60,110	112,801	60,110 + 52,691
总病例	26,142	47,279	未直接暴露
20× 切片	57,647	110,338	未取
40× 切片	2,463	2,463	未取
H&E 切片	58,282	92,536	未取
IHC 切片	未单列	16,920	未取
其他染色	1,828	3,345	未取
许可	未声明	CC BY-NC 4.0	cc-by-nc-4.0
访问	仅称 open-access	HF 下载命令	gated=manual ×10
空间分辨率	未公开	未公开	未公开
官方划分	无	无	无
伦理审查	未披露	未披露	未披露

使用这张表的三条规则：

1. 任何空缺都不要用"想当然"填。典型错误是把"未单列 IHC"读成"IHC 数量为 0"——论文只是没在 8 子集口径里拆开统计。
2. 引用时标明列名。写"论文口径 58,282 张 H&E"是准确的；写"HISTAI 有 58,282 张 H&E"则不准确，因为全仓库是 92,536 张。
3. 遇到二手材料给出第四种数字（例如"约 6 万张"），先判断它是四舍五入还是另一个时点，不要直接采信。

附录 J：致谢与引用规范

推荐引用格式（数据）：

Nechaev D, Pchelnikov A, Ivanova E. HISTAI: An Open-Source, Large-Scale Whole Slide Image Dataset for Computational Pathology. arXiv:2505.12120 [eess.IV]. 2025. doi:10.48550/arXiv.2505.12120. Dataset: https://huggingface.co/datasets/histai/HISTAI-metadata (accessed 2026-10-17).

如果引用了规模数字，在正文补一句口径说明：

“…comprising 112,801 whole slide images from 47,279 cases (9 subsets; the original arXiv preprint reported 60,110 slides and 26,142 cases across 8 subsets).”

如果讨论了标签质量，应同时引用审计文献：

Hewitt KJ, Reitsam NG, Foersch S, Erber R, Zeng Q, Kather JN. HISTAI: a valuable dataset with a valuable lesson. J Pathol Clin Res. 2026;12(3):e70089. doi:10.1002/2056-4538.70089.

如果使用了 hist.ai 的模型或工具，README 建议引用对应的姊妹工作：SPIDER（arXiv:2503.02876）与 Hibou（arXiv:2406.05074）。本条目未核实这两项的细节，引用前请自行查阅原文。

不建议的引用方式：把 HISTAI 列为"TCGA 扩展集"或"TCGA 子集"；把论文标题中的 “Open-Source” 当成"无限制开放"；只引 GitHub 仓库而不引论文（反之亦然）。这三类写法都会给审稿留下可质疑的入口。

附录 K：数据字典（字段级）

本表把 §4.1 与附录 B 的字段信息整合成可直接用于建表的规格说明。"建议类型"一列是按建模需要推出的处理建议，不是原始数据类型。

字段	原始形态	建议类型	处理要点
diagnosis	自由文本（短）	string，仅作元信息	不建议作标签；可用于推断转诊科室
conclusion	自由文本（中长）	string → 派生标签表	标签主来源；需分词与实体抽取
diff_diagnosis	自由文本	string，可空	稀疏，多数场景弃用
micro_protocol	自由文本（长）	string	图文对齐的正文来源；需按句切分
additional_info	自由文本	string，可空	含 PII 风险，公开前须脱敏
age	数值字符串	int，可空	注意单位统一为年；异常值需清洗
gender	单字符	category，可空	取值可能为 f/m 或其他记号，需先统计
icd10	编码字符串	multi-label list	可能含多个编码（逗号或分号分隔），需拆
specialization	短文本	category，可空	与子集目录交叉校验
case_mapping	路径字符串	外键	解析为 (subset, case_id)
grossing	自由文本（长）	string，可空	含 PII 风险；非随机缺失

建表建议：主表一例一行，键为 (subset, case_id)；标签拆成独立的 case_label 表（一例多行，每行一个标签），这样 icd10 的多编码与 conclusion 的多诊断都能容纳。若强行做成宽表，多标签会被压成一条长字符串，后续查询与统计都很麻烦。

三个字段处理的具体提醒：

• gender 的取值集合未公开。常见病理系统的做法是 m/f 单字符，但可能混入本地语言记号。建议读取后先做一次 value_counts，再定映射规则，不要预设只有两个值。
• icd10 的分隔符未公开。README 示例只给了单一编码 D22，没有展示多编码的写法。建议用正则先探测（逗号、分号、空格、斜杠四种），再决定解析器。
• age 可能为空串而非 null。JSON 里空串与缺键的处理方式不同，清洗前要先区分这两种情况，否则会把空串当成 0 岁。

附录 L：模型与流程选型建议

本节给出的是一个"不追新、够用"的基础配置，目的是让读者在决定投入之前有一个可执行的起点。所有建议都不依赖特定论文的网络结构。

L.1 切片编码器

方案	优点	缺点	适用
通用 ImageNet 主干（ResNet50/ViT-B）	易得、稳定、算力低	对病理纹理的判别力有限	先跑通基线
病理自监督主干（如公开的病理基础模型）	特征更贴合组织学	权重许可需另查，可能也有 NC 限制	追求性能
自建自监督（在 HISTAI 上预训练）	充分利用无标签优势	需要大算力与长周期	有资源的团队

提醒：病理基础模型本体（如 Hibou）的许可是独立的一套，与 HISTAI 数据的 CC BY-NC 不是同一件事。二者叠加使用时，最终模型的可用范围取交集——这一点在项目立项时就该确认。

L.2 切片级到病例级聚合

方案	说明	适用
均值池化	全部 patch 特征取平均	最快，基线
注意力多实例学习（ABMIL）	学习 patch 权重	病变占比小的情况
Top-k 池化	取响应最强的 k 个 patch	检出导向任务
Transformer 切片级	把病例内多张切片当作序列	需要切片间关系建模

HISTAI 平均每例 2.39 张切片，切片级 Transformer 的序列不长，计算上完全可行。若做病例级报告生成，这条路径值得优先尝试。

L.3 评测的三个必报指标

指标	为何必报
每类样本数	类别极不均衡时，宏平均会被少数类主导，需让读者自行判断
宏平均 AUROC / F1	与微平均并列，揭示少类表现
病例级 vs 切片级指标	两者差距反映聚合策略的效果，也是与文献对比的关键

L.4 一个常被忽略的对照

若要论证"HISTAI 有价值"，最有力的对照不是"比其他数据集好"，而是同一任务、同等数据量下，有无临床文本的差异。例如在 breast 子集上，仅用图像 vs 图像 + conclusion 文本嵌入，两者对比能直接量化文本字段的边际价值。这个实验不需要大量算力，结论却很实在。

附录 M：术语之外的三条阅读提示

提示一：数字要带"谁说的"。 本条目里每个规模数字都标了三源中的哪一源（论文 S2 / README S3 / HF 实测 S4）。读者在别处看到"HISTAI 有 X 张"时，也应先问一句"这个 X 出自哪里、什么时点"。

提示二：形容词要还原成事实。 论文说 “open-access”，事实是 gated + 非商用；摘要说 “detailed pathological annotations”，事实是无图像标注、只有报告文本。这类措辞在数据集论文里很常见，阅读时的习惯性动作是把形容词翻译成可核查的事实。

提示三：批评要看作者位置。 指出 HISTAI 标签问题的是外部团队（Kather 组），不是作者自己。这不影响批评的有效性，但说明作者在发布时并未做同类自检。对使用者来说，这意味着不能指望作者提供质量担保，只能靠自己抽样验证。

---

相关数据集导航

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

• lightmycells2 — 共享标签：医学影像 / 病理图像 / 多模态影像
• hancock-hnscc — 共享标签：病理图像 / 影像-文本对齐 / 队列研究 / 肿瘤学
• cmb-aml — 共享标签：医学影像 / 病理图像 / 队列研究 / 肿瘤学
• patchgastricadc22 — 共享标签：医学影像 / 病理图像 / 影像-文本对齐 / 肿瘤学
• ocelot — 共享标签：医学影像 / 病理图像 / 肿瘤学
• sicapv2 — 共享标签：医学影像 / 病理图像 / 肿瘤学
• msk-impact — 共享标签：医学影像 / 病理图像 / 肿瘤学
• munich-bmc — 共享标签：医学影像 / 病理图像 / 肿瘤学
• cmb-gec — 共享标签：医学影像 / 病理图像 / 队列研究 / 肿瘤学
• cima — 共享标签：医学影像 / 病理图像 / 肿瘤学

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