MultiDx: A Multi-Source Knowledge Integration Framework towards Diagnostic Reasoning¶

会议: ACL 2026
arXiv: 2604.24186
代码: https://github.com/Applied-Machine-Learning-Lab/ACL2026-MultiDx
领域: 医学图像 / 医疗诊断推理
关键词: 多源知识整合, 鉴别诊断, 医疗推理, RAG, Agent

一句话总结¶

MultiDx 将网页检索、SOAP 结构化病例、相似病例库和细粒度推理片段检索合成一个两阶段诊断推理框架，先从多路证据生成候选疾病，再通过疾病匹配、投票和鉴别诊断重排，最终在 MedCaseReasoning 与 DiReCT 上同时提升诊断命中率和推理召回。

研究背景与动机¶

领域现状：医疗诊断推理不只是给出一个疾病名，而是要根据主诉、体征、检验、影像和病程变化形成可核查的临床推理链。近两年大模型已经被用于 MedQA、PubMedQA 和病例问答，也出现了 MedAgents、MDAgents、ConfAgents、OpenAI-DR 这类多 Agent 或检索增强框架。

现有痛点：单靠 LLM 内部知识时，模型容易在罕见病、最新诊疗知识或复杂多系统病例上知识不足；单靠静态知识库时，知识覆盖和更新速度又受限。更麻烦的是，很多方法只看最终答案是否正确，忽略诊断过程是否符合临床习惯，导致结果难以被医生验证。

核心矛盾：诊断推理需要两种能力同时成立：一方面要有足够全面且动态的医学知识，另一方面要能把分散证据组织成标准的鉴别诊断过程。现有方法通常只强调“找更多知识”或“让模型多思考”，但缺少一个把多源候选诊断转化为临床式差异分析的显式整合层。

本文目标：作者希望让模型先像医生一样列出可疑疾病，再围绕这些候选疾病比较支持证据和反证，输出带有推理轨迹的最终诊断。这个目标可以拆成三个子问题：如何把自由文本病例转成更稳定的临床结构，如何从外部知识中取回对当前病例真正有用的证据，如何把多路候选结果统一成一个可解释的鉴别诊断结论。

切入角度：论文观察到临床诊断天然是多视角的：同一个病例可以从病历结构、相似病例、相似推理步骤和最新医学网页资料中得到不同线索。单一路径可能偏，但多路径之间的共识和冲突反而是鉴别诊断的重要信号。

核心 idea：用“多源候选诊断生成 + 显式鉴别诊断整合”代替单次问答式诊断，让 LLM 先收集不同视角的疾病列表，再在统一候选空间里做同义疾病匹配、证据聚合和临床重排。

方法详解¶

MultiDx 是一个训练无关的两阶段框架，核心不在微调某个医疗模型，而在组织诊断推理流程。输入是一个病例描述 \(C\)，输出包括最终诊断 \(D\) 和推理路径 \(R\)。第一阶段从四个知识源各自产生候选疾病列表，第二阶段把这些候选疾病和证据整合成最终排名与解释。

整体框架¶

第一阶段称为 Multi-source Knowledge-guided Diagnosis Generation。模型围绕同一个病例并行调用四类信息源：网页搜索得到 \(H_{web}\)，SOAP 结构化病例得到 \(H_{SOAP}\)，相似病例检索得到 \(H_{case}\)，相似推理片段检索得到 \(H_{trace}\)。每一路都会输出一个带有证据说明的疑似疾病列表。

第二阶段称为 Evidence Integration and Differential Diagnosis。LLM 接收原病例和四路候选疾病列表，先把“myocardial infarction / heart attack”这类同义或近义疾病统一为标准名称，再统计每个疾病被哪些来源支持以及在各来源中的排序，最后比较高置信候选之间的临床证据，输出最终诊断列表和推理轨迹。

这个流程有一个很清楚的临床对应关系：第一阶段类似医生形成“疑似诊断清单”，第二阶段类似医生做“鉴别诊断”。因此，MultiDx 不是单纯把多个 Agent 的答案投票，而是把候选疾病背后的证据也纳入重排。

关键设计¶

