信息速览
INFOBOX — Huatuo-26M 一屏速览
维度 内容 本质 截至 2023 年发布时最大的中文医疗问答数据集,也接近当时全球最大医疗 QA 数据集(比既有中文医疗 QA 大两个数量级) 团队 香港中文大学(深圳)+ 深圳市大数据研究院 + 上海人工智能实验室;GitHub 组织 FreedomIntelligence;通讯 Benyou Wang(王本友) 论文 arXiv:2305.01526(2023-05-02 v1)→ Findings of ACL: NAACL 2025(2025-04,页 3828-3848,doi:10.18653/v1/2025.findings-naacl.211) 数据 26,504,088 条 QA 对 = 问诊记录 25,341,578 + 医学百科 364,066 + 知识图谱 798,444;平均问题 44.6 字符、答案 120.7 字符 命名 纪念中国东汉名医华佗(Hua Tuo,约公元 200 年) 精修版 Huatuo-Lite(Huatuo26M-Lite/Huatuo26M_v2):去重→ChatGPT 打分→润色三步得 177,703 条(全集 0.6%),含科室与相关疾病字段 双基准 检索:BM25/DeepCT/DPR(DPR 全库 R@1000 42.55);生成:T5/GPT2 微调 + 七个 LLM(T5 微调 BLEU-1 26.63 最高) 四大应用 医疗 LLM 微调(DISC-MedLLM CMB-Exam +5.05)、RAG 外部知识、零样本迁移(cMedQA2 BLEU-1 +25.42)、CBLUE 持续预训练(RoBERTa-base 70.1 超 RoBERTa-large 70.0) 许可 Apache 2.0;raw version 公开(consultation 答案仅 URL),full-text version 需签仅研究协议申请 获取 HuggingFace 五仓(FreedomIntelligence 组织)+ GitHub + SRIBD 镜像页(.jsonl 5.3GB) 库内互链 cblue(190)(Application IV 评测基准)、chinese-critical-care-database(166)
Huatuo-26M 是一个「把中文医疗问答从万级抬到千万级」的数据集工程:在它出现之前,公开的中文医疗 QA 数据集最大不过十几万条(cMedQA2 108K、webMedQA 63K),而它一次带来了 26,504,088 条——两个数量级的跨度,使「用真实中文问诊语料训练医疗大模型」第一次不再受数据规模掣肘。它不追求单条数据的人工金标质量,而是用三源自动抽取(在线问诊、医学百科、知识图谱)换取规模,再用一套「去重—打分—润色」管线压缩出 177,703 条精修版 Huatuo-Lite 供大模型微调,形成「海量粗语料 + 小而精子集」的双轨结构。
三分钟版本:如果你只有三分钟,记住四件事——第一,它是 2023 年 5 月由香港中文大学(深圳)FreedomIntelligence 团队发布、2025 年正式发表于 NAACL Findings 的中文医疗问答数据集;第二,26,504,088 条里 95.6% 来自真实在线问诊(51zyzy.com),其余来自中文维基百科医学条目模板转换与三大医学知识图谱模板生成;第三,一切公开,Apache 2.0,唯独问诊子集的答案全文以 URL 形式发布(要全文要么自抓、要么签研究协议申请 full-text 版);第四,用它做 SFT 用 177,703 条的 Huatuo-Lite(DISC-MedLLM 多选基准 +4.5 到 +6.6 分),做检索/RAG/预训练才用全量(CBLUE 上 RoBERTa-base 70.1 分反超 RoBERTa-large)。其余一切都是这四件事的细节展开。
这个双轨结构正是理解 Huatuo-26M 的钥匙:直接全量微调大模型既无必要也不经济,论文的实验表明仅用 0.6% 的 Huatuo-Lite 就能让 DISC-MedLLM 在 CMB-Exam 上提升 5.05 分;而全量 26M 则在检索、RAG、持续预训练三类场景中发挥规模优势——RoBERTa-base 吃下 26M 语料后在 CBLUE 上拿到 70.1 平均分,反超参数量大四倍的 RoBERTa-large。数据怎么分层用、URL 版本是什么意思、五个 HuggingFace 仓库分别装了什么,是本条目要讲清楚的三件事。
导语读法三则:
- 只想下数据:直奔 §6 获取与许可——先分清 raw version(公开,consultation 答案仅 URL)与 full-text version(需申请),再按用途选五仓之一,别把 6,000 条测试集当成完整测试集(坑 3)。
- 关心数据质量:直奔 §3 质量工程——四维质量标注、医师抽评 71%/88%/79% 与 Huatuo-Lite 三步管线三段连读。
- 做基准对比:直奔 §4 检索/生成双基准与 §5 四大应用——所有表格数字直接对标,注意测试集与指标口径(坑 4)。
§0 导读:这个数据集解决什么问题
大语言模型进入医疗领域的第一个瓶颈不是算力也不是算法,而是数据:英文世界有 MedQA、PubMedQA、MedMCQA 等成规模评测集,中文医疗问答却长期停留在「几万到十几万条」的量级——ChiMed 47K、webMedQA 63K、cMedQA2 108K。这个量级够跑评测,不够做预训练;够微调一个小分类头,不够喂饱一个大语言模型。论文开篇给出的背景是:全球约 14 亿人以中文为母语,其中中国大陆的医疗资源可及性与发达国家仍有差距,在线问诊是分流的常规手段——海量真实问诊数据存在于中文互联网,却从未被系统整合为公开语料。
Huatuo-26M 的回答分四层。第一层是规模:从在线问诊网站 Qianwen Health(51zyzy.com)抓取 3,167 万原始问答对,清洗去重后保留 25,341,578 条,再叠加医学百科模板转换的 364,066 条与三大知识图谱模板生成的 798,444 条,合计 26,504,088 条,比此前最大的医疗 QA 数据集(英文 PubMedQA 272K)大两个数量级。第二层是基准:在同一数据上同时评测答案检索(BM25/DeepCT/DPR 三种检索器)与答案生成(从 T5、GPT2 到 Baichuan2、ChatGLM3、Qwen 等七个大模型),给出后续工作的对标线。第三层是应用证明:四个实验分别验证它当医疗 LLM 微调数据、RAG 外部知识库、零样本迁移源、持续预训练语料都有效。第四层是可用性工程:以 Apache 2.0 开放,公开版用「答案仅 URL」的折中方案化解问诊数据的版权与滥用风险,全文本版走机构协议通道。
这套设计有一个清醒的代价表:26M 条数据不可能全量人工审核,论文 Limitations 坦承可能包含错误医疗信息;三源风格差异极大(问诊口语化、百科条目式、图谱模板化),混用必须分层评估。条目 §3 与 §10 会把这些代价算清楚。
数据规模的历史坐标:把 Huatuo-26M 放回 2023 年的时间点,它的出现更接近「断层式补课」。此前中文医疗 QA 最大的三个集合——cMedQA2(108K,2018)、webMedQA(63K,2019)、ChiMed(47K,2019)——全部诞生于 BERT 时代之前,服务于答案句选择或阅读理解,量级只够训练判别式模型。2022 年底 ChatGPT 引爆生成式医疗对话需求后,中文社区发现:英文有 MedQA(美国医师考试题)、HealthCareMagic 等对话语料,中文却拿不出一个百万级以上的开放问答集。Huatuo-26M 在 2023 年 5 月以 26M 条一次性填平这个断层,两个月内(2023-05-06 至 05-17)三个子集与官方测试集全部上架 HuggingFace,成为后续中文医疗大模型(HuatuoGPT、DISC-MedLLM 等被评对象与用户)的公共语料选项。
§0 读法三则:
- 这个条目是「数据集+双基准+四应用」三合一:本体是 26M 条 QA 对,衍生品是 Huatuo-Lite 精修版与检索/生成两条基准线,副产品是一套「LLM 当数据工人」的加工管线——三者的获取方式与许可各不相同(§6)。
- 全文统计数字均出自论文(NAACL 2025 Findings 版)正文与表格、GitHub README 及 HuggingFace API 实抓;正文与外部镜像的口径冲突(总量、test 规模、encyclopedias 计数)已在坑 2、坑 3、坑 4 存照。
- 检索时若把「HuatuoGPT」当作数据集名去搜,得到的是同团队的医疗大模型而非数据集——生态关系见 §7,命名混淆全表见坑 1。
它和常见「论文即全部」的数据集有什么不同:多数学术数据集的公共形态是「论文 + 一个下载链接」,Huatuo-26M 的形态是「论文 + 双版本数据架构 + 五个 HuggingFace 仓 + 官方测试集 + 完整加工 prompt」——团队把数据工程的过程资产(打分标准、润色模板、超参配置)一并公开,使它既是语料,也是方法学参考实现。这个「过程透明度」在 2023 年的领域数据集里是少数派,也是本条目愿意把管线细节展开到 §3.6 粒度的原因。
§1 数据集速览:十四问十四答
Q1:Huatuo-26M 到底有多少条数据?
NAACL 2025 正式版精确口径:26,504,088 条 QA 对,其中训练集 26,239,047、测试集 265,041。早期 arXiv v1 摘要与 GitHub 标语写「26 million」,是同一物的约数。SRIBD 镜像页的 test 264,041 与论文 265,041 相差 1,000,以论文为准(坑 2)。
Q2:三条数据来源各占多少?
在线问诊记录 25,341,578 条(占约 95.6%,绝对主力)、医学百科 364,066 条、知识图谱 798,444 条。问诊记录来自 Qianwen Health(51zyzy.com),原始抓取 31,677,604 对,经正则去特殊字符与哈希去重后缩减至 25,341,578——缩水约 633 万条,主因是重复与格式问题。
Q3:每条数据长什么样?
统一为问答对形式:questions(问题描述)+ answers(医生/专家回答)。问诊源问题口语化(例:「3 岁宝宝把整个水果糖咽了,怎么才能知道是咽下去了呢?」);百科源问题短、答案长(平均答案 540.4 字符的条目式文本);图谱源问题由模板生成(例:「颜面部凹陷的手术治疗有些什么?」),答案为图谱条目内容的短列表。全库平均问题 44.6 字符、答案 120.7 字符。
Q4:问诊记录公开版为什么只有 URL?
版权与防滥用:团队公开的 raw version 中,问诊子集只发布问题文本与答案所在的原始页面 URL,答案全文需自行访问或走协议申请 full-text version。论文原话:这是为了避免数据被公司或个人滥用(坑 6 详述)。
Q5:数据质量有人工审核吗?
全量无法人工审核(论文自述),但有三层质量工程:一是 3 名执业医师对每源抽 100 例评估答案准确率——问诊 71%、百科 88%、图谱 79%;二是用医师标注+ChatGPT 扩展训练四个分类模型,为全库打四维质量标签(流利度/相关性/完整性/专业性),分类器准确率 72.70%-76.86%;三是 Huatuo-Lite 子集经 ChatGPT 0-5 分打分与润色,人工复评零 Poor 评级。
Q6:Huatuo-Lite 是什么,和本体的关系?
精修子集:26,239,047 条训练数据经 BGE 嵌出去重(剩 1,316,730)、ChatGPT 打分留 4 分以上(剩 237,127)、GPT-3.5-turbo 润色答案(终得 177,703),约为全集 0.6%。字段比本体多两个:就诊科室(Hospital Department,如「眼耳鼻喉科」)与相关疾病(Related Diseases)。HuggingFace 仓库名 Huatuo26M-Lite,卡内 pretty_name 为 Huatuo26M_v2——同一物三名(坑 1)。
Q7:license 是什么,商用可以吗?
全部仓库与代码统一 Apache 2.0。但注意 full-text version 的发放附带「仅限研究用途」协议,问诊子集答案全文的使用边界以协议为准;论文伦理声明同时要求:用该数据训练的模型限科研用途,不得直接向患者提供处方建议。
Q8:怎么下载?
公开部分三条路:HuggingFace datasets.load_dataset('FreedomIntelligence/huatuo_encyclopedia_qa') 等五仓直载;GitHub 仓库 FreedomIntelligence/Huatuo-26M;SRIBD 开放数据集页(.jsonl 共 5.3GB)。国内镜像可用 hf-mirror.com。full-text version 需邮件联系团队签协议。
Q9:用它训练模型,效果提升有多少?
论文四组实验:Huatuo-Lite 微调让 DISC-MedLLM-13B 在 CMB-Exam 从 37.51 升到 41.56(+5.05);零样本迁移让 T5 在 cMedQA2 的 BLEU-1 从 0.23 跳到 25.65,甚至超过在 cMedQA2 自己训练集上微调的 T5(20.88);作 RAG 外部知识在 cMedQA2 上把 T5-RAG 的 BLEU-1 从 25.86 提到 31.85;作持续预训练语料让 RoBERTa-base 在 CBLUE 拿到 70.1 平均分、反超 RoBERTa-large 的 70.0。
Q10:论文发表在哪,算正式发表吗?
算。预印本 arXiv:2305.01526(2023-05-02),正式版发表于 Findings of the Association for Computational Linguistics: NAACL 2025(2025 年 4 月,页 3828-3848),NLP 顶会 Findings 级别。作者名单从 v1 的 9 人调整为正式版 12 人(坑 5)。
Q11:数据覆盖哪些科室与疾病方向?
问诊源的问题分布由真实用户需求决定:论文附录 C 的词云分析显示产科、儿科词汇最突出(新手父母的知识缺口与儿童高发疾病构成咨询主力),生殖健康类问题高频出现。图谱源覆盖疾病的 42 类属性维度(症状/病因/治疗/检查/预防等全谱系)与药品适应症。Huatuo-Lite 的 label 字段直接标注就诊科室(如「眼耳鼻喉科」),可按科室切片使用。
Q12:数据是纯中文吗,能直接用于英文项目吗?
纯中文(HF 五仓统一标 language:zh)。论文里出现的中英对照文本只是数据样例展示,不属于数据本身。论文 Limitations 提到计划翻译为其他语言(尤其是低资源语言),同时警告翻译可能引入额外错误——截至抓取时点未见官方多语版发布,第三方翻译版本需自行验证质量。
Q13:它和 cMedQA2、webMedQA 有数据重叠吗?
论文没有做跨集去重声明,而 cMedQA2(在线医疗论坛)、webMedQA(医疗咨询网站)与 Huatuo-26M 的问诊源同属中文在线问诊生态,来源站点可能有交集。论文把两者用作迁移实验的目标数据集——如果关注严格的无泄漏评估,应自行做问题相似度去重(BGE 嵌入 + 阈值筛即可复用论文的方案)。
Q14:它能当医疗考试题库用吗?
不能。它是开放式的真实问答对(患者描述+医生回复),不是选择题考试集;论文评测医疗 LLM 用的 CMB-Exam/CMExam/CMMLU/C-Eval(Med) 都是独立的外部考试基准。如果你的需求是考试类题目,那些基准各自独立发布;Huatuo-26M 的价值在「真实问诊分布」,两者互补不可互替。
§2 数据构成与规格:三源如何拼出 2600 万
2.1 规模总账:一张表看全集
论文 Table 3 给出的全集统计如下(NAACL 2025 口径):
| 构成 | 条数 | 平均问题长度(字符) | 平均答案长度(字符) |
|---|---|---|---|
| Huatuo-26M Train | 26,239,047 | 44.6 | 120.7 |
| Huatuo-26M Test | 265,041 | 44.6 | 120.6 |
| 来源:问诊记录(consultant records) | 25,341,578 | 46.0 | 117.3 |
| 来源:医学百科(encyclopedias) | 364,066 | 11.5 | 540.4 |
| 来源:知识库(knowledge bases) | 798,444 | 15.8 | 35.9 |
| 全部(All) | 26,504,088 | 44.6 | 120.7 |
三行来源数字之和(25,341,578 + 364,066 + 798,444 = 26,504,088)与全集精确相等——这张表是全文所有规模讨论的锚点。三个长度列已经泄露了三源的性格差异:问诊源问题最长(患者要把症状讲清楚)、答案居中(医生的针对性回复);百科源问题极短(平均 11.5 字符,基本是标题转写)、答案极长(平均 540.4 字符,整段条目文本);图谱源两头都短(模板问句 + 图谱条目式短答案)。
检索者最常踩的规模坑有两个。一是总量口径:arXiv v1 摘要与 GitHub 标语写「26 million」,论文贡献句与 Table 3 写 26,504,088,SRIBD 镜像只列 train+test 两数且 test 少 1,000——引用时一律回到 Table 3(坑 2)。二是encyclopedias 计数:论文写 364,066,HuggingFace 数据卡描述写 364,420,相差 354,疑为论文定稿后子集仍有过微调(坑 4)。本条目正文一律采用论文口径并标注差异。
2.2 问诊记录:占 95.6% 的绝对主力从哪来
数据源是 Qianwen Health(论文脚注:https://51zyzy.com/),一个真实的中文在线医疗咨询网站,平台记录了医生的基本信息(姓名、供职医院、科室),患者侧信息匿名化处理以保证可追溯并防泄漏。每条记录天然是「患者提问 + 医生回答」的一问一答。
原始抓取量 31,677,604 对。随后是标准化的清洗管线:
- 用正则表达式剔除含特殊字符的问答对(乱码、广告、格式残片);
- 用哈希去重消除完全重复项;
- 产出 25,341,578 对——清洗损耗约 633 万条(约 20%)。
值得注意的细节是患者隐私的处理策略:团队「仔细选择使用匿名患者数据且提供清晰医生信息的网站」,即网站本身已匿名化患者、医生侧实名可追溯。这既是伦理选择,也是后面「URL 版本」发布策略的铺垫——数据源头合规,发布端仍要再上一层保险(§6)。
问诊子集的内容画像:问题覆盖症状咨询、用药、检查解读、术前术后疑问;论文词云分析(附录 C)显示产科、儿科词汇突出——新手父母的知识缺口与儿童高发疾病构成问诊主力,生殖健康类问题的高频出现则被作者解读为线上问诊「去病耻感」效应。
论文 Figure 1 展示了问诊问题的高频主题分布(词云中反复出现的问题类别):进食相关(Eat,如误吞异物、辅食添加)、发热(Fever,儿科最高频主题之一)、孕期用药与注意事项(Pregnant)、用药方法(Medicine,含剂量与相互作用)、面部与颈部症状(Face/Neck,皮肤与淋巴结问题)、以及「无痛/不痛」类表述(Painless,患者用「不痛」来描述与排除病情)——这些高频词勾勒出中文在线问诊的真实需求图谱:家庭健康护理场景(育儿、孕产、日常用药)远多于急重症描述。对下游的启示:用问诊源训练的模型天然带「家庭医生/导诊」语感,与 hospital 场景的专业病历文本是两种语域。
三源互补的整体图景可以概括为:问诊源供「真实问题分布」、百科源供「权威知识文本」、图谱源供「结构化覆盖」——三者拼在一起才是完整的 Huatuo-26M,任何单源都不能代表全集性质。
2.3 医学百科:把条目拆成问答对
百科源由三块材料构成:
- 中文维基百科(zh.wikipedia.org)8,699 个疾病条目 + 2,736 个药品条目;
- 从 Qianwen Health 抓取的 226,432 篇高质量医疗文章。
处理逻辑是「标题-段落」转问答:每篇文章由标题与段落组成,标题可能是「用法用量」「禁忌」「营养」(药品类)或「诊断」「临床特征」「治疗方式」(疾病类)。管线先把出现少于五次的标题剔除,得到 733 个唯一标题;再为每个标题设计人工模板,把标题转写成一个可被对应段落回答的问题,疾病名或药名作占位符填入。例如标题「用法用量」+ 药品「曲匹地尔片」+ 药品说明段落,就生成一条「曲匹地尔片的用法用量」问答对。
这个设计解释了百科源「问题极短、答案极长」的统计画像:问题就是模板句,答案是原始条目整段文本。也意味着百科子集的信息密度高但问题多样性低——733 个模板就是它的问题类型上限。364,066 条的最终规模与 HF 卡 364,420 的差异见坑 4。
举两个「标题→问题」的转换实例(出自论文公开样例):药品条目「曲匹地尔片」+ 标题「用法用量」→「曲匹地尔片的用法用量」,答案即说明书段落(内含「同种药品可由于不同的包装规格有不同的用法或用量」这类标准免责声明——百科源答案的样板腔由此而来);疾病/药理条目「生物药剂学」→「什么是生物药剂学?」,答案是数百字的学科定义段。前者是典型的「结构化用药知识」,后者是「教科书式概念解释」——百科源内部也有细分语域,按标题类别分层使用效果更好。
2.4 知识图谱:43 个模板造出 80 万条
知识图谱(knowledge base)源是三份既有医学图谱:
| 图谱 | 实体类型数 | 关系数 | 实体数 | 三元组数 |
|---|---|---|---|---|
| CPubMed-KG | - | 40 | 1.7M | 4.4M |
| 39Health-KG | 7 | 6 | 36.8K | 210.0K |
| Xywy-KG | 7 | 10 | 44.1K | 294.1K |
- CPubMed-KG:中文医学文献知识图谱,基于中华医学会的大规模文献数据(Qingcai Chen 等,2022,cpubmed.openi.org.cn);
- 39Health-KG 与 Xywy-KG(寻医问药):两个开源医学知识图谱(Zhihao Chen,2018,github.com/zhihao-chen/QASystemOnMedicalGraph)。
清洗流程:去除无效字符、合并实体与关系,得到 43 个类别(每类挂接一种关系或属性);再为每类设计一个问题模板,形如「查询主体实体的对象实体」或「查询主体实体的某属性」,答案即对象实体或属性值。43 个模板覆盖疾病侧 42 类(症状、并发症、简介、预防、病因、发病率、就诊科室、治疗方式、治疗周期、治愈率、检查、多发群体、药物治疗、忌食、宜食、死亡率、辅助检查、多发季节、相关症状、发病机制、手术治疗、转移部位、风险评估因素、筛查、传播途径、发病部位、高危因素、发病年龄、预后生存率、组织学检查、辅助治疗、多发地区、遗传因素、发病性别倾向、放射治疗、化疗、临床表现、内窥镜检查、影像学检查、相关导致、治疗后症状、相关转化)+ 药品侧 1 类(适应症),模板样例见附录 E。
这套管线产出 798,444 条,质量验证方式是人工抽检 500 个随机样例、检查答案与问题是否匹配——结果「几乎每条都正确」。但要注意:模板生成意味着问题分布由图谱结构而非真实用户需求决定,且答案受限于图谱条目内容(常常是分号分隔的短列表,平均答案长度仅 35.9 字符)。它是规模与结构化质量的贡献者,不是真实对话语料。
三份图谱的分工也值得了解:CPubMed-KG 出自医学文献(中华医学会数据),术语规范但偏学术;39Health-KG 与 Xywy-KG 出自健康门户(39 健康网、寻医问药网),语言更贴近患者视角但实体规模小一个量级。模板逐类跑遍三图后合并,同一疾病-属性组合在不同图里可能各有一条——这也是图谱子集中语义近似条目的主要来源,用 BGE 去重(§3.4)时被大量合并的就是它们。
2.5 划分口径与两个「测试集」
Huatuo-26M 有两套「test」概念,检索者极易混淆(坑 3):
- 论文 Table 3 的 Test 265,041 条:按源划分的评测集——encyclopedias 与 knowledge bases 按 90% 训练 / 10% 测试 切分,问诊记录等按 99% 训练 / 1% 测试 切分(官方理由:候选池巨大,1% 已够评测且省时)。这套划分服务于论文的检索基准。
- 6,000 条 NLG 评测集:从多源随机抽样的独立测试集,论文生成基准专用,单独发布为 HuggingFace 仓库
FreedomIntelligence/huatuo26M-testdatasets(GitHub README 标注 “testdatasets (6k)”)。
因此「Huatuo-26M 的测试集是多大」没有单一答案:做检索对比看 265,041 口径,做生成对比用 6,000 条官方集,自己切分则需先声明所用子集与比例。
2.6 文件结构与格式
四个发布单元的文件结构统一(SRIBD 镜像页口径):
# huatuo_encyclopedia_qa / huatuo_knowledge_graph_qa / huatuo_consultation_qa 三者同构
.
├── train_datasets.jsonl
├── validation_datasets.jsonl
└── test_datasets.jsonl
# Huatuo-Lite
.
└── format_data.jsonl
- 格式:JSONL,每行一个问答对象;三个子集字段为 question 与 answer(consultation 的 answer 为 URL 字符串);
- Huatuo-Lite 的 format_data.jsonl 每行含 id、question、answer、score(ChatGPT 质量分)、label(就诊科室)、related_diseases(相关疾病)六个字段;
- SRIBD 镜像合计存储 5.3GB;HuggingFace 各仓 API 实测存储:consultation ~8.7GB(最大)、Huatuo-Lite ~2.8GB、encyclopedia ~2.0GB、knowledge_graph ~0.5GB、testdatasets ~26MB。
2.7 数据样例细读:六个官方实例能告诉你什么
论文 Table 6 与 Table 15 给出逐源样例,是判断「数据长什么样」最直接的材料。逐条拆解:
问诊源样例一(儿科急症场景):
Q: 3岁宝宝把整个水果糖咽了,怎么才能知道是咽下去了呢?
A: 只要是咽后宝宝没有憋气的现象,那就是咽下去了。
问题口语化、带真实焦虑情绪与具体年龄信息;答案一句话、直给判断。这正是问诊源的典型形态:上下文短、交互密度高、答案不一定完整(没有叮嘱何时需要就医)——这既是它的真实感来源,也是 71% 准确率基线的成因之一。
问诊源样例二(成人慢病场景):
Q: 我可能得了戊肝,因为我饮食越来越不好,而且吃饭的时候总是想吐。
问一下戊肝早期的症状是什么呢?
A: 肝早期的症状会出现脂肪无法消化,造成大量脂肪存积于体内,同时胃功能
也会紊乱,就会出现厌食,看见油腻的食物就恶心的症状,肤色素沉着,指
甲颜色改变,毛发改变等。
问题自带病史叙述(饮食变化+呕吐),答案列症状但开头写「肝早期」而非「戊肝早期」——自动抽取语料里常见的轻微措辞瑕疵,检索时需容忍这类噪声。
百科源样例:
Q: 什么是生物药剂学?
A: 生物药剂学是研究给药后药物的吸收的整个体内过程,包含各种制剂因素和
生物因素对这一过程与药效的影响。……
问题就是条目标题的疑问化,答案是数百字的完整定义段落(该源平均答案 540.4 字符)。适合做知识注入与长文本生成,不适合做对话训练。
百科源样例二(前列腺钙化治疗)同样是标题转问题 + 长条目答案,内含「忌久坐、忌久骑、排便时间控制在 3 到 5 分钟」等生活医嘱细节——百科源答案的信息颗粒度可见一斑。
图谱源样例两则:
Q: 气道吸痰的辅助治疗有些什么?
A: 足量补液
Q: 脓腔穿刺的辅助治疗有些什么?
A: 消毒隔离;皮肤的护理;营养支持
模板问句(「……的辅助治疗有些什么?」正是 43 模板之一)、分号分隔的短答案。两例同模板不同实体——图谱子集的机械性一目了然:它提供覆盖广度与结构一致性,不提供语言多样性。
Huatuo-Lite 样例(SRIBD 镜像页公开):
{
'id': 22647835,
'question': '上个月感冒了,也没有用药,感冒好了以后就觉得鼻子经常不通畅,
鼻子经常发红发痒,还有头晕,一直以为是感冒后遗症,去医院检查
说是鼻中隔偏曲。请问如何治疗鼻中隔偏曲?',
'answer': '治疗鼻中隔偏曲的方法有手术和非手术治疗两种,手术治疗是通过手术
矫正鼻中隔偏曲,非手术治疗则是通过药物治疗和物理治疗来缓解症状。
……',
'score': 5,
'label': '眼耳鼻喉科',
'related_diseases': '鼻中隔偏曲'
}
对照可见 Lite 管线的净效果:问题被打分器筛过(score 5 = 完整清晰具体)、答案被统一成结构化叙述、多了科室与疾病两个可筛选维度。id 22647835 也暗示其母体规模(原始训练集 2,623 万条的编号空间)。
2.8 隐私处理:匿名化的边界在哪
论文对隐私的三层处理值得记录,检索合规评估时可直接引用:
- 源头选择:只从「患者数据已匿名、医生信息清晰」的网站采集——匿名在网站侧完成,不在数据集侧补做;
- 患者侧:无姓名、无联系方式、无身份证号等直接标识符;问题文本中患者自述的年龄、症状、病程等属于咨询必要信息,保留;
- 医生侧:保留姓名、医院、科室三项基本信息,官方理由是「保证答案可追溯性」——医生实名使答案质量可归因,也使数据可回溯到原始问诊页面。
这套设计与「URL 版发布」是配套的:医生信息+URL 使每条问诊数据可回溯到原始页面,使用者可自行核验原文;但也意味着数据集不是「完全去标识」的产物,做伦理审查时应把「医生侧实名」这一事实纳入评估。
对应到工程实践:如果下游要把问诊源用于生成式训练,建议在数据装载层再做一次医生姓名/医院名的实体掩码(正则+词表即可覆盖大部分),把「论文层面的合规」推进为「训练层面的合规」;百科源与图谱源来自公开百科与图谱,无需此步。另需注意:URL 字段本身含原站路径结构,批量再抓取前应核对原站 robots 与服务条款——「数据集许可 Apache 2.0」约束的是数据集发布物,不自动延伸到 URL 指向的第三方页面内容。
§3 质量工程:从 2600 万粗语料到 17.7 万精子集
3.1 四维质量标签:给每条数据发体检报告
为方便按场景筛选用途,团队给库内数据打了四个维度的 1-3 级标签:
- Fluency(流利度):从「完全破碎不可读」到「人类级流畅」;
- Relevance(相关性):从「完全答非所问」到「直接精准命中问题」;
- Completeness(完整性):从「信息极端不全」到「信息完整呈现」;
- Professionalism(医学专业性):从「无医学术语的口语」到「扎实掌握医学术语、细节偶有小错」。
标签的生产是「医师种子 + LLM 扩容器」两级流程:先请 3 名执业医师独立标注 200 条,只保留四个维度全部一致的 146 条作为种子;再用 ChatGPT(gpt-3.5-turbo)做 5-shot 提示扩展、统一打分分布,得到 10K 标注集;70% 训练 / 30% 测试,各训一个分类模型。四个分类器的测试准确率分别为 76.86%(流利度)、72.70%(相关性)、75.60%(完整性)、72.70%(专业性)。
打分器的可靠性单独验过:从 146 条医师标注中抽 73 条作盲测集,其余做 5-shot 池;ChatGPT 打分 71 条与医师完全一致,仅 2 条在单一维度差 1 分。
读数提醒:这是 72%-77% 准确率的自动化标签,不是人工金标;用它做粗筛合理,当 ground truth 引用要打折扣。全库标签分布见 3.3。
3.2 医师抽评:三源答案准确率 71% / 88% / 79%
论文做了最直接的可用性检验:从问诊、百科、图谱三个源各抽 100 例,请 3 名执业医师评估答案准确性,结果分别为 71%、88%、79%。百科源最高——答案来自权威条目文本;问诊源最低——医生回复天然带个体判断与不完整信息(患者描述不全时医生也只能就有限信息作答)。
这组数字与论文附录 I 的质量分布相互印证:问诊源「口语化 + 针对性强」,百科源「正式 + 信息密集」,图谱源介于两者之间。检索者选子集时可按此对号入座:要专业文本语料优先百科源,要真实对话语料用问诊源但要接受 71% 的答案准确率基线。
解释这组数字时还要守住两条边界:其一,评估对象是「答案准确性」,不含问题本身的质量(患者描述不全是问诊源的结构性特征,不是答案错误);其二,每源 100 例的样本量决定了这是量级参考而非精确估计,与其他数据集的类似抽评数字对比时要连评估协议一起比(评估者人数、判定标准、抽样方式),裸数字跨论文直接比大小没有意义。
3.3 全库四维标签分布:专业性维度的短板
论文 Table 4 给出全库自动化标签分布(百分比):
| 质量档 | Fluency | Relevance | Completeness | Professionalism |
|---|---|---|---|---|
| Poor | 0.15 | 0.55 | 0.59 | 0.49 |
| Medium | 21.80 | 23.45 | 40.99 | 67.98 |
| Good | 78.05 | 76.01 | 58.42 | 31.53 |
两个结构信息值得记住。其一,Professionalism 维度 Good 仅 31.53%,近七成数据落在 Medium——医疗问答里大量口语化描述(问诊源尤甚)天然不是「专业术语级」文本,这不是缺陷而是语料性质,引用质量数据时应四维并报而非只挑好看的单维(坑 7)。其二,四个维度的 Poor 都在 1% 以下,说明清洗管线有效挡住了垃圾数据;主体质量集中在 Medium-Good 区间。
3.4 Huatuo-Lite:三步管线压出 0.6% 精子集
Huatuo-Lite 的目标是「在可负担算力内提升 LLM 医疗能力」——26M 全量微调不经济,需要一个既保质量又保覆盖的小集合。三步管线每一步都有精确账目(论文 Table 8):
| 步骤 | 剩余条数 | 平均问题长度 | 平均答案长度 |
|---|---|---|---|
| Huatuo-26M Train(起点) | 26,239,047 | 44.6 | 120.7 |
| 第一步:去重后(Aft. Deduplication) | 1,316,730 | 75.6 | 131.9 |
| 第二步:过滤后(Aft. Filtering) | 237,127 | 81.3 | 141.7 |
| 第三步:润色后(Aft. Polishing) | 177,703 | 80.1 | 143.9 |
第一步·语义去重:用 BGE(BAAI/bge-large-zh)给每个问题算词嵌入,以欧氏距离小于 12 为阈值定义「邻居」,向量检索用 FAISS,单问题邻居数上限 512;邻居数低于 30 的问题视为低频问题剔除;另定义基于 2-gram 重叠的词频距离,超过 0.2 的组内问题相互排除。随机遍历全库、已入选问题邻居集中的一律不再收——这一步把 2,623 万压到 131.7 万,去重率达 95%。
第二步·ChatGPT 打分过滤:用 ChatGPT(gpt-3.5-turbo-0125)给问题打 0-5 分,评分标准从「1 分:信息不全/含链接广告/医生导向内容」到「5 分:完整、清晰、具体、无冗余、无可改进处」;只保留 4 分以上。打分分布:Score 0 共 3,076 条、Score 1 共 248,256 条、Score 2 共 466,459 条、Score 3 共 361,383 条、Score 4 共 212,827 条、Score 5 共 24,300 条——即 4 分以上合计 237,127 条。注意打分对象是问题(评估清晰度、完整性、相关性),不是答案。
第三步·答案润色:ChatGPT 参考原始答案重写,目标是清晰、简洁、风格一致、无语法错误——理由是论坛答案的多样性有益泛化,但答案风格不一致会给模型引入负效应。润色提示词(论文附录 K)指定 AI 助手角色、仅答医疗、不答医院/医生/品牌导向问题等约束,输出「Thought + Answer」结构。终得 177,703 条。
三步之后平均答案长度从 120.7 升到 143.9——润色不是压缩而是补全细节;平均问题长度从 44.6 升到 80.1——低信息量的短问题被高分长问题替换。子集另附 score、label(就诊科室)、related_diseases 三个字段,比本体多出两层结构化维度。
3.5 Huatuo-Lite 的人工终审
100 条随机样本交执业医师按四维严格评估(论文 Table 10):
| 质量档 | Fluency | Relevance | Completeness | Professionalism |
|---|---|---|---|---|
| Poor | 0 | 1 | 5 | 3 |
| Medium | 19 | 20 | 56 | 63 |
| Good | 81 | 79 | 39 | 34 |
结论原文要点:流利度 81% Good 且零 Poor;相关性 79% Good;完整性 95% 达 Medium 以上;专业性 97% 达 Medium 以上。与全库分布对照,Huatuo-Lite 在四个维度上全面上移——尤其是 Professionalism 的 Good 档从全库 31.53% 提到 34%(样本口径)、Medium 以上 97%,这正是「打分+润色」两步针对的靶点。
3.6 ChatGPT 打分标准细读:什么问题会被留下
论文附录 K 公开了打分 prompt 的完整评分标准(0-5 分制,实际筛选保留 4 分以上),逐档转述如下——理解这个标准,就理解了 Huatuo-Lite 的筛选口味:
- 1 分:信息不完整、语义含糊,不足以让医生作出判断;可能含无关或重复内容、超链接、或针对特定医生的推广内容;
- 2 分:大体完整清晰、重复少,但信息量仍不足以支撑医生判断;可能不简洁、组织欠佳,有轻微语法错误但不影响流畅;
- 3 分:完整、清晰、简洁,无重复无关内容,信息足以让医生判断,组织良好、语法正确——但可能缺少一个具体的问题,或有轻微歧义;
- 4 分:非常完整清晰简洁,信息充分且含具体问题,组织良好、语法正确,无重复/歧义/链接/推广——仅剩清晰度或信息丰富度上的微小改进空间;
- 5 分:完整与简洁的完美状态,包含医生判断所需的全部信息,有明确清晰的问题,无可改进之处。
三条推论:其一,「含链接或医生导向推广」直接打到 1 分——打分器在替清洗管线做二次内容安全过滤;其二,「有明确具体的问题」是 4-5 分的硬条件,这解释了去重后平均问题长度从 44.6 跳到 75.6 的另一半原因(长而具体的问题天然占优);其三,prompt 要求模型「先给简短理由再在最后一行输出 Score: <score>」,这是典型的思维链式评分设计,2023 年即已成型的做法。
润色 prompt(Figure 9)同样值得注意:系统提示以「You are Huatuo GPT, an AI assistant for medical questions」开头,约束包括仅答医疗问题、不答具体地点/医院/医生/品牌相关、不答广告类问题、不明确时追问澄清、可参考但不必照抄参考答案——这份约束清单实质上是团队对「理想医疗问答助手行为规范」的早期成文化,与 HuatuoGPT 的系统提示一脉相承。
3.7 质量工程的总账与局限
把 §3 各层工程放在一起算总账,可以看到一条清晰的「质量-规模交换曲线」:
| 层级 | 覆盖规模 | 质量保障 | 适用场景 |
|---|---|---|---|
| 全库 26,504,088 | 全部 | 自动清洗+自动标签(72%-77% 准确率) | 预训练、检索池、RAG |
| 按源切片 | 百科 364,066 / 图谱 798,444 | 医师抽评 88% / 79% | 知识注入、结构化问答 |
| 问诊源 25,341,578 | 最大 | 医师抽评 71% + URL 可回溯 | 对话语感、真实分布研究 |
| Huatuo-Lite 177,703 | 0.6% | ChatGPT ≥4 分 + 润色 + 人评零 Poor | SFT 微调 |
诚实的局限清单(论文自述 + 本条目归纳):
- 全库无逐条人工审核,可能含错误医疗信息——论文 Limitations 原话;
- 自动质量标签是分类器输出,跨维度间的一致性未标定;
- 打分与润色均由 ChatGPT 完成,子集风格受单一模型偏好影响(2023 年时点 gpt-3.5-turbo 系);
- 医师评估样本量小(每源 100 例、标注种子 146 条),置信区间宽;
- 质量标签与 Huatuo-Lite 的 score 体系(1-3 级 vs 0-5 分)是两套并行标准,混用时需各自换算。
这五条不是否定——在 2023 年的条件下,这套「规模分层+多层抽检」的设计已是同类数据集中最完整的质量交代之一;写在这里是提醒下游:引用质量数据时带上方法学语境,别把抽检数字当成全库承诺。
§4 双基准:在 2600 万条上检索与生成有多难
4.1 检索基准:DPR 拿下 42.55 的 Recall@1000
实验设置:从含训练集与测试集答案的候选池中排序 top-1000 相关答案。三个基线——稀疏检索 BM25(基于 Lucene,以单字符为索引单元而非词,k1=1.2、b=0.9)、稀疏改进 DeepCT(用 bert-base-chinese 学习上下文感知词权重,训练 3 epochs、lr 2e-5、batch 72、最大序列长 256)、稠密检索 DPR(双编码器,batch-negative 训练,batch 192 外加 BM25 负例,2 epochs、lr 1e-5)。指标为 Recall@k(前 k 个候选含正确答案的比例)与 MRR@10。划分口径:百科与图谱 90/10,问诊等 99/1。
结果(论文 Table 5,ALL 行):
| 模型 | Recall@5 | Recall@20 | Recall@100 | Recall@1000 | MRR@10 |
|---|---|---|---|---|---|
| BM25 | 4.77 | 6.83 | 10.21 | 17.84 | 3.71 |
| DeepCT | 7.58 | 10.24 | 14.22 | 22.68 | 6.04 |
| DPR | 6.79 | 11.92 | 21.02 | 42.55 | 4.53 |
分源完整表(Recall@5/20/100/1000 与 MRR@10):
| 数据源 | 模型 | R@5 | R@20 | R@100 | R@1000 | MRR@10 |
|---|---|---|---|---|---|---|
| 问诊记录 | BM25 | 4.91 | 6.99 | 10.37 | 17.97 | 3.82 |
| 问诊记录 | DeepCT | 7.60 | 10.28 | 14.28 | 22.85 | 6.06 |
| 问诊记录 | DPR | 6.79 | 11.91 | 20.96 | 42.32 | 4.52 |
| 百科 | BM25 | 4.58 | 8.71 | 17.82 | 39.91 | 3.10 |
| 百科 | DeepCT | 20.33 | 26.92 | 36.61 | 53.41 | 16.25 |
| 百科 | DPR | 16.01 | 27.25 | 45.33 | 78.30 | 11.20 |
| 图谱 | BM25 | 0.52 | 1.02 | 1.82 | 3.51 | 0.38 |
| 图谱 | DeepCT | 1.05 | 1.46 | 2.10 | 3.29 | 0.71 |
| 图谱 | DPR | 2.66 | 5.25 | 11.84 | 33.68 | 1.83 |
| ALL | BM25 | 4.77 | 6.83 | 10.21 | 17.84 | 3.71 |
| ALL | DeepCT | 7.58 | 10.24 | 14.22 | 22.68 | 6.04 |
| ALL | DPR | 6.79 | 11.92 | 21.02 | 42.55 | 4.53 |
分源来看(Recall@1000):问诊记录 BM25 17.97 / DeepCT 22.85 / DPR 42.32;百科 BM25 39.91 / DeepCT 53.41 / DPR 78.30;图谱 BM25 3.51 / DeepCT 3.29 / DPR 33.68。MRR@10 上 DeepCT 在问诊源(6.06)与百科源(16.25)均领先。
三条读数:
- 神经检索整体占优:DeepCT 与 DPR 全面超过 BM25,DPR 在大候选池深召回上优势最大——稠密模型赢在语义匹配,26M 池里 BM25 的字面匹配天花板极低。
- 26M 池的残酷性:问诊源 Recall@5 只有个位数,DPR 到 R@1000 才爬到 42.32——从数百万候选中精确命中一条答案本身就是难任务;图谱源 R@5 仅 0.52-2.66,因为模板问题彼此高度相似、正确答案大量假性重复。
- 指标低估了真实可用性:团队随机抽 100 问、用 DPR 取 top-5 检索结果,请 3 名全科医生判断是否有答案能直接回答问题——三源分别有 52%(问诊)、54%(百科)、42%(图谱) 的问题在前五检索结果中获得可用答案。原因:库内大量问答对语义相近,即使目标答案未被精确召回,排名靠前的答案往往也含相关医学信息。
4.2 生成基准:微调 T5 的 26.63 是对标线
实验设置:6,000 条官方 NLG 测试集;T5 与 GPT2 用 Huatuo-26M 全量训练集微调(T5 为 12 层中文 t5-pegasus,1 epoch、lr 1e-4、batch 8、问题/答案最大长度 256/512;GPT2 为 12 层中文 uer/gpt2-chinese-cluecorpussmall,1 epoch、lr 2e-5、batch 72);大模型组用 Huatuo-Lite 微调(统一 2 epochs、batch 32、lr 1e-5、cosine 调度 warm-up 0.03)。指标:BLEU-1/2/3/4、GLEU、ROUGE-1/2/L、Distinct-1/2。ChatGPT 以 API(gpt-3.5-turbo-0125)零样本参评。
结果精选(论文 Table 7,BLEU-1 口径):
| 组别 | 模型 | BLEU-1 | ROUGE-1 | Distinct-2 |
|---|---|---|---|---|
| 小模型·无微调 | T5 | 0.33 | 0.67 | 0.02 |
| 小模型·无微调 | GPT2 | 10.04 | 14.26 | 0.22 |
| LLM·无微调 | Baichuan2-7B-Chat | 20.73 | 26.75 | 0.92 |
| LLM·无微调 | Qwen-7B-Chat | 18.94 | 29.03 | 0.87 |
| LLM·无微调 | HuatuoGPT | 20.59 | 28.36 | 0.93 |
| LLM·无微调 | ChatGPT (API) | 18.44 | 19.60 | 0.89 |
| 小模型·微调后 | T5 | 26.63 | 33.21 | 0.68 |
| 小模型·微调后 | GPT2 | 23.42 | 30.48 | 0.58 |
| LLM·微调后 | Qwen-7B-Chat | 27.30 | 29.82 | 0.92 |
| LLM·微调后 | ChatGLM3-6B | 25.65 | 29.37 | 0.93 |
| LLM·微调后 | HuatuoGPT | 25.39 | 28.75 | 0.95 |
| LLM·微调后 | InternLM-7B-Chat | 23.36 | 30.32 | 0.86 |
| LLM·微调后 | Baichuan2-7B-Chat | 22.52 | 28.80 | 0.94 |
| LLM·微调后 | DISC-MedLLM | 21.52 | 27.99 | 0.97 |
(微调后 LLM 组其余模型:InternLM BLEU-2/3/4 = 12.99/7.71/4.60 等,完整表见论文。)
四条读数:
- 微调收益巨大:T5 从 0.33 到 26.63、GPT2 从 10.04 到 23.42——任务难度高到零样本几乎不可用,微调是必须的。
- 12 层 T5 微调后 BLEU-1 26.63 压过所有微调前的 LLM(最高 20.73),也被微调后的 Qwen-7B(27.30)反超——「领域微调的小模型」与「通用大模型」在此任务上互有胜负。
- ChatGPT 零样本 BLEU-1 仅 18.44、ROUGE-1 19.60——参考基指标对「合理但与标准答案措辞不同」的回答不利,论文明确提示大模型结果需医学专家进一步评估,不能只看 BLEU。
- 任务仍然困难:论文结论是医疗领域专家知识密度高于通用域,加上答案长、生成「完全命中参考答案」难,整体指标偏低是任务性质而非模型缺陷。
- 解码配置影响可比性:LLM 组统一 temperature 0.5/top-p 0.7/repetition penalty 1.2/max 1024、三次采样取均值——复现时任何一项改动都会带来分数漂移,跨论文对比先核解码配置。
4.3 复测与引用守则
- 引检索数字先声明所用划分(90/10 还是 99/1)与候选池范围(论文含训练集答案入池);
- 引生成数字先声明测试集(6,000 条官方集)与微调数据(T5/GPT2 吃全量、LLM 吃 Huatuo-Lite——两组不互比);
- ChatGPT 的 API 版本(gpt-3.5-turbo-0125)要注明——不同版本的分数不可跨表混用;
- 三个人工评估数字(52%/54%/42% 可用答案率、71%/88%/79% 答案准确率、95% 完整性)分属三个不同实验,勿混引。
4.4 检索实验的中文工程细节
三个检索基线的中文适配各有可迁移的细节:
- BM25 用单字符索引而非分词索引:论文明确「以单字符为单元建索引」并基于 Lucene 实现(k1=1.2、b=0.9)。动机是绕开中文分词器的误差传播——医疗文本里的「鼻中隔偏曲」「房室传导阻滞」等专业词极易被通用分词器切碎,单字索引牺牲匹配精度换取召回稳定。做中文医疗检索对比实验时,这一细节必须显式声明,否则 BM25 数字不可比。
- DeepCT 的词权重学习:用 bert-base-chinese 做上下文感知的词重要性估计,训练 3 epochs、lr 2e-5、batch 72、最大序列长 256。它在 MRR@10 上全库领先(6.04 vs DPR 4.53),说明「排序质量」与「深召回」是两种能力——稠密模型赢 R@1000,稀疏改进模型赢头部排序。
- DPR 的负例策略:batch-negative(batch 192)外加 BM25 负例,2 epochs、lr 1e-5。26M 候选池下的难负例采样是深召回成绩的关键;论文附录 H.1 有完整配置。
- 检索人评的设计:52%/54%/42% 的「top-5 可用答案率」由 3 名全科医生对 DPR top-5 逐问判定——这是对「指标与体感脱节」问题的直接回应,也提示复现者:在高度冗余的大池子里,Recall@k 低不等于检索结果不可用。
§5 四大应用:同一个数据集的四种用法
5.1 应用 I:医疗 LLM 的微调数据(Huatuo-Lite 上场)
设置:用 Huatuo-Lite(177,703 条)微调两个代表性医疗大模型——HuatuoGPT-7B 与 DISC-MedLLM-13B(2 epochs、batch 32、lr 1e-5、Adam、cosine warm-up 0.03);用五个知识基准评测:CMB-Exam(中文综合性医学多选)、CMExam(中国医师资格考试 6 万+ 题)、CMMLU(Med 子集:解剖、临床、遗传、营养、中医、病毒学等)、C-Eval(Med 子集:临床与基础医学)、CMB-Clin(复杂病历会诊问答)。
结果(论文 Table 9):
| 模型 | CMB-Exam | CMExam | CMMLU (Med) | C-Eval (Med) | CMB-Clin |
|---|---|---|---|---|---|
| ChatGPT (API) | 43.26 | 46.51 | 50.37 | 48.80 | 4.53 |
| HuatuoGPT-7B | 28.81 | 31.08 | 33.23 | 36.53 | 3.97 |
| HuatuoGPT-7B (Huatuo-Lite) | 32.09 (+3.28) | 31.08 (+0.00) | 36.04 (+2.81) | 36.74 (+0.21) | 3.97 (+0.00) |
| DISC-MedLLM-13B | 37.51 | 37.98 | 38.73 | 40.07 | 3.58 |
| DISC-MedLLM-13B (Huatuo-Lite) | 41.56 (+5.05) | 42.48 (+4.50) | 44.02 (+5.29) | 46.67 (+6.60) | 3.67 (+0.09) |
三条读数:
- 0.6% 子集撬动显著提升:DISC-MedLLM 四个多选基准平均涨约 5 个百分点,C-Eval(Med) 涨 6.60——Huatuo-Lite 的质量优先策略(打分+润色)在小样本微调场景兑现了价值。
- HuatuoGPT 提升有限的原因:论文分析其系统提示要求回答「尽量丰富友好」,模型倾向先展开分析再给选项,对知识密集型多选题反而加剧幻觉、拖累选择题成绩;但它在 CMB-Clin(模拟真实场景的病历会诊)上依然显著领先——选择题与诊疗对话是两种能力。
- 与 ChatGPT 的差距仍在:微调后 DISC-MedLLM 41.56 vs ChatGPT 43.26 已很接近,但后者未做任何医疗微调——说明 Huatuo-Lite 能补知识短板,尚不足以反超前沿通用模型的底子。
5.2 应用 II:RAG 的外部知识库
设置:把 Huatuo-26M 当作 RAG(检索增强生成)的非参数记忆:先用库内数据训练中文 DPR 检索器,文档编码器对每条答案算嵌入、FAISS 建 MIPS 索引;对给定问题 q 检索最相近 QA 对拼进上下文,T5 生成(拼接后最大 400 token、10 epochs、batch 24、lr 3e-5)。T5 (Huatuo-26M) 指先在 Huatuo-26M 上预训、再到目标数据集微调的版本。
结果(论文 Table 11,cMedQA2 上 BLEU-1):T5 20.88 → T5-RAG 25.86 → T5 (Huatuo-26M)-RAG 31.85(ROUGE-1 37.01、ROUGE-2 19.23、BLEU-4 15.96)。webMedQA 上模式不同:T5-RAG 20.30、T5 (Huatuo-26M)-RAG 25.56——预训练+RAG 在 webMedQA 上反而比纯微调低近 6 个绝对点(31.47 → 25.56)。
读法:RAG 收益高度依赖目标数据集特性——cMedQA2 持续受益,webMedQA 则出现负迁移;论文把 cMedQA2 上「额外预训练带来约 3 个绝对点提升」归为正向证据,同时诚实记录了 webMedQA 的反向结果。把 Huatuo-26M 当 RAG 知识库的设计模板(DPR+FAISS+QA 对级拼接)可直接复用,效果需在自家任务上重验。实操上还有三点注意:检索粒度是「QA 对级」而非「文档级」,召回结果自带答案上下文,无需二次切分;拼接格式为 (qaug, aaug, q) 三段式、总长上限 400 token,复现时不要放宽(超长会挤压生成空间);问诊源答案为 URL 时,RAG 库应剔除该源或先用 Lite 版全文替代——把 URL 字符串当知识喂给生成器没有意义。
5.3 应用 III:零样本迁移的燃料
设置:直接拿在 Huatuo-26M 上预训的模型去别的问答数据集生成答案,不在目标集上做任何微调(对照 T5-CBQA 式设置);目标集为 cMedQA2(108,000 问 / 203,569 答)与 webMedQA(63,284 问)。
结果(论文 Table 12):
- cMedQA2:T5 零样本 BLEU-1 从 0.23 → 25.65(+25.42 绝对点);GPT2 从 9.96 → 23.34;
- webMedQA:T5 从 0.47 → 23.20(+22.73);GPT2 从 7.84 → 19.99;
- 最强证据:cMedQA2 上「只在 Huatuo-26M 训练、从未见过 cMedQA2 任何数据」的 T5,BLEU-1 25.65 超过在 cMedQA2 自身训练集上微调的 T5(20.88)。
读法:26M 语料封装的医学知识广度具备可迁移性——对没有目标域标注数据的场景(新科室、新语种扩展),Huatuo-26M 预训练是可行的冷启动方案。
5.4 应用 IV:生物医学模型的持续预训练语料
设置:以掩码语言模型(MLM)方式用 Huatuo-26M 继续训练 BERT-base 与 RoBERTa-base(hfl/chinese-roberta-wwm-ext 初始化;10 epochs、lr 5e-5、batch 64、问答拼接最大长度 256),再在 CBLUE(首个中文医疗语言理解评测平台)八任务上评测,对照 ZEN、MacBERT、MC-BERT 等中文医疗预训练模型。
结果(论文 Table 13,CBLUE 测试集):
| 模型 | CMedEE | CMedIE | CDN | CTC | STS | QIC | QTR | QQR | Avg-ALL |
|---|---|---|---|---|---|---|---|---|---|
| BERT-base | 62.1 | 54.0 | 55.4 | 69.2 | 83.0 | 84.3 | 60.0 | 84.7 | 69.1 |
| BERT-base (Huatuo-26M) | 61.8 | 53.7 | 56.5 | 69.7 | 84.6 | 86.2 | 62.2 | 84.7 | 69.9 |
| RoBERTa-base | 62.4 | 53.7 | 56.4 | 69.4 | 83.7 | 85.5 | 60.3 | 82.7 | 69.3 |
| RoBERTa-large | 61.8 | 55.9 | 55.7 | 69.0 | 85.2 | 85.3 | 62.8 | 84.4 | 70.0 |
| RoBERTa-base (Huatuo-26M) | 62.8 | 53.5 | 57.3 | 69.8 | 84.9 | 86.1 | 62.0 | 84.7 | 70.1 |
| ZEN | 61.0 | 50.1 | 57.8 | 68.6 | 83.5 | 83.2 | 60.3 | 83.0 | 68.4 |
| MacBERT | 60.7 | 53.2 | 57.7 | 67.7 | 84.4 | 84.9 | 59.7 | 84.0 | 69.0 |
| MC-BERT | 61.9 | 54.6 | 57.8 | 68.4 | 83.8 | 85.3 | 61.8 | 83.5 | 69.6 |
头条结论:吃了 Huatuo-26M 的 12 层 RoBERTa-base 平均分 70.1,反超 24 层 RoBERTa-large 的 70.0,也比 MC-BERT-base 高 0.5 个百分点——证明该语料足够「富医学信息」,小参数量模型靠数据可对冲参数劣势。QIC(问句意图分类)与 QTR(问句术语召回)涨幅最明显(+0.6/+1.7 与 +0.2/+1.7 量级),与语料的问诊问题分布吻合。
读 Table 13 的三个提醒:
- 涨幅是全库平均意义上的——分任务看并非全面上涨(CMedIE 53.5 vs RoBERTa-base 53.7 微降、QTR 62.0 vs RoBERTa-large 62.8 未及大模型),「数据换参数」是平均结论不是逐任务保证;
- 对照组 ZEN/MacBERT/MC-BERT 的数字取自 CBLUE 官方网站(论文脚注声明),与自训模型的评测协议可能存在细节差异,跨组对比需保留余地;
- 12 层 vs 24 层的比较对象是 RoBERTa 架构内部,不能外推为「Huatuo-26M 预训练能替代模型规模」——它证明的是语料信息密度,不是缩放律的反例。
5.5 四应用选择指南
| 你的目标 | 用哪个部分 | 参考效果 |
|---|---|---|
| 微调 7B-13B 医疗对话模型 | Huatuo-Lite(177,703 条) | DISC-MedLLM CMB-Exam +5.05 |
| 搭医疗 RAG 知识库 | 全库(注意 consultation 答案为 URL) | cMedQA2 BLEU-1 25.86→31.85 |
| 无目标域数据的冷启动 | 全库做预训练再迁移 | cMedQA2 零样本 BLEU-1 0.23→25.65 |
| 训练医疗 BERT/RoBERTa | 全库做 MLM 持续预训练 | CBLUE Avg 69.3→70.1(12 层胜 24 层) |
| 评测检索/生成模型 | test 划分或 6,000 条官方测试集 | 见 §4 两表 |
5.6 实验配置速查表(复现直接抄)
论文附录 H 公开的全部关键超参,按实验分组(全部数字经论文附录 H 原文核对):
| 实验 | 模型/配置 | 关键超参 |
|---|---|---|
| 检索-BM25 | Lucene 实现 | 单字符索引、k1=1.2、b=0.9 |
| 检索-DeepCT | bert-base-chinese 词权重 | 3 epochs、lr 2e-5、batch 72、max len 256 |
| 检索-DPR | 双编码器 | batch-negative batch 192 + BM25 负例、2 epochs、lr 1e-5、warm-up+dropout 0.1 |
| 生成-T5 | 12 层中文 t5-pegasus | 全量训练集、1 epoch、lr 1e-4、batch 8、Q/A max 256/512 |
| 生成-GPT2 | 12 层 uer/gpt2-chinese-cluecorpussmall | 全量训练集、1 epoch、lr 2e-5、batch 72 |
| 生成-LLM 组 | Baichuan2/InternLM/Qwen/ChatGLM3/HuatuoGPT/DISC-MedLLM | Huatuo-Lite、2 epochs、lr 1e-5、batch 32、cosine warmup 0.03 |
| 生成-解码 | 全部 LLM | max len 1024、temperature 0.5、top-p 0.7、repetition penalty 1.2、3 returns 取均值 |
| 生成-ChatGPT | gpt-3.5-turbo-0125 | 零样本、random_sample=False |
| SFT 评测 | HuatuoGPT-7B / DISC-MedLLM-13B | 2 epochs、batch 32、lr 1e-5、Adam;病历问答 max 1024/温度 0.5/top-p 0.7/重复惩罚 1.2;多选 greedy/max 10 |
| RAG | T5 + 中文 DPR + FAISS MIPS | 拼接 max 400、10 epochs、batch 24、lr 3e-5 |
| CBLUE 预训练 | BERT/RoBERTa-base(hfl 中文权重) | MLM、10 epochs、lr 5e-5、batch 64、拼接 max 256 |
多选题的提示词(附录 J)也公开:中文指令「下面是一道关于医学知识的选择题,请直接回答正确选项,不需要任何分析」——禁止分析再作答的硬约束,正是 HuatuoGPT 在多选基准上提升受限的对照面(其系统提示鼓励详尽分析)。
5.7 同期中文医疗数据工程的横向定位
把 Huatuo-26M 放进 2023 年前后的中文医疗语料工程群像里,能看到三种不同的路线赌注:
- 规模路线(Huatuo-26M):自动抽取换规模(26M),质量靠分层筛选兜底——赌的是「下游有办法从大数据里筛出自己要的那层」;
- 精标路线(同团队后续的 medical-o1-reasoning-SFT 等):小规模、强结构、逐条校验——赌的是「SFT 数据在精不在多」(Huatuo-26M 自己的 Huatuo-Lite 实验就是这条路线的内部证明);
- 合成路线(ChatGPT 蒸馏类指令集):让 LLM 生成医疗问答——多样性好但医学可靠性依赖生成模型,论文作者选择的是「真实数据打底 + LLM 只做过滤与改写」的折中,明确不让 LLM 无中生有造医学内容。
Huatuo-26M 的独特生态位在「真实问诊分布」:它是当时唯一把中文在线问诊的真实问题分布(产科/儿科高频、口语化描述、多症状混杂)带进公开语料的大规模数据集——这一点是合成数据集与考试题库都替代不了的。论文词云里「宝宝」「发烧」「怀孕」这些词的高频出现,本身就是中国家庭健康关切的一面镜子;论文对生殖健康咨询高频的解读(线上问诊的去病耻感效应)则是数据社会学层面的附带发现。
三条路线的取舍没有绝对优劣,但有一条经验性观察:Huatuo-26M 用「真实数据打底」避开了合成语料最常见的「医学幻觉固化」问题——LLM 只被用来过滤、打分与改写,不被用来生成新的医学断言;这一设计选择与它 Apache 2.0 的彻底开放一起,构成其在 2023 年中文医疗数据工程中被广泛引用的两个核心理由。
§6 获取与许可:双版本架构的门怎么进
6.1 License 与双版本获取架构
全部发布物统一 Apache 2.0:GitHub 仓库 LICENSE 声明、五个 HuggingFace 仓库的 tags(license:apache-2.0)与数据卡 cardData 完全一致,无 license 冲突。
但「Apache 2.0 一行」之下藏着论文 Table 14 的双版本架构——这是获取 Huatuo-26M 唯一的真正门槛:
| 版本 | 问诊记录 | 百科 | 知识库 | 获取方式 |
|---|---|---|---|---|
| raw version | 仅问题+URL(无答案全文) | 全文 | 全文 | 完全公开(public-available) |
| full-text version | 全文 | 全文 | 全文 | 依申请:签署仅限研究用途协议的研究机构或大学 |
论文对 full-text 版不公开的理由写得直白:防止数据被某些公司或个人滥用(数据误用/滥用)。问诊内容涉及真实医患交互,全文敞开投喂商业模型存在合规风险;「URL 版」则把再抓取的责任与合规负担移交给使用者——这既保持了数据集的公开性与可发现性,又守住了原文站的权益边界。这套设计的实质是「分级公开」:知识性内容(百科/图谱)一步到位全公开,敏感性内容(问诊对话)分两档发放——它是同类涉及真实医患交互的语料中首批给出成文分发架构的。
由此产生的检索者第一困惑:load_dataset('FreedomIntelligence/huatuo_consultation_qa') 下载后发现 answer 字段是一个 URL(例如 https://www.51zyzy.com/question/detail/10391424.html)而非文本——这不是数据损坏,是设计如此(坑 6)。
6.2 HuggingFace 五仓导航(API 实测数据)
五个仓库均属 FreedomIntelligence 组织,均为 public、非 gated,datasets.load_dataset 直载:
| 仓库 | 内容 | 规模 | createdAt | lastModified | downloads/likes(抓取时点) | 存储 |
|---|---|---|---|---|---|---|
FreedomIntelligence/huatuo_knowledge_graph_qa |
知识图谱问答子集 | 798,444 条 | 2023-05-06 | 2023-07-07 | 386 / 52 | ~0.5GB |
FreedomIntelligence/huatuo_encyclopedia_qa |
医学百科问答子集 | 364,420 条(卡口径) | 2023-05-10 | 2023-05-17 | 825 / 92 | ~2.0GB |
FreedomIntelligence/huatuo_consultation_qa |
问诊问答子集(答案为 URL) | 25.3M 条量级 | 2023-05-10 | 2023-05-17 | 417 / 16 | ~8.7GB |
FreedomIntelligence/huatuo26M-testdatasets |
6,000 条 NLG 官方测试集 | 6,000 条 | 2023-05-17 | 2023-05-17 | 251 / 22 | ~26MB |
FreedomIntelligence/Huatuo26M-Lite |
精修子集(卡内名 Huatuo26M_v2) | 177,703 条 | 2023-10-11 | 2023-11-29 | 534 / 70 | ~2.8GB |
全部仓库 tags 统一为:task_categories:text-generation(Lite 另有 question-answering/text-classification/conversational)、language:zh、license:apache-2.0、arxiv:2305.01526、medical。注意 huatuo_consultation_qa 的 size_categories 标注自相矛盾(API tags 写 10M<n<100M、cardData 写 1M<n<10M)——实际 2,534 万条,两个区间都不准,别按平台标签估规模(坑 4)。
时间线一眼可见版本节奏:三个主子集 2023-05-06 至 05-17 密集上架(与 arXiv v1 同月)、测试集 05-17 补齐、Huatuo-Lite 2023-10-11 才出现(对应论文NAACL 版新增的 Lite 管线章节)、GitHub README 最后一次实质更新是 2024-03-14(加入 Huatuo-Lite 介绍与中文 README)。
6.3 实操:三种下载路径
路径一:HuggingFace 直载(推荐)
import datasets
# 子集一:知识图谱问答(798,444 条,全文)
kg = datasets.load_dataset('FreedomIntelligence/huatuo_knowledge_graph_qa')
# 子集二:医学百科问答(364K 条,全文)
enc = datasets.load_dataset('FreedomIntelligence/huatuo_encyclopedia_qa')
# 子集三:问诊问答(25M 条,answer 为 URL)
consult = datasets.load_dataset('FreedomIntelligence/huatuo_consultation_qa')
# 官方 NLG 测试集(6,000 条)
test = datasets.load_dataset('FreedomIntelligence/huatuo26M-testdatasets')
# 精修子集(177,703 条,含 score/label/related_diseases)
lite = datasets.load_dataset('FreedomIntelligence/Huatuo26M-Lite')
每个子集仓内含 train/validation/test_datasets.jsonl 三个分片(testdatasets 仓仅 test_datasets.jsonl;Huatuo26M-Lite 仓为单文件 format_data.jsonl)。
路径二:GitHub 仓库:github.com/FreedomIntelligence/Huatuo-26M 提供说明、加载代码、基准结果图(img/ 目录 retrieve.png/NLG.png/zero-shot.png/rag.png/cblue.png/sft.png)与引用格式;数据本体经 HuggingFace 分发。
路径三:SRIBD 官方镜像:dataset.sribd.cn/huatuo-26M.html 提供四部分 .jsonl 直链(合计 5.3GB)与数据示例,公开日期标注 2023.5——适合不走 HF 生态的批量下载。
full-text version 申请:论文与 README 均指向邮件联系(GitHub Issues 区与 xidongw@163.com),需以研究机构/大学名义签署「仅限研究用途」协议;无公开申请表单,响应流程未公开承诺——立项排期请预留沟通周期(坑 8)。
6.4 AI-Ready 评估:公开性换来了什么、丢了什么
- 可发现性(好):论文+GitHub+HF+SRIBD 四入口互链,HF tags 完整,搜索引擎与 HF 检索均易命中;
- 可获取性(分裂):四分之三的内容公开直链即得,唯独问诊答案全文被 URL 化——对「要真实医生答复文本」的研究者等效于只有四分之一可用,需要自建爬虫(受原站协议约束)或申请协议版;
- 可互操作(好):JSONL 标准格式+HF datasets 生态原生支持,字段极简(question/answer),Huatuo-Lite 补结构化字段;
- 元数据(中上):论文表格完备(规模/长度/质量分布/管线账目),HF 卡有数据示例与加载代码;扣分项是 size_categories 标注错误与卡-论文两处计数漂移;
- 可持续性(中):多平台分发冗余度高,但 GitHub 主仓 2024-03 后更新放缓,full-text 申请流程单点依赖邮箱。
综合判断:这是一套「AI-Ready 光谱」中偏公开端的数据集——比「论文-only、需邮件要数据」的多数医疗语料开放得多,比「全量 CC0 一键下载」的合成数据集多一道 URL 版的现实门槛。检索者按 5.5 的选择指南对号入座即可绕开大部分摩擦。
6.5 镜像与受限网络环境实操
在国内或受限网络环境下,三条路径的可用性差异明显:
- HuggingFace 主站:datasets 库支持
HF_ENDPOINT=https://hf-mirror.com环境变量整体切镜像,五个仓库名不变,load_dataset 代码零修改; - hf-mirror API:
/api/datasets/<org>/<name>路径返回权威元数据 JSON(含 cardData/tags/siblings),适合自动化采集与规模核查;网页路径(/datasets/…)会按访问 IP 地域重定向,抓取脚本应避开; - SRIBD 镜像:完全独立于 HF 生态的 .jsonl 直链,是离线环境与大文件批量下载的首选;缺点是没有 HF 的分片(split)抽象,需自行按文件名组织 train/validation/test。
三通道内容一致性:SRIBD 页面标注的规模与论文一致(train 完全一致,test 差 1,000 见坑 2);HF 仓为发布主渠道(最后更新 2023-05-17/11-29);GitHub 仓以说明与图示为主,数据本体经 HF 分发。自动化流程建议以 HF API 为元数据源、SRIBD 为文件源,双源交叉校验下载完整性。
§7 生态与影响:Huatuo 家族的起点
7.1 官方生态叙事:从数据到模型的完整栈
FreedomIntelligence(CUHKSZ FreedomAI Lab)在官方医疗 AI 生态页中把 Huatuo-26M 列为整条技术栈的「data」层起点,原话是它 “seeded the early HuatuoGPT training pipeline”(为早期 HuatuoGPT 训练管线播下种子)。生态链按官方叙事展开:
- Huatuo-26M(2023-05,数据层)→
- HuatuoGPT(2023,医疗对话模型;论文生成基准中被评对象之一,Zhang et al., 2023)→
- HuatuoGPT-II(one-stage 医疗适配,公开 checkpoint)→
- HuatuoGPT-o1(医疗复杂推理,medical-o1-reasoning-SFT 数据)→
- HuatuoGPT-Vision / PubMedVision(医学多模态,影像-报告-对话)→
- 深圳龙岗分诊/预问诊部署(真实医院工作流落地)。
在这个谱系里,Huatuo-26M 的角色是「中文医疗指令数据的可复用基底」:它本身不发布模型,但它定义的数据形态(中文问诊问答对)与加工范式(LLM 打分+润色)被后续模型线继承。
7.2 与 CBLUE 的双向关系
CBLUE 在 Huatuo-26M 论文里出现两次:一次是 Application IV 的评测基准(八任务,Table 13),一次是工具箱(RoBERTa 持续预训练的检验台)。反过来,Huatuo-26M 给 CBLUE 生态贡献了「QA 语料持续预训练可涨点」的证据——RoBERTa-base 70.1 分的成绩单成了「数据规模换模型性能」的典型案例。本库已收录 cblue 条目(rid 190),与 huatuo-26m 构成「基准平台 ↔ 语料供给」的互链对。
7.3 在中文医疗 QA 数据集景观中的位置
论文 Table 1 把 Huatuo-26M 放进医疗 QA 数据集全景(单位:问题数):
| 数据集 | 语言 | 来源 | 规模 |
|---|---|---|---|
| ChiMed (2019) | 中文 | 在线医疗论坛 | 47K |
| MedQA (2020) | EN&CH | 医学考试 | 60K |
| webMedQA (2019) | 中文 | 医疗咨询网站 | 63K |
| cMedQA2 (2018) | 中文 | 在线医疗论坛 | 108K |
| PubMedQA (2019) | 英文 | 文献问答 | 272K |
| Huatuo-26M | 中文 | 问诊+百科+知识库 | 26M |
| MS MARCO (2016) | 英文 | 网页搜索(通用域参照) | 1.0M |
| PAQ (2021) | 英文 | Wikipedia(通用域参照) | 65M |
两个数量级的领先使「largest medical QA dataset」的宣称在 2023 年发布时点成立——论文摘要的原话是 “the largest ever medical Question Answering (QA) dataset with 26 Million QA pairs”,比所有已列医疗数据集(含英文)都大。通用域参照(MS MARCO 1.0M、PAQ 65M)提醒我们它的绝对规模在通用 QA 面前并不夸张,但医疗域的高价值密度改变了等式的意义。
这张景观表还有一层阅读方式:按「来源类型」列看,前作们几乎全是单一来源(论坛 OR 考试 OR 文献),Huatuo-26M 是表内唯一的三源混合体——这既解释了它的规模(三个采集面同时铺开),也解释了它的统计异质性(§2.1 的长度画像三源迥异)。检索者引用「规模对比」时建议连来源类型一起呈现,避免造成「同质数据的单纯数量差」误读。
7.4 传播路径与社区使用
- 学术引用:论文同时以 arXiv(2023 起累计引用)与 NAACL 2025 Findings 双形态流通;GitHub citation 块沿用 v1 的 li2023huatuo26m 条目;
- 平台分发:HF 侧 downloads 四主仓合计约 2,400(抓取时点 2026-10-04),likes 合计 252——对中文垂类数据集属常规水位,说明其用户群稳定但非爆款;
- 镜像与转述:SRIBD 开放数据集页收录;GitHub 存在镜像仓库 sxm1129/Huatuo-26M(README 为旧版:9 人 citation、旧联系邮箱 anon2010@163.com)——查信息认准 FreedomIntelligence 组织源仓(坑 1);
- 下游教育传播:多个中文医疗 LLM 复现教程与开源项目把 Huatuo-26M/Huatuo-Lite 列为标准训练语料选项;非权威百科词条(如 newton.com.tw 华佗 GPT 词条)转述的部分数字(部署医院数、准确率等)无一手来源支撑,本条目不采信。
7.5 论文版本演变:v1 与 NAACL 版差异对照
同一工作相隔两年的两个版本差异不小,引用前对照清楚:
| 维度 | arXiv v1(2023-05-02) | NAACL 2025 Findings(2025-04) |
|---|---|---|
| 作者 | 9 人,Jianquan Li 一作,含 Prayag Tiwari | 12 人,Xidong Wang/Shunian Chen/Jianquan Li 共同一作,Tiwari 移除,新增 Shunian Chen/Yuxuan Zhu/Junying Chen/Anningzhe Gao |
| 总量表述 | 摘要「26 million」 | 贡献句精确 26,504,088 |
| 四大应用框架 | 零样本、RAG、预训练三类为主 | 扩为四类(新增 Application I:医疗 LLM 微调 + Huatuo-Lite 专节) |
| Huatuo-Lite | 无 | 完整管线(Table 8)+ 人评(Table 10)+ SFT 实验(Table 9) |
| 生成基准模型 | GPT2/T5 到 Baichuan2/ChatGLM3 | 增补 Qwen、InternLM、HuatuoGPT、DISC-MedLLM 对照 |
| 质量工程 | 基础清洗描述 | 四维标签体系 + 医师抽评 + 分类器化(附录 I) |
| 版本存续 | 仍为 v1(无 v2,无 HTML 版) | ACL Anthology 永久存档,开放获取 |
对检索者的含义:若引用「应用 I(医疗 LLM 微调)」「Huatuo-Lite」「质量标签」相关结论,必须引 NAACL 版——这些内容 v1 里不存在;v1 的 BibTeX(li2023huatuo26m)是 GitHub 官方 citation 块,作为格式惯例可用,但学术叙述请以 2025.findings-naacl.211 为准(坑 5)。
§8 方法学启示:四条可迁移的经验
8.1 「海量粗语料 + 小而精子集」的双轨结构是可复制的
Huatuo-26M 的结构创新不在采集而在分层:26M 条供检索/预训练/RAG 消费规模红利,177,703 条供 SFT 消费质量红利,两者由同一管线衔接(BGE 去重→LLM 打分→LLM 润色)。论文用 DISC-MedLLM +5.05 的成绩证明了「0.6% 精子集 ≈ 全量微调的上界」这一省算力路径。任何「爬到千万级但不敢直接喂模型」的领域都可以套这个模板。
8.2 知识图谱是低成本造 QA 对的模板机
80 万条图谱 QA 对来自 43 个人工模板+三份现成图谱,人工抽检 500 例几乎全对——这是整套数据中单位成本质量最高的部分。代价是问题分布由图谱结构决定(42 类疾病属性+1 类药品适应症)、答案风格单一(短列表)。适合当结构化补充与预训练语料,不适合当真实用户问题分布的样本。
8.3 「URL 版发布」是敏感爬取数据的折中范式
问诊数据涉及真实医患交互,全文本公开有版权与滥用风险,完全不公开则失去数据集的公共价值。Huatuo-26M 的解法是:问题文本公开(研究可用)、答案给 URL(可追溯)、全文走机构协议(可审计)。这一范式后来被多个中文对话数据集借鉴。它的副作用也要认:答案可用性从「下载即得」降为「再抓取或再申请」,直接损失了问诊源在生成式微调中的即时可用性(问诊源恰恰是最大、最贴近真实对话的部分)。
8.4 LLM 当数据工人的先声(2023 年的管线设计)
Huatuo-Lite 管线把 ChatGPT 同时当三类工人用:打分器(0-5 分质量过滤,与医师标注一致性 71/73)、扩容器(5-shot 扩展医师标注到 10K)、改写器(答案润色统一风格)。2023 年这套「LLM 过滤+改写 UGC 语料」的流水线是先行实践,其可靠性验证设计(医师种子→一致性盲测→分类器化)至今仍是可引用的对照样板。同时它也预演了这类管线的固有风险:打分器偏好的问题类型会重塑子集分布(长而完整的问题留存率天然更高,去重后平均问题长度从 44.6 跳到 75.6 即是证据)。
8.5 基准即贡献:数据集论文的第二条腿
很多数据集论文只交付「数据+基本统计」,Huatuo-26M 则交付了「数据+双基准+四应用」的完整评估包——检索(三种检索器×三个源×五档 k 值)、生成(九个模型×十项指标)、四类应用的端到端实验。这使后续工作无论从哪个角度切入(检索、生成、微调、预训练)都有现成对标线,也使数据集的「用法说明书」内嵌在论文里。代价是维护面变大:论文承认需要在线修订机制来持续纠错,而静态基准数字会随模型迭代过时。对新数据集作者的启示:交付评估包的边际成本远低于其带来的采用率收益。
§9 与库内条目的关系
9.1 家族图谱
- cblue(rid 190):中文医疗语言理解评测基准平台——Huatuo-26M 论文 Application IV 的评测台(Table 13 八任务),两库构成「基准平台 ↔ 语料供给」互链对。检索 CBLUE 预训练涨点实验时应同时看两卡。
- chinese-critical-care-database(rid 166,库内目录 Chinese-Critical-Care-DB):同为中文医疗文本类资源,与 Huatuo-26M 构成「中文医疗 NLP 语料」邻接;一个面向重症场景结构化数据、一个面向问诊问答文本,互补不重叠。
库内暂无但外部强相关的三类条目方向(供后续建条参考):HuatuoGPT 系列模型(同团队)、cMedQA2/webMedQA/ChiMed(中文医疗 QA 前辈数据集)、CMB/CMExam/CMMLU/C-Eval(论文用到的知识评测基准)。
9.2 检索路径建议
- 从 Huatuo-26M 找「中文医疗预训练/微调基准」:cblue(190);
- 找「HuatuoGPT 模型」:本库暂无该条目,外部入口 freedomintelligence.github.io 与 HF FreedomIntelligence 组织页;
- 找「其他中文医疗 QA 数据集」:库内暂无 cMedQA2/webMedQA/ChiMed 条目,外部入口见论文 Table 1 引文;
- 检索词组合:“Huatuo-26M”(注意连字符与 M 大写)+ “Chinese medical QA”;勿用 “HuatuoGPT dataset”(模型名≠数据集名,坑 1);Huatuo-Lite 精确仓名为 Huatuo26M-Lite(无连字符 h、大小写敏感)。
9.3 别名与拼写变体全表(检索覆盖用)
同一数据集在文献与平台上的变体写法,检索时建议全部覆盖:
| 变体 | 出现场景 | 备注 |
|---|---|---|
| Huatuo-26M | 论文、GitHub、官方叙述 | 标准名(含连字符、M 大写) |
| Huatuo26M | HF 仓名 huatuo26M-testdatasets、Huatuo26M-Lite | 无连字符变体 |
| Huatuo-26m / huatuo-26m | 部分转述与 slug 场景 | 小写 m 变体,搜索引擎一般归一 |
| 华佗数据集 / 华佗 26M | 中文转述 | 对应 Hua Tuo 命名 |
| Huatuo-Lite / Huatuo-Lite dataset | 论文 NAACL 版、README | 精修版叙述名 |
| Huatuo26M-Lite | HF 仓库名 | 大小写敏感(H 大写、M 大写) |
| Huatuo26M_v2 | HF 卡 pretty_name | 同一精修版的第三个名字 |
| huatuo_encyclopedia_qa / huatuo_knowledge_graph_qa / huatuo_consultation_qa | HF 子仓名 | 三个子集仓,非独立数据集 |
§10 避坑清单:八个已踩过的坑
坑 1:HuatuoGPT 是模型不是数据集,Huatuo-Lite 有三名。HuatuoGPT/HuatuoGPT-II/HuatuoGPT-o1/HuatuoGPT-Vision 全是 FreedomIntelligence 的模型;数据集只有 Huatuo-26M 一个本体。精修版一名三写:官方称 Huatuo-Lite、HF 仓库名 Huatuo26M-Lite、卡内 pretty_name Huatuo26M_v2——同一物,检索时三词都试。镜像仓 sxm1129/Huatuo-26M 的 README 是旧版(9 人 citation、旧邮箱),引用信息以 FreedomIntelligence 源仓为准。
坑 2:总量口径至少三套。arXiv v1 摘要/GitHub 标语「26 million」、NAACL 版精确值 26,504,088(Train 26,239,047 + Test 265,041)、SRIBD 镜像 train 26,239,047 + test 264,041(比论文少 1,000)。正式引用一律用 NAACL Table 3 的 26,504,088;发现来源写「264,041 test」时注明系镜像页口径。
坑 3:两个「测试集」不是一回事。论文 Table 3 的 Test 265,041 条是按源划分(百科/图谱 90:10、问诊 99:1)的检索评测集;HF 仓 huatuo26M-testdatasets 的 6,000 条是多源随机抽样的 NLG 生成评测集。复现检索实验用前者口径,复现生成实验必须用后者,混用则数字全错。
坑 4:平台标注与论文数字漂移。encyclopedias 子集论文 364,066 vs HF 卡描述 364,420(差 354);huatuo_consultation_qa 的 size_categories 在 API tags(10M<n<100M)与 cardData(1M<n<10M)之间自相矛盾,且两者都不覆盖实际的 25.3M。自动化采集请以论文 Table 3 为准、HF 标签仅作辅助。
坑 5:作者名单两个版本。arXiv v1(与 GitHub citation 块 li2023huatuo26m)为 9 人、Jianquan Li 一作、含 Prayag Tiwari;NAACL 2025 正式版为 12 人、Xidong Wang/Shunian Chen/Jianquan Li 三人共同一作、Tiwari 移除、新增 Chen/Yu/Gao 等。学术引用惯例可用 v1 BibTeX,但叙述作者贡献与机构时以 NAACL 版为准。
坑 6:consultation 下载后 answer 是 URL。公开 raw version 中问诊子集答案字段为原站链接(51zyzy.com),非文本——这是官方防滥用设计而非数据缺陷。需要全文要么按 URL 自行抓取(注意原站 robots 与服务条款),要么走 full-text version 机构协议申请。把「answer 字段是链接」当 bug 报 issue 前先读论文 §2.3 与 Table 14。
坑 7:质量数据别只挑单维。全库四维标签里 Professionalism Good 仅 31.53%(Medium 67.98%),而 Fluency Good 78.05%——只引后者会系统性高估语料的术语密度;只引前者会低估可用性。正确姿势是四维并报,并注明这些是 72%-77% 准确率的自动化分类标签而非人工金标;三源医师抽评准确率(71%/88%/79%)与 Huatuo-Lite 人评(零 Poor)是三套不同实验,不可互相替代。
坑 8:full-text 申请无公开表单。论文只写「sign an agreement for research purposes only」,README 指向邮件(xidongw@163.com)与 GitHub Issues;无表单、无 SLA、无已批准机构名单。立项依赖 full-text 数据时预留数周沟通期,并先用 raw version + 百科/图谱子集搭管线过渡。
坑点使用总则:八个坑分两类——坑 1/2/3/5 是「名字与口径」类,踩中的表现是检索不到或引用错数字,解法是回到本文 INFOBOX 与附录 J 对齐口径;坑 4/6/7/8 是「预期落差」类,踩中的表现是下载后与预期不符或质量误读,解法是动手前读一遍 §6 与 §3。自动化流程接入前,建议把附录 J 的口径表直接抄进配置文件。
§11 总结
11.1 三句话总结
- Huatuo-26M 用三源自动抽取把中文医疗问答抬到 26,504,088 条(两个数量级于此前所有医疗 QA 数据集),以 Apache 2.0 公开,但问诊子集答案以 URL 形式发布、全文需机构协议申请。
- 它的价值由双轨结构兑现:26M 粗语料喂检索、RAG 与持续预训练(RoBERTa-base 在 CBLUE 拿 70.1 超 RoBERTa-large),0.6% 精修子集 Huatuo-Lite 喂 SFT(DISC-MedLLM 多选基准平均 +5 分)。
- 质量工程诚实分层:医师抽评三源准确率 71%/88%/79%,全量数据可能含错(论文自述),自动化质量标签与 6,000 条官方测试集为下游提供了可对标的评估基础设施。
一句话版本:它是中文医疗 NLP 的「数据断层填补者」——用真实问诊的规模、权威百科的深度、知识图谱的结构三层拼图,把「中文医疗大模型缺粮」从常态变成了历史,代价与质量边界也都在论文里写得明明白白。
11.2 适合谁
- 要训练/微调中文医疗对话模型、需要大规模真实问诊语料的团队(主用 Huatuo-Lite + 百科/图谱全文);
- 搭医疗 RAG 系统需要中文 QA 知识库的工程师(用全库,注意 URL 处理);
- 做中文稠密检索(DPR 类)研究与评测的 NLP 研究者(26M 候选池是现成的大规模测试床);
- 训练中文医疗 BERT/RoBERTa 需要领域持续预训练语料的工程师;
- 研究「LLM 参与数据清洗/标注/改写」管线的方法学研究者(Huatuo-Lite 三步管线是完整公开的样板)。
11.3 不适合谁
- 需要「每条数据都经人工医学审核」的高可靠性场景——全量数据无法人工审核,问诊源答案准确率基线 71%;
- 需要问诊答案全文开箱即用、且无爬虫能力或机构身份的个人研究者——URL 版对这部分人是硬门槛;
- 需要英文或多语种医疗 QA 的项目——本库纯中文(language:zh);
- 需要患者级结构化信息(化验、影像、随访)的临床研究——这是纯文本问答对,无患者级临床变量;
- 期望图谱子集反映真实用户问题分布的分析——43 个模板决定其分布是人工设计的。
11.4 30 秒决策卡
- 只要百科+图谱全文做预训练/检索 → 直接 HF 下载,零门槛,Apache 2.0。
- 要问诊全文 → 先确认有机构身份;否则自测 URL 抓取的合规与可行性,或改用 Huatuo-Lite(含润色后的问诊源答案文本)。
- 要微调 7B-13B 医疗模型 → Huatuo-Lite 177,703 条起步,对照论文 Table 9 设定涨点预期(+3~+6.6)。
- 要跑检索/生成基准 → 检索用 265,041 test 口径、生成用 6,000 条官方集,勿混(坑 3)。
- 引用规模数字 → 26,504,088(NAACL Table 3),勿引 26 million 约数或镜像页变体(坑 2)。
11.5 一句话给三类人
- 给工程师:先
load_dataset('FreedomIntelligence/Huatuo26M-Lite')跑通 SFT 基线(对标 CMB-Exam +5),再决定是否为 RAG/预训练引入全量——consultation 仓 8.7GB,别在没想清 URL 处理方案前全量下载。 - 给研究者:检索与生成两条基准线(Table 5/7)都有公开配置可复现,最值得做的增量是「跨集去重后的严格迁移实验」与「质量标签的跨维度一致性标定」——论文自己留了这两个口子。
- 给决策者:这是中文医疗 NLP 的公共基础设施级语料,Apache 2.0 + 四入口分发使采用成本极低;唯一需要提前规划的合规项是问诊全文的使用边界(URL 版公开 / 全文版协议),以及「训练产物不得直接面向患者提供处方建议」的伦理红线。
FAQ(高频问答 41 问)
A. 基础认知
Q1:Huatuo-26M 的「26M」精确指多少?
26,504,088 条问答对(NAACL 2025 正式版 Table 3)。训练集 26,239,047、测试集 265,041。早期宣传口径「26 million」为约数。
Q2:名字里的「华佗」是什么来历?
论文原文:命名纪念中国东汉名医华佗(Hua Tuo),其生卒约在公元 200 年前后。同团队后续模型(HuatuoGPT 系列)延续这一命名家族。
Q3:这是第一个大规模中文医疗问答数据集吗?
是第一个到千万级的。此前最大中文医疗 QA 是 cMedQA2 的 108K,Huatuo-26M 比它大约 245 倍;论文宣称的「largest medical QA dataset」涵盖中英文在内(次大 PubMedQA 272K)。
Q4:数据是人工写的还是自动采集的?
自动采集+自动加工:问诊与百科从真实网站抓取,图谱问答由模板从知识图谱生成。人工参与在模板设计、抽检(500 例图谱验证、300 例医师评估)与质量标注种子(200 条标注取 146 条一致项)。
Q5:论文是谁写的,机构是什么?
NAACL 2025 Findings 版 12 位作者,来自香港中文大学(深圳)、深圳市大数据研究院与上海人工智能实验室;Xidong Wang、Shunian Chen、Jianquan Li 共同一作,通讯 Benyou Wang(王本友)。
Q6:发表记录可信吗,有正式同行评审吗?
有。预印本 arXiv:2305.01526(2023-05-02),正式版经 NAACL 2025 同行评审发表于 Findings of ACL: NAACL 2025(页 3828-3848),DOI 10.18653/v1/2025.findings-naacl.211。
Q7:数据集和 HuatuoGPT 模型什么关系?
同一团队的上下游:数据集是生态「data」层的起点,官方称其 “seeded the early HuatuoGPT training pipeline”;HuatuoGPT 模型在论文生成基准中也被作为被评对象。但两者是不同的发布物,别混名(坑 1)。
Q8:Huatuo-Lite、Huatuo26M-Lite、Huatuo26M_v2 是三个东西吗?
不是,是同一精修子集的三种名字:官方叙述用 Huatuo-Lite,HuggingFace 仓名 Huatuo26M-Lite,卡内 pretty_name 叫 Huatuo26M_v2。内容都是 177,703 条。
Q9:发表于 Findings 算不算「没中主会」?
Findings of ACL 系列是 ACL 常设的正式发表轨道(有同行评审、有 DOI、有 Anthology 永久存档),与主会论文的区别在于贡献定位而非质量审核缺失。对数据集类工作,Findings 是标准归宿之一。
Q10:数据集有 DOI 吗?
两个:arXiv DOI 10.48550/arXiv.2305.01526(预印本)与 ACL DOI 10.18653/v1/2025.findings-naacl.211(正式版)。数据本体无独立 DOI(未发现 Zenodo 存档),引用以论文 DOI 为准。
B. 数据与获取
Q9:三个子集分别从哪些网站/图谱来?
问诊子集来自在线医疗咨询网站 Qianwen Health(51zyzy.com);百科子集来自中文维基百科(8,699 疾病条目+2,736 药品条目)与同站 226,432 篇医疗文章;图谱子集来自 CPubMed-KG、39Health-KG、Xywy-KG 三个医学知识图谱。
Q10:JSONL 每行有哪些字段?
三个主子集:question(问题描述)与 answer(医生/专家回答;问诊子集为 URL 字符串)。Huatuo-Lite 的 format_data.jsonl 多四个:id、score(ChatGPT 质量分 0-5)、label(就诊科室,如眼耳鼻喉科)、related_diseases(相关疾病)。
Q11:Apache 2.0 意味着可以随便商用吗?
许可证层面 Apache 2.0 允许商用,但注意两点:full-text version 的发放附带「仅限研究用途」协议,其内容的使用以协议为准;论文伦理声明要求用该数据训练的模型不得直接向患者提供处方建议。公开 raw version 的商用边界建议自行做合规评估,尤其问诊数据再抓取环节。
Q12:为什么问诊子集只给 URL?
官方理由是防止数据被公司或个人滥用:问诊内容是真实医患交互,全文敞开有版权与伦理风险;URL 保留可追溯性,把全文获取的决定权交给使用者(自抓或申请协议版)。见论文 Table 14 双版本架构。
Q13:full-text version 怎么申请?
以研究机构/大学名义邮件联系团队(GitHub Issues 或 xidongw@163.com),签署仅研究用途协议。无公开表单与 SLA,建议立项时预留沟通周期(坑 8)。
Q14:HuggingFace 五个仓库怎么选?
做生成微调:Huatuo26M-Lite + 百科/图谱子集;做检索或 RAG:三个主子集全上;跑官方基准:huatuo26M-testdatasets(6,000 条)。仓库名大小写敏感(Huatuo26M-Lite 的 H 大写)。
Q15:国内环境下载有什么便利?
HF 镜像 hf-mirror.com 可代理 datasets 下载;SRIBD 官方镜像页(dataset.sribd.cn/huatuo-26M.html)提供四部分 .jsonl 直链共 5.3GB,可完全绕开 HF 生态。注意 hf-mirror 的网页路径(/datasets/…)会按 IP 重定向原站,API 路径(/api/datasets/…)稳定可用。
Q16:数据有版本号吗?
无正式版本号体系。以发布节点计:2023-05 主子集+测试集上架、2023-10/11 Huatuo-Lite 发布、2024-03 README 最后更新。HF 仓 lastModified 可查(主子集 2023-05-17 后未再动),数据内容基本冻结。
Q17:有验证集吗?
三个主子集仓内含 validation_datasets.jsonl 分片(train/validation/test 三分片结构)。注意 SRIBD 镜像页的元信息表把 val 列写为「-」、论文 Table 3 只报 Train/Test 两行——验证集存在于分片结构中但未在论文统计里单列,规模以实际文件为准。
Q18:能复现论文的 train/test 划分吗?
论文承诺公开抽取与处理脚本(“We will make the extraction and processing scripts public”),但未公开带随机种子的划分清单;检索口径按 90/10、99/1 自行划分即可复现量级,逐条对齐官方划分不可行——这也是官方另发 6,000 条固定测试集的原因。
C. 统计与基准
Q17:三源各占多少,为什么问诊占绝对大头?
问诊 25,341,578(95.6%)、图谱 798,444(3.0%)、百科 364,066(1.4%)。问诊抓取基数大(原始 3,167 万对),且它是最贴近真实医疗对话的语料——规模与价值双高。
Q18:原始抓取 3,167 万怎么变成 2,534 万?
两步标准清洗:正则表达式剔除含特殊字符的问答对(乱码/广告/格式残片)+ 哈希去重消除完全重复项。损耗约 633 万条。
Q19:问题与答案平均多长?
全库平均问题 44.6 字符、答案 120.7 字符。分源差异大:问诊 46.0/117.3、百科 11.5/540.4(问题即标题转写、答案即整段条目)、图谱 15.8/35.9(模板问句+短列表答案)。
Q20:数据质量标签怎么打的,可信吗?
3 名执业医师标注 200 条取 146 条一致项做种子,ChatGPT 5-shot 扩展到 10K,训练四个分类模型(流利度/相关性/完整性/专业性),测试准确率 76.86%/72.70%/75.60%/72.70%。这是自动化标签——做粗筛可信,当金标引用需注明误差(坑 7)。
Q21:医师对答案准确率的评价是多少?
每源抽 100 例×3 名执业医师:问诊 71%、百科 88%、图谱 79%。百科最高(权威条目文本)、问诊最低(真实对话带个体判断)。
Q22:检索基准里哪个模型最强?
DPR 的 Recall@1000 全库 42.55 最强(百科源达 78.30),MRR@10 上 DeepCT 略优(全库 6.04 vs DPR 4.53)。BM25 全线垫底(R@1000 17.84)。26M 候选池下小 k 检索极难(问诊源 R@5 个位数)。
Q23:生成基准里哪个模型最强?
微调后 Qwen-7B-Chat BLEU-1 27.30 最高,微调 T5 26.63 紧随(其 ROUGE-1 33.21 为全场最高);无微调组最强是 Baichuan2-7B-Chat 20.73,ChatGPT(gpt-3.5-turbo-0125)零样本 18.44。注意 T5/GPT2 吃全量训练集而 LLM 组吃 Huatuo-Lite,两组配置不同。
Q24:Huatuo-Lite 微调真的涨分吗?
DISC-MedLLM-13B 四个多选基准涨 4.50-6.60 分(CMB-Exam 37.51→41.56),HuatuoGPT-7B 涨 0-3.28 分(其系统提示要求回答丰富友好,多选题上先展开后作答拖累成绩,但 CMB-Clin 病历会诊仍领先)。与 ChatGPT 参照线(CMB-Exam 43.26)相比,微调后已接近但未反超。
Q25:零样本迁移那句「超过目标集微调模型」怎么理解?
在 cMedQA2 上,只在 Huatuo-26M 训练、从未见过 cMedQA2 任何数据的 T5,零样本 BLEU-1 25.65 高于在 cMedQA2 自己训练集上微调的 T5 的 20.88。解释是 26M 语料的医学知识广度与问题多样性覆盖了小数据集的分布——跨域冷启动场景的有效性证据。
Q26:CBLUE 涨点 0.8 值得吗?
平均分 69.3→70.1 的绝对值不大,但对比对象是参数量翻倍的 RoBERTa-large(70.0)与三个医疗特化预训练模型(MC-BERT 69.6/MacBERT 69.0/ZEN 68.4)——12 层小模型靠语料追平 24 层模型,这说明语料信息密度高,也是「数据换参数」的量化案例。
Q27:检索指标里的 Recall@k 与 MRR@10 具体怎么算?
Recall@k = 前 k 个候选中包含正确答案的查询比例(正确答案 = 与查询配对的原始答案);MRR@10 = 第一个相关文档排名倒数的均值,只看到第 10 位。候选池同时包含训练集与测试集的答案(论文 §3.1.1),即模型要在 26M+ 的完整池子里检索——复现时池子范围不同数字会差很多。
Q28:生成指标里的 Distinct-1/2 衡量什么?
衡量生成文本的多样性(unigram/bigram 去重比例)。有趣的是微调后模型的 Distinct 低于无微调 LLM(T5 0.68 vs Baichuan2 0.94)——微调让输出收敛到数据集风格、多样性下降,这是「对齐参考答案」与「保持多样性」的固有张力,读生成基准时应成对看「准确性(BLEU/ROUGE)×多样性(Distinct)」。
Q29:为什么论文说「医疗 QA 在预训练时代仍然困难」?
三重证据:微调后最强模型的 BLEU-4 也只有 8.46(T5);26M 候选池下 DPR 的 Recall@5 只有个位数;ChatGPT 零样本 ROUGE-1 19.60 低于很多微调模型。医疗答案的长文本、术语密度与个体化措辞使「精确命中参考答案」比通用 QA 难一个量级。
D. 生态与工程
Q27:想复现论文实验,超参在哪查?
论文附录 H:检索基线(BM25 Lucene k1=1.2/b=0.9 单字索引;DeepCT 3 epochs/lr 2e-5/batch 72/max 256;DPR batch 192+BM25 负例/2 epochs/lr 1e-5)、生成微调(T5 1 epoch/lr 1e-4/batch 8;GPT2 1 epoch/lr 2e-5/batch 72;LLM 组 2 epochs/lr 1e-5/batch 32/cosine warmup 0.03)、CBLUE 预训练(10 epochs/lr 5e-5/batch 64/max 256)。Huatuo-Lite 管线 prompt 在附录 K(打分与润色模板全文公开)。
Q28:这个数据集现在还更新吗?
数据主体 2023 年冻结(HF 主子集 lastModified 2023-05-17、Lite 2023-11-29),GitHub README 最后更新 2024-03-14(补 Huatuo-Lite 与中文说明)。论文 Limitations 提到计划建在线站供专家修订错误 QA,截至抓取时点未见上线。
Q29:用之前必须读论文哪几节?
§2(数据构建与统计——字段、划分、双版本架构)、§3.1(检索基准设置——候选池含训练集答案这个细节影响对比)、附录 B(数据下载与版本差异)。做生成评测再加 §3.2 与附录 H.2(微调配置)。
Q30:发现数据有错误怎么办?
论文欢迎通过 GitHub Issues 反馈(仓库 README 的 Contribution 节);问诊答案原文错误属来源网站内容,团队建议以在线修订机制解决(计划中)。引用具体条目做医学结论前,务必回溯原文核对——数据集定位是研究语料而非临床参考。
Q31:可以做商用向量检索/嵌入模型训练吗?
Apache 2.0 的公开部分(问题文本、百科/图谱全文、URL)许可上无商用障碍;问诊答案全文(URL 背后的内容)不在公开许可范围内,商用产品中使用需另行获得授权。用 Huatuo-26M 训练的嵌入/检索模型做医疗咨询产品时,还应遵守论文伦理声明的精神——不得把模型输出当处方建议直接交付患者。
Q32:HuggingFace 下载慢或失败怎么办?
三条备选:设置 HF_ENDPOINT=https://hf-mirror.com 走镜像代理;直接用 SRIBD 镜像页的 .jsonl 直链(合计 5.3GB);或从 GitHub 仓库取加载脚本后手动分流。consultation 仓 8.7GB 最大,建议单独限速下载。
Q33:想为数据集贡献修订或扩展,官方接受吗?
README 明确欢迎 Issue 与 Pull Request 形式的贡献(纠错、建议);论文 Limitations 提到的在线专家修订站(计划中)如上线,将是更系统的纠错通道。截至抓取时点以 GitHub Issues 为实际反馈渠道。
Q34:百科子集的 733 个标题模板意味着什么限制?
百科源的问题类型上限就是 733 个标题(如「用法用量」「禁忌」「诊断」),每类模板套不同实体。这使该源在「同一类问题、成百上千个实体」的意义上高度规整——做实体级知识抽取很好用;做问题多样性研究则要意识到它的问题分布是模板结构给定的。
Q35:问诊子集的原始 URL 还能访问吗?
URL 指向 51zyzy.com 的原始问答页,长期有效性无官方承诺(2023 年抓取的链接到 2026 年的存活率未标定)。学术复现建议尽早把所需页面的内容本地化存档(遵守原站协议),不要把 URL 当永久指针。
Q36:Huatuo-Lite 的 label 字段覆盖率如何?
论文未单独公布科室字段的覆盖率;从 SRIBD 示例看 label 为中文科室名(如「眼耳鼻喉科」)。按科室切片使用前建议先统计空值率与取值分布——该字段由管线生成,不是全量人工标注。
Q37:论文里「Recall@1000 才 42.55」说明检索没用吗?
恰恰相反——26M 候选池下 42% 的 R@1000 是合理量级(随机基线约 0.004%),且人评显示 top-5 有 42%-54% 的问题能拿到可用答案。这个「指标低但可用」的组合正是大规模冗余语料的检索特征:正确答案的近义版本排在周围。
Q38:能拿它训练通用(非医疗)对话模型吗?
技术上可以(Apache 2.0),但语料全是医疗单域——练通用对话会严重偏科。反过来,通用对话语料也补不了它的功能:医疗术语密度与问诊结构是它的独特资产。
Q39:如果只记一件事,该记什么?
分清双轨:全量 26M 是给检索和预训练的,Huatuo-Lite 177,703 条才是给 SFT 的——拿 URL 化的问诊全集直接微调对话模型是最常见的错误起点。
Q40:BIUE/ROUGE 在医疗长答案上可靠吗?
部分可靠。BLEU 系与 ROUGE 系衡量与参考答案的 n-gram 重合,医疗答案的合理措辞空间大——同一问题的两个都正确的回答可能重合度不高。论文自己的处理是「参考基指标+LLM 常给出合理但不同的答案,需医学专家进一步评估」——引用生成基准时建议同时报 BLEU-1/4 与 ROUGE-L,并避免把指标差当成医学质量差。
Q41:这个数据集会过时吗?
数据本体(2023 年的真实问诊语料)不会过时——历史语料的价值随时间不减反增;会过时的是论文的基准数字(2023 年的模型成绩单)与论文宣称的「最大」头衔(后续可能被更大规模数据集超越)。引用时区分「语料事实」(稳定)与「基准纪录」(时点性)即可。
事实清单(硬事实 36 条)
- 数据集名:Huatuo-26M;论文题名 Huatuo-26M, a Large-scale Chinese Medical QA Dataset。
- 预印本 arXiv:2305.01526 v1 提交于 2023-05-02 15:33:01 UTC,10,163 KB,提交人 Benyou Wang。
- 正式版:Findings of ACL: NAACL 2025,2025 年 4 月,页 3828-3848,Anthology ID 2025.findings-naacl.211,DOI 10.18653/v1/2025.findings-naacl.211。
- NAACL 版 12 位作者,Xidong Wang/Shunian Chen/Jianquan Li 共同一作;arXiv v1 为 9 人、Jianquan Li 一作、含 Prayag Tiwari。
- 三家机构:深圳大数据研究院(SRIBD)、上海人工智能实验室、香港中文大学(深圳);通讯 wangbenyou@cuhk.edu.cn。
- 总量 26,504,088 = Train 26,239,047 + Test 265,041;早期口径「26 million」;SRIBD 镜像 test 264,041。
- 问诊子集 25,341,578 条(原始抓取 31,677,604,正则清洗+哈希去重),来源 Qianwen Health(51zyzy.com)。
- 百科子集 364,066 条(HF 卡口径 364,420),材料为中文维基百科 8,699 疾病条目 + 2,736 药品条目 + 226,432 篇医疗文章,733 个唯一标题模板转换。
- 图谱子集 798,444 条,由 CPubMed-KG(40 关系/1.7M 实体/4.4M 三元组)、39Health-KG(6 关系/36.8K 实体/210.0K 三元组)、Xywy-KG(10 关系/44.1K 实体/294.1K 三元组)43 类模板生成。
- 图谱问答人工抽检 500 例,几乎全部正确。
- 全库平均问题 44.6 字符、答案 120.7 字符;分源:问诊 46.0/117.3、百科 11.5/540.4、图谱 15.8/35.9。
- 划分:百科/图谱 90% 训练+10% 测试;问诊等 99% 训练+1% 测试。
- 官方 NLG 测试集 6,000 条(多源随机抽样),HF 仓 huatuo26M-testdatasets,2023-05-17 发布。
- License:Apache 2.0(GitHub 与五个 HF 仓统一)。
- 双版本架构(论文 Table 14):raw version 公开(问诊仅问题+URL)、full-text version 仅向签研究协议的机构/大学开放。
- 五个 HF 仓库:huatuo_knowledge_graph_qa(2023-05-06)、huatuo_encyclopedia_qa(2023-05-10)、huatuo_consultation_qa(2023-05-10)、huatuo26M-testdatasets(2023-05-17)、Huatuo26M-Lite(2023-10-11,lastModified 2023-11-29)。
- HF 实测存储:consultation ~8.7GB、Lite ~2.8GB、encyclopedia ~2.0GB、KG ~0.5GB、test ~26MB;SRIBD 镜像合计 5.3GB。
- GitHub 仓库 FreedomIntelligence/Huatuo-26M;README 最后更新 2024-03-14;联系邮箱 xidongw@163.com。
- Huatuo-Lite = 177,703 条(约全集 0.6%):BGE 去重 26,239,047→1,316,730→ChatGPT 打分留 ≥4 分 237,127→润色 177,703。
- 去重细节:BAAI/bge-large-zh 嵌入、欧氏距离 <12 为邻、FAISS 检索、邻居上限 512、低频 <30 剔除、2-gram 词频距离 >0.2 排除。
- 打分分布:Score 0/1/2/3/4/5 = 3,076/248,256/466,459/361,383/212,827/24,300;打分器为 gpt-3.5-turbo-0125。
- 润色后平均答案 143.9 字符(原 120.7)、平均问题 80.1 字符(原 44.6)。
- 质量标注流程:3 医师标 200 条→146 条一致→ChatGPT(gpt-3.5-turbo)5-shot 扩到 10K→四个分类器准确率 76.86%/72.70%/75.60%/72.70%。
- 打分器可靠性:73 例盲测 71 例与医师全维一致。
- 全库标签分布:Fluency Good 78.05%、Relevance Good 76.01%、Completeness Good 58.42%、Professionalism Good 31.53%(Poor 均 <1%)。
- 医师抽评答案准确率:问诊 71%、百科 88%、图谱 79%(每源 100 例×3 名执业医师)。
- Huatuo-Lite 人评(100 例):Fluency Good 81% 零 Poor、Relevance Good 79%、Completeness ≥Medium 95%、Professionalism ≥Medium 97%。
- 检索基准(Table 5):全库 DPR R@1000 42.55/MRR@10 4.53;百科 DPR R@1000 78.30;图谱 DPR R@1000 33.68;问诊 DPR R@1000 42.32;BM25 全库 R@1000 17.84;DeepCT 22.68。
- DPR top-5 人评可用率:问诊 52%、百科 54%、图谱 42%(3 名全科医生判定)。
- 生成基准(Table 7):微调 T5 BLEU-1 26.63/ROUGE-1 33.21 全场 ROUGE 最高;微调 Qwen-7B-Chat BLEU-1 27.30;无微调组最高 Baichuan2-7B-Chat 20.73;ChatGPT 零样本 18.44。
- 应用 I(Table 9):Huatuo-Lite 微调使 DISC-MedLLM-13B CMB-Exam 37.51→41.56(+5.05)、CMExam +4.50、CMMLU +5.29、C-Eval +6.60;HuatuoGPT-7B CMB-Exam +3.28;ChatGPT 参照 43.26。
- 应用 II(Table 11):cMedQA2 上 T5-RAG 25.86→T5 (Huatuo-26M)-RAG 31.85 BLEU-1;webMedQA 上预训练+RAG 25.56 低于纯微调 31.47。
- 应用 III(Table 12):零样本 BLEU-1,cMedQA2 T5 0.23→25.65(超目标集微调 20.88)、webMedQA 0.47→23.20;GPT2 cMedQA2 9.96→23.34。
- 应用 IV(Table 13):RoBERTa-base (Huatuo-26M) CBLUE Avg-ALL 70.1 > RoBERTa-large 70.0 > MC-BERT 69.6 > RoBERTa-base 69.3 > MacBERT 69.0 > ZEN 68.4。
- Funding:深圳科技计划 JCYJ20220818103001002、深圳博士启动 RCBS20221008093330065、NSFC 天元 12326608、深圳跨模态认知计算重点实验室 ZDSYS20230626091302006、深圳稳定支持计划 2023。
- 伦理声明:模型训练产物限科研用途、不得直接向患者提供处方建议;论文 Limitations 承认 26M 无法全量人工审核、可能含错误医疗信息。
附录 A:速查卡
| 项 | 值 |
|---|---|
| 条目 slug | huatuo-26m |
| 官方名 | Huatuo-26M |
| 论文 | arXiv:2305.01526 → Findings of ACL: NAACL 2025(2025.findings-naacl.211) |
| 团队 | FreedomIntelligence(CUHKSZ + SRIBD + Shanghai AI Lab) |
| 总量 | 26,504,088 条 QA(Train 26,239,047 / Test 265,041) |
| 三源 | 问诊 25,341,578 / 百科 364,066 / 图谱 798,444 |
| 精修版 | Huatuo-Lite 177,703 条(0.6%) |
| License | Apache 2.0(raw 公开 / full-text 依协议) |
| 主入口 | HuggingFace FreedomIntelligence 五仓 + GitHub + SRIBD 镜像 5.3GB |
| 测试集 | 检索口径 265,041 / 生成口径 6,000 条官方集 |
| 双基准 | 检索 BM25/DeepCT/DPR;生成 BLEU/GLEU/ROUGE/Distinct |
| 关键对标 | DPR R@1000 42.55;T5 微调 BLEU-1 26.63;DISC-MedLLM +5.05;CBLUE 70.1 |
| 官方测试仓 | huatuo26M-testdatasets(6,000 条,2023-05-17) |
| 质量基线 | 医师抽评 71%/88%/79%;四维自动标签 72.70%-76.86% |
| 抓取时点 | 2026-10-04 |
| 库内互链 | cblue(190) / chinese-critical-care-database(166) |
附录 B:DAIMS 评估全表
| 维度 | 评分(1-10) | 依据 |
|---|---|---|
| D 可发现性 | 9 | 论文+GitHub+HF+SRIBD 四入口互链,HF tags 完整(language:zh/license/task_categories/arxiv);唯 HuatuoGPT/Huatuo-Lite 命名家族易混淆检索 |
| A 可获取性 | 7 | 四分之三内容公开直链(Apache 2.0,HF/GitHub/SRIBD 三通道);问诊答案全文 URL 化、full-text 版需机构协议申请——最大失分项 |
| I 可互操作 | 8 | JSONL 标准+HF datasets 原生支持,字段极简统一;Huatuo-Lite 补结构化字段(score/label/related_diseases);无官方转换脚本到其他 schema |
| M 元数据质量 | 7 | 论文表格完备(规模/长度/管线账目/质量分布),HF 卡有示例与加载代码;扣分:size_categories 标注错误、卡-论文两处计数漂移、SRIBD test 口径差 1,000 |
| S 可持续性 | 6 | 多平台分发冗余、arXiv+ACL Anthology 双存档;但数据 2023 年后冻结、GitHub 更新放缓、full-text 申请单点依赖邮箱、承诺的专家修订站未上线 |
| 综合评级 | 7.4/10(中上) | 公开性与文档质量高于医疗语料均值;可获取性被 URL 版与协议版双轨拖低,命名家族混淆与元数据漂移需检索者自行校准 |
评级解读:这个分数的分布不均匀——D/I 两维(9/8)接近满分档,A/M/S 三维(7/7/6)被「URL 双轨 + 元数据漂移 + 更新冻结」三项拖住。与库内均值对照,它的短板不在开放意愿而在数据敏感性处置,属于「高分但用前必须做功课」的类型;若 full-text 申请通道未来开放自助表单、size_categories 标注修正,综合评级可上探 8 分档。
附录 C:逐项证据链自证
| 关键数字 | 来源 | 位置 |
|---|---|---|
| 26,504,088 / 26,239,047 / 265,041 | 论文贡献句与 Table 3 | NAACL 2025 Findings PDF(ACL Anthology) |
| 31,677,604 → 25,341,578 | 论文 §2.1.1 | NAACL PDF 正文 |
| 8,699+2,736 条目 / 226,432 文章 / 733 标题 | 论文 §2.1.2 | NAACL PDF 正文 |
| 三图谱统计 1.7M/4.4M 等 | 论文 Table 2 | NAACL PDF |
| 798,444 / 43 类模板 / 500 例抽检 | 论文 §2.1.3、附录 F | NAACL PDF |
| 90/10 与 99/1 划分 | 论文 §3.1.1 | NAACL PDF |
| 检索基准全表 | 论文 Table 5 | NAACL PDF |
| 生成基准全表 | 论文 Table 7 | NAACL PDF |
| Huatuo-Lite 管线账目 | 论文 Table 8 与 §4.1 | NAACL PDF |
| CMB/CMExam 等 +5.05 | 论文 Table 9 | NAACL PDF |
| RAG 与零样本数字 | 论文 Table 11/12 | NAACL PDF |
| CBLUE 70.1 | 论文 Table 13 | NAACL PDF |
| 71%/88%/79% 医师评估 | 论文 §2.2 | NAACL PDF |
| Apache 2.0 | GitHub LICENSE 声明与 HF tags | 两平台实抓 2026-10-04 |
| 五仓 createdAt/lastModified/downloads | HF API(/api/datasets/<id>) | hf-mirror API 实抓 2026-10-04 |
| 364,420(HF 口径)与 825 downloads | HF 仓 huatuo_encyclopedia_qa 描述 | hf-mirror API 实抓 2026-10-04 |
| 6,000 条测试集说明 | HF 仓 huatuo26M-testdatasets 描述 | hf-mirror API 实抓 2026-10-04 |
| SRIBD 5.3GB / test 264,041 | dataset.sribd.cn/huatuo-26M.html | 官网抓取 2026-10-04 |
| arXiv v1 时间与作者 | arxiv.org/abs/2305.01526 | arXiv 页面抓取 2026-10-04 |
附录 D:数据获取决策树
需求是什么?
├── 训练/微调医疗对话模型(SFT)
│ ├── 算力有限(7B-13B)→ Huatuo26M-Lite(177,703 条,含科室/疾病字段)
│ ├── 想自建子集 → 三个主子集 + 复用论文附录 K 的打分/润色 prompt
│ └── 想按科室切分数据 → Lite 的 label 字段(先统计空值率,见 FAQ Q36)
├── 搭 RAG 知识库
│ ├── 只要百科+图谱 → 两个子集直载(全文,零门槛)
│ ├── 要问诊语料 → raw version(answer 为 URL)→ 评估自抓合规性或申请 full-text
│ └── 检索器选型 → 论文配置:中文 DPR(batch 192+BM25 负例)+ FAISS MIPS
├── 跑论文口径基准
│ ├── 检索 → 自按 90/10 或 99/1 划分(Table 3 test 口径)
│ │ └── 注意 BM25 用单字索引、候选池含训练集答案(§4.4)
│ └── 生成 → huatuo26M-testdatasets(6,000 条官方集)
│ └── T5/GPT2 吃全量、LLM 吃 Lite,两组别互比(§4.2)
├── 持续预训练 BERT/RoBERTa → 全库 MLM(论文配置:10 epochs/lr 5e-5/batch 64)
│ └── 对标线:RoBERTa-base 70.1 / RoBERTa-large 70.0(CBLUE Avg-ALL)
├── 跨域冷启动(无目标域标注)
│ └── 全库预训 → 目标集零样本(对标 cMedQA2 BLEU-1 25.65)
└── 只要规模数字做调研/引用 → 用 26,504,088(NAACL Table 3),口径注记见坑 2
附录 E:知识图谱模板选录与三源对照
E.1 43 类问题模板选录(全表见本条目附录 G):
| 实体类型 | 属性/关系 | 模板问句示例 |
|---|---|---|
| 疾病 | 症状 | [disease]的症状是什么? |
| 疾病 | 并发症 | [disease]的并发症是什么? |
| 疾病 | 病因 | [disease]的发病原因? |
| 疾病 | 就诊科室 | [disease]的就诊科室是什么? |
| 疾病 | 治疗方式 | [disease]的治疗方式是什么? |
| 疾病 | 治愈率 | [disease]的治愈率是多少? |
| 疾病 | 检查 | [disease]的检查有些什么? |
| 疾病 | 忌食 | [disease]忌食什么? |
| 疾病 | 传播途径 | [disease]的传播途径有些什么? |
| 疾病 | 高危因素 | [disease]的高危因素有些什么? |
| 疾病 | 辅助治疗 | [disease]的辅助治疗有些什么? |
| 药品 | 适应症 | [drug]能治疗什么疾病? |
模板特点:全部以主体实体(疾病/药品名)占位、按属性/关系填槽生成,共 42 个疾病模板 + 1 个药品模板;答案取图谱对象实体或属性值(常为分号分隔短列表,如「自体颗粒脂肪移植;自体脂肪移植;自体脂肪干细胞移植」)。
E.2 三源性格对照表:
| 维度 | 问诊记录 | 医学百科 | 知识图谱 |
|---|---|---|---|
| 规模 | 25,341,578 | 364,066 | 798,444 |
| 问题来源 | 真实患者提问 | 733 个标题模板转写 | 43 个图谱模板生成 |
| 答案形态 | 医生针对性回复(公开版为 URL) | 整段条目文本(均长 540.4) | 图谱条目短列表(均长 35.9) |
| 语言风格 | 口语化、带个人情境 | 正式、术语密集 | 规范、模板化 |
| 医师评估准确率 | 71% | 88% | 79% |
| 最佳用途 | 对话微调、RAG 语料 | 预训练知识注入 | 结构化问答、检索评测 |
| 主要局限 | 答案全文需 URL 抓取或协议 | 问题多样性受 733 标题限制 | 分布由图谱结构决定 |
三源不是替代关系而是拼图关系:问诊源给「中国人怎么问健康问题」,百科源给「权威知识怎么陈述」,图谱源给「医学属性怎么结构化」——去掉任何一块,Huatuo-26M 都只是又一个普通语料集;拼在一起,它才同时覆盖了真实分布、知识密度与结构规整三个维度。
E.3 Huatuo-Lite 与本体字段对照:
| 字段 | 三主子集 | Huatuo-Lite |
|---|---|---|
| question | 有 | 有(去重+打分筛选后) |
| answer | 有(问诊为 URL) | 有(GPT-3.5-turbo 润色后全文) |
| id | 无 | 有 |
| score | 无 | 有(ChatGPT 0-5 分,≥4) |
| label(就诊科室) | 无 | 有(如「眼耳鼻喉科」) |
| related_diseases | 无 | 有(如「鼻中隔偏曲」) |
E.4 Huatuo-Lite 样例 id 22647835 的逐字段解读:id(22647835)保留了母体训练集的编号空间痕迹,提示其源自 26M 原库的采样过程;score(5)是 ChatGPT 打分的最高档,代表问题完整、清晰、具体、无冗余;label(眼耳鼻喉科)来自管线标注的就诊科室,值域为中文科室名;related_diseases(鼻中隔偏曲)从问题与答案中抽取的结构化疾病锚点——这两个附加字段使 Huatuo-Lite 同时可用作 QA 语料、科室分类语料与疾病标签语料,是它与本体最大的功能性差异。
附录 F:常见错误用法对照
| 错误做法 | 后果 | 正确做法 |
|---|---|---|
| 把 HuatuoGPT 当数据集检索 | 命中的是模型仓库 | 检索 Huatuo-26M / FreedomIntelligence 组织页 |
| 引「26 million」或「264,041 test」 | 规模口径失真 | 引 26,504,088(NAACL Table 3)并注口径 |
| 用 6,000 条官方集跑检索实验 | 与论文检索数字不可比 | 按 90/10、99/1 自划分(论文 §3.1.1) |
| 拿 consultation 的 URL 字段当答案文本跑 SFT | 训练出「只会生成链接」的模型 | 用 Huatuo-Lite(润色后全文)或抓取/申请全文 |
| 只引 Professionalism Good 31.53% 或只引 Fluency Good 78.05% | 单维偏差 | 四维并报 + 注明自动化标签性质 |
| 用 hf-mirror 网页路径抓数据卡 | 被 IP 重定向落空 | 用 /api/datasets/<id> API 路径 |
| 预期 full-text 快速发货 | 排期风险 | 预留数周邮件沟通;先用 raw+百科/图谱过渡 |
| 把图谱子集当真实用户问题分布 | 分布结论失真 | 注明 43 模板生成属性,问诊源才代表真实分布 |
本附录与 §10 的分工:§10 的八个坑是「已知坑 + 存照」(含口径出处),本表是「错误做法 → 后果 → 正确做法」的速查形式——两者覆盖同一批风险,团队内培训用本表,写论文引用时查 §10。
附录 G:知识图谱 43 类问题模板全表(论文 Table 16)
42 个疾病模板 + 1 个药品模板,模板中的 [disease]/[drug] 为占位符,答案取图谱对应属性值或对象实体:
| # | 实体类型 | 属性/关系 | 模板问句 |
|---|---|---|---|
| 1 | 疾病 | 症状 | [disease]的症状是什么? |
| 2 | 疾病 | 并发症 | [disease]的并发症是什么? |
| 3 | 疾病 | 简介 | [disease]的简介是? |
| 4 | 疾病 | 预防 | [disease]的预防措施有哪些? |
| 5 | 疾病 | 病因 | [disease]的发病原因? |
| 6 | 疾病 | 发病率 | [disease]的患病比例是多少? |
| 7 | 疾病 | 就诊科室 | [disease]的就诊科室是什么? |
| 8 | 疾病 | 治疗方式 | [disease]的治疗方式是什么? |
| 9 | 疾病 | 治疗周期 | [disease]的治疗周期多长? |
| 10 | 疾病 | 治愈率 | [disease]的治愈率是多少? |
| 11 | 疾病 | 检查 | [disease]的检查有些什么? |
| 12 | 疾病 | 多发群体 | [disease]的多发群体是? |
| 13 | 疾病 | 药物治疗 | [disease]的推荐药有哪些? |
| 14 | 疾病 | 忌食 | [disease]忌食什么? |
| 15 | 疾病 | 宜食 | [disease]宜食什么? |
| 16 | 疾病 | 死亡率 | [disease]的死亡率是多少? |
| 17 | 疾病 | 辅助检查 | [disease]的辅助检查有些什么? |
| 18 | 疾病 | 多发季节 | [disease]的多发季节是什么时候? |
| 19 | 疾病 | 相关症状 | [disease]的相关症状有些什么? |
| 20 | 疾病 | 发病机制 | [disease]的发病机制是什么? |
| 21 | 疾病 | 手术治疗 | [disease]的手术治疗有些什么? |
| 22 | 疾病 | 转移部位 | [disease]的转移部位是什么? |
| 23 | 疾病 | 风险评估因素 | [disease]的风险评估因素有些什么? |
| 24 | 疾病 | 筛查 | [disease]的筛查有些什么? |
| 25 | 疾病 | 传播途径 | [disease]的传播途径有些什么? |
| 26 | 疾病 | 发病部位 | [disease]的发病部位是什么? |
| 27 | 疾病 | 高危因素 | [disease]的高危因素有些什么? |
| 28 | 疾病 | 发病年龄 | [disease]的发病年龄是多少? |
| 29 | 疾病 | 预后生存率 | [disease]的预后生存率是多少? |
| 30 | 疾病 | 组织学检查 | [disease]的组织学检查有些什么? |
| 31 | 疾病 | 辅助治疗 | [disease]的辅助治疗有些什么? |
| 32 | 疾病 | 多发地区 | [disease]的多发地区是哪里? |
| 33 | 疾病 | 遗传因素 | [disease]的遗传因素是什么? |
| 34 | 疾病 | 发病性别倾向 | [disease]的发病性别倾向是啥? |
| 35 | 疾病 | 放射治疗 | [disease]的放射治疗有些什么? |
| 36 | 疾病 | 化疗 | [disease]的化疗有些什么? |
| 37 | 疾病 | 临床表现 | [disease]的临床表现有些什么? |
| 38 | 疾病 | 内窥镜检查 | [disease]的内窥镜检查有些什么? |
| 39 | 疾病 | 影像学检查 | [disease]的影像学检查有些什么? |
| 40 | 疾病 | 相关(导致) | [disease]会导致什么样的结果? |
| 41 | 疾病 | 治疗后症状 | [disease]的治疗后症状是什么? |
| 42 | 疾病 | 相关(转化) | [disease]会转化成什么? |
| 43 | 药品 | 适应症 | [drug]能治疗什么疾病? |
附录 H:医疗 QA 数据集全景对照(论文 Table 1 医疗组)
| 数据集 | 年份 | 语言 | 来源 | 规模(问题数) |
|---|---|---|---|---|
| LiveQA | 2018 | 英文 | 美国国立卫生研究院(NIH) | 0.7K |
| MedHop | 2018 | 英文 | MEDLINE | 2.5K |
| BiQA | 2020 | 英文 | 在线医疗论坛 | 7.4K |
| HealthQA | 2019 | 英文 | 医疗服务网站 | 7.5K |
| MASH-QA | 2020 | 英文 | 医疗文章网站 | 35K |
| MedQuAD | 2019 | 英文 | 美国国立卫生研究院(NIH) | 47K |
| ChiMed | 2019 | 中文 | 在线医疗论坛 | 47K |
| MedRedQA | 2023 | 英文 | Reddit AskDocs 版块 | 51K |
| MedQA | 2020 | 英中双语 | 医学考试 | 60K |
| webMedQA | 2019 | 中文 | 医疗咨询网站 | 63K |
| CliCR | 2018 | 英文 | 临床病例报告 | 100K |
| cMedQA2 | 2018 | 中文 | 在线医疗论坛 | 108K |
| MedMCQA | 2022 | 英文 | 医学考试 | 192K |
| PubMedQA | 2019 | 英文 | 在线医疗论坛 | 272K |
| Huatuo-26M | 2023 | 中文 | 问诊记录+百科+知识库 | 26M |
通用域参照(同一 Table 1):TriviaQA 96K、HotpotQA 113K、SQuAD 158K、DuReader 200K、Natural Questions 323K、MS MARCO 1.0M、CNN/Daily Mail 1.3M、PAQ 65M——Huatuo-26M 在医疗组内断层领先,绝对规模介于 MS MARCO 与 PAQ 之间。
附录 I:评测提示词结构(论文附录 J/K 公开)
多选题评测 prompt(应用 I 与生成基准的知识评测用):
下面是一道关于医学知识的选择题,请直接回答正确选项,不需要任何分析.
{问题}
{选项}
正确答案是:
The following is a multiple-choice question about medical knowledge.
Please answer the correct option directly without any analysis.
{Question}
{Options}
The correct answer is:
Huatuo-Lite 打分 prompt 骨架(完整 1-5 分档定义见 §3.6):要求模型「先输出评分理由,最后一行写 Score: <score>」,评分对象是问题文本,判据为完整性/清晰度/信息充分性/无链接与推广内容。
Huatuo-Lite 润色 prompt 骨架:系统提示定义医疗问答助手角色(仅答医疗、不答医院/医生/品牌导向、可参考不必照抄参考答案),用户消息给出 Question 与 Reference Answer,要求输出 Thought(对参考答案的判断)与 Answer(重写后的答案)两部分。
三份 prompt 的公开使 Huatuo-Lite 管线成为少数「全要素可复现」的 LLM 数据加工样板——从打分档位定义到改写行为约束均有一手文本可查。
附录 J:数值口径速查表(一页对齐所有关键数字)
自动化处理与本条目交叉引用时,按下表口径对齐(来源缩写:P=NAACL 2025 论文,HF=HuggingFace API 实抓,SR=SRIBD 镜像页,GH=GitHub README):
| 数字 | 值 | 口径来源 | 冲突注记 |
|---|---|---|---|
| 总量 | 26,504,088 | P(Table 3/贡献句) | 「26 million」=GH/v1 约数 |
| Train | 26,239,047 | P/SR 一致 | 无冲突 |
| Test(检索口径) | 265,041 | P | SR 写 264,041(差 1,000) |
| Test(NLG 口径) | 6,000 | HF/GH/P | 与 265,041 是两回事 |
| 问诊子集 | 25,341,578 | P(Table 3) | 原始 31,677,604 |
| 百科子集 | 364,066 | P | HF 卡 364,420(差 354) |
| 图谱子集 | 798,444 | P/HF 一致 | 无冲突 |
| Huatuo-Lite | 177,703 | P/HF 一致 | 约全集 0.6% |
| 去重后 | 1,316,730 | P(Table 8) | 打分后 237,127 |
| 平均问题/答案长度 | 44.6/120.7 | P(Table 3) | 分源见 §2.1 |
| DPR R@1000(ALL) | 42.55 | P(Table 5) | MRR@10 4.53 |
| 微调 T5 BLEU-1 | 26.63 | P(Table 7) | ROUGE-1 33.21 |
| 微调 Qwen BLEU-1 | 27.30 | P(Table 7) | LLM 组最高 |
| DISC-MedLLM CMB-Exam | 37.51→41.56 | P(Table 9) | +5.05 |
| 零样本 cMedQA2 BLEU-1 | 0.23→25.65 | P(Table 12) | 超目标集微调 20.88 |
| CBLUE Avg-ALL | 70.1 | P(Table 13) | RoBERTa-large 70.0 |
| 医师评估准确率 | 71%/88%/79% | P(§2.2) | 问诊/百科/图谱 |
| 质量分类器准确率 | 72.70%-76.86% | P(附录 I) | 四维各一 |
| license | Apache 2.0 | GH/HF 一致 | full-text 另附研究协议 |
| HF 主仓发布窗口 | 2023-05-06 至 05-17 | HF(createdAt) | Lite 2023-10-11 |
| GitHub README 更新 | 2024-03-14 | GH(commit 记录) | 最后实质更新 |
附录 K:条目编写过程与来源留痕(审计用)
编写信息:本条目由写手代理 agent-c-huatuo26m 于 2026-10-04 编写;开工三查(租约锁、私有区唯一化、进程留痕)与 slug 查重(库内 url_name ILIKE '%huatuo%' 返回 0 行、writing/ 无同名目录)均在动笔前完成并留痕于工作目录。
一手来源清单(按证据权重排序):
- NAACL 2025 Findings 论文 PDF(aclanthology.org/2025.findings-naacl.211.pdf,21 页,2026-10-04 下载至本地并全文提取)——正文与 Table 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17 全部数字的最终依据;
- arXiv 摘要页(arxiv.org/abs/2305.01526,2026-10-04 实抓)——v1 提交时间戳、9 人作者列表、 subjects cs.CL/cs.AI;
- GitHub 官方仓库 README(github.com/FreedomIntelligence/Huatuo-26M,2026-10-04 实抓)——加载代码、benchmark 图目录、Apache 2.0 声明、citation 块、联系邮箱;
- HuggingFace API 实抓(hf-mirror.com/api/datasets/<id>,2026-10-04,四主仓+Lite 仓共 5 个 JSON)——createdAt/lastModified/downloads/likes/storage/tags/描述;encyclopedia 364,420 与 testdatasets 6,000 条等卡面数字均出于此;
- SRIBD 官方镜像页(dataset.sribd.cn/huatuo-26M.html,2026-10-04 实抓)——元信息表(train 26,239,047/test 264,041/5.3GB)、文件结构、数据示例、Huatuo-Lite 示例;
- OpenReview 存档 PDF(NAACL 版全文另一镜像,用于交叉核对 Table 7/8/9 数字);
- freedomintelligence.github.io 医疗 AI 生态页(2026-10-04 实抓)——HuatuoGPT 生态叙事与官方定位原文。
二手与排除来源:
- WebSearch 汇总(2026-10-04):深圳市大数据研究院官网页、ACL Anthology 条目页、deepwiki Awesome-Medical-Dataset 词条(确认 26,239,047 与三源构成)、alphaXiv 中文解读(用于定位论文论点,数字一律回溯原论文核对);
- 排除:newton.com.tw 華佗GPT 词条(含部署医院数、准确率等无一手来源数字,仅作生态背景线索不采信);GitHub 镜像仓 sxm1129/Huatuo-26M(旧版 README,仅作版本演变旁证)。
抓取环境注记:HuggingFace 主站与 hf-mirror 网页路径在编写环境中被 IP 地域重定向干扰,五个仓库的元数据全部改走 hf-mirror API 路径(/api/datasets/<id>)实抓——该路径返回权威 JSON,与主站数据一致;arXiv HTML 版不存在(v1 为 PDF only),论文全文以 ACL Anthology PDF + pdftotext 布局模式提取,表格数字经 OpenReview 版二次交叉核对。
附录 L:术语对照表(条目高频英文术语)
| 英文术语 | 本条目译法/写法 | 说明 |
|---|---|---|
| QA pairs | 问答对 | 数据集基本单元 |
| Online medical consultation | 在线问诊/在线医疗咨询 | 问诊子集来源类型 |
| Medical encyclopedia | 医学百科 | 百科子集来源类型 |
| Knowledge base / Knowledge graph | 知识库/知识图谱 | 图谱子集来源类型(论文混用 KB/KG) |
| Huatuo-Lite | Huatuo-Lite(不译) | 精修子集官方名 |
| Retrieval-augmented generation (RAG) | 检索增强生成 | Application II |
| Dense Passage Retrieval (DPR) | DPR(稠密段落检索) | 检索基线 |
| BM25 / DeepCT | 不译 | 稀疏检索基线 |
| Recall@k / MRR@10 | 不译 | 检索指标 |
| BLEU / ROUGE / GLEU / Distinct | 不译 | 生成指标 |
| Zero-shot transfer | 零样本迁移 | Application III |
| Continued pre-training | 持续预训练 | Application IV(论文亦写 continued training) |
| Masked language model (MLM) | 掩码语言模型 | Application IV 训练方式 |
| Fluency / Relevance / Completeness / Professionalism | 流利度/相关性/完整性/(医学)专业性 | 四维质量标签 |
| Hospital Department / Related Diseases | 就诊科室/相关疾病 | Huatuo-Lite 增列 |
| Full-text version / raw version | 全文版/原始版 | 双版本获取架构 |
| Findings of ACL: NAACL | Findings(不译) | 发表轨道 |
| License agreement | 使用协议 | full-text 申请要件 |
| De-identification / anonymous | 去标识/匿名 | 隐私处理语境 |
| CBLUE (Chinese Biomedical Language understanding Evaluation) | CBLUE 基准 | Application IV 评测台 |
术语使用总则:本条目中文为主、术语首现标英文;与论文原文表述有细微差异处(如「问诊记录」对应论文的 consultant records、「知识库」对应 knowledge bases)已在相应位置注明——跨语言检索时建议中英术语各试一轮,仅用中文检索会漏掉 GitHub/HF 上的英文页面,仅用英文检索会漏掉 SRIBD 中文页与中文社区讨论。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集,按相关度降序排列:
- medreason — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准 / 知识图谱
- healthsearchqa — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- claimify — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- pubmedqa — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- medqa — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- medmcqa — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- medicationqa — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- cmb-cmexam — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 评测基准
- disc-med-sft — 共享标签:医疗NLP / 医学问答与基准 / 医学问答 / 知识图谱
- qizheng-gpt — 共享标签:医疗NLP / 医学问答 / 评测基准 / 知识图谱
导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

