💻 computer science

PhenoAgent: agentic LLM framework for phenotyping electronic health records via structured query decomposition and self-correction

PhenoAgent 是一个保护隐私的智能体化大语言模型（LLM）框架，它利用结构化查询分解、自我修正和多模型共识技术，从自由文本电子健康记录中准确提取临床表型，其性能显著优于传统基准模型，并在日本医院数据集上达到了医生水平的表现。

原作者： Yuki Kashiwada, Rieko Sakurai, Yuta Yokokawa, Kenichiro Ando, Chinatsu Gocho, Chiaki Murata, Kosuke Tohda, Maki Tanioka, Shinya Sonobe, Tatsuya Harada, Jun Takayama

发布于 2026-06-28

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Yuki Kashiwada, Rieko Sakurai, Yuta Yokokawa, Kenichiro Ando, Chinatsu Gocho, Chiaki Murata, Kosuke Tohda, Maki Tanioka, Shinya Sonobe, Tatsuya Harada, Jun Takayama

原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，医院就像一座巨大的图书馆，每一位患者的故事都记录在一本独特的、凌乱的日记本中（即电子健康档案/EHR）。这些故事中的大部分都是以自由流动的段落形式书写的，而不是整齐的清单。如果医生想要寻找具有某种特定复杂情况的患者——比如“一次需要使用特定生命维持设备的心脏病发作”——他们不能仅仅搜索“心脏病”和“设备”这两个词。他们必须阅读成千上万本凌乱的日记，才能找到那两个事件同时发生且被描述在一起的病例，而这些内容往往隐藏在长句子的中间，或者有不同的表达方式。

PhenoAgent 是一款全新的、智能的工具，旨在充当一位超高效、注重隐私的图书管理员，能够阅读这些凌乱的日记，并在不出医院大楼的情况下精准地找到正确的患者。

以下是它的工作原理，分为简单的步骤：

1. “食谱拆解”（结构化查询分解）

想象一下，你要求一位厨师做一份“香辣牛肉豆腐炒菜”。与其只是大喊订单，PhenoAgent 首先会将该订单拆解为一份严格的购物清单：

必须包含：牛肉
必须包含：豆腐
必须包含：辣酱
绝不能有：鸡肉

在论文中，这被称为结构化查询分解（structured query decomposition）。系统会将一个复杂的医学问题转化为一份清晰、结构化的清单（JSON schema），甚至在开始阅读患者记录之前就完成这一步。这防止了计算机被混乱的语言所迷惑。

2. “自我修正循环”（自我修正）

有时，即使是聪明的计算机也会产生混乱，或者以错误的格式输出答案（例如，把段落写成了清单）。PhenoAgent 内置了一个逻辑上的“拼写检查器”。

它会要求三位不同的 AI“专家”来阅读患者日记并填写清单。
如果某位专家犯了错或以错误的格式书写了答案，系统会说：“等等，这看起来不对。再试一次。”
该专家会再次尝试（最多两次），直到答案完全符合清单的要求。这就是自我修正循环（self-correction loop）。

3. “全票通过的陪审团”（一致性集成投票）

这是最重要的安全规则。PhenoAgent 不仅仅询问一个 AI；它会询问三个不同的 AI 模型（GPT-OSS-20B、DeepSeek-32B 和 Llama-3.1-Swallow-70B）。

你可以将这三个 AI 想象成一个陪审团。
要判定一名患者符合标准，所有三位陪审员都必须投出“赞成”票。
如果哪怕只有一位陪审员投了“反对”或表示“我不确定”，该患者就不会被选中。
这使得系统变得非常谨慎。它可能会错过一些患者（较低的敏感度），但极不可能选错不属于该类别的人（高精确度）。在处理医疗数据时，宁缺毋滥比出错更好。

为什么它很特别？

目前的多数 AI 工具都运行在“云端”（即大型科技公司拥有的远程服务器上）。由于隐私法律，医院通常无法将患者数据发送到那里。

“本地化”优势： PhenoAgent 的设计初衷是在医院内部的一台单机上运行。它使用“开放权重（open-weight）”模型（类似于免费的开源软件），因此医院可以将所有数据保留在自己的围墙之内。数据绝不会离开建筑。
“非英语”优势： 它专门针对日本医院记录进行了测试，这类记录因混合了不同的书写系统和缩略语而对计算机来说极具挑战性。

