DrugEHRQA：结构化与自由文本双模态用药问答

用药是住院期间记录最密、也最难从文本里读准的一类信息。处方表里有一行行剂量与途径，出院小结里有一段段「口服每日一次」的叙述，两处记的是同一件事，却经常对不上：表格记的是开立时的规格，小结记的是实际吞下去几片。要回答「这位患者为什么用这个药」，只看表格答不出理由；只读小结又拿不到精确剂量。

这套数据集把两路放到同一个问题上。70,381 条问答，每条给出一个自然语言问题、一条可在 MIMIC-III 上执行的 SQL、从处方表取回的答案、从出院小结取回的答案，以及按规则合并后的第三份答案。问题的起点是 505 份带用药标注的出院小结，模板只有九个，句式重复度很高。

它的价值在于把「同一问题的两种证据」显式摆出来，让模型必须处理一致、互补与冲突三种情形。局限也同样明确：问题来自模板而非医生真实提问，答案只是检索结果而非临床判断，全部为英文，且分散在两个受限仓库。

§1 它是什么：一份把两路证据并排放的问答集

1.1 一句话定义与三条边界

这是一套以用药关系为唯一主题、以模板生成为唯一手段、以双路答案并置为唯一特色的英文医疗问答基准。

「以用药关系为唯一主题」意味着九个模板全部围绕药名、剂量、剂型、途径、疗程与用药理由。不涉及诊断推理、不涉及影像、不涉及时间序列预测。做非用药类问答的研究者用不上它。

「以模板生成为唯一手段」意味着句式高度可控但极度单一。九个模板各三个改写，合计句式的多样性上限就是这三十六个骨架。真实临床提问的长尾在这里完全缺席。

「以双路答案并置为唯一特色」是它区别于 emrQA 与 MIMICSQL 的地方。前者只用自由文本，后者只用结构化表，两路各自成立，但从不要求模型在两者之间做证据权衡。这套数据把权衡这件事变成了任务的一部分。

1.2 数据的四个组成部分

组成	内容	数量口径	存放位置
结构化三元组	问句、SQL、处方表答案	四万一千余条	PhysioNet
自由文本问答	问句、出院小结答案	未单独公布条数	n2c2 仓库
合并答案	按规则选出的多模态答案	覆盖全量	需运行脚本生成
改写版本	每个模板三个改写	句式骨架 36 个	与主数据同存

四个部分的存放位置不同，这一点直接影响可复现性。拿到 PhysioNet 的包只完成了一半，另一半在 n2c2，需要另外申请、另外同意条款。两个仓库的许可不完全一致，作者用「因许可问题」来解释这种拆分。

合并答案不是现成文件，而是要靠两个脚本跑出来。官方使用说明要求先下结构化包、放进指定目录，再从 n2c2 取自由文本部分，然后依次运行合并脚本与生成脚本。跳过任何一步，得到的都不是完整数据集。

1.3 生成链的五个环节

链条的起点不是数据集本身，而是一批已有的标注。

第一步，人工标注九个问题模板与对应的 SQL 模板。九个里有五个直接取自 emrQA 的用药类模板，另外四个是新写的。模板的设计约束是「答案在两路里都能找到」，这一条决定了后面所有环节的可行性。

第二步，从 n2c2 挑战赛的 505 份出院小结标注里抽出药名与六类属性：规格、剂型、途径、剂量、频次疗程、用药理由。这一步是整个流程的关键借用——标注是别人为另一个任务做的，这里拿来当槽位字典。

第三步，用抽出的槽位值填充模板，同时生成自然语言问题与 SQL。同一个住院号、同一个药名进入两条模板，保证问句与查询指向同一事实。

第四步，改写。每个模板生成四个版本，即三个额外的改写。SQL 随机映射到其中一个改写，不随改写变化。

第五步，合并。按三条规则从两路答案里选出最终答案。

这条链的巧妙处在于「借标注」。为问答任务重新标注七万条不可能，但把已有的药物抽取标注当成槽位字典，成本降到几乎为零。代价是数据分布被那 505 份小结的分布锁死——只有出现过药物不良事件的患者在里头。

1.4 九个模板与四档难度

模板按药物属性组织，难度按 SQL 结构组织，两者不是一一对应。

序号	问的是什么	主要用到的表	难度档
1	这位患者用了哪些药	PRESCRIPTIONS	简单
2	某药的规格是多少	PRESCRIPTIONS	中等
3	某药的剂型是什么	PRESCRIPTIONS	中等
4	某药的给药途径是什么	PRESCRIPTIONS	中等
5	某药的剂量是多少	PRESCRIPTIONS	中等
6	这位患者用某药用了多久	PRESCRIPTIONS	困难
7	这位患者为什么用某药	PRESCRIPTIONS 联 DIAGNOSES_ICD 联 D_ICD_DIAGNOSES	极难
8	这位患者针对某问题用了什么药	三表嵌套	极难
9	某问题的用药与剂量都列出来	三表嵌套	极难

难度判定沿用 RAT-SQL 的口径，看 WHERE 条件数、聚合列数、有无 GROUP BY 与 ORDER BY、涉及表数与是否嵌套。第 1 条只有一列聚合与一个条件，判为简单；第 7 至 9 条含嵌套与多表连接，判为极难。

值得注意的是第 7 至 9 条同时是语义上最含糊的一类。「为什么用这个药」在 MIMIC-III 里没有直接字段，只能通过诊断编码反推。反推得到的理由是诊断清单里的某一条，未必是医生当时的真实考虑。这一点在下文的质量部分还会展开。

1.5 与三代前作的关系

这套数据处在一条演进线上，理解它需要知道前两代做了什么。

