信息速览

数据集名称GastroHUN — 胃部系统筛查内镜图像与序列数据集

数据类型影像数据,视频数据,人工标注

规模387 名患者（图像口径）；序列来自 223 名患者（部分患者无录像）；视频内镜 238 段

接入方式哥伦比亚国立大学医院（Hospital Universitario Nacional de Colombia）消化内科真实临床采集的胃部系统筛查内镜（Olympus EVIS EXCERA III CV-190 + MAJ-1925 便携存储），Epiphan/Elgato 采集卡录像，四名消化内科专家按 SSS 协议标注

AI 就绪度

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

上消化道（胃）内镜检查是发现胃癌、尤其是癌前病变与早期胃癌的核心手段，而标准化、系统化的检查流程是提升检出率的关键。近年内镜 AI 研究急需公开的内镜图像数据库，但既有的公开内镜数据集长期存在两个痛点：标注口径不一致（不同中心、不同医师对同一站位/病灶的命名与判定差异大）与可获取性受限（数据封闭或不完整），导致训练出的模型有偏、泛化能力差。

GastroHUN（全称 GastroHUN an Endoscopy Dataset of Complete Systematic Screening Protocol for the Stomach）正是为回应这两个痛点而建：它由哥伦比亚国立大学（Universidad Nacional de Colombia）Cimalab 与 MindLab 研究组联合哥伦比亚国立大学医院消化内科构建，于 2025 年 1 月发表于 Scientific Data（Nature Portfolio），并同步在 Figshare 公开。

一句话概括：这是一个按「SSS 胃系统筛查拍照协议」组织的、由四名消化内科专家按多级共识标注的、包含 8834 张图像 + 4729 条视频序列 + 238 段完整视频内镜的公开上消化道内镜数据集，作者称其为「largest publicly available collection of systematic stomach examination images」（公开可得的规模最大的胃系统检查图像集合）。

本条目怎么读

想快速判断能不能用 → 直接看「§1 十问十答」与「§5 获取与许可」。
想复现基线 → 看「§6 评估与基准」，模型 checkpoint 与 Colab notebook 均公开。
关心标注质量 → 看「§4 标注体系与多级共识」与「§8 方法学启示」。
关心数字口径 → 全文所有硬数字均来自论文正文/表格与官方 README；两处双口径（许可、类别数）已在「§9 避坑清单」存照。
本条目为中文为主、术语首现标英文的百科式条目；英文对照用于检索与引用。

为什么 GastroHUN 值得单独建档

在众多内镜数据集中，GastroHUN 有三个「不可替代」的理由：

它是地理稀缺的：绝大多数公开上消化道内镜数据来自欧洲或东亚（挪威 Kvasir、日本 ENDOTOKYO 等），拉丁美洲来源的大型公开数据集此前近乎空白。对研究「模型跨人种/跨地域泛化」的团队，这是一个不可替代的数据点。
它是协议驱动的：不是把医院里现成的图像堆起来，而是先有一套临床标准协议（SSS），再按协议采集与标注。这种「协议即结构」的设计，使数据集天然适合做「检查完整性」类研究。
它把标注过程也公开了：四专家双团队 + 8 级共识，让「标签有多可信」成为可分析的变量，而非黑箱 ground truth。这在内镜数据集里罕见。

同时，它也是一个需要看清边界的数据集：许可为 CC BY-NC 4.0（非完全开放）、任务聚焦站位分类（非病灶检出）、规格存在异质性（双分辨率/双来源）。本条目把这些边界逐条写清，正是为了让使用者「用得住、不踩线」。

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

十问十答提供的是「够用就停」的最小决策信息；每问下的展开段是给需要深入的使用者的补充。若只想知道能不能用，读每问的第一段即可。

Q1：GastroHUN 是什么？

一个公开的上消化道（胃）内镜数据集，含图像、视频序列与完整视频内镜三类资产，按 SSS 系统筛查协议组织，用于 AI 模型的解剖站位识别与图像/序列分类。

展开：它不是一个「病灶数据集」——数据集不含息肉/癌/溃疡的像素或框标注，而是标注「这张图拍的是胃的哪个标准站位」。因此它的典型用途是「内镜检查完整性识别」与「站位分类」，而非「病变检出」。三类资产（帧/序列/视频）对应三种粒度的研究。

Q2：谁做的？

哥伦比亚国立大学 Cimalab 与 MindLab 研究组 + 哥伦比亚国立大学医院消化内科。通讯作者 Diego Bravo。

展开：这是一个「大学研究组 + 大学附属医院」的合作产物——研究组提供 AI 与数据工程能力，医院消化内科提供真实临床内镜与标注专家。八名作者的构成也体现了这一点（影像/计算背景与临床背景混合）。数据集是拉丁美洲首个大型公开上消化道内镜数据集。

Q3：什么时候发的？

2024-08-24 投稿 Scientific Data，2025-01-02 接收，2025-01-17 见刊（论文 2025;12(1):102）。

展开：GitHub News 逐条记录了投稿到见刊的四个节点（投稿 → 收审稿意见 → 提交修订 → 接收/见刊），详见 §2.6 前的时间线。数据集在论文接收前仅对审稿人可见，见刊后经 Figshare 正式开放。

Q4：数据量多大？

8834 张标注图像（387 名患者）+ 4729 条标注序列（223 名患者）+ 238 段视频内镜，总容量 96.86 GB。

展开：三个数字对应三类资产，且患者数不同（见 Q6 与 §2.5）。容量 96.86 GB 主要由视频内镜贡献；若只做图像分类，实际下载量远小于此。分片表（训练/验证/测试）见 §5.3。

Q5：有多少类？

23 类：22 个胃解剖站位 + 1 个 NA（不合格/不适用）。

展开：22 个站位按胃的解剖分区与四象限（前壁 A / 小弯 L / 大弯 G / 后壁 P）组织，来自 SSS 协议。论文摘要用「22 anatomical landmarks + NA」表述，GitHub 表列 0-22 共 23 个 ID——二者本质一致，见 §9 坑 2。

Q6：怎么标？

四名消化内科专家组成两个团队（FG 专科培训医师 Team A / G 主治医师 Team B）独立标注，并给出 8 级共识标签（All/Triple/FG/G 及两两一致）。

展开：双团队设计的用意是让「资历」成为一个可控变量。8 级共识让下游可选择标签严格度。标注流程 SOP 见 §4.6，一致性统计方法见 §4.4。

Q7：从哪拿？

Figshare，DOI 10.6084/m9.figshare.27308133，论文接收后公开。

展开：配套资源包括 GitHub 代码仓库、Google Drive 上的预训练 checkpoint、以及 Colab 可运行的示例 notebook。获取入口汇总见 §5.1。

Q8：什么许可？

CC BY-NC 4.0（署名-非商业性使用），且竞赛等用途需事先书面许可。注意与论文本体 CC BY 4.0 不同。

展开：这是使用 GastroHUN 最容易踩的坑（§9 坑 1）。数据集 README 徽章为 CC BY-NC 4.0，正文另加「竞赛等用途需事先书面许可」与「强制引用」两条。合规检查清单见 §5.5。

Q9：有基线吗？

有。图像分类基线 ConvNeXt_Large 达 Macro-F1 88.25±0.22（224×224，All agreement）；序列分类基线最优约 86.30（FG1-G2 agreement）。checkpoint 与 notebook 公开。

展开：论文给出三个场景（A 骨干对比 / B 共识级别 / C 序列分类）的完整 F1 表，见 §6。核心结论是「共识级别」对结果的影响与「换模型」同量级。

Q10：有什么坑？

许可双口径、类别数表述（22 landmarks vs 23 类）、序列/图像患者数不一致、README 站位拼写笔误——见「§9 避坑清单」。

展开：四类坑分属「合规」「口径」「结构」「文档」四个层面。前两个必须在使用前看清，后两个影响数据清洗与论文写作。每条坑都给了处理口径与存照。

§2 数据构成与规格

2.1 三大目录与资产清单

GastroHUN 在 Figshare 上组织为三个目录：

Labeled Images（标注图像）：每类一个归档文件，含 8834 张带标签图像。
Labeled Sequences（标注序列）：每类一个归档文件，含 4729 条 10 秒短视频片段。
Videoendoscopies（视频内镜）：含内镜所见与病理诊断的完整录像文件（共 238 段）。

三个目录分别配一份元数据 JSON：gastrohun-image-metadata.json、gastrohun-sequence-metadata.json、gastrohun-videoendoscopy-metadata.json。这些 JSON 是理解数据集的关键——它们把每个文件名映射到标签、患者号与共识级别。

2.2 图像资产：8834 张，两种来源

图像部分（Labeled Images）是数据集的「主资产」：

维度	规格
总张数	8834 张
患者数	387 名
内镜直采	8053 张 JPG（Olympus MAJ-1925 便携存储，随 EVIS EXCERA III CV-190）
视频抽帧	781 张 JPG（从录制的视频内镜中截帧）
分辨率档 1	1080×1350，8427 张（91.16%）
分辨率档 2	720×900，407 张（8.84%）
压缩	默认 1/5–1/10（奥氏设备默认压缩）

元数据 JSON 中的 source_type 字段明确标注每张图是「直采」还是「视频抽帧」，这对数据清洗很重要：两类来源的图像质量、压缩痕迹不同。

有一处需要辨析的口径：视频抽帧的分辨率亦为两档——720×900（407 张）与 1080×1350（374 张）。论文称「尽管压缩与分辨率格式存在差异，专家团队未感知到差异」（the set of experts did not perceive any difference among the different compression and resolution formats），这是作者对异质性的自我辩护。

2.3 序列资产：4729 条，10 秒切片

「序列（Sequence）」在 GastroHUN 中有严格定义：以某张已标注帧为中心、前后各取 5 秒、共 10 秒的视频片段。

序列总数：4729 条
来源患者：223 名（注意：少于图像的 387 名）
中心帧标签：沿用 Labeled Images 流程赋予
编码规格：15 fps，libx264，像素格式 yuv420p，baseline profile，bitrate 23，MP4 封装
元数据字段：gastrohun-sequence-metadata.json 记录患者号、帧号、序列帧范围、来源视频内镜名、以及四专家独立标注与各级共识

序列的医学意义在于：单帧图像丢失了「内镜推进/退镜过程中站位如何变化」的时间信息，而 10 秒窗口恰好捕捉一个站位被稳定观察的时间跨度，因此序列分类任务比单帧分类更贴近真实内镜检查的时序特征。

