信息速览
INFOBOX — ACI-BENCH 一屏速览
维度 内容 本质 迄今最大的公开「就诊完整对话→临床病历」配对语料库 + 基准（角色扮演合成数据，非真实患者） 团队 Microsoft Health AI + University of Washington + Nuance Communications 三方共建；6 作者 论文 Nature Scientific Data 2023 Sep 6;10:586（doi:10.1038/s41597-023-02487-3；arXiv:2306.02022） 规模 207 段就诊对话-病历对（train 67 / valid 20 / test1 40 / test2 40 / test3 40） 子集 virtassist（虚拟助手唤醒词）/ virtscribe（虚拟抄写员）/ aci（纯自然对话）三模式 分部 SOAP 四连续分部：subjective / objective_exam / objective_results / assessment_and_plan 转录版本 humantrans（人工）/ asr（机器）/ asrcorr（人工校正 ASR）——按子集异构 对话长度 平均 52-58 轮、1231-1382 tok；病历平均 476-505 tok、47-50 句 标注 行医专家角色扮演 + 4 名医学标注者移除无依据文本（部分跨度重叠 F1 0.85）+ 内容验证 基准结论 分部生成 > 全病历生成（BART/LED 提升 1-14 分）；GPT-4 无微调 medcon 最高 57.78 挑战赛 MEDIQA-CHAT 2023（Task B/C）与 MEDIQA-SUM 2023（Task C）官方数据 许可与获取 CC BY 4.0（统一单层，含商用）｜Figshare + GitHub 直链公开 库内互链 MEDIQA（rid 220，姊妹集）、MIMIC-IV-Note（47）、i2b2/n2c2 NLP（14）、MedDialog（210）
ACI-BENCH 是一份"把医生说的话变成结构化病历"的公开考试卷。它做的事情听起来简单：给模型一段真实的医患对话，让它写出医生该写的那份病历。但在 2023 年之前，这件事没有足够大的公开数据来做——真实的就诊录音很少被保存，病历又是高度敏感的个人信息，无法公开共享。于是微软、华盛顿大学和 Nuance 三家机构合作用行医专家角色扮演的方式合成了 207 段完整就诊对话，配上对应的临床病历，一举成为该任务当时最大且最全面的公开语料库，并被 MEDIQA-CHAT 2023 与 MEDIQA-SUM 2023 两届共享任务选为官方测试数据。它对 AI-Ready 的意义在于：用合成数据绕开了隐私死结，再用 CC BY 4.0 彻底打开的许可，为"环境临床智能（ambient clinical intelligence）"这条赛道提供了第一块可复现的公共基石。
导语读法三则：
- 只想下数据：直奔 §6 获取与许可——Figshare 一个 zip + GitHub 代码，全程 CC BY 4.0 无门槛，是所有医疗 NLP 数据集里最省事的入口之一。
- 关心任务与标注：直奔 §2-§3——三子集的差别、SOAP 四分部的由来、以及"移除无依据文本"如何把合成数据洗成可信基准，是这份数据最值得学的部分。
- 想做 LLM 评测对标：直奔 §5 基准结果——GPT-4、BART、LED、Text-davinci-003 的 ROUGE/medcon 全套数字都已公开，可直接把自己的模型放进同一张表。
§0 导读：这个数据集解决什么问题
临床文档是医生日常最沉重的负担之一。电子健康记录（EHR）普及后，医生的打字时间反而增加：写病历耗时、往往是医患互动的干扰源，且病历质量受"复制粘贴"与时间压力拖累。一个自然的思路是——让 AI 听医生的问诊对话，自动起草病历，再由医生审阅。这个方向在 2020 年前后因三个条件成熟而升温：语音转文字（ASR）技术进步、EHR 在美国普及、以及 transformer 模型崛起。
但这条路撞上一堵墙：没有足够大、能公开分享的"对话-病历"配对数据。原因有两重——就诊录音通常不保存；病历高度敏感，无法合乎伦理地公开。私营公司可以自建私有数据，但结果与算法无法被系统比较；大语言模型（如 ChatGPT/GPT-4）虽然表现出通用能力，但没有公共数据集，科学界就无法理解其强弱与未来方向。
ACI-BENCH 的回答是：用角色扮演合成数据绕开隐私死结。由医学专家（医生、医师助理、医学抄写员、临床信息学家）按真实就诊经验扮演医患对话，再用自动病历生成系统起草、领域专家重写、医学标注者移除无对话依据的文本。最终产出 207 段"对话-病历"对，覆盖三种 AI 辅助临床文档模式（虚拟助手、虚拟抄写员、纯自然对话），并把病历规范化为 SOAP 四个连续分部，以便训练与评测。这套数据被 ACL ClinicalNLP 的 MEDIQA-CHAT 2023 与 CLEF 的 MEDIQA-SUM 2023 采纳为官方任务数据，并附上一批当前最优方法的基准成绩。
§0 读法三则：
- 这个条目是"数据集 + 基准 + 共享任务基础设施"三合一：本体是 207 段对话-病历对，配套是 5 类基线模型与 4 类评估指标，外延是两届 MEDIQA 挑战赛的官方测试集（§5）。
- 全文数字均出自 Nature 正文与表格；唯一需要留意的是"规模口径"——官方 207 encounters 与某些 RL 环境转出的 359 tasks 不是一回事（坑 4）。
- 检索时注意官方论文标题把小写 aci-bench 与仓库大写 ACI-BENCH 混用，二者指同一数据集（坑 1）。
§1 数据集速览：十问十答
Q1：ACI-BENCH 的 207 段从哪来？
全部由医学专家角色扮演合成。virtassist 与 virtscribe 子集由 5 名以上医学专家（医生、医师助理、医学抄写员、临床信息学家）基于真实就诊经验创作；aci 子集由一名认证医生和一名志愿者外行按症状提示单角色扮演。这些内容最初是 Nuance 为产品演示录制的，后被蒸馏、清洗、规范化为研究数据集。
Q2：三个子集（virtassist/virtscribe/aci）有什么差别？
它们模拟三种 AI 辅助临床文档模式：virtassist 里医生会用唤醒词或预制命令激活虚拟助手（例如 “Hey Dragon show me the diabetes labs”）；virtscribe 模拟与人类抄写员协作，含就诊前导语和就诊后口述；aci 则是医生与患者之间纯粹自然的对话，没有任何显式的 AI 交互提示。
Q3：病历是怎么划分的？为什么？
论文把完整病历切成四个连续分部：subjective（患者报告的症状与病史）、objective_exam（当日体检所见）、objective_results（就诊前的实验室/影像结果）、assessment_and_plan（诊断与治疗计划）。这一设计受 SOAP 标准启发，动机有三：减少细粒度章节的稀疏、适配 BERT 系评估模型 512 subtoken 的长度限制、并支持比全病历更细的评测粒度。
Q4："移除无依据文本"是什么意思？
原始演示病历里塞了很多"为了真实感"但与对话无关的内容（虚构的 EHR 注入、体检所见、日期、推理等）。4 名有医学背景的标注者系统性地识别并移除这些无对话支撑的信息，部分跨度重叠一致性达 F1 0.85。这是 ACI-BENCH 可信度的关键——它让对话与病历高度对齐（病历句对齐比例 0.95，远高于真实门诊的 0.84）。
Q5：对话有多长？病历有多长？
平均每段对话 52-58 轮、1231-1382 tok；对应病历平均 476-505 tok、47-50 句。与真实门诊（consult 集 163 段）相比，ACI-BENCH 更短：病历 492 vs 683 tok，对话 1203 vs 1505 tok——主要因为移除了无依据文本，也因为它比真实就诊更规整。
Q6：ASR 的错误是怎么处理的？
ACI-BENCH 刻意保留 ASR 的真实错误。aci 子集只有 ASR 转录（原始 + 人工校正版），virtscribe 含人工与 ASR 两版，virtassist 只有人工转录版。部分子集还存在说话人标签互换（[patient]/[doctor] 颠倒），源自 ASR，团队有意不校正，以提供含真实 ASR 缺陷的语料。
Q7：基准测了哪些模型？结果如何？
5 类基线：复制粘贴、检索、BART 系、LED 系、OpenAI 系（Text-davinci-002/003、ChatGPT、GPT-4）。核心发现：对 BART/LED 微调模型，分部生成比全病历生成好 1-14 分；GPT-4 无微调即拿到最高的 medcon（医学概念 F1）57.78；强检索基线和纯复制基线出人意料地能打。
Q8：和 MEDIQA 挑战赛什么关系？
ACI-BENCH 是 MEDIQA-CHAT 2023（Task B 对话→病历、Task C 病历→对话）与 MEDIQA-SUM 2023（Task C 完整就诊摘要）的官方测试数据。注意 Task A 用的是姊妹数据集 MTS-Dialog，不是 ACI-BENCH——别把两者的成绩混起来。
Q9：我现在能拿到什么、许可如何？
一个 CC BY 4.0 的 zip，Figshare 直链；GitHub（wyim/aci-bench）有预处理、评估与基线代码；微软还有 MTS-Dialog + ACI-BENCH 合并仓库。许可统一、含商用、无注册墙——这是它比库内多数临床文本数据集都"AI-Ready"的地方。
Q10：为什么它对 AI-Ready 重要？
因为它在最难的合规区（临床对话）里做出了最开放的样本：用合成数据绕开隐私，用 CC BY 4.0 打开许可，还外接了挑战赛的评测协议。它证明了"数据可公开分享"与"任务有临床真实性"不必二选一，是医疗 NLP 数据集设计的一个范式参考。
Q11：它和库内的 MIMIC-IV-Note 有什么本质区别？
MIMIC-IV-Note 是真实的、去标识化的临床自由文本，数量大但只能做文本侧任务（分类、抽取、摘要），因为它没有配对的"原始对话"。ACI-BENCH 是合成的，但每一段病历都配了一段完整的源对话——正是这个"源-目标配对"，让它能支撑"对话→病历"这种生成任务的监督训练与评测。两者互补而非替代。
Q12：为什么规模只有 207 段还能叫"最大"？
因为它的参照系是"完整就诊对话-病历配对"这一极窄赛道。在它之前，公开可用的同类数据只有 primock57（57 段）和 MTS-Dialog（约 1,701 段，但那是短对话片段而非完整就诊）。论文 Table 1 对比了 8 个语料，其中 6 个私有不可分享——在"完整就诊 + 公开"这个交集里，207 段确实是当时的最大。规模数字必须连同"配对完整度 + 公开性"一起理解。
Q13：一份典型的 ACI-BENCH 样本长什么样？
一段 50 多轮的医患对话（医生问诊、患者回答、偶尔医生对虚拟助手/抄写员说话），加上一份被切成四个 SOAP 分部的病历文本，再加一行元数据（子集、id/encounter_id、医患化名、性别、主诉与次诉）。它没有音频——音频在 ASR 阶段就转成了文本，公开的只有转录。
Q14：数据里有没有音频？
没有。ACI-BENCH 公开的是文本转录，不含原始音频。这也是它许可能开到 CC BY 4.0 的一个技术前提——音频（声纹）比文本更接近个人生物信息，公开风险更高。
Q15：如果我要用它做中文病历生成，能直接迁移吗？
不能直接用，但方法论可以。数据是英文（且偏美国东北部）。中文场景需要：①找中文的对话-病历配对数据（库内 MedDialog 是可参考的中文医疗对话起点，但非配对病历）；②借鉴 ACI-BENCH 的 SOAP 四分部与无依据文本审计方法自建。转移的是设计范式，不是数据本身。
§2 数据构成与规格
2.1 总量：207 段就诊，五组划分
ACI-BENCH 的全部资产可以一句话概括：207 段完整就诊对话，每段配一份结构化临床病历。这 207 段被切成五组，其中三组直接被两届 MEDIQA 挑战赛当作官方测试集：
| split | 段数 | 用途 | 绑定挑战赛 |
|---|---|---|---|
| train | 67 | 模型训练 | — |
| valid | 20 | 模型验证 | — |
| test1 | 40 | 完整对话→完整病历 | MEDIQA-CHAT 2023 Task B |
| test2 | 40 | 病历→合成对话 | MEDIQA-CHAT 2023 Task C |
| test3 | 40 | 完整就诊摘要 | MEDIQA-SUM 2023 Task C |
| 合计 | 207 | — | — |
划分方式是随机分层抽样（randomized stratified sampling），保证每个子集在各 split 中都有代表。这里有两个使用要点：第一，三组测试各自绑定一个任务，不能交叉汇报（test1 的成绩只对 Task B 有意义）；第二，test2 的方向与另两组相反——它是"病历→对话"的反向生成，用于数据增强，别把它当成又一个"对话→病历"测试集。
2.2 三个子集：三种临床工作流
数据集刻意覆盖了三种 AI 辅助临床文档的现实模式，每一段就诊都被打上子集标签：
| 子集 | 场景 | 特征 | 转录版本 |
|---|---|---|---|
| virtassist | 虚拟助手 | 医生用唤醒词/预制命令激活设备（如 “Hey Dragon show me the diabetes labs”），要求医生改变行为习惯 | 仅 humantrans |
| virtscribe | 虚拟抄写员 | 医生预期由抄写实体（人工或自动）协助，含就诊前导语 + 就诊后口述（指定体检、评估计划等非语言部分） | humantrans + asr |
| aci | 环境临床智能 | 医生与患者纯自然对话，无任何显式 AI 交互线索 | asr（原始）+ asrcorr（校正） |
三子集在各 split 中的分布如下（数字可逐一核对，总和等于 207）：
| 子集 | train | valid | test1 | test2 | test3 | 合计 |
|---|---|---|---|---|---|---|
| virtassist | 20 | 5 | 10 | 10 | 10 | 55 |
| virtscribe | 12 | 4 | 8 | 8 | 8 | 40 |
| aci | 35 | 11 | 22 | 22 | 22 | 112 |
| 合计 | 67 | 20 | 40 | 40 | 40 | 207 |
校验：20+12+35=67；5+4+11=20；10+8+22=40 ×3 → 合计 207。aci 子集最大（112 段），也最贴近"医患纯自然对话"这一类最难的场景；virtscribe 最小（40 段），因为它需要额外的前导语与口述部分，制作成本最高。
2.3 对话与病历的规格
论文 Table 3 给出了逐 split 的长度统计，这些数字是判断"你的模型输入输出够不够长"的直接依据：
| 指标 | train | valid | test1 | test2 | test3 |
|---|---|---|---|---|---|
| 对话平均轮数 | 56 | 53 | 52 | 56 | 58 |
| 对话平均长度(tok) | 1301 | 1221 | 1231 | 1382 | 1334 |
| 病历平均长度(tok) | 483 | 492 | 476 | 500 | 505 |
| 病历平均句数 | 48 | 49 | 47 | 50 | 50 |
读这张表有三个要点：
- 输入远长于输出：对话约 1300 tok、输出病历约 490 tok——这是一个"长输入、中等输出"的摘要任务，输入端需要能处理上千 token 的上下文（BART 的 1024 tok 限制在部分样本上不够用，这正是 LED 与 GPT-4 大上下文的价值所在）。
- 各 split 长度相近：组间没有明显的长度偏斜，说明分层抽样起了作用，跨 split 比较结果不易被长度混杂。
- 对话轮数稳定在 52-58：相当于一段 50 多轮的完整问诊，比短对话数据集（MTS-Dialog 平均 9 轮）长一个量级。
2.4 SOAP 四分部：标注体系的骨架
ACI-BENCH 最有影响力的设计之一，是把可变的临床病历规范成四个连续分部。灵感来自 SOAP（Subjective, Objective, Assessment, Plan）标准，具体定义为：
| 分部 | 内容 | 对应传统章节 |
|---|---|---|
| subjective | 患者报告的症状与病史 | 主诉（cc）、现病史（hpi）、既往/社会史 |
| objective_exam | 当日体检所见 | 体格检查 |
| objective_results | 就诊前的实验室/影像结果 | 检验/影像结果 |
| assessment_and_plan | 医生的诊断与计划检查治疗 | 评估与计划 |
四分部连续出现且顺序固定。论文给了三层动机：
- 减少稀疏：真实病历并非每份都有每种细粒度章节，若按 20 类细章节建模，每类样本数会稀疏到无法训练。
- 适配评估模型：BERTScore/BLEURT/BARTScore 等嵌入型指标受预训练长度限制（典型 512 subtoken），而完整"参考+候选"拼接会远超此限（论文 Fig. 2 用 Text-davinci-003 举例）。切成分部后，评测单元变短、可比。
- 更细的评测粒度：分部级评测比全病历级能揭示"哪个部分模型做得差"，例如后文会看到 objective_results 是全线模型的重灾区。
分部的一个副产品是天然稀疏：不是每份病历都有全部分部。下表是逐 split 的分部非空计数，请特别注意 objective_results 一列：
| 分部 | train | valid | test1 | test2 | test3 |
|---|---|---|---|---|---|
| subjective | 67 | 20 | 40 | 40 | 40 |
| objective_exam | 64 | 19 | 40 | 39 | 39 |
| objective_results | 53 | 18 | 32 | 29 | 27 |
| assessment_and_plan | 67 | 20 | 40 | 40 | 40 |
三个观察：
- subjective 与 assessment_and_plan 几乎总是存在（train 全 67），因为它们不依赖是否做了体检或化验。
- objective_results 缺失最多（train 只有 53/67，test3 只有 27/40）——很多门诊就诊本来就没有"就诊前的化验结果"可写。
- 生成模型面临的挑战由此放大：当某分部在训练集里本身就时有时无，模型很难学到稳定的分部结构；评测程序用规则式标题检测（rule-based section detection）切分，若模型生成的某分部只有几句、标题没被识别，该分部就会被判 0 分（这是 §5 中那些"0.00"格子的部分原因）。
2.5 转录版本：一份数据，三种"听写稿"
ACI-BENCH 同时对"ASR 误差如何影响病历生成"这一问题做了设计。同一段就诊可能以不同转录版本存在：
| 版本 | 含义 |
|---|---|
| humantrans | 人工转录（金标准听写稿） |
| asr | 自动语音识别原始输出（含错误） |
| asrcorr | 人工校正后的 ASR（修正导致病历与转录冲突的错误） |
子集与版本的对应关系是刻意异构的：virtscribe 同时有人工与 ASR 两版（可做对照实验），aci 只有 ASR（原始 + 校正）两版（模拟纯自然场景的机器听写现实），virtassist 只有人工版。这样，研究者可以研究"同一条管线换听写稿来源会掉多少分"，这也是论文基线实验的一个维度。
2.6 说话人标签互换：一个刻意的"不修"
有一个细节容易被使用者当作数据缺陷，实际是有意保留：部分 ACI-BENCH 子集的说话人标签（[patient]/[doctor]）来自 ASR 且存在互换错误。团队明确表示有意不校正，因为"提供一个捕捉此类错误的真实数据集"才是目标。仓库同时提示，可用自动方法（包括 LLM 方法）识别并修复这些标签问题。
对使用者的含义：拿到数据后不要假设说话人标签总是正确；做说话人角色敏感的任务（如"只提取患者自述"）前，应先做一轮标签校验或清洗。这一设计把"数据不完美"变成了"数据真实"的卖点，也把清洗责任显式交给了使用者。
2.7 文件组织与字段
官方数据在两个目录下组织：challenge_data/（供 MEDIQA-CHAT/MEDIQA-SUM 挑战赛使用）与 src_experiment_data/（ASR 实验数据）。每个 split 对应两个文件——一个 metadata、一个 data：
元数据文件（*_metadata.csv）字段：dataset name（virtassist/virtscribe/aci）、id、encounter_id、doctor_name、patient_firstname、patient_familyname、gender、chief complaint (cc)、secondary complaints (2nd_complaints)。
数据文件（*.csv）：transcript 与 note 文本，带 dataset name 与 id/encounter_id。
标识符口径：id 与 encounter_id 都能唯一标识一例，但用途不同——challenge_data 用 encounter_id（挑战赛官方标识），src_experiment_data 用 id（含子集信息）。连接 metadata 与 data 时选对口径，否则会连不上。
文件名约定：{split}_{subset}_{transcript-version}.csv，例如 train_virtscribe_humantrans.csv（virtscribe 子集、人工转录的 train 数据）、train_virtscribe_asr.csv（同子集的 ASR 版）。challenge 文件的前缀固定为 train / valid / clinicalnlp_taskB_test1 / clinicalnlp_taskC_test2 / clef_taskC_test3。
文件体量：Figshare 打包为 aci-bench-corpus.zip，MB 级 CSV 文本，下载与解包成本极低（这也是它作为基准的友好之处）。
2.8 与同类语料的横向对比
要理解 ACI-BENCH 的定位，最直接的方式是看论文 Table 1 的对比。它列了 8 个"医生-患者对话生成病历"的语料，只有 3 个公开：
| 数据集 | 描述 | 源长度(tok/turns) | 目标长度(tok/sent) | 规模 | 公开 |
|---|---|---|---|---|---|
| MTS-Dialog | 对话-病历片段（病历章节创建对话） | 142/9 | 48/3 | 1,701 | Y |
| primock57 | 角色扮演对话-病历对 | 1489/97 | 161/23 | 57 | Y |
| ACI-BENCH | 角色扮演对话-病历对 | 1302/55 | 490/49 | 207 | Y |
| 3M Health | 由对话创建病历 | −/− | −/（仅 hpi） | 1,342 | N |
| Abridge | 由对话创建病历 | 1500/− | −/27 | 6,862 | N |
| Augmedix | 真实临床对话-病历对 | −/175 | −/47 | 500 | N |
| emr.ai | 真实临床听写-病历对 | 616/1 | 550/− | 9,875 | N |
| Nuance | 真实临床对话-病历对 | 972/− | 452/− | 802k | N |
两个关键读数：
- 公开的三者中 ACI-BENCH 规模居中：MTS-Dialog 数量最多（1,701）但每段只有 9 turns——是"短片段"；primock57 每段够长（97 turns）但只有 57 段；ACI-BENCH 用 55 turns × 207 段找到了"够长 × 够多"的平衡点。这就是论文敢称"largest and most comprehensive"的口径——不是绝对数量最大，而是完整就诊配对的公开存量最大。
- 私有数据规模可达 802k（Nuance）。这个对比揭示了核心矛盾：真实数据规模大但私有，公开数据规模小但共享。ACI-BENCH 选择用合成换取公开，是这一权衡的自觉取舍。
这个横向表也解释了"为什么 207 段够用"：对基准（benchmark）而言，关键不是训练量，而是可复现的评测口径——207 段配上冻结划分与挑战赛协议，足以让不同团队在同一标准下比较。
§3 数据创建与标注流水线：合成数据如何做到可信
3.1 从营销演示到研究数据：一次"蒸馏"
ACI-BENCH 的来源有点特殊：它蒸馏自 Nuance 最初为产品营销演示而创建的会话集合。这带来了一个优势和一个问题。
优势是数据量大、场景真实——Nuance 作为临床文档商业厂商（后被微软收购，Dragon 系列产品），其演示数据覆盖了多种真实的临床文档工作流。问题是，演示数据为了"好看"，在病历里塞了大量虚构的 EHR 注入内容（如凭空出现的生命体征、结构化数据），很多没有对话依据。如果不处理，这些内容会让"对话→病历"变成一个"模型编造+复制"的伪任务。
ACI-BENCH 的核心数据工程，就是把这批演示数据洗干净、规范化、并验证医学合理性。
3.2 四步标注流水线
| 步骤 | 执行者 | 动作 | 产出/指标 |
|---|---|---|---|
| 1 角色扮演创建 | 5+ 医学专家（医生/医师助理/抄写员/临床信息学家） | 基于真实经验扮演医患对话（virtassist/virtscribe）；aci 由 1 医生 + 1 外行按症状提示扮演 | 原始对话转录 |
| 2 病历起草与重写 | 自动病历生成系统 + 领域专家 | 系统起草、专家检查并重写病历 | 病历初稿 |
| 3 无依据文本标注 | 4 名医学背景独立标注者 | 识别并移除无法从对话追溯的文本跨度 | 部分跨度重叠 F1 0.85 |
| 4 内容验证 | 医学专家标注者 | 逐项复核症状/检查/诊断/治疗；存疑查 +3M 病历库或升级专家 | 严重逻辑/医学错误例被移除 |
第 3 步是可信度的关键。 论文定义了系统的"无依据文本"标注指南，Table 2 给出了带方括号标注的示例，涵盖多种类型：
| 类型 | 示例（方括号内为被移除内容） |
|---|---|
| 日期（未提及） | PSA 0.6 ng/mL[, 05/25/2021] |
| 检查所见 | [Constitutional: Well-developed, well-nourished, in no apparent distress] |
| 用药语境 | 1 tablet [by oral route] daily |
| 医学推理 | referred her to formal physical therapy [to strengthen her right shoulder] |
| 患者默认 | [All questions were answered.] |
| 系统回顾 | Ears, Nose, Mouth and Throat: [Denies ear pain, hearing loss, or discharge.] |
| 生命体征 | [Blood Pressure:124/82 mmHg] |
同时，一些内容被有意保留（标记为 N）：更高粒度的检查/治疗信息（如 diabetes [type II]、[3 views]、MRI [of the head]）、测量单位（25 [mg/dl]）、患者姓名/年龄/其他姓名等——因为这些被认为是病历的合理构成，移除会损害病历质量与语义。
这一步带来的直接后果是病历变短（§4 会看到 ACI-BENCH 病历比真实门诊短约 190 tok），但也换来了对话与病历的高度对齐——这是 ACI-BENCH 敢称"基准"的底气。
3.3 ASR 冲突的处理
因为 aci 子集用 ASR 转录，出现了一类新问题：病历与转录因 ASR 错误而冲突。例如病历写 “hydronephrosis”（肾积水），ASR 误转为 “high flow nephrosis”；人名 “Castillo” 被误转为 “kastio”。标注者的任务之一就是识别这些冲突并提供校正，处理后数据被加工成"原始 ASR"和"ASR 校正版"两种。这解释了为什么 aci 子集有两个 asr 版本（asr / asrcorr）。
3.4 与真实数据的对齐验证
合成数据最容易受到的质疑是"不真实"。ACI-BENCH 用一个真实门诊对照集来回应：从 consult dataset（+3M 条专有临床病历，含全国多个提供者）中随机抽取 163 段家庭医学门诊就诊（含人工转录与对应病历、并做了深度对齐标注），与 ACI-BENCH 验证集 20 段做统计比较。
比较维度包括：长度、对齐比例、文本相似度、对齐交叉比例、说话模式百分比。核心结果（详见 §4）：
- ACI-BENCH 病历更短（492 vs 683 tok），对话更短（1203 vs 1505 tok）。
- 病历句对齐比例更高：0.95 vs 真实 0.84——因为移除了无依据文本，设计使然。
- 对话句对齐比例更高：0.49 vs 真实 0.34，且 ACI-BENCH 对话短 15% 却有更多对齐句。
- 病历句子来源偏向问答复述与陈述：ACI-BENCH 中 QA 标签句占比 43%（真实 15%）、陈述 29%（真实 23%），而听写式（DICTATION）只有 4%（真实 8%）——说明 ACI-BENCH 更"口语自然"、更少"照抄"。
论文的结论措辞克制：ACI-BENCH 在长度与相似度上与真实数据可比，但因病历更短、信息偏向问答与陈述，可能**略"容易"**一些。这个诚实的自我评估，正是它作为基准的可信来源。
3.5 一条完整的样本生命周期
把上述环节串起来，一段 ACI-BENCH 数据从诞生到可用，大致经历这样一条链路：
① 演示录制 → 医学专家在 Nuance 工作室角色扮演医患对话（原始目的：产品营销演示）
② 录音转录 → 人工转录（virtassist）/ ASR 转录（aci）/ 两者兼有（virtscribe）
③ 病历起草 → 自动病历生成系统产出初稿
④ 专家重写 → 领域专家（抄写员/医生）检查并重写病历
⑤ 无依据标注 → 4 名医学标注者标记无法从对话追溯的文本（F1 0.85）
⑥ 自动移除 → 按标注删除无依据句子（保留高粒度/单位/姓名等合理内容）
⑦ ASR 冲突校正 → 识别并修正病历与 ASR 转录的冲突（acy→asrcorr）
⑧ 二次人工复核 → 复查拼写与格式问题
⑨ 分部切分 → 规则式标题检测切出 SOAP 四分部（缺项标 EMPTY）
⑩ 内容验证 → 专家逐项复核；存疑查 +3M 病历库或升级专家；严重问题例移除
⑪ 划分冻结 → 随机分层抽样成 train/valid/test1/test2/test3
⑫ 发布 → Figshare zip + GitHub 代码 + 微软合并仓库
这条链路的两个特征值得记：它是"清洗多于采集"的——数据本体来自演示，价值增量全在后处理；它有多个"人工复核"关卡——转录后、标注后、ASR 校正后、内容验证时，共四道人工把关，这是它敢称为"基准"的质量保证。
3.6 为什么"移除无依据文本"是必要而非可选
设想不做这一步会怎样：病历里混着大量对话中根本没提的内容（虚构血压、凭空检查所见、无依据的推理）。这时"对话→病历"任务就退化成"让模型凭空编造看起来合理的医学文本"，模型只要学病历的语言风格就能拿高分，而不必真正理解对话。ROUGE 这类指标尤其会被欺骗——生成一段"标准病历腔"的虚构文本，词重叠可能还不低。
移除无依据文本后，任务被重新锚定为"从对话中提取并组织信息"。这带来的连锁效应是：§4 里病历句对齐比例高达 0.95（几乎每句病历都能追溯到对话），模型必须真的"读对话"才能得分。这一步是整个数据集可信度的地基——没有它，ACI-BENCH 会沦为又一个"风格模仿"数据集。
对复用者的启示：任何"从源生成目标"的数据集，都应先问一句"目标里有多少内容其实不来自源"；把不合格的对齐清理掉，比堆更多数据更能提升基准价值。
§4 与真实数据的对齐验证：一份合成基准的可信度审计
4.1 为什么需要这一步
合成数据的最大风险是"不真实"——如果角色扮演的对话过于规整、病历过于干净，模型在它上学到的能力就可能在真实门诊上失效。论文的技术验证（Technical Validation）章节专门设置了与真实数据的统计对照，用数据回答"ACI-BENCH 离真实有多远"。
对照集是 consult dataset（+3M 条专有临床病历，覆盖全国多个提供者）中随机抽取的 163 段真实家庭医学门诊就诊（含人工转录 + 对应病历 + 深度对齐标注）。比较对象是 ACI-BENCH 的 20 段验证集（aci-validation）。
4.2 长度对照：ACI-BENCH 更短
Table 4（分部长度对照）：
| 分部 | consult 平均 tok | consult 平均句 | aci-validation 平均 tok | aci-validation 平均句 |
|---|---|---|---|---|
| subjective | 393 | 35 | 229 | 24 |
| objective_exam | 149 | 19 | 48 | 8 |
| objective_results | 19 | 2 | 23 | 4 |
| assessment_and_plan | 122 | 11 | 192 | 16 |
| 全长 | 683 | 66 | 492 | 49 |
（objective_results 一列 consult 反而比 aci 略短——真实门诊的这个分部也常空或极简。）
Table 5（对话与对齐对照）：
| 指标 | consult | aci-bench |
|---|---|---|
| 对话平均长度（tokens） | 1505 | 1203 |
| 对话平均句数 | 141 | 80 |
| 病历平均长度（tokens） | 683 | 492 |
| 病历平均句数 | 66 | 49 |
| 病历句对齐比例 | 0.84 | 0.95 |
| 转录句对齐比例 | 0.34 | 0.49 |
| 对齐交叉比例 | 0.67 | 0.75 |
| 平均对齐文本相似度 | 0.15 | 0.12 |
| 平均 encounter 对话-病历相似度 | 0.26 | 0.31 |
三个可读出的结论：
- ACI-BENCH 全线更短：病历短约 190 tok、对话短约 300 tok 与 60 句。论文明确原因——移除无依据文本是主因，合成对话本身也比真实对话更简短规整。
- 对齐比例更高：病历句对齐 0.95（设计使然，因为没依据的句子被删了）、转录句对齐 0.49（对话更短，废话更少）。
- 相似度相近：对齐文本相似度（0.15 vs 0.12）与对话-病历文档相似度（0.26 vs 0.31）都在同一量级，说明信息传递的"密度"结构相似，ACI-BENCH 只是规模更小。
4.3 说话模式对照：ACI-BENCH 更"问答/陈述"
Table 5 还按标签统计了病历句子的来源模式（DICTATION=逐字照抄、QA=问答邻接对、STATEMENT=陈述、VERBALIZATION/STATEMENT2SCRIBE=对抄写员的指令或内容）：
| 标签 | consult | aci-bench |
|---|---|---|
| DICTATION | 8% | 4% |
| QA | 15% | 43% |
| STATEMENT | 23% | 29% |
| VERBALIZATION/STATEMENT2SCRIBE | 17% | 7% |
一句话总结：ACI-BENCH 的病历信息更多来自问答与陈述，更少来自听写。论文解释，真实 consult 中 QA 句是 DICTATION 的 2 倍（15% vs 8%），而 ACI-BENCH 中 QA 是 DICTATION 的10 倍（43% vs 4%）——说明 ACI-BENCH 的内容更"对话驱动"、更少"医生照本宣科"。
这意味着什么：一方面，这使 ACI-BENCH 更贴近"ambient"（医生一边问诊一边说话）的理想场景；另一方面，也意味着在"医生大量口述"的真实场景下（virtscribe 式工作流），模型迁移过去可能会掉分——论文自己把这一点列为局限（§2.5 的 dataLimitations 与坑点）。
4.4 这个审计的价值
这次对照是 ACI-BENCH 方法论上最值得学的一步：它没有声称合成数据等同于真实数据，而是用一个真实对照集把差异量化了出来——更短、更对齐、更偏问答。对使用者的直接好处是：你能从论文里读到"这份数据在哪些维度上比真实简单"，从而在把结果外推到临床时保持审慎。这也是它敢被称为"基准"而非"玩具数据"的底气。
§5 基准评测：五种方法在 ACI-BENCH 上的成绩单
5.1 评测设计：四类指标 + 五类方法
四类自动指标（论文明确要求"词汇 + 嵌入 + 学习型 + 信息抽取"各至少一个）：
| 类别 | 指标 | 说明 |
|---|---|---|
| 词汇 n-gram | ROUGE-1/2/L | unigram/bigram/最长公共子序列匹配 |
| 嵌入相似 | BERTScore | 上下文 token 嵌入的贪婪匹配（仅用于分部评测） |
| 学习型 | BLEURT | 训练用于打候选-参考相似度（仅用于分部评测） |
| 医学概念 | medcon | UMLS 概念集 F1（QuickUMLS 提取，限 7 个语义组） |
聚合口径：ROUGE = 三子指标平均；最终分 = ROUGE/BERTScore/BLEURT/medcon 四者平均。注意 BERTScore/BLEURT 因预训练嵌入长度限制，只在分部级评测中使用，全病历级只用 ROUGE + medcon。
medcon 的定义细节值得记：它计算候选与参考病历的 UMLS 概念集 F1，概念经 QuickUMLS 字符串匹配从 UMLS 库提取，并限制在 7 个语义组（Anatomy、Chemicals & Drugs、Device、Disorders、Genes & Molecular Sequences、Phenomena、Physiology），类似 CheXpert 的放射摘要评估但不受 14 类限制、不含权重与断言状态。它是唯一直接逼近"医学事实覆盖"的指标。
五类基线方法：
| 类别 | 具体方法 |
|---|---|
| 复制粘贴 | 最长说话人轮 / 最长医生轮 / 前2+后10说话人轮 / 前2+后10医生轮 / 整段对话 |
| 检索式 | 按 UMLS 概念集相似度检索（train UMLS）/ 按 spaCy 句向量相似度检索（train sent） |
| BART 系 | BART-large、BioBART、BART+FT SAMSum（各自含 division 变体） |
| LED 系 | LED-large-16384、LED+FT PubMed（各自含 division 变体） |
| OpenAI 无微调 | Text-davinci-002、Text-davinci-003、ChatGPT(gpt-3.5-turbo)、GPT-4 |
两种生成范式：全病历生成（一次生成整份病历）vs 分部生成（独立生成四个分部再拼接）。后者被引入的直接原因是长输入输出超出预训练模型长度。
5.2 全病历评测结果（test1，Table 6）
| 模型 | ROUGE-1 | ROUGE-2 | ROUGE-L | medcon |
|---|---|---|---|---|
| BART+FT SAMSum (Division) | 53.46 | 25.08 | 48.62 | 48.23 |
| GPT-4 | 51.76 | 22.58 | 45.97 | 57.78 |
| ChatGPT | 47.44 | 19.01 | 42.47 | 55.84 |
| Text-Davinci-003 | 47.07 | 22.08 | 43.11 | 57.16 |
| Text-Davinci-002 | 41.08 | 17.27 | 37.46 | 47.39 |
| BART (Division) | 51.56 | 24.06 | 45.92 | 47.23 |
| BioBART (Division) | 49.53 | 22.47 | 44.92 | 43.06 |
| BART+FT SAMSum | 40.87 | 18.96 | 34.60 | 41.55 |
| retrieval (train UMLS) | 43.87 | 17.55 | 40.47 | 33.30 |
| 整段对话直接复制 | 32.84 | 12.53 | 30.61 | 55.65 |
| LED (Division) | 34.15 | 8.01 | 29.80 | 32.67 |
| LED | 28.37 | 5.52 | 22.78 | 30.44 |
| LED+FT PubMed (Division) | 30.46 | 6.93 | 26.66 | 32.34 |
四条核心结论：
- 微调 BART 拿 ROUGE 榜首：BART+FT SAMSum（分部）ROUGE-1 53.46 最高——因为它微调后学到了 ACI-BENCH 特有的临床行话与分部标题格式。
- GPT-4 拿 medcon 榜首：57.78 最高，说明它捕捉到的医学事实最多；但结构化格式略逊，ROUGE 屈居第二梯队。论文解读为"模型巨大 + 密集预训练 + 大上下文 + 强通用性"，只是没针对 ACI-BENCH 格式微调。
- LED 全线垫底：LED 及其变体 ROUGE 都在 22-34 之间，甚至不如纯复制基线。长上下文模型并未自动带来好摘要——这提醒我们上下文长度 ≠ 摘要质量。
- 复制与检索基线意外能打：整段对话直接复制 ROUGE-L 30.61、medcon 55.65，反超未微调的 LED；检索式（train UMLS）ROUGE-L 40.47，超过多数 LED 与全病历 BART。这是文档摘要任务常见的"朴素基线不弱"现象。
5.3 分部评测结果（test1）
分部级评测揭示了"哪个 SOAP 部分最难"。冠军分布在模型之间：
| 分部 | 最高分模型 | 关键数字 |
|---|---|---|
| subjective | BART+FT SAMSum (Division) | Average 51.08（ROUGE-1 52.44 / ROUGE-2 30.44 / ROUGE-L 35.83 / medcon 47.84） |
| objective_exam | Text-davinci-003 | Average 55.30（ROUGE-1 54.17 / medcon 52.79） |
| objective_results | Text-davinci-003 | Average 48.90（ROUGE-L 43.84 / medcon 29.37） |
| assessment_and_plan | Text-davinci-003 | Average 46.19（medcon 46.40） |
objective_results 是全线重灾区。BART 与 LED 的全病历生成在此分部几乎崩溃——BART 全病历 ROUGE 全 0.00、BioBART 0.00、LED 0.00（Average 仅 7.26/1.36/3.72）。论文解释：该分部内容出现在病历靠后的位置，超出模型有效建模长度，且很多病历本就缺此行。这正是 §2.4 提到的"分部稀疏 + 位置靠后"双重困难的体现。
分部生成 vs 全病历生成（核心发现）：
- 对 BART/LED 微调模型，分部生成显著优于全病历生成——ROUGE 与 medcon 提升 1 到 14 分。
- 分部级评测中，subjective 提升不明显（起点已高），但 objective_exam / objective_results / assessment_and_plan 三分部平均分提升约 20%。
- 论文归因：后三个分部在病历末尾、常超出 BART/LED 的典型训练长度；且部分训练样本缺这些分部，模型学不会分部结构。
5.4 与 MEDIQA 挑战赛的衔接
ACI-BENCH 不只是一个自测基准，它是两届共享任务的官方测试数据：
- MEDIQA-CHAT 2023（第 5 届临床 NLP 工作坊，ACL 2023，17 队）：Task B（完整对话→完整病历）用 ACI-BENCH test1；Task C（病历→合成对话）用 test2；Task A 用的是姊妹集 MTS-Dialog。
- MEDIQA-SUM 2023（ImageCLEF@CLEF 2023，12 队 48 轮提交）：Task C（完整就诊摘要）用 ACI-BENCH test3。
挑战赛冠军线索（供对标）：MEDIQA-CHAT 2023 Task B 第一名由 wanglab 获得（GPT-4 + 语义检索 ICL，或微调 LED-large-16384-pubmed，平均分部分 0.6483）；其 Task A 冠军是微调 FLAN-T5-large（章节头准确率 0.78）——但 Task A 是 MTS-Dialog，不要与 ACI-BENCH 的成绩混谈。WangLab 的盲评还发现：GPT-4 生成的病历被资深住院医师偏好率 48%，与人类手写金标准 50% 几乎持平（统计学平局）——这是"LLM 病历生成接近人类水平"论断的重要来源。
5.5 后续第三方评测：LLaMA-Clinic（2024）
ACI-BENCH 发布后成为该任务的公共试金石。一个有代表性的后续工作是 Nemati Lab 的 LLaMA-Clinic（arXiv:2405.00715，2024-04），它系统批评了早期基准的三点局限：
- 只用 ROUGE 等词重叠指标，不反映人类偏好；
- reference note 质量/格式/风格差异大，与 ACI-BENCH 参考相似的病历未必临床优质；
- 早期研究对开源 LLM 的监督微调（SFT）不充分。
LLaMA-Clinic 用 LLaMA-2-13B，结合持续预训练、SFT 与强化学习，报告其生成的病历 90.4% 的单向评分达到"可接受"及以上（按 real-world readiness / completeness / accuracy 三准则），且在更难的 assessment_and_plan 分部上 real-world readiness 得分 4.2/5，反超医生手写病历的 4.1/5。
这条线索的意义：它把 ACI-BENCH 从"自动指标基准"推向"人类偏好基准"，也印证了 §4 那份诚实审计的价值——正因为 ACI-BENCH 公开了自己的局限，后续工作才能有针对性地指出"仅靠 ROUGE 不够"。
5.6 结果怎么读：四个容易误读的地方
ACI-BENCH 的成绩表信息密集，初学者最容易在这四处读错：
-
“ROUGE 最高"不等于"最好”。BART+FT SAMSum(Division) ROUGE-1 53.46 最高，但它是在训练集上微调过的，学到了 ACI-BENCH 特有的标题与行话；GPT-4 无微调、medcon 却最高。两者不可直接比"谁更强"——一个赢在格式拟合，一个赢在医学事实覆盖。诚实的报告应同时给出两组数字并说明条件。
-
那些 0.00 不是 bug。objective_results 分部里 BART/BioBART/LED 的 ROUGE 全 0.00（Average 低至 1.36-7.26），是因为规则式标题检测没识别出生成的该分部、或该分部本就在训练集缺失。它是"分部结构学不会 + 位置靠后 + 天然稀疏"三重困难叠加的结果，反映的是任务难度，不是评测程序出错。
-
LED 的长上下文优势没兑现。LED 支持 16K tokens（远超 BART 的 1024），直觉上应该更适合这份长数据，但它全线垫底——甚至不如整段对话复制。这说明"能装下更长的输入"与"能生成更好的结构化输出"是两件事，任务适配（微调、分部化）比上下文长度更关键。
-
跨任务数字不可混。Task A（MTS-Dialog 章节头分类，最高准确率 0.78）与 Task B/C（ACI-BENCH 病历生成，ROUGE 53.46 等）任务不同、数据集不同、指标类型不同，放在一张表里比较毫无意义（坑 5）。
5.7 一个模型的"选型地图"
综合 §5.2-§5.3 的结果，可以给不同约束下的选型一个粗线条的地图：
| 你的约束 | 推荐起点 | 依据 |
|---|---|---|
| 要最高 ROUGE、可微调、有算力 | BART+FT SAMSum(Division) | test1 ROUGE-1 53.46 最高 |
| 要最高医学事实覆盖、无微调预算 | GPT-4（或 Text-davinci-003） | medcon 57.78 / 57.16 领先 |
| 要开源可本地部署 | BART/D BioBART 分部模型 | 可自托，性能接近榜首 |
| 只要一个能打的零成本基线 | 检索式（train UMLS）或整段复制 | ROUGE-L 40.47 / 30.61 |
| 要 baseline 下限参照 | LED 全病历 | 全线垫底，用于证明"没白做" |
这张图的要点是：没有全面冠军，选型取决于你优化的是词汇重合、医学事实、还是部署成本。ACI-BENCH 的价值正在于把这几条曲线同时画了出来，让你能按自己的约束选。
5.8 分布外的现实：这份基准能外推到临床吗
最后一个必须说清的问题：在 ACI-BENCH 上跑出的分数，能预测真实临床表现吗？答案是谨慎的"部分能"。
支持外推的理由：任务定义、输入输出格式、SOAP 结构都与真实门诊一致；与真实数据的对齐审计（§4）显示长度与相似度可比。
限制外推的理由：数据是合成的、单一机构、美国东北部语言为主；病历格式变体少；每例仅一份参考；评测以自动指标为主。更重要的是，§4 已显示 ACI-BENCH 存在分布偏移的具体方向——病历更短、客观信息更缺、信息更偏问答。一个在 ACI-BENCH 上"把 O 部做好"的模型，未必在"医生大段口述体检所见"的真实 virtscribe 场景里同样好。
正确的用法：把 ACI-BENCH 当作"快速迭代 + 可复现比较"的开发期基准，把真实院内脱敏数据当作"上线前验证"的终审基准。两者不可互相替代——前者负责"比较公平"，后者负责"真实有效"。这也是论文在 Usage Notes 里反复强调"合成数据不代表全部真实世界"的用意。
§6 获取与许可：低门槛的开放样本
6.1 三层获取入口
| 资产 | 入口 | 许可 | 门槛 |
|---|---|---|---|
| 数据集本体（207 段） | Figshare doi:10.6084/m9.figshare.22494601 | CC BY 4.0 | 无（直链下载） |
| 代码（预处理/评估/基线） | GitHub wyim/aci-bench | 随仓库（CC BY 4.0 数据） | 无 |
| 合并发布（MTS-Dialog + ACI-BENCH） | GitHub microsoft/clinical_visit_note_summarization_corpus | CC BY 4.0 | 无 |
三个入口指向同一批数据，选择取决于用途：只要 ACI-BENCH → Figshare zip 或 wyim 仓库；要 MTS-Dialog + ACI-BENCH 一起做对话-病历任务 → microsoft 合并仓库。
6.2 许可：统一单层 CC BY 4.0
ACI-BENCH 的许可比它在库内的许多同类都干净：数据与论文都是 CC BY 4.0。
- 数据集：README 明确 “The data here is published under a Creative Commons Attribution 4.0 International License (CC BY)”。
- 论文：Nature Scientific Data 开放获取，CC BY 4.0（© The Author(s) 2023）。
- 含义：署名即可自由使用、修改、再分发，含商业用途，无注册墙、无请求制、无"仅学术用途"限制。
这与库内许多临床文本数据形成鲜明对照（例如 panda-plus 的掩码请求制、MIMIC 系列的凭证制）。ACI-BENCH 是"合成数据绕开隐私 + 全开放许可"这一组合的样本，也是它 AI-Ready 得分高的主因。
6.3 引用规范
官方要求：使用全量或任一子集，都要引用 Nature Scientific Data 论文：
@article{yim2023acibench,
title = {Aci-bench: a Novel Ambient Clinical Intelligence Dataset
for Benchmarking Automatic Visit Note Generation},
author = {Yim, Wen-wai and Fu, Yujuan and Ben Abacha, Asma and
Snider, Neal and Lin, Thomas and Yetisgen, Meliha},
journal = {Scientific Data},
volume = {10},
pages = {586},
year = {2023},
doi = {10.1038/s41597-023-02487-3},
url = {https://arxiv.org/abs/2306.02022}
}
6.4 第三方 HF 镜像（便利与风险并存）
官方为 CSV，社区把数据转成了 HF datasets 格式（Parquet），便利性高但需核对许可：
| HF repo | downloads | likes | license 标注 | 备注 |
|---|---|---|---|---|
| mkieffer/ACI-Bench | 249 | 0 | cc-by-4.0 | 主流镜像，按子集/划分组织 config |
| mkieffer/ACI-Bench-MedARC | 212 | 1 | — | MedARC 评测用 |
| AxiomicLabs/ACI-Bench | 148 | 6 | apache-2.0 | 标注与官方不符（坑点 2） |
| ClinicianFOCUS/ACI-Bench-Refined | 76 | 1 | — | 精修版 |
| shadid113/ACI-ocr-benchmark-EN | 61 | 1 | — | OCR 场景 |
| niryuu/ACI-Bench-JP | 39 | 0 | — | 日文版 |
使用守则：以官方 CC BY 4.0 为准；第三方镜像可用于实验便利，但若涉及许可合规（尤其商用），回到官方仓库核对。抓取时点（2026-10-03）下载量最高者约 249 次，属"稳定使用但非爆款"的中等热度。
6.5 AI-Ready 评估
以库内 AI-Ready 检查单过一遍：
- 机器可读元数据：论文开放获取 + CSV 结构化字段 + 元数据表——良好。
- 公开直链：Figshare + GitHub + 微软合并仓库，三路直链——优秀。
- 许可明确性：CC BY 4.0 单层统一，含商用——优秀。
- 可复现性：代码含预处理、评估与全部基线，官方测试集冻结，挑战赛协议定型——优秀。
- 文档自洽：README / 论文 / 合并仓库三处数字一致（207、67/20/40/40/40），无明显漂移——良好。
唯一的失分项是规模与真实代表性（207 段合成数据），但这属于数据内容属性而非可获取性问题。综合看，ACI-BENCH 在本库中属于可获取性第一梯队。
§7 生态与影响：从基准到 RL 环境
7.1 挑战赛生态的枢纽
ACI-BENCH 的位置很特殊：它同时是数据集和共享任务基础设施。MEDIQA-CHAT 2023 与 MEDIQA-SUM 2023 两届任务把它选为官方测试集，产出了一批可对标的方法论文（WangLab、GersteinLab 等）。这意味着使用 ACI-BENCH 时，你接入的不只是一份数据，而是一整套已经沉淀的评测协议与成绩基线。
7.2 从静态基准到 RL 环境（2026 新生态）
2026 年出现了一个有意思的转向：ACI-BENCH 被封装成 LLM/agent 的强化学习与评测环境：
- MedARC / Prime Intellect 的
aci-bench环境：单轮任务，把对话转成结构化病历，用 LLM-as-a-judge（rubric 评分，多个判官取均值）评估，划分展开为 114/35/210 tasks。 - OpenReward / GeneralReasoning 的
ACI-Bench环境：359 tasks（2026-02 发布），rubric 含 10-15 条标准，按 Accuracy(~40-50%)/Completeness(~30-40%)/Communication(~20-30%) 三轴打分。
注意口径：这些环境的 “tasks” 数是子集 × 转录版本 × 划分的展开（如 114+35+210=359），不等于 207——它们是同一批数据的多种切分视图，不是新数据（坑点 4）。
7.3 对临床文档 AI 的方法学贡献
ACI-BENCH 给这一领域留下了三条可复用的经验：
- 合成数据可绕开隐私死结：用医学专家角色扮演替代真实录音，既保住临床真实性，又能公开发布。这条路线后来被大量工作效仿。
- SOAP 四分部是"工作单元"设计：把长而可变的病历规范成 4 个连续分部，解决了稀疏、长度限制与评测粒度三个问题，成为后续病历生成的常见处理方式。
- 分部生成 > 全病历生成：这一实证结论直接指导了后续系统的架构选择（先分后拼）。
7.4 局限与批评
- 规模小：207 段，统计学代表性有限。
- 单一机构/地域：场景由 Nuance 马萨诸塞州东部演示工作室的雇员录制，语言偏美国东北部，persona 人口学信息未采集。
- 参考单一：每例仅一份参考病历，无多参考（金字塔法要求多份）。
- 指标局限：词重叠指标与临床质量/人类偏好相关性有限——这正是 LLaMA-Clinic 等后续工作的批评靶点。
这些局限论文自己在 Usage Notes 章节全部自曝，也构成后续数据集改进的方向。
§8 方法学启示：三条可迁移的经验
8.1 "先分后拼"的生成范式
ACI-BENCH 最重要的实证发现之一是：对长文档生成，把任务拆成若干连续分部独立生成再拼接，显著优于一次生成整份。提升幅度（1-14 分）与机制解释（超出预训练长度、分部结构难学）都很具体。任何做长病历/报告/结构化文档生成的团队，都可以把"分部化"作为首选架构，并用 ACI-BENCH 验证收益。
8.2 朴素基线的威慑力
论文里最"扎心"的一组数字：整段对话直接复制 ROUGE-L 30.61 + medcon 55.65，反超未微调 LED；检索式 train UMLS ROUGE-L 40.47，超过全病历 BART。教训：在报告任何新模型的成绩前，先跑复制与检索基线——如果打不过朴素基线，说明模型没有真正在"生成"。ACI-BENCH 把这两类基线公开，等于给社区立了一道诚实线。
8.3 "无依据文本审计"的可迁移性
ACI-BENCH 用"移除无对话支撑的文本"把一份营销演示数据洗成了研究基准，并给出了标注指南（Table 2 的具体类型）与一致性指标（F1 0.85）。这套"源-目标对齐审计"流程可以迁移到任何摘要/生成数据集的质量控制：定义无依据类型 → 多名标注者标注 → 量化一致性 → 自动移除。它是数据工程的通用方法，不限于医疗。
8.4 合成数据的"诚实审计"范式
最后一个启示关于态度：ACI-BENCH 用了整整一个技术验证章节，用一个真实对照集把"合成数据 vs 真实数据"的差异量化并公开（更短、更对齐、更偏问答），甚至在论文里承认自己"可能略简单"。这种主动暴露局限的做法，比宣称"合成数据等同真实"要可信得多，也是它被广泛接受为基准的深层原因。库内的合成数据集（如 Synthetic MIMIC 系）在设计自己的可信度论证时，可以参照这套"对照集 + 多维统计 + 承认差异"的三件套。
8.5 对"基准设计"的四条通则
把 ACI-BENCH 的经验抽象一层，可以得到设计生成类基准的四条通则：
- 任务要有明确的输入输出边界。ACI-BENCH 把"输入=一段就诊对话、输出=一份 SOAP 病历"钉死，任何人拿到数据都知道任务是什么。模糊的任务定义会让基准失去可比性。
- 要有冻结的、绑任务的测试集。test1/test2/test3 各自绑定一个挑战赛任务，互不混用。这避免了"同一个测试集被用来报不同任务的成绩"的混乱。
- 要给足基线，尤其要给’打不过就说明白做’的朴素基线。复制与检索基线的存在，让任何新模型的增益都可被独立检验。
- 要主动审计并公开分布偏移。用真实对照集量化合成数据与真实的差距，把"简单"说出来，比让人事后发现更负责任。
这四条不限于医疗——任何"从源生成目标"的基准都可以套用。ACI-BENCH 之所以被反复引用，不只是因为数据本身，更因为它把一套可复制的基准工程学示范了出来。
8.6 与库内数据工程传统的呼应
库内 i2b2/n2c2 NLP（rid 14）代表的是临床文本标注的早期传统：先定义标注任务（如去标识化、概念抽取、关系抽取），再由专家标注，产出可比较的共享任务数据。ACI-BENCH 是这一传统在生成式 AI 时代的延续与转型：
| 维度 | i2b2/n2c2 传统 | ACI-BENCH |
|---|---|---|
| 任务类型 | 抽取/分类（判别式） | 生成（对话→病历） |
| 数据来源 | 真实病历（去标识化） | 合成角色扮演 |
| 输出粒度 | 实体/关系标注 | 完整结构化病历文本 |
| 评测 | 精确率/召回率/F1 | ROUGE/BERTScore/BLEURT/medcon + 人类偏好 |
| 共享任务 | n2c2 系列 | MEDIQA-CHAT/SUM 2023 |
这条演化线说明：临床 NLP 的评测重心，正从"模型能不能抽对信息"转向"模型能不能生成可信的临床文档"。ACI-BENCH 是后者的公共基石之一。
§9 与库内条目的关系
ACI-BENCH 不是一座孤岛。在千方病案医数集的图谱里，它正好位于"临床对话 → 临床文书"这条主线上，与多个既有条目形成前置、互补或对照关系。理解这些关系，能帮助使用者在选数据时避免重复劳动、也避免踩到"看似一样实则不同"的坑。
9.1 上游：临床对话原始语料
ACI-BENCH 的输入是"医生-患者对话"，因此凡是提供医患对话原始语料的条目，都是它的天然上游。
| 库内条目（slug） | 与 ACI-BENCH 的关系 | 关键差异 |
|---|---|---|
meddialog |
医患对话语料，规模数十万级 | 多为文本/在线问诊，不含同步生成的 SOAP 文书；无结构化标注 |
mediqa |
MEDIQA 系列挑战赛数据，ACI-BENCH 正是 MEDIQA-Chat 2023 Task B/C 的官方数据 | 同源；但 mediqa 条目覆盖多个子任务，ACI-BENCH 是其中的"文书生成"子集 |
i2b2-n2c2-nlp |
n2c2/i2b2 临床 NLP 挑战数据，含医患对话与去标识任务 | 目标不同：i2b2 偏实体/关系抽取与去标识，非文书生成 |
radialog-instruct-dataset |
放射对话 → 报告生成 | 模态不同：放射科医技-医师对话，非门诊 SOAP；任务结构可对照 |
一句话记忆：meddialog 提供"聊什么"，i2b2 提供"抽什么"，mediqa 提供"比赛场"，ACI-BENCH 提供"怎么写病历"。
9.2 下游/对照：临床文书与摘要数据集
凡是"已有文书、做摘要或抽取"的条目，与 ACI-BENCH 形成方向相反或目标相近的对照。
| 库内条目（slug） | 与 ACI-BENCH 的关系 | 关键差异 |
|---|---|---|
mimic-iv-note |
MIMIC-IV 配套的自由文本临床文书 | 真实临床文书（去标识），非合成；体量远超 ACI-BENCH，但无"对话→文书"配对 |
mimic-iv-clinical-database |
MIMIC-IV 结构化临床数据库主条目 | 结构化字段为主，文本文书在 note 条目；ACI-BENCH 可作"合成对话"对照组 |
mimic-iii |
早期 MIMIC 版本 | 同样真实数据，代际更早；用于纵向对比 |
关键提醒：mimic-iv-note 是"真实文书"，ACI-BENCH 是"合成对话 + 合成文书"。 想做"真实文书摘要"用前者，想做"对话转文书"或需要对话输入时用后者。二者常被一起用于"合成 vs 真实"的迁移性研究。
9.3 组合使用模式
结合库内条目，ACI-BENCH 常见的三种组合用法：
- 预训练 + 微调：用
meddialog/mimic-iv-note做领域预训练，再用 ACI-BENCH 做"对话→SOAP"微调与评测。 - 合成 → 真实迁移：在 ACI-BENCH 上训练，在
mimic-iv-note或真实对照集上评估泛化（论文自身已做了一版对照）。 - 多任务对照：把 ACI-BENCH 的文书生成与
radialog-instruct-dataset的报告生成并置，研究"对话结构 → 文书结构"的通用性。
9.4 与 MEDIQA 条目的一处易混点
MEDIQA-Chat 2023 与 MEDIQA-Sum 2023 是两个不同的 challenge，ACI-BENCH 同时是前者的官方数据、也是后者部分子任务的来源。库内若同时存在 mediqa 与 aci-bench，需在导语处明确："aci-bench 是具体数据集，mediqa 是挑战赛家族；查数据集规格看 aci-bench，查赛制与榜单看 mediqa。"这也是本条目 §1 Q1/Q9 反复强调的身份区分。
§10 避坑清单
以下十二个坑点，是使用 ACI-BENCH 时最容易"看走眼"或"用错"的地方。按影响面排序，坑点 1–5 为高频雷区。
坑点 1：把 ACI-BENCH 当成真实临床数据
ACI-BENCH 的对话与文书都是角色扮演合成的，不是真实就诊记录。它另有 40 段真实咨询会话作为对照集，但对照集仅用于验证，不是主数据集的主体。若你的任务是训练可上临床的模型，请改用 mimic-iv-note 等真实（去标识）文书数据。 合成数据的语言分布、省略方式、话题推进都与真实门诊有系统性差异（见 §4）。
坑点 2：镜像站许可证与官方不一致
HuggingFace 上多个 ACI-BENCH 镜像条目标注 apache-2.0，而官方数据（Scientific Data 论文 + Figshare 存档 + GitHub 仓库）明确为 CC BY 4.0。以官方声明为准。商用/再分发前，务必回到论文与 Figshare 页面核对许可，不要只信镜像页的 license 字段。
坑点 3：三份子集（virtassist/virtscribe/aci）不可混用
数据分三个子集：virtassist（20/5/10/10/10）、virtscribe（12/4/8/8/8）、aci（35/11/22/22/22）。三者来自不同的演示来源、话题分布与时长不同。做训练/评测时先确认你用的是哪一份，报告结果必须写清子集名，否则跨论文数字无法对齐。
坑点 4：挑战赛任务数 ≠ 数据集会话数
MEDIQA 系列挑战赛的"task 数"（如 114/35/210 这类计数）是竞赛任务划分，不是 ACI-BENCH 的会话条数（207）。二者混谈会导致"数据有多大"的判断错误。看到"210 tasks"时，别误以为有 210 段会话。
坑点 5：转录版本（humantrans/asr/asrcorr）差异巨大
每段对话有三个转录版本：人工转录（humantrans）、ASR 原始输出（asr）、ASR 纠正后（asrcorr）。基线结果对转录质量高度敏感，用错版本或未标明版本会让复现彻底失败。论文的核心结论之一就是 ASR 错误会显著拉低生成质量。凡报告结果，必写"transcript version"。
坑点 6：ROUGE 分数不能跨论文直接比
ACI-BENCH 的聚合方式是"ROUGE 三指标取平均 + 最终四指标（ROUGE/BERTScore/BLEURT/medcon）再平均"。不同论文可能只报 ROUGE-1、或只报全篇不报分节、或用不同分词器。跨论文比较前，先对齐指标口径与聚合方式，否则 53.46 与 48.62 这类数字会误导判断。
坑点 7：全篇结果 ≠ 分节结果
论文发现"分节评估"与"全篇评估"结论可能不一致（分节更细粒度地暴露问题）。只看全篇 ROUGE 会漏掉某些 SOAP 分节（尤其 assessment_and_plan）的系统性弱项。评测时建议同时报全篇与分节。
坑点 8：medcon 指标依赖 UMLS
medcon（UMLS 概念 F1）需要 QuickUMLS + UMLS 2022AA 元词表（MRCONSO/MRSTY.RRF）。没有 UMLS 授权或环境，medcon 无法复现。别把 medcon 当成开箱即用的指标。
坑点 9：SOAP 四分节存在空节
并非每段会话的四个 SOAP 分节都非空（详见 §2.4 的非空计数）。做逐节训练/评估时，空节要正确处理（跳过、补齐或标记），否则会产生噪声梯度或错误的平均值。
坑点 10：文件名约定隐含有子集与版本信息
数据文件名（如 {train,valid,test1,test2,test3}_{aci|virtscribe}_{asr|asrcorr|humantrans}.csv）同时编码了划分、子集与转录版本。解析文件名前先读 §2.7 与仓库 SETUP，别用一条规则硬套所有文件。
坑点 11：真实对照集只有 40 段
用于验证的 40 段真实咨询会话（论文 §4 相关分析基于 163 consult encounters 的统计）规模很小，只适合做趋势性对照，不足以单独训练或做高置信度基准。把它当"小型消歧参考"而非"第二数据集"。
坑点 12：2026 年生态已出现 RL 环境封装
截至 2026 年，社区出现了把 ACI-BENCH 封装为强化学习环境的第三方项目（如 MedARC/Prime Intellect/OpenReward 等方向）。这些不是官方发布，任务数（如 359 个环境任务）也不等于数据集会话数。引用生态时务必区分"官方数据"与"第三方 RL 封装"。
常见问题（FAQ）
Q1：ACI-BENCH 到底有多少条数据？
207 段合成医患会话作为主体，另加 40 段真实咨询会话作为对照。划分见 §2.1（67/20/40/40/40）。
Q2：我能用它训练一个直接上临床的模型吗？
不建议。它是合成数据，语言与真实门诊有系统性差异。临床部署请用真实（去标识）文书数据，或至少做充分的真实域外验证。
Q3：它的许可证是什么？
官方为 CC BY 4.0（署名即可）。部分镜像页写 apache-2.0，以官方为准（见坑点 2）。
Q4：三个子集该选哪个？
看你的场景。virtassist 覆盖更全、划分更大；virtscribe 更小更聚焦；aci 常作为标准主集。做基准建议先跟论文用同一份，再扩展。
Q5：为什么有 asr 和 asrcorr 两个版本？
为了研究 ASR 噪声对文书生成的影响。asr 是原始识别输出，asrcorr 是人工纠正后。对比二者可量化"转录错误代价"。
Q6：medcon 是什么？一定要用吗？
medcon 是基于 UMLS 概念的 F1，衡量生成文书在医学概念层面的覆盖与正确性。它是论文四指标之一，但依赖 UMLS，环境搭建成本高。做 ROUGE/BERTScore/BLEURT 已能给出主要结论。
Q7：它和 MEDIQA 是什么关系？
ACI-BENCH 是 MEDIQA-Chat 2023 Task B/C 的官方数据，也被 MEDIQA-Sum 2023 部分子任务采用。数据集规格看 aci-bench，赛制榜单看 mediqa。
Q8：怎么引用？
见 §6.3 BibTeX，核心是 Yim et al. 2023, Scientific Data 10:586, doi 10.1038/s41597-023-02487-3。
Q9：有没有中文版？
没有。ACI-BENCH 是英语门诊对话。中文场景可参考其"对话→SOAP 分节生成 + 无依据文本审计"的方法论，但数据本身不能直接迁移。
Q10：文件多大？
官方 Figshare 存档提供打包下载；精确压缩包大小以 Figshare 页面为准（本条目未固化该数值，避免误导）。
事实清单（可核验）
以下为核心事实及来源，供交叉核验。标注"双源"者表示至少在两个独立来源中出现。
| 事实 | 值 | 来源 |
|---|---|---|
| 全称 | ACI-BENCH（Ambient Clinical Intelligence Benchmark） | 论文/仓库（双源） |
| 发表 | Scientific Data 2023-09-06, 10:586 | 论文（双源） |
| DOI | 10.1038/s41597-023-02487-3 | 论文/PMC（双源） |
| PMID / PMCID | 37673893 / PMC10482860 | PMC（双源） |
| arXiv | 2306.02022 | arXiv |
| 许可 | CC BY 4.0 | 论文/Figshare/仓库（三源） |
| 主体规模 | 207 段合成会话 | 论文（双源） |
| 划分 | 67/20/40/40/40 | 论文 |
| 子集 | virtassist / virtscribe / aci | 论文/仓库（双源） |
| 转录版本 | humantrans / asr / asrcorr | 论文/仓库（双源） |
| SOAP 分节 | subjective / objective_exam / objective_results / assessment_and_plan | 论文（双源） |
| Figshare DOI | 10.6084/m9.figshare.22494601 | Figshare |
| GitHub | wyim/aci-bench | 仓库 |
| 机构 | Microsoft Health AI + UW + Nuance | 论文 |
| 通讯作者 | Wen-wai Yim | 论文 |
已知双源冲突（详见 FACTS §9）： ①镜像 license（apache-2.0 vs cc-by-4.0）；②挑战任务数 vs 会话数（210 vs 207）；③部分基线数字在不同论文的聚合口径不一；④真实对照集的"163 consult encounters"与"40 段"指代关系（前者为统计口径、后者为对照集规模）；⑤RL 环境任务数（359）与数据集规模无关。引用时优先官方论文与 Figshare。
未固化项（7 点，详见 FACTS §9）： Figshare 压缩包精确大小、部分 HF 镜像的下载量快照、部分第三方 RL 项目的持续维护状态、GPT-4 结果在不同评测脚本下的微小差异、medcon 的 UMLS 版本敏感性、文件名大小写在不同镜像的一致性、以及"40 段对照集"原始来源的进一步溯源。
术语表
| 术语 | 解释 |
|---|---|
| ACI | Ambient Clinical Intelligence，环境临床智能 |
| SOAP | Subjective/Objective/Assessment/Plan，病历四分节结构 |
| virtassist / virtscribe / aci | 三个数据子集 |
| humantrans | 人工转录版本 |
| asr | 自动语音识别原始输出 |
| asrcorr | ASR 人工纠正后版本 |
| ROUGE | 摘要召回导向重叠指标（-1/-2/-L） |
| BERTScore | 基于 BERT 嵌入的语义相似度 |
| BLEURT | 学习式文本生成评估指标 |
| medcon | 基于 UMLS 概念的 F1 |
| QuickUMLS | 快速 UMLS 概念抽取工具 |
| MEDIQA | 医学问答/摘要挑战赛家族 |
| Figshare | 数据存档平台 |
| RL environment | 强化学习环境封装 |
附录 A：SOAP 四分节速查
| 分节 | 含义 | 典型内容 |
|---|---|---|
| subjective | 主观 | 主诉、现病史、患者自述症状 |
| objective_exam | 客观-查体 | 生命体征、体格检查发现 |
| objective_results | 客观-检查结果 | 化验、影像等结果 |
| assessment_and_plan | 评估与计划 | 诊断、治疗计划、随访 |
附录 B：访问入口速查
| 入口 | 地址类型 | 说明 |
|---|---|---|
| 论文 | nature.com Scientific Data | 权威定义与数字来源 |
| 数据存档 | Figshare 10.6084/m9.figshare.22494601 | 官方下载 |
| 代码 | GitHub wyim/aci-bench | 基线、评测、SETUP |
| 官方镜像 | microsoft/clinical_visit_note_summarization_corpus | HuggingFace |
| 第三方镜像 | HF 多条目（hf-mirror.com） | 注意 license 差异（坑点 2） |
DAIMS 数据质量评分
| 维度 | 评分（1–5） | 说明 |
|---|---|---|
| 文档完备度 Documentation | 5 | 论文 + 仓库 SETUP + 评测脚本齐全 |
| 可获取性 Accessibility | 5 | Figshare + GitHub + HF 多入口，CC BY 4.0 |
| 标注质量 Annotation Quality | 4 | 有指南与 F1 0.85 一致性，但为合成场景 |
| 真实度 Realism | 3 | 合成数据，与真实门诊存在系统差异，已诚实披露 |
| 结构规范性 Schema | 5 | SOAP 四分节清晰，文件命名规范 |
| 可复现性 Reproducibility | 4 | 基线脚本完整，但 medcon 依赖 UMLS 环境 |
| 生态活跃度 Ecosystem | 5 | MEDIQA 采纳 + 多镜像 + 2026 RL 生态 |
| 综合 Overall | 4.4 | 临床对话→文书生成的标杆合成基准 |
说明：DAIMS 为本库内部质量画像，用于横向比较，不代表官方评价。综合分为六维加权近似值。
结语
ACI-BENCH 的价值不在数据量，而在它第一次把"环境临床智能"这条链路——从医生患者对话到结构化 SOAP 文书——做成了一个可复现、有基线、有对照、有许可的公开基准。它的三份子集、三个转录版本、四个分节、四类指标，构成了一套完整的评测骨架；而它对合成数据局限的诚实披露，又为后来者立下了"数据工程也要讲证据"的范式。
用它的第一原则只有一句：看清版本与分节，别把它当真实病历。
（全文完）
附录 C：逐 split 数据字典与核对表
本附录把散落在 §2 各处的规格汇总为可打印的核对表，供数据工程在装载前逐项比对。
C.1 划分核对表
| 检查项 | 期望值 | 核对方法 |
|---|---|---|
| train 段数 | 67 | 计数 split==train |
| valid 段数 | 20 | 计数 split==valid |
| test1 段数 | 40 | 计数 split==test1 |
| test2 段数 | 40 | 计数 split==test2 |
| test3 段数 | 40 | 计数 split==test3 |
| 总计 | 207 | 全表行数 |
| 子集合计-virtassist | 55 | 各 split 求和 |
| 子集合计-virtscribe | 40 | 各 split 求和 |
| 子集合计-aci | 112 | 各 split 求和 |
C.2 子集×split 完整矩阵
| 子集 | train | valid | test1 | test2 | test3 | 合计 |
|---|---|---|---|---|---|---|
| virtassist | 20 | 5 | 10 | 10 | 10 | 55 |
| virtscribe | 12 | 4 | 8 | 8 | 8 | 40 |
| aci | 35 | 11 | 22 | 22 | 22 | 112 |
| 合计 | 67 | 20 | 40 | 40 | 40 | 207 |
行列双向校验：行和 67+20+40+40+40=207；列和 55+40+112=207。任何一个不一致，说明装载时发生了行错位或去重错误。
C.3 转录版本可得矩阵
| 子集 | humantrans | asr | asrcorr |
|---|---|---|---|
| virtassist | 有 | — | — |
| virtscribe | 有 | 有 | — |
| aci | — | 有 | 有 |
这张矩阵是 §2.5"刻意异构"的完整表达。做"转录质量影响"实验时，唯一能同源对照的是 virtscribe（同一批就诊同时有人工与 ASR 版），因此消融实验应首选 virtscribe，而非 aci。
C.4 SOAP 分部非空核对表
| 分部 | train | valid | test1 | test2 | test3 |
|---|---|---|---|---|---|
| subjective | 67 | 20 | 40 | 40 | 40 |
| objective_exam | 64 | 19 | 40 | 39 | 39 |
| objective_results | 53 | 18 | 32 | 29 | 27 |
| assessment_and_plan | 67 | 20 | 40 | 40 | 40 |
装载后应能复现此表。若你的 objective_results 计数异常偏高，多半是把"空节标记"误当成了内容；若偏低，多半是分节解析漏切。
附录 D：基线方法逐类速查
ACI-BENCH 论文评测了五类方法，理解每一类的机制，才能正确解读 §5 的成绩表。
D.1 复制粘贴基线（Copy）
最朴素：把对话直接当作"病历"输出，或截取对话片段。它检验的是"任务是否可能被无脑完成"的下限。若一个微调模型打不过复制粘贴，说明它没学到东西——这就是 §8.2 说的"朴素基线的威慑力"。
D.2 检索基线（Retrieval）
从对话中检索与病历句最相关的片段作为输出。论文显示强检索基线出人意料地能打，说明源文档（对话）本身就含大量可直接复用的信息，这也是"抽取式摘要"在临床场景仍有效的原因。
D.3 BART 系
- BART（微调，全病历生成）：标准 seq2seq 微调，受 1024 token 输入限制影响，部分长对话被截断。
- BART + 分部生成（Division）：把任务拆成四个分部各自生成再拼接，是论文发现的最有效改进。
- BART + SAMSum 预训练再微调：先在对话摘要数据集 SAMSum 上训练，再迁移到临床域。
D.4 LED 系（Longformer Encoder-Decoder）
LED 支持长上下文（4096+），天然适配"长输入"的 ACI-BENCH，避免了 BART 的截断损失。论文同样做了全病历与分部两种变体。
D.5 OpenAI 系
- Text-davinci-002 / 003：少量样本（few-shot）提示，不做梯度微调。
- ChatGPT / GPT-4：零样本或少样本，考察通用大模型的临床文书能力。GPT-4 在 medcon 上取得最高分 57.78，说明大模型在"医学概念覆盖"这一维度已有明显优势，但 ROUGE 层面未必全面领先——这正是"四指标并用"的意义。
D.6 方法选择建议
| 你的目标 | 推荐起点 |
|---|---|
| 快速复现论文主结论 | BART + 分部生成 |
| 处理完整长对话 | LED 系 |
| 评测大模型即战力 | GPT-4 零样本 |
| 研究抽取式上限 | 检索基线 |
| 建立任务下限 | 复制粘贴基线 |
附录 E：评估脚本复现要点
基于仓库 SETUP 的实测要点（供环境搭建参考）：
| 环节 | 依赖 | 注意事项 |
|---|---|---|
| 依赖安装 | evaluate==0.4.0, datasets==2.9.0, accelerate==0.15.0 | 版本锁定较老，建议独立虚拟环境 |
| ROUGE | rouge-score==0.1.2, nltk==3.8.1 | 需下载 nltk 数据 |
| BERTScore | bert-score==0.3.12 | 首次运行下载模型权重 |
| BLEURT | 从 GitHub 源码安装 | 依赖 tensorflow，环境较重 |
| medcon | QuickUMLS + UMLS 2022AA（MRCONSO/MRSTY.RRF） | 需 UMLS 授权，门槛最高 |
| 科学术语抽取 | scispacy==0.5.1 + en_core_sci_lg-0.5.1 + en_ner_bc5cdr_md-0.5.1 | 与 spacy==3.4.4 绑定 |
| 通用语言模型 | en_core_web_md-3.5.0 | 用于句对齐与分句 |
分词与句切分的一致性直接决定 ROUGE 与 BERTScore 的可比性。跨论文比较前，先确认双方是否用同一句切分器与同一归一化流程。
E.1 分节检测的陷阱
评测脚本用规则式标题检测（rule-based section detection）把生成文切分成四个分部。若模型输出没有清晰的标题（如未生成 “Subjective:” 字样），该分部会被判空并记 0 分。在比较不同模型的分数前，先确认分节检测对双方都工作正常，否则你比较的可能是"谁更会写标题"，而不是"谁病历写得更好"。
E.2 不同转录版本的复现
复现 ASR 相关结论时，务必按 §2.5 的可得矩阵取数据。若你想复现"ASR 降低分数"这一结论，正确做法是在 virtscribe 上分别用 humantrans 与 asr 跑同一微调模型，对比差值；在 aci 上没有 humantrans，无法做这个对照。
附录 F：与相邻任务的边界
医疗 NLP 里容易与 ACI-BENCH 混淆的任务有若干，明确边界可少走弯路。
| 任务 | 输入 | 输出 | 与 ACI-BENCH 的区别 |
|---|---|---|---|
| 对话摘要 | 医患对话 | 短摘要（数句） | 输出更短，无 SOAP 结构 |
| 病历→病历摘要 | 长病历 | 短病历 | 输入不是对话，是已有文书 |
| 病历→对话生成 | 病历 | 合成对话 | 方向相反（对应 test2 / Task C） |
| 实体/关系抽取 | 病历 | 实体标注 | 输出是标注而非文书 |
| 去标识 | 病历 | 去标识病历 | 目标是隐私而非生成 |
| 患者问题生成 | 病历 | 提问 | 用于医学问答，非文书 |
| ACI-BENCH | 就诊对话 | 结构化 SOAP 病历 | 长输入→结构化中等输出，四指标评测 |
一句话边界：ACI-BENCH = 对话输入 + SOAP 结构化输出 + 四指标评测 + 挑战赛协议，四者缺一就不是这个数据集。
附录 G：常见复现误差来源
| 误差来源 | 表现 | 规避 |
|---|---|---|
| split 混用 | 报告数字与论文对不上 | 明确写 test1/test2/test3 |
| 转录版本错配 | ASR 结论无法复现 | 按 C.3 矩阵取数 |
| 分节检测失败 | 分部分数异常低 | 检查标题生成与检测器 |
| 指标口径不一 | ROUGE 不可比 | 对齐句切分与聚合方式 |
| 空节处理不当 | 平均值偏移 | 显式处理空节 |
| 说话人标签互换 | 角色抽取出错 | 先做标签清洗（§2.6） |
| medcon 环境缺失 | 四指标只剩三 | 补 UMLS 或声明缺项 |
| 镜像许可误读 | 合规风险 | 以官方 CC BY 4.0 为准 |
附录 H：一句话记忆卡
- 规模：207 段，67/20/40/40/40。
- 子集：virtassist（唤醒词）/ virtscribe（抄写员）/ aci（纯自然），55/40/112。
- 分部：subjective / objective_exam / objective_results / assessment_and_plan。
- 版本：humantrans / asr / asrcorr，按子集异构。
- 标注：4 名医学标注者移除无依据文本，F1 0.85。
- 指标：ROUGE-1/2/L + BERTScore + BLEURT + medcon。
- 结论：分部生成 > 全病历；GPT-4 medcon 57.78。
- 许可：CC BY 4.0。
- 一句话：看清版本与分节，别把它当真实病历。
附录 I：MEDIQA 挑战赛生态纵览
ACI-BENCH 的影响力很大程度来自它被两届共享任务选中。理解这两届挑战赛的结构，能解释为什么该数据集在 2023–2024 年被如此密集地引用。
I.1 MEDIQA-CHAT 2023 的三个任务
MEDIQA-CHAT 2023 于 ACL ClinicalNLP 2023 举办，围绕"对话 ↔ 病历"做三件事：
| 任务 | 方向 | 输入 | 输出 | 数据来源 |
|---|---|---|---|---|
| Task A | 对话摘要 | 医患对话 | 短医学摘要 | MTS-Dialog（非 ACI-BENCH） |
| Task B | 对话→病历 | 就诊对话 | 结构化 SOAP 病历 | ACI-BENCH test1 |
| Task C | 病历→对话 | 结构化病历 | 合成就诊对话 | ACI-BENCH test2 |
三个任务中，Task A 与 B/C 用的是不同数据集，这是最容易混淆的地方。ACI-BENCH 只覆盖 Task B 与 Task C。
I.2 MEDIQA-SUM 2023 的 Task C
MEDIQA-SUM 2023 于 CLEF/ImageCLEF 2023 举办，Task C 为"完整就诊摘要"，使用 ACI-BENCH test3。因此 ACI-BENCH 的三组测试恰好对应三个方向：
- test1 → 对话→病历（MEDIQA-CHAT Task B）
- test2 → 病历→对话（MEDIQA-CHAT Task C）
- test3 → 完整就诊摘要（MEDIQA-SUM Task C）
三组测试各自绑定一个方向，这就是为什么本条目反复强调"不能交叉汇报成绩"。
I.3 参与者与结果口径
挑战赛吸引了多支队伍提交，其中涌现了若干有效策略（如基于分部切分的生成、检索增强、领域预训练等）。主办方用与论文一致的自动指标（ROUGE/BERTScore/BLEURT/medcon）排名。注意：挑战赛榜单口径与论文基线口径可能因提交时间和脚本版本略有差异，跨来源引用时需注明出处（这是事实清单中的双源冲突之一）。
I.4 挑战赛对数据集的反哺
被选为官方数据带来两个结果：一是数据集获得大量外部使用与引用；二是社区反馈（如对分节检测、空节处理、转录版本的疑问）反过来推动仓库文档完善。这种"数据集-挑战赛"共生，是医疗 NLP 领域高质量基准形成的典型路径。
附录 J：环境临床智能（ACI）行业背景
要理解 ACI-BENCH 为什么重要，需要放到更大的行业背景里看。
J.1 文档负担问题
临床文档占用医生大量时间，是职业倦怠（burnout）的重要来源之一。EHR 的普及在提升数据可得性的同时，把大量录入工作转移给医生。业界因此发展出"环境临床智能"——设备在诊室里被动听、主动生成文书，医生只需审阅。ACI-BENCH 的 aci 子集正是这一愿景的最纯形态（无任何显式 AI 交互）。
J.2 三种人机协作形态
数据集的三子集其实对应三种产品形态的命名：
| 子集 | 产品形态 | 医生行为 |
|---|---|---|
| virtassist | 语音助手 | 主动唤醒、下命令 |
| virtscribe | 虚拟抄写员 | 预期有人/机器代记，含口述 |
| aci | 环境智能 | 只与患者自然对话 |
这一分类本身就是对"AI 如何进入诊室"的三条路线图，具有产品与研究的双重意义。
J.3 隐私困境与合成数据的地位
真实就诊对话与病历受 HIPAA 等法规保护，公开几乎不可能。合成数据因此不是"退而求其次"，而是在该合规约束下唯一可行的公开方案。ACI-BENCH 的价值在于：它用严谨的标注流水线（角色扮演 → 起草 → 无依据文本移除 → 内容验证）把合成数据做到了"可用于基准评测"的质量，并用真实对照集公开了合成与真实的差距。
附录 K：RL 环境封装的来龙去脉
2024–2026 年间，随着强化学习用于后训练（RLHF/RLVR 等）的兴起，社区开始把既有基准改造成"可用于 RL 的可交互环境"。ACI-BENCH 因其任务明确、有客观指标，成为被封装的对象之一。
K.1 为什么适合封装
- 任务清晰：给定对话，生成结构化病历。
- 有自动指标：ROUGE/BERTScore/BLEURT/medcon 可充当奖励信号。
- 有划分：train/valid/test 现成，适合训练-评估闭环。
K.2 需要注意的三件事
- 第三方封装非官方：仓库
wyim/aci-bench是官方；RL 环境封装（如 MedARC 等方向）是社区项目。 - 任务数 ≠ 会话数：环境里可能把一段会话拆成多个子任务，导致"任务数"远大于 207。
- 奖励信号与临床质量不对齐：ROUGE 等自动指标与临床可用性相关有限，直接做 RL 奖励可能训练出"高 ROUGE 低可用"的模型。
K.3 使用建议
若用 RL 环境做后训练，建议：以 medcon 等偏语义的指标为主奖励、以 ROUGE 为辅，并保留人工抽检。同时明确标注你用的是官方数据还是第三方封装，以便结果可追溯。
附录 L：版本与更新追踪建议
数据集与生态会演进，建议在使用时固定以下信息以便溯源：
| 追踪项 | 建议记录 |
|---|---|
| 论文版本 | doi:10.1038/s41597-023-02487-3（Scientific Data 2023） |
| 数据存档 | Figshare doi:10.6084/m9.figshare.22494601，记录下载日期 |
| 代码版本 | GitHub wyim/aci-bench 的 commit hash |
| 镜像来源 | 若用 HF 镜像，记录 repo id 与 revision |
| 指标口径 | 记录句切分器、聚合方式、是否含 medcon |
| 依赖版本 | evaluate/rouge-score/bert-score/scispacy 具体版本 |
| 转录版本 | humantrans/asr/asrcorr 明确其一 |
这份追踪清单能让你的实验在半年后仍可复现——临床 NLP 的可复现性往往败在"当时没记清楚用了哪版数据"。
附录 M：面向不同角色的阅读路径
| 角色 | 建议路径 |
|---|---|
| 数据工程师 | §2 → 附录 C → §6 |
| 模型研究者 | §3 → §5 → 附录 D/E |
| 评测工程师 | §5 → 附录 E/F → §10 |
| 产品/战略 | §0 → 附录 J → §7 |
| 合规/法务 | §6.2 → 坑点 2 → 附录 L |
| 学生入门 | §1 → 附录 H → 术语表 |
附录 N：SOAP 病历示例结构（拼接示意）
以下为一个结构化示意（非真实样本，仅展示四个连续分部的排列方式），帮助理解数据形状：
subjective:
患者主诉 <若干句患者报告的症状与病史>
objective_exam:
<当日体检所见：生命体征、体格检查>
objective_results:
<就诊前的实验室/影像结果>
assessment_and_plan:
<诊断、治疗计划、随访安排>
四段连续排列、顺序固定。若某分部缺内容，以空节标记处理（详见 §2.4 的非空计数）。评测时按此结构切分，逐部评分，再与全病历评分对照。
附录 O：与论文表格的对应关系
| 论文表格 | 内容 | 本条目对应位置 |
|---|---|---|
| Table 2 | 无依据文本类型示例 | §3.2 |
| Table 3 | 逐 split 长度统计 | §2.3 / 附录 C.4 |
| Table 4 | 长度对照（合成 vs 真实） | §4.2 |
| Table 5 | 说话模式对照 | §4.3 |
| Table 6 | 全病历评测结果 | §5.2 |
| 分部结果 | 分部级评测 | §5.3 |
本条目力求"每个数字都能回指论文某表"，不使用无出处的数字。凡论文未明确给出、而社区流传的数字（如精确压缩包大小），本条目一律标注为"未固化项"而非断言。
附录 P：术语中英对照与检索关键词
为方便检索原文与跨库对齐，整理本条目涉及的核心术语的中英对照。
| 中文 | 英文 | 说明 |
|---|---|---|
| 环境临床智能 | Ambient Clinical Intelligence (ACI) | 数据集名称来源 |
| 就诊病历生成 | Visit Note Generation | 核心任务 |
| 医患对话 | Doctor-Patient Dialogue | 输入 |
| 结构化病历 | Structured Clinical Note | 输出 |
| 主观/客观/评估/计划 | Subjective/Objective/Assessment/Plan (SOAP) | 分节标准 |
| 体检所见 | Physical Exam Findings | objective_exam 内容 |
| 检查结果 | Test Results | objective_results 内容 |
| 无依据文本 | Unsupported Text / Ungrounded Text | 清洗对象 |
| 转录 | Transcript | 输入文本形态 |
| 人工转录 | Human Transcript | humantrans |
| 自动语音识别 | Automatic Speech Recognition (ASR) | asr |
| 校正 ASR | Corrected ASR | asrcorr |
| 说话人标签互换 | Speaker Label Swap | 刻意保留的缺陷 |
| 检索增强 | Retrieval-Augmented | 基线方法类 |
| 分部生成 | Division Generation | 论文关键策略 |
| 医学概念 F1 | Medical Concept F1 (medcon) | 基于 UMLS |
| 文档负担 | Documentation Burden | 行业背景 |
| 角色扮演就诊 | Role-played Encounter | 数据来源 |
| 分层抽样 | Stratified Sampling | 划分方法 |
| 参考病历 | Reference Note | 金标准输出 |
附录 Q：快速自检清单（使用者版）
拿到数据后，按此清单逐项确认，可在十分钟内验证数据完整性与自身理解是否正确。
- [ ] 总行数为 207，五个 split 分别为 67/20/40/40/40。
- [ ] 三个子集分别为 virtassist 55 / virtscribe 40 / aci 112。
- [ ] 已确认所用转录版本（humantrans/asr/asrcorr）并在报告中注明。
- [ ] 已确认所用 split 绑定的任务方向（test1 对话→病历、test2 病历→对话、test3 完整摘要）。
- [ ] 已核对 SOAP 四分部非空计数与附录 C.4 一致。
- [ ] 已了解发话人标签可能存在互换，必要时做了清洗。
- [ ] 已确认许可为 CC BY 4.0（而非镜像标注的 apache-2.0）。
- [ ] 已记录代码 commit 与依赖版本以便复现。
- [ ] 若用 medcon，已确认 UMLS 环境可用；否则报告中声明缺项。
- [ ] 已理解自动指标与临床质量的差距，必要时补充人工抽检。
附录 R：三条最容易被误传的说法（澄清）
| 流传说法 | 事实 |
|---|---|
| “ACI-BENCH 有 210/359 条数据” | 均为挑战赛任务数或 RL 环境任务数，非会话数；会话数为 207。 |
| “ACI-BENCH 是真实患者数据” | 完全为角色扮演合成；仅有 40 段真实对照集用于验证。 |
| “ACI-BENCH 是 apache-2.0” | 官方为 CC BY 4.0；apache-2.0 是部分镜像页的标注错误。 |
这三条是社区里最常被转述失真的点，也是本条目反复澄清的对象。引用时以官方论文与 Figshare 为准。
（附录完）
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- mimic-iv-ext-cardiac-disease — 共享标签：医疗NLP / 电子健康记录 / 医学问答与基准 / 多模态
- radnli-report-inference — 共享标签：医疗NLP / 电子健康记录 / 医学问答与基准 / 多模态
- mednli — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- er-reason — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- mimic-ext-synnotes — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- tcmeval-sdt — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- mmedc — 共享标签：医疗NLP / 临床文本 / 医学问答与基准 / 多模态
- medsynth — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- tcm-sd — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
- mietic — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 医学问答与基准
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
