PriMock57 — 模拟基层问诊多模态语料

INFOBOX — PriMock57 一屏速览

维度	内容
本质	57 场模拟基层问诊的公开多模态语料（音频 + 人工逐句转写 + SOAP 记录），非真实患者数据
团队	Babylon Health（英国数字医疗）+ University of Aberdeen，通讯 Papadopoulos Korfiatis / Moramarco
论文	ACL 2022 短论文 pp.588-598（doi:10.18653/v1/2022.acl-short.65；arXiv:2204.00333）
规模	57 场 / 5 天 / 7 名临床医生 / 57 名扮演患者；音频 8h38m6s（双声道累计 17h:16m）
格式	WAV 16bit/16kHz 双声道（医生/患者分轨）+ Praat TextGrid 转写 + JSON 记录
两大基准	① 会话式医疗 ASR ② 问诊记录生成（consultation note generation）
ASR 结果	Google 30.9† / Azure 31.3† / Amazon Medical 34.0‡ / Conformer 34.4‡ / QuartzNet 46.4 / Kaldi 48.9（mean WER）
记录生成	BART-finet 全指标最高（R1 0.31）；BART-CNN、BERT-ext 打不过随机基线
人类评估	5 名 GP 评 285 篇记录；18 项自动指标相关性研究；字符级 Levenshtein 与 BertScore 相当
获取	GitHub 公开直链（音频走 Git LFS）；HF 上仅有非官方社区镜像
许可	CC BY 4.0（唯一条件署名，无请求制、无 gated）
库内互链	MedDialog（210）、MEDIQA（220）、MTSamples（350）、MIMIC-IV-Note（47）

PriMock57 是临床语音与医疗 NLP 领域一个"小而关键"的公开数据集：它用 57 场由演员按病例卡扮演患者的模拟基层问诊，绕开了真实患者数据几乎无法公开分享的隐私壁垒，一次性提供了音频、人工逐句转写和临床医生的 SOAP 记录三件套。它之所以被反复引用，不是因为规模大（只有 8 小时 38 分音频），而是因为它同时把两个此前缺乏公共基准的任务钉在了同一个数据集上——会话式医疗语音识别（ASR）与问诊记录自动生成——并且配套一篇罕见的大规模人类评估方法论论文，用 5 名全科医生的人工判断去标定 18 项自动指标到底哪些靠谱。

导语读法三则：

1. 只想下数据：直奔 §5 获取与许可——GitHub 直链、CC BY 4.0，但音频走 Git LFS，别忘了先 git lfs install。
2. 做医疗 ASR：先读 §6——Table 3 给了 6 个引擎的 WER 与临床概念准确率，可直接对标；注意 Google/Azure 与其余引擎之间有统计显著断层。
3. 做记录生成评测：§7 与 §8 连读——4 个基线模型的 ROUGE/BERTScore 与 5 名 GP 的人类评估、18 项指标相关性，共同回答了"该用什么指标衡量生成记录"。

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

临床对话数据是公认的"高价值、难获取"资源。真实医患对话录音含大量个人健康信息（PHI，Personal Health Information），公开前需要患者知情同意与去标识化，对音频而言尤其困难——声音本身就是可识别的生物特征。结果是整个会话式医疗 ASR 与自动记录生成（medical scribe）领域长期没有公认的公共基准：团队各自建设私有数据集，横向比较无从谈起。论文在 Related Work 里点名的对照——Chiu 等 2018 的约 14,000 小时私有问诊、Kim 2020 与 Soltau 等 2021 的端到端临床 ASR——全部基于专有数据。

PriMock57 的解法是用模拟换公开：雇佣 7 名临床医生和 57 名员工，按精心设计的病例卡（case card）出演基层问诊，全程录音。因为是模拟，不涉及真实患者隐私，团队得以用 CC BY 4.0 完全公开——这是该数据集最重要的属性，也是它在引用中被反复提到的理由。作为代价，数据的真实性和规模受限（§3 会详细讨论这个权衡的边界）。

数据集的技术贡献有三个层次：第一层是数据——57 场问诊的双声道音频、人工逐句转写与 SOAP 记录，三者按 day/consultation 对齐；第二层是基准——团队实测 6 个 ASR 引擎（3 个商用 + 3 个开源）的 WER 与临床概念准确率，并用 4 个摘要模型建立问诊记录生成的基线；第三层是评估方法论——配套论文用 5 名 GP 对 285 篇记录做后期编辑与错误标注，系统研究 18 项自动指标与人类判断的相关性，得出"字符级 Levenshtein 距离与 BertScore 相当甚至更好"这一反直觉结论，为整个医疗记录生成领域的评测提供了标尺。

§0 读法三则：

1. 这个条目是"数据集 + 双基准 + 评估方法论"三合一：数据论文（2204.00333）定基准，评估论文（2204.00447）定评测方法，两个 arXiv 编号要同时引。
2. 全文硬数字以论文正文与 Table 1-6 为准；音频时长等仓库口径与论文口径的细微格式差异已在坑 2 存照。
3. 检索时要注意：HuggingFace 上的 primock57 全是个人社区镜像，官方唯一发布点是 GitHub 仓库 babylonhealth/primock57（坑 4）。

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

Q1：PriMock57 的"57"是什么？
57 场模拟基层问诊（mock consultations）。数据集名即来源：PriMock = primary care mock，57 = 问诊场次。全部在 5 天内完成，由 7 名 Babylon 临床医生与 57 名 Babylon 员工（扮演患者）参与。

Q2：为什么用"模拟"而不是真实问诊？
因为真实问诊音频含 PHI，公开需知情同意与去标识化，成本极高且进展缓慢。团队选择建一个"尽可能接近真实条件"的模拟数据集作为务实替代（pragmatic alternative），从而能一次性以 CC BY 4.0 完全开放。

Q3：数据里到底有什么？
四类：① 57 场问诊的双声道音频（医生/患者分轨）；② 人工逐句、说话人分离的转写（Praat TextGrid）；③ 临床医生写的 SOAP 问诊记录（JSON）；④ 5 名 GP 的人类评估数据（后期编辑、错误陈述、遗漏）。另有病例卡与咨询核对清单。

Q4：音频有多大、什么格式？
总时长 8 小时 38 分 6 秒，双声道分开录制，累计 17h:16m。导出格式 WAV 16bit/16kHz；原始来源是视频流（WebM 容器、Opus 编码）。单场时长 3m48s 至 14m18s，平均 9m5s。

Q5：转写是怎么做的？
由有临床对话经验的转写员完成三层工作：听医生与患者分轨音频 → 识别每句话的起止点 → 给出准确转写。产出是 TextGrid 格式的时间区间（Interval：xmin/xmax/text）。转写含两类标签：<UNSURE>（转写员不确定）与 <UNIN/>（不可辨识音频段）。

Q6：ASR 基准的结论是什么？
6 个引擎里 Google Cloud STT（30.9）与 Azure STT（31.3）最好，且二者无显著差异（p=0.097）；医疗专用的 Amazon Transcribe Medical（34.0）并未因领域适配而胜出；本地 Kaldi 基线最差（48.9）。临床概念准确率（ECCA）结论与 WER 大体一致。

Q7：问诊记录生成基线表现如何？
4 个模型里只有在真实数据上再微调的 BART-finet 全面领先（ROUGE-1 0.31、BERTScore 0.81）；BART-CNN 与 BERT-ext 甚至打不过"随机抽 15 句"的基线——论文以此说明问诊记录生成与通用摘要任务有本质差异。

Q8：那篇人类评估论文讲了什么？
5 名执业 GP 对 285 篇记录做后期编辑、标注错误陈述与遗漏，团队据此研究 18 项自动指标与人类判断的相关性。核心发现：字符级 Levenshtein 距离与 BertScore 等模型型指标表现相当甚至更好；指标高度依赖参考文本的选择。

Q9：我现在能拿到什么、怎么拿？
全部数据都在 GitHub（babylonhealth/primock57），CC BY 4.0 公开直链。唯一门槛是音频走 Git LFS——必须先装 git-lfs 并 git lfs install，否则克隆到的只是指针文件。

Q10：为什么它对 AI-Ready 重要？
它是"以模拟换合规"从而做到完全开放（CC BY 4.0 + 直链）的代表样本：在真实临床数据普遍受限的领域，用可公开的模拟数据建立可复现基准，是推动领域进展的实用路径。它也是库里罕见的"音频+文本+人类评估标注"三位一体条目。

Q11：数据集的"三件套"是哪三件？
音频（双声道 WAV）、逐句人工转写（Praat TextGrid）、SOAP 问诊记录（JSON）。外加人类评估标注（CSV/JSON）与咨询核对清单（xlsx），共同构成完整的研究资源包。

Q12：为什么叫"mock"（模拟）？这会影响结果可信度吗？
因为是演员按病例卡出演的模拟问诊，不是真实诊疗。可信度问题是有边界的：对方法基准（比较不同引擎/模型的相对高低）影响小——相对排序通常可迁移；对真实临床语言分布的推断影响大——模拟患者更配合、更流畅。论文对此诚实声明。

Q13：一场问诊大概多长？医生和患者谁说得更多？
平均 9m5s（范围 3m48s–14m18s）。每场平均 92 个对话轮次、1,489 词，其中医生 897 词、患者 592 词——医生说得更多、轮次更长（19.3 vs 12.8 词）。但患者开场发言更多，医生在结尾接管。

Q14：主诉覆盖哪些科别？
12 类常见基层主诉：心血管（11 场最多）、胃肠炎（8）、尿路感染/上呼吸道感染/偏头痛（各 6）、皮炎/发热（各 4）、过敏反应/心理健康（各 3）、耳炎/哮喘/外伤（各 2）。

Q15：数据集是谁做的、为什么做？
Babylon Health（英国数字医疗公司，运营 NHS 的 GP at Hand 远程问诊服务）+ 阿伯丁大学。动机是真实临床对话数据因隐私无法公开，导致该领域缺乏公共基准，团队用模拟数据填补这一空缺。

§1.5 数据集速览：一张表看懂定位

为了帮助检索者快速判断"这是不是我需要的数据"，下面从六个问题维度给出定位：

问题	回答
它是什么	57 场模拟基层问诊的多模态语料（音频+转写+记录+评估标注）
它解决什么	真实临床对话数据因隐私无法公开 → 用模拟数据建立公开基准
它好在哪	完全开放（CC BY 4.0 直链）、音频+人工转写+记录三件套、附人类评估方法论
它的短板	规模小（8.6 小时）、模拟性偏差、英国中心、机构已破产
适合谁用	医疗 ASR 评测、记录生成评测、NLG 评测方法论研究
不适合谁用	大规模预训练、真实临床分布推断、跨语言泛化研究

这个定位可浓缩成一句话：PriMock57 是一个"窄而深"的公开基准数据集——它的价值不在于数据量，而在于它把两个此前无法公开比较的任务（会话式医疗 ASR 与记录生成）钉在了同一个可复现的公开数据集上，并配套了一套严谨的评测方法学。

§1.6 两篇论文速读对照

PriMock57 由两篇 ACL 2022 论文共同承载，初学者容易混淆。对照如下：

维度	数据集论文	评估论文
标题	PriMock57: A Dataset Of Primary Care Mock Consultations	Human Evaluation and Correlation with Automatic Metrics in Consultation Note Generation
arXiv	2204.00333	2204.00447
作者数	4	8
会议卷	ACL 2022 Short Papers, pp.588-598	ACL 2022
核心贡献	发布数据集；建 ASR 与记录生成两大基准	用 5 名 GP 的人类评估标定 18 项自动指标
关键结果	6 引擎 WER/ECCA；4 基线 ROUGE/BERTScore	Levenshtein ≈ BertScore；指标依赖参考文本
数据/标注	描述数据集本身	提供 human_eval_data（285 篇评估）
引用场景	引用数据集本身	引用评估方法与人类判断

引用建议：使用数据本身引数据集论文；使用人类评估数据或讨论评测方法时另引评估论文。两篇都要引，因为它们承载不同层次的贡献。若只引一篇，会遗漏数据集另一半价值（评估方法论）。