2.4 视频内镜资产：238 段完整录像

Videoendoscopies 目录存放完整的内镜检查录像（238 段），除视频本身外还包含「内镜所见（endoscopic findings）」与「病理诊断（pathological diagnoses）」信息。这是数据集中最贴近原始临床记录的一层——序列与图像都是从这一层派生出来的。

值得注意：238 段视频对应 223 名（有序列的）患者量级，说明部分患者可能做了多次检查，或存在视频与患者的一对多关系。

2.5 患者数口径：387 vs 223 不是矛盾

一个常见误读是把「8834 图 / 387 患者」与「4729 序列 / 223 患者」当成矛盾。其实不然：序列必须有录像才能提取，而部分患者只有静态图像、没有录制视频。论文在分片表注解中明确写道，序列病例数的减少源于「absence of recorded video procedures」（缺少录像检查）。因此：

图像任务的患者全集 = 387；
序列任务的患者全集 = 223（是 387 的子集）；
两个任务的训练/验证/测试划分在各自患者集合内做患者级隔离（避免同一患者跨集泄漏）。

2.6 类目体系：23 类（22 站位 + NA）

数据集采用 23 个类别，对应胃部 22 个标准拍照站位 + 1 个 NA 类：

0-3：A1 / L1 / P1 / G1 —— 胃窦（Antrum）
4-7：A2 / L2 / P2 / G2 —— 下胃体（Lower Body）
8-11：A3 / L3 / P3 / G3 —— 中上胃体（Middle Upper Body）
12-15：A4 / L4 / P4 / G4 —— 胃底贲门（Fundus Cardia）
16-18：A5 / L5 / P5 —— 中上胃体（Middle Upper Body）
19-21：A6 / L6 / P6 —— 胃角（Incisura）
22：NA —— 其他/不合格（OTHERCLASS）

其中字母含义：L = 小弯（Lesser curvature）、A = 前壁（Anterior wall）、G = 大弯（Greater curvature）、P = 后壁（Posterior wall）；数字代表站位顺序。

这一体系直接来自 SSS（Systematic Screening protocol for the Stomach，胃系统筛查协议） 的拍照规范（Yao 光对照法 Photodocumentation guidelines），也是数据集名字里「HUN」之外「系统性筛查」的由来。§4 会详述协议本身。

值得注意的一个结构特点：22 个站位并非均匀分布在胃的各个区域。从上面的分组可以看到，胃窦、下胃体、中上胃体各占 4 个站位（前/后/大弯/小弯四象限），胃底贲门占 4 个，而中上胃体在协议的第二段（反转视角）又补了 3 个（A5/L5/P5），胃角占 3 个。这种「同一区域在不同视角下重复覆盖」的设计，正是 SSS 协议为保证反转视角下（retroflex）胃底与胃角也被拍全而做的冗余——但也带来一个隐性后果：同一解剖区域在不同站位标签下的图像外观可能相似，构成类间混淆的天然来源（例如 A5/L5/P5 与 A3/L3/P3 都属中上胃体，模型容易互错）。

2.7 分辨率与压缩的异质性：一个被轻描淡写的规格问题

把图像资产的规格摊开看，GastroHUN 并非「同质齐整」：

维度	档 A	档 B
直采图像分辨率	1080×1350（8427 张，91.16%）	720×900（407 张，8.84%）
视频抽帧分辨率	1080×1350（374 张）	720×900（407 张）
压缩比	1/5	1/10

也就是说，数据集里同时存在两种分辨率、两种压缩比、两种来源的组合。论文对此的辩护是「专家组未察觉不同压缩与分辨率格式间的差异」（the set of experts did not perceive any difference among the different compression and resolution formats）——这句话的准确含义是「不影响标注正确性」，不等于「对模型无影响」。做复现或迁移时，一个稳妥的做法是：

先把所有图像统一 resample 到目标分辨率（论文基线用 224×224）；
用 source_type 分层统计直采 vs 抽帧两类图像在各站位上的分布；
若发现某站位几乎全部来自单一分辨率档，则模型在该站位上的表现可能被分辨率而非解剖特征驱动。

2.8 患者级分布与「序列是子集」的结构

数据集的两条主线（图像任务、序列任务）在患者层面并非同一批人，这是理解复现与迁移的关键结构：

图像任务患者全集 = 387：其中训练 270、验证 58、测试 59。
序列任务患者全集 = 223：其中训练 159、验证 32、测试 32。
223 ⊂ 387：所有有序列的患者，必然也是有图像的患者（因为序列由录像派生，而录像对应的检查同样产出图像）；反之不成立。

这意味着：

不能把图像任务与序列任务的患者混着做多任务学习再按患者划分——否则会对不齐。
序列任务的样本量虽小（4729 vs 8834），但患者数更少（223 vs 387），患者级划分后每名患者贡献的序列数（4729/223 ≈ 21.2 条/人）高于每名患者贡献的图像数（8834/387 ≈ 22.8 张/人）——数量级相近，说明采集时对每名患者大致按同一套站位拍照，序列则从这些站位对应的录像段切出。

2.9 一个「规模最大」宣称的边界

作者在 GitHub 与论文中称 GastroHUN 是「largest publicly available collection of systematic stomach examination images」（公开可得的规模最大的胃系统检查图像集合）。这个宣称有两个限定词值得注意：

「systematic stomach examination」：限定在「系统性胃检查」这一协议组织方式，而非泛泛的「胃镜图像」总量——所以它并不与 Kvasir/HyperKvasir 这类以病变/息肉为主的消化道数据集在规模上直接比拼。
「images」：宣称主体是图像数量（8834 张），而非序列或视频数。

因此这是一个有明确边界的宣称，引用时不宜简化为「最大的胃镜数据集」。

2.10 三类资产的关系图（文字版）

把三类资产的关系画成文字流程：

每次内镜检查（238 段视频内镜）
        │
        ├── 录像 → 抽帧 → 部分 Labeled Images（781 张，source_type=video_frame）
        │
        └── 内镜直采 → 部分 Labeled Images（8053 张，source_type=direct）
                          │
                          └── 以某标注帧为中心 → 前后各 5 秒 → Labeled Sequences（4729 条）

要点：

图像有两个来源：直采（质量更好）与录像抽帧（覆盖更全）。
序列由图像派生：不是所有图像都有对应序列，只有「站点已标注且录像可用」的帧才生成序列。
视频内镜是根：238 段视频是抽帧与序列的源头，也是唯一保留完整时间轴的资产。

2.11 元数据字段逐项说明

三份 JSON 元数据是复现的关键，字段大致如下（据论文 Table 3）：

图像元数据（gastrohun-image-metadata.json）：

字段	含义
文件名	图像 ID（对应 Labeled Images 内文件）
患者号	患者标识（用于患者级划分）
标签	站位类别（0-22）
FG1/FG2/G1/G2	四专家各自的标签
共识（8 级）	All/Triple/FG/G/两两
source_type	direct（直采）/ video_frame（抽帧）

序列元数据（gastrohun-sequence-metadata.json）：

字段	含义
序列名	序列文件标识
患者号	患者标识
帧号	中心帧编号
序列帧范围	中心帧前后各 5 秒对应的帧区间
来源视频名	对应 Videoendoscopies 中的视频
标签与共识	与图像同一套 8 级共识

视频内镜元数据（gastrohun-videoendoscopy-metadata.json）：

字段	含义
视频名	视频文件标识
内镜所见	endoscopic findings
病理诊断	pathological diagnoses

说明：以上字段名以论文 Table 3 的描述为准（本条目未逐字复制 JSON schema）；实际字段以下载后的文件为准。

2.12 类别分布：一个未被逐类披露的维度

需要诚实指出：论文没有在正文中给出 23 类各自的精确样本数（Fig 2 以柱状图按标注者与共识级别展示分布，但数值需从图上读取）。因此本条目不列逐类数字，以免从图片估读引入误差。已知的分布特征包括：

22 个站位按 SSS 协议采集，理论上应大致均衡，但真实临床采集必有波动。
NA 类作为兜底类，其占比反映「难以定性」的图像比例。
类别不均衡对 Macro-F1 的影响，已在 §4.11 讨论。

给使用者的建议：拿到数据后先自己统计逐类样本数（用元数据 JSON 聚合），这是任何不平衡处理（重采样/类权重）的前提。不要假设分布均衡。

2.13 从数据到模型：一个典型流水线

把本条的资产与任务串起来，一个典型的使用流水线是：

Figshare 下载 Labeled Images
        │
        ├─ 解析 gastrohun-image-metadata.json（取标签 + 共识 + source_type）
        ├─ 按官方 CSV 划分患者级 train/val/test
        ├─ 选一个共识级别作为 ground truth（如 All 或 FG）
        ├─ 预处理：统一分辨率到 224×224
        ├─ 训练骨干（如 ConvNeXt）→ 评估 Macro-F1
        └─ （进阶）换软标签/多共识训练，或迁移到跨中心测试

若做序列任务，把 Labeled Images 换成 Labeled Sequences，模型换成 GRU/Transformer，流程类似。这条流水线对应 §6 的基线复现路径。

§3 采集与协议：SSS 胃系统筛查拍照法

3.1 为什么需要「系统化」拍照协议

传统胃镜检查依赖操作者的经验与习惯，站位覆盖随意。对于胃癌早筛，能否把胃的每个解剖区域都拍到位直接决定了能否发现癌前病变与早期癌。日本学者 Yao 等人提出的 SSS（Systematic Screening protocol for the Stomach） 通过规定固定的拍照站位与视角，把「看没看全」这一问题标准化。GastroHUN 的整个数据组织即建立在这一协议之上。

3.2 协议的两段式拍照流程

SSS 协议把胃的检查分为前向视角与反转视角两段：

前向视角（anterograde view）：内镜进入胃窦后，对胃窦、胃体、中上胃体各拍 4 个象限的照片。
反转视角（retroflex view）：内镜在胃底反转，对胃底贲门拍 4 个象限，对中上胃体与胃角拍 3 个象限。

整个 SSS 系列共 22 张标准站位的照片。四个象限对应四个位置：小弯（L）、前壁（A）、大弯（G）、后壁（P）——这与 §2.6 的 23 类标签字母一一对应。

3.3 采集工程：设备与人员

