信息速览

数据集名称RareBench — 大语言模型罕见病诊断能力评测基准

数据类型真实世界数据,临床文本,人工标注,知识图谱

规模1,197 例公开患者（RAMEDIS 624 / MME 40 / HMS 88 / LIRICAL 370 / PUMCH_ADM 75）；PUMCH 内部总盘 1,650 例仅公开 75 例；T

接入方式五大罕见病公开/临床数据源：RAMEDIS（欧洲，624 例）、MME（加拿大，40 例）、HMS（德国，88 例）、LIRICAL（多国，370 例）、PUMCH_ADM（北京协和医院，75 例）；表型以 HPO 编码、诊断以 OMIM/Orphanet/CCRD 编码；附 HPO 表型映射、疾病映射、IC 值表与 256 维表型嵌入

AI 就绪度

RareBench (rarebench) — 大语言模型罕见病诊断能力评测基准

INFOBOX

项目	内容
数据集名称	RareBench（Can LLMs Serve as Rare Diseases Specialists?）
发布方	清华大学 / 北京协和医院（PUMCH）团队
发布时间	arXiv 2024-02-09（v1）｜KDD '24 正式出版 2024-08
数据规模	1,197 例公开患者病例（五大子集）
任务维度	4 大任务：表型提取 / 特定罕见病筛查 / 比较分析 / 通用鉴别诊断
疾病编码	HPO（表型）+ OMIM / Orphanet / CCRD（诊断）
数据模态	文本（临床表型描述 + 结构化编码）
许可协议	Apache-2.0
获取方式	HuggingFace `chenxz/RareBench` + GitHub `chenxz1111/RareBench`（公开直链）
论文	KDD 2024, pages 4850–4861, DOI 10.1145/3637528.3671576
语言	英文（HF 标注 language: en）
核心结论	GPT-4 top-1 52.0% vs 资深专科医师 44.7%；动态少样本 top-1 召回平均 +108%
AI-Ready 评级	★★★★☆（公开直链、结构清晰、许可宽松；扣分项：PUMCH 内部数据不可得、无独立版本号）

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

罕见病（rare disease）是一类典型的「长尾医学难题」：单病种患者稀少，但全球累计患者超过 3 亿人。罕见病诊断的困难不在于医生「没见过病」，而在于两大结构性障碍——一是缺乏经验丰富的专科医生，二是需要在数千种表型相互重叠的罕见病之间做鉴别。结果是罕见病患者常经历多年误诊、辗转多科才获确诊。

2023 年以来，诸如「ChatGPT 在 17 位医生失败后正确诊断一名 4 岁儿童的罕见病」这类新闻，让大语言模型（Large Language Model，LLM）在罕见病诊断中的潜力受到关注。然而这种「个案传奇」无法回答一个严肃问题：LLM 在罕见病诊断上的真实能力究竟几何？ 当时已有的医学评测基准（如 USMLE 类考试题）主要衡量通用医学知识，而罕见病诊断恰恰要求精准的表型抽取与在超过 7,000 种疾病的重叠搜索空间中导航的能力——这两点通用基准完全测不到。

RareBench 填补的正是这一空白。 它不是又一份医学问答题库，而是首个系统性评估 LLM 罕见病诊断能力的基准框架，同时配套发布了迄今规模最大的开源罕见病患者数据集。它的设计有三个要点：

四维任务框架：把「LLM 当罕见病专家」这件抽象的事，拆解为四个可测量的真实临床步骤（表型提取 → 特定病筛查 → 常见病/罕见病比较 → 全谱鉴别诊断）。
最大开源患者数据：整合 RAMEDIS、MME、HMS、LIRICAL 四个公开数据集与北京协和医院（PUMCH）临床数据，公开 1,197 例带确诊的罕见病病例。
知识增强提示法：用 HPO/OMIM/Orphanet/CCRD 四库合成罕见病知识图谱，以「信息量（Information Content，IC）」为核心设计动态少样本提示，把 LLM 的 top-1 召回平均拉高 108%。

对「千方病案医数集」的读者而言，RareBench 的价值在于：它是医疗 LLM 评测谱系中少见的「罕见病专项」，与库内的通用医疗评测（HealthBench、MedAgentBench）形成「通用 vs 长尾」的对照轴，同时其知识图谱方法（HPO + IC）可与库内罕见病本体条目（Orphanet-ORDO）互链。

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

Q1：RareBench 是什么？
一个评测基准（benchmark），用于系统性评估大语言模型在罕见病四大诊断任务上的能力；同时是一份开源罕见病患者数据集。

Q2：数据从哪来？
五个来源：RAMEDIS（欧洲患者登记）、MME（Matchmaker Exchange，加拿大）、HMS（德国）、LIRICAL（多国）、PUMCH_ADM（中国北京协和医院）。前四个为公开数据集，第五个为临床数据脱敏公开。

Q3：一共多少病例？
公开 1,197 例：RAMEDIS 624 + MME 40 + HMS 88 + LIRICAL 370 + PUMCH_ADM 75。

Q4：为什么是这四个任务？
因为这四个任务对应真实罕见病诊断流程的四步：读病历提取症状（Task 1）→ 对特定病筛查（Task 2）→ 判断是常见病还是罕见病（Task 3）→ 在全部罕见病中做鉴别（Task 4）。

Q5：数据长什么样？
每条样本含：Phenotype（HPO 表型代码列表）、RareDisease（OMIM/Orphanet/CCRD 诊断代码列表）、Department（就诊科室，仅 PUMCH_ADM 子集）。

Q6：许可协议是什么？
Apache-2.0——宽松开源许可，允许商用与再分发（需保留版权声明）。

Q7：怎么获取？
load_dataset('chenxz/RareBench', 'RAMEDIS', split='test')（HuggingFace datasets 库）；GitHub chenxz1111/RareBench 提供评测代码。

Q8：核心结论是什么？
GPT-4 在 75 例头对头病例中 top-1 准确率 52.0%，超过资深专科医师的 44.7%；动态少样本提示使六个模型的 top-1 召回平均提升 108%。

Q9：它的局限是什么？
PUMCH 内部 1,650 例仅公开 75 例；表型标准化是 LLM 的主要瓶颈（端到端 F1 约 25%）；公共子集地理偏西方；对否定性表型识别差。

Q10：它和被广泛使用的医学考试基准有什么不同？
医学考试基准测「知识记忆」，RareBench 测「临床推理 + 编码标准化 + 长尾鉴别」，且输入形态是模拟真实 EHR 的患者表型集合，而非选择题题干。

§2 数据构成与规格

2.1 规模、来源与机构构成

RareBench 的数据集分为两组：四个公开数据集与 PUMCH 临床数据集。官方 README 给出的权威统计表如下：

数据集	RAMEDIS	MME	HMS	LIRICAL	PUMCH_ADM
国家/地区	Europe	Canada	Germany	Multi-Country	China
#病例数	624	40	88	370	75
#疾病数	74	17	39	252	16
#科室数	N/A	N/A	N/A	N/A	5
每病病例数·最小	1	1	1	1	3
每病病例数·中位	2	1	1	1	5
每病病例数·最大	82	11	11	19	8
每例 HPO·最小	3	3	5	3	3
每例 HPO·中位	9	10.5	17.5	11	16
每例 HPO·最大	46	26	54	95	47

五个子集合计 1,197 例。其中四个公共子集合计 1,122 例、覆盖 362 种罕见病（论文 §3.2）；PUMCH_ADM 子集 75 例覆盖 16 种病、5 个科室。

来源机构背景：

RAMEDIS（Rationale for a Rare Disease Information System）：德国比勒费尔德大学（Bielefeld）维护的罕见病登记系统，欧洲患者数据。
MME（Matchmaker Exchange / mme-apis）：GA4GH 基因型-表型匹配平台，属加拿大方向数据。
HMS：德国罕见病相关数据集。
LIRICAL（Likelihood Ratio Inference for Clinical Assessment）：美国杰克逊实验室（The Jackson Laboratory）开发的罕见病诊断工具及其配套数据，多国来源。
PUMCH_ADM：北京协和医院（Peking Union Medical College Hospital）真实临床电子健康记录，经脱敏与医生核验后公开 75 例。

2.2 任务-数据映射关系

并非所有数据都用于全部四个任务。论文明确说明：