emrQA 用自由文本，把 n2c2 五个挑战任务的标注转成一 million 量级的逻辑形式与四万余条证据对。它的强项是文本定位，弱项是完全不碰结构化表。MIMICSQL 反过来，只用结构化表，把自然语言映射到 SQL。它的强项是查询生成，弱项是看不到文本里的细节。

第三代把两路并置。这既是进步也是妥协：进步在于任务更接近真实的信息检索场景——医生问一个问题，既可能去查表也可能去翻病历；妥协在于为了两路都可答，问题只能限制在「两路都记」的那一族关系上，用药恰好满足这个条件，诊断推理则不满足。

这条线的下一步在论文里写得很清楚：目前的多模态仍停留在「选一路来答」，尚未做到「联合两路推理」。作者把这个留作未来工作。

1.6 数量口径的三种说法

同一套数据在不同位置出现三个数量，各有各的口径，混用会出错。

第一处，PhysioNet 页面摘要给出的结构化部分是四万一千四百余条三元组。这是只有 SQL 与结构化答案的那一批。

第二处，论文与页面都说全量七十千余条。这是含自由文本答案与合并答案的完整集合。

第三处，两路都有答案的是一万二千七百余条，占全量的 18.1%。这一批才是真正意义上的双模态样本。

三者的关系是包含而非并列。引用时若只写「七万条问答」，读者会以为每条都有两路答案；若只写「四万条」，又漏掉了文本那一路。准确的说法是分层写清，或至少注明属于哪一批。

§2 数据构成：一条问答里到底有什么

2.1 一行记录的字段

以结构化部分为例，每行三个字段。

NL_Question 是自然语言问题，句式固定，槽位已填实。例如「What is the dosage of PREDNISONE prescribed to the patient with admission ID 103142」。

SQL_Query 是可执行的查询，条件里带同一个住院号与同一个药名。上例对应的是从处方表取剂量值与剂量单位两列，条件是住院号等于 103142 且药名等于 PREDNISONE。

Answer_Structured 是执行结果。上例返回的是一个元组，里面有两个剂量值，说明同一次住院里该药被开立过两次且剂量不同。

三个字段的关系是严格对应的：问题里的每个槽位在 SQL 里都有对应条件，SQL 的返回就是答案。这种对应性是模板生成的直接好处，也是它的局限——真实提问里槽位常常残缺或含糊，而这里每个槽位都必须填满。

2.2 答案为什么常常是列表

上例返回两个值而不是一个，这不是个例。

处方表的一行是一条开立记录，不是一次用药事件。同一位患者同一种药可能被开立多次，剂量随病情调整。因此「剂量是多少」这个问题在数据层面本来就没有唯一答案。

这一点对评测影响很大。若把答案当集合比，模型只要命中其中一个就算对；若当序列比，顺序不同就判错。论文用的是精确匹配，具体怎么处理多值未在正文说明，这是复现时首先会撞上的口径问题。

更麻烦的是空答案。某些住院号与药名的组合在处方表里查不到，SQL 执行返回空集。这类样本在数据里是存在的，论文也承认「某些问题的答案可能不存在」。空答案样本该保留还是该剔除，直接改变难度分布。

2.3 SQL 的四种结构

从可执行性角度看，九个模板的 SQL 分四类。

单表单条件，如第 1 条。这类查询几乎不会写错，模型学会了映射就能过。

单表多条件，如第 2 至 5 条。多出的条件是与药名的等值匹配，难点在药名的大小写与拼写。

单表带聚合与分组，如第 6 条。要把同一住院同一药的多条记录的疗程天数求和。聚合函数与分组字段的对应关系是这类查询的主要出错点。

多表嵌套，如第 7 至 9 条。内层从诊断表取疾病编码，外层用编码去处方表取药，或反过来。嵌套层次与连接条件是难点，也是这套数据相对前作的主要增量。

四类结构的占比直接决定基准的区分度。若极难档真占一半，那么一个只会写单表查询的模型在这套数据上的分数会很低——这正是设计者想要的效果。

逐类看具体难点，能看清这套基准想考的是什么。

单表单条件这一档考的是「能不能把短语映射到列名」。问题里说「用了哪些药」，列是处方的药名列。难点不在逻辑而在词汇：模型必须知道药名对应的是 DRUG 而不是 PROD_STRENGTH，而两个列名里都带药的意思。

单表多条件这一档考的是「能不能处理复合约束」。两个条件之间是「与」的关系，且第二个条件的值来自问题里的槽位。真实的失败模式是漏掉第二个条件，只按住院号返回全部用药，答案集合被放大几十倍。这种错误在执行准确率上有惩罚，但逻辑形式准确率可能只差一点，两个指标的分歧正出在这里。

单表带聚合这一档考的是「聚合与分组的配对」。要把同一住院同一药的疗程天数求和，求和之前必须先分组，分组字段必须包含药名，否则同一住院的多种药会被加在一起。漏掉药名这个分组字段是典型错误，且结果看起来像是一个合理数字，不执行一遍很难发现。

多表嵌套这一档考的是「连接路径的选择」。三张表的连接有两条可能路径：一是从诊断表的编码经字典表拿到病名，再从同一住院号的处方表取药；二是从处方表拿到药，再反查该住院的诊断。两条路径在语法上都成立，语义上却不同——前者得到「这个病的用药」，后者得到「这个住院所有药里与病名相关的那些」。差异在于是否按疾病过滤，而这层过滤在问题里是隐含的。

这种隐含条件是多表档真正的难点，也是它与前作的最大差别。MIMICSQL 的查询多为单表，emrQA 的答案全在文本里，两者都不会迫使模型去思考「隐含的过滤条件该不该加」。

2.4 自由文本那一路的形态

文本答案不是一句话，而是一个短语，外加它在出院小结里的出处行。

