简介面向医疗人工智能与心内科辅助诊断领域这份资源适合医工交叉项目开发者、算法工程师以及相关课题学生用于构建集成检索增强生成与多智能体协同的自动化诊断系统。项目围绕真实临床场景覆盖心电图、超声心动图、生化指标等数据的采集与匹配通过智能体分工完成风险评估、方案生成与疗效监控。压缩包共二十三个文件大小约十二点五八兆字节其中十篇PDF为心血管诊疗专家共识与学术文献十一个JSON为患者病历与输出样例另有说明文件和Readme文档便于快速理解目录结构与数据格式。已有六十七人浏览或学习。借助病例数据、医学文献语料和完整项目框架可复现系统核心流程学会搭建医学知识库、设计多智能体协作逻辑并进一步扩展到其他专科疾病的辅助诊断研究。1. 心内科疾病智能诊断的卡点知识库和推理过程是割裂的心内科疾病智能诊断这个赛道大多数翻车现场并不是出在“大模型不够聪明”而是出在知识库与推理过程互相脱节模型知道肌钙蛋白升高指向心肌损伤却说不清依据的是哪一版指南、哪一段既往病历更没法把“先看主诉→再查检查→最后鉴别诊断”的临床顺序稳定地走完。基于RAG与多智能体协同架构的心内科疾病智能诊断系统就是把这两条线捏在一起检索增强生成负责把权威指南、历史确诊病历和药物信息作为可溯源证据挂进生成链路多智能体协同负责把诊断流程拆成筛查、鉴别、检查建议、文书整理等不同职责的执行单元。这篇文章按我搭建同类系统的一线经验把架构选型、可复现骨架、RAG知识库落地和验证路径完整讲一遍适合正在做医疗AI系统、想从“单个模型聊天”走向“可追溯自动诊断”的团队参考。2. 为什么单RAG与单Agent撑不起心内科诊断架构选型的三个理由很多团队立项时第一反应是“先做个RAG知识库再接一个大模型”。这个思路在客服问答和文档问答上没问题但在心内科诊断这个场景单RAG和单Agent都扛不住。原因不在于模型能力而在于心内科的诊断逻辑本身就不是一次检索、一段生成能覆盖的。2.1 心内科诊断的数据特征多点证据与动态时序心内科疾病有一个鲜明的特点多数诊断不是靠某一条指标一行判定的而是“症状、心电图、心肌酶谱、影像与病史”四类证据拼出来的。比如急性冠脉综合征胸痛只是入场券还要看肌钙蛋白的动态变化、心电图ST段改变、既往是否有支架史房颤的诊断依赖心律不齐的持续时间和卒中风险评分心衰则要看BNP、超声心动图以及患者的容量负荷状态。这些证据之间有权重、有先后、有排除关系。我见过不少医疗AI项目第一步就把大量医学问答、公开文献、病例讨论一股脑塞给RAG知识库以为文档越多召回越准。实际跑起来却是检索top_k返回的片段可能来自五份不同年代的指南模型把这些互相矛盾的表述拼在一起产出一个看似合理、实际站不住的结论。这不是检索质量的问题而是“一次检索、直接生成”这个范式承载不了诊断任务中对证据结构和时序关系的要求。所以在RAG实战里心内科场景必须先做数据分级再做诊断流程编排最后才轮到调模型。知识库只负责“提供证据”证据如何被组织、被取舍、被串联成诊断假设靠的是多智能体协同架构。2.2 单一Agent的两种失败模式上下文漂移与黑匣子推理把主诉解析、鉴别诊断、检查建议、病历整理全部交给同一个Agent不是不能跑而是跑完没法复核。我在项目里见过两种典型的失败模式。第一种是上下文漂移。患者先主诉胸痛追问后补充气促和既往PCI术后史单一Agent在长时间会话里很容易把后来补充的信息当成独立的新主诉去处理甚至把三个月前的心电图结果误认为当前检查的发现。原因在于单个Agent的上下文窗口里历史信息和新信息的边界逐渐模糊模型分不清哪些字段是刚更新的、哪些已经失效。第二种是黑匣子推理。模型直接给出“考虑冠心病建议行冠脉造影”的结论但医生追问一句“依据是什么”系统拿不出证据链。这在医学场景里是致命的。临床决策系统最大的价值不是猜中答案而是把答案还原成一条可以被复核、被质疑、被打回的推理路径。单一Agent的线性生成很难做到这一点。所以多智能体协同架构的核心价值不是“每个Agent更聪明”而是“每个Agent只负责一段局部任务全局状态由路由统一管理”。一旦某个环节出错系统可以从审计日志里定位到底是谁、在哪个字段、依据什么证据做出了决策。没有这个分层就无法支撑医疗场景对可追溯性的硬性要求。2.3 Agentic RAG从“一次检索拼上下文”到“按需多次检索再仲裁”近两年Agentic RAG这个概念被反复提起放在这个系统里其实很好懂。经典RAG流程是用户问题→向量检索→拼进提示词→生成回答从头到尾只检索一次。而心内科诊断的问题往往不是一个清晰的自然语言问题而是一串有待澄清的临床表现。Agentic RAG会把“胸痛伴气促”拆成症状组分别去检索心电图表现、心衰指南、肌钙蛋白解读再按诊断任务组织成证据包并由专门的Agent判断证据包是否足够支撑下一步决策如果证据不足它会自动触发二次检索或要求补充检查。对比维度静态RAG经典做法Agentic RAG多智能体协同做法检索次数主诉整体检索一次按症状、检查、药物分别触发多轮检索证据组织直接拼进提示词按诊断任务组织成证据包由Agent判断够不够容错机制检索不到就硬答检索不到主动发起二次检索或请求更多信息输出形态一段生成文本结构化诊断假设 引用证据链这套架构对团队的要求也变高了。不是接一个LangChain就能交付而是要做query改写、证据包判定、补检触发、引用ID追踪。因此我一般建议团队在立项前先回答四个问题诊断流程能否被拆成明确的阶段状态每个阶段的输出是否是结构化字段而不是自由文本知识库里是否覆盖了本机构前六个月的脱敏确诊病历团队有没有能力维护一套证据引用ID体系这四个问题只要有一个答不上来先不要急着搭多智能体因为搭出来也验证不了。3. 从零搭起多智能体协同诊断骨架角色分工、消息路由与病例状态这一章直接落地。我会用一个简化但完整的最小骨架把多智能体协同的核心抽象讲清楚。生产环境里用LangGraph或AutoGen这类框架能省不少事但如果你不理解这里的状态流转用框架也只会被框架的抽象绕晕。3.1 四个Agent的角色划分与触发条件心内科诊断流程在实际项目中通常拆成四个Agent每个Agent负责一个可独立验证的决策阶段。这里要特别说明Agent不等于独立模型同一个模型配不同的system prompt和工具权限就可以承担多个Agent角色拆分的目的是让每一步决策都有明确的输入、输出和复核入口。Agent角色职责触发时机主要输出分诊Agent主诉解析与急诊风险初判会话开始结构化主诉词表、危急指标标记诊断Agent鉴别诊断与假设生成分诊完成后Top3诊断假设与每条假设的证据检查建议Agent医嘱与检查判读诊断假设出现后需补做的检查项及判读标准文书Agent病历结构化与引用标注全流程末尾带引用ID的现病史与初步诊断段这里的顺序不是随意的。分诊Agent的输出决定诊断Agent从哪些角度切入诊断Agent的假设决定检查建议Agent要补哪些证据最后文书Agent再把整个链路整理成可归档的病历文本。如果一个Agent发现问题应该允许流程回退到上一阶段而不是继续往下走。3.2 一个最小可跑的消息路由Agent基类与串行流水线下面这个代码是整条链路的最小可跑版本。它不依赖任何编排框架只有一个基类和一个流水线循环适合团队快速验证角色划分是否合理。# agent_base.py from dataclasses import dataclass, field from enum import Enum from typing import Any, Callable class AgentRole(Enum): TRIAGE 分诊 DIAGNOSTIC 诊断 EXAM 检查 DOC 文书 dataclass class CaseContext: case_id: str complaints: dict # 原始主诉分诊Agent写入后只读 vitals: dict field(default_factorydict) lab_results: dict field(default_factorydict) ecg_text: str hypotheses: list field(default_factorylist) audit_trail: list field(default_factorylist) # 审计日志只追加不可改 class DecisionAgent: def __init__(self, role: AgentRole, process_fn: Callable[[CaseContext], CaseContext]): self.role role self.process_fn process_fn def handle(self, ctx: CaseContext) - CaseContext: new_ctx self.process_fn(ctx) changed_fields [ f for f in new_ctx.__dict__ if getattr(ctx, f, None) ! getattr(new_ctx, f, None) ] new_ctx.audit_trail.append({ agent: self.role.value, changed: changed_fields, }) return new_ctx这段代码的核心是DecisionAgent的handle方法。它先调用process_fn执行业务逻辑再自动对比处理前后的CaseContext把变更字段追加到audit_trail。这样每个Agent做了什么、改了哪些字段都有一条可回溯的记录。相比直接让Agent在状态字典上随手赋值这个设计多了一道审计保障。# pipeline.py def triage_process(ctx): keywords [胸痛, 大汗, 濒死感] if any(k in ctx.complaints for k in keywords): ctx.vitals[risk_flag] ACS_alert return ctx pipeline [ DecisionAgent(AgentRole.TRIAGE, triage_process), DecisionAgent(AgentRole.DIAGNOSTIC, diagnostic_process), DecisionAgent(AgentRole.EXAM, exam_process), DecisionAgent(AgentRole.DOC, doc_process), ] ctx CaseContext(case_idC2024001, complaints{胸痛: 活动后加重}) for agent in pipeline: ctx agent.handle(ctx)流水线的参数说明pipeline列表的顺序就是诊断流程的顺序串行执行保证后一个Agent拿到的永远是前一个Agent已经结构化完成的输出。triage_process只是演示分诊如何把“胸痛、大汗、濒死感”这类词映射成风险标记。实际项目里diagnostic_process和exam_process都会调用RAG检索器并把检索结果的文档ID存入hypotheses结构里这里为了展示骨架用占位函数代替。生产中如果用LangGraph就是在StateGraph里把每个agent包成一个node用add_conditional_edges实现回退核心抽象和我上面写的最小版本是一样的——消息路由、病例状态、审计追踪三件套。3.3 病例临时态与字段权限防止Agent互相污染多智能体协同架构里大多数看似诡异的问题最后都指向同一个根因共享状态被某个Agent原地覆盖了。我在血泪经验里总结出一条铁律——任何Agent都不允许修改患者原始字段只能追加结构化的推理结果。CaseContext里的complaints是原始区只有分诊Agent在会话最开始写入之后的Agent只能读不能改。lab_results、ecg_text这些检查结果字段由外部检查服务写入诊断Agent不能因为自己的假设不符合结果就篡改数值。hypotheses是推理区只允许诊断Agent和检查建议Agent追加内容。完整的权限控制生产上可以用数据库行级锁或专门的状态服务实现但最小版本用断言就够了class CaseContext: def add_hypothesis(self, agent, hyp, evidence): assert agent in {AgentRole.DIAGNOSTIC, AgentRole.EXAM}, \ 只有诊断与检查Agent可以追加诊断假设 self.hypotheses.append({ hyp: hyp, evidence: evidence, agent: agent.value, })注意这里的证据字段必须存RAG返回的文档ID列表不能只存自然语言描述。文档ID是后面做证据回溯和评测的基础。每个诊断会话的CaseContext是一次性临时态会话结束后需要归档到持久化存储但不需要长期保留中间过程我一般会把audit_trail单独落一份JSON用于后续模拟评测和错误分析。4. 建一个服务心内科的RAG知识库数据选型、分块策略与检索参数多智能体骨架搭完后最耗时的是RAG知识库建设。医疗场景的RAG知识库和通用文档问答的用法差别很大核心原则是“少而精、可溯源、按诊疗逻辑组织”。这一章我把数据、分块、检索参数三块分别讲透。4.1 数据源选型指南、药物说明书、确诊病历与结构化指标我见过的失败案例八成是把RAG知识库当成“越大越好”的存储桶。实际上心内科诊断系统只要四类数据就够用多余的内容只会拉低检索精度数据源类型来源与质量要求在诊断链路中的作用权重建议临床指南中华医学会、ESC、AHA等权威指南的中文执行版鉴别诊断标准、治疗推荐依据高权重优先保证召回既往确诊病历本机构前6-12个月确诊病历脱敏处理匹配本机构人群分布与书写习惯高权重但需做时间切分药物说明书药品适应症、禁忌症、不良反应检查建议Agent的用药合理性判断中权重结构化检验指标表肌钙蛋白、BNP、D-二聚体等参考范围诊断Agent判读检验结果高权重单独存储不参与向量切块这里有个关键操作结构化检验指标表不要和指南文档混在一起做向量化。因为数值型参考范围是精确匹配场景比如“肌钙蛋白I0.04ng/mL提示心肌损伤”如果被切进一段长文本召回时可能因为相似度分数被其他句子稀释。我一般会把这类指标单独做成JSON或数据库表由检查建议Agent直接查询不走向量检索。4.2 医疗文本分块为什么“按段落硬切”会让诊断翻车临床指南和病历文本的结构高度依赖章节层级。一个典型的指南段落先讲适应症再讲检查方法然后给诊断标准最后是治疗建议。如果按300字固定长度硬切常常把“诊断标准”和“治疗建议”切到两个chunk里导致诊断Agent只检索到标准、没检索到治疗边界。我使用的分块策略是两层结构先用Markdown标题切出章节再对长章节按语义边界二次切分。from langchain_text_splitters import ( MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter, ) md_splitter MarkdownHeaderTextSplitter( headers_to_split_on[(#, 章节), (##, 小节)] ) rec_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap120, separators[\n\n, 。, , \n], ) chunks [] for section in md_splitter.split_text(guideline_md): if len(section.page_content) 800: chunks.extend(rec_splitter.split_text(section.page_content)) else: chunks.append(section)第一层按“章、节”标题切分保证临床逻辑单元不被拦腰截断第二层只对超过800字的长章节做二次切分分隔符优先用句号和分号避免在单位数值中间断开。chunk_overlap设为120的原因是让“症状描述”和“对应检查建议”之间保留重复上下文防止诊断Agent因为边界二字缺失漏掉关键证据。另外每个chunk必须带元数据。我常用的元数据字段是source、chapter、chunk_id、updated_at。后续做引用回溯时chunk_id就是审计日志里的证据ID没有这个ID链路的诊断结论无法被验证。4.3 检索参数设置top_k、阈值与混合检索心内科专业词汇缩写极多LBBB、ACS、BNP、PCI这些缩写向量模型并不总能和中文全称对齐。只靠向量检索一定会漏。所以我的RAG知识库检索配置始终是混合检索BM25关键词召回兜底向量召回负责语义泛化。retriever_config { top_k: 20, # 初召回放宽留给重排序筛选 score_threshold: 0.30, # 向量相似度阈值宁低勿高 rerank_top_n: 5, # 重排序后最终进入上下文的条数 hybrid_search: True, # BM25 向量召回混合 bm25_weight: 0.3, # BM25结果在混合排序中的权重 query_rewrite_rules: { lbbb: [左束支传导阻滞], acs: [急性冠脉综合征], mi: [心肌梗死], }, }这段配置里的每个参数都有讲究。top_k20是初召回数量医疗场景漏召回比多召回危险所以先放宽检索范围score_threshold设成0.30而不是更高的0.6也是同样的逻辑宁可多召回不相关片段也不能让真正关键的证据因为分数略低被过滤掉。rerank_top_n5表示最终进提示词的只有5个chunk这一步是精筛通常用交叉编码器重排序小团队如果资源有限可以先不做rerank只把top_k放宽到20让诊断Agent自己从20个片段里选证据。hybrid_searchTrue解决缩写问题BM25按字面匹配把“LBBB”这种缩写直接命中。query_rewrite_rules是缩写扩展表每次遇到检索失败就先查这张表而不是急着换嵌入模型。提示医疗RAG知识库的调参顺序一定是先看漏检再谈精度。你可以在检索服务里打印每个问题的命中chunk列表人工扫一遍就知道是阈值太高、分块太碎还是缩写没扩展。5. 联调与避坑心内科诊断系统最容易翻车的5个现场多智能体协同和RAG知识库单独跑都能work一旦联调各种“玄学级”问题就冒出来了。这一章写5个我踩过的具体坑全部按“现象→原因→解决”的顺序写。5.1 检索命中但回答里没有引用证据模型把知识库当“参考书”而不是“证据”现象知识库里明明有2023版心衰指南患者主诉“气促、下肢水肿”系统输出“考虑心衰”但整个回答里没有任何引用标注医生追问依据时系统答不上来。原因提示词里只写了“请参考检索内容”没有强制要求引用机制。LLM把检索结果当成背景知识而不是必须在回答中逐条表明出处的证据。这是RAG项目最典型的误配置。解决在文书Agent的生成指令里加硬约束每个诊断结论后面必须附引用ID格式固定为[docs:编号]如果关键证据未检索到直接输出“证据不足建议补充检查”禁止编造。提示词长这样诊断结论后必须附引用ID格式为[docs:N]。 若结论对应的关键证据未检索到直接输出“证据不足建议补充检查”禁止编造。显式的否定指令比“请准确回答”有效得多。加了这条约束后系统宁可答“证据不足”也不会给出无依无据的断言。5.2 多Agent跑到第三轮出现“记忆冲突”气促被当成新主诉支架史凭空消失现象分诊Agent在第一轮已经记录“既往PCI术后”到检查建议Agent输出时这段病史不见了患者补充的“气促”在诊断Agent那里被当成独立新主诉导致诊断方向跑偏。原因共享状态被某个Agent原地覆盖。常见写法是直接在CaseContext的dict上做update不同Agent的执行顺序导致后写入覆盖先写入又没有在审计日志里留下前后对比。解决按第3章的字段权限设计把状态分成原始区、推理区、审计区任何Agent不能直接覆盖原始字段。更重要的是加审计对比每次Agent执行完记录变更字段的前后值。这样即使发生覆盖也能重放trace定位是哪个Agent动的手。5.3 同一份病历两次诊断结论不一致温度与召回排序都在抖现象同一份心电图报告文本上午跑是“考虑房颤建议抗凝”下午跑是“窦性心律观察”医生直接把系统判了死刑。原因两个因素叠加。生成侧采样温度过高检索侧向量相似度分数接近的文档顺序抖动导致两次检索返回的chunk列表顺序不一样模型看到的上下文不同结论自然不同。解决诊断相关Agent的temperature固定到0.05到0.1top_p不低于0.85任何情况下不对诊断结论开启随机采样。检索侧对每个文档生成稳定的hash值排序时用“score为主、hash为副”做确定性仲裁。我在项目里的做法是检索结果先按分数排序分数相同按hash排序保证同一条知识库内容返回顺序永远一致。这个用例不需要创造性发挥答案应该可复现。5.4 知识库明明有“左束支传导阻滞”检索就是查不到现象用户输入“LBBB”知识库文档里写的是“左束支传导阻滞”RAG返回了完全不相关的chunk诊断Agent给不出关于LBBB的鉴别诊断。原因向量模型对医学缩写的语义映射很弱BM25又因为字符级不匹配而无法命中。这个问题在纯向量检索项目里几乎无解因为语义本身就模糊。解决建同义词缩写归一表在query改写阶段把缩写还原成中文全称和英文全称再进检索器。上面的retriever_config里已经写了query_rewrite_rules实际生产里这张表是迭代频率最高的每个被复核为错误的病例优先查是不是缩写和术语没有进表而不是去换embedding模型。换模型成本高且不可解释补表是五分钟的事。5.5 离线评测准确率高一上真实病历就崩现象用100份脱敏标注病历跑离线评测诊断准确率91%。拿医院最近两周的真实门诊病历做抽样测试准确率掉到六成左右。原因评测集和真实分布的偏差。标注病历往往是“已经确诊的典型病例”症状描述规范、检查结果齐全真实病历里有大量非典型症状、多病共存、信息缺失的情况。更隐蔽的问题是如果用随机切分方式划分训练和测试病历中同一患者多次就诊的记录会同时出现在两边造成数据泄漏。解决用时间切分代替随机切分。前6个月病历用于构建RAG知识库和调参后6个月病历只做评测保证知识库不存在“见过答案”的可能。评测指标除了诊断准确率还要加两个底线指标证据覆盖率每个诊断结论是否都有引用ID支撑和幻觉率无引用ID却输出的结论占比。我的项目经验是宁要85%的证据覆盖率也不要95%却没依据的准确率。6. 验证这套系统能不能进科室单病例回溯与批量模拟评测6.1 单病例回溯从结论反向检查证据链多智能体系统的可追溯性设计最终要落到验证手段上。我的习惯是每次改完知识库或提示词先抽三个历史病例做单病例回溯取一条pipeline输出从audit_trail里逆序检查每个诊断假设的引用ID然后做一个“遮挡重放”测试——把对应知识库原文完全遮住让诊断Agent只看剩余上下文重新推理一次。如果遮挡后推理结果明显漂移说明结论依赖了未被引用的隐藏上下文如果遮挡后结论依然稳定说明证据链是真实可信的。这个办法成本低、可解释是目前对幻觉最直接的检测手段之一。每轮回溯发现的断裂证据链我都会记入一个独立的问题清单按“知识库缺块、缩写未扩展、阈值过严”三个类别归因修复后再重放。6.2 批量模拟评测三项指标和一个小脚本单病例回溯解决的是“个案对不对”批量模拟评测解决的是“整体稳不稳”。我每周跑一次批量回溯固定用后6个月的时间切分病例集脚本逻辑很轻量def evaluate_trace(trace, gold_docs): total max(len(trace), 1) coverage sum( 1 for step in trace if step.get(citation_id) in gold_docs ) / total hallucination sum( 1 for step in trace if not step.get(citation_id) ) / total stability diagnosis_consistency(prev_result, cur_result) return { evidence_coverage: coverage, hallucination_rate: hallucination, diagnosis_stability: stability, }三个指标各有作用evidence_coverage低于0.85说明RAG召回或证据组织有问题先查分块和query改写hallucination_rate高于0.05说明提示词约束失效优先加硬拒答逻辑diagnosis_stability连续两次跑同一批病例不一致则检查采样参数和检索排序确定性。重点提醒一句指标崩了不要急着换模型。在这个架构里90%的问题都在知识库覆盖度和检索参数上换模型只会让问题更不可控。医疗诊断系统和我之前做过的所有RAG项目最大的不同是错误代价不对称。一个错误的诊断建议在普通问答场景里只是体验差在科室里就是真实的风险。我现在的习惯是每次发布前跑两轮批量回溯把证据链断裂的病例标记出来优先补知识库和同义词表而不是去调模型。坚持三个月后诊断稳定性上升明显系统输出也终于敢给医生复核了。希望帮到你。本文还有配套的精品资源点击获取 RAG+多智能体协同的心内科智能诊断系统落地实践
简介面向医疗人工智能与心内科辅助诊断领域这份资源适合医工交叉项目开发者、算法工程师以及相关课题学生用于构建集成检索增强生成与多智能体协同的自动化诊断系统。项目围绕真实临床场景覆盖心电图、超声心动图、生化指标等数据的采集与匹配通过智能体分工完成风险评估、方案生成与疗效监控。压缩包共二十三个文件大小约十二点五八兆字节其中十篇PDF为心血管诊疗专家共识与学术文献十一个JSON为患者病历与输出样例另有说明文件和Readme文档便于快速理解目录结构与数据格式。已有六十七人浏览或学习。借助病例数据、医学文献语料和完整项目框架可复现系统核心流程学会搭建医学知识库、设计多智能体协作逻辑并进一步扩展到其他专科疾病的辅助诊断研究。1. 心内科疾病智能诊断的卡点知识库和推理过程是割裂的心内科疾病智能诊断这个赛道大多数翻车现场并不是出在“大模型不够聪明”而是出在知识库与推理过程互相脱节模型知道肌钙蛋白升高指向心肌损伤却说不清依据的是哪一版指南、哪一段既往病历更没法把“先看主诉→再查检查→最后鉴别诊断”的临床顺序稳定地走完。基于RAG与多智能体协同架构的心内科疾病智能诊断系统就是把这两条线捏在一起检索增强生成负责把权威指南、历史确诊病历和药物信息作为可溯源证据挂进生成链路多智能体协同负责把诊断流程拆成筛查、鉴别、检查建议、文书整理等不同职责的执行单元。这篇文章按我搭建同类系统的一线经验把架构选型、可复现骨架、RAG知识库落地和验证路径完整讲一遍适合正在做医疗AI系统、想从“单个模型聊天”走向“可追溯自动诊断”的团队参考。2. 为什么单RAG与单Agent撑不起心内科诊断架构选型的三个理由很多团队立项时第一反应是“先做个RAG知识库再接一个大模型”。这个思路在客服问答和文档问答上没问题但在心内科诊断这个场景单RAG和单Agent都扛不住。原因不在于模型能力而在于心内科的诊断逻辑本身就不是一次检索、一段生成能覆盖的。2.1 心内科诊断的数据特征多点证据与动态时序心内科疾病有一个鲜明的特点多数诊断不是靠某一条指标一行判定的而是“症状、心电图、心肌酶谱、影像与病史”四类证据拼出来的。比如急性冠脉综合征胸痛只是入场券还要看肌钙蛋白的动态变化、心电图ST段改变、既往是否有支架史房颤的诊断依赖心律不齐的持续时间和卒中风险评分心衰则要看BNP、超声心动图以及患者的容量负荷状态。这些证据之间有权重、有先后、有排除关系。我见过不少医疗AI项目第一步就把大量医学问答、公开文献、病例讨论一股脑塞给RAG知识库以为文档越多召回越准。实际跑起来却是检索top_k返回的片段可能来自五份不同年代的指南模型把这些互相矛盾的表述拼在一起产出一个看似合理、实际站不住的结论。这不是检索质量的问题而是“一次检索、直接生成”这个范式承载不了诊断任务中对证据结构和时序关系的要求。所以在RAG实战里心内科场景必须先做数据分级再做诊断流程编排最后才轮到调模型。知识库只负责“提供证据”证据如何被组织、被取舍、被串联成诊断假设靠的是多智能体协同架构。2.2 单一Agent的两种失败模式上下文漂移与黑匣子推理把主诉解析、鉴别诊断、检查建议、病历整理全部交给同一个Agent不是不能跑而是跑完没法复核。我在项目里见过两种典型的失败模式。第一种是上下文漂移。患者先主诉胸痛追问后补充气促和既往PCI术后史单一Agent在长时间会话里很容易把后来补充的信息当成独立的新主诉去处理甚至把三个月前的心电图结果误认为当前检查的发现。原因在于单个Agent的上下文窗口里历史信息和新信息的边界逐渐模糊模型分不清哪些字段是刚更新的、哪些已经失效。第二种是黑匣子推理。模型直接给出“考虑冠心病建议行冠脉造影”的结论但医生追问一句“依据是什么”系统拿不出证据链。这在医学场景里是致命的。临床决策系统最大的价值不是猜中答案而是把答案还原成一条可以被复核、被质疑、被打回的推理路径。单一Agent的线性生成很难做到这一点。所以多智能体协同架构的核心价值不是“每个Agent更聪明”而是“每个Agent只负责一段局部任务全局状态由路由统一管理”。一旦某个环节出错系统可以从审计日志里定位到底是谁、在哪个字段、依据什么证据做出了决策。没有这个分层就无法支撑医疗场景对可追溯性的硬性要求。2.3 Agentic RAG从“一次检索拼上下文”到“按需多次检索再仲裁”近两年Agentic RAG这个概念被反复提起放在这个系统里其实很好懂。经典RAG流程是用户问题→向量检索→拼进提示词→生成回答从头到尾只检索一次。而心内科诊断的问题往往不是一个清晰的自然语言问题而是一串有待澄清的临床表现。Agentic RAG会把“胸痛伴气促”拆成症状组分别去检索心电图表现、心衰指南、肌钙蛋白解读再按诊断任务组织成证据包并由专门的Agent判断证据包是否足够支撑下一步决策如果证据不足它会自动触发二次检索或要求补充检查。对比维度静态RAG经典做法Agentic RAG多智能体协同做法检索次数主诉整体检索一次按症状、检查、药物分别触发多轮检索证据组织直接拼进提示词按诊断任务组织成证据包由Agent判断够不够容错机制检索不到就硬答检索不到主动发起二次检索或请求更多信息输出形态一段生成文本结构化诊断假设 引用证据链这套架构对团队的要求也变高了。不是接一个LangChain就能交付而是要做query改写、证据包判定、补检触发、引用ID追踪。因此我一般建议团队在立项前先回答四个问题诊断流程能否被拆成明确的阶段状态每个阶段的输出是否是结构化字段而不是自由文本知识库里是否覆盖了本机构前六个月的脱敏确诊病历团队有没有能力维护一套证据引用ID体系这四个问题只要有一个答不上来先不要急着搭多智能体因为搭出来也验证不了。3. 从零搭起多智能体协同诊断骨架角色分工、消息路由与病例状态这一章直接落地。我会用一个简化但完整的最小骨架把多智能体协同的核心抽象讲清楚。生产环境里用LangGraph或AutoGen这类框架能省不少事但如果你不理解这里的状态流转用框架也只会被框架的抽象绕晕。3.1 四个Agent的角色划分与触发条件心内科诊断流程在实际项目中通常拆成四个Agent每个Agent负责一个可独立验证的决策阶段。这里要特别说明Agent不等于独立模型同一个模型配不同的system prompt和工具权限就可以承担多个Agent角色拆分的目的是让每一步决策都有明确的输入、输出和复核入口。Agent角色职责触发时机主要输出分诊Agent主诉解析与急诊风险初判会话开始结构化主诉词表、危急指标标记诊断Agent鉴别诊断与假设生成分诊完成后Top3诊断假设与每条假设的证据检查建议Agent医嘱与检查判读诊断假设出现后需补做的检查项及判读标准文书Agent病历结构化与引用标注全流程末尾带引用ID的现病史与初步诊断段这里的顺序不是随意的。分诊Agent的输出决定诊断Agent从哪些角度切入诊断Agent的假设决定检查建议Agent要补哪些证据最后文书Agent再把整个链路整理成可归档的病历文本。如果一个Agent发现问题应该允许流程回退到上一阶段而不是继续往下走。3.2 一个最小可跑的消息路由Agent基类与串行流水线下面这个代码是整条链路的最小可跑版本。它不依赖任何编排框架只有一个基类和一个流水线循环适合团队快速验证角色划分是否合理。# agent_base.py from dataclasses import dataclass, field from enum import Enum from typing import Any, Callable class AgentRole(Enum): TRIAGE 分诊 DIAGNOSTIC 诊断 EXAM 检查 DOC 文书 dataclass class CaseContext: case_id: str complaints: dict # 原始主诉分诊Agent写入后只读 vitals: dict field(default_factorydict) lab_results: dict field(default_factorydict) ecg_text: str hypotheses: list field(default_factorylist) audit_trail: list field(default_factorylist) # 审计日志只追加不可改 class DecisionAgent: def __init__(self, role: AgentRole, process_fn: Callable[[CaseContext], CaseContext]): self.role role self.process_fn process_fn def handle(self, ctx: CaseContext) - CaseContext: new_ctx self.process_fn(ctx) changed_fields [ f for f in new_ctx.__dict__ if getattr(ctx, f, None) ! getattr(new_ctx, f, None) ] new_ctx.audit_trail.append({ agent: self.role.value, changed: changed_fields, }) return new_ctx这段代码的核心是DecisionAgent的handle方法。它先调用process_fn执行业务逻辑再自动对比处理前后的CaseContext把变更字段追加到audit_trail。这样每个Agent做了什么、改了哪些字段都有一条可回溯的记录。相比直接让Agent在状态字典上随手赋值这个设计多了一道审计保障。# pipeline.py def triage_process(ctx): keywords [胸痛, 大汗, 濒死感] if any(k in ctx.complaints for k in keywords): ctx.vitals[risk_flag] ACS_alert return ctx pipeline [ DecisionAgent(AgentRole.TRIAGE, triage_process), DecisionAgent(AgentRole.DIAGNOSTIC, diagnostic_process), DecisionAgent(AgentRole.EXAM, exam_process), DecisionAgent(AgentRole.DOC, doc_process), ] ctx CaseContext(case_idC2024001, complaints{胸痛: 活动后加重}) for agent in pipeline: ctx agent.handle(ctx)流水线的参数说明pipeline列表的顺序就是诊断流程的顺序串行执行保证后一个Agent拿到的永远是前一个Agent已经结构化完成的输出。triage_process只是演示分诊如何把“胸痛、大汗、濒死感”这类词映射成风险标记。实际项目里diagnostic_process和exam_process都会调用RAG检索器并把检索结果的文档ID存入hypotheses结构里这里为了展示骨架用占位函数代替。生产中如果用LangGraph就是在StateGraph里把每个agent包成一个node用add_conditional_edges实现回退核心抽象和我上面写的最小版本是一样的——消息路由、病例状态、审计追踪三件套。3.3 病例临时态与字段权限防止Agent互相污染多智能体协同架构里大多数看似诡异的问题最后都指向同一个根因共享状态被某个Agent原地覆盖了。我在血泪经验里总结出一条铁律——任何Agent都不允许修改患者原始字段只能追加结构化的推理结果。CaseContext里的complaints是原始区只有分诊Agent在会话最开始写入之后的Agent只能读不能改。lab_results、ecg_text这些检查结果字段由外部检查服务写入诊断Agent不能因为自己的假设不符合结果就篡改数值。hypotheses是推理区只允许诊断Agent和检查建议Agent追加内容。完整的权限控制生产上可以用数据库行级锁或专门的状态服务实现但最小版本用断言就够了class CaseContext: def add_hypothesis(self, agent, hyp, evidence): assert agent in {AgentRole.DIAGNOSTIC, AgentRole.EXAM}, \ 只有诊断与检查Agent可以追加诊断假设 self.hypotheses.append({ hyp: hyp, evidence: evidence, agent: agent.value, })注意这里的证据字段必须存RAG返回的文档ID列表不能只存自然语言描述。文档ID是后面做证据回溯和评测的基础。每个诊断会话的CaseContext是一次性临时态会话结束后需要归档到持久化存储但不需要长期保留中间过程我一般会把audit_trail单独落一份JSON用于后续模拟评测和错误分析。4. 建一个服务心内科的RAG知识库数据选型、分块策略与检索参数多智能体骨架搭完后最耗时的是RAG知识库建设。医疗场景的RAG知识库和通用文档问答的用法差别很大核心原则是“少而精、可溯源、按诊疗逻辑组织”。这一章我把数据、分块、检索参数三块分别讲透。4.1 数据源选型指南、药物说明书、确诊病历与结构化指标我见过的失败案例八成是把RAG知识库当成“越大越好”的存储桶。实际上心内科诊断系统只要四类数据就够用多余的内容只会拉低检索精度数据源类型来源与质量要求在诊断链路中的作用权重建议临床指南中华医学会、ESC、AHA等权威指南的中文执行版鉴别诊断标准、治疗推荐依据高权重优先保证召回既往确诊病历本机构前6-12个月确诊病历脱敏处理匹配本机构人群分布与书写习惯高权重但需做时间切分药物说明书药品适应症、禁忌症、不良反应检查建议Agent的用药合理性判断中权重结构化检验指标表肌钙蛋白、BNP、D-二聚体等参考范围诊断Agent判读检验结果高权重单独存储不参与向量切块这里有个关键操作结构化检验指标表不要和指南文档混在一起做向量化。因为数值型参考范围是精确匹配场景比如“肌钙蛋白I0.04ng/mL提示心肌损伤”如果被切进一段长文本召回时可能因为相似度分数被其他句子稀释。我一般会把这类指标单独做成JSON或数据库表由检查建议Agent直接查询不走向量检索。4.2 医疗文本分块为什么“按段落硬切”会让诊断翻车临床指南和病历文本的结构高度依赖章节层级。一个典型的指南段落先讲适应症再讲检查方法然后给诊断标准最后是治疗建议。如果按300字固定长度硬切常常把“诊断标准”和“治疗建议”切到两个chunk里导致诊断Agent只检索到标准、没检索到治疗边界。我使用的分块策略是两层结构先用Markdown标题切出章节再对长章节按语义边界二次切分。from langchain_text_splitters import ( MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter, ) md_splitter MarkdownHeaderTextSplitter( headers_to_split_on[(#, 章节), (##, 小节)] ) rec_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap120, separators[\n\n, 。, , \n], ) chunks [] for section in md_splitter.split_text(guideline_md): if len(section.page_content) 800: chunks.extend(rec_splitter.split_text(section.page_content)) else: chunks.append(section)第一层按“章、节”标题切分保证临床逻辑单元不被拦腰截断第二层只对超过800字的长章节做二次切分分隔符优先用句号和分号避免在单位数值中间断开。chunk_overlap设为120的原因是让“症状描述”和“对应检查建议”之间保留重复上下文防止诊断Agent因为边界二字缺失漏掉关键证据。另外每个chunk必须带元数据。我常用的元数据字段是source、chapter、chunk_id、updated_at。后续做引用回溯时chunk_id就是审计日志里的证据ID没有这个ID链路的诊断结论无法被验证。4.3 检索参数设置top_k、阈值与混合检索心内科专业词汇缩写极多LBBB、ACS、BNP、PCI这些缩写向量模型并不总能和中文全称对齐。只靠向量检索一定会漏。所以我的RAG知识库检索配置始终是混合检索BM25关键词召回兜底向量召回负责语义泛化。retriever_config { top_k: 20, # 初召回放宽留给重排序筛选 score_threshold: 0.30, # 向量相似度阈值宁低勿高 rerank_top_n: 5, # 重排序后最终进入上下文的条数 hybrid_search: True, # BM25 向量召回混合 bm25_weight: 0.3, # BM25结果在混合排序中的权重 query_rewrite_rules: { lbbb: [左束支传导阻滞], acs: [急性冠脉综合征], mi: [心肌梗死], }, }这段配置里的每个参数都有讲究。top_k20是初召回数量医疗场景漏召回比多召回危险所以先放宽检索范围score_threshold设成0.30而不是更高的0.6也是同样的逻辑宁可多召回不相关片段也不能让真正关键的证据因为分数略低被过滤掉。rerank_top_n5表示最终进提示词的只有5个chunk这一步是精筛通常用交叉编码器重排序小团队如果资源有限可以先不做rerank只把top_k放宽到20让诊断Agent自己从20个片段里选证据。hybrid_searchTrue解决缩写问题BM25按字面匹配把“LBBB”这种缩写直接命中。query_rewrite_rules是缩写扩展表每次遇到检索失败就先查这张表而不是急着换嵌入模型。提示医疗RAG知识库的调参顺序一定是先看漏检再谈精度。你可以在检索服务里打印每个问题的命中chunk列表人工扫一遍就知道是阈值太高、分块太碎还是缩写没扩展。5. 联调与避坑心内科诊断系统最容易翻车的5个现场多智能体协同和RAG知识库单独跑都能work一旦联调各种“玄学级”问题就冒出来了。这一章写5个我踩过的具体坑全部按“现象→原因→解决”的顺序写。5.1 检索命中但回答里没有引用证据模型把知识库当“参考书”而不是“证据”现象知识库里明明有2023版心衰指南患者主诉“气促、下肢水肿”系统输出“考虑心衰”但整个回答里没有任何引用标注医生追问依据时系统答不上来。原因提示词里只写了“请参考检索内容”没有强制要求引用机制。LLM把检索结果当成背景知识而不是必须在回答中逐条表明出处的证据。这是RAG项目最典型的误配置。解决在文书Agent的生成指令里加硬约束每个诊断结论后面必须附引用ID格式固定为[docs:编号]如果关键证据未检索到直接输出“证据不足建议补充检查”禁止编造。提示词长这样诊断结论后必须附引用ID格式为[docs:N]。 若结论对应的关键证据未检索到直接输出“证据不足建议补充检查”禁止编造。显式的否定指令比“请准确回答”有效得多。加了这条约束后系统宁可答“证据不足”也不会给出无依无据的断言。5.2 多Agent跑到第三轮出现“记忆冲突”气促被当成新主诉支架史凭空消失现象分诊Agent在第一轮已经记录“既往PCI术后”到检查建议Agent输出时这段病史不见了患者补充的“气促”在诊断Agent那里被当成独立新主诉导致诊断方向跑偏。原因共享状态被某个Agent原地覆盖。常见写法是直接在CaseContext的dict上做update不同Agent的执行顺序导致后写入覆盖先写入又没有在审计日志里留下前后对比。解决按第3章的字段权限设计把状态分成原始区、推理区、审计区任何Agent不能直接覆盖原始字段。更重要的是加审计对比每次Agent执行完记录变更字段的前后值。这样即使发生覆盖也能重放trace定位是哪个Agent动的手。5.3 同一份病历两次诊断结论不一致温度与召回排序都在抖现象同一份心电图报告文本上午跑是“考虑房颤建议抗凝”下午跑是“窦性心律观察”医生直接把系统判了死刑。原因两个因素叠加。生成侧采样温度过高检索侧向量相似度分数接近的文档顺序抖动导致两次检索返回的chunk列表顺序不一样模型看到的上下文不同结论自然不同。解决诊断相关Agent的temperature固定到0.05到0.1top_p不低于0.85任何情况下不对诊断结论开启随机采样。检索侧对每个文档生成稳定的hash值排序时用“score为主、hash为副”做确定性仲裁。我在项目里的做法是检索结果先按分数排序分数相同按hash排序保证同一条知识库内容返回顺序永远一致。这个用例不需要创造性发挥答案应该可复现。5.4 知识库明明有“左束支传导阻滞”检索就是查不到现象用户输入“LBBB”知识库文档里写的是“左束支传导阻滞”RAG返回了完全不相关的chunk诊断Agent给不出关于LBBB的鉴别诊断。原因向量模型对医学缩写的语义映射很弱BM25又因为字符级不匹配而无法命中。这个问题在纯向量检索项目里几乎无解因为语义本身就模糊。解决建同义词缩写归一表在query改写阶段把缩写还原成中文全称和英文全称再进检索器。上面的retriever_config里已经写了query_rewrite_rules实际生产里这张表是迭代频率最高的每个被复核为错误的病例优先查是不是缩写和术语没有进表而不是去换embedding模型。换模型成本高且不可解释补表是五分钟的事。5.5 离线评测准确率高一上真实病历就崩现象用100份脱敏标注病历跑离线评测诊断准确率91%。拿医院最近两周的真实门诊病历做抽样测试准确率掉到六成左右。原因评测集和真实分布的偏差。标注病历往往是“已经确诊的典型病例”症状描述规范、检查结果齐全真实病历里有大量非典型症状、多病共存、信息缺失的情况。更隐蔽的问题是如果用随机切分方式划分训练和测试病历中同一患者多次就诊的记录会同时出现在两边造成数据泄漏。解决用时间切分代替随机切分。前6个月病历用于构建RAG知识库和调参后6个月病历只做评测保证知识库不存在“见过答案”的可能。评测指标除了诊断准确率还要加两个底线指标证据覆盖率每个诊断结论是否都有引用ID支撑和幻觉率无引用ID却输出的结论占比。我的项目经验是宁要85%的证据覆盖率也不要95%却没依据的准确率。6. 验证这套系统能不能进科室单病例回溯与批量模拟评测6.1 单病例回溯从结论反向检查证据链多智能体系统的可追溯性设计最终要落到验证手段上。我的习惯是每次改完知识库或提示词先抽三个历史病例做单病例回溯取一条pipeline输出从audit_trail里逆序检查每个诊断假设的引用ID然后做一个“遮挡重放”测试——把对应知识库原文完全遮住让诊断Agent只看剩余上下文重新推理一次。如果遮挡后推理结果明显漂移说明结论依赖了未被引用的隐藏上下文如果遮挡后结论依然稳定说明证据链是真实可信的。这个办法成本低、可解释是目前对幻觉最直接的检测手段之一。每轮回溯发现的断裂证据链我都会记入一个独立的问题清单按“知识库缺块、缩写未扩展、阈值过严”三个类别归因修复后再重放。6.2 批量模拟评测三项指标和一个小脚本单病例回溯解决的是“个案对不对”批量模拟评测解决的是“整体稳不稳”。我每周跑一次批量回溯固定用后6个月的时间切分病例集脚本逻辑很轻量def evaluate_trace(trace, gold_docs): total max(len(trace), 1) coverage sum( 1 for step in trace if step.get(citation_id) in gold_docs ) / total hallucination sum( 1 for step in trace if not step.get(citation_id) ) / total stability diagnosis_consistency(prev_result, cur_result) return { evidence_coverage: coverage, hallucination_rate: hallucination, diagnosis_stability: stability, }三个指标各有作用evidence_coverage低于0.85说明RAG召回或证据组织有问题先查分块和query改写hallucination_rate高于0.05说明提示词约束失效优先加硬拒答逻辑diagnosis_stability连续两次跑同一批病例不一致则检查采样参数和检索排序确定性。重点提醒一句指标崩了不要急着换模型。在这个架构里90%的问题都在知识库覆盖度和检索参数上换模型只会让问题更不可控。医疗诊断系统和我之前做过的所有RAG项目最大的不同是错误代价不对称。一个错误的诊断建议在普通问答场景里只是体验差在科室里就是真实的风险。我现在的习惯是每次发布前跑两轮批量回溯把证据链断裂的病例标记出来优先补知识库和同义词表而不是去调模型。坚持三个月后诊断稳定性上升明显系统输出也终于敢给医生复核了。希望帮到你。本文还有配套的精品资源点击获取