公共数据集（RAMEDIS/MME/HMS/LIRICAL）：仅提供「表型/症状 + 已确诊罕见病（OMIM/Orphanet 编码）」，因此只能用于 Task 4 通用鉴别诊断。
PUMCH 临床 EHR：因为有完整病历叙述，既可用于表型提取（Task 1），也可用于三个诊断任务（Task 2/3/4）。

这一映射关系决定了 RareBench 的一个关键特征：你无法仅凭四个公共子集复现全部四任务的评测——Task 1（表型提取）与 Task 2（筛查）依赖 PUMCH 形态的完整 EHR，而公开版本只有 75 例。

2.3 数据字段规格

HuggingFace 数据集卡片给出的字段格式为：

{
    "Phenotype": "The list of phenotypes presented in HPO codes",
    "RareDisease": "The list of rare diseases code including OMIM, Orphanet and CCRD format",
    "Department": "(Optional) Only provided in PUMCH_ADM"
}

Phenotype：HPO（Human Phenotype Ontology，人类表型本体）代码列表。HPO 是描述人类表型异常的标准本体，每个术语对应一个稳定的 HP 编号（如 HP:0001250 表示「癫痫」）。
RareDisease：诊断代码列表，跨 OMIM（Online Mendelian Inheritance in Man，在线人类孟德尔遗传数据库）、Orphanet、CCRD（Chinese Catalogue of Rare Diseases，中国罕见病目录）三套体系。
Department：就诊科室，仅 PUMCH_ADM 子集提供，共 5 个科室。

2.4 配套映射与嵌入文件

GitHub 与 HF 仓库的 mapping/ 目录提供四个辅助文件，是复现知识增强方法的关键：

文件	内容	用途
`phenotype_mapping.json`	HPO 表型代码 → 术语名	将 HP 编号翻译为可读表型
`disease_mapping.json`	OMIM/Orphanet/CCRD 代码 → 病名	将诊断代码翻译为病名
`ic_dict.json`	HPO 术语的信息量（IC）值	衡量表型特异性（类 IDF）
`phe2embedding.json`	HPO 表型的 256 维嵌入向量	基于 IC 随机游走学习所得

这些文件共同支撑了「动态少样本提示」——见 §4。

2.5 数据清洗与隐私处理

论文与数据卡片披露了两条数据处理规则：

质量过滤：应用合理的过滤标准，剔除因记录错误或信息缺失导致的低质量病例——包括诊断不确定/不精确者，以及「相关表型少于 3 项」者。这解释了为何每例 HPO 术语数的最小值统一为 3。
隐私保护：PUMCH 医生在上传文本信息之前逐例监控审查，确保不存在任何个人隐私信息泄露（“ensuring the absence of any personal information leaks”）。

2.6 规模口径辨析（重要）

读者在检索时应留意三组不同的数字，它们对应不同口径：

1,197：公开可下载的病例总数（五子集合计）。
1,122 / 362：四个公共子集的病例数 / 疾病数。
2,185 / 421：Task 4 评估所用的病例数 / 疾病数——这是公共 + PUMCH 合并的评测盘，包含了未公开的 PUMCH 内部数据，因此大于可下载的 1,197。
1,650：PUMCH 医院内部的罕见病病例总盘，仅公开其中 75 例。

下文所有硬数字均标注口径，读者引用时务必区分「可下载」与「论文评测盘」。

2.7 五个子集的数据特征画像

为便于使用者选型，下表给出各子集的「性格」——它们并非同质数据的简单拼接，而是来自不同卫生体系、不同病例收集方式的异源数据：

子集	收集方式	数据「性格」	典型使用场景
RAMEDIS	欧洲医师在线登记上报	病例最多（624）、单病样本最厚（最多 82 例/病），疾病数仅 74	需要「每病多例」做统计的子集
MME	国际基因型-表型匹配平台	病例少（40）但疾病谱广（17），每病中位仅 1 例	极长尾、单例罕见病的极限测试
HMS	德国队列	每例表型最丰富（中位 17.5、最多 54 个 HPO）	表型密集、信息饱和的病例推理
LIRICAL	诊断工具配套数据（多国）	疾病数最多（252），表型跨度最大（最多 95 个 HPO/例）	疾病类别极多、表型极长的压力测试
PUMCH_ADM	北京协和医院真实 EHR	含科室字段（5 科）、有完整病历叙述、每病最少 3 例	Task 1/2/3 唯一可用子集

选型建议：

想研究「表型密集病例的推理」→ 用 HMS（中位 17.5 个表型）。
想研究「超多疾病类别下的鉴别」→ 用 LIRICAL（252 病）。
想研究「完整临床流程（含表型提取）」→ 只能用 PUMCH_ADM（但只有 75 例）。
想做「跨子集泛化」研究 → 五子集全用，但必须处理疾病编码体系的差异。

2.8 数据的地理与人群分布

RareBench 的数据分布高度偏向欧美：四个公共子集分别来自欧洲（RAMEDIS）、加拿大（MME）、德国（HMS）与多国（LIRICAL），中国数据（PUMCH_ADM）仅占 75 / 1,197 ≈ 6.3%。

这一分布带来两个使用警示：

人群遗传背景偏置：罕见病中有大量遗传病，不同人群的致病基因频率与表型谱存在差异。以欧美人群为主的病例，未必能代表中国患者（如某些东亚高发的罕见病可能缺失）。
医疗体系差异：四个公共子集的「就诊科室」（Department）字段多为 N/A，唯独中国 PUMCH 提供了科室信息——这反映了不同数据源的记录习惯差异，也意味着跨子集的「科室」维度不可直接比较。

2.9 数据规模对照：在医学 LLM 基准中的位置

把 RareBench 放进更大的医学 LLM 评测版图中，其规模属中等：

基准	规模	定位
MedQA/USMLE 类	万题级	通用医学知识
RareBench	1,197 例（可下载）	罕见病专项
HealthBench	数千对话	开放式临床对话
MedAgentBench	百级任务	医疗 agent 能力

RareBench 的规模不算「大」，但这恰恰体现了罕见病数据的稀缺性——它是同类开源资源中最大者，这一点本身即为其价值所在。规模不是它的卖点，「罕见病 + 四维任务 + 知识图谱」的组合才是。

2.10 数据样例示意（教学用）

以下为示意性样本结构（字段名与格式取自官方数据卡片，具体编码值仅为说明用途，非真实病例）：

{
  "Phenotype": [
    "HP:0001250",   // Seizure 癫痫
    "HP:0001249",   // Intellectual disability 智力障碍
    "HP:0001263"    // Global developmental delay 全面发育迟缓
  ],
  "RareDisease": [
    "OMIM:300672",  // 示意：某 X 连锁遗传病
    "ORPHA:998"     // 示意：Orphanet 编码
  ],
  "Department": "Neurology"  // 仅 PUMCH_ADM 提供
}

读法要点：

Phenotype 是HPO 术语代码列表，中位约 9–17 个/例，最多达 95 个。
RareDisease 是诊断代码列表，可含多体系编码。
Department 为可选字段，反映就诊科室（仅 PUMCH_ADM）。

把这段结构交给 LLM 时，必须先经 mapping 翻译——否则模型看到的是「HP:0001250」这样的裸代码，无法理解其临床含义。这一点在 §10 坑 6 已有强调。

2.11 子集加载的常见问题

问题	原因	解法
`load_dataset` 报 config 不存在	子集名大小写/拼写错	用官方五名：RAMEDIS/MME/HMS/LIRICAL/PUMCH_ADM
网页端看不到数据表	卡片设 `viewer: false`	改用 Python 代码加载
内网无法访问 HF	网络限制	配置镜像端点（如 hf-mirror）
想读原始 zip	需要离线包	从 HF 仓库下载 `data.zip` 等
分不清哪些数据属于哪个任务	未看任务-数据映射	参见 §2.2

2.12 一句话记住 RareBench

四个来源的公开罕见病病例 + 一个中国医院的真实病例 = 最大的开源罕见病患者数据集；用四任务框架评测 LLM 的「读病历 → 查线索 → 分常见罕见 → 全谱鉴别」能力；靠 HPO 知识图谱 + 信息量少样本把性能拉高。

至此，数据构成部分结束。下一节进入四大任务的技术细节。

§3 四大任务详解：从病历到诊断的四步

RareBench 的核心设计是把「LLM 当罕见病专家」分解为四个渐进任务。论文明确指出，这四个任务反映了罕见病的真实诊断过程。理解它们是理解整个基准的关键。

3.1 Task 1：从电子健康记录中提取表型