论文附录给了一个典型例子。问某住院号患者的阿司匹林剂量，结构化答案给出两个毫克数，文本答案是「ONE (1)」，出处行是「325 mg Tablet Sig: One (1) Tablet PO DAILY」。

三个答案都对，但表达的单位不同：表格给毫克，文本给片数。要把它们对齐，必须知道一片是多少毫克，而这个换算关系不在数据里显式给出，只能从同一行的规格推出。

这个例子说明双模态的核心难点不是「找答案」，而是「判断两个答案是否等价」。等价判断需要单位换算、缩写展开与剂型知识，三者都不在数据集里提供。论文附录专门列了一张常见缩写对照表，把片、胶囊、吸入、注射、静脉、口服与鼻饲的写法统一，就是为了处理这件事。

2.5 合并答案的三条规则

合并逻辑不复杂，但顺序敏感。

第一条，只有一路有答案时，取那一路。

第二条，两路答案有交集时，取交集。理由是两路一致会提高可信度。

第三条，两路都非空但无交集时，按问题是否属于衍生关系来选择：非衍生关系取结构化表，衍生关系取自由文本。

「衍生关系」指的是答案在表里没有直接字段、需要推理才能得到的关系。论文举的例子是「某患者为什么用某药」——表里只有诊断编码，没有「理由」字段，理由要靠编码与药物的对应去推；而小结里往往直接写了「因高钾血症予降钾树脂」。所以这类问题应当信文本。

规则的问题在于第三条的后半句与第二条的默认倾向相反。第二条整体上偏向结构化表（有交集取交集，无交集时非衍生取结构化），第三条又在衍生类上反转。这意味着规则的取向不是单一的「结构化优先」，而是「按模板类型分别定优先级」。若实现时忽略这一层，全按结构化优先，衍生类样本的正确率会明显下降。

2.6 改写与 SQL 的错位

每个模板生成四个版本，即三个改写。论文特意说明 SQL 随机映射到其中一个改写。

这个设计的用意是让模型不能靠句式记忆反推 SQL。但它带来一个副作用：同一 SQL 对应的四个问句在数据里只出现一个，另外三个版本不附 SQL。若研究者想用全部改写做数据增强，需要自己按模板回溯映射关系。

改写的影响在实验里有量化：加入改写后，两个 Text-to-SQL 模型的逻辑形式准确率分别下降 0.6 与 0.7 个百分点。降幅不大但方向明确——改写确实提高了难度，只是提高得有限，因为改写仍是在模板骨架内换词，没有改变句法结构的复杂度。

2.7 与 MIMIC-III 的依赖关系

这套数据不是一个独立数据集，而是 MIMIC-III 的一个派生视图。

三类依赖必须清楚。第一，住院号是外键，指向 MIMIC-III 的住院表；没有原库，答案无法验证。第二，表名与列名沿用 MIMIC-III 的英文命名，SQL 的可执行性完全依赖原库结构。第三，患者的临床事实（年龄、诊断、用药）全部来自原库，数据集只增加了「问题」这一层。

这意味着使用门槛是双重的：既要拿到这套数据的凭证，也要拿到 MIMIC-III 的凭证。PhysioNet 的凭证体系覆盖两者，但申请时必须两项都通过审核。

2.8 版本与仓库的分离

结构化部分在 PhysioNet，自由文本部分在 n2c2。两个仓库各有各的版本与条款。

PhysioNet 侧只有一个版本，2022 年 4 月 12 日发布，此后无更新。n2c2 侧的可用状态在论文写作时尚未放行，附录注明「即将可用」。这一条对当下的使用者很关键：若 n2c2 侧至今未放行，双模态的后半部分就拿不到，只能做纯结构化那一支。

分开存放的后果是复现难度上升。一篇声称复现了多模态结果的论文，必须同时说明两个仓库的取数日期与版本，否则无法判断它用的是哪一批。

§3 怎么拿到：两层凭证与两份协议

3.1 获取路径

结构化部分走 PhysioNet 的凭证流程，三层：账号认证、签署凭证式健康数据使用协议 1.5.0、完成 CITI 的「仅数据或样本研究」培训。三项齐备后文件才可见。

自由文本部分走 n2c2 的流程。n2c2 的数据在哈佛数据库门户上申请，需要单独提交用途说明并获得批准。两套流程不通用。

配套代码在 GitHub，公开可访问，不受凭证限制。但代码本身不含数据，跑起来仍然要本地已有两份数据。

3.2 两份协议的关系

PhysioNet 的协议约束的是「不得再分发」「不得尝试重识别」「仅用于研究」。n2c2 的条款在细节上更严，通常还要求定期报告使用情况与成果。

两份协议叠加的后果是：即使拿到了 PhysioNet 那部分，也不能把两路拼好的完整数据集分享给合作者，除非对方同时满足两边的条件。这对多机构合作是实质障碍。

论文用「因 n2c2 仓库的许可问题」解释拆分，话很短，但指向的是真实的合规约束，而非技术选择。

3.3 三条使用约束

不得再分发。 包括同机构的其他课题组。每位使用者单独取证。

不得重识别。 问题与 SQL 里带住院号，这些在 MIMIC-III 框架内是允许保留的假名标识，但不得与其他数据源交叉匹配。

成果须声明。 使用该数据发表的论文，按惯例需引用 PhysioNet 条目与配套论文两处。

3.4 实际操作中的四个卡点

凭证、协议、培训这三步在文件里写得清楚，真正耗时间的是文件之外的四件事。

第一，CITI 培训的时效。 培训证书有有效期，通常三年。若项目跨年，中途证书过期，PhysioNet 侧的访问会被中断，需要重做。多人协作时更要提前对齐：一个人的证书过期，整条数据流水线就断在那一环。

