当AI助手试图从乱糟糟的病历堆里找答案时，会发生什么？——德国埃森大学医学院的临床信息智能提取系统实战报告

这项研究由德国埃森大学医学院人工智能医学研究所（IKIM）、杜伊斯堡-埃森大学计算机学院、多特蒙德工业大学以及日本福岛医科大学等多个机构联合完成，于2026年6月发表于arXiv预印本平台，论文编号为arXiv:2606.19602。

每当一位患者在医院积累了数年的就诊记录，那些记录就像一座随机堆放的档案仓库。有的文件重复出现好几份，有的日期标注得乱七八糟，有的被埋在与当前病情毫不相关的文件堆里。当医生需要整理一个淋巴瘤患者多年来的治疗历史，以便将其纳入临床研究时，这项工作完全靠人工完成，而且信息经常被遗漏。德国埃森大学医学院的研究团队面对的正是这样一个现实难题，他们决定造一个能帮医生做这件事的AI系统——ACIE（Agentic Clinical Information Extraction，主动式临床信息提取系统）。

这个系统部署在埃森大学医学院，那里的医疗数据规模在欧洲数一数二：将近20亿条医疗资源、170万名患者的数据，统一存储在符合国际标准的FHIR（Fast Healthcare Interoperability Resources，医疗信息快速互操作资源）数据库中。研究团队不仅造出了这个系统，还在一个真实的淋巴瘤登记研究中对它进行了严格检验——74个提取字段、99名患者、7326次人工核查判断，最终系统的被接受率达到了96.5%，而且没有一条内容是"凭空捏造"的。

这篇文章将带你完整了解这项研究——从问题的根源到系统的设计，从数据的乱象到评估的结果，从成功的经验到失败的教训。

一、档案仓库里的寻宝游戏：AI面对的真实病历是什么样的

要理解这项研究为什么重要，先得了解真实医院的病历数据有多"混乱"。

研究团队从10000名随机患者的数据出发，对大约120万份经过去重处理的医疗文件做了一次系统性的质量体检。结果发现，这座"档案仓库"远比想象中要乱得多。

先说文件的数量和分布。一个普通患者平均有52份去重后的文件，但最多的患者拥有2542份，最顶端1%的患者至少有937份文件。与此同时，每位患者平均有406条结构化数据点（比如化验结果、用药记录等），而最复杂的患者有超过11.9万条。这就好比你去查一个人的快递记录，有人就买过几件东西，有人的记录却堆满了整栋楼——查找起来的难度天壤之别。

再说文件去重的情况。系统发现，每位患者平均有33.5%的原始文件是重复的，最严重的患者有54.6%的文件都是重复版本。这意味着，如果AI不先做去重，它读到的"信息"有一半以上可能是反复看同一份东西。

然后是一个更棘手的问题：时间戳不可靠。FHIR数据库里的每份文件都带有几个时间戳——报告完成时间、文件创建时间、记录更新时间等等。研究团队做了一个交叉验证：用OCR技术和大语言模型从文件内容本身提取实际的临床日期，再与数据库里的元数据时间戳对比。结果令人沮丧——只有58.8%的文件在"同一天"上对得上，有36.5%的文件差了超过一天。不管用哪个元数据字段作为参考，准确率都稳定在59%左右，没有一个字段表现得更好。换句话说，没有任何一个元数据时间戳能够可靠地告诉你这份文件对应的是什么时候发生的临床事件。

与此同时，FHIR系统里有一个"就诊记录"（Encounter）的概念，理论上可以把患者的文件按照就诊事件分类整理。但实际情况是，有13.7%的就诊记录根本没有挂任何文件，而且文件在就诊记录中的分布极度不均匀——对于就诊次数少的患者，单次就诊可能包含全部文件的100%；对于就诊次数超过20次的复杂患者，最忙的那次就诊平均也只包含14.7%的文件，但在最极端的情况下，仍有一次就诊包含了53.5%的文件。更严重的是，56.5%的文件所携带的时间戳，完全落在它所属就诊记录的时间范围之外。