内镜设备：Olympus EVIS EXCERA III CV-190 内镜系统，配 Olympus MAJ-1925 便携存储（直采图像默认压缩比 1/5–1/10）。
录像采集卡：Epiphan（Ottawa, Canada，专业视频采集硬件厂商）或 Elgato（Corsair Components, Inc., Fremont, California, USA，消费级采集设备）。
录像帧率：30 fps 与 15 fps 两种。
人员监督：录像期间由五名消化内科医师中的至少一名在场监督采集质量——但不干预诊疗流程。
采集期：回顾性收集 2019–2023 年间计划检查的病例。
去标识化：图像与视频经手工编辑去除直接/间接标识符，并删除镜头在体外时的帧。

3.4 从原始录像到可用数据集的处理链

去标识化剪辑：删除可识别信息与体外的无效帧。
直采图像归档：内镜便携存储出的 JPG 直接作为「直采图像」。
抽帧补充：对无直采图像的站位，从录像中截帧（记为「视频抽帧」，source_type 区分）。
序列切分：以标注帧为中心，前后各 5 秒生成 10 秒 MP4 片段（15 fps）。
元数据绑定：三份 JSON 把文件名绑定到标签、患者号、共识级别与来源视频名。

3.5 视频内镜与病理诊断的叠加信息

Videoendoscopies 目录不仅存视频，还附带「内镜所见」与「病理诊断」——这使数据集不仅是「图像分类素材」，也具备临床结局标签的雏形。不过需要说明：论文的基线任务聚焦在解剖站位分类（23 类），并未把病灶/病理诊断作为主要预测目标，这一点在复用数据时应留意。

3.6 站位与视角的空间关系：为什么有两段式

理解 SSS 两段式协议的关键是内镜的物理可及性。内镜是一根柔性管，从口腔经食管进入胃：

当内镜直行前进（前向视角）时，它能清楚看到前方的胃窦、胃体壁面，因此用前向视角对胃窦、胃体、中上胃体各拍四象限。
但胃底与贲门位于内镜入口的「背后」，直行视角看不到。必须让内镜回勾（反转视角，retroflex），像「回头看」一样才能拍到胃底贲门。
反转视角下，胃角（incisura）这一小弯上的角状结构也需要专门的角度才能拍清，因此协议为胃角额外规定 3 个站位。

这种「前向 + 反转」两段式是胃镜检查的通用手法，SSS 协议的贡献是把它量化为固定的站位与象限数。GastroHUN 的 23 类标签，本质就是把这个空间协议「逐站打点」的结果。

3.7 采集质量控制：谁在场、怎么保证

数据集的采集质量由三层机制保障：

在场监督：录像期间至少一名消化内科医师在场（五名专家轮值），确保采集符合规范而不干预诊疗。这是「真实临床场景下的质量兜底」。
专家标注复核：四名专家独立标注并计算一致性，一致性的高低直接反映采集/标注质量。
NA 兜底：无法清晰辨识的图归 NA，避免坏样本污染站位类。

这套机制的代价是依赖人工在场，无法完全自动化——但也正因如此，数据的临床真实性较高。

3.8 采集期 2019–2023 的含义

数据集是**回顾性（retrospective）**收集的：从 2019 至 2023 年间已排期的检查中挑选。这意味着：

数据反映的是这五年间该医院的真实检查实践与设备状态；
设备（Olympus CV-190）在这段期间相对稳定，但患者构成、季节、操作者轮换等因素可能引入未记录的批次效应；
回顾性设计无法控制样本量在各类别上的均衡，因此类别分布可能反映真实就诊结构而非平衡采样。

3.9 采集链中的质量衰减点

从临床操作到最终数据集，数据经过了多个处理环节，每一环都可能引入质量差异：

环节	潜在问题	数据集对策
内镜操作	站位未拍全/拍偏	监督医师在场 + NA 兜底
直采保存	压缩（1/5–1/10）	记录压缩比，专家确认不影响标注
录像采集	采集卡差异（Epiphan vs Elgato）	两种设备混用，未分离标注
抽帧	分辨率不同（720×900 vs 1080×1350）	记录 source_type
序列切分	帧率 15 fps 固定	统一编码参数
标注	专家分歧	8 级共识 + κ 统计

这张表的价值在于：它列出了复现时可能需要分层控制的变量。若你的模型在 GastroHUN 上表现异常，逐一排查这些环节（尤其设备差异与 source_type）往往能定位问题。

3.10 为什么「拍全 22 个站位」临床上有意义

胃癌的分布并不均匀——不同解剖部位的癌前病变与早期癌发生率不同。若一次检查漏拍了某一站位，该部位的病变就可能完全被漏掉。SSS 协议通过强制覆盖 22 个站位，把「漏拍」的概率降到最低。

从 AI 角度，这意味着：

站位分类模型可以作为「检查完整性审计器」：自动识别每张图属于哪个站位，统计一次检查是否拍全。
缺站位提示：若某站位在所有图像中缺失，系统可提醒医师补拍。
质控量化：把「检查质量」从一个主观评价，变成一个「22 站位覆盖率」的客观指标。

这正是 §8.1 所说「把临床 SOP 结构化，再喂给模型」的直接应用价值。

§4 标注体系与多级共识

4.1 四专家、两团队

标注由四名消化内科专家完成，且刻意分为两个团队以比较不同资历的一致性与可靠性：

Team A — FG（Fellow Gastroenterologist，消化内科专科培训医师）：FG1、FG2 两名。
Team B — G（Gastroenterologist，主治消化内镜医师）：G1、G2 两名。

这种「同域不同资历双团队」的设计，使数据集可以回答一个方法论问题：训练标签用谁的标准，模型结果差多少？（见 §7 场景 B/C 的数字）。

4.2 8 级共识标签

每张图/每条序列不只记录单一标签，而是记录多个共识层级：

共识层级	含义
Annotator FG1/FG2/G1/G2	单个专家的原始标注
FG	Team A 两名一致（FG1 = FG2）
G	Team B 两名一致（G1 = G2）
Triple	三名专家一致
All	四名专家全一致
FG1-G1 / FG1-G2 / FG2-G1 / FG2-G2	跨团队两两一致

这 8 级（论文称 “consensus labels across 8 levels”）让研究者可以按「标签严格程度」切分训练集，观察模型对标签噪声的敏感度。

4.3 NA 类的定义与语义异质性

NA（Not Applicable，不适用/不合格） 类在数据集中扮演特殊角色：当「目标类别不可清晰辨识」或「存在已记录病变」时，该图归入 NA。这一设计的用意是避免把模糊或异常图像强行塞进某个站位类，从而污染解剖站立分类。

但这也带来一个复制使用时需要注意的问题：NA 内部混合了两种异质情形（看不清 vs 有病灶），它不是一个语义单一的类别。若把 NA 当作「其他」类直接参与分类，模型学到的可能是「模糊度」而非某解剖语义。条目在 §9 中把这一点列为数据局限。

4.4 一致性度量：Cohen’s κ 与 Fleiss’ κ

论文用两类统计量评估标注一致性：

Cohen’s Kappa（科恩卡帕）：用于两两专家之间（组间）与同一专家跨时间（组内）的一致性（Fig 3 给出了完整的两两矩阵 + 对角线时序一致性）。
Fleiss’ Kappa（弗莱斯卡帕）：用于多名专家在某一患者子集内的整体一致性（Fig 4 以箱线图展示不同患者集上的 κ 分布）。

这些一致性统计的意义在于：GastroHUN 把「标签有多可信」量化并公开，而不是只给一个 ground truth。这为后来者按共识级别筛选训练数据提供了依据。

4.5 标注粒度与任务定义

数据集中每个资产对应明确的任务标签：

图像：单帧 → 23 类站位（含 NA）。
序列：10 秒片段 → 中心帧的站位标签（同样是 23 类）。

序列的标签继承自中心帧的图像标注流程，因此「序列分类」本质上是「带时序上下文的站位分类」。

4.6 标注流程 SOP：从挂图到落标签

把论文与仓库信息拼起来，GastroHUN 的标注流程大致可还原为以下 SOP：

站位筛选：从每名患者的图像集中，按 SSS 的 22 个标准站位定位候选帧（直采优先，缺则从录像抽帧）。
独立性保证：四名专家各自独立标注，标注前不共享彼此的判断（以保证 κ 统计有意义）。
标签赋予：对每张候选图，专家给出 23 类中的一类；当类别不可辨识或存在病灶时给 NA。
共识计算：系统据四人标注自动派生 8 级共识（单标注者 / FG / G / Triple / All / 两两）。
一致性统计：计算 Cohen’s κ（两两 + 时序）与 Fleiss’ κ（多专家）。
序列派生：以已标注帧为中心，前后各取 5 秒生成序列，中心帧标签沿用上一步结果。
元数据固化：写入三份 JSON。

这个 SOP 的可贵之处在于第 2 步的独立性与第 4 步的共识显式化——很多数据集只给一个 ground truth，而 GastroHUN 把「标注过程本身」也作为可分析对象保留下来。

4.7 一致性数字怎么读

论文用 Fig 3（Cohen’s κ 矩阵）与 Fig 4（Fleiss’ κ 箱线图）展示标注一致性。读这两张图有三个要点：

矩阵的对角线（Fig 3）是组内一致性（同一专家跨时间重复标注的自我一致性），非对角线是组间一致性（两名不同专家之间）。对角线通常高于非对角线——即「自己始终比自己 vs 别人」更一致，这是人因学的常见规律。
两个团队 的成员分别标为 FG（Team A）与 G（Team B），矩阵中的 FG×G 交叉块反映跨资历一致性，通常低于同团队内一致性。
Fleiss’ κ 箱线图（Fig 4）按患者子集展开，箱线图的离散程度本身是信息：方差大的子集说明该批患者图像对专家而言更难判。

需要提醒：本条目未逐格转录 Fig 3/Fig 4 的具体 κ 数值（论文正文以图呈现为主），因此正文不列具体 κ 数字，以免与图口径不符。若需精确数值，请以论文图为准——这是本条目「不臆造数字」纪律的体现。

4.8 标注粒度与「哪些图难」

从任务定义反推，GastroHUN 中有几类图像天然更难标：

同一区域跨视角图（如胃底贲门的前向 vs 反转视角）：外观差异大，但解剖归属相同，模型易混。
中上胃体的重复覆盖站位（A3/L3/P3 与 A5/L5/P5）：区域重叠，站位边界模糊。
NA 图像：本身就定义在「看不清/有病灶」的困难区。

这三点共同解释了一个现象：为什么 NA 类与若干中上胃体站位在混淆矩阵（Fig 7）里往往是最活跃的误分类对——不是因为模型差，而是因为这些类在解剖定义上本就相邻或重叠。

4.9 伦理与隐私：内镜数据的去标识化