第二，n2c2 审批的不确定性。 n2c2 的数据申请走哈佛数据库门户，需要提交研究用途说明，审批周期无公开承诺。若课题有时间节点，这条路径是排期上最大的风险点。稳妥做法是把它当作「可能拿不到」来规划：先只做结构化那一支，若后续放行再补双模态。

第三，两套凭证的身份绑定。 PhysioNet 与 n2c2 各自绑定个人身份，不能用一个机构账号代替。这意味着五位合作者要各做五遍流程，而不是一个人办好再共享。这与「不得再分发」是同一条约束的两面。

第四，代码与数据的版本错配。 GitHub 上的脚本会更新，PhysioNet 的数据包不会。若脚本在某次提交里改了拼接逻辑（例如住院号字段的处理方式），用新版脚本跑旧版数据，可能得到与论文不一致的结果。稳妥做法是在复现时锁定脚本的提交哈希，并在方法部分写明。

§4 质量与已知问题

4.1 模板化带来的分布窄化

九个模板、三十六种句式，这是全部的语言多样性。

真实临床提问的形态要丰富得多：有省略主语的、有指代前文的、有一句话里问两件事的、有带否定与条件的。模板句全部是完整句、单一意图、槽位填满。用这套数据训练出来的模型，在真实提问上会遇到分布外问题。

这不是设计缺陷，而是自动化生成的必然代价。作者在局限里承认了这一点，措辞是「问题模板的多样性受限于从挑战赛数据里抽出的关系类型」。真正的限制其实更靠前：受限于「必须能用模板表达」这一条。

4.2 患者群体的选择偏倚

起点是 505 份出院小结，而这批小结来自 2018 n2c2 药物不良事件与用药抽取挑战赛的数据集。该挑战赛选的是「住院期间发生过药物不良事件」的患者。

这个筛选条件的影响是系统性的。用药种类更多、用药更复杂、住院更长、合并症更多的患者在此被过度代表。基于这批人做出的用药问答模型，在普通住院人群上的表现未知。

更细一层：505 份小结对应多少个住院号、多少个患者，论文未给。若一位患者多次入院各有一份小结，去重后的人数会小于 505。这个数字缺失使得「覆盖多少患者」无法回答。

4.3 答案的语义层级不统一

同一个问题「剂量是多少」，在结构化那一路返回的是毫克数，在文本那一路返回的是片数。两者都对，但不在同一语义层级上。

合并规则用「有交集取交集」处理这种情况，可前提是两路答案能被判定为相同。片与毫克在没有规格信息时无法比较，规则实际会退化为「无交集，按模板类型选一路」。

这意味着合并答案的质量取决于一个未在数据集里显式建模的知识：剂型换算。使用者若要严格评估，需要自己建一张换算表，而这张表对不对，无从验证。

4.4 用药理由的循环论证风险

第 7 至 9 条模板问「为什么用这个药」，答案由 SQL 从诊断表联出。得到的是一串诊断名称。

问题在于：这些诊断名称本来就可能来自「患者用了什么药」的推断。ICD 编码由病案编码员根据整份病历填写，用药是重要依据之一。用诊断解释用药，再用用药反推诊断，逻辑上是一个环。

对问答任务本身这不构成错误——任务只要求检索出正确的诊断名。但若有人把答案当作「真实的用药理由」去做药物流行病学分析，就会把编码惯例当成临床事实。

4.5 空答案与不可执行 SQL

论文承认某些组合在表里查不到答案，SQL 返回空集。这类样本的处理方式未在正文说明。

还有一类更隐蔽的问题：SQL 可执行但语义不对。例如第 6 条问「用了多久」，SQL 是把该住院该药所有开立记录的疗程天数求和。若同一药被间断开立，求和得到的是累计天数而非连续疗程，两者临床含义不同。SQL 写对了，答案也不是问句想要的那个。

逻辑形式准确率与执行准确率两个指标的差距，部分就来自这类情况。前者只看结构，后者看结果，但两者都不检验「结果是否回答了问句的本意」。

4.6 核验样本的代表性

人工核验抽了 500 条，占全量不到百分之一。三名标注者交叉核对，错误率 0.2%。

抽样方法只说是随机，未提分层。而合并规则的争议恰恰集中在衍生关系类模板上，这类模板在九个里占三个，若随机抽样按条数均分，衍生类样本在 500 条里约一百多条，够看出大问题但不足以估计每个模板的细粒度错误率。

0.2% 这个数字的正确解读是「规则整体可用」，而非「每个模板都可靠」。

4.7 日期与去标识的继承问题

数据集继承 MIMIC-III 的去标识处理：日期被平移到未来区间、姓名被替换、住院号被重新编号。

这些处理对问答任务影响不大，但有一处需要注意：问题里的住院号是重新编号后的值，与原始病历的编号不对应。若研究者试图把答案回溯到公开文献里的病例，会找不到。

4.8 一个被忽略的偏倚来源：药名写法

处方表里的药名不是标准化词表，而是开方时的录入字符串。

同一种药可能有多种写法：全名与商品名、大写与小写、带剂量后缀与不带、含盐基与不含。这套数据的 SQL 用等值匹配来取答案，等值匹配对写法极其敏感。若问题里的药名来自出院小结（小写、商品名），而处方表里存的是大写全名，查询就会返回空集。

空集的后果不是报错，而是静默。SQL 语法正确、执行成功、结果是空——流程完全没有提示，样本就这么变成了无答案样本。这也是「某些问题答案可能不存在」的一部分真实来源：其中有些不是临床上没有，而是写法没对上。

论文的模板设计部分没有讨论正规化。附录的缩写对照表处理的是剂型与途径的缩写（片、胶囊、口服、静脉），不涉及药名。这意味着药名的写法归一化要么在前置步骤里做了但未写明，要么根本没做。