任务定义：从非结构化的电子健康记录（Electronic Health Record，EHR）中提取标准化的表型。

这是最基础的一步：如果连患者症状都无法准确读出并转成标准术语，后续诊断无从谈起。该任务被进一步拆为三个子任务：

(a) 表型提取（Phenotype Extraction）：直接从 EHR 中抽取精确的表型表述。
(b) 通用实体提取（General Entity Extraction）：抽取一般性临床实体（如症状、体征、检查项的通俗表述）。
© 通用实体标准化（General Entity Standardization）：把上一步抽出的通俗实体标准化为 HPO 术语。

论文将 (b) 与 © 视为表型提取的两步分解，用于更细致地定位 LLM 的能力短板。核心发现：LLM 在「找症状」（实体抽取）上尚可，但在「把通俗症状标准化为正式医学术语」（HPO 标准化）上明显吃力——这被论文认定为主要瓶颈，导致端到端表型提取的 F1 仅约 25%。

临床意义：这意味着当前 LLM 若直接接入医院信息系统做自动编码，其产出的 HPO 代码质量远不足以支撑下游诊断，必须先经人工或专用 NLP 预处理。

3.2 Task 2：特定罕见病筛查

任务定义：评估 LLM 识别特定罕见病相关风险因素或症状的能力。

任务利用患者的病史与辅助检查，判断是否存在指向某一特定罕见病的线索，以便推动进一步诊断。论文选定三种罕见病作为筛查对象：

ALS（Amyotrophic Lateral Sclerosis，肌萎缩侧索硬化，俗称「渐冻症」）
PNH（Paroxysmal Nocturnal Hemoglobinuria，阵发性睡眠性血红蛋白尿）
MSA（Multiple System Atrophy，多系统萎缩）

为什么选这三病？ 它们都是有明确诊断线索、但早期极易被漏诊/误诊的罕见病。筛查任务不等同于确诊，而是「从海量就诊记录中找出值得进一步查的病人」——这正是罕见病诊断漏斗的第一道关。

3.3 Task 3：常见病与罕见病的比较分析

任务定义：验证 LLM 能否区分表型/症状相似的常见病与罕见病患者。

这是模拟临床中最常见的混淆场景：病人的症状既可能是常见病，也可能是某种罕见病。数据来自 PUMCH 数据集，具体构成：

527 份电子健康记录（EHR）
其中 60 例 / 13 种罕见病
其中 467 例 / 64 种常见病
疾病池共 77 种（13 罕见 + 64 常见）
LLM 任务：基于患者 EHR，从 77 种疾病池中预测最可能的十种疾病（top-10）

设计意涵：罕见病人数（60）远少于常见病（467），这模拟了真实的患病率先验。一个只会「偏向常见病」的模型会得到高常见病命中率但低罕见病召回；真正的能力体现在不因罕见而漏诊。

3.4 Task 4：通用罕见病鉴别诊断

任务定义：在整个已知罕见病谱系中做系统性鉴别诊断，找出最可能的罕见病。

与 Task 3 不同，Task 4 不限定疾病范围——LLM 必须仅凭患者表型/症状，对全部已知罕见病给出最可能的十种诊断（top-10）。这是 RareBench 中最具挑战性、也是最具前瞻性的任务。规模：

2,185 例患者病例
覆盖 421 种罕见病
数据来自公共数据集与 PUMCH 数据集合并

核心结果：GPT-4 在 Task 4 上的中位排名为 5.0（即在数百种候选病中，正确答案平均排在第 5 位）——表现可圈可点，但与临床可用的「第一位即正确」仍有距离。

3.6 为什么是「四」个任务：一个能力金字塔

RareBench 的四任务不是随意罗列，而构成一个能力金字塔——下层任务的失败会传导到上层：

        Task 4 通用鉴别诊断（421 病，最难，综合能力）
              ↑ 依赖
        Task 3 罕见/常见病比较（77 病，鉴别能力）
              ↑ 依赖
        Task 2 特定罕见病筛查（3 病，线索识别）
              ↑ 依赖
        Task 1 表型提取（HPO 标准化，基础能力）

金字塔逻辑：Task 1 是地基（把病历读成标准表型）；Task 2 是筛查漏斗（从海量就诊中找可疑）；Task 3 是「常见 vs 罕见」的分流阀；Task 4 是终极考验（全谱鉴别）。

这一设计的精妙之处在于：它能把「模型为什么不行」定位到具体层。论文发现 Task 1 的标准化瓶颈（F1 ~25%）是全局短板——即便 Task 4 的推理逻辑再强，输入表型若是错的，诊断也必然错。这正是「垃圾进垃圾出」在临床推理中的体现。

3.7 与真实临床流程的对应

把四任务映射到真实门诊场景：

患者就诊，医生读病历 → Task 1：从 EHR 提取症状体征。
医生判断「需要进一步查罕见病吗」 → Task 2：针对特定病的线索筛查。
医生权衡「更可能是常见病还是罕见病」 → Task 3：比较分析。
医生在鉴别诊断中列出候选 → Task 4：罕见病鉴别诊断。

RareBench 的设计者显然有意让基准贴近真实临床路径，而非构造人造任务——这也是它被临床 AI 研究者接受的原因之一。

§4 知识增强方法：信息量驱动的动态少样本提示

RareBench 在「数据集 + 基准」之外，第二个核心贡献是一套知识整合动态少样本提示策略（Knowledge Integration Dynamic Few-shot Prompting）。这是它区别于普通评测集的关键技术点。

4.1 动机：为什么普通少样本不够用

常规少样本提示（few-shot）是随机或固定地挑几个示例塞进 prompt。但对罕见病鉴别诊断，随机示例几乎无用——因为关键在于检索到「表型模式最相近」的病例作为参考。罕见病诊断的本质是：某些高度特异的表型（如某种特殊的皮疹、某类异常指标）才是锁定诊断的钥匙，而「发热」「乏力」这类常见表型几乎没有区分度。

4.2 知识图谱合成

作者整合四大学术知识库，合成了一个全面的罕见病知识图谱：

HPO（Human Phenotype Ontology，人类表型本体）
OMIM（Online Mendelian Inheritance in Man）
Orphanet
CCRD（Chinese Catalogue of Rare Diseases，中国罕见病目录）

该图谱建立了「表型 ↔ 疾病」的关联网络，是后续表征学习的基础。

4.3 信息量（IC）：给表型「称重」

方法引入 Information Content（IC，信息量） 值，概念上类似 NLP 中的 IDF（逆文档频率）——衡量某个表型的特异性。一个表型在越多疾病中出现，其 IC 越低（区分度弱）；出现得越少，IC 越高（区分度强）。

直觉上：「发热」IC 低（到处都有），而某种特异的「角膜 K-F 环」IC 高（只在极少数病出现）。RareBench 用 IC 给表型加权，让罕见而特异的症状在推理中占更大权重。

4.4 基于 IC 的随机游走与 256 维嵌入

作者设计了基于 IC 的随机游走算法（IC-based Random Walk）：

当随机游走在表型之间移动时，偏置由目标表型的 IC 决定——倾向于探索高特异性的表型。
当从表型过渡到疾病时，偏置反映源表型的 IC。

通过这一过程，为每个 HPO 表型学习出 256 维嵌入向量（即 phe2embedding.json）。患者的病例则由其表型集合（经 IC 加权）的嵌入表示。

4.5 动态少样本的实际效果

对每个查询病例，系统基于嵌入检索数据集中最相似的病例，作为 LLM prompt 中的 few-shot 示例——相当于为模型提供「量身定制的临床经验」。

量化增益：动态 3-shot 策略使 6 个不同 LLM 的 top-1 召回平均提升 108%，相比标准零样本（zero-shot）有大幅改进。更值得注意的是，小模型受益更明显：GLM4、Llama2-7B 等开源小模型经动态少样本增强后，有时能接近 GPT-4 的零样本水平。

4.6 方法学启示

这一方法传达了一个可迁移的经验：在长尾医学领域，「给对示例」比「模型多大」更关键。通过知识图谱 + IC 加权检索，可以让小模型在特定任务上逼近大模型——这对资源受限的临床部署场景尤其有价值。

4.7 与检索增强生成（RAG）的关系

RareBench 的动态少样本提示，本质上是检索增强生成（Retrieval-Augmented Generation，RAG）在罕见病诊断上的特化：