结果：效果如何？

研究人员在来自两家不同日本医院的真实患者记录上测试了 PhenoAgent。

金标准： 他们将 AI 的工作结果与两名人类医生进行了对比。只有当两名医生都认为患者符合标准时，该患者才会被计为“匹配”。
得分： PhenoAgent 的表现几乎与两名医生的共识水平相当。它的“宏平均 F1 分数（macro-F1）”约为 71.6，非常接近人类共识得分 71.4。
碾压传统方法： 它以巨大的优势击败了旧方法（如简单的关键词搜索或标准的数据库搜索）——准确率提升了 24 到 43 个百分点。

缺陷（局限性）

论文指出，由于 PhenoAgent 使用了“全票通过的陪审团”规则，它非常严格。

如果患者的情况在记录中描述得比较模糊或间接，AI 可能会因为三位陪审员无法达成一致而判定为“否”。
这是一种权衡：系统优先考虑准确性（确保不选错人）而非找全所有可能的匹配项。这对于需要极其干净的患者列表的临床研究来说是非常理想的，但它可能会错过一些罕见病例。

总结

PhenoAgent 是一款隐私安全、本地运行的 AI 图书管理员。它能将复杂的医学问题拆解为清单，自我检查工作，并要求三位不同的 AI 专家达成一致后才选择患者。它证明了自己可以在凌乱的日本医院记录中，几乎像人类医生一样精准地找到正确的患者，且无需将敏感数据发送到互联网。

技术摘要：PhenoAgent

问题陈述

临床表型信息主要嵌入在非结构化的自由文本电子健康记录（EHR）中，这为用于队列选择和临床试验招募的结构化查询制造了显著障碍。虽然计算表型学对于二次 EHR 利用（如研究、质量改进）至关重要，但现有方法面临以下局限性：

标准查询和关键词匹配难以处理同义词、否定表达以及复杂的上下文表达。
基于规则和基于字典的方法需要大量的手动策展，且缺乏对复合表型（例如“使用 ECMO 治疗的心力衰竭”）的灵活性支持。
机器学习方法通常依赖于特定任务的微调和标注数据集，限制了其在常规临床部署中的应用。
**生成式大语言模型（LLMs）**展现了前景，但在临床环境中面临实际约束，特别是患者隐私问题（限制了使用云端 API）以及在医院防火墙内进行本地化、隐私保护部署的需求。
非英语语境，特别是日语临床文本，由于存在多种书写系统、机构特定的缩略语以及非分词短语，带来了独特的挑战，且与英语相比，可用的标注资源较少。

方法论：PhenoAgent 框架

作者提出了 PhenoAgent，这是一个可本地部署的三阶段智能体（agentic）LLM 框架，旨在从自由文本形式的日语 EHR 中检索复合临床表型，且无需依赖云服务或特定任务的标注。

1. 结构化查询分解

PhenoAgent 并非直接针对记录处理自然语言查询，而是首先将临床查询 $Q$ 分解为结构化的 JSON 模式 $S_k$ 。该模式列举了回答查询所需的组成医学概念，并为每个概念分配一个布尔字段。这一步骤约束了下游的提取任务并减少了歧义，使得系统能够在无需针对每个查询进行微调的情况下，处理诊断、治疗和合并症的复杂组合。

2. 自我修正语义评估

该框架使用开源权重 LLM 根据模式 $S_k$ 对每个临床记录 $C$ 进行评估。

流程： 模型生成一个包含二进制值和自由文本理由（rationales）的 JSON 对象，对应模式中的每个字段。
验证： 输出结果需通过要求的 JSON 模式验证。如果验证失败（例如 JSON 格式错误），系统会触发自我修正循环，通过带有格式提醒的提示再次调用同一模型。最多允许两次重试（总计三次尝试）。
回退机制： 如果在重试后仍无法获得有效的输出，未解决的字段将被设为负值。这种受 Reflexion 框架启发的机制解决了绝大多数格式失败问题。

3. 一致性集成投票

为了确保稳定性并减少模型特有的幻觉，PhenoAgent 采用了由三种不同的开源权重 LLM 组成的集成系统：GPT-OSS-20B、DeepSeek-32B 和 Llama-3.1-Swallow-70B。

决策规则： 只有当所有三个组成模型一致认为模式中的每个要求字段均为正值（positive）时，病例才被分类为阳性。
原理： 这种保守的投票规则优先考虑精确度而非敏感度，过滤掉不稳定的预测，并确保仅接受高置信度的检索结果。