内镜图像比一般医学影像更敏感——视频中可能出现患者的体表、口咽部，甚至操作者的对话。GastroHUN 的处理是：

手工去标识：论文明确「images and videos were manually edited to remove any identifying information, such as direct and indirect identifiers」（手工编辑去除直接与间接标识符）。
删除体外帧：删除「镜头在患者体外时」录制的帧（frames recorded when the camera was outside the patient’s body），避免摄入环境景物。
回顾性收集的伦理基础：数据来自已排期的临床检查，经伦理审批（论文为 Scientific Data 常规伦理声明；Collect data via clinical practice）。

对使用者的提示：即便数据已去标识，部署模型时仍需遵守当地医疗数据法规（如 HIPAA/GDPR 或所在国对应法规），数据集本身的开放不等于部署无约束。

4.10 共识标签的工程用法

「8 级共识」在工程上有几种典型用法：

严格训练：只用 All（四专家全一致）训练，标签最干净，但样本最少。
宽松训练：用单标注者标签，样本最多，但噪声最大。
多标签/软标签训练：把四专家的标签分布当作软目标（soft label），让模型学习专家分歧——这是「共识即消融」的进阶用法。
评估分级：在多个共识级别上分别评估，报告一条「随标签严格度变化的性能曲线」。

这四种用法的选择，直接决定实验结论的解读方式。论文场景 B/C 实际展示了前两种的对比。

4.11 一个容易被忽略的统计要点：Macro-F1 的选择

论文全程用 Macro-F1（宏平均 F1）而非 accuracy 或 micro-F1。这一选择有讲究：

23 类里各类样本数不均衡（某些站位图像远多于其它），若用 accuracy，模型可能靠预测大类刷分。
Macro-F1 对每一类等权，能暴露模型在小类上的崩塌。
这也是医学分类任务的惯例——临床关心的往往是「每个站位都识别得准」，而非「总体平均准」。

因此引用 GastroHUN 结果时，务必标注评价指标为 Macro-F1，否则与论文数字不可比。

4.12 双专家团队的共识派生示例

为直观理解 8 级共识，举一个假想的例子（示意，非真实数据）：

专家	标签	说明
FG1	A1	认为拍的是胃窦前壁
FG2	A1	与 FG1 一致
G1	A1	与 FG 一致
G2	P1	认为拍的是胃窦后壁

对这张图：

All（四全一致）：不成立（G2 不同）。
Triple（三一致）：成立（FG1/FG2/G1 三人为 A1）。
FG（Team A 一致）：成立（FG1 = FG2 = A1）。
G（Team B 一致）：不成立（G1 与 G2 不同）。
FG1-G1 / FG1-G2 / FG2-G1：均成立（都含 G1 或 G2 之一与 FG 一人，且同标签）；FG2-G2 不成立。

这个例子说明：同一张图在不同共识级别下「是否可用」不同——若只用 All 训练，这张图被排除；若用 Triple，它可用；若用单标注者，它则是四个不同标签。这正是数据集「共识即消融」的微观体现。

4.13 一致性为何对训练如此重要

回到一个根本问题：为什么要在意标注一致性？

若标签噪声高，模型的性能上限被拉低——它会去拟合专家的随机分歧，而非解剖规律。
高一致性标签训出的模型更可迁移——它学到的是多数专家共认的解剖特征。
论文场景 B/C 的经验值给出量化答案：共识标签比单标注者高 3–6 个 F1 点，这就是一致性的「价钱」。

对数据使用者而言，这意味着：如果你的下游任务对精度敏感，优先用高共识级别的子集，即便样本更少。

§5 获取与许可：Figshare 公开，但有非商业限制

5.1 获取入口

资产	位置
数据集本体	Figshare，DOI 10.6084/m9.figshare.27308133（v1）
代码与脚本	GitHub `Cimalab-unal/GastroHUN`
论文	Scientific Data 2025;12(1):102，doi 10.1038/s41597-025-04401-5（开放获取）
预训练 checkpoint	GitHub README 指向 Google Drive 直链（图像/序列分类多组）
快速上手 notebook	`run_example.ipynb` 与 `Prediction_Stability_and_Performance_ScenarioABC.ipynb`（含 Colab 按钮）

Figshare 在论文接收前仅对审稿人开放，2025-01 论文见刊后正式公开。

5.2 许可：数据集与论文是两套

这是使用 GastroHUN 最需要看清的一点：

论文本体：Scientific Data 为开放获取期刊，论文采用 CC BY 4.0。
数据集本体：GitHub README 徽章标注 CC BY-NC 4.0（署名-非商业性使用）。

也就是说，你可以自由阅读、引用论文，但数据集的使用受「非商业性」限制。README 正文进一步收紧：

「The data is released fully open for research and educational purposes. The use of the dataset for purposes such as competitions needs prior written permission.」

即：研究与教育用途开放，但竞赛等用途需事先书面许可；并且任何使用或引用该数据集/基于其报告实验结果的文档与论文，都必须引用相关文章。

综合口径应为：CC BY-NC 4.0 + 竞赛用途额外书面许可 + 强制引用。条目在 §9 把「数据集 CC BY-NC 4.0 vs 论文 CC BY 4.0」列为双口径存照。

5.3 复现所需的元数据与划分

要复现基线，关键是拿对划分表（论文 Table 5）：

任务	训练	验证	测试	合计
图像分类（患者/图）	270 / 6165	58 / 1316	59 / 803	387 / 8834
序列分类（患者/序列）	159 / 3401	32 / 654	32 / 394	223 / 4729

划分在患者级做隔离，避免同患者跨集泄漏。GitHub 仓库另提供 image_classification.csv、sequence_classification.csv，以及三个 JSON 元数据文件，用于把文件名映射到划分与标签。

5.4 下载前的实操提示

数据集总容量 96.86 GB，务必先规划存储；Labeled Images 与 Labeled Sequences 按类打包，可按类选择性下载。
视频内镜（238 段）体积最大，若不需时序研究可跳过。
序列为 MP4（yuv420p / baseline / 15 fps / libx264 / bitrate 23），可用 ffmpeg 直接解码，无需特殊编解码器。
直采与抽帧图像混在同一 Labeled Images 中，用 source_type 字段区分，做质量控制时建议分层统计。

5.5 许可合规检查清单

若准备在正式项目中使用 GastroHUN，建议逐条核对：

[ ] 用途是否为非商业（研究/教学）？若为商业，需另行取得授权。
[ ] 是否涉及竞赛？竞赛用途需事先书面许可。
[ ] 是否会在成果（论文/报告/模型卡）中引用该数据集文章？README 要求强制引用。
[ ] 是否同时引用了数据集 DOI（Figshare 27308133）与论文 DOI（s41597-025-04401-5）？
[ ] 是否在数据卡中标注了 CC BY-NC 4.0 而非误写为论文的 CC BY 4.0？

这份清单对应的是 §9 坑 1 的合规面——GastroHUN 的许可是「开放但有边界」，不是完全无限制。

5.6 AI-Ready 视角的获取性评估

从「AI-Ready」的角度给 GastroHUN 的获取性打分（定性）：

维度	评价	说明
可发现性	高	论文 + 唯一名称 + Figshare DOI + GitHub，检索友好
直取性	高	Figshare 公开，无需申请（竞赛除外）
结构化	高	三份 JSON 元数据 + 划分 CSV，机器可读
复现性	高	脚本 + checkpoint + notebook 三件套齐全
许可宽松度	中	CC BY-NC 4.0，非商业限制
规格同质性	中	双分辨率/双来源/双压缩，需预处理统一
文档自洽性	中	许可/类别数双口径、README 拼写笔误

一句话：GastroHUN 在「直取性、结构化、复现性」上近乎满分，扣分项集中在「许可边界」与「规格异质性」两处。这恰是它作为 AI-Ready 条目的价值——它足够好用，但需要使用者看清边界。

5.7 与「请求制」数据集的对比

库内不少医学数据集采用请求制（向通讯作者申请、签数据使用协议），GastroHUN 则走公开直取路线。两条路线的权衡：

维度	公开直取（GastroHUN）	请求制
门槛	低（下载即用）	高（审批、等待）
可控性	低（使用方自证合规）	高（发布方可审用途）
速度	快	慢
隐私风险	依赖去标识质量	签署协议分担责任
复用率	高	受审批摩擦影响

GastroHUN 选择公开直取，用 CC BY-NC 4.0 与「竞赛需书面许可」来替代逐份审批——这是一种「批量授权 + 少量保留」的折中。对使用者而言，好处是快；代价是必须自己读懂许可边界。

5.8 版本链与长期可获取性

数据集当前为 v1（Figshare 27308133.v1）。长期可获取性的几个考量：

Figshare 的持久性：Figshare 为学术数据提供 DOI 与长期托管，优于个人网盘/Google Drive（后者常用于放 checkpoint）。
checkpoint 托管风险：预训练模型放在 Google Drive 直链，存在链接失效风险——若需长期复用，建议下载后自行归档。
代码仓库：GitHub Cimalab-unal/GastroHUN 若归档，需留意是否转为只读。
建议：任何依赖本数据集的生产系统，都应本地留存一份数据快照 + 记录 DOI 版本号，以对冲到原文失效的风险。

§6 评估与基准：三个场景的基线

论文提供三组可复现的基线实验（GitHub README「Main Results」与论文 Fig 5-8 一致）。

6.1 场景 A：图像分类 · 骨干网络横向对比

在 All agreement（四专家全一致） 作为 ground truth、224×224 输入下，多个骨干网络的表现：

骨干网络	分辨率	Macro Precision	Macro Recall	Macro F1
ConvNeXt_Large	224×224	88.83 ± 0.20	88.54 ± 0.23	88.25 ± 0.22
ConvNeXt_Base	224×224	87.96 ± 0.27	87.53 ± 0.28	87.16 ± 0.29
ConvNeXt_Tiny	224×224	87.58 ± 0.25	86.92 ± 0.27	86.79 ± 0.26
ConvNeXt_Small	224×224	87.24 ± 0.27	86.77 ± 0.26	86.47 ± 0.28
ResNet152	224×224	86.30 ± 0.26	85.49 ± 0.27	85.28 ± 0.27

结论直观：ConvNeXt 系列整体优于 ResNet152，规模越大的 ConvNeXt 越好，Macro-F1 从 ResNet152 的 85.28 提升到 ConvNeXt_Large 的 88.25。

6.2 场景 B：图像分类 · 不同共识级别（ConvNeXt_Tiny）