维度	通用 RAG	RareBench 动态少样本
检索库	通用文档/网页	罕见病知识图谱 + 病例库
相似度度量	通用嵌入余弦相似	IC 加权的表型嵌入
注入方式	上下文文档	few-shot 示例病例
领域知识	无结构化先验	HPO/OMIM/Orphanet/CCRD 图谱

差异点在于「IC 加权」——通用 RAG 用稠密向量相似度，对所有特征一视同仁；RareBench 则用信息量让高特异表型主导检索。这相当于在检索阶段就注入了医学上的「鉴别诊断直觉」：罕见的、特异的症状才是关键线索。

可迁移性：这一「领域知识加权检索」思路可推广到其他长尾医学任务（如超罕见肿瘤分型、罕见遗传代谢病），也可与向量数据库（如 FAISS）结合工程化。

§5 核心实验结果

5.1 GPT-4 vs 人类专家：头对头比较

论文最具传播力的结果，是在 75 例高质量病例上的头对头比较：

方法	top-1 准确率
GPT-4	52.0%
资深专科医师（可借助外部检索工具）	44.7%

GPT-4 的 52.0% 超过了资深专科医师的 44.7%。 这一结果被媒体广泛引用，但需谨慎解读：医师在真实临床中拥有体格检查、影像、检验等 LLM 无法获取的信息；此处的比较是在仅有表型文本的条件下的推理能力对比，不代表 LLM 已可替代医生。

5.2 各任务表现速览

任务	代表性结果
Task 1 表型提取	所有模型端到端 F1 约 25%；实体抽取尚可，HPO 标准化是瓶颈
Task 2 筛查	三病（ALS/PNH/MSA）风险线索识别能力评估
Task 3 比较分析	77 病池 top-10 预测，考察罕见/常见病区分
Task 4 鉴别诊断	GPT-4 中位排名 5.0（数百候选病中）

5.3 提示策略的增益

动态 3-shot vs 零样本：6 个 LLM 的 top-1 召回平均 +108%。
小模型（GLM4、Llama2-7B）经增强后有时接近 GPT-4 零样本水平。
说明「知识增强的检索示例」是提升罕见病诊断性能的高性价比手段。

5.4 论文自述的局限

作者坦诚列出若干障碍：

输入敏感性问题：LLM 仍难以正确处理否定性表型（如「无发热」——模型可能误读为「有发热」）与复杂描述性症状（如「爬三层楼后气短」需推理为运动耐量下降）。
数据模态限制：当前 LLM 主要处理文本，无法纳入影像、基因等模态，而真实罕见病诊断常依赖多模态证据。

这两点也是后续研究的重要方向。

5.5 结果解读的四条守则

引用 RareBench 数字时，请遵守以下守则以避免误读：

口径优先：任何数字都要问「是哪个子集/哪个评测盘」。52.0% 是 75 例子集，5.0 是 Task 4 的 2,185 例盘，25% 是 Task 1 全模型——三组数字不可混用。
条件限定：GPT-4 vs 医师的对比是仅凭表型文本的推理比较，非综合临床能力对比。
均值陷阱：各子集每病病例数极不均衡（中位仅 1），「平均性能」会被少数高频病主导，应同时看分层结果。
时效性：2024 年的结果针对当时的 GPT-4；后续模型能力已大幅变化，且存在预训练污染风险，不宜将 52.0% 当作当前 LLM 的天花板。

§6 获取与许可：门怎么进

6.1 三条获取路径

RareBench 的获取门槛很低，走公开直链，无需申请或签署数据使用协议：

HuggingFace 数据集（主渠道）：https://huggingface.co/datasets/chenxz/RareBench
- 使用 datasets 库一行加载：load_dataset('chenxz/RareBench', 'RAMEDIS', split='test')
- 五个子集名：RAMEDIS、MME、HMS、LIRICAL、PUMCH_ADM
- 注意：数据集卡片标注 viewer: false，即 HF 网页端不提供在线预览器，必须用代码加载。
GitHub 仓库：https://github.com/chenxz1111/RareBench
- 提供评测代码（含 API 与本地 LLM 两套路径）、mapping/ 映射文件、prompt_comparison_results.zip。
- API 模型配置：将 OpenAI key 放入 llm_utils/gpt_key.txt、Gemini key 放 gemini_key.txt、智谱 key 放 glm_key.txt。
- 本地模型配置：修改 mapping/local_llm_path.json 为本机模型路径。
arXiv 论文：https://arxiv.org/abs/2402.06341（PDF 同页可得）

6.2 仓库文件清单（实测）

HF 仓库 main 分支的文件树（通过 tree API 实测）为：

文件	大小	说明
`README.md`	4,550 B	数据集卡片
`RareBench.py`	2,694 B	HuggingFace datasets 加载脚本
`mapping/`	目录	映射文件（见表下）
`Task1_in_RareBench.zip`	22,812 B	Task 1 相关数据
`data.zip`	32,441 B	主体数据包
`prompt_comparison_results.zip`	2,163,729 B	提示对比实验结果
`.gitattributes`	2,438 B	git 配置

mapping/ 目录含：phenotype_mapping.json、disease_mapping.json、ic_dict.json、phe2embedding.json（详见 §2.4）。

6.3 许可协议：Apache-2.0

RareBench 的数据集以 Apache-2.0 许可发布，这一结论有三源互证：

HuggingFace 数据集卡片的 YAML 头：license: apache-2.0
HuggingFace API 的 tags：license:apache-2.0
HF 卡片 JSON 的 cardData.license：apache-2.0

Apache-2.0 意味着什么：

✅ 允许商业使用、修改、再分发
✅ 允许闭源集成（无 copyleft 传染）
⚠️ 需保留版权声明与许可声明
⚠️ 需标注修改内容
⚠️ 不含专利授权之外的明示保证（“AS IS”）

边界提醒：Apache-2.0 覆盖的是数据集本身。论文本体（KDD '24 出版版）版权归 ACM，其文本使用受 ACM 政策约束。此外，PUMCH 子集虽以 Apache-2.0 发布，但源于真实临床数据，使用者应关注医疗数据伦理与再识别风险（尽管论文声明已脱敏）。

6.4 HF 元数据与社区活跃度

指标	数值（核验时点 2026-10-16）
创建时间	2024-03-05
最后修改	2024-12-12
下载量	622
点赞数	14
规模类别	`1K<n<10K`
任务类别	`question-answering`
语言	`en`（英文）
标签	`medical`

解读：下载量 622、点赞 14，属中等偏学术的活跃度——它不是那种被疯狂下载的通用大集，但在罕见病 LLM 研究方向是被反复引用的参考基准（KDD 论文被引已近百次）。

6.5 与被引/前作的关系

数据来源致谢：RAMEDIS（Bielefeld 登记系统）、MME（ga4gh/mme-apis）、LIRICAL（TheJacksonLaboratory/LIRICAL）、PhenoBrain（xiaohaomao/timgroup_disease_diagnosis）。
同域方法对比对象（论文引用）：Phen2Disease、Xrare、Phen2Gene、EHR-Phenolyzer、Phenomizer、RDAD、RDD、MinIC 等——这些是非 LLM 的传统罕见病诊断方法，RareBench 的 LLM 结果与它们形成新老对照。

6.6 获取实操：三步走

第一步：装环境

pip install datasets

第二步：加载数据

from datasets import load_dataset

# 五个子集名任选
for subset in ["RAMEDIS", "MME", "HMS", "LIRICAL", "PUMCH_ADM"]:
    data = load_dataset('chenxz/RareBench', subset, split='test')
    print(subset, len(data))

第三步：翻译编码

import json

# 先从 GitHub 下载 mapping/ 目录
with open('mapping/phenotype_mapping.json') as f:
    phe_map = json.load(f)          # HPO 代码 -> 术语名
with open('mapping/disease_mapping.json') as f:
    dis_map = json.load(f)          # OMIM/Orphanet/CCRD -> 病名

# 把样本中的编码翻译为可读文本
sample = data[0]
phenotypes = [phe_map.get(code, code) for code in sample["Phenotype"]]
diagnoses  = [dis_map.get(code, code) for code in sample["RareDisease"]]

注意事项：

沙箱/内网环境访问 HuggingFace 主站受限时可配置镜像（如 HF_ENDPOINT=https://hf-mirror.com）。
split='test' 是官方推荐用法；数据卡片的 config 为 default。

6.7 许可合规的实操要点

即便 Apache-2.0 宽松，用于临床或商业时仍建议：