§1.7 数据集内部关系图

PriMock57 的各组成部分之间存在清晰的"采集 → 派生 → 评估"链条，理解它有助于按需取用：

① 病例卡（case cards）
      │ 驱动
      ▼
② 模拟问诊（57 场，5 天，7 医生 × 57 扮演患者）
      │ 录制
      ├──────────────────┬──────────────────┐
      ▼                  ▼                  ▼
③ 双声道音频        ④ 人工逐句转写       ⑤ SOAP 记录
   (WAV 16k)          (TextGrid)          (JSON + highlights)
      │                  │                  │
      │ 切句             │                  │
      ▼                  ▼                  │
   ASR 评测 ←────── 参考文本                 │
   (6 引擎)                                │
                        │ 输入              │ 参考
                        ▼                  ▼
                  ⑥ 记录生成模型（10 BART）───→ ⑦ 生成的记录
                                                   │
                                                   ▼
                                        ⑧ 人类评估（5 GP × 285 篇）
                                        ├─ post-edit 时长
                                        ├─ 错误陈述（critical/非）
                                        └─ 遗漏（critical/非）
                                                   │
                                                   ▼
                                        ⑨ 18 项自动指标相关性研究

这张图解释了为什么 PriMock57 是"三合一"资源：

• 要做 ASR → 用 ③ 音频 + ④ 转写（切句后），对标 6 引擎；
• 要做记录生成 → 用 ④ 转写 + ⑤ 记录（配对），训练/评测摘要模型；
• 要做评测方法研究 → 用 ⑧ 人类判断 + ⑨ 指标分数，标定自动指标。

各环节都可独立取用，无需整体采用——这是数据集"可组合性"的体现。

§2 数据构成与规格

2.1 三件套如何按 day/consultation 对齐

PriMock57 的组织轴是"天 + 场次"：目录里每个文件都以 dayN_consultationMM 命名（N 取 1-5，MM 取 01-15）。同一场问诊在三个目录里有严格对应的文件：

目录	文件模式	数量	格式
audio/	dayN_consultationMM_doctor.wav + _patient.wav	114（57 场 × 2 声道）	WAV 16bit/16kHz
transcripts/	dayN_consultationMM_doctor.TextGrid + _patient.TextGrid	114	Praat TextGrid
notes/	dayN_consultationMM.json	57	JSON

也就是说，一场问诊对应 5 个文件：2 个音频（医生/患者各一）、2 个转写（医生/患者各一）、1 个记录。这种"分声道"设计对 ASR 评测至关重要——它让研究者可以把医生与患者语料分别送入引擎，也可以混音成单声道后再评，从而分离"说话人分离"与"识别"两类误差来源。

每日场次分布（据仓库文件树实测）：

采集日	场次	说明
day1	15	采集量最大的一天
day2	10	—
day3	10	—
day4	10	—
day5	12	—
合计	57	5 天

2.2 音频规格与来源链路

属性	规格
总时长	8h38m6s（论文正文）；audio/README.md 记 “8h:38m”
双声道累计	17h:16m（医生 + 患者分轨）
采样格式	WAV，16 bit / 16 kHz
声道设计	医生、患者各一轨独立录制
原始来源	视频流（WebM 容器 / Opus 编码，可变码率）
单场时长	最短 3m48s，最长 14m18s，平均 9m5s
设备场景	医生用笔记本电脑、患者用手机，办公室环境含背景噪声

两点规格细节值得注意：

1. 有损压缩的痕迹：音频原始导出为 WebM/Opus（可变码率）再转 WAV——这意味着 16bit/16kHz 的 WAV 并非"无损原始录音"，高频成分已受 Opus 编码影响。对追求极致保真的声学研究是一个已知限制。
2. 刻意的"不完美"：论文强调医生的笔记本电脑与患者的手机、办公室背景噪声，是为了"emulate real clinical practice"（模拟真实诊疗实践）。远程问诊的真实声学环境本就嘈杂、设备不一，团队没有刻意追求录音棚级音质。

2.3 转写规格与标签体系

转写由具有临床对话经验的转写员完成，流程三步：听分声道音频 → 识别每句话的起止（结束于停顿的连续语音段） → 给出转写。产出为 Praat TextGrid 格式（语音学界通用的标注格式），每个 utterance 是一个 Interval：

字段	含义
xmin	起始时间
xmax	结束时间
text	转写文本

转写含两类特殊标签：

• <UNSURE>：转写员对内容不确定；
• <UNIN/>：不可辨识（unintelligible）的音频段。

这两个标签的存在本身是数据质量的信号——它诚实标记了人工转写的边界，而非假装每个音节都被完美捕捉。对 ASR 评测者而言，含这两个标签的片段应在计算 WER 时单独处理或排除，以免把"人耳也听不清"的部分算作引擎错误。

转写的语言学统计（论文口径）：

指标	数值
平均对话轮次	92 轮/场
平均总词数	1,489 词/场
医生词数	897 词/场
患者词数	592 词/场
医生平均轮长	19.3 词/轮
患者平均轮长	12.8 词/轮

一个有趣的对话动力学观察：患者在开场发言更多（陈述主诉），中段趋于均衡，医生在结尾的诊断与管理阶段接管话语权。论文用 Figure 2（平均话语长度随对话轮次变化）刻画了这一模式。这个规律对记录生成有直接含义——问诊记录里的关键信息（主诉）密集出现在对话前段，而处理方案（Plan）出现在后段。

2.4 问诊记录（consultation notes）与病例卡

每场问诊有一份由当值医生在问诊中或之后写的 SOAP 记录，JSON 格式，字段如下：

字段	含义
day	问诊日
consultation	场次编号
presenting_complaint	患者主诉
note	问诊记录正文
highlights	医生在记录中高亮的医学术语列表

highlights 字段的说明值得留意：医生被要求高亮记录中的重要医学信息，但论文注明这"并不详尽，取决于是否有时间"。因此 highlights 是部分标注，不宜当作完整的医学实体金标准。

病例卡（case card）是模拟问诊的"剧本"，含人口统计（年龄、性别）、主诉、症状时长、开放提问下的病史、症状与风险因素、用药与既往史等。病例卡从英国基层常见病池抽取，主诉分布（Table 1）如下：

主诉类型	场次	主诉类型	场次
Cardiovascular（心血管）	11	Urinary tract infection（尿路感染）	6
Gastroenteritis（胃肠炎）	8	Upper respiratory infection（上呼吸道感染）	6
Migraine（偏头痛）	6	Dermatitis（皮炎）	4
Fever（发热）	4	Anaphylactic reaction（过敏反应）	3
Mental health（心理健康）	3	Otitis（耳炎）	2
Asthma（哮喘）	2	Physical injury（外伤）	2

论文附表还给出完整病例卡样例（尿路感染），从中可见病例卡的详尽程度——包含性生活史、避孕措施、既往筛查等敏感但临床必要的字段，且明确指出该病例卡驱动下的患者描述会如何自然引出这些信息。

2.5 咨询核对清单与转换脚本

仓库另外提供两个辅助目录，二者是 2022-11-16 那次提交新增的（数据集论文成稿后）：

• consultation_checklists/：29 个文件（Clinician_1 子目录 20 个 xlsx + Clinician_2 子目录 7 个 xlsx + 2 个目录本身），是医生在问诊中使用的结构化核对清单。
• scripts/：数据转换脚本——extract_utterances.py（按转写切分单句音频）、textgrid_to_transcript.py（TextGrid 转纯文本）、mix_audio.sh（双声道混音）、utils.py、requirements.txt。

extract_utterances.py 是复现 ASR 基准的关键：它把每场问诊按人工转写的时间戳切成一句一个音频片段，再送入 ASR 引擎。研究者若要复现 Table 3 的 WER，必须先跑这个脚本。

2.6 数据文件的读取示例

对每类文件，读取方式与注意事项如下（供实际使用者参考）：

音频（WAV 双声道分轨）：用 librosa 或 soundfile 读取单轨；双轨混音用 scripts/mix_audio.sh 或自行叠加（注意防止削波）。

转写（TextGrid）：可用 textgrid Python 库或 scripts/textgrid_to_transcript.py 解析。每句是一个 Interval，务必保留 xmin/xmax 以便与音频对齐；遇到 <UNSURE> / <UNIN/> 需按需过滤。

记录（JSON）：直接 json.load，note 字段是 SOAP 文本，highlights 是术语列表（部分标注，勿当完整实体金标准）。

人类评估（CSV/JSON）：results.csv 每行是一篇记录的评估结果，注意 Post-edited note 的增删用 XML 风格标注；metric-scores.json 结构为"指标 → 参考类型 → 分数"。

一个实操建议：由于不同评估者的 post-edit 风格差异大，聚合统计时应按 Evaluator 分组先算再汇总，避免个体风格噪声淹没信号。

2.7 SOAP 记录结构详解

SOAP 是临床记录的通用四段式结构，理解它有助于读懂问诊记录生成任务：

段	全称	内容	能否从转写自动生成
S	Subjective（主观）	患者主诉、病史、症状描述	大部分可（PriMock57 记录生成的目标段）
O	Objective（客观）	医生观察与检查所见	部分（"看起来气色好"这类需医生目视）
A	Assessment（评估）	诊断或鉴别诊断	难（需临床推理）
P	Plan（计划）	处理方案、用药、随访	较可（多在对话末尾明确说出）

为什么数据集论文与评估论文都把目标锁定在 S 段？ 因为 Subjective 部分"大部分是 verbalised"（被口头表达出来）——患者和医生在对话中已经说出了病史与症状，模型只需忠实提炼即可。而 O/A/P 段涉及医生的观察、专业推理和决策，很多信息并不在对话中显式出现。

这一设计带来一个重要的边界：PriMock57 的记录生成任务只覆盖 SOAP 的 S 段，用它的结果去宣称"能生成完整临床记录"是过度外推。完整记录生成（含 A/P）仍是开放难题。

从 Table 4 的样例句（听力学问诊）可以看到 S 段的典型内容：病史（Hx of difficulty hearing left ear for 6 weeks…）、既往（One previous similar episode…）、否认项（No discharge/fever/itchiness/pain）、用药（Doesn’t use cotton wool buds）、既往病史（No Pmhx of note）——这些几乎全部在医生与患者的对话中被陈述过，因此可从转写重构。

§3 采集设计与人群构成

3.1 参与者与人口统计

角色	人数	构成细节
临床医生	7	4 男 3 女；5 名英式英语口音、2 名印度口音；均有虚拟问诊经验
扮演患者	57	均为 Babylon 员工；女 52.6% / 男 47.4%；多数 25-45 岁
人类评估 GP	5	≥3 年经验执业全科医生；2 男 3 女，多种族

患者口音分布：英式英语 47.4%、其他欧洲 31.6%、其他英语 10.5%、其他非英语 10.5%。论文在附表中进一步给出患者口音与年龄组分布，用于分析 ASR 误差是否与口音相关。

参与的自愿性被明确声明：参加是可选的（participation was optional），任何人可在任何时候退出。这一点在伦理层面很重要——即便是模拟问诊，团队仍按真人研究的标准处理知情与退出权。

3.2 伦理与合规边界：为什么模拟能 CC BY 4.0

数据集论文开头就点明核心矛盾：发布含 PHI 的数据集通常代价高昂，需采集患者同意和/或去标识化，对音频尤其困难。团队的应对是"建一个尽可能接近真实条件的模拟数据集"。

这个决策的连锁效应解释了整个数据集的许可形态：

环节	真实问诊数据	PriMock57（模拟）
患者同意	必需且复杂	无需（员工自愿参演）
去标识化	必需（音频尤难）	无需（无真实 PHI）
公开范围	通常受限/请求制	完全公开
许可	各异且常受限	CC BY 4.0
生态真实性	高	中（受"表演"影响）

这是本数据集最根本的权衡：用生态效度（ecological validity）换取完全开放。对需要大规模、可自由分发基准的研究者，这个交换是划算的；对研究真实临床语言分布的团队，则需谨慎对待模拟性带来的偏差。