固定 ConvNeXt_Tiny，切换 ground truth 的来源：

策略	标签	Macro F1	策略	标签	Macro F1
Annotator	FG1	82.86 ± 0.30	Consensus	All	86.79 ± 0.26
Annotator	FG2	84.33 ± 0.28	Consensus	Triple	84.97 ± 0.28
Annotator	G1	84.82 ± 0.23	Consensus	FG	87.05 ± 0.21
Annotator	G2	83.53 ± 0.27	Consensus	G	85.66 ± 0.27
Consensus	FG1-G1	85.44 ± 0.28	Consensus	FG2-G1	86.07 ± 0.28
Consensus	FG1-G2	85.94 ± 0.24	Consensus	FG2-G2	85.11 ± 0.27

读法：用多专家共识标签训练/评估，模型分数普遍高于用单标注者（单标注者 82.86–84.82，共识 84.97–87.05）。其中 FG 共识（87.05 ± 0.21）最高，甚至略高于 All（86.79）。

6.3 场景 C：序列分类（GT = FG1-G2 agreement）

序列任务以 FG1-G2 一致 为 ground truth，用 GRU 与 Transformer encoder：

策略	标签	Macro F1	策略	标签	Macro F1
Annotator	FG1	79.52 ± 0.48	Consensus	All	85.14 ± 0.48
Annotator	FG2	77.47 ± 0.44	Consensus	Triple	80.51 ± 0.45
Annotator	G1	80.12 ± 0.39	Consensus	FG	83.33 ± 0.40
Annotator	G2	79.38 ± 0.51	Consensus	G	80.46 ± 0.45
Consensus	FG1-G1	84.81 ± 0.44	Consensus	FG2-G1	82.03 ± 0.48
Consensus	FG1-G2	86.30 ± 0.42	Consensus	FG2-G2	82.00 ± 0.44

序列任务的数字整体略低于图像任务（图像共识最高 87.05 vs 序列最高 86.30），且标准差更大（视频时序的方差天然更高）。同样地，共识标签显著优于单标注者。

6.4 三个场景共同的结论

共识级别是关键超参数：同一模型、同一数据，仅因 ground truth 从单标注者换成多专家共识，Macro-F1 可差 3–6 个百分点。
跨团队共识（FG1-G2）在序列任务上表现最佳，提示「不同资历专家的交集」可能比「同团队一致」更可泛化。
模型-专家 Kappa（Fig 8） 用于比较模型预测与专家标注的一致性层级——模型与专家的分歧结构，与专家之间（FG vs G）的分歧结构可对照阅读。

6.5 场景 D：模型-专家一致性（Fig 8 的读法）

除三个基准场景外，论文还用 Cohen’s Kappa 比较了模型预测与各专家标注的一致性（Fig 8）。这张图的信息量与 F1 表互补：

F1 是「模型 vs ground truth」的绝对性能；
模型-专家 κ 是「模型与某一具体专家有多像」——它回答的问题不是「模型对不对」，而是「模型像哪一类专家」。

从研究设计上看，Fig 8 让模型可以与专家「同桌比较」：图中下三角是专家两两一致性（FG 与 G 之间），对角线是模型与各专家的一致性。若模型-专家 κ 接近专家-专家 κ，说明模型已达到接近人类专家的站位判断水平。

6.6 场景 A/B/C/D 的横向对照读法

把四个场景放在一起，能得到一个「决策树」式的结论：

只选骨干：直接看场景 A。ConvNeXt 系列优于 ResNet，规模越大越好（85.28 → 88.25）。
定标签严格度：看场景 B/C。共识级别比骨干选择更影响结果（差 3–6 点）。
做序列 vs 图像：场景 C vs B。序列整体略低、方差略大，但结论（共识优于单标注者）一致。
评估模型是否「像专家」：看场景 D。κ 反映模型与专家的相似结构，而非单纯准确率。

6.7 复现入口

GitHub 提供 test_image_classification.py、test_sequence_classification.py，以及针对「整序列 / 仅图像目录 / 仅序列中心帧」的两个细分测试脚本（test_WhiteLightImage_classification.py、test_WhiteLightSequence_classification.py）。checkpoint 通过 Google Drive 直链公开，Colab notebook 可一键验证。

6.8 数字的稳定性：bootstrap 置信区间

论文的 F1 数字都带「±」误差（如 88.25±0.22），这是通过 bootstrap 重采样估计的稳定性区间（论文 Fig 5 展示 Macro-F1 排名的 bootstrap 分布，b=100）。它的意义是：

骨干之间的差距（如 ConvNeXt_Large 88.25 vs ConvNeXt_Base 87.16）远大于 ±0.22–0.29 的波动，因此排名可信；
但共识级别之间的某些接近对（如 FG 87.05 vs All 86.79）差距在误差量级附近，不宜过度解读谁「显著」更高。

读这类带区间的基准表时，先看差距是否超过误差，再下结论，是本数据集给出的统计卫生建议。

6.9 复现时需要固定的变量

若要复现或对比 GastroHUN 上的新方法，建议固定以下变量（否则数字不可比）：

共识级别（All / FG / Triple / …）——影响最大；
输入分辨率（基线用 224×224）；
划分（用官方 CSV，患者级隔离）；
评价指标（Macro-F1，而非 micro/accuracy）；
任务粒度（图像 vs 序列；序列还要区分整序列/仅中心帧）。

把这五项写进实验设置，是引用 GastroHUN 结果的基本礼貌。

6.10 参数量与性能的关系（Fig 6）

论文 Fig 6 用气泡图展示 bootstrap Macro-F1 与模型总参数量（含特征提取 + 分类层）的关系。从场景 A 的数据可以还原趋势：

骨干	大致规模档	Macro-F1
ResNet152	大	85.28
ConvNeXt_Small	中	86.47
ConvNeXt_Base	中大	87.16
ConvNeXt_Tiny	小	86.79
ConvNeXt_Large	最大	88.25

一个有意思的现象是 ConvNeXt_Tiny（86.79）略高于 ConvNeXt_Small（86.47）——说明并非「越大越准」的单调关系，架构设计（ConvNeXt 的现代化设计）比单纯堆参数更重要。这对内镜这类「纹理丰富但结构重复」的图像尤其适用：合适的归纳偏置比参数量更关键。

6.11 场景 C 的标准差为什么更大

对比场景 B（图像）与场景 C（序列）的误差项：

图像共识级（如 All）F1 88.25±0.22；序列共识级（如 FG1-G2）86.30±0.42。
序列的 ± 值普遍是图像的近两倍。

原因是视频序列引入了额外方差源：

抽帧/播放的时序抖动：同一站位的 10 秒片段，不同患者的镜头运动速度不同。
关键帧定位误差：序列以中心帧标签为准，但中心帧的标注沿用图像流程，若中心帧本身难判，整条序列的方差被放大。
样本量更小：序列任务患者数 223（vs 图像 387），bootstrap 的抽样波动更大。

因此，序列任务的结果需要更多重复实验才能得到稳定结论，这也是论文用 bootstrap（b=100）估计区间的原因。

6.12 三场景最优结果总表

场景	任务	最优配置	最优 Macro-F1
A	图像分类	ConvNeXt_Large（All GT）	88.25 ± 0.22
B	图像分类	ConvNeXt_Tiny（FG 共识）	87.05 ± 0.21
C	序列分类	共识 FG1-G2	86.30 ± 0.42
D	一致性	模型-专家 κ	见 Fig 8

一句话记忆：图像 > 序列，共识 > 单标注者，大骨干 > 小骨干（但不单调）。

6.13 基准数字的引用规范

若在论文中引用这些数字，建议写成（示例）：

「在 GastroHUN 上，ConvNeXt_Large 以 All agreement 为 ground truth、224×224 输入，取得 Macro-F1 88.25（bootstrap 95% 区间 ±0.22）。」

要点：写明骨干 + 共识口径 + 输入分辨率 + 指标名称 + 区间。缺任一项，数字即不可独立复现。这是本条目反复强调「共识级别是隐性超参数」的落地要求。

§7 生态、互链与影响

7.1 在拉丁美洲内镜 AI 生态中的位置

GastroHUN 的特殊性在于地域：既有的公开内镜数据集（Kvasir、HyperKvasir、GastroVision、ENDOTOKYO 等）多来自欧洲或日本，而 GastroHUN 是哥伦比亚、乃至拉丁美洲首个大型公开上消化道内镜数据集。这为「跨人种/跨中心泛化」研究提供了此前缺失的南美数据点。

7.2 与库内可互链条目

gastrovision（rid 203）：同为消化道内镜图像分类数据集（Kvasir 系谱，含上/下消化道），是最直接的横向对照——可对比类别体系（解剖站位 vs 病变/器官）与地域来源。
gastroendonet（rid 780）：上消化道内镜检测/分类数据集，可作「内镜检测任务」对照。
手术/内镜视频类条目（如 autolaparo、asoca）：可作「视频序列分类/手术视频理解」的方法学横向参照——GastroHUN 的序列任务（GRU/Transformer）与之同属时序建模。
解剖地标识别类条目：GastroHUN 的 22 站位本质是「器官内解剖地标」，可与各类 landmark 数据集互链为「解剖结构化标注」家族。

7.3 数据集留下的方法论遗产

GastroHUN 对后续内镜 AI 研究的三点可迁移贡献：

协议即结构：把 SSS 拍照协议的站位结构直接编码为标签体系，使「检查完整性」可被机器学习量化。
共识即消融：公开 8 级共识标签，把「标签质量」从隐变量变成可做消融实验的显变量。
多层资产：图像（静态）、序列（10 秒时序）、完整视频（全程）三层并存，支持从单帧分类到长时程视频理解的不同粒度研究。

7.4 与其他内镜数据集的定位对比

把 GastroHUN 放进消化道内镜数据集谱系，可以看到一个清晰的分工：

数据集	组织主线	主要任务	地域
Kvasir / HyperKvasir	病变/发现类型	检测、分类	挪威
GastroVision	多类内镜所见	分类/检测	多中心
GastroHUN	解剖站位（SSS 协议）	站位分类、序列分类	哥伦比亚
ENDOTOKYO 类	胃癌/病灶	检出	日本

GastroHUN 的差异化在于：它不标病灶，只标解剖站位。这使它不与胃癌检出数据集竞争，而是补上「内镜检查完整性/站位识别」这一被忽视的环节——因为只有先确认「每个站位都拍到了、且模型能认出这是哪个站位」，后续的病灶检出才能在正确的解剖上下文里进行。