保留声明：在衍生产品中包含 Apache-2.0 许可文本与原始版权声明。
标注修改：若对数据做了清洗/映射/重标注，需在文档中显著标注。
伦理审查：因含真实患者数据（PUMCH），用于敏感场景前建议做内部伦理评估。
再识别防范：避免将数据与外部可识别信息关联，防止 re-identification。
论文引用：学术使用时按 BibTeX 引用 KDD '24 论文。

官方 BibTeX（来自仓库 README）：

@inproceedings{chen2024rarebench,
  title={RareBench: Can LLMs Serve as Rare Diseases Specialists?},
  author={Chen, Xuanzhong and Mao, Xiaohao and Guo, Qihan and Wang, Lun and Zhang, Shuyang and Chen, Ting},
  booktitle={Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining},
  pages={4850--4861},
  year={2024}
}

§7 生态与影响

7.1 在罕见病数据集景观中的位置

罕见病数据资源分三类，RareBench 横跨其中两类：

本体/知识库类：Orphanet（ORDO）、HPO、OMIM——描述「疾病与表型长什么样」。
患者病例类：RAMEDIS、MME、LIRICAL 等——描述「真实病人数据」。RareBench 整合了这类并补充 PUMCH 数据。
诊断工具类：LIRICAL、Phen2Gene、Exomiser 等——做诊断的算法。RareBench 提供了评测这些（及其 LLM 后继者）的统一标尺。

RareBench 的独特定位在于：它是首个把「LLM 罕见病诊断」变成可量化基准的工作，同时提供了最大规模的开源罕见病患者数据集。

7.2 学术影响

KDD 2024 ADS Track（Applied Data Science Track）录用，pages 4850–4861——KDD 是数据挖掘顶会，ADS Track 侧重应用价值，契合 RareBench 的临床落点。
论文被引增长（据 Google Scholar，核验时点约 86 次引用，2025-2026 增长明显），说明其对后续「医疗 LLM 长尾能力评测」方向的启发。
传播层面，GPT-4 52.0% vs 医师 44.7% 的结论被媒体广泛引用，成为「LLM 医疗能力」公共讨论的典型例证。

7.3 对医疗 LLM 评测谱系的贡献

RareBench 提出了一条与通用医学基准（USMLE/MedQA 类）正交的评测轴：

评测轴	代表基准	测什么
通用医学知识	MedQA、USMLE	知识记忆与选择题推理
临床对话/多轮	HealthBench	开放式医疗对话质量
医疗 agent	MedAgentBench	工具调用与任务完成
罕见病长尾	RareBench	表型编码 + 长尾鉴别诊断

这条「长尾轴」的价值在于：它测的是通用基准的系统性盲区。一个在 MedQA 拿高分的模型，完全可能在 Task 4 的 421 病鉴别中表现平平——因为罕见病考的不是知识量，而是从稀疏表型中做精确检索与推理的能力。

7.4 局限与改进空间

不可复现的评测盘：Task 4 的 2,185 例含 1,650 例 PUMCH 内部数据中的一部分，公开者仅 75 例——外部研究者无法完全复现论文的 Task 4 数字。
英文中心：数据标注为 language: en，虽有中国数据但已英文化，对中文临床场景的评测迁移性存疑。
无独立版本号：HF 与 GitHub 均为单一 main 分支，缺少 formal release（如 v1.0/v1.1），影响引用时的可复现性。
静态基准：随 LLM 迭代，存在数据污染/训练集泄漏风险——模型可能在预训练中见过这些公开病例。

7.5 对临床 AI 落地的启示

RareBench 的结果对「把 LLM 用于罕见病辅助诊断」给出了审慎乐观的判断：

乐观面：

GPT-4 在仅凭表型的条件下已能超过资深医师，说明 LLM 具备相当的「鉴别诊断推理」潜力。
知识增强（IC 检索）能显著提升性能，且对小模型尤其有效，降低了部署门槛。
罕见病是「医生经验稀缺」的领域，正是 AI 最能发挥「知识平权」价值之处。

审慎面：

表型标准化 F1 仅 25%，意味着不能直接把 LLM 接入医院编码流程。
否定性表型与复杂描述处理差，是临床安全的隐患（漏掉「无发热」可能导致错误诊断）。
评测条件（仅文本）与真实临床（多模态、可追问）有别，实验结果不可直接外推。

务实路径：把 LLM 定位为「鉴别诊断的候选生成器」（给出 top-10 供医生参考），而非「自动诊断器」——这正是 RareBench 用 top-10 而非单答案评测的深意。

7.6 后续研究方向

基于 RareBench 的局限，可预见的研究方向：

多模态扩展：纳入影像、基因、检验数据，逼近真实诊断证据链。
中文罕见病基准：填补中文临床场景的评测空白。
抗污染评测：设计动态/私有测试集，防止预训练泄漏。
表型标准化专用模型：针对 Task 1 的 25% 瓶颈做专项优化。
否定性表型处理：攻克临床安全的这一关键弱点。
与临床工作流集成：研究 LLM 候选如何在真实门诊中辅助医生决策。

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

8.1 「知识图谱 + 信息量检索」是可复制范式

RareBench 用 IC 加权的知识图谱检索来挑选 few-shot 示例，把「示例质量」变成一个可计算的问题。这一思路可迁移到任何长尾、类别极多、样本稀少的医学领域（如超罕见肿瘤亚型、遗传代谢病）。

可复制要点：

构建领域本体图谱（表型↔疾病、症状↔诊断）；
用类 IDF 的权重衡量特征特异性；
基于加权嵌入做相似病例检索；
把检索结果作为动态 few-shot 注入 prompt。

8.2 「编码标准化」是被低估的瓶颈

论文最重要的负面发现是：LLM 会读症状，但不会准确编码。端到端表型提取 F1 仅 ~25%，症结在「通俗表述 → HPO 术语」的标准化环节。

实践建议：任何把 LLM 接入临床编码流程的方案，都应把「标准化»作为独立环节专门优化（如外挂 HPO 映射表、专用 NER + 术语归一化模型），而非指望通用 LLM 端到端搞定。

8.3 小模型的「检索增强」红利

动态少样本对小模型（GLM4、Llama2-7B）增益尤为显著，有时可逼近大模型零样本水平。这意味着在隐私敏感、需要本地部署的医院场景中，用「小模型 + 高质量检索示例」可能比「大模型 + 零样本」更务实——既不外泄数据，又能接近可用性能。

8.4 评测设计的启示：先验偏置要显式建模

Task 3 刻意设置罕见病（60）远少于常见病（467）的分布，逼迫模型面对真实患病率先验。好的医学评测不应回避类别不平衡，而应把不平衡本身作为考点——因为临床漏诊恰恰源于「罕见病先验太低」。

8.5 对「医疗 AI 评测方法论」的三点贡献

RareBench 不止贡献了一个数据集，它对如何评测医疗 AI 本身也提出了方法论层面的贡献：

贡献一：任务分解代替单一分数。 传统医学基准只给一个准确率，RareBench 把「诊断能力」拆成四层，使失败点可定位。这一「能力金字塔」思路可推广到其他复杂临床任务（如急救决策、慢病管理）。

贡献二：知识注入的度量。 通过 IC 加权，把「示例质量」从主观判断变成可计算指标。这为「检索增强」类方法提供了可复现的评测框架。

贡献三：口径透明。 论文与数据卡片明确区分了「公开数据」与「内部评测盘」，并声明数据处理与隐私措施。这种透明度值得其他医疗数据集借鉴——尽管它也让「不可完全复现」成为公开的已知局限。

8.6 与「临床决策支持系统（CDSS）」传统的关系

RareBench 的 LLM 诊断，与经典临床决策支持系统（Clinical Decision Support System，CDSS）形成代际对照：

维度	经典 CDSS	RareBench 式 LLM
知识来源	人工编码规则/概率模型	预训练语料 + 知识图谱检索
表型输入	结构化（医生手工录入）	非结构化文本（LLM 自动提取）
输出	概率排序	自然语言 + top-10 候选
泛化性	局限于已编码疾病	覆盖全部罕见病谱系
可解释性	规则透明	弱（黑箱）
瓶颈	知识维护成本高	表型标准化准确率低

互补点：经典 CDSS 在「结构化输入 + 概率推理」上稳健且可解释；LLM 在「非结构化文本理解 + 全谱泛化」上更强。RareBench 的价值之一，正是用统一基准量化了 LLM 相对传统方法在哪一环节强、哪一环节弱——例如 LLM 胜在筛选与鉴别推理，败在表型编码标准化（这本是 CDSS 的强项）。