3.3 采集协议：如何做到"接近真实"

团队在多个维度刻意还原真实诊疗情境：

1. 设备真实：医生用笔记本、患者用手机，办公室背景噪声——不追求录音棚纯净度。
2. 时长约束：要求医生遵守约 10 分钟的咨询时长——与实际基层问诊惯例一致。实测单场 3m48s 至 14m18s、均值 9m5s。
3. 记录格式：要求医生按 SOAP 格式（Subjective/Objective/Assessment/Plan）写记录，与英国基层医疗实践一致。
4. 软件真实：使用专有远程医疗软件录制并导出医生与患者的分轨音频。
5. 病例卡驱动：患者拿到病例卡后需先研读再问诊，确保症状描述自然连贯。

但"表演"无可避免地带来系统差异：真实患者可能答非所问、隐瞒、情绪化、语无伦次，而演员患者通常更"配合"、语言更流畅。论文诚实地将数据集定位为"as close as possible to the real conditions"（尽可能接近真实），而非等价于真实——使用者在解读结果时应牢记这一保留。

3.4 模拟 vs 真实：偏差的方向与量级

模拟数据的偏差不是随机的，而是有方向性的。理解这一点对正确解读基准结果至关重要：

偏差维度	模拟数据特征	对结果的可能影响
语言流畅度	演员更流畅、少废话	ASR 表现可能被高估（真实场景更难）
症状描述	按病例卡结构化陈述	信息抽取易被高估（真实主诉更散乱）
情感与态度	更配合、少冲突	对话模型在真实冲突场景的鲁棒性未测
术语使用	医生仍专业，患者词汇偏简单	专业术语侧的 WER 信号偏乐观
场景单一性	全为基层问诊	跨科别泛化未验证
口音覆盖	有分层但样本小	口音相关结论统计功效有限

核心结论：模拟数据的相对比较（哪个引擎/模型更好）通常可迁移，因为偏差对所有被比较对象是大致同向的；但绝对水平（“WER 30% 意味着真实可用”）不可直接外推。使用者在引用绝对指标时应明确声明数据来源为模拟问诊，并建议在真实数据（如受限获取的 MIMIC）上复核关键结论。

§4 ASR 基准：六个引擎的横评

4.1 评测方法与六个引擎

ASR 评测的流程是：先按人工转写把每场问诊切成单句音频（用 extract_utterances.py），再把每句送入各引擎识别，最后统一后处理后用 NIST SCTK 的 sclite 工具逐句计算 WER。

对比的 6 个引擎：

引擎	类型	说明
Kaldi	开源（本地）	基线系统；Zamia Speech 预训练声学模型 + 专有医疗问答数据训练的 3-gram 语言模型
NeMo QuartzNet	开源（端到端）	Nvidia NeMo 工具包的 QuartzNet 模型，不使用语言模型
NeMo Conformer	开源（端到端）	Nvidia NeMo 工具包的 Conformer 模型，不使用语言模型
Google Cloud STT（GCSTT）	商用（通用域）	video enhanced 模型，仅 en-us
Amazon Transcribe Medical（ATM）	商用（医疗域）	对话模型，speciality=Primary Care
Azure STT（ASTT）	商用（通用域）	Standard 模型

后处理统一规则（对人工与自动转写同时施加）：去除 disfluencies（“umm”、“uhh” 等填充词）、数字转写为文字（“5” → “five”）、去标点、多空格折叠、转小写。三处关键控制变量：填充词在参考转写里保留但在多数引擎输出里被省略，因此统一去除；数字统一以避免"5"与"five"的假性错误。

4.2 WER 结果与统计显著性

六个引擎的平均 WER（越低越好，Table 3）：

引擎	mean WER	stdev	男	女	医生	患者	en-gb	other
GC STT	30.9†	12.7	32.7	28.9	28.5	33.4	30.0	32.2
Azure STT	31.3†	12.8	32.7	29.6	26.7	35.8	30.2	32.7
ATM	34.0‡	13.9	33.8	34.2	32.8	35.2	31.6	37.2
Conformer	34.4‡	14.5	36.8	31.7	35.6	33.2	35.0	33.7
QuartzNet	46.4	15.5	48.4	44.1	48.1	44.7	46.6	46.1
Kaldi	48.9	14.9	52.7	44.6	47.0	50.8	49.5	48.2

显著性标记：† 表示与均值 WER 无统计显著差异（p = 0.097，指 Google 与 Azure）；‡ 表示弱显著（p = 0.026）；其余差异 p < 0.001。

如何读这张表（初学者最易误读的三处）：

1. 商用两强（Google/Azure）与其余引擎之间存在断层：30.9/31.3 与第三名 34.0 之间有明确差距，且 Google 与 Azure 彼此无显著差异。尽管二者都是通用域模型，却打败了专为医疗定制的 Amazon Transcribe Medical——"领域适配未能自动转化为 WER 优势"是这张表最重要的反直觉结论。
2. Conformer 的"意外之喜"：Conformer 是字符级模型却在词级指标上表现亮眼（34.4），论文用 “surprisingly well” 形容，并指出这与它以字符为建模单位却在词级 WER 上不落下风有关。
3. 角色与性别的系统性差异：多数引擎识别患者比识别医生差（如 Azure 患者 35.8 vs 医生 26.7），识别男性略差于女性。可能的解释是医生（专业表达、结构清晰）比患者（口语、含糊）更"好识别"，而口音分布（患者含 31.6% 非英式英语）在患者侧引入更多变异。

注意 WER 的绝对值偏高（全都在 30% 以上）：这是真实对话式语音的典型水平——含大量口语化、断句、重叠和背景噪声，与朗读式语料的低 WER 不可比。

4.3 ECCA：比 WER 更贴近临床的指标

论文指出 WER 的根本局限：它把所有词等权看待，但在临床域，特定临床术语的正确转写远比普通词重要——把"Fexofenadine"（非索非那定）听错，代价远高于把"um"漏掉。为此团队引入 ECCA（Extracted Clinical Concepts Accuracy，抽取临床概念准确率）：用一个基于模糊字符串匹配的专有临床信息抽取引擎，把参考与假设转写中的医学概念链接到 SNOMED-CT（临床术语标准本体），再比较抽取出的概念集合，计算 Precision / Recall / F1。

引擎	Precision	Recall	F1
GC STT	0.83	0.82	0.81
Azure STT	0.87	0.79	0.82
ATM	0.79	0.75	0.78
Kaldi	0.64	0.69	0.68
QuartzNet	0.67	0.49	0.56
Conformer	0.79	0.71	0.75

ECCA 结论与 WER 大体一致（商用两强领先），但有两个细节：医疗域的 Amazon 模型并未更好（与 WER 结论互证）；QuartzNet 的 Recall 仅 0.49（大量临床概念被漏掉），说明它即使识别出词也常错在关键术语上。

ECCA 的方法学意义超出本数据集：它示范了"用下游任务相关性而非单纯词错误率来评估 ASR"的思路，这对一切临床 ASR 应用都有借鉴价值。

4.4 六引擎横向对比：按维度再切一刀

把 Table 3 的完整分档铺开，可以看清每个引擎的"软肋"在哪里：

引擎	总体 WER	医生	患者	差值(患者-医生)	en-gb	other	差值(other-en-gb)
GC STT	30.9	28.5	33.4	+4.9	30.0	32.2	+2.2
Azure STT	31.3	26.7	35.8	+9.1	30.2	32.7	+2.5
ATM	34.0	32.8	35.2	+2.4	31.6	37.2	+5.6
Conformer	34.4	35.6	33.2	−2.4	35.0	33.7	−1.3
QuartzNet	46.4	48.1	44.7	−3.4	46.6	46.1	−0.5
Kaldi	48.9	47.0	50.8	+3.8	49.5	48.2	−1.3

三个值得玩味的模式：

1. 只有商用的 Google/Azure 显著受"角色"影响（患者比医生难识别），而开源 Conformer/QuartzNet 在患者侧反而略好。可能的原因是开源模型本就整体偏弱，天花板效应使其对角色差异不敏感。
2. Amazon 是唯一对"口音"极度敏感的引擎：其他引擎 en-gb 与 other 的差距在 ±2.5 以内，唯独 ATM 达到 +5.6（非英式英语 WER 大涨）。这提示其领域适配可能偏向某一特定口音分布的训练数据。
3. 性别差异不稳定：GC 与 Azure 都是女性略好（28.9/29.6 vs 男性 32.7），而 ATM、Conformer、QuartzNet、Kaldi 的性别差异方向不一，说明性别效应远弱于角色与口音。

4.5 为什么 WER 这么高：对话式语音的固有难度

初学者看到 30% 以上的 WER 常会误判"这些 ASR 引擎不行"。事实恰恰相反——对话式语音是 ASR 最难啃的场景之一。原因有四：

1. 口语化与断裂：真实对话充满"umm"、“uhh”、重复、自我修正、半截话，这些在参考转写里全部保留，任一引擎漏掉或错读都会计入 WER。
2. 重叠与打断：医患对话中双方常同时说话，分轨录制缓解了但未消除串扰。
3. 背景噪声与设备差异：医生用笔记本、患者用手机，办公室环境有背景噪声，与朗读式语料（如 LibriSpeech）的录音棚条件天差地别。
4. 专业术语：临床药物名、解剖术语、缩写是通用 ASR 的"地狱难度"——一次"Fexofenadine"识别错误就贡献多个词错。

因此论文选用 ECCA 作为补充指标是有道理的：它承认 WER 在临床域的信号稀释问题，改用"临床概念对了多少"来衡量实用性。

4.6 ASR 基准的可迁移结论

• 领域定制未必优于通用大厂：这是最值得警醒的结论。Amazon Transcribe Medical 专门为医疗做了训练，却在对话式基层问诊上输给通用域的 Google/Azure。
• 商用主流与开源存在代差：最好的开源端到端（Conformer 34.4）尚未追平商用两强（30.9/31.3），但已明显强于本地 Kaldi 基线（48.9）。
• 评测要看下游概念而非纯词错：ECCA 与 WER 结论互证，但在关键术语上揭示了更深的问题（QuartzNet Recall 0.49）。

§4.7 与真实临床 ASR 的对比参照（背景补充）

论文在 Related Work 中列出若干私有临床 ASR 工作，可作为"PriMock57 结果在整体图景中的位置"参照：

研究	数据	是否公开	说明
Chiu et al. 2018	≈14,000 小时记录问诊	私有	训练端到端临床会话 ASR
Kim 2020	临床对话	私有	端到端 ASR
Soltau et al. 2021	医疗对话	私有	富转写 + 置信度 + 信息抽取
Mani et al. 2020	医疗对话	私有	seq2seq 纠错通用 ASR 错误
Johnson et al. 2014 / Kodish-Wachs et al. 2018	系统综述	私有	综述开源与商用 ASR 在临床的表现
PriMock57	57 场 / 8h38m	公开 CC BY 4.0	唯一可公开复现的基层会话 ASR 基准

这张表点出了 PriMock57 的核心价值：在全部参照项都基于私有数据、无法横向比较时，它提供了唯一公开、可复现的基准点。规模远小于私有数据集（14,000 小时 vs 8.6 小时），但"可公开复现"这一属性在科研中往往比规模更稀缺。

§5 获取与许可：一个完全开放的样本

5.1 许可：CC BY 4.0，无附加条件

PriMock57 采用 Creative Commons Attribution 4.0 International（CC BY 4.0）。仓库根目录的 LICENSE.md 是 CC BY 4.0 官方全文（实测确认）。这是最宽松的 CC 许可之一，允许：

• 任意复制、分发、改编（含商用）；
• 用于训练模型、发表研究、再分发衍生数据集；
• 跨媒介、跨格式使用。

唯一条件是署名（attribution）：须注明创作者、版权声明、许可声明，标明是否修改，并附许可链接。没有非商业限制（非 NC）、没有相同方式共享限制（非 SA）、没有禁改编限制（非 ND）——这一点比库内许多医疗数据集更宽松。