四路多源候选诊断生成:
- 功能：从病例结构、相似病例、相似推理片段和实时网页四个角度生成候选疾病，降低单一知识源带来的盲区。
- 核心思路：SOAP 分支先用 LLM 将自由文本病例转为 Subjective、Objective、Assessment、Plan 四栏，其中 Assessment 和 Plan 在原始病例没有提供时显式标为空，再基于结构化病例生成 \(H_{SOAP}\)；病例库分支用 BM25 从 MedCaseReasoning 训练集检索 top-k 相似病例，拼入 prompt 生成 \(H_{case}\)；推理片段分支把历史推理链切成步骤，用 SciSpacy 抽取生物医学实体，并用 Jaccard 相似度 \(|E_C \cap E_{i,j}| / |E_C \cup E_{i,j}|\) 找到与当前病例实体最相关的推理片段，生成 \(H_{trace}\)；网页分支让 Agent 先规划查询、工具类型和检索步数，再迭代搜索、浏览、抽取内容并更新内部记忆，最后生成 \(H_{web}\)。
- 设计动机：诊断推理对知识覆盖特别敏感。SOAP 解决输入杂乱，相似病例提供少样本临床范式，推理片段提供细粒度证据对齐，网页搜索补充动态知识和罕见病信息；四者互补，比单一 RAG 或单一多 Agent 讨论更稳。
层次化病例库检索:
- 功能：让模型既能参考完整病例，又能参考和当前病例局部症状、检查结果最相关的推理步骤。
- 核心思路：作者把病例数据库表示为 \(\mathcal{G}=\{(C_i,R_i,D_i)\}_{i=1}^{N}\)。第一层检索以病例文本为单位，用 BM25 找相似病例；第二层检索以推理句为单位，把每条推理链拆成编号步骤，对每个步骤抽取医学实体，与输入病例实体做集合相似度匹配。两种检索结果分别进入不同 prompt，形成病例级候选和推理级候选。
- 设计动机：只检索完整病例时，模型容易被相似但非关键的病史细节误导；只检索短片段时，又可能丢掉完整临床上下文。层次化检索把“完整案例模式”和“局部证据逻辑”拆开建模，提升了可解释性和召回能力。
证据整合与鉴别诊断重排:
- 功能：把四路候选列表变成最终诊断，而不是机械选票数最高的疾病。
- 核心思路：LLM 被要求完成四步：疾病名匹配、按来源和排名聚合支持度、对高排名疾病进行差异分析、输出最终重排列表和简短理由。形式上，模型根据 \(C,H_{web},H_{SOAP},H_{case},H_{trace}\) 生成 \((R,D)\)，其中 \(R\) 是临床式解释，\(D\) 是最终疾病列表。
- 设计动机：简单投票无法处理医学同义词、证据冲突和“某疾病出现次数少但证据更强”的情况。显式鉴别诊断让模型比较候选疾病对症状、检查和排除证据的拟合度，更接近真实临床决策。

损失函数 / 训练策略¶

MultiDx 本身不引入新的可训练参数，主要依赖 prompt、检索和工具调用流程。实验中作者使用 DeepSeek-R1 官方 API 作为主要 backbone，并在所有 Agentic baselines 中保持相同 backbone 以保证公平比较。层次化检索默认取 top 10 相似病例和 top 10 推理路径，医学实体抽取使用 SciSpacy 0.5.5。

训练集的作用主要是构建病例数据库，而不是微调 MultiDx。MedCaseReasoning 的 13,092 个训练病例被用作检索库；评估时因为计算资源限制，作者随机抽取 300 个 MedCaseReasoning 测试样本，并在 DiReCT 上随机抽取 50 个样本。网页搜索模块为了降低数据泄漏风险，屏蔽了 PubMed 和 Hugging Face 等可能直接暴露 benchmark 或相关资料的来源；DiReCT 病例已经是标准临床笔记格式，因此实验时省略 SOAP 结构化模块。

实验关键数据¶

主实验¶

论文在两个诊断推理数据集上评估：MedCaseReasoning 用 Reasoning Recall 衡量推理链覆盖，用 H@1/H@5/H@10 衡量正确诊断是否出现在前 k 个预测中；DiReCT 也使用同样指标。所有带 * 的 MultiDx 结果为三次随机运行平均，论文报告 t-test 下 \(p<0.05\)。