7.5 「本地化」价值：南美与资源有限场景

从应用角度看，GastroHUN 的另一个意义是地域代表性。内镜 AI 模型存在域偏移（domain shift）问题：在欧洲/日本数据上训练的模型，换到南美人群可能性能下降。GastroHUN 提供了一个南美来源的、结构化的公开数据点，可用于：

跨中心泛化实验：在 Kvasir（挪威）训练、GastroHUN（哥伦比亚）测试，量化域偏移。
资源有限场景的可行性研究：装置为相对常见的 Olympus CV-190 + 消费级采集卡，贴近基层内镜室的设备条件，而非顶级研究中心的专用配置。

7.6 与病理诊断信息的潜在扩展空间

Videoendoscopies 目录附带了「内镜所见」与「病理诊断」信息。虽然论文基线未把病理诊断作为预测目标，但这层信息为后续工作留了接口——研究者可在解剖站位分类之上，进一步探索「站位 + 病灶 + 病理」的多层次建模。这使 GastroHUN 不仅是一个分类基准，也是一个可扩展的临床数据结构。

7.7 对胃癌早筛链条的定位

把 GastroHUN 放进「胃癌早筛 AI」的完整链条里看，它占据的是最上游的一环：

[检查完整性/站位识别] → [病灶检出] → [良恶性判别] → [病理分级]
     ↑ GastroHUN 在这里

理由很直接：无论病灶检出模型多强，它都必须先知道「当前画面是胃的哪个部位」，才能结合该部位的解剖先验做判断。GastroHUN 提供的就是这个「解剖定位基础层」。把它与病灶数据集（Kvasir 系等）组合，是构建完整内镜 AI 流水线的合理路径。

7.8 对数据集复用的三种典型场景

综合全文，GastroHUN 的三种典型复用场景是：

站位分类基准：直接复现 §6 的基线，作为新骨干/新方法的对比平台。
域泛化研究：作为「南美来源」的测试集，量化跨中心/跨人群的域偏移。
标注方法论研究：利用 8 级共识与双团队设计，研究标签噪声、软标签、主动学习等课题。

三种场景对应三类读者：模型开发者、泛化研究者、方法论研究者。数据集的「多共识 + 双团队 + 三层资产」设计，恰好同时服务这三类需求。

7.9 局限与改进空间

客观地说，GastroHUN 也有可改进之处（这些不削弱其价值，反而是后续数据集的发力点）：

无病灶标注：站位分类之外不含病变的像素/框级标注，限制了「检出」类任务。
单一中心：数据来自一家医院，跨中心泛化性未经检验（这恰是它作为「域偏移测试集」的价值，但也意味着它本身是单域数据）。
规格异质：双分辨率 + 双来源 + 双压缩，需预处理统一。
类别不均衡：真实临床采集导致各类样本数不均，小类可能欠采样。
人口学缺失：未披露年龄/性别分布，难以做亚组分析（见 FACTS §9 遗留疑点）。

一个理想的「GastroHUN v2」可能会补上病灶标注、多中心采集与人口学元数据——但在现有公开内镜数据集中，它的「协议化 + 多共识 + 三层资产」组合仍属独树一帜。

§8 方法学启示：四条可迁移的经验

8.1 用「拍照协议」把模糊的检查质量变成可计算标签

传统内镜质量评价依赖操作者主观，而 GastroHUN 把 SSS 的 22 个标准站位直接做成类别标签。于是「这台检查拍全了吗」从一句经验判断，变成一个可计算的问题——23 类分类器的混淆矩阵，实际上就是一张「哪几个站位容易漏拍/难分辨」的体检表。这是数据集设计层面最值得借鉴的一点：把临床 SOP 结构化，再喂给模型。

8.2 双团队标注是一次「资历-一致性」的天然对照实验

FG（专科培训医师）与 G（主治医师）的双团队设置，让数据集自带一个资历变量。从场景 B/C 看：G 单人的分数（图像 84.82/83.53）与 FG 单人（82.86/84.33）互有高低，而跨团队共识（FG1-G2）在序列任务上反而最高（86.30）。这提示：标注者的差异不全是「噪声」，跨资历的交集可能携带更稳的信号。设计标注流程时，与其只追求同质标注者一致，不如让异质标注者交叉验证。

8.3 「共识级别」是比模型结构更敏感的超参数

三个场景反复说明同一件事：模型结构变化带来的差异（ResNet152→ConvNeXt_Large 约 3 个点），量级上与「换一套 ground truth」相当。这意味着在医学数据集上做基准比较时，必须先固定共识级别再比模型，否则「模型 A 比 B 好」可能只是 A 恰好用了一套更宽容的标签。

8.4 静态图 + 短序列 + 长视频的三层设计

GastroHUN 把同一批检查拆成三层粒度发布（帧 / 10 秒片段 / 全程视频），这让同一数据可服务三类研究：单帧分类、短时序分类、长时程视频理解。对比只发布单一粒度的数据集，三层并存显著提升了数据的复用面。代价是存储（96.86 GB）与版本管理成本，但这笔账对「一次性发布、长期复用」的公开数据集划算。

8.5 一个被低估的细节：NA 类的诚实

把「看不清」与「有病变」的图像单列为 NA，而非强行归入某站位，是一种对标注诚实性的坚持。它让 23 类分类器不必在模糊样本上「假装」有答案，也让研究者能显式衡量模型在困难样本上的行为。

8.6 「患者级划分」的不可妥协

GastroHUN 的划分表明确按患者隔离（图像 270/58/59 患者，序列 159/32/32 患者）。这一点在医学影像数据集里是硬要求：同一患者的多张图像若跨集分布，会造成数据泄漏（模型记住了这个人的胃，而非学会了站位）。GastroHUN 把它写进划分表，值得所有内镜/影像数据集效仿。复现时尤其注意：不要为了凑样本量而打乱患者边界。

8.7 对数据标注生产的三点借鉴

综合 §4 与 §8，GastroHUN 给「如何组织一次高质量医学标注」的可迁移结论是：

让 SOP 决定标签空间：不是先有图像再想标签，而是先有临床协议（SSS）再把它翻译成标签。
让共识可切换：不给单一 ground truth，而是给多级共识，让下游按需选择严格度。
让异质标注者交叉：双团队（不同资历）设计让「标注者差异」从缺陷变成可研究的信号。

§9 避坑清单：使用 GastroHUN 的八个坑

坑 1：数据集许可与论文许可不是一回事。 论文（Scientific Data）是 CC BY 4.0，但数据集本体的 README 徽章是 CC BY-NC 4.0，且竞赛等用途还需事先书面许可。若把数据集当 CC BY 4.0 用于商业产品会踩线。引用/使用数据集以 CC BY-NC 4.0 为准，引用论文文本以 CC BY 4.0 为准。

现象：同一份材料里出现两个不同的 CC 许可。
原因：期刊论文的许可是期刊惯例（Scientific Data 全刊 OA），与数据集自身的许可独立设定。
处理：在使用数据前跑一遍 §5.5 的合规清单；数据卡中显式写 CC BY-NC 4.0。（双口径存照）

坑 2：「22 landmarks」与「23 类」并存。 论文摘要写「22 anatomical landmarks … plus an additional category for unqualified images」，GitHub 表列出 0-22 共 23 个 ID。二者本质一致（22 站位 + NA = 23 类），但表述不同，检索或自动抽取时容易对不上。

现象：「22」与「23」两个数字都正确，取决于是否把 NA 计入。
处理：本条目统一口径为「23 类 = 22 站位 + NA」；引用检索时同时用两个表述以防漏检。（双口径存照）

坑 3：序列患者数（223）≠ 图像患者数（387），不是矛盾。 序列必须有录像才能提取，部分患者只有静态图像。若在论文里看到两个患者数，不要当成错误。

现象：两个 patients 数值出现在同一数据集的不同任务里。
原因：序列任务的患者集是图像任务患者集的子集（223 ⊂ 387）。
处理：做多任务学习或联合划分时，按患者取两组任务的患者交集，不要混用。（双口径存照）

坑 4：README 的站位标签有拼写笔误。 GitHub 表中站位的 “Incisura（胃角）” 被拼作 “Incusira”；且 ID 9 与 ID 11 都写成 “L3”，其中 ID 11 的解剖区域标为 Middle Upper Body（疑应为 G3 或其它）。

现象：标签表内字母与区域存在不一致。
处理：按解剖学常识校正（本条目附录 A 已注明），勿照抄进论文；若做自动解析，建议对标签做一次人工核对。（源文档笔误存照）

坑 5：别把 Figshare DOI 与论文 DOI 弄混。 数据集是 10.6084/m9.figshare.27308133，论文是 10.1038/s41597-025-04401-5。二者都要引，但用途不同。

处理：BibTeX 分别见附录 D；数据 DOI 带 .v1 版本后缀。

坑 6：直采图与抽帧图混放。 Labeled Images 目录内既有内镜直采 JPG（8053 张），也有视频抽帧 JPG（781 张），质量与压缩不同。

现象：同一目录内两类来源的图像混在一起。
处理：务必用元数据的 source_type 字段分层，否则质量分析会被两类来源混合污染；做分辨率统一时也要分层统计。

坑 7：比较模型时未固定共识级别，结论不可比。 这是最容易被忽视的「隐性坑」。场景 B/C 显示，换共识级别带来的 F1 变化（3–6 点）与换骨干相当。

现象：两篇论文都报「在 GastroHUN 上达到 XX%」，但用的是不同 ground truth。
处理：报告结果时必须注明共识级别（All / FG / Triple / …）与任务粒度（图像/序列/中心帧），否则数字不可比（见 §6.9）。

坑 8：把「站位分类」误当「病灶检测」。 GastroHUN 的标签是胃的解剖站位，不是病变。

现象：想用它训练胃癌检出模型。
处理：明确任务边界——站位分类用本数据集，病灶检测需另找带病变标注的内镜数据集（如 Kvasir 系列）。Videoendoscopies 的病理信息只作扩展线索，不是像素级病变标注。

9.1 八坑汇总表

坑	类型	严重度	处理口径
1 许可双口径	合规	高	数据集按 CC BY-NC 4.0
2 22 vs 23 类	口径	低	统一为 23 类（22 站 + NA）
3 患者数不同	结构	中	223 ⊂ 387，取交集
4 标签拼写笔误	文档	低	按解剖学校正
5 两个 DOI	引用	中	数据与论文分别引
6 直采/抽帧混放	数据	中	按 source_type 分层
7 未固定共识级别	方法	高	报告时注明共识口径
8 站位≠病灶	任务	高	明确任务边界