§9 与库内条目的关系

9.1 家族图谱：RareBench 在千方病案库中的位置

RareBench 在「千方病案医数集」中扮演 「罕见病 × 医疗 LLM 评测」交叉点的角色，与库内条目存在三条互链轴线。

轴线一：医疗 LLM 评测基准族（横向对照）

库内条目	rid	关系
`healthbench`	1063	OpenAI 通用医疗健康 LLM 评测——通用 vs 长尾对照轴的一端
`medagentbench`	1064	医疗 agent 能力评测——测「工具使用」而非「知识推理」
`meds-ins`	1093	医学指令数据——同属医疗 LLM 训练/评测生态
`xmedbench`	727	跨语言医学 LLM 评测——与 RareBench 的英文中心形成语言维度对照
`multimedbench`	129	多模态医学评测——RareBench 仅文本，模态维度互补

互链价值：这一族构成「医疗 LLM 能力坐标系」，RareBench 是其中唯一的罕见病专项，检索者可沿此轴做「通用能力 vs 长尾能力」的横向对比。

轴线二：罕见病资源族（纵向深入）

库内条目	rid	关系
`orphanet-ordo`	812	Orphanet 罕见病本体（ORDO）——RareBench 知识图谱的来源库之一，强互链
`rare25`	777	⚠️ Barrett 食管内镜数据集，名字含 rare 但非同域，勿误链

轴线三：知识图谱/表型方向

primekg（rid=831，任务头提示）——知识图谱条目，与 RareBench 的 HPO/OMIM/Orphanet/CCRD 合成图谱方法论同属「生物医学知识图谱」族，可互链。

9.2 检索路径建议

想了解罕见病诊断 LLM 基准 → 本条目（RareBench）
想了解罕见病本体/编码体系 → orphanet-ordo(812)
想看通用医疗 LLM 评测 → healthbench(1063)
想看医疗 agent 评测 → medagentbench(1064)
想看多模态医学评测对照 → multimedbench(129)

9.3 消歧说明（重要）

RareBench ≠ rare25：rare25 是 Barrett 食管内镜影像数据集（MICCAI 2025 Challenge），虽名字含「rare」但与罕见病诊断无关，检索时勿混淆。
RareBench ≠ Orphanet-ORDO：后者是本体/知识库（描述疾病），RareBench 是评测基准 + 患者病例集（评测能力），前者是后者的一个数据来源，二者互补而非重复。
RareBench ≠ HealthBench/MedAgentBench：后两者是通用医疗评测，RareBench 是罕见病专项，评测轴正交。

9.4 组合使用建议

RareBench 与库内条目可组合出多种研究视角：

研究问题	组合方式
通用医疗能力 vs 长尾罕见病能力是否有相关性？	RareBench + `healthbench`(1063)
LLM 的「知识」与「工具使用」能力是否分离？	RareBench + `medagentbench`(1064)
跨语言医学评测的差异有多大？	RareBench + `xmedbench`(727)
文本 vs 多模态医学评测的鸿沟？	RareBench + `multimedbench`(129)
知识图谱驱动的诊断如何评测？	RareBench + `orphanet-ordo`(812)（同源）

9.5 在千方病案医数集中的标签归属

RareBench 的 category_tags 归属：

L1 层：医学问答与基准（主类）、电子健康记录
L2 层：临床文本（医疗NLP 下）、知识图谱、评测基准（医学问答与基准下）
DISEASE 层：罕见病

这一标签组合决定了它在互链算法中的邻居：既连向「医疗 NLP/临床文本」族，也连向「罕见病」疾病族，形成跨类桥接。

§10 避坑清单：十个已踩过/易踩的坑

以下坑点基于对数据集规格、论文口径与许可条款的一手核验整理，供使用者避雷。

坑 1：把「1,197」当成论文评测盘

RareBench 公开可下载 1,197 例，但论文 Task 4 的评测盘是 2,185 例 / 421 病——后者含 PUMCH 内部未公开数据。引用论文数字时须注明口径，否则会得到「论文用 2,185 例却只开源 1,197 例」的困惑。同理，PUMCH 内部总盘 1,650 例仅公开 75 例。

坑 2：以为四个公共子集能跑全部四任务

公共子集（RAMEDIS/MME/HMS/LIRICAL，合计 1,122 例）只能用于 Task 4。Task 1（表型提取）与 Task 2（筛查）依赖 PUMCH 形态的完整 EHR，而公开版只有 75 例。想复现 Task 1/2 评测的，数据根本不够。

坑 3：忽略 `viewer: false`

HF 数据集卡片标注 viewer: false，网页端不提供在线预览。习惯在 HF 网页点开看的用户会找不到数据表，必须用 datasets 库代码加载。

坑 4：把 task_categories=question-answering 当成「它就是选择题」

HF 标签是 question-answering，但 RareBench 的输入是患者表型集合/EHR，输出是诊断排序列表，不是传统 QA。按选择题思路调用会错配。

坑 5：误以为 Apache-2.0 覆盖论文文本

Apache-2.0 只覆盖数据集。论文（KDD '24 出版版）版权归 ACM，文本复用须遵守 ACM 政策。引用论文图表时不要想当然套用数据集许可。

坑 6：直接照搬 HPO 代码而不做映射

数据里的 Phenotype 是 HPO 代码（如 HP:0001250），RareDisease 是 OMIM/Orphanet/CCRD 混合代码。直接丢给模型读代码无意义，必须用 mapping/phenotype_mapping.json 和 mapping/disease_mapping.json 翻译。且诊断代码混用三套体系，需做 ID 归一化才能跨子集比较。

坑 7：忽视「每病病例数」极不均衡

RAMEDIS 单病最多 82 例，而 MME/HMS/LIRICAL 的每病中位数均为 1。做分类或统计时若不处理这种长尾（多数病仅 1-2 例），会得到误导性的「平均性能」——少数高频病主导了指标。

坑 8：把 GPT-4 52.0% > 医师 44.7% 读成「LLM 已超越医生」

该比较是仅凭表型文本的条件下的推理对比。真实临床中医生有体格检查、影像、检验、追问病史等 LLM 不具备的信息。切勿将实验结论外推为「LLM 可替代医生做罕见病诊断」——这是该结果最常被误读之处。

坑 9：以为数据是纯中文（因含 PUMCH）

PUMCH 是中国数据，但 HF 标注 language: en，数据集以英文形态发布。中文临床场景使用者需注意迁移损失。

坑 10：忽略「否定性表型」的表达陷阱

论文明确指出 LLM 处理否定性表型（如「无发热」）与复杂描述性症状（如「爬三层楼后气短」）时易出错。构建 prompt 或做评测时若忽略这一点，会把模型的系统性弱点误判为随机噪声。

§10.5 深挖：三个最容易致命的误用

误用一：把 RareBench 当训练集直接微调

RareBench 是评测基准，不是训练集设计用途。若将其公开病例用于微调，会污染评测（模型见过测试集），导致性能虚高。正确做法：用其他罕见病数据训练，用 RareBench 做独立评测；或明确标注「评测集已用于训练」的局限。

误用二：忽略疾病编码的三体系混用

RareDisease 字段混合了 OMIM（6 位数字，如 105400）、Orphanet（ORPHA:xxxx）、CCRD（中国目录编号）三套编码。直接按字符串去重或统计，会把同一疾病的不同体系编码当成不同疾病：

# 错误：把同一病的三种编码当作三种病
len(set(all_disease_codes))  # 虚高

# 正确：先用 disease_mapping.json 归一化到统一体系

后果：疾病数统计错误（如把 421 病算成更多）、跨子集合并时出现伪重复。

误用三：用「平均排名」掩盖长尾失败

Task 4 的中位排名 5.0 看起来不错，但平均/中位排名会掩盖少数疾病的灾难性失败。若某类罕见病（如表型极不特异的病）排名常在百名开外，中位排名仍可能漂亮。正确做法：看分层结果——按疾病、按表型数、按子集分层报告。

§10.6 数据使用检查清单

使用 RareBench 前，逐项确认：

[ ] 我清楚用的是哪个子集，以及它的病例/疾病数。
[ ] 我没把 1,197（可下载）与 2,185（论文评测盘）混淆。
[ ] 我用 phenotype_mapping.json 翻译了 HPO 代码。
[ ] 我用 disease_mapping.json 做了疾病编码归一化。
[ ] 我处理了每病病例数极不均衡的长尾问题。
[ ] 我没把这批公开病例用于训练（避免评测污染）。
[ ] 我保留了 Apache-2.0 声明。
[ ] 我注意了 PUMCH 数据的脱敏与伦理边界。
[ ] 我引用论文时用了官方 BibTeX。