文件的元数据本身也极度稀疏。作者字段只有1.9%的文件有填写，子类型字段只有41.87%，结构化结论只有0.45%。更关键的是，整个数据库里没有任何一份文件带有"内容摘要"——没有一个能让AI快速判断"这份文件和我要找的内容有没有关系"的预览信息。超过1000种文件分类被使用，很多只是措辞不同，本质上指的是同一类文件。

此外，OCR（光学字符识别，把扫描的纸质文件转成可读文字的技术）拒绝处理的文件比例中位数是10.3%，最糟糕的患者有52%的文件因质量太差无法被OCR处理。

这一系列发现让研究团队意识到：对于AI来说，这不是一座整齐的图书馆，而是一个没有索引、没有标签、日期乱写、重复堆积的档案室。要在里面找到正确答案，光靠"按标签筛选"是行不通的。

二、传统方法为什么失败了：从"按图索骥"到"独立侦查"

了解了这座"档案室"有多乱，就能理解研究团队为什么放弃了常规思路。

最直觉的做法，是用一种叫做"检索增强生成"（RAG，Retrieval-Augmented Generation）的技术——先根据关键词或语义相似度找出相关文档片段，再让AI基于这些片段生成答案。这种技术在很多场景下运行得很好，但前提是：文档有可靠的元数据，可以用来过滤和排序；文档之间相互独立，不需要跨文档推理；时间信息准确，可以用来处理"最新值是什么"这类问题。

研究团队最初确实尝试了这条路，他们设计了基于就诊范围的检索过滤、日期范围过滤、文件类别过滤等各种静态筛选机制。但是，正如前一节描述的那样，这些过滤器所依赖的元数据要么不存在，要么不准确，要么无法可靠地定位到正确的文件。在穷尽了各种静态过滤组合之后，团队得出结论：要可靠地找到正确信息，AI必须能够根据文件的内容本身来判断哪些文件值得阅读，而不是依赖外部标签。

于是他们转向了一种"主动式"的架构——让AI系统像一个侦探一样，自主决定查哪些文件、怎么查、查到什么程度再收手。这就是ACIE系统的核心设计理念。

这个"侦探式"检索还面临一个具体的技术难题：文件被切成小片段（chunk）后，片段长短差异极大。有些片段很短，内容寥寥；有些片段很长，信息丰富。而现有的语义相似度算法有一个已知的偏好——它们倾向于把短片段排在前面，哪怕短片段里的实质信息远少于长片段。这就好比图书馆的推荐系统总是把书名推给你，而不是真正有内容的章节。

研究团队为此专门设计了一个"长度惩罚检索评分"公式：在原有的语义相似度分数基础上，给过短的片段打折扣。具体公式是：最终分数 = 语义相似度 × 长度惩罚系数，其中长度惩罚系数对于字符数低于40个字符的极短片段会大幅压低分数，随着片段变长，惩罚逐渐消失，直到完全不惩罚。这个设计让检索系统不再偏爱短碎片，同时也不完全排除它们。惩罚系数中的参数（阈值40字符，以及混合权重）是在一个开发子集上固定好的，之后在所有任务中保持不变。

三、ACIE系统长什么样：一个像侦探一样工作的AI助手

ACIE系统的设计理念可以用一个比喻来理解：它不是一个在图书馆里被动等待提问的查号台，而是一个拿着任务清单、主动翻档案的侦探助手。

整个系统的工作流程分成几个层次。

患者上下文（Patient Context）是侦探拿到的"案件全貌"。系统通过医院的FHIR服务器拉取某位患者的所有可用数据，包括各类文书（出院小结、放射报告、化验报告、转诊信、手术记录等）以及结构化的FHIR数据点（化验结果、用药记录、诊断记录、观察记录等）。非机器可读的文件会先经过OCR处理，质量太差的会被剔除。每份文件会被切成两个粒度的片段：较粗的"检索块"保留了更多上下文，供语义检索用；较细的"引用块"是每份文件的最小原子单位，供最终答案引用溯源用。