数据集	方法	Reasoning Recall	H@1 Acc.	H@5 Acc.	H@10 Acc.	关键结论
MedCaseReasoning	DeepSeek-R1	0.648	0.360	0.419	0.442	强 backbone，但候选召回不足
MedCaseReasoning	MedAgents	0.641	0.344	0.458	0.471	多专家讨论带来一定提升
MedCaseReasoning	OpenAI-DR	0.557	0.416	0.553	0.602	强 agentic baseline，准确率高但推理召回偏低
MedCaseReasoning	MultiDx	0.662	0.420	0.577	0.617	四项指标均最好，H@5/H@10 优势最明显
DiReCT	DeepSeek-R1	0.473	0.293	0.413	0.473	迁移到临床笔记后性能下降
DiReCT	Self-refinement	0.662	0.300	0.466	0.586	推理召回强，H@10 接近 MultiDx
DiReCT	OpenAI-DR	0.586	0.297	0.452	0.479	整体不如 Self-refinement
DiReCT	MultiDx	0.665	0.333	0.503	0.587	在小样本 DiReCT 上仍保持最佳或并列最佳

从主结果看，MultiDx 的主要收益不是只把 top-1 提高一点，而是显著扩大正确诊断进入候选列表的概率。在 MedCaseReasoning 上，相比 DeepSeek-R1，H@5 从 0.419 提到 0.577，H@10 从 0.442 提到 0.617；相比 OpenAI-DR，H@5/H@10 也分别提升 0.024/0.015。这说明多源证据整合特别适合“先列全，再鉴别”的诊断任务。

消融实验¶

消融实验把 DeepSeek-R1 作为基础模型，分别只加入一种知识增强，再与完整 MultiDx 比较。

配置	H@1	H@5	H@10	Reasoning Recall	说明
DeepSeek-R1	0.360	0.419	0.442	0.648	无外部知识增强
w/ SOAP	0.379	0.467	0.502	0.638	仅结构化病例，准确率提升但推理召回略降
w/ web search	0.416	0.553	0.602	0.460	准确率最强的单模块，推理轨迹覆盖不足
w/ related case	0.393	0.489	0.523	0.634	相似病例对 seen disease 更有帮助
w/ related trace	0.386	0.520	0.576	0.573	推理片段比完整病例更利于候选召回
MultiDx	0.420	0.577	0.617	0.662	多源融合同时改善准确率和推理召回

最有意思的是 web search 单模块在 H@1/H@5/H@10 上已经很强，但 Reasoning Recall 从 0.648 降到 0.460，说明实时网页知识能帮助找到疾病名，却未必生成与专家标注一致的临床推理链。完整 MultiDx 能把网页的知识覆盖、病例库的临床范式和 SOAP 的结构化输入结合起来，所以最终 Recall 反而最高。

泛化、整合策略与成本分析¶

作者还做了三个补充实验：换 backbone、区分 seen/unseen 疾病、比较简单投票和鉴别诊断整合。

实验设置	对比项	H@1	H@5	H@10	Recall	观察
Qwen3-14B backbone	Qwen3-14B	0.284	0.295	0.295	0.638	基础模型候选召回很弱
Qwen3-14B backbone	MedAgents	0.362	0.377	0.384	0.572	多 Agent 提升有限
Qwen3-14B backbone	MultiDx	0.399	0.556	0.601	0.679	说明框架收益不依赖单一 backbone
Seen diseases	DeepSeek-R1	0.459	0.520	-	-	训练病例库内疾病较容易
Seen diseases	MultiDx	0.504	0.710	-	-	多源整合显著提高候选覆盖
Unseen diseases	DeepSeek-R1	0.300	0.366	-	-	罕见或未见疾病更难
Unseen diseases	MultiDx	0.338	0.448	-	-	网页知识和多源互补改善泛化
Stage 2 strategy	simple vote	0.403	0.552	0.604	-	只数票会漏掉证据强弱
Stage 2 strategy	differential diagnosis	0.420	0.577	0.617	-	显式鉴别诊断优于简单投票

计算成本方面，MultiDx 的端到端平均延迟约 8.46 分钟，总 token 约 20,000，与 Self-refinement 的 5.3 分钟/18,398 tokens 和 OpenAI-DR 的 8.0 分钟大致同量级。Stage 1 的四个分支可以并行执行，因此实际等待时间主要受最慢的 web search 和 related trace 影响。作者也指出，如果场景对延迟敏感，可以关闭 web search 或 related trace，把耗时降到约 2 分钟，但会牺牲一部分性能。

关键发现¶