§10.7 常见错误排查表

症状	可能原因	排查方向
模型输出看不懂的代码	未翻译 HPO/OMIM 编码	加载 mapping 文件
疾病数统计异常大	三体系编码未归一化	用 disease_mapping 统一
平均性能虚高	少数高频病主导	做分层统计
复现不出论文数字	用了可下载 1,197 而非 2,185 盘	确认口径
HF 网页打不开数据	viewer=false	用 datasets 库加载
加载报错	子集名拼错	用 RAMEDIS/MME/HMS/LIRICAL/PUMCH_ADM

§11 DAIMS 评估

DAIMS（Data and AI Maturity/Readiness Scoring）从六个维度评估数据集对 AI 应用的成熟度与就绪度。RareBench 评分如下：

维度	权重	评分	说明
D — Data Availability（数据可获取性）	20%	9/10	HF 与 GitHub 双公开直链，一行代码加载；扣分因 PUMCH 内部数据不可得
A — Annotation Quality（标注质量）	20%	9/10	诊断经临床确诊，表型为标准 HPO 编码，PUMCH 医生逐例核验；扣分因跨库编码需归一化
I — Interoperability（互操作性）	15%	9/10	采用 HPO/OMIM/Orphanet/CCRD 国际标准本体，附完整映射文件
M — Methodology（方法论成熟度）	15%	9/10	四任务框架 + IC 知识图谱动态少样本，方法严谨，KDD 顶会认证
S — Scalability（可扩展性）	15%	7/10	规模适中（1,197 例），框架可扩展但无版本化 release，扩展需自力更生
C — Compliance（合规性）	15%	8/10	Apache-2.0 宽松许可 + 明确脱敏声明；扣分因 PUMCH 临床数据的伦理敏感性与再识别风险

加权总分：8.55 / 10（★★★★☆）

总评：RareBench 是罕见病 LLM 评测领域方法成熟、许可宽松、结构规范的标杆数据集。其得分短板集中在规模与版本化（无独立 release、PUMCH 数据不可得）与临床数据合规（真实患者数据的敏感性）两方面。对于研究罕见病诊断 LLM、评测长尾医学能力的团队，它属高就绪度可直接使用；对于需要大规模、可完全复现训练数据的场景，则需注意 1,197 例的规模上限与 2,185 评估盘的不可得性。

11.1 使用建议速查

你的需求	建议
评测 LLM 罕见病鉴别诊断能力	✅ 直接用 Task 4 数据（1,197 例公开）
复现论文 Task 1/2 表型提取与筛查	⚠️ 公开数据仅 75 例，难以完整复现
研究知识图谱 + 少样本提示策略	✅ 直接用 `mapping/` + `phe2embedding.json`
构建中文罕见病诊断系统	⚠️ 数据为英文，需注意迁移
商业集成（闭源）	✅ Apache-2.0 允许（保留声明）

§12 FAQ 高频问答

A. 基础认知

A1：RareBench 是什么类型的资源？
一个评测基准（benchmark）+ 开源数据集。评测 LLM 的罕见病诊断能力，同时发布 1,197 例罕见病患者病例。

A2：它和 MedQA、USMLE 类基准有什么本质区别？
USMLE 类测「医学知识记忆」（选择题），RareBench 测「临床推理 + 表型编码标准化 + 长尾鉴别诊断」，输入是患者表型集合，输出是诊断排序。

A3：为什么罕见病诊断特别难？
两大结构性障碍：缺乏有经验的专科医生 + 需要在数千种表型重叠的疾病间鉴别。全球累计患者超 3 亿，但单病种患者稀少。

A4：RareBench 是谁做的？
清华大学与北京协和医院（PUMCH）团队。第一作者 Xuanzhong Chen（GitHub chenxz1111），通讯方向含 Ting Chen。

A5：什么时候发布的？
arXiv v1 于 2024-02-09 提交；KDD '24 正式出版于 2024-08。

A6：发表在哪个会议？
ACM SIGKDD 2024（KDD '24）ADS Track，pages 4850–4861，DOI 10.1145/3637528.3671576。

A7：核心创新是什么？
三点：四维任务框架、最大开源罕见病患者数据集、基于信息量（IC）的知识图谱动态少样本提示。

A8：四大任务分别是什么？
Task 1 表型提取、Task 2 特定罕见病筛查、Task 3 常见病/罕见病比较分析、Task 4 通用罕见病鉴别诊断。

B. 数据与获取

B1：数据在哪下载？
HuggingFace chenxz/RareBench（主渠道）+ GitHub chenxz1111/RareBench（代码与映射）。

B2：怎么加载？
from datasets import load_dataset; load_dataset('chenxz/RareBench', 'RAMEDIS', split='test')。

B3：有哪些子集？
五个：RAMEDIS、MME、HMS、LIRICAL、PUMCH_ADM。

B4：总共多少病例？
公开 1,197 例：624+40+88+370+75。

B5：为什么 HF 网页看不到数据？
数据集卡片设 viewer: false，不提供在线预览，必须用代码加载。

B6：数据字段有哪些？
Phenotype（HPO 代码列表）、RareDisease（OMIM/Orphanet/CCRD 代码列表）、Department（仅 PUMCH_ADM）。

B7：许可协议？
Apache-2.0，允许商用与再分发（保留声明）。

B8：包含个人隐私信息吗？
论文声明 PUMCH 医生在上传前逐例审查，确认无隐私泄露；发布时已剔除低质量病例。

B9：PUMCH 数据有多少？
内部总盘 1,650 例，仅公开 75 例（Human vs LLMs 实验所用）。

B10：数据是中文还是英文？
HF 标注 language: en，以英文形态发布（含中国来源数据的英文化）。

C. 任务与评测

C1：Task 1 具体做什么？
从非结构化 EHR 提取表型，分三子任务：表型提取、通用实体提取、通用实体标准化为 HPO。

C2：Task 2 筛查哪三种病？
ALS（渐冻症）、PNH（阵发性睡眠性血红蛋白尿）、MSA（多系统萎缩）。

C3：Task 3 的疾病池多大？
77 种（13 罕见 + 64 常见），527 份 EHR。

C4：Task 4 规模多大？
2,185 例 / 421 种罕见病（公共 + PUMCH 合并口径）。

C5：GPT-4 表现如何？
Task 4 中位排名 5.0；头对头 75 例 top-1 达 52.0%，优于资深医师 44.7%。

C6：哪个任务最难？
Task 1 的表型标准化（所有模型 F1 约 25%）与 Task 4 的全谱鉴别（搜索空间超大）。

C7：模型的主要短板？
表型编码标准化、否定性表型识别、复杂描述性症状理解。

D. 方法论

D1：什么是信息量（IC）？
Information Content，概念类似 IDF，衡量表型的特异性。出现越少的表型 IC 越高、区分度越强。

D2：知识图谱来自哪些库？
HPO、OMIM、Orphanet、CCRD 四库合成。

D3：动态少样本提示效果如何？
动态 3-shot 使 6 个 LLM 的 top-1 召回平均 +108%（相对零样本）。

D4：小模型有收益吗？
有。GLM4、Llama2-7B 经增强后有时可接近 GPT-4 零样本水平。

D5：256 维嵌入是什么？
基于 IC 的随机游走为每个 HPO 表型学习的嵌入向量（phe2embedding.json）。

E. 生态与库内

E1：库内有哪些可互链的条目？
healthbench(1063)、medagentbench(1064)、meds-ins(1093)、xmedbench(727)、multimedbench(129)、orphanet-ordo(812)。

E2：RareBench 和 rare25 是一回事吗？
不是。rare25(777) 是 Barrett 食管内镜数据集，名字含 rare 但与罕见病无关。

E3：RareBench 和 Orphanet-ORDO 什么关系？
Orphanet 是 RareBench 知识图谱的来源库之一；ORDO 是本体（描述疾病），RareBench 是基准（评测能力）。

E4：它的 AI-Ready 评级？
★★★★☆（DAIMS 8.55/10）。

F. 工程与复现细节

F1：API 模型怎么配？
key 写入 llm_utils/gpt_key.txt（OpenAI）、gemini_key.txt、glm_key.txt。

