简介本资源面向医疗人工智能方向的研究者、算法工程师与心内科临床信息化开发者提供一套基于检索增强生成RAG与多智能体协同架构的心内科疾病智能诊断系统开发项目。项目围绕心电图、超声心动图、生化指标等临床数据结合文献与案例库检索实现个性化诊断建议生成并通过多智能体分工完成数据整理、风险评估与治疗方案生成适合作为医疗AI课题复现、毕业设计或工程落地的参考方案。资源包共23个文件包含11个json病例与配置数据、10个pdf心内科指南及文献、1个txt说明与1个md文档压缩包约12.58MB目录按语料、病例与输出示例分层组织。已有68人学习下载读者可获取完整项目结构、病例样例、医学知识语料与输出示例快速理解RAG与多智能体在医疗诊断中的协同实现路径。1. 心内科诊断系统为什么需要 RAG 加多智能体协同心内科门诊有个很现实的问题一个主诉“胸闷三天”的患者可能对应稳定型心绞痛、急性冠脉综合征、主动脉夹层、肺栓塞、胃食管反流甚至焦虑障碍。指南文本动辄上百页检验指标几十项影像报告又各说各话。单靠一个大模型直接问答最常见的翻车是“编指南”——它会把 2018 年的旧推荐当成 2023 年更新把禁忌症说成适应证。检索增强生成RAG解决的是“知识从哪来、引用可不可查”多智能体协同解决的是“一个复杂诊断任务该拆给谁、谁对谁负责”。把这两件事拼起来才是一个能落地的心内科疾病智能诊断系统RAG 负责把指南、共识、药品说明书、院内路径变成可检索的知识底座多智能体负责分诊、证据检索、鉴别诊断、用药核查、报告汇总各司其职。这套架构适合谁适合手里有结构化病历和指南文档、想做一个可解释诊断辅助的工程团队也适合想从“套壳问答”升级到“可追溯推理”的医疗 AI 开发者。下面按“知识底座怎么搭 → 智能体怎么分工 → 怎么跑通 → 坑在哪 → 怎么验证”的顺序讲透。2. 心内科 RAG 知识底座从指南 PDF 到可检索证据链2.1 为什么心内科不能只靠向量库要区分三类知识库热搜里常有人问“rag知识库和结构知识库区分以及应用场景”放到心内科特别典型。心内科知识大致分三类混在一起存会直接拖垮召回质量。第一类是非结构化指南文本比如《稳定性冠心病诊断与治疗指南》《心力衰竭诊断和治疗指南》。这类适合切块后进向量库用语义相似度召回。第二类是结构化知识比如“肌钙蛋白 I 超过参考上限第 99 百分位 缺血症状 心肌损伤”这是规则和阈值适合放进图数据库或关系表用精确查询而不是向量近似。第三类是半结构化院内路径比如胸痛中心的时间节点表、用药剂量表适合用表格解析后存成键值对。我一般会做三层向量库存指南原文块图库KG存疾病-症状-检查-药物-禁忌的关系关系库存阈值和剂量。检索时先走图库做实体对齐再用向量库补原文证据最后用关系库校验数值。这就是热词里说的“kg知识库”和“ontology rag”的落地形态——不是二选一而是分工。提示心内科药物剂量和禁忌必须走结构化查询不要让向量库“猜”否则阿司匹林在消化道出血患者身上的禁忌会被语义相似度抹平。2.2 用 Python 把指南 PDF 切成带元数据的证据块下面这段是最小可跑的分块脚本核心是保留来源、页码、章节方便后面做引用回溯。import re from pathlib import Path from langchain.text_splitter import RecursiveCharacterTextSplitter def clean_text(raw: str) - str: # 去掉页眉页脚、多余空白保留中文标点和数字 raw re.sub(r\n{2,}, \n, raw) raw re.sub(r第\s*\d\s*页, , raw) return raw.strip() def split_guideline(pdf_text: str, source: str, page: int): splitter RecursiveCharacterTextSplitter( chunk_size500, # 中文指南一段约 400-600 字500 较稳 chunk_overlap80, # 重叠 80 字避免阈值被切断 separators[\n\n, \n, 。, , ] ) chunks splitter.split_text(clean_text(pdf_text)) return [{ text: c, source: source, # 指南文件名 page: page, # 页码用于引用 dept: cardiology # 科室标签便于过滤 } for c in chunks]逻辑说明chunk_size500是中文医学文本的经验值太小会丢上下文太大召回噪声多。chunk_overlap80保证“肌钙蛋白超过第 99 百分位”这类跨句阈值不被切断。source和page是后面做证据链引用的关键没有它们RAG 输出就无法被医生核查。参数怎么改如果指南表格多先把表格单独抽出来走结构化解析不要硬塞进这个分块器。2.3 检索层要加科室过滤和阈值重排纯向量召回在心内科容易把“心衰”和“肾衰”混在一起因为两者都涉及水肿、呼吸困难。常见做法是检索时加元数据过滤deptcardiology再用一个交叉编码器做重排。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def retrieve(query, vector_store, top_k20, final_k5): # 先粗召回 20 条再重排取前 5 coarse vector_store.similarity_search(query, ktop_k, filter{dept: cardiology}) pairs [[query, doc.page_content] for doc in coarse] scores reranker.predict(pairs) ranked sorted(zip(coarse, scores), keylambda x: x[1], reverseTrue) return [doc for doc, _ in ranked[:final_k]]top_k20是粗召回数量final_k5是喂给智能体的证据条数。重排模型选中文医学语料微调过的效果更好没条件就用通用重排但要把阈值调高宁可少召回也不要引入错误证据。这一步是 RAG 质量的分水岭热词里说的“rag瓶颈”很多时候就卡在召回噪声上。3. 多智能体协同分诊、检索、鉴别、用药核查怎么分工3.1 四个智能体的职责边界与消息协议多智能体最容易犯的错是“大家都干一样的活”结果重复检索、互相矛盾。我一般按诊断流程切四个角色分诊智能体输入主诉和生命体征输出紧急程度和初步方向胸痛/心衰/心律失常。证据检索智能体拿分诊结果去 RAG 底座检索指南和结构化知识返回带来源的证据列表。鉴别诊断智能体基于证据做鉴别输出候选诊断及支持/反对证据。用药核查智能体对候选诊断对应的药物做禁忌和相互作用检查。它们之间用结构化消息传递而不是自由文本否则下游没法解析。消息格式建议固定字段task、payload、evidence、confidence。from dataclasses import dataclass, field from typing import List dataclass class AgentMessage: sender: str task: str payload: dict evidence: List[dict] field(default_factorylist) confidence: float 0.0 # 分诊智能体输出示例 triage_msg AgentMessage( sendertriage, taskchest_pain, payload{urgency: high, direction: [ACS, aortic_dissection]}, confidence0.7 )task字段决定下游走哪条链路evidence只在检索后填充confidence用于最终汇总时加权。这样设计的好处是每个智能体可以独立替换和测试不会牵一发动全身。3.2 用状态机编排智能体避免无限循环多智能体协同如果没有终止条件会出现“鉴别智能体要求补证据 → 检索智能体再检索 → 又要求补证据”的死循环。常见做法是用一个轻量状态机控制流转设置最大轮次。MAX_ROUNDS 3 def run_diagnosis(patient, agents): state {round: 0, messages: [], diagnosis: None} msg agents[triage].run(patient) state[messages].append(msg) while state[round] MAX_ROUNDS: state[round] 1 evidence agents[retrieval].run(msg) diff agents[differential].run(evidence) if diff.confidence 0.8 or state[round] MAX_ROUNDS: state[diagnosis] diff break msg diff # 置信度不足带着新问题再检索 return agents[medication].run(state[diagnosis])MAX_ROUNDS3是经验值心内科急诊场景不建议超过 3 轮否则响应时间不可接受。confidence 0.8是提前终止条件具体阈值要按科室调。这个状态机是“多智能体代码”里最该先写对的部分比智能体本身聪明更重要。3.3 智能体之间共享证据而不是各查各的很多实现让每个智能体自己调 RAG结果同一份指南被检索五次既慢又容易不一致。正确做法是检索智能体统一查一次把证据放进共享上下文其他智能体只读不查。class SharedContext: def __init__(self): self.evidence [] self.structured {} def add_evidence(self, docs): self.evidence.extend(docs) def get_by_source(self, source): return [e for e in self.evidence if e[source] source]SharedContext是整条链路的单一事实来源鉴别诊断和用药核查都从这里取证据。这样最终报告里的每条结论都能追溯到具体指南页码医生才愿意用。这也是“多智能体协同”和“单模型多轮对话”的本质区别前者有明确的责任分工和共享证据后者只是换个说法继续编。4. 把系统跑起来从环境到一次完整诊断的最小命令4.1 本地环境与依赖安装先说明这里只讲本地可复现的最小环境不涉及任何网络访问工具。Python 3.10 以上主要依赖向量库、嵌入模型和智能体编排。python -m venv venv source venv/bin/activate pip install langchain chromadb sentence-transformers \ pypdf fastapi uvicorn pydanticchromadb用作本地向量库sentence-transformers提供嵌入和重排fastapi用来暴露诊断接口。如果机器没有 GPU嵌入模型选小尺寸的速度优先。安装完先跑一个嵌入测试确认模型能正常加载再往下走。4.2 灌入指南并建索引import chromadb from sentence_transformers import SentenceTransformer client chromadb.PersistentClient(path./cardio_db) collection client.get_or_create_collection(guidelines) embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) def index_chunks(chunks): for c in chunks: vec embedder.encode(c[text]).tolist() collection.add( ids[f{c[source]}_{c[page]}_{hash(c[text])}], embeddings[vec], documents[c[text]], metadatas[{source: c[source], page: c[page], dept: c[dept]}] )PersistentClient把索引落盘重启不丢。ids用来源加页码加哈希保证不重复。metadatas里的dept就是前面检索过滤的依据。灌完后用一条测试查询验证召回比如“肌钙蛋白升高 胸痛 诊断”看返回的是不是相关指南段落。4.3 一次完整诊断的调用链def diagnose(patient_input: dict): ctx SharedContext() triage triage_agent(patient_input) docs retrieve(triage.payload[direction][0], collection) ctx.add_evidence([{text: d.page_content, **d.metadata} for d in docs]) diff differential_agent(ctx) med medication_agent(diff, ctx) return { triage: triage.payload, diagnosis: diff.payload, medication_check: med.payload, evidence: ctx.evidence }调用链清晰分诊 → 检索 → 鉴别 → 用药核查证据全程共享。返回结构里带evidence前端可以展开每条结论对应的指南来源。参数上patient_input至少要有主诉、生命体征、关键检验缺项时要在分诊阶段标记为信息不足而不是让下游硬猜。5. 避坑与排查心内科 RAG 多智能体最常见的五个翻车点5.1 现象诊断结果引用了不存在的指南页码原因分块时没保留页码或者重排后把元数据丢了。解决分块阶段强制写入page检索返回时校验source和page是否存在缺失的证据块直接丢弃不允许进入鉴别环节。5.2 现象同一患者两次运行给出不同诊断原因向量检索有随机性或者智能体温度参数没固定。解决嵌入和重排设为确定性模式智能体调用时temperature0并把检索结果缓存同一输入走同一证据集。5.3 现象用药核查漏掉禁忌原因禁忌知识存在指南正文里向量召回没命中。解决把禁忌和相互作用单独抽成结构化表用药核查智能体优先查表查不到再走 RAG并在报告里标注“未在结构化库中找到仅供参考”。5.4 现象多智能体循环超过预期轮次原因鉴别智能体置信度一直上不去反复要求补证据。解决设置MAX_ROUNDS并在每轮记录已检索过的查询避免重复检索同一问题超过轮次直接输出当前最优并标注不确定性。5.5 现象中文指南里的表格被切碎阈值丢失原因PDF 表格被当成普通文本分块。解决解析阶段先识别表格用专门工具抽成结构化行再决定是进关系库还是转成自然语言块不要和正文混切。6. 怎么验证这套系统值不值得继续投入验证不要只看“回答像不像”要看三个可量化指标。第一是证据命中率构造 50 条心内科典型病例人工标注应引用的指南段落看系统召回是否覆盖。第二是禁忌漏检率专门测有用药禁忌的病例看用药核查智能体是否拦截。第三是一致性同一病例重复跑 10 次诊断结论是否稳定。我一般会做一个小的回归集用表格管理病例编号主诉金标准诊断系统诊断证据命中禁忌拦截C001胸痛ACSACS是是C002呼吸困难心衰心衰是否C003心悸房颤房颤否是证据命中为“否”的病例要回查检索层禁忌拦截为“否”的要回查结构化库覆盖度。这张表比任何主观评价都有用因为它直接告诉你瓶颈在 RAG 还是智能体。最后一个技巧把每次诊断的完整消息链和证据快照落盘出问题时能回放。心内科场景没有后悔药只有可追溯的日志。我自己踩过最深的坑是早期没存证据快照结果一个错误诊断查了两天才发现是分块把“禁忌”和“慎用”切到了两个块里。从那以后任何进入鉴别环节的证据都必须带来源和页码这条习惯帮我省了无数返工。希望帮到你。本文还有配套的精品资源点击获取