复现时这一点必须先自查：抽一批样本，把问题里的药名与处方表里的药名做字符串比对，统计完全一致的比例。若这个比例明显低于一，说明存在写法鸿沟，需要自己建映射表。建映射表的成本不低——MIMIC-III 的处方表药名有上千种不同写法，人工归一化是数天的工作量。

同样的写法问题也出现在诊断名上。第 7 至 9 条模板用诊断描述做匹配，而描述来自字典表的 LONG_TITLE 字段，是自由文本。同一个疾病可能有长短两种写法，是否都能匹配上取决于字典表的实际内容。

§5 能做什么：五类任务与实现要点

5.1 任务一：Text-to-SQL 的领域适配

这是最直接的用法。用这套数据微调一个通用 Text-to-SQL 模型，看它在医疗 schema 上的表现。

实现要点有三。第一，schema 要完整给出，包括三张表的列名与类型，因为模型必须知道 DOSE_VAL_RX 与 PROD_STRENGTH 的区别。第二，评测要同时报逻辑形式与执行两个指标，两者差距大说明模型在抄结构而非理解语义。第三，要按难度分档报，只报总体会掩盖极难档的失败。

论文给出的参照数字：TREQS 在不带恢复机制时逻辑形式准确率 63.84%，带恢复机制时 64.8%，执行准确率 64.9%；RAT-SQL 的逻辑形式准确率 87.23%，但论文明确说这个数字不能与前者直接比，因为 RAT-SQL 的统计口径排除了条件值。

这个不可比性本身是一课。同一张表里并列两个数字，读者容易以为后者更强，实际是两把不同的尺子。引用时必须带上口径说明。

5.2 任务二：双模态证据选择

给定一个问题，判断该去查表还是去翻文本。这是论文里那个模态选择网络做的事，准确率 99.6%。

99.6% 这个数字需要谨慎解读。任务本身可能过于简单：模板句式固定，某些问法几乎必然对应某一模态，模型学到的是句式与模态的映射，而非真正的证据判断。若换成真实提问，这个准确率大概率会掉。

要做一个更有意义的版本，应当把评测集换成「两路都可能有答案」的样本，逼迫模型做实质判断，而不是靠句式线索。

5.3 任务三：答案等价性判定

给定两路答案，判断它们是否表达同一事实。这是一个尚未被这套数据正式定义、但显然存在的任务。

做这件工作需要外部知识：单位换算、缩写展开、剂型规格。数据里给了缩写对照表，没给换算表。构造换算表的过程本身就是一项有价值的工作。

评测可以用两路都有答案的那一万二千余条做基础，人工标注其中一部分的等价关系，再看模型能否复现。这个方向比单纯刷 SQL 准确率更接近临床实用。

5.4 任务四：冲突检测与消解

两路答案不一致时，谁对？这既是技术问题也是临床问题。

技术侧可以做的事：按模板类型分组统计冲突率，看哪些关系天然容易冲突。论文提到药名、剂型、途径三类模板的重合率高，剂量与理由类低。重合率低的那些正是冲突集中的地方。

临床侧需要判断的是：处方表记的是开立，小结记的是执行，两者本就可以不同。这种「不同」不是错误，而是信息。把冲突一律当噪声处理，会丢掉「开了但没吃」这一临床上很重要的情况。

5.5 任务五：模板生成方法学的迁移

这套数据的生成方法本身可以迁移：借一个已有标注任务的数据当槽位字典，为另一个任务自动造数据。

迁移时要检查三件事。一是槽位字典的覆盖面，若原标注只覆盖某类患者，新数据也会继承这个偏倚。二是模板与槽位的匹配度，槽位值填进模板后语义是否仍然成立。三是答案的可验证性，自动生成的答案必须有独立来源可以核对，否则错误无从发现。

这套数据在这三点上都做了处理：槽位来自有标注的挑战赛数据、模板设计时要求两路都可答、答案由 SQL 执行与文本抽取两路互证。这三点是方法可迁移的前提。

5.6 可复现的最小路径

按官方说明，复现需要五步：

1. 取得 PhysioNet 凭证，下载结构化包，解压到 structured_queries 目录
2. 取得 n2c2 批准，下载自由文本问答
3. 运行 join_structured_and_unstructured.py，按住院号拼接两批
4. 运行 generate_multimodal_dataset.py，按三条规则生成合并答案
5. 划分训练验证测试集，比例为 0.8/0.1/0.1

第三步是最容易出错的地方。两个仓库的住院号字段名可能不同，拼接前必须先核对类型（整数还是字符串）与是否有前导零。这类问题在小规模试跑时不易发现，全量跑完才报错。

5.7 基线模型的配置

论文给了完整的训练配置，复现时可直接照抄。

TREQS：批大小 16，学习率 5e-3，梯度裁剪 2.0，词表上限 50,000，训练 4 轮，学习率调度步长 2、衰减 0.8，最低词频 5。

RAT-SQL：批大小 20，词向量用 GloVe，训练至多 40,000 步，优化器 Adam，硬件为 RTX 2080 Ti。

BERT 与 ClinicalBERT：批大小 12，学习率 3e-5，训练 2 轮，文档步长 128，最大长度 384，硬件为 Quadro RTX 6000。

模态选择网络：批大小 64，学习率 1e-7，训练 16 轮。

这些超参数字面上可抄，但硬件差异会导致实际可复现性打折。论文没有报随机种子，也没有报多次运行的方差，这意味着单次结果的波动范围未知。做对比实验时，这个缺失比超参更重要。

在没有方差信息的情况下要判断两个模型的差异是否真实，只有一条路：自己多重跑，估出波动范围。按这套数据的规模（训练集约五万六千条，测试集约七千条），一个中等规模模型的准确率跑三次的标准差通常在零点几个百分点量级。也就是说，两组成绩差不到一个百分点时，在单次实验里基本无法区分。