多源融合比单模块更稳：web search 是准确率最强的单一增强源，但完整 MultiDx 才能同时拿到最高 H@k 和最高 Reasoning Recall。
鉴别诊断不是装饰模块：附录中 simple vote 的 H@1/H@5/H@10 为 0.403/0.552/0.604，而 differential diagnosis 为 0.420/0.577/0.617，说明 Stage 2 的临床比较确实比投票更有效。
病例检索存在噪声-覆盖权衡：case retrieval 的 k 从 2 增到 10 时 H@1 提高到 0.393，但 H@5/H@10 并非单调上升，说明更多相似病例会增加候选疾病覆盖，也可能引入不相关证据。
unseen disease 仍然受益：在未出现在病例库的疾病上，MultiDx 的 H@1/H@5 达到 0.338/0.448，高于 DeepSeek-R1 的 0.300/0.366，证明它不是只靠记忆训练库病例。
病例分析验证了整合逻辑：在 CNS 复杂病例中，四路模块把 PCNSL、转移性疾病、神经结节病、感染性脑膜炎等候选列在不同位置；MultiDx 最终将 primary CNS lymphoma 排到第一，并给出和专家推理相近的排除逻辑。

亮点与洞察¶

把诊断任务拆成“候选生成”和“鉴别诊断”非常自然：很多医疗 LLM 方法把输出疾病名当作终点，而 MultiDx 把候选疾病列表视作中间对象。这个设计让模型有机会比较多个看似合理的疾病，而不是在一次生成中仓促定案。
SOAP 的价值不是带来外部知识，而是降低输入噪声：它只是重排病例信息，却能提升 H@k，说明医疗推理中“信息组织形式”本身就是能力瓶颈。类似思想可以迁移到法律、金融风控等高度结构化推理任务。
推理片段检索比普通病例 RAG 更贴近诊断过程：疾病诊断常常由某个关键体征或检查结果触发，整篇相似病例未必相似。按推理步骤抽实体再检索，相当于从历史病例中取出可复用的局部临床逻辑。
Stage 2 提醒我们不要迷信投票：多源系统中，来源数量不是证据强度的充分条件。一个来源少但证据贴合度高的候选疾病，可能比三个泛泛相关的候选更可信。
这个框架很适合做可控降级：在高风险或复杂病例中开启所有模块，在低风险或高并发场景中只开 SOAP + related case，可以形成性能、成本和可解释性的可调节组合。

局限与展望¶

外部知识质量会直接影响诊断质量：作者也承认，如果网页搜索结果或检索病例含有噪声，MultiDx 的候选列表可能被污染。尤其在医疗场景中，网页信息的权威性、时效性和适用人群都需要更严格过滤。
两阶段设计仍然是解耦流程：第一阶段各模块独立生成候选，第二阶段再整合，这可能导致早期漏掉的关键疾病无法在后续恢复。未来可以探索联合规划，让 Stage 2 反向要求 Stage 1 针对冲突点补检索。
实验样本规模偏小：MedCaseReasoning 只随机评估 300 个测试样本，DiReCT 只有 50 个样本。虽然三次运行和统计检验提高了可信度，但真实部署前仍需要更大规模、多中心、跨科室的验证。
推理质量评估仍依赖现有标注：Reasoning Recall 能衡量是否覆盖专家推理步骤，却不完全等价于临床正确性。某些病例可能存在多条合理推理路径，单一 gold trace 会低估模型的替代解释。
安全性和责任边界尚未充分讨论：论文主要报告准确率、召回和成本，没有系统分析 hallucination、过度诊断、漏诊风险、人机协作界面和医生复核机制。这些是医疗 AI 走向真实场景时必须补上的部分。

评分¶

新颖性: ⭐⭐⭐⭐☆ 多源检索、SOAP 和鉴别诊断单独看并不陌生，但组合成贴合临床流程的两阶段诊断框架很扎实。
实验充分度: ⭐⭐⭐⭐☆ 主实验、消融、跨 backbone、seen/unseen、成本和病例分析都覆盖了，但测试样本规模和真实临床验证仍偏有限。
写作质量: ⭐⭐⭐⭐☆ 方法线索清楚，表格信息密度高，附录 prompt 和病例分析有助复现；不足是部分公式和变量在 arXiv HTML 中排版略混乱。
价值: ⭐⭐⭐⭐⭐ 对医疗 LLM 的实用启发很强：诊断系统需要多源证据、标准流程和可核查推理，而不是只追求最终答案命中。