提取模式（Extraction Schema）是侦探拿到的"任务单"。临床医生通过系统提供的配置界面，定义他们想提取哪些信息、每条信息是什么类型（分类型、数值型、布尔型、日期型、自由文本、表格型）。整个配置过程不需要任何开发人员介入，医生自己就能完成。重要的是，同一个ACIE系统可以服务于完全不同的临床场景——术前准备、回顾性研究数据采集、临床文书生成——只需更换"任务单"即可，代码不需要任何修改。

提取代理（Extraction Agent）是侦探本人。系统使用一个叫做ReAct框架的工具调用代理——这是一种让AI能够交替进行"思考"和"行动"的架构。这位AI侦探有四种工具可以使用：一是在整个患者记录中按语义相似度搜索，找出和当前问题最相关的文件片段；二是列出所有文件，并为每份文件生成一个与查询相关的即时摘要（做法是把这份文件中评分最高的引用块按照文件原始顺序拼接，直到累计超过200词，这样得到的摘要既保留了时间顺序，又聚焦于相关内容）；三是完整阅读某一份特定文件；四是直接查询结构化数据。

侦探会不断迭代——搜索、阅读、再搜索、再阅读——直到它认为自己已经收集了足够的证据。然后它返回一个"有根据的答案"：不仅给出提取的值，还明确标注每个值的来源，指向具体的原始文件片段。

这最后一步，"引用溯源"，是整个系统的安全保障机制。临床医生在看到AI给出的每个提取结果时，都能同时看到对应的原始文件段落。他们可以对照原文核实答案是否正确，然后决定"接受"或"拒绝"。只有经过医生核实的值才会进入正式的临床文书。这种设计把AI的角色从"自动执行者"变成了"草稿起草者"，医生始终保持最终决定权。

在技术部署层面，ACIE完全运行在医院的内部网络中，部署在Kubernetes容器平台上，患者数据从不离开医院网络。系统使用的大语言模型是Qwen 3.6 35B-A3B（一个混合专家架构模型），OCR模型使用PaddleOCR-VL 1.5。评估期间，语言模型运行在4块H100 GPU上，OCR模型运行在1块H100 GPU上。

还有一个细节值得一提：研究团队在部署过程中发现，当患者元数据以JSON格式传入系统时，某些特定患者会稳定地触发格式错误的工具调用。这些失败是确定性的，而且与特定患者绑定，说明某些患者的异质性临床元数据产生的JSON结构干扰了工具调用机制。把输入格式从JSON改成Markdown之后，所有此类失败彻底消失。这个发现提示我们，数据序列化格式（把数据组织成文字的方式）对AI系统的实际表现有不容忽视的影响。

四、在真实淋巴瘤研究中的考试成绩：7326次判断告诉我们什么

光设计一个好系统是不够的，还得在真实场景中检验它。研究团队把ACIE拿去参与了一项独立进行的回顾性淋巴瘤登记研究。

这项研究本身由两名核医学医生和一名血液学医生设计，他们的电子病例报告表（eCRF）早于ACIE系统存在，完全是按照临床需要设计的，并非为了配合AI的能力。一名拥有四年以上专科培训经验的核医学专科医生负责配置ACIE的提取模式，在一部分患者上进行调试，整个过程不需要任何工程技术人员参与。

提取字段总共74个，覆盖了整个淋巴瘤病程的各个维度：有45个分类型字段（比如WHO分类和亚型、组织学与免疫组化定性指标、细胞遗传学与FISH检测、二代测序基因突变状态、总体生存事件）；9个数值型字段（诊断时体重、身高、Ki-67增殖指数、各类IHC表达百分比等）；8个布尔型字段（有无B症状、有无进展事件、有无骨髓侵犯等）；6个日期型字段（诊断日期、最近活检日期、转化日期、进展或最后随访日期等）；3个自由文本字段；3个表格型字段（治疗时间线、PET检查记录、微小残留病检测记录）。

系统为99名患者的所有74个字段都做了提取，共产生7326个待核查的值。每个值和对应的引用原文片段都被呈现给负责核查的核医学医生，医生对照临床系统（也就是日常工作中实际使用的系统）进行核实，然后给出"接受"或"拒绝"的判断，拒绝时需要注明具体原因。

总体结果是7073个接受，253个拒绝，被接受率96.5%。