这个判断对本文前面引用的两个数字有直接影响。TREQS 带恢复机制相对不带恢复机制，逻辑形式准确率从 63.84% 提到 64.8%，差 0.96 个百分点。按上述量级，这个提升处在可辨识的边缘，论文也只用「性能有所改善」来描述，没有做显著性检验。反过来，RAT-SQL 的 87.23% 与 TREQS 的 64.8% 相差二十余个百分点，远超噪声范围，这个差距是真实的（尽管两个数字的口径不同，不宜直接相减）。

还有一个容易被忽略的复现细节：三个模型用了三种不同的硬件。TREQS 与 RAT-SQL 分别在不同型号的显卡上跑，BERT 系列又在第三种上跑。不同硬件的浮点行为差异会带来微小但不可忽略的结果漂移，尤其是序列到序列模型的束搜索。论文没有说明是否固定了确定性模式，这意味着即使完全按配置重跑，也可能复现不出原数字的最后一位。

实践中的处理办法是把复现目标从「数字完全一致」下调为「量级与排序一致」。前者在深度学习基准上几乎不可能，后者才是可验证的。

5.8 DAIMS 24 项检查

按数据文档与元数据标准逐项对照，结果如下。

维度	项	判定
文档	数据字典	是（九个模板的 SQL 结构、字段含义在论文附录列明）
文档	采集协议	是（五步生成流程逐步说明）
文档	设备规格	不适用（非采集设备产生）
文档	标注规范	是（模板设计约束与三条合并规则明确）
文档	版本历史	部分（只有一个版本，无更新记录可谈）
文档	许可说明	是
文档	引用格式	是
文档	局限披露	是（两项，简明）
质量	缺失披露	部分（承认存在空答案，未给比例）
质量	信号质量说明	不适用（无信号数据）
质量	一致性检验	是（两路答案互为交叉验证）
质量	金标准对照	部分（答案来自检索，非人工金标准）
质量	异常值处理	否（未讨论）
质量	隐私处理	是（继承 MIMIC-III 去标识）
可得性	开放程度	否（凭证式）
可得性	下载方式	是（两个仓库分别说明）
可得性	文件校验	否（未提校验和）
可得性	数据体量	否（未给文件体积）
可得性	格式说明	是（CSV，含三列定义）
可得性	工具支持	是（GitHub 公开生成与合并脚本）
伦理	伦理批准	是（作者声明无伦理问题，因数据已去标识）
伦理	知情同意	是（沿用 MIMIC-III 的知情同意豁免）
伦理	试验注册	不适用（非临床试验）
伦理	去标识化说明	部分（说明继承 MIMIC-III，未逐项复核）

24 项中「是」12 项、「部分」4 项、「否」4 项、不适用 4 项。

判定为「否」的四项集中在可得性与质量：没有校验和、没有体积、没有异常值处理说明。这四项都不影响数据的可用性，但都影响复现的严谨度——尤其是校验和，在两仓库拆分、脚本与数据可能错配的情况下，一个哈希值能省掉大量排查。

5.9 评测该怎么报

三类任务三套指标，不能混。

结构化一支：逻辑形式准确率与执行准确率并列报，且注明条件值是否计入。RAT-SQL 的 87.23% 与 TREQS 的 64.8% 不可直接比较，原因就在这里。

自由文本一支：精确匹配与 F1 并列报。论文的数字是测试集精确匹配 61.363、F1 64.307（BERT），ClinicalBERT 为 61.679 与 65.220。两者差距很小，说明在这个任务上临床预训练带来的增益有限。

多模态一支：完全匹配率。论文用图呈现，未在正文给具体数字，这是引用时的一个空缺。

三个指标体系各自成立，但若有人把「多模态的完全匹配率」与「结构化的执行准确率」放在一张表里比大小，结论一定错。

§6 常见误读与引用陷阱

6.1 误读一：把七万条当七万个临床问题

七万条里有大量重复的句式骨架，差异只在槽位。真正不同的「问法」只有三十六个。

按信息量算，这套数据提供的是「三十六种问法 × 若干槽位组合」的笛卡尔积，不是七万个独立的临床疑问。评估模型的语言泛化能力时，这个区别是决定性的。

6.2 误读二：把 0.2% 当整体错误率

0.2% 是 500 条抽样里的错误率，且只针对多模态答案的合并结果，不涉及 SQL 是否正确、结构化答案是否准确。

这三个层面各有各的错误来源。合并错误 0.2% 完全可能与 SQL 错误 10% 并存——因为合并只在两路都返回结果时才有意义，SQL 写错导致返回空集的情况根本进不了合并环节。

6.3 误读三：把答案当临床事实

答案字段是检索结果。「剂量是 60 毫克」意味着处方表里有一行这么写，不意味着患者真的吃了 60 毫克。

这个区别在用药安全研究里是致命的。处方表记开立，执行记录在护理系统里，两者可以相差很大。论文自己也指出，结构化表代表「开立」而文本代表「执行叙述」，双模态的价值正在于能看出这个差。

6.4 误读四：把难度分档当模型难度

四档难度是按 SQL 结构判的，不是按语义难度判的。

一条极难的嵌套 SQL 在语义上可能很简单（「这位患者因某病用了什么药」），而一条简单的单表查询在语义上可能需要大量领域知识才能理解（「用了哪些药」里的「哪些」是否包含已停用的）。结构复杂度与认知复杂度不是一回事。

6.5 误读五：忽略两组难度数字的矛盾

PhysioNet 页面给的四档占比是：简单 1.30%、中等 32.06%、困难 33.32%、极难 33.32%。论文表 1 给的是：简单 1.1%、中等 39.2%、困难 9.8%、极难 49.9%。