9.2 每个坑的「一句话对策」

坑 1 → 数据卡写 CC BY-NC 4.0，商业用途另行授权。
坑 2 → 检索时同时用「22 landmarks」与「23 类」。
坑 3 → 联合任务取患者交集。
坑 4 → 标签表人工核对一次。
坑 5 → 两个 DOI 分别引。
坑 6 → 按 source_type 分层。
坑 7 → 实验设置写清共识级别。
坑 8 → 站位任务与病灶任务分开。

关于数字的溯源：本条目全文硬数字（8834/387/4729/223/238/96.86 GB/23 类/分辨率档/分片表/基线 F1）均取自论文正文与表格、以及官方 GitHub README 的结果表；两处双口径（许可、类别数）与两处源文档问题（患者数口径差、标签拼写）已在上文逐条存照。

§10 数据集档案（DAIMS 式速查表）

下表以 DAIMS（Data Management and Sharing）常见维度对 GastroHUN 做一页式档案，便于入库检索与合规核对。

维度	内容
数据集名称	GastroHUN — an Endoscopy Dataset of Complete Systematic Screening Protocol for the Stomach
简称 / slug	gastrohun
领域	医学影像 · 消化道内镜（上消化道/胃）
数据模态	JPG 图像 + MP4 序列 + MP4 视频内镜 + JSON 元数据
规模	8834 图像 / 4729 序列 / 238 视频；96.86 GB
受试者	图像 387 名患者；序列 223 名患者
类别数	23（22 胃解剖站位 + NA）
标注者	四名消化内科专家（FG 团队 2 人 + G 团队 2 人）
标签体系	8 级共识（单标注者 / FG / G / Triple / All / 两两）
采集设备	Olympus EVIS EXCERA III CV-190 + MAJ-1925；Epiphan/Elgato 采集卡
采集期	2019–2023（回顾性）
机构	Universidad Nacional de Colombia（Cimalab/MindLab）+ Hospital Universitario Nacional de Colombia
论文	Scientific Data 2025;12(1):102，doi 10.1038/s41597-025-04401-5，PMID 39824869
数据 DOI	10.6084/m9.figshare.27308133
获取方式	Figshare 公开
许可	CC BY-NC 4.0（数据集）；竞赛用途需书面许可；论文 CC BY 4.0
基线任务	图像分类（23 类）、序列分类（23 类）
最优基线 F1	图像 88.25（ConvNeXt_Large，All GT）；序列 86.30（FG1-G2 GT）
代码仓库	github.com/Cimalab-unal/GastroHUN
发布时点	2025-01-17 见刊

任务-资产-标签对照

任务	输入资产	输出标签	划分（患者/样本）	基线
图像分类	Labeled Images（8834 张）	23 类站位	270/58/59 患者；6165/1316/803 图	ConvNeXt_Large 88.25
序列分类	Labeled Sequences（4729 条）	23 类站位	159/32/32 患者；3401/654/394 序列	共识 FG1-G2 86.30

一致性统计一览

统计量	用途	论文位置
Cohen’s Kappa	两两专家组间 + 单专家跨时间组内	Fig 3
Fleiss’ Kappa	多专家在患者子集内的整体一致性	Fig 4
模型-专家 Kappa	模型预测与各专家标注的一致性	Fig 8
混淆矩阵	23 类（22 站位 + NA）分类	Fig 7

论文图表明细（可复现索引）

图/表	内容	本条目引用
Fig 1	SSS 胃拍照协议示意（前向+反转视角站位）	§3.2
Fig 2	各解剖类别图像分布（按标注者与共识级别）	§2.6、§4.2
Fig 3	Cohen’s κ 矩阵（组间 + 组内时序）	§4.4、§4.7
Fig 4	Fleiss’ κ 箱线图（按患者集）	§4.4
Fig 5	Macro-F1 排名 bootstrap 分布（b=100）	§6.8
Fig 6	气泡图：bootstrap Macro-F1 vs 参数量	§6.1
Fig 7	23 类混淆矩阵	§4.8、§6.6
Fig 8	模型-专家 Cohen’s κ	§6.5
Table 2	数据集记录总览（含 387 患者）	§2
Table 3	图像/序列元数据列说明	§2.2、附录 B
Table 5	图像/序列分类划分（患者/样本）	§5.3、§10
Table 7	训练模型与共识口径	§6.2

论文正文-表格数字漂移核查

本条目在整理时逐项比对了论文正文与表格、以及 GitHub README 的结果表，未发现正文与表格之间的数字冲突（这一点与部分数据集不同）。唯一需要区分的是：

论文摘要用「22 anatomical landmarks + NA」描述类别；
GitHub README 表列 0-22 共 23 个 ID。

二者本质一致（22 + 1 = 23），不是数字矛盾而是表述口径差，已在 §9 坑 2 存照。

数字来源矩阵（三源互证）

硬数字	论文	GitHub README	Figshare/其他	结论
8834 图像 / 387 患者	✓	✓	—	三源一致
4729 序列 / 223 患者	✓	✓	—	三源一致
238 视频内镜	—	✓	—	README 口径
96.86 GB	✓	—	—	论文口径
23 类（22+NA）	✓（22+NA）	✓（0-22）	—	口径一致
CC BY-NC 4.0	—	✓	—	README 徽章
论文 CC BY 4.0	✓	—	—	期刊惯例
基线 F1（场景 A/B/C）	✓	✓	—	二源一致

10.1 数据卡（Datasheet 风格）

参照 Datasheets for Datasets 的常见问项，给出一页式回答：

动机

目的：为胃镜 AI 提供标准化、公开、多共识的上消化道内镜数据。
资助/创建方：Universidad Nacional de Colombia 研究组 + 大学医院。

构成

实例：单张图像 / 10 秒序列 / 完整视频。
总量：8834 图 + 4729 序列 + 238 视频。
类别：23（22 站位 + NA）。
划分：患者级，见 §5.3。

收集过程

来源：真实临床检查（回顾性，2019–2023）。
采样：按 SSS 协议站位拍照，非随机采样。
去标识：手工删除标识符与体外帧。

预处理

直采图像：设备默认压缩（1/5–1/10）。
序列：ffmpeg 切片（15 fps，libx264，yuv420p）。

用途

适用：站位分类、序列分类、域泛化、标注方法学研究。
不适用：病灶检测（无病变标注）。

分发

渠道：Figshare（DOI 27308133）。
许可：CC BY-NC 4.0（竞赛另需许可）。

维护

联系：Diego Bravo（dbravoh@unal.edu.co）。
版本：v1。

§11 附录与引用

附录 A：23 类标签全表

ID	标签	解剖区域	ID	标签	解剖区域
0	A1	胃窦（Antrum）	12	A4	胃底贲门（Fundus Cardia）
1	L1	胃窦	13	L4	胃底贲门
2	P1	胃窦	14	P4	胃底贲门
3	G1	胃窦	15	G4	胃底贲门
4	A2	下胃体（Lower Body）	16	A5	中上胃体（Middle Upper Body）
5	L2	下胃体	17	L5	中上胃体
6	P2	下胃体	18	P5	中上胃体
7	G2	下胃体	19	A6	胃角（Incisura）
8	A3	中上胃体	20	L6	胃角
9	L3	中上胃体	21	P6	胃角
10	P3	中上胃体	22	NA	其他/不合格（OTHERCLASS）
11	L3	中上胃体

注：上表 ID 11 在官方 README 中亦标为 “L3”，与 ID 9 重复（见 §9 坑 4）；字母含义 L=小弯、A=前壁、G=大弯、P=后壁。

附录 B：三个元数据 JSON 的用途

文件	绑定内容
`gastrohun-image-metadata.json`	图像文件名 → 标签（四专家 + 8 级共识）+ `source_type`（直采/抽帧）
`gastrohun-sequence-metadata.json`	序列名 → 标签 + 患者号 + 帧号 + 序列帧范围 + 来源视频内镜名
`gastrohun-videoendoscopy-metadata.json`	视频内镜 → 内镜所见 + 病理诊断关联

附录 C：复现路径速查

目标	做法
快速验证	Colab 打开 `run_example.ipynb`
复现场景 A/B/C	`Prediction_Stability_and_Performance_ScenarioABC.ipynb`（含 bootstrap 置信区间）
图像分类测试	`test_image_classification.py`
序列分类测试	`test_sequence_classification.py`（整序列）/ `test_WhiteLightImage_classification.py`（仅图像目录）/ `test_WhiteLightSequence_classification.py`（仅序列中心帧）
下载 checkpoint	GitHub README「Download Trained models」表内 Google Drive 直链

附录 D：检索与引用建议

精确检索词：GastroHUN（唯一标识）+ gastric endoscopy / systematic screening protocol；勿与 GastroVision、GastroEndoNet 混淆（后者为库内不同条目）。
引用数据集（BibTeX）：

@article{BRAVO2025,
  author = "Diego Bravo and Martin Gomez and Juan Frias and Carlos Martinez and Felipe Vera Polania and Fabio A. Gonzalez and Eduardo Romero and Juan Naranjo",
  title  = "{GastroHUN an Endoscopy Dataset of Complete Systematic Screening Protocol for the Stomach}",
  year   = "2025",
  month  = "1",
  url    = "https://springernature.figshare.com/articles/dataset/GastroHUN_an_Endoscopy_Dataset_of_Complete_Systematic_Screening_Protocol_for_the_Stomach/27308133",
  doi    = "10.6084/m9.figshare.27308133.v1"
}

引用论文（BibTeX）：