从两个角度来看这个数字更有意思。在系统确实给出了一个值的4440个字段中，有96.4%被接受，也就是说临床医生认可的精确率是96.4%。在系统选择什么都不返回的2886个字段中，有96.8%确实是"正确的空白"——那个字段本来就没有值。这意味着系统既不会无中生有，也不会大量遗漏。患者层面的分布也相当稳定：99名患者的平均被接受率96.5%，中位数97.3%，范围82.4%到100%，其中78名患者的接受率达到或超过95%，7名患者零拒绝。

然而，深入到不同类型的字段，情况就分化了。分类型、数值型、布尔型、自由文本这四种类型的被接受率都在96%到98.6%之间，表现相当一致。但日期型字段的被接受率只有84.3%，表格型字段更低，只有79.8%（在非空表格中只有71.2%）。

日期型字段的问题是双向的。当系统返回了一个日期值时，核查医生经常认为系统选错了临床事件——比如有多个日期候选，系统选了一个，但医生认为应该是另一个。而当系统什么都没返回时，医生发现那个值其实存在的比例是整个系统最高的（空答案只有69.8%被认可，而整体平均是96.8%）。换句话说，日期型字段是唯一一种"不回答也经常是错的"类型。

表格型字段的问题则集中在"组装"上。这类字段要求系统从分散在整个病历中的信息里，整理出一张有时间顺序的多行表格（比如每一个治疗疗程的名称、开始时间、周期数）。即便证据在原文中是明确的，系统也经常搞错——漏掉某些行、多出某些行、或者日期填错。

从错误方向来看，253个拒绝中有161个是"系统给出了一个值，但这个值需要修正"，有92个是"系统什么都没给，但值其实存在"（绝大多数是日期字段）。最关键的安全指标：没有任何一个被拒绝的值是"幻觉"——没有任何值是在没有任何引用原文支持的情况下编造出来的。只有一个字段出现了"应该为空却给了值"的情况（false positive只有1例）。所以系统最主要的残余风险是"值不够准"，而不是"值是捏造的"。

错误高度集中。74个字段中，有10个字段贡献了253个拒绝中的182个。排在最前面的是"死亡或最后随访日期"（44个拒绝）和"治疗时间线"（40个拒绝），它们正好代表了日期型和表格型这两类弱项的典型案例。这两个字段都要求对整个病历进行最大程度的时序推理——要在数年的记录中找出正确的事件节点，或者把分散各处的治疗记录整合成一张完整的时间线。

研究团队还记录了9个"表单配置问题"——这些拒绝不是因为系统提取错了，而是因为eCRF的选项设置不符合临床实际（比如下拉菜单里的选项和临床真实情况对不上）。去掉这9个表单问题，提取本身的被接受率是96.7%。

值得一提的是，参与研究的医生们反映，完成每位患者的核查大约比纯手工操作快了三倍。

五、部署中学到的两条硬教训：数据质量决定架构设计

研究团队把这项工作总结为两条核心教训，这两条教训相互关联，构成了整个研究最有价值的洞见。

第一条教训是：临床数据的实际质量，远远低于AI系统所需要的水平。这不是埃森大学医院独有的问题。研究团队引用了多个独立来源的证据：在一个大型初级保健数据库中，自由文本病历里只有13%的临床概念在结构化编码字段中有对应记录；美国临床病历中普遍存在大量重复文本；一家德国地区医院的数据系统中存在长达30年的错误行政录入。研究团队认为，这种数据质量问题很可能源于医疗信息基础设施历史上是为计费优化的，而非为临床信息的一致性和可查询性优化的。任何部署在真实医院数据上的系统，都必须在架构设计层面对这种现实做出补偿。

第二条教训是：数据现实直接塑造了架构决策，而不是反过来。研究团队记录了三个具体的架构决策，每一个都是被某个具体的数据质量问题逼出来的。

首先是"放弃静态过滤，转向主动检索"。研究团队最初部署了一个依靠元数据过滤的检索-生成管道，发现它在各种过滤条件下都失败了，因为每个过滤条件都依赖于某个不可靠的元数据字段。在穷尽静态过滤方案之后，他们得出结论：可靠的检索需要一个能根据内容本身推理"哪些文件值得读"的代理，而不是一个依靠外部标签过滤的管道。这就是为什么系统需要主动代理架构。