四个数字里有三个不同，其中「困难」一档差了 23 个百分点。这不是四舍五入能解释的。可能的原因包括：页面数字是后期改的、统计口径从「模板数」改成「条数」、或者单纯是笔误。

正确做法是两组都注明来源，或说明「官方两处口径不一致」。直接引用其中一组而不提另一组，是把不确定性藏起来了。

6.6 引用时必须写清的五件事

版本：PhysioNet 侧 1.0.0，2022-04-12 发布。

批次：用的是四万余条的结构化部分，还是含合并答案的全量，数字差别很大。

数据来源：MIMIC-III v1.4 加 2018 n2c2 挑战赛的 505 份小结。

难度口径：引用占比数字时注明来自页面还是论文。

指标口径：逻辑形式准确率必须说明条件值是否计入，否则不同论文的数字不可比。

§7 在生态中的位置

7.1 与三代前作的坐标

横向看，它站在 emrQA 与 MIMICSQL 之间，试图同时覆盖两路。

纵向看，它是「模板生成」这一流派在医疗问答上的一个成熟样本。同一流派还有 emrKBQA（九十四万条，只用知识库）与 MIMICSQL（只用表）。这套数据的差异化在于双路并置。

与后来者相比，它的规模不算大。但规模不是它的卖点，结构才是。

7.2 与中文医疗问答资源的差异

中文这一侧有 CMeKG、MedDG、cMedQA 等资源，多数是医患对话或常识问答，与电子病历里的结构化查询不是同一类任务。

把 DrugEHRQA 的经验迁到中文，最大的障碍不是翻译，而是 schema。MIMIC-III 的表结构是公开的、稳定的，中文医院的表结构各家不同。没有统一 schema，Text-to-SQL 的评测就无从建立。

这一点决定了中文版本短期内难以出现同等规模的对应物。

7.3 长期可用性判断

PhysioNet 条目 2022 年发布后无更新，DOI 稳定。风险在三个方面。

一是双仓库依赖。自由文本部分在 n2c2，若那边长期不放行或条款变化，数据集就永久残缺。

二是 MIMIC-III 的退役节奏。MIMIC-IV 已成主流，新研究多用后者。这套数据锁在 MIMIC-III 上，随着原库使用率下降，维护动力也会下降。

三是派生数据的凭证继承。PhysioNet 对派生数据集的处理方式与原库一致，但若原库条款修订，派生数据是否同步修订，规则不明。

7.4 适合谁用

使用者	适合做的事	不适合做的事
Text-to-SQL 研究者	医疗 schema 上的领域适配、嵌套查询评测	通用 SQL 能力评估
多模态问答研究者	证据选择、冲突检测	联合推理（数据未提供该任务）
临床 NLP 方法学者	模板生成方法的复用与改进	真实提问分布的研究
药物流行病学者	只作为方法参照	直接得出用药安全结论

§8 总结

这套数据的价值不在七万这个数字，而在它把「同一问题的两种证据」做成了可计算的对象。

三件事决定了它的用法。第一，问题来自模板，句式三十六个骨架，语言多样性极低，不能用来评估真实提问的理解能力。第二，答案来自检索，代表「记录里写了什么」而非「患者实际如何」，做临床结论前必须再跨一步。第三，双路并置是核心特色，但两路的语义层级不同（毫克对片数），等价判断需要外部知识。

使用时守住三条：按批次说明引用的是四万条还是七万条；难度占比注明来自页面还是论文（两者矛盾）；指标分三套报，不要把不同口径的数字放进同一张表比大小。

它的历史位置在于提出了一个正确的问题——真实的信息检索需要同时面对表与文本——但在方法上只走到了「选一路来答」，尚未走到「联合两路来推」。这个空档，是后来者可以接手的地方。

§9 术语与口径速查

术语	全称	本文口径
Text-to-SQL	—	把自然语言问题翻译成可执行 SQL 的任务
逻辑形式准确率	Logical Form Accuracy	生成的 SQL 与标准 SQL 的字符串匹配比例
执行准确率	Execution Accuracy	生成的 SQL 执行结果与标准答案一致的比例
精确匹配	Exact Match	预测答案与标准答案完全一致的比例
衍生关系	derived relation	答案在表中无直接字段、需推理才能得到的关系
非衍生关系	non-derived relation	答案在表中有直接字段的关系
多模态答案	multimodal answer	按三条规则从两路答案中选出的最终答案
改写	paraphrase	同一模板的不同表述，每模板三个
槽位填充	slot filling	把药名、住院号等具体值代入模板占位符
模态选择网络	modality selection network	判断该查表还是查文本的二分类模型
TREQS	TRanslate-Edit Model for Question-to-SQL	序列到序列的 Text-to-SQL 模型
RAT-SQL	Relation-Aware Schema Encoding and Linking for Text-to-SQL	关系感知的 Text-to-SQL 模型
n2c2	National NLP Clinical Challenges	哈佛主办的临床自然语言处理挑战赛系列
MIMIC-III	Medical Information Mart for Intensive Care III	贝斯以色列女执事医疗中心的重症数据库

§10 事实清单与附录

10.1 核心事实

项	值
全量问答对	70,381 条
结构化三元组	41,417 条
两路均有答案	12,738 条（18.1%）
两路答案有重合	11%
两路答案不同且有重叠	7.1%
其中衍生关系类	15%
问题模板数	9
改写版本数	每模板 3 个（共 4 版）
涉及 MIMIC-III 表	3（PRESCRIPTIONS、DIAGNOSES_ICD、D_ICD_DIAGNOSES）
出院小结标注数	505 份
人工核验样本	500 条，错误率 0.2%
数据划分	0.8 / 0.1 / 0.1
发布机构	佛罗里达大学、德州大学休斯顿健康科学中心
发布日期	2022-04-12
DOI（v1.0.0）	10.13026/a849-cd06
DOI（latest）	10.13026/chym-n302
配套论文	arXiv:2205.01290，2022-05-03
访问等级	Credentialed
许可	PhysioNet Credentialed Health Data License 1.5.0