实现细节

部署： 整个流水线在单台工作站（配备 128GB 统一内存的 Apple M4 Max）上运行，通过 MLX 框架使用 8-bit 量化模型。不进行任何外部 API 调用。
数据集： 在两个独立的日本急诊科数据集上进行了评估：
- TUH-DEM： 来自东北大学医院（2022–2023）的 842 例入院记录。
- OUH-DEM： 来自冈山大学医院（2023–2024）的 196 例入院记录。
参考标签： 真值通过两名医师的一致性建立。只有当两名独立的执业急诊医师均判定记录符合查询时，该记录才被标记为阳性。

关键结果

性能指标

PhenoAgent 与三种信息检索基准（关键词搜索、带有 ICD-10 扩展的语义搜索、BM25）以及六个单 LLM 基准进行了对比测试。

宏 F1 分数（Macro F1 Scores）：
- TUH-DEM (内部)： PhenoAgent 实现了 71.6 的宏 F1 分数（95% CI 66.5–75.7）。这与医师间一致性的 F1 分数 71.4 相匹配，并超过了表现最好的单 LLM 基准（GPT-OSS-20B 为 67.3）以及信息检索基准（语义搜索为 47.9）达 24–34 个百分点。
- OUH-DEM (外部)： PhenoAgent 保持了 71.1 的宏 F1 分数（95% CI 68.6–73.8），展示了在不同文档习惯的机构间的泛化能力。它比信息检索基准高出 35–43 个百分点。
一致性 (Cohen's $\kappa$ )：
- PhenoAgent 的 $\kappa$ 值在 TUH-DEM 中为 0.69，在 OUH-DEM 中为 0.68，显著高于关键词搜索（ $\approx$ 0.38–0.44）和单 LLM 基准（范围在 0.31 到 0.61 之间）。
精确度-敏感度权衡：
- PhenoAgent 保持了与关键词搜索相当的高精确度（TUH-DEM 为 70.5%，OUH-DEM 为 78.8%），但实现了大幅提升的敏感度（在 TUH-DEM 中为 76.5%，而关键词搜索仅为 34.0%）。
- 一致性投票策略产生了一种保守的预测特征，优先考虑高置信度检索。虽然单 LLM 在某些外部验证案例中实现了更高的敏感度，但 PhenoAgent 的精确度依然保持稳健。

具体观察

罕见表型： 该框架在罕见表型（患病率 <5%）上表现良好，但在临床模糊性较高的状况（如脓毒症/败血症）下表现有所波动，因为这类状况的证据往往是隐性的或通过临床轨迹推断出来的，而非显性术语。
自我修正： 自我修正循环解决了 84–99% 的 JSON 格式失败，使 TUH-DEM 数据集的宏 F1 分数提升了 1.3 个百分点。
模型选择： 通过详尽搜索选出的通用模型集成，其表现与专门的医学模型（如 MedLLM-72B）相当，这表明指令遵循和结构化输出生成对于此任务至关重要。

意义与主张

作者声称，PhenoAgent 证明了智能体 LLM 工作流可以支持在非英语临床环境下，从自由文本 EHR 中进行灵活且隐私保护的表型检索。

强调的核心贡献包括：

可本地部署性： 该框架完全利用开源权重模型在医院管理的内部环境中运行，解决了关于患者隐私、数据治理和网络限制的关键障碍。
无需微调的灵活性： 通过结构化查询分解，系统可以在无需针对每个查询进行微调或进行大规模本体工程的情况下，处理复合表型（诊断 + 治疗/合并症）。
性能媲美专家： 该系统的表现接近于人类医师之间的评分一致性水平，表明它可以作为临床研究队列选择的可靠工具。
在非英语语境下的鲁棒性： 对日语 EHR 的成功应用验证了该方法在标注数据集和临床语言资源有限的场景下的适用性。

论文总结道，虽然一致性投票规则创建了一个以精确度优先的系统，适用于临床研究队列选择（其中假阳性会增加人工审核负担），但该框架具有模块化特征。它可以根据不同的精确度-敏感度平衡（例如通过多数投票）进行调整，并能随着更强大的本地模型出现而进行整合，从而成为连接通用 LLM 进展与可靠临床研究基础设施的实用桥梁。