5.2 获取：GitHub 直链，音频走 LFS

官方且唯一的发布点是 GitHub 仓库：

git clone https://github.com/babylonhealth/primock57.git

关键陷阱：音频文件因体积较大存储在 Git LFS（Git Large File Storage）中。若不安装 git-lfs，克隆得到的 audio/*.wav 只是 LFS 指针文件（约 133 字节的文本），打开会报错。正确步骤：

# 1. 安装 git-lfs（macOS 用 Homebrew）
brew install git-lfs
# 2. 为用户账户初始化
git lfs install
# 3. 正常克隆（LFS 文件会自动拉取）
git clone https://github.com/babylonhealth/primock57.git

仓库访问完全公开：无 gated、无请求制、无申请表、无 IRB 审批、无注册。这是与库内众多"请求制"临床数据集（如掩码需邮件通讯作者申请）的根本区别。

5.3 版本链与镜像情况

载体	地址/编号	状态
ACL Anthology 论文	aclanthology.org/2022.acl-short.65	永久存档（含 PDF 与视频）
arXiv 数据论文	2204.00333v1（2022-04-01）	可访问
arXiv 评估论文	2204.00447	可访问
GitHub 仓库	babylonhealth/primock57	20 commits，末次更新 2022-11-16
HuggingFace	无官方托管	仅个人社区镜像

GitHub 仓库的关键提交节点：2022-02-15 首提交（audio/notes/transcripts 三件套）→ 2022-03 分离各目录 README 并添加 LICENSE.md → 2022-07 对齐 Google Scholar 引用名 → 2022-11-16 新增 consultation_checklists（PR #5）。

5.4 官方 vs 社区镜像的辨别

HuggingFace 上搜索 primock57 会得到多个结果——全部是个人社区镜像，没有一个由 Babylon Health 官方发布：

HF 仓库	上传者	备注
utsav2000/Primock57	个人	2024-05
piyushmaharana/primock57	个人	2024-11，parquet 格式
macabdul9/Primock57	个人	2024-12
macabdul9/Primock57_eval_1K	个人	2025-01，评测子集
Play-Your-Part/Primock-57	个人	2025-10

使用这些镜像的风险：格式转换（如转 parquet）可能引入偏差，数据完整性未经 Babylon 认证，权重/切分可能被改动。推荐做法是一律从 GitHub 官方仓库获取，社区镜像仅作格式参考。这也是它区别于库内许多"官方 HF 直链"数据集的检索注意点（坑 4）。

5.5 许可形态对比：PriMock57 在库内的位置

把库内常见数据集的许可/获取形态横向对比，可见 PriMock57 的开放性处在什么位置：

数据集类型	典型许可/获取	门槛
PriMock57	CC BY 4.0，GitHub 直链	零（仅需 git-lfs 拉音频）
多数医学影像集	CC BY-NC / CC BY-NC-SA	非商业限制
请求制数据集	upon request（邮件作者）	需申请+用途说明
gated HF 数据集	需同意条款/填表	需账户+同意
PhysioNet 受限（如 MIMIC）	培训 + DUA	需 CITI 培训+签署协议
私有数据	不公开	无法获取

PriMock57 处在金字塔顶端——最开放的一档。这种开放性并非偶然，而是它用模拟数据规避 PHI 的直接结果。对"需要完全自由分发基准"的研究（如开源模型评测、会议 challenge），这一属性几乎不可替代。

§6 问诊记录生成基准

6.1 任务定义

问诊记录生成（consultation note generation）的目标是：从问诊转写自动生成 SOAP 记录。数据集论文建立了 4 个基线，评估论文（2204.00447）则聚焦"如何正确评估"。

任务的实际输入是自动转写而非人工转写——评估论文明确用 Google Speech-to-text 的输出作为 Note Generation 模型的输入，以模拟真实部署场景（真实环境里没有人工转写）。目标是生成 SOAP 记录的 Subjective（主观）部分。

6.2 数据集论文的四基线

模型	类型	说明
BART-CNN	神经摘要	BART 模型，在 CNN/DailyMail 数据上微调（通用摘要模型）
BERT-ext	抽取式摘要	基于 BERT 嵌入的通用抽取式摘要器
Random	基线	从转写随机抽 15 句拼成记录
BART-finet	神经摘要	BART-CNN 再在 8,000 篇真实转写+记录上微调

评估指标：ROUGE-1/2/L（F1）与 BERTScore。

模型	R1	R2	RL	BERTScore
BART-CNN	0.17	0.02	0.10	0.80
BERT-ext	0.21	0.03	0.10	0.78
Random	0.19	0.02	0.09	0.78
BART-finet	0.31	0.08	0.17	0.81

三个关键观察：

1. 微调是决定性的：只有 BART-finet（在真实问诊数据上微调）全面领先，说明通用摘要模型直接迁移到医疗域的局限。
2. 通用摘要模型打不过随机基线：BART-CNN（R1 0.17）和 BERT-ext（R1 0.21）都低于 Random（0.19）的 R1——论文用此凸显问诊记录生成与通用摘要的本质差异。通用摘要追求"提炼要点"，而问诊记录要求"忠实、结构化、不遗漏临床关键信息"，两者目标函数并不一致。
3. BERTScore 差异不显著：范围在 0.78-0.81，区分度远不如 ROUGE——因为 BERTScore 的分数区间本就压缩在 0.7-0.9，微小差异不具鉴别力。

6.3 评估论文的十模型与人类评估设计

评估论文的规模大得多：团队基于 facebook/bart-large-cnn 微调了 10 个 BART 摘要模型，在 130,000 篇真实记录+转写的专有数据集上训练。10 个模型的差异来自：不同规模的微调数据、预处理（过滤无关句子）、后处理（过滤无关生成句）——目的是让模型输出覆盖更广的错误类型。

人类评估由 5 名执业 GP 完成四个任务：

1. 听音频写自己的记录（eval_notes）——作为参考之一，全程显示在评估者屏幕上以降低记忆负担；
2. 后期编辑自动记录（post-editing）——用 track-changes 界面修正，绿色为增补、灰色删除；
3. 量化错误陈述与遗漏（incorrect statements / omissions）——每条错误标注是否 critical（关键，即若出错会引发医疗法律责任）；
4. 定性反馈（Other Issues）——如语句顺序、重复等。

评估规模：每名 GP 评估全部 57 场，每场 5 篇待评记录（4 篇来自 10 个模型随机抽 + 1 篇当值医生所写 human_note），共 57 × 5 = 285 篇。设计上刻意打乱顺序且不告诉评估者哪篇是人类所写，以防偏见。

6.4 人类评估的三项核心发现

发现一：自动记录与人工记录的差距可量化。 团队用 post-edit 时长、错误陈述数、遗漏数三项指标对比。人工记录（human_note）所需后期编辑时间显著短于模型记录——这为"记录生成系统离可用还有多远"提供了基准。

发现二：记录长度本身就是强基线。 post-edit 时长与记录长度的 Spearman 相关达 0.413——意味着任何自动指标若要与人类判断相关性超过 0.413，才比"数句子数"更有信息量。这是一个简洁有力的方法学标尺。

发现三：标准并非唯一。 论文披露一个案例：Lead Clinician 认为某篇人工记录无问题，但检查评估者的修正后发现，被标为"错误陈述"的内容其实是当值医生根据患者未明说的信息做出的合理临床推断。这揭示了问诊记录生成的深层困难——即使人类专家之间也不完全一致，任务没有唯一 ground truth。论文建议用设计良好的评估任务来缓解，产出"一个或多个好的 ground truth 近似"。

6.5 错误分类学与评估者间一致性

评估者间一致性（Inter-Annotator Agreement，Table 2）：

判断项	一致性	度量
Post-edit 时长	0.431	Krippendorff α（序数/rank）
错误陈述数	0.374	Krippendorff α（区间）
遗漏数	0.268	Krippendorff α（区间）
词级重叠	—	word-level F1

一致性整体偏低（α 多在 0.27-0.43），反映了临床判断的主观性——这本身就是重要发现：即便训练有素的 GP，对"什么是错误、什么是重要遗漏"的判断也存在可观分歧。这为自动指标的标定设置了天然的噪声上限。

定性错误分类学（通过评估者反馈归纳）涵盖语句顺序问题、重复、重要阴性发现（important negatives）的遗漏等类型。其中"重要阴性发现的遗漏"尤其值得注意——记录里"无发热、无呼吸困难"这类阴性陈述看似冗余，实则是临床决策的关键依据，模型常会漏掉。

6.6 级联误差：ASR 错误如何传导到记录

一个容易被忽视但极重要的系统性问题是级联误差（cascading error）：评估论文明确用 Google Speech-to-text 的自动转写（而非人工转写）作为记录生成模型的输入，以模拟真实部署。这意味着：

真实语音 → ASR（引入 WER ~30%）→ 带错转写 → 记录生成模型 → 记录（误差叠加）

级联的后果是：即便记录生成模型本身完美，ASR 的错误（如把"breathless"听成"breathless"或漏掉"no"）也会传导为记录中的错误陈述或遗漏。这解释了两个现象：

1. 为什么记录生成基线分数偏低（BART-finet R1 仅 0.31）——部分误差来自输入转写本身；
2. 为什么"重要阴性发现遗漏"是高频错误——一个"no"（无）的漏听会直接翻转临床含义。

实践启示：在真实部署中，ASR 与记录生成不应独立优化，而应联合评估——降低 ASR 的 critical 错误（尤其是否定词、药物名、剂量）对下游记录质量的影响，可能比改进生成模型更立竿见影。这是 PriMock57 级联设计带来的重要工程洞见。

§7 自动指标相关性：18 项指标的审判

7.1 研究设计

评估论文的核心贡献之一，是对 18 项自动指标做系统性的相关性研究——把每项指标的分数与三类人类判断（post-edit 时长、错误陈述数、遗漏数）计算 Pearson 与 Spearman 相关系数。这是医疗 NLP 领域罕见的"用人类判断给自动指标打分"的元评估工作。

18 项指标按类型分组：

类别	代表指标
编辑距离类	Levenshtein 编辑距离、WER、MER、WIL
嵌入类	ROUGE-WE、SkipThoughts、EmbeddingAverage、VectorExtrema、GreedyMatching、USE、WMD、BertScore、MoverScore
事实抽取类	Stanza+Snomed（抽取医学概念 → 映射 SNOMED CT → 计算 F1）

参考文本（reference）有三种选择：human_note（当值医生的记录）、edited_note（评估者后期编辑后的记录）、eval_note（评估者自己写的记录），并分别取平均与最大值。

7.2 核心发现

发现一：字符级 Levenshtein 与模型型指标平分秋色。 这是论文最反直觉的结论——简单的字符级 Levenshtein 距离，表现与 BertScore 等基于大模型的指标相当甚至更好。这对"越复杂的指标越好"的直觉是一记反驳，也降低了评估的算力门槛。

发现二：所有指标都严重依赖参考文本的选择。 以 edited_note 为参考时的相关性远高于 human_note 或 eval_note。由于 edited_note 是生成文本的转化产物（评估者在模型输出上做修正），这种高相关恰恰暴露了所有指标都过度依赖表面文本形式——用的是"生成物 vs 生成物的修正版"，而非"生成物 vs 独立参考"。

发现三：human_note 与 eval_note 的差异可归因。两个原因：① human_note 每场唯一，人类判断在评估者间平均后降低了噪声、坍缩了分歧；② eval_note 不是用来替代 SOAP 记录的，而是最重要要点的列表，有时比标准 SOAP 记录包含更多信息。

发现四：指标更擅长预测"错误数"而非"编辑时长"。 所有指标与错误陈述+遗漏数的相关性，都高于与 post-edit 时长的相关性——尽管后两者彼此强相关（Spearman 0.829）。论文解释：post-edit 时长含更多噪声，也更多地捕捉了评估者之间的风格差异，而非纯粹的错误量。

7.3 方法学启示

这项研究对医疗记录生成评测的启示可归纳为三条：

1. 别迷信复杂指标：Levenshtein 这种"朴素"指标已经够用，甚至更好——评估方法的选择应以与人类判断的相关性为准，而非复杂度。
2. 参考文本的选择决定一切：报告自动指标时必须声明用了哪种参考，否则分数不可比。
3. 人类判断自身有噪声上限：评估者间一致性仅 0.27-0.43，意味着任何自动指标的相关性都不可能无限接近 1.0——0.413（与记录长度）与 0.829（错误与遗漏间）是两个可参照的锚点。

这一研究让 PriMock57 从"一个数据集"升格为"一套评测方法论的载体"——它不只提供数据，还回答了"该用什么尺子量"。这正是它被临床 NLP 社区持续引用的深层原因。

7.4 三类指标的相关性排序（相对判断）

论文 Table 6 给出 18 项指标对三类人类判断的 Spearman 系数（每列加粗为前三）。虽然具体数字繁多，但可归纳出清晰的类别排序：

指标类别	对"错误+遗漏数"	对"post-edit 时长"	综合评价
编辑距离类（Levenshtein/WER/MER/WIL）	强	中	朴素但有效，性价比最高
事实抽取类（Stanza+Snomed）	强	中	临床相关性语义强，但依赖抽取质量
嵌入类（BertScore/MoverScore/USE 等）	中-强	弱-中	依赖预训练模型，算力成本高
单纯长度基线（数句子）	—	0.413	一切指标需超越的下限

一个重要的"反常识"结论再次得到印证：嵌入类（含 BertScore）并不系统性优于编辑距离类。论文直言不讳地建议：在这个任务上，简单指标是合理选择。

7.5 参考文本的三种选择及其偏差

参考类型	来源	特点	带来的偏差
human_note	当值医生所写	每场唯一；评估者判断在其上平均	平均化降低噪声、坍缩分歧
edited_note	评估者后期编辑后	生成文本的"修正版"	与生成物表面高度相似 → 指标虚高
eval_note	评估者自己写的要点列表	非标准 SOAP 格式，信息可能更多	与 SOAP 记录分布不一，指标偏低

论文发现以 edited_note 为参考时相关性明显最高——这正是问题所在：edited_note 源自生成物本身，用它当参考相当于"用考生的修改稿当标准答案"，指标自然"好看"，却掩盖了真实质量。这个发现对所有用自动指标做评测的研究都是警示。

7.6 从"记录生成"到"评测科学"：本数据集的方法学遗产

把两篇论文合起来看，PriMock57 的方法学遗产可提炼为一份"临床文本生成评测检查清单"：

1. 声明参考文本类型——否则指标分数不可比（§7.5）。
2. 报告与人类判断的相关性，而非仅报告指标绝对值（§7.1）。
3. 用简单基线锚定——记录长度（0.413）、编辑距离都是必测的对照（§6.4）。
4. 承认 ground truth 的多义性——专家间一致性仅 0.27-0.43，不要假装有唯一标准（§6.4）。
5. 区分关键错误与非关键错误——临床域尤其需要 critical/non-critical 分层（§6.3）。

这份清单的意义已超出 PriMock57 本身：它可迁移到一切"从对话生成临床文本"的任务（放射报告生成、出院小结、护理记录），这是数据集被持续引用的方法论理由。

7.7 与通用摘要评测的根本差异

把 PriMock57 的评测结论与通用摘要（如 CNN/DailyMail）评测对照，可看清临床域的特殊性：

维度	通用新闻摘要	临床记录生成
评价目标	要点覆盖 + 流畅度	事实忠实 + 临床安全
错误代价	信息损失	可能致医疗事故
关键错误	一般不分层	需区分 critical / 非 critical
Ground truth	通常唯一（编辑稿）	多义（专家间不完全一致）
指标有效性	ROUGE 广泛适用	论文显示 Levenshtein 更稳
参考文本	相对稳定	选择敏感（三种参考差异大）

两个直接结论：

1. 通用指标不能无脑迁移：论文的相关性研究正是为此而做——它证明了在这个任务上"哪把尺子准"需要专门标定。
2. 临床评测必须引入人工判断：因为错误代价高、ground truth 多义，纯自动指标不足以保证安全。人类评估是 gold standard（论文原话），自动指标只应作为快速代理。

这对一切"高风险领域 NLG"（医疗、法律、金融）都有普适启示：在错误代价高的场景，评测方法本身就是一个需要认真研究的研究课题，而非套用现成指标的收尾工作。

§8 生态与影响

8.1 在临床对话数据集中的定位

PriMock57 的出现填补了一个具体的空缺。数据集论文的 Related Work 系统梳理了当时的公开临床对话资源，可以整理成一张对照表：

数据集	类型	有音频？	有人工转写？	领域	获取
PriMock57	模拟基层问诊	✅ 双声道	✅ 逐句	基层医疗	CC BY 4.0 直链
Kazi et al. 2020	模拟精神科问诊（70 场）	✅	❌（仅自动转写）	精神科	公开
MedDialog（He 2020）	中英临床对话	❌	✅（文本）	多专科	公开
COVID-Dialogue（Ju 2020）	COVID-19 对话	❌	✅（文本）	COVID	公开
Switchboard（1992）	电话语音语料	✅	✅	通用（非医疗）	授权
Fisher（2004）	电话语音语料	✅	✅	通用（非医疗）	授权

PriMock57 的差异化优势清晰：它是当时唯一的、同时具备音频 + 人工转写 + 临床记录的公开基层医疗数据集。Kazi 等 2020 虽有音频但只有自动转写且限于精神科；MedDialog/COVID-Dialogue 有文本无音频，且源于在线问答而非真实互动，不具代表性。通用域的 Switchboard/Fisher 是语音识别的经典基准但无临床内容。

8.2 孤儿数据集的命运

一个不可回避的现实：Babylon Health 已于 2023 年 8 月破产。时间线如下：

• 2023 年 8 月：美国分支进入 Chapter 7 破产程序；英国分支（Babylon Group Holdings、Babylon Partners）被 Alvarez & Marsal 接管；
• 2023 年 8 月 30 日：英国业务资产被美国远程医疗公司 eMed Healthcare UK 收购，NHS 的「GP at Hand」业务（约 10 万患者）转由 eMed 品牌运营；
• 剩余集团实体按司法辖区程序清算。

这对数据集的影响是双面的：

• 风险：GitHub 仓库挂在 babylonhealth 组织名下，机构解体后仓库的长期存续存在不确定性（组织账户可能被归档或删除）；联系人邮箱（@babylonhealth.com）可能失效。
• 缓冲：数据集是 CC BY 4.0，任何人都可合法归档、再分发。ACL Anthology 已永久存档论文。因此即便原始仓库消失，数据也不会真正"灭失"——前提是有人及时备份。

给使用者的建议：克隆后自行归档（含 Git LFS 对象），并在论文中同时引用 arXiv 编号与 ACL Anthology 链接，以降低链接失效风险。

8.3 引用与复用模式

PriMock57 在社区中的复用方式主要有三类：

1. 作为临床 ASR 评测集：直接对标其 6 引擎 WER，或在其上评测新 ASR 模型；
2. 作为记录生成训练/评测数据：用转写→记录对微调摘要模型，或复现其人类评估协议；
3. 作为评估方法论模板：借用其"post-edit 时长 + 错误计数 + 指标相关性"的框架去评估自己的生成系统。

值得注意的是，HuggingFace 上的社区镜像（如 Play-Your-Part/Primock-57）多用于语音合成/语音克隆相关研究（“Play Your Part” 命名暗示表演/配音场景），说明数据集的生命周期已超出原始设计意图，进入更广的语音 AI 应用。

8.4 典型应用场景清单

在具体的研发流程中，PriMock57 可嵌入以下环节：

场景	用法	产出
ASR 引擎选型	用 6 引擎基准对标候选引擎	"该选 Google 还是自建 Kaldi"的实证依据
口音鲁棒性测试	用口音分档 WER 评估公平性	发现特定口音的性能塌陷
记录生成微调	用转写→记录对微调摘要模型	医疗领域的生成模型
记录生成评测	复现 4 基线 + 人类评估协议	新方法的可比分数
自动指标标定	用 285 篇人类判断验证新指标	"我的新指标是否有用"的答案
级联系统诊断	分别量化 ASR 与生成的误差贡献	定位瓶颈在识别还是生成
教学与 demo	小规模、开放、带标注，适合课程与原型	医疗 NLP 教学素材

这个清单说明 PriMock57 的价值是可组合的：不同研究目的可以只取其中一块（音频、转写、记录、评估数据）使用，无需整体采用。

§9 与库内条目的关系

PriMock57 在本库中属于"临床对话/语音"这一相对稀有的类别。与若干条目的关系如下：

9.1 互链逻辑总览

库内条目	rid	关系
MedDialog	210	最直接对照：同为临床对话数据集，MedDialog 是文本、无音频；PriMock57 补上了音频与人工转写
MEDIQA	220	任务域相邻：MEDIQA 聚焦医疗问答/摘要挑战，PriMock57 的记录生成是其对话侧补充
MTSamples	350	医学抄本样本集：真实临床文本，与 PriMock57 的模拟记录形成"真实 vs 模拟"对照
MIMIC-IV-Note	47	ICU 临床笔记：真实 EHR note、规模大；PriMock57 是小规模、带音频、结构化评估的对照
MIMIC-IV-Clinical-Database	4	电子健康记录数据库：上游 EHR 语境
ClinicalTrials.gov	556	临床试验登记：非同任务，但同属临床文本大生态
Radiolog-Instruct-Dataset	625	放射报告对话生成：同为"从对话/输入生成临床文本"的任务家族

三条互链逻辑：

1. 数据形态互补：MIMIC-IV-Note（真实 ICU 文本）↔ PriMock57（模拟基层音频+文本）——一个求真实、一个求开放；
2. 任务家族：MEDIQA、Radiolog-Instruct ↔ PriMock57 的记录生成——同属临床文本生成；
3. 对话资源：MedDialog、MTSamples ↔ PriMock57——临床对话/抄本家族的成员。

9.2 与 MedDialog 的深度对比（最贴切的互链）

在库内，MedDialog（rid 210）是与 PriMock57 最可比的一个条目，两者恰好在多个维度上互补：

维度	PriMock57	MedDialog
模态	音频 + 文本	纯文本
语言	英语（英式为主）	中文 + 英语
数据性质	模拟问诊	在线问答/对话
规模	57 场 / 8h38m	大规模（百万级对话）
人工转写	有（逐句）	不适用（本就是文本）
临床记录	有（SOAP）	无
用途	ASR 基准 + 记录生成	对话模型训练/问答
许可	CC BY 4.0	视来源

互补逻辑：需要大规模对话训练数据 → MedDialog；需要带音频、带临床记录、可评测 ASR 与记录生成 → PriMock57。两者不互斥，同一项目可按阶段混用（先大规模预训练，再用 PriMock57 做小样本评测）。

9.3 与 MIMIC-IV-Note 的"真实 vs 模拟"对照

MIMIC-IV-Note（rid 47）是真实 ICU 临床笔记——规模大、真实，但受限于物理隔离环境（PhysioNet 需完成 CITI 培训 + 签署 DUA，属受限获取）。PriMock57 是小规模模拟、完全开放。这对对照映射了临床 NLP 数据的根本张力：

维度	MIMIC-IV-Note（真实）	PriMock57（模拟）
真实性	高	中
获取门槛	高（培训+DUA）	零（CC BY 4.0）
规模	大	小（57 场）
模态	文本	音频+文本
场景	ICU	基层问诊
适用	真实世界研究	基准评测、方法验证

对研究者的实际建议：用 PriMock57 做方法原型与基准对齐，用 MIMIC 做真实世界验证——前者快、开放、可复现，后者真、大、受限。二者结合可兼顾开发速度与结论可信度。

§9.4 使用者画像：谁该用这个数据集

使用者类型	适配度	建议用法
医疗 ASR 研究者	高	直接对标 6 引擎 WER/ECCA，评测新引擎
临床记录生成开发者	高	复现 4 基线，用人类评估协议评测
NLG 评测方法研究者	极高	借 18 指标相关性框架标定自动指标
语音合成/克隆研究者	中	可用但规模小、场景单一，需谨慎
大规模预训练团队	低	规模不足，仅适合作评测子集
真实临床语言分布研究者	低	模拟性偏差大，不宜推断真实分布
跨语言/跨体系研究者	低	英语、英国中心，泛化未验证

这张画像的要点是：PriMock57 是**“窄而深”**的数据集——在其设计意图（基准评测与评估方法论）内价值极高，超出范围则受限明显。正确判断"它在哪用、不能在哪用"，是用好它的前提。

§10 避坑清单：八个已踩过的坑

坑 1：把模拟数据当真实临床语料。
PriMock57 的"患者"全是演员按病例卡表演，语言比真实患者更流畅、更配合，且回避了真实问诊中的打断、沉默、答非所问、情绪波动等现象。若用它推断真实临床语言分布或训练要部署到真实场景的模型，必须把"模拟性"作为已知偏差来源纳入考量。论文自己把它定位为 “as close as possible to the real conditions”，而非等价真实。

坑 2：音频时长双口径。
论文正文写 8h38m6s，仓库 audio/README.md 写 8h:38m。两者同指 8 小时 38 分钟，仅格式不同（秒级精度 vs 分精度）——不是数据冲突，但引用时建议统一口径并注明来源。此外"双声道累计 17h:16m"是医生轨与患者轨相加，不是另有 17 小时的独立录音。

坑 3：音频走 Git LFS，直接 clone 会拿到空壳。
这是最高频的实操陷阱。不装 git-lfs 时，audio/*.wav 只是约 133 字节的 LFS 指针文本文件，播放器打开报错，且文件大小极具误导性（每个都"看起来"存在）。必须先 git lfs install 再克隆。若已克隆了空壳，用 git lfs pull 补齐。

坑 4：HuggingFace 上的 primock57 全是个人镜像，无官方托管。
HF 搜索 primock57 返回的 utsav2000、piyushmaharana、macabdul9、Play-Your-Part 等全是个人社区上传，格式（如转 parquet）、切分、完整性均未经 Babylon Health 认证。官方唯一发布点是 GitHub 仓库 babylonhealth/primock57。研究者若为图方便从 HF 拉数据，可能拿到被改动或截断的版本而不自知。

坑 5：ECCA 是专有引擎，不可直接复现。
ASR 基准里的临床概念准确率（ECCA）使用的是一个"基于模糊字符串匹配、链接到 SNOMED-CT"的专有（proprietary）临床信息抽取引擎。论文只报告结果，未开源该引擎。因此 ECCA 数值无法被完整复现，只能作为方向性对标。要复现需自建等价的医学实体抽取+链接流程，结论未必数值一致。

坑 6：问诊记录生成没有唯一 ground truth。
评估论文明确披露：即便是"人工写的记录"也不被视为绝对正确——Lead Clinician 曾判定某评估者标注的"错误陈述"实为合理临床推断。评估者间一致性仅 0.268-0.431。因此一切以此为基准的"准确率"都只是近似，报告时应说明参考文本类型，并承认 ground truth 的多义性。

坑 7：自动指标分数必须绑定参考文本类型。
评估论文的核心发现是：同一指标以 edited_note 为参考时相关性远高于 human_note/eval_note。所以看到任何 PriMock57 上的 ROUGE/BERTScore 分数，先问"用哪个参考算的"——不声明参考类型的指标分数不具可比性。这也是复现基线时最容易出错的地方。

坑 8：机构已破产，链接与联系方式的长期风险。
Babylon Health 于 2023 年 8 月破产、英国业务被 eMed 收购。GitHub 组织账户与 @babylonhealth.com 邮箱存在失效风险。论文引用应优先用 arXiv 编号与 ACL Anthology（长期存档），并自行归档数据副本（含 LFS 对象）。不要依赖单一 URL 作为长期可访问性保证。

§11 数据质量与 DAIMS 评分

DAIMS（Data Asset Interoperability Maturity Score）从多个维度评估数据资产的成熟度。PriMock57 的评分如下（每项 1-5 分）：

DAIMS 维度	评分	依据
可发现性（Discoverability）	5	GitHub 公开仓库 + ACL Anthology 永久存档 + arXiv + 多处社区镜像；多路径可达
可访问性（Accessibility）	5	CC BY 4.0 直链，无 gated/请求制/审批；唯一门槛是 Git LFS（只需装工具，无需授权）
互操作性（Interoperability）	4	格式标准（WAV/TextGrid/JSON/CSV）；TextGrid 为语音学通用格式；扣分为音频经有损转码、无统一 schema 描述文件
元数据质量（Metadata）	4	各目录 README + 论文详尽描述；病例卡、核对清单齐全；扣分为无机器可读的数据字典（如 Croissant/Data Cards 标准）
许可清晰度（Licensing）	5	CC BY 4.0 全文在仓库，标准许可无歧义，商用/改编均允许
数据质量（Quality）	4	人工逐句转写 + 双声道 + <UNSURE>/<UNIN/> 诚实标注；扣分为模拟数据的生态效度损失
规模（Scale）	2	仅 57 场 / 8h38m，不适合从零训练，定位为基准与小规模微调验证
代表性与偏差控制（Representativeness）	3	覆盖 12 类常见主诉、口音多样；但英国中心、演员患者偏差、规模小
可持续性（Sustainability）	3	CC BY 4.0 保障可再分发；但机构破产、仓库归属存不确定，扣分
可复现性（Reproducibility）	4	附转换脚本（extract_utterances/textgrid_to_transcript/mix_audio）+ 评估数据全公开；扣分为 ECCA 引擎专有不可复现

综合定位：PriMock57 是一个**"开放性满分、规模有限"的数据资产。它的 DAIMS 画像鲜明——可发现性、可访问性、许可清晰度三项满分（这正是"以模拟换合规"策略的直接红利），而规模与可持续性是明显短板。这决定了它的正确用法是基准评测与微调验证**，而非大规模预训练。

11.5 使用前的数据准备建议

基于 DAIMS 画像中暴露的短板（无统一 schema、音频有损、ECCA 不可复现），使用前的准备建议如下：

准备项	建议
建立数据字典	自行编写机器可读的 schema（字段/类型/取值），弥补无标准 Data Card 的缺口
音频质量核查	抽查 WebM/Opus 转码对高频的影响，必要时对特定声学研究做说明
否定词与剂量专项检查	因 critical 错误多源于否定词（no/not）、药物名、剂量，建议单独评估这些类别的识别率
统一音视频对齐	用 TextGrid 的 xmin/xmax 严格对齐音频，避免切片漂移
评估者分组处理	human_eval_data 聚合时按 Evaluator 分组，控制个体风格噪声
口径记录	记录自己用的是人工转写还是自动转写作输入，这直接影响可比性
自归档	克隆后连同 LFS 对象一并归档，应对仓库归属风险

这套准备动作的核心是：把 PriMock57 当"原料"而非"成品"——它是高质量的研究素材，但要让结论可靠，使用者需自行补齐 schema、质检与口径记录这几道工序。

§12 总结

PriMock57 用 57 场模拟问诊、8 小时 38 分双声道音频，回答了临床 AI 领域一个长期困扰：当真实临床对话数据因隐私几乎无法公开时，如何建立可复现的研究基准？ 它的答案是用精心设计的模拟数据换取完全开放——CC BY 4.0、GitHub 直链、无任何审批门槛。

它的价值是三层叠加的：数据层（音频+人工转写+SOAP 记录+人类评估标注）、基准层（6 个 ASR 引擎 + 4 个记录生成基线的完整结果）、方法层（5 名 GP 的人类评估 + 18 项自动指标相关性研究）。特别地，它用严格的人类评估证明了"字符级 Levenshtein 距离与 BertScore 相当"这一反直觉结论，为整个医疗文本生成领域的评测方法选择提供了实证依据。

它的局限同样清晰：规模小（8.6 小时）、模拟性强（演员患者）、英国中心、机构已破产。这些不是缺陷而是明确的边界声明——论文本身就把数据集定位为"接近真实的务实替代"，并在首页坦诚模拟带来的取舍。

对研究者而言，PriMock57 最适合的角色是基准与评测方法论的载体：用它对标 ASR 模型、用它评测记录生成系统、借用它的人类评估协议标定自动指标——而把它当作真实临床语料去推断分布，则需要格外谨慎。这种"清楚知道自己在哪用、不能在哪用"的数据集，恰恰是 AI-Ready 评测基础设施最需要的类型。

FAQ（高频问答 30 问）

Q1：PriMock57 里的数据是真实患者吗？
不是。全部是模拟问诊——7 名 Babylon 临床医生与 57 名 Babylon 员工（扮演患者）按病例卡出演。没有任何真实患者参与，因此不涉及真实 PHI，也因此能以 CC BY 4.0 完全公开。

Q2：数据集名称怎么读？
“PriMock57” = Pri（primary care，基层医疗）+ Mock（模拟）+ 57（场次）。仓库名与论文名都是小写 primock57。

Q3：为什么只有 57 场，规模会不会太小？
规模确实小（8 小时 38 分），不适合从零训练大模型。它的定位是基准评测集——用来横向比较不同 ASR 引擎、评测记录生成系统、标定自动指标。这是论文的明确设计意图，不是缺陷。

Q4：音频是单声道还是双声道？
双声道——医生和患者各自独立录制一轨。这允许研究者分别评测、或混音后评测，从而分离说话人分离误差与识别误差。

Q5：音频总时长到底是多少？
论文正文：8h38m6s；仓库 README：8h:38m。双声道累计为 17h:16m（医生轨 + 患者轨相加）。最长单场 14m18s，最短 3m48s，平均 9m5s。

Q6：为什么音频要单独走 Git LFS？
音频体积大（WAV 未压缩），若直接放 Git 会让仓库膨胀几十倍。Git LFS 把大文件存在独立存储，克隆时按需拉取。不装 git-lfs 会拿到指针文件而非真音频。

Q7：转写是什么格式？
Praat TextGrid——语音学界通用标注格式。每句话一个 Interval，含 xmin（起）、xmax（止）、text（转写文本）。

Q8：转写里的 <UNSURE> 和 <UNIN/> 是什么？
<UNSURE> 表示转写员对内容不确定；<UNIN/> 表示该音频段不可辨识。这两个标签诚实标记了人工转写的边界，计算 WER 时应单独处理。

Q9：问诊记录是什么格式？
JSON，字段包括 day（日）、consultation（场次）、presenting_complaint（主诉）、note（记录正文）、highlights（医生高亮的医学术语列表）。

Q10：highlights 能当医学实体金标准吗？
不能完全。论文注明医生高亮"取决于是否有时间"，是部分标注，不保证覆盖全部重要术语。

Q11：ASR 基准里哪个引擎最好？
Google Cloud STT（mean WER 30.9）与 Azure STT（31.3）并列最优，且二者无统计显著差异（p=0.097）。医疗专用的 Amazon Transcribe Medical（34.0）并未胜出。

Q12：为什么医疗专用 ASR 反而更差？
论文只说"the medical-domain Amazon model does not seem to perform better"，未给因果解释。可能的原因是通用大厂的海量训练数据优势超过了领域定制的作用，或该"Primary Care"专用模型的适配并不针对对话场景。

Q13：WER 30% 是不是说明 ASR 很差？
不能这样理解。这是真实对话式语音的典型水平——含口语化、断句、重叠、背景噪声，与朗读式语料的低 WER 不可比。对话场景 20-30% 的 WER 已属可用范围。

Q14：ECCA 是什么，为什么重要？
ECCA（Extracted Clinical Concepts Accuracy）是基于临床概念抽取的准确率，链接到 SNOMED-CT 本体。它比 WER 更贴近临床——因为把"Fexofenadine"听错远比对漏掉"um"严重。ECCA 结论与 WER 大体一致。

Q15：ECCA 能复现吗？
不能完整复现。它用的是专有（proprietary）医学实体抽取引擎，论文未开源。数值只能作为方向性对标，自建等价流程未必一致。

Q16：记录生成基线哪个最好？
BART-finet（在 8,000 篇真实转写+记录上再微调）：ROUGE-1 0.31、BERTScore 0.81，全指标最高。通用摘要模型 BART-CNN、BERT-ext 甚至打不过"随机抽 15 句"的基线。

Q17：为什么通用摘要模型打不过随机？
因为问诊记录生成与通用摘要目标不同：通用摘要追求"提炼要点"，问诊记录要求"忠实、结构化、不遗漏临床关键信息"。通用模型在这种情况下会产生看似流畅但临床不忠实的输出。

Q18：人类评估是怎么做的？
5 名执业 GP（≥3 年经验）完成四任务：听音频写记录、后期编辑自动记录（track-changes）、量化错误陈述与遗漏（分 critical/非 critical）、给出定性反馈。每场 5 篇待评（4 模型 + 1 人工），共 285 篇。

Q19：评估者知道哪篇是人类写的吗？
不知道。设计上刻意打乱顺序且不告知哪篇非合成，以防偏见。

Q20：人类评估的关键结论是什么？
① 用 post-edit 时长、错误数、遗漏数可量化自动记录与人工记录的差距；② 记录长度与 post-edit 时长的相关达 0.413，是自动指标需超越的基线；③ 任务没有唯一 ground truth，专家间也不完全一致。

Q21：18 项自动指标研究得出什么？
最重要的发现：字符级 Levenshtein 距离与 BertScore 等模型型指标表现相当甚至更好。此外，所有指标高度依赖参考文本的选择（edited_note 参考下相关性最高）。

Q22：评估者间一致性高吗？
不高——Krippendorff α：post-edit 时长 0.431、错误陈述 0.374、遗漏 0.268。这反映了临床判断的主观性，也为自动指标的相关性设了噪声上限。

Q23：许可是什么？能商用吗？
CC BY 4.0，可以商用。唯一条件是署名。没有非商业限制、没有相同方式共享限制、没有禁改编限制。

Q24：怎么获取数据？
git clone https://github.com/babylonhealth/primock57.git，先 git lfs install。无需申请、无需审批、无 gated。

Q25：HuggingFace 上能直接下载吗？
HF 上的 primock57 全是个人社区镜像（utsav2000、piyushmaharana、macabdul9、Play-Your-Part 等），无官方托管。建议从 GitHub 官方仓库获取。

Q26：Babylon Health 破产影响数据可用性吗？
数据本身是 CC BY 4.0，可被任何人合法归档再分发，不会"灭失"。但 GitHub 组织账户与 @babylonhealth.com 邮箱存在失效风险，建议自行归档并优先引用 arXiv/ACL Anthology 链接。

Q27：这个数据集和 MedDialog 有什么区别？
MedDialog 是文本临床对话（中英），无音频；PriMock57 有双声道音频 + 人工逐句转写。两者互补：一个规模大、纯文本，一个小、带音频。

Q28：能用来研究方言/口音偏差吗？
有限。患者含四类口音（英式 47.4%、其他欧洲 31.6%、其他英语 10.5%、非英语 10.5%），论文也给了按口音的 WER 分档，但每档样本量很小（57 人分摊），统计功效有限。

Q29：能用来训练语音克隆/合成吗？
可以（许可允许），社区已有此类用途（如 Play-Your-Part 镜像）。但需注意仅 57 场、单一医疗场景、演员语音，训练通用 TTS 时代表性与规模都不足。

Q30：这个数据集最大的价值是什么？
"以模拟换开放"的范式样本——在真实临床数据普遍受限的领域，演示了一条用可公开模拟数据建立完整基准（ASR + 记录生成 + 评估方法论）的可行路径，并用严格的人类评估为领域提供了评测标尺。

Q31：数据里医生和患者的口音信息在哪里？
论文附表（Figure A.1）给出患者口音与年龄组分布；Table 3 给出按口音（en-gb / other）分档的 WER。医生口音在正文说明（5 英式 + 2 印度）。

Q32：能做说话人分离（diarisation）研究吗？
可以借鉴但非最佳。数据已是人工分离的双声道，本身不含"未分离混合音频"，因此不适合直接训练/评测说话人分离模型；但可作为 diarisation 的"黄金参考"对照。

Q33：Soap 记录的"highlights"能训练 NER 吗？
谨慎。highlights 是医生按需高亮、不保证完整，覆盖度不足，直接当 NER 金标准会低估召回。可作为弱监督信号或人工标注的起点。

Q34：语音里有没有标注情绪/语气？
没有。数据集只标注文本与时间，不含副语言（paralinguistic）信息（情绪、语速、停顿类型等）。做情感计算需自行标注。

Q35：咨询核对清单（checklists）有什么用？
医生在问诊中使用的结构化核对项，可用于研究与"问诊完整性/质量"相关的评估，或作为记录生成的额外上下文。注意仅覆盖 Clinician_1 与 Clinician_2 两位医生（共 27 个 xlsx）。

Q36：能不能做成问诊质量评估数据集？
可以探索。human_eval_data 提供了 GP 对记录的错误/遗漏判断，可衍生"记录质量评分"任务；但需注意其设计初衷是评测生成系统，非通用质量量表。

Q37：为什么叫"57"而不是别的数字？
就是实际采集到的场次数。5 天 × 每天约 10-15 场 = 57 场。不是抽样目标，而是采集结果。

Q38：有没有版本更新/后续数据集？
GitHub 仓库末次更新为 2022-11-16（加 checklists）。公开信息未见官方后续版本。相关延续工作多引用评估方法论或在其上评测新模型。

Q39：数据能用于商业产品训练吗？
CC BY 4.0 允许商用，唯一条件是署名。但要注意：数据是模拟的，直接用其训练的模型迁移到真实临床需额外验证。

Q40：如果我要复现论文结果，最小步骤是什么？
① git lfs clone 仓库；② 跑 extract_utterances.py 切句；③ 送入目标 ASR 算 WER（复现 Table 3）；④ 用转写→记录对训练/评测摘要模型（复现 Table 5）；⑤ 用 human_eval_data 做指标相关性分析（复现评估论文）。详见附录 B。

事实清单（硬事实 42 条）

1. 官方全称：PriMock57: A Dataset Of Primary Care Mock Consultations
2. slug：primock57
3. 问诊场次：57 场
4. 采集天数为 5 天（day1-day5）
5. 每日分布：day1 15 场、day2 10 场、day3 10 场、day4 10 场、day5 12 场
6. 临床医生：7 名（4 男 3 女；5 英式口音 + 2 印度口音）
7. 扮演患者：57 名 Babylon 员工
8. 患者性别：女 52.6% / 男 47.4%
9. 患者口音：英式英语 47.4%、其他欧洲 31.6%、其他英语 10.5%、非英语 10.5%
10. 患者年龄：多数 25-45 岁
11. 音频总时长：8h38m6s（论文口径）/ 8h:38m（仓库口径）
12. 双声道累计时长：17h:16m
13. 音频格式：WAV 16bit/16kHz
14. 音频原始来源：WebM 容器 / Opus 编码 / 可变码率
15. 单场时长范围：3m48s – 14m18s
16. 单场平均时长：9m5s
17. 音频文件数：114（57 场 × 2 声道）
18. 转写格式：Praat TextGrid
19. 转写文件数：114
20. 转写标签：<UNSURE>、<UNIN/>
21. 平均对话轮次：92 轮/场
22. 平均总词数：1,489 词/场
23. 医生词数：897 词/场
24. 患者词数：592 词/场
25. 医生平均轮长：19.3 词/轮
26. 患者平均轮长：12.8 词/轮
27. 记录文件数：57 个 JSON
28. 记录格式：SOAP；字段 day/consultation/presenting_complaint/note/highlights
29. 主诉类别：12 类
30. 咨询核对清单：29 个文件（Clinician_1 20 + Clinician_2 7 + 2 目录）
31. 人类评估 GP：5 名
32. 人类评估规模：285 篇记录（57 场 × 5 篇）
33. 评估每场构成：4 篇模型记录 + 1 篇人工记录
34. 评估论文微调模型：10 个 BART 模型
35. 评估论文训练数据：130,000 篇专有真实记录+转写
36. 自动指标数：18 项
37. ASR 引擎数：6 个（Kaldi/QuartzNet/Conformer/Google/Azure/Amazon）
38. ASR 最佳 WER：Google 30.9；Azure 31.3（无显著差异 p=0.097）
39. ASR 最差 WER：Kaldi 48.9
40. 记录生成最佳：BART-finet（R1 0.31 / BERTScore 0.81）
41. 评估者间一致性：post-edit 0.431 / 错误 0.374 / 遗漏 0.268
42. 许可：CC BY 4.0

术语表（28 条）

术语	英文	释义
模拟问诊	mock consultation	由演员按病例卡扮演患者进行的模拟诊疗，非真实患者
病例卡	case card	给扮演患者的"剧本"，含主诉、症状、病史等信息
基层医疗	primary care	以全科医生为首诊入口的医疗服务层级
SOAP 记录	SOAP note	Subjective/Objective/Assessment/Plan 四段式临床记录
问诊记录	consultation note	医生在问诊后写的病历文本
自动语音识别	ASR	Automatic Speech Recognition，语音转文字
词错误率	WER	Word Error Rate，ASR 核心指标（替换+插入+删除）/总词数
临床概念准确率	ECCA	基于医学概念抽取（链接 SNOMED-CT）的准确率
SNOMED-CT	SNOMED-CT	系统化临床医学术语集，国际临床术语标准
说话人分离	diarisation	区分"谁在什么时候说话"的标注
逐句转写	utterance-level transcription	以语义完整的单句为单位的转写
TextGrid	TextGrid	Praat 软件的语音标注格式
对话轮次	conversation turn	一方从开始说话到停下的一轮发言
后期编辑	post-editing	人工修正机器生成的文本
post-edit 时长	post-edit time	把机器记录修正为可用记录所需的时间（秒）
遗漏	omission	生成记录中缺失的关键信息
错误陈述	incorrect statement	生成记录中不正确的陈述
关键错误	critical error	若出错会引发医疗法律责任的错误
参考文本	reference	计算自动指标时用作"标准答案"的文本
ROUGE	ROUGE	基于 n-gram 重叠的摘要评估指标
BERTScore	BERTScore	基于 BERT 嵌入相似度的评估指标
Levenshtein 距离	Levenshtein distance	字符级编辑距离，最小的插入/删除/替换次数
BART	BART	去噪序列到序列预训练模型，常用于摘要
摘要	summarisation	把长文本压缩为短文本的任务
会话式 ASR	conversational ASR	针对自然对话（非朗读）的语音识别
Git LFS	Git Large File Storage	Git 大文件存储扩展
gated	gated	HF 上需申请/同意条款才能访问的受限数据集
生态效度	ecological validity	研究情境与真实情境的接近程度

附录 A：目录结构详解

PriMock57 仓库的完整目录树（据 GitHub API 实测，2026-10-03）：

primock57/
├── .gitattributes            # LFS 追踪规则
├── .gitignore
├── CONTRIBUTING.md
├── LICENSE.md                # CC BY 4.0 全文
├── README.md                 # 顶层说明
├── audio/                    # 114 个 wav（57场×2声道）+ README
│   ├── day1_consultation01_doctor.wav
│   ├── day1_consultation01_patient.wav
│   └── ...
├── transcripts/              # 114 个 TextGrid + README
│   ├── day1_consultation01_doctor.TextGrid
│   └── ...
├── notes/                    # 57 个 JSON + README
│   ├── day1_consultation01.json
│   └── ...
├── consultation_checklists/  # 29 个文件（含 README）
│   ├── Clinician_1/          # 20 个 xlsx
│   ├── Clinician_2/          # 7 个 xlsx
│   └── README.md
├── human_eval_data/          # 3 个数据文件 + README
│   ├── results.csv           # ~7.5 MB
│   ├── metric-scores.json    # ~12.3 MB
│   └── other-issues-taxonomy-examples.csv  # ~54 KB
└── scripts/                  # 6 个文件
    ├── extract_utterances.py
    ├── textgrid_to_transcript.py
    ├── mix_audio.sh
    ├── utils.py
    ├── requirements.txt
    └── README.md

附录 B：ASR 评测流程复现步骤

若要复现数据集论文 Table 3 的 WER，步骤如下：

1. 克隆（含 LFS）：

   git lfs install
   git clone https://github.com/babylonhealth/primock57.git
   

2. 切分单句音频：运行 scripts/extract_utterances.py，按 TextGrid 的时间戳把每场问诊切成一句一个音频片段。
3. 送入 ASR 引擎：对每个片段调用目标引擎（Google/Azure/Amazon/本地 Kaldi/NeMo）。注意 Google 用 video enhanced、en-us；Amazon 用 conversation 模型 + speciality=Primary Care。
4. 统一后处理：对人工与自动转写同时施加——去填充词（umm/uhh）、数字转文字、去标点、折叠空格、转小写。
5. 计算 WER：用 NIST SCTK 的 sclite 工具逐句比对，汇总 mean WER，并按性别/角色/口音分档。
6. 计算 ECCA（可选，不可完整复现）：需自建医学实体抽取+SNOMED-CT 链接流程。

附录 C：人类评估数据结构

human_eval_data/results.csv 的字段（据 human_eval_data/README.md）：

字段	含义
Evaluator	评估者 id（5 人之一）
Consultation	问诊 id（57 场之一）
Model	模型 id（10 个模型 + 1 个人工 “doctor”）
Evaluator Note	该评估者为该问诊写的记录（57 × 5 = 285 篇）
Model Note	该模型为该问诊生成的记录（57 × 5 = 285 篇）
Post-edited note	评估者后期编辑后的记录（含 XML 标注增删）
Post-edit time	后期编辑耗时（秒）
Incorrect Statements	错误陈述列表（! 开头为 critical，- 开头为非 critical）
Omissions	遗漏列表（! 关键，- 非关键）
Other Issues	定性反馈

metric-scores.json：18 项指标对三种参考（human_note/edited_note/eval_note）分别取平均与最大值的分数。

other-issues-taxonomy-examples.csv：定性反馈按错误分类法归组，首列是分类名。

附录 D：ASR 引擎配置速查

引擎	类型	配置要点
Kaldi	开源/本地	Zamia Speech 声学模型 + 3-gram 医疗问答 LM
NeMo QuartzNet	开源	Nvidia NeMo，无 LM，端到端
NeMo Conformer	开源	Nvidia NeMo，无 LM，字符级
Google Cloud STT	商用	video enhanced 模型，en-us
Amazon Transcribe Medical	商用/医疗	conversation 模型，speciality=Primary Care
Azure STT	商用	Standard 模型

附录 E：关键来源 URL

来源	URL
GitHub 官方仓库	https://github.com/babylonhealth/primock57
数据集论文 arXiv	https://arxiv.org/abs/2204.00333
评估论文 arXiv	https://arxiv.org/abs/2204.00447
ACL Anthology	https://aclanthology.org/2022.acl-short.65/
数据集论文 DOI	https://doi.org/10.18653/v1/2022.acl-short.65
TextGrid 格式说明	https://www.fon.hum.uva.nl/praat/manual/TextGrid.html
Git LFS	https://git-lfs.github.com/
Babylon 破产 SEC 文件	SEC Form 8-K（2023-08-31）

附录 F：完整硬数字速查（供交叉核对）

类别	数字	来源
问诊场次	57	论文/仓库
采集天数	5	论文/仓库
临床医生	7	论文/仓库
扮演患者	57	论文/仓库
评估 GP	5	评估论文
评估记录总数	285	评估论文
微调模型数	10	评估论文
微调训练数据	130,000 篇	评估论文
自动指标数	18	评估论文
ASR 引擎数	6	数据集论文
音频总时长	8h38m6s	论文正文
音频总时长（仓库）	8h:38m	audio/README
双声道累计	17h:16m	audio/README
采样率	16kHz/16bit	audio/README
音频文件数	114	仓库实测
转写文件数	114	仓库实测
记录文件数	57	仓库实测
核对清单文件数	29	仓库实测
平均对话轮次	92	论文
平均词数	1,489	论文
医生词数	897	论文
患者词数	592	论文
医生轮长	19.3 词	论文
患者轮长	12.8 词	论文
单场平均时长	9m5s	论文
单场时长范围	3m48s–14m18s	论文
主诉类别数	12	论文 Table 1
最佳 ASR WER	30.9（Google）	论文 Table 3
最差 ASR WER	48.9（Kaldi）	论文 Table 3
最佳记录生成 R1	0.31（BART-finet）	论文 Table 5
一致性 post-edit	0.431	评估论文 Table 2
一致性 错误陈述	0.374	评估论文 Table 2
一致性 遗漏	0.268	评估论文 Table 2
长度-时长相关	0.413	评估论文
错误-遗漏相关	0.829	评估论文 Table 4
患者英式口音占比	47.4%	论文

附录 G：常见误用与纠正

误用	纠正
把 57 场当作真实患者问诊	全部模拟，演员按病例卡出演
从 HF 直接下载当官方数据	HF 全是社区镜像，官方在 GitHub
不装 git-lfs 就 clone	音频会是指针文件，必须 git lfs install
用通用 WER 直觉评判 30% 结果	对话式语音 WER 本就高，非引擎差
报告指标不声明参考文本	edited/human/eval 三种参考结果差异巨大
认为复杂指标（BertScore）一定更好	论文证明 Levenshtein 相当甚至更好
用 human_note 当唯一 ground truth	专家间一致性仅 0.27-0.43，无唯一标准
忽略机构破产的链接风险	建议自归档 + 引用 arXiv/ACL 链接
用 ECCA 数值直接对比自建流程	ECCA 用专有引擎，不可完整复现
假设跨语言可迁移	仅英语、英国中心，泛化未验证

附录 H：与其他数据集的选型决策树

需要临床对话数据？
├─ 需要音频？
│  ├─ 是 → 需要人工转写？
│  │     ├─ 是 → PriMock57（本项目）
│  │     └─ 否 → Kazi et al. 2020（精神科，仅自动转写）
│  └─ 否 → 需要多语言？
│        ├─ 是 → MedDialog（中英）
│        └─ 否 → COVID-Dialogue / MTSamples
└─ 需要真实临床记录（非对话）？
   ├─ 需要公开直链 → MIMIC-IV-Note（受限）/ MTSamples
   └─ 需要完全开放 → MIMIC-IV（需 DUA）

这个决策树帮助检索者在临床 NLP 数据生态中定位 PriMock57 的适用位置：需要"带音频 + 人工转写 + 公开"时，它几乎是唯一选择。

延伸阅读：相关数据集与工作

同一数据集的两篇论文（必读）：

• Papadopoulos Korfiatis, Moramarco, Sarac, Savkov. PriMock57: A Dataset Of Primary Care Mock Consultations. ACL 2022 Short Papers, pp.588-598. arXiv:2204.00333.
• Moramarco, Papadopoulos Korfiatis, Perera, Juric, Flann, Reiter, Belz, Savkov. Human Evaluation and Correlation with Automatic Metrics in Consultation Note Generation. ACL 2022. arXiv:2204.00447.

论文相关工作链（临床对话/记录生成）：

• Kazi et al. 2020：70 场模拟精神科问诊，有音频+自动转写+记录，无人工转写——PriMock57 主要对标对象。
• He et al. 2020（MedDialog）：中英临床对话文本数据集，无音频。
• Ju et al. 2020（COVID-Dialogue）：COVID-19 相关临床对话，源于在线问答。
• Krishna et al. 2021：从医患对话生成 SOAP 记录的模块化摘要方法。
• Enarvi et al. 2020：seq2seq 从医患对话生成医疗报告。
• Joshi et al. 2020（Dr. Summarize）：利用局部结构的医疗对话全局摘要。

通用会话语音基准（非医疗，方法对照）：

• Switchboard（Godfrey et al. 1992）：电话语音语料，会话 ASR 的经典基准。
• Fisher（Cieri et al. 2004）：Switchboard 的后续大规模电话语音资源。

评测方法学参照：

• Fabbri et al. 2021：新闻摘要的自动指标相关性研究（PriMock57 评估论文的直接方法学前身）。
• Celikyilmaz et al. 2020 / Sai et al. 2020：NLG 评估指标分类学。

库内互链条目：MedDialog（210）、MEDIQA（220）、MTSamples（350）、MIMIC-IV-Note（47）、MIMIC-IV-Clinical-Database（4）、ClinicalTrials.gov（556）、Radiolog-Instruct-Dataset（625）。

抓取与核验说明

本条目成稿于 2026-10-03，核心事实的核验路径如下：

事实类型	核验来源	方式
数据集真实存在	GitHub 官方仓库 + ACL Anthology + arXiv 三源互证	三方独立可达
仓库目录结构	GitHub API trees/main?recursive=1	实测（含文件清单与大小）
许可	LICENSE.md 全文下载	实测确认为 CC BY 4.0
音频规格	audio/README.md	原文抓取
转写格式	transcripts/README.md	原文抓取
记录字段	notes/README.md	原文抓取
人类评估结构	human_eval_data/README.md	原文抓取
硬数字（57/7/5 天/8h38m 等）	数据集论文 PDF（arXiv:2204.00333）	pdftotext 提取
WER/ECCA 表	数据集论文 Table 3	原文提取
记录生成基线	数据集论文 Table 5	原文提取
人类评估与 18 指标	评估论文（arXiv:2204.00447）	arXiv HTML 提取
Babylon 破产	SEC Form 8-K + 多家媒体	交叉核验

三源互证结论：数据集真实存在，官方名称为 PriMock57，规模/license/获取方式均可查证。任务头 brief 与实核结果一致，无需改道。

库内查重：ai_ready_dataset 表 status=1 中 url_name 匹配 primock/mock/consult 的记录数为 0；writing/primock57/ 无同名目录——无撞库，正常成稿。

尾注

本条目基于 PriMock57 数据集官方仓库（babylonhealth/primock57，含 README.md 与各子目录 README.md）、数据集论文（arXiv:2204.00333 / ACL 2022 短论文 pp.588-598）、配套人类评估论文（arXiv:2204.00447）以及 Babylon Health 破产相关公开信息（SEC Form 8-K 2023-08-31、多家媒体报道）撰写。全部硬数字均标注来源口径；仓库结构与文件数经 GitHub API 实测（2026-10-03）。

口径与存照说明：

• 音频时长存在论文（8h38m6s）与仓库（8h:38m）两种格式口径，均指同一时长，已在坑 2 存照。
• ASR WER、ECCA、记录生成指标均取自两篇论文的 Table 3、Table 5；人类评估一致性取 Table 2。
• HuggingFace 镜像均非官方，本条目不采信镜像数据，一应以 GitHub 官方仓库为准。
• Babylon Health 破产与数据可用性：数据本身 CC BY 4.0，不受机构破产约束；但仓库长期存续存在不确定性，已在 §8.2 与坑 8 提示。

引用建议：优先引用 ACL Anthology 版本（10.18653/v1/2022.acl-short.65）与 arXiv:2204.00333；数据引用注明 CC BY 4.0 与 GitHub 仓库地址；使用评估数据时另引 arXiv:2204.00447。

核心源：PriMock57: A Dataset Of Primary Care Mock Consultations（Papadopoulos Korfiatis, Moramarco, Sarac, Savkov, ACL 2022）；Human Evaluation and Correlation with Automatic Metrics in Consultation Note Generation（Moramarco et al., ACL 2022）。

---

相关数据集导航

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

• mednli — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• trec-ct-2021 — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• er-reason — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• medsecid — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• tcm-sd — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• generated-codes-low-resource — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• labelled-notes-hospital-course — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• mietic — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• discharge-summary-templates — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准
• medisumqa — 共享标签：医疗NLP / 临床文本 / 电子健康记录 / 评测基准

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