F2：本地模型怎么配？
修改 mapping/local_llm_path.json 指向本机模型路径。

F3：加载的最小子集名？
RAMEDIS、MME、HMS、LIRICAL、PUMCH_ADM。

F4：映射文件都在哪？
GitHub/HF 的 mapping/ 目录。

F5：有版本号吗？
无独立 release，单一 main 分支持续更新（HF 创建 2024-03，最后修改 2024-12）。

G. 局限与误读防范

G1：能复现论文全部结果吗？
不能完全复现——Task 4 的 2,185 例含未公开 PUMCH 数据。

G2：「GPT-4 超医师」该怎么理解？
仅在「只给表型文本」条件下的推理能力对比，不代表 LLM 可替代医生。

G3：有数据污染风险吗？
有。作为公开基准，后续 LLM 预训练可能见过这些病例，影响评测的独立性。

G4：适合商业使用吗？
Apache-2.0 允许商用集成，需保留许可声明；注意医疗数据的伦理合规。

G5：中文场景能用吗？
数据为英文，中文临床场景存在迁移损失，需谨慎评估。

H. 深度技巧

H1：如何用好 IC 值做检索？
用 ic_dict.json 给每个表型赋权，检索相似病例时按 IC 加权——高特异表型主导相似度计算，避免「发热、乏力」这类常见表型稀释信号。

H3：如何做跨子集泛化实验？
在 RAMEDIS 上调优（或选 few-shot 示例），在 LIRICAL 上测——但要注意两子集疾病集不重叠带来的难度跃升。

H4：如何防范评测污染？
用发布后新出的 LLM、或对病例做改写（paraphrase）后再测、或保留一部分私有测试集。

H5：top-10 指标怎么算？
正确诊断是否落在模型输出的前 10 个候选内（top-10 命中率）；Task 4 额外报中位排名。

H6：为什么用 top-10 而不是 top-1？
因为临床实践中鉴别诊断本就产出候选列表供医生参考，top-10 更贴近真实用途，也更能反映模型的「候选生成」能力。

I. 与临床的结合

I1：这个基准能指导临床 AI 开发吗？
能。它明确了「表型标准化是瓶颈」「否定性表型是隐患」「小模型 + 检索可逼近大模型」三条可操作结论。

I2：医院能直接部署吗？
不能直接部署。25% 的表型提取 F1 说明需先解决编码标准化，且需本地合规与伦理审查。

I3：最适合的定位是什么？
「鉴别诊断候选生成器」——给医生 top-10 参考，而非取代医生判断。

I4：为什么罕见病是 AI 的好赛道？
因为医生经验稀缺、诊断周期长、误诊率高，AI 的「知识平权」价值在此最大。

I5：数据规模够吗？
对评测够（1,197 例是同类最大开源），对训练不够——应结合其他罕见病数据。

J. 元数据与引用

J1：怎么引用？
用仓库 README 的 BibTeX（见 §6.7），booktitle 为 KDD '24，pages 4850–4861。

J2：DOI 是什么？
10.1145/3637528.3671576。

J3：arXiv 编号？
2402.06341。

J4：谁维护？
清华 + PUMCH 团队，GitHub chenxz1111/RareBench。

J5：有官方评测脚本吗？
有，在 GitHub 仓库（支持 API 与本地 LLM 两套路径）。

§12.5 术语表（中英对照）

中文	英文/缩写	释义
罕见病	rare disease	单病种患病率极低、累计患者众多的疾病群
电子健康记录	EHR / Electronic Health Record	患者的电子病历数据
人类表型本体	HPO / Human Phenotype Ontology	标准化描述人类表型异常的本体，HP 编号
在线人类孟德尔遗传	OMIM	遗传病与基因关联数据库
表型	phenotype	可观察的性状/症状体征
鉴别诊断	differential diagnosis	在多个候选病中逐一区分、锁定诊断
表型提取	phenotype extraction	从文本中抽取表型并标准化
标准化	standardization	把通俗表述映射为标准术语（如 HPO 代码）
信息量	IC / Information Content	类似 IDF，衡量表型特异性
随机游走	random walk	在知识图谱上按概率转移以学习嵌入
少样本提示	few-shot prompting	在 prompt 中给出若干示例
检索增强生成	RAG	检索相关内容注入生成过程
肌萎缩侧索硬化	ALS	「渐冻症」，Task 2 筛查病种
阵发性睡眠性血红蛋白尿	PNH	Task 2 筛查病种
多系统萎缩	MSA	Task 2 筛查病种
中国罕见病目录	CCRD	中国官方罕见病名录编码

§12.6 一页速览卡

问题	答案
是什么	首个 LLM 罕见病诊断评测基准 + 最大开源罕见病病例集
谁做的	清华 + 北京协和医院
何时	arXiv 2024-02 / KDD 2024-08
多少	1,197 例公开（RAMEDIS 624/MME 40/HMS 88/LIRICAL 370/PUMCH 75）
几任务	4（表型提取/筛查/比较/鉴别）
怎么拿	`load_dataset('chenxz/RareBench', <子集>, split='test')`
许可	Apache-2.0
亮点	GPT-4 top-1 52.0% > 医师 44.7%；动态少样本 +108%
短板	表型标准化 F1 ~25%；PUMCH 内部数据不可得；英文
适用	罕见病 LLM 评测、长尾医学能力研究、知识图谱少样本方法研究

§13 DAIMS 与 AI-Ready 小结

RareBench 在「AI-Ready」维度上的表现可概括为 「方法成熟、门好进、盘偏小」：

方法成熟：四任务框架、IC 知识图谱、动态少样本，KDD 顶会背书的完整方法论。
门好进：Apache-2.0 + 双公开直链 + 标准本体编码，开箱即用。
盘偏小：公开 1,197 例，PUMCH 内部数据不可得，无版本化 release。

对于研究者，它是罕见病 LLM 评测的首选起点；对于工程落地者，它是理解「长尾医学能力评测」设计思想的范本；对于数据治理者，它是「真实临床数据如何在脱敏与合规下开源」的参考案例。

事实清单（硬事实 20 条）

数据集名 RareBench，全称副题 “Can LLMs Serve as Rare Diseases Specialists?”。
论文发表于 KDD '24（ACM SIGKDD 2024），pages 4850–4861。
DOI：10.1145/3637528.3671576。
arXiv：2402.06341，v1 于 2024-02-09 提交（有 v2）。
作者：Xuanzhong Chen, Xiaohao Mao, Qihan Guo, Lun Wang, Shuyang Zhang, Ting Chen。
机构：清华大学 + 北京协和医院（PUMCH）。
公开病例 1,197 例（五子集合计）。
子集：RAMEDIS 624、MME 40、HMS 88、LIRICAL 370、PUMCH_ADM 75。
四个公共子集合计 1,122 例 / 362 病。
PUMCH 内部总盘 1,650 例，仅公开 75 例。
Task 4 评测盘 2,185 例 / 421 病。
Task 3 用 527 份 EHR / 77 病池（13 罕见 + 64 常见）。
Task 2 三病：ALS、PNH、MSA。
表型编码用 HPO；诊断编码用 OMIM/Orphanet/CCRD。
许可 Apache-2.0（HF 卡片三源一致）。
GPT-4 top-1 52.0% vs 资深医师 44.7%（75 例头对头）。
动态 3-shot 使 top-1 召回平均 +108%。
GPT-4 Task 4 中位排名 5.0。
Task 1 端到端 F1 约 25%（全模型）。
HF 创建 2024-03-05，最后修改 2024-12-12，language en。

来源

论文（arXiv）：https://arxiv.org/abs/2402.06341
论文（ACM DOI）：https://doi.org/10.1145/3637528.3671576
GitHub 仓库：https://github.com/chenxz1111/RareBench
GitHub README：https://raw.githubusercontent.com/chenxz1111/RareBench/main/README.md
HuggingFace 数据集：https://huggingface.co/datasets/chenxz/RareBench
HF 数据集卡片（镜像）：https://hf-mirror.com/datasets/chenxz/RareBench
HF API：https://hf-mirror.com/api/datasets/chenxz/RareBench

核验声明：本条目硬数字均经三源互证（arXiv 论文 / GitHub README / HuggingFace 数据集卡片），核验时点 2026-10-16。所有双口径冲突已在 §2.6 与 FACTS.md §9 逐条存照。库内互链 rid 一律以占位 /0 呈现，由发布流程统一回填。