其次是"需要查询相关的文档摘要"。即使有了主动代理，代理也不可能对每份文件都完整阅读一遍——在拥有数百份文件的患者记录中，这样做太慢了。解决方案是为每份文件生成"与当前查询相关的即时摘要"，让代理先看摘要，再决定是否有必要深入阅读全文。这个设计同时解决了另一个问题：文件被切成长短极度不均的片段后，短片段在检索中被优先推出，这就需要前面描述的长度惩罚评分来修正这种偏差。

第三是"把JSON格式改成Markdown格式"。这个改动看起来微不足道，但背后揭示了一个更深层的问题：患者元数据的异质性，会在特定情况下产生破坏AI工具调用机制的JSON结构。这不是偶发性故障，而是确定性的、与特定患者绑定的。切换到Markdown格式彻底消除了这类问题。这与学术界已有的发现一致——数据序列化格式会影响语言模型在临床任务上的表现。

归根结底，ACIE这套系统回答的不仅是"AI能不能从病历里提取信息"这个问题，而是"当你真正把AI部署在真实医院的真实数据上，你会遭遇什么，你得怎么应对"。研究团队坦率地记录了每一次失败的尝试，每一个数据质量发现，以及每一个被迫做出的架构调整。这种从失败中逆向推导出设计原则的记录方式，是这篇论文最具参考价值的部分。

当然，研究本身也有局限性需要诚实面对。这只是一个单中心、单病种、单语言的回顾性研究，仅有99名患者，每个字段只有一位专家核查，没有测量评审者间一致性。回顾性场景比实时临床场景宽松，因为在实时场景中错误可能直接影响治疗决策。整体被接受率也部分受益于39.4%的字段"正确答案就是空白"这一情况——在这种情况下，96.4%的值精确率和最弱类型84.3%、79.8%的表现之间的差距才更值得关注。关于幻觉的判断依赖于有引用来源的评审，而不是独立的逐段落核实。研究也没有与非主动架构或商业产品做对比实验，所以无法单独量化"主动代理设计"本身的贡献。

说到底，这项研究最重要的贡献，是把"AI在实验室里表现得多好"和"AI在真实医院数据上需要什么"这两件事放在了一起讨论，而不是割裂开来。临床信息提取的可靠性，依赖两个条件：一是能够基于内容推理的架构，二是每个输出都有原文支撑、由人类核实的验证机制。两者缺一不可，就像侦探的破案报告，既要有推理过程，也要有证据链。感兴趣的读者可以通过arXiv:2606.19602查阅完整论文。

Q&A

Q1：ACIE系统提取的信息准确率有多高？

A：在针对99名淋巴瘤患者、74个提取字段、7326次人工核查的评估中，ACIE的总体被接受率为96.5%。分类型、数值型、布尔型字段的接受率均在96%至98.6%之间表现较好，而日期型字段接受率为84.3%，表格型字段为79.8%，是两个相对薄弱的类型。整个评估中没有出现任何"幻觉"内容，即没有任何值是在没有原文支撑的情况下捏造出来的。

Q2：为什么ACIE不用普通的关键词或标签过滤来查找病历文件？

A：因为真实医院的FHIR数据库中，文件的元数据极度稀疏且不可靠。研究团队发现，只有1.9%的文件有作者字段，时间戳与实际临床日期的同日符合率只有58.8%，就诊记录与文件的关联也存在大量错位。依赖这些元数据做过滤会导致大量关键文件被错误排除，因此系统必须基于文件内容本身来判断哪些文件值得阅读，而不是靠外部标签。

Q3：ACIE系统是否会把患者数据传送到医院外部的服务器？

A：不会。ACIE完全部署在医院内部网络的基础设施上，通过Kubernetes容器平台运行，所使用的语言模型和OCR模型均在医院本地的GPU服务器上运行。患者数据全程不会离开医院网络，这也是该系统符合医疗隐私和监管要求的关键设计原则之一。