@article{bravo2025gastrohun,
  title   = {GastroHUN an Endoscopy Dataset of Complete Systematic Screening Protocol for the Stomach},
  author  = {Bravo, Diego and Frias, Juan and Vera, Felipe and Trejos, Juan and Mart{\'\i}nez, Carlos and G{\'o}mez, Mart{\'\i}n and Gonz{\'a}lez, Fabio and Romero, Eduardo},
  journal = {Scientific Data},
  volume  = {12},
  number  = {1},
  pages   = {102},
  year    = {2025},
  publisher = {Nature Publishing Group UK London}
}

附录 E：机构与人员速查

机构：Universidad Nacional de Colombia（哥伦比亚国立大学）Cimalab 与 MindLab 研究组；Hospital Universitario Nacional de Colombia（哥伦比亚国立大学医院）消化内科。
标注团队：FG Team A（FG1、FG2，Fellow Gastroenterologist）+ G Team B（G1、G2，Gastroenterologist）；采集监督由五名消化内科医师轮值。
通讯作者：Diego Bravo（dbravoh@unal.edu.co）。

附录 F：本条目维护触发点

触发点	动作
数据集发布新版本（v2+）	更新本条目规模/许可/版本链
论文补充患者人口学（年龄/性别）	补全 §2、§5，更新患者标签
Figshare 下载量/文件清单可直取	补全 FACTS §9 遗留疑点
第三方在 GastroHUN 上报告新基准	更新 §6、§7 生态
许可变更（如转为 CC BY）	修订 §5、§9 坑 1

附录 G：与库内条目的互链锚点

互链条目	rid	关联点
gastrovision	203	消化道内镜图像分类，横向对照（类别体系/地域）
gastroendonet	780	上消化道内镜检测/分类

附录 H：一句话总结

GastroHUN 用 SSS 协议把胃镜检查「标准化」，用四专家多级共识把「标签可信度」显式化，以 8834 图 + 4729 序列 + 238 视频的规模，成为拉丁美洲首个大型公开上消化道内镜数据集——使用前请认准 CC BY-NC 4.0 的数据集许可，而非其 CC BY 4.0 的论文许可。

附录 I：术语中英对照

中文	英文 / 缩写	含义
上消化道内镜	upper GI endoscopy	食管-胃-十二指肠内镜检查
胃镜	gastroscopy	胃部内镜检查
系统筛查协议	SSS（Systematic Screening protocol for the Stomach）	胃部标准化拍照协议
解剖站位	anatomical landmark / station	协议规定的标准拍照位置
胃窦	antrum	胃的远端部分
胃体	gastric body	胃的主体部分
胃底贲门	fundus / cardia	胃的近端与食管交界区
胃角	incisura	胃小弯的角状结构
小弯/前壁/大弯/后壁	L / A / G / P	四象限方位
前向视角	anterograde view	内镜直行视角
反转视角	retroflex view	内镜回勾视角
消化内科专科培训医师	Fellow Gastroenterologist (FG)	完成住院医后的亚专科培训阶段
消化内科主治医师	Gastroenterologist (G)	独立执业的专科医师
科恩卡帕	Cohen’s Kappa	两评估者间一致性统计
弗莱斯卡帕	Fleiss’ Kappa	多评估者间一致性统计
宏平均	Macro average	各类指标不加权平均

附录 J：数据验收清单（拿到数据后建议逐项核对）

[ ] 三个目录（Labeled Images / Labeled Sequences / Videoendoscopies）文件数与论文一致（8834 / 4729 / 238）。
[ ] 三份 JSON 元数据可解析，字段含标签与患者号。
[ ] 图像总数 8834，其中 source_type=direct 约 8053、source_type=video_frame 约 781。
[ ] 分辨率分布约 1080×1350 占 91.16%、720×900 占 8.84%。
[ ] 划分 CSV 的患者数与论文 Table 5 一致（图像 270/58/59，序列 159/32/32）。
[ ] 序列 MP4 可正常解码（yuv420p / 15 fps）。
[ ] 23 类标签齐全（0-22），NA 类存在。
[ ] 患者级划分无跨集泄漏（同一 patient_number 不出现在两个划分中）。

附录 K：常见问题（FAQ）

Q：GastroHUN 能用来做胃癌检测吗？
A：数据集的主任务是解剖站位分类，不直接标注癌/非癌。但它附带的 Videoendoscopies 含内镜所见与病理诊断信息，可作为扩展基础；直接用 23 类标签做胃癌检出是不对的。

Q：为什么类别里有个 NA？
A：当目标站位不可辨识或存在病变时归 NA，避免污染站位分类。但注意 NA 内部混合了「看不清」与「有病灶」两种情形（§4.3）。

Q：可以直接用于商业产品吗？
A：不行，除非另行取得授权。数据集为 CC BY-NC 4.0，非商业性使用（§5.2）。

Q：图像和序列的患者数为什么不一样？
A：序列必须有录像才能切，部分患者无录像。223 是 387 的子集（§2.5）。

Q：复现基线要下多少数据？
A：若只做图像分类，下 Labeled Images 即可；序列任务再下 Labeled Sequences；视频内镜体积最大，非必需（§5.4）。

Q：模型结果差很多，是哪里出问题？
A：先检查用的是哪套 ground truth。共识级别不同，Macro-F1 可差 3–6 个点（§6.4）。固定共识级别再比模型。

附录 L：完整时间线

时间	事件	来源
2019–2023	临床数据回顾性采集期	论文
2024-08-24	投稿 Scientific Data；数据集仅对审稿人开放	GitHub News
2024-09-25	收到审稿人与编辑意见	GitHub News
2024-10-25	提交修订稿	GitHub News
2025-01-02	论文被接收	GitHub News
2025-01-17	论文见刊（2025;12(1):102）	GitHub News
2025-01（同期）	数据集经 Figshare 正式公开	Figshare
2026-10-08	本条目抓取与整理时点	本条目

附录 M：与库内 GastroVision / GastroEndoNet 的详细对比

维度	GastroHUN	gastrovision（rid 203）	gastroendonet（rid 780）
组织主线	胃解剖站位（SSS 协议）	内镜所见/多类	内镜检测/分类
覆盖部位	上消化道（胃）	消化道（含上下）	上消化道
主要任务	站位分类、序列分类	分类/检测	检测/分类
地域	哥伦比亚	多中心	—
数据形态	图+序列+视频三层	图像为主	图像/视频
许可	CC BY-NC 4.0	见该条目	见该条目
互链价值	站位 vs 病灶的分工对照	内镜大类横向	上消化道纵向

引用建议：做「消化道内镜数据集综述」时，把三者按「标注对象（站位/所见/病灶）」这条轴并列，能清楚展示内镜数据集的三种设计哲学。

附录 N：消化道内镜/视频数据集景观（简表）

数据集	地区	规模特征	标签对象	获取
GastroHUN	哥伦比亚	8834 图 + 4729 序列 + 238 视频	22 站位 + NA	Figshare（CC BY-NC 4.0）
Kvasir / HyperKvasir	挪威	图像/视频量级大	病变/解剖	公开
GastroVision	多中心	多类内镜所见	所见类别	公开
手术视频类条目（库内）	多	腹腔镜等	器械/阶段	见各条目

本表为条目内对照用途，具体数字以各数据集官方口径为准；库内条目详见 §7.2 与附录 G。

附录 O：给论文作者的引用落地建议

若想在论文中引用 GastroHUN，建议：

引用两处：数据集 DOI（Figshare 27308133）+ 论文 DOI（s41597-025-04401-5）。
声明许可：在数据使用声明中写「GastroHUN 采用 CC BY-NC 4.0，本研究为非商业学术用途」。
注明共识口径：报告结果时写清 ground truth 级别（如「以 All agreement 为准」）。
注明任务粒度：图像/序列，序列还需注明是否只取中心帧。
复现声明：如用了官方 checkpoint，注明 checkpoint 的共识口径与骨干。

附录 P：本条目的事实锚点（供质检核对）

事实	值	出处
论文 DOI	10.1038/s41597-025-04401-5	Nature
PMID	39824869	PubMed
数据 DOI	10.6084/m9.figshare.27308133	GitHub README
论文卷期	2025;12(1):102	BibTeX
图像/患者	8834 / 387	论文 + README
序列/患者	4729 / 223	论文 + README
视频内镜	238	README
容量	96.86 GB	论文
类别	23（22 + NA）	论文 + README
划分（图）	270/58/59 患者	Table 5
划分（序）	159/32/32 患者	Table 5
图像基线	88.25（ConvNeXt_Large）	论文 + README
序列基线	86.30（FG1-G2）	论文 + README
许可	CC BY-NC 4.0	README

附录 Q：本条目与其他 AI-Ready 条目的写法对照

本条目在写法上遵循千方病案医数集的通用范式，与库内同类条目的一致性体现在：

九节 FACTS + 五 part 成稿：事实档案与百科成稿分离，事实可追溯。
双口径存照：凡遇源文档冲突（许可、类别数、患者数），逐条存照而非择一。
三源互证：硬数字须至少两至三个独立来源一致才录入。
不臆造数字：论文图（Fig 3/4）未逐格转录的 κ 值，正文不列具体数字，只描述结构。

这套写法对内镜/影像类数据集尤其重要，因为这类数据的「规格异质性」与「许可边界」是最容易被概述性介绍掩盖的部分。

附录 R：给不同读者的快速入口

你是……	先读	再读
想快速判断能否用	§1 十问十答	§5 获取与许可
想复现基线	§6 评估与基准	§5.3 划分表 + 附录 C
关心标注质量	§4 标注体系	§8 方法学启示
做域泛化研究	§7.5 本地化价值	§7.9 局限
写综述	附录 N 景观表	§7.4 定位对比
做合规审查	§5.2 许可 + §5.5 清单	§9 坑 1
质检本条目	FACTS.md	附录 P 事实锚点

附录 S：源文档问题存照（供后续修订对照）

问题	位置	本条目处理
数据集 CC BY-NC 4.0 vs 论文 CC BY 4.0	README vs 期刊	分别标注，数据集用 NC
竞赛用途需书面许可	README 正文	§5.2 收录
22 landmarks vs 23 类	论文摘要 vs README 表	统一为 23 类
患者数 387 vs 223	论文两任务	说明 223 ⊂ 387
“Incusira” 拼写	README 表	附录 A 校正为 Incisura
ID 9 与 ID 11 均标 L3	README 表	附录 A 注明
患者人口学未披露	全篇	FACTS §9 遗留疑点
Figshare 文件清单未直取	—	FACTS §9 遗留疑点

附录 T：条文快速检索表

想找……	去
规模数字	§2.2–2.4、§10
23 类标签	§2.6、附录 A
SSS 协议	§3.1–3.2
采集设备	§3.3
标注团队	§4.1
8 级共识	§4.2、§4.12
κ 统计	§4.4、§4.7
许可	§5.2、§5.5、§9 坑 1
划分表	§5.3
基线 F1	§6、§6.12
与库内对比	§7.2、附录 M
互链锚点	§7.2、附录 G
避坑	§9
术语	附录 I
引用格式	附录 D
事实锚点	附录 P

本条目由千方病案医数集（AI-Ready Wikipedia）编辑，抓取与整理时点 2026-10-08；所有事实以论文、官方 GitHub 与 Figshare 公开信息为准，双口径与源文档问题已逐条存照。