10.2 难度占比的两组口径

难度档	PhysioNet 页面	论文表 1
简单	1.30%	1.1%
中等	32.06%	39.2%
困难	33.32%	9.8%
极难	33.32%	49.9%

两组的简单档接近，极难档差 16.6 个百分点，困难档差 23.5 个百分点。引用时必须注明来源，或直接说明官方两处不一致。

10.3 基线成绩

模型	任务	指标	数值
TREQS（无恢复）	结构化	逻辑形式准确率	0.6384
TREQS（无恢复）	结构化	执行准确率	0.6384
TREQS（带恢复）	结构化	逻辑形式准确率	0.648
TREQS（带恢复）	结构化	执行准确率	0.649
RAT-SQL	结构化	逻辑形式准确率	0.8723
BERT	自由文本（测试集）	精确匹配	61.363
BERT	自由文本（测试集）	F1	64.307
ClinicalBERT	自由文本（测试集）	精确匹配	61.679
ClinicalBERT	自由文本（测试集）	F1	65.220
模态选择网络	模态判断	准确率	99.6%

RAT-SQL 的 0.8723 与 TREQS 的数字口径不同：前者在统计时排除 SQL 的条件值，后者不排除。两者不可直接比较。

10.4 附录 A：一条完整样本的拆解

以论文附录里的阿司匹林剂量问题为例，逐层看这条问答的构成。

问题层：问某住院号患者的阿司匹林剂量。槽位是住院号与药名，句式属于第五个模板。

SQL 层：从处方表取剂量值与剂量单位两列，条件是住院号与该药名等值匹配。

结构化答案层：返回两个毫克值。说明同一次住院里该药被开立过两次，规格不同。

文本答案层：返回「ONE (1)」。出处是出院小结里的用药行，原文写着三百二十五毫克片剂、每日一次、一次一片。

合并层：两路无交集（毫克与片数不可直接比），问题属于非衍生关系，按规则取结构化那一路。

这条样本暴露了三处需要判断的地方。第一，结构化答案是列表而非单值，评测时怎么处理多值。第二，两路答案表达单位不同，是否等价需要规格换算。第三，合并规则在有规格可推的情况下仍取结构化，是否合理。

这三处都值得在复现时单独做敏感性分析，而论文没有展开。

10.5 附录 B：六个可立即验证的疑问

1. 505 份小结对应多少个去重后的住院号与患者数？
2. 空答案样本在全部七万条里占多大比例？
3. 两路都有答案的那一批里，冲突样本（无交集）实际多少条，与论文隐含的 7.1% 口径是否一致？
4. n2c2 侧的问答数据当前是否已放行？
5. 多值答案在精确匹配里如何计分？
6. 九个模板各自的错误率分别是多少？

这六个问题官方材料均未明确回答，前两个与最后一个对结论的解释力影响最大。

10.6 附录 C：证据链

本文数字分两处来源。PhysioNet 条目页 v1.0.0 提供：四万一千余条结构化三元组、七万余条全量、两个 DOI、发布日期、许可与访问等级、九个模板与对应文件、难度的页面口径、示例问答三元组、n2c2 与 PhysioNet 分开存放的原因、使用说明的脚本顺序。

论文 arXiv:2205.01290 提供：全量精确条数、两路均有答案比例、重合与不重合比例、九个模板的结构与难度、五种模型的训练配置与成绩、抽样核验流程与 0.2% 错误率、难度的论文口径、局限陈述。

两处冲突之处（难度占比）已在正文与附录表格中并列呈现，未择一采信。凡本文提及而两处均未给出的数字（去重患者数、空答案比例、各模板错误率），均标注为待核实，未作推断性填充。

编辑说明

核验时点：2026 年 10 月 19 日，依据 PhysioNet 条目页 v1.0.0 与配套论文 arXiv:2205.01290v1 全文。

核验方式：条目页逐段读，论文 PDF 全文下载后逐节核对，重点比对数字在两处是否一致。发现难度占比这一处明显矛盾，四档中三档不同，并列呈现并注明来源，未做取舍。示例样本、SQL 模板、训练超参数均从论文附录原样引出。

口径处理：七万与四万两个数字按批次分别表述，不用单一数字概括全量。逻辑形式准确率一律注明条件值是否计入，避免不同论文数字被误比。人工核验的 0.2% 明确限定为「多模态答案合并结果的抽样错误率」，不外推为整体质量。

未覆盖内容：因两个仓库均为受限访问，未能下载数据核对空答案比例、去重患者数、各模板错误率。n2c2 侧的问答数据当前放行状态未能确认。多值答案在精确匹配中的计分方式论文未说明，本文标注为待核实。

---

相关数据集导航

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

• bedside-bench — 共享标签：电子健康记录 / 医学问答 / 医疗NLP / 药物安全
• emrqa — 共享标签：电子健康记录 / 医学问答 / 医疗NLP
• mimic-iii — 共享标签：电子健康记录 / 医疗NLP
• medicationqa — 共享标签：医学问答 / 医疗NLP / 药物安全
• mimiciii-legacy — 共享标签：电子健康记录 / 医疗NLP
• nosocomial-risk-mimic — 共享标签：电子健康记录 / 医疗NLP
• phenotype-annotations-mimic — 共享标签：电子健康记录 / 医疗NLP
• paediatric-intensive-care — 共享标签：电子健康记录 / 医疗NLP
• stroke-scale-mimic-iii — 共享标签：电子健康记录 / 医疗NLP
• synthetic-mimic-iii-health-gym — 共享标签：电子健康记录 / 医疗NLP

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