软件学院创新项目实训第一期报告

面向用药安全的多智能体协同决策系统


负责内容:后端设计与模型微调
阶段:2026 年第一期阶段报告


摘要

本报告为“面向用药安全的多智能体协同决策系统”项目的第一期阶段性报告,重点围绕项目的研究背景、系统目标、总体技术路线、后端与模型微调任务规划展开说明。针对当前临床与日常生活中处方药、非处方药、保健品混用带来的安全风险,项目拟构建一套基于多智能体协同、知识图谱检索增强与后端状态机控制的安全用药辅助决策系统。本人在项目中主要负责后端服务架构设计、医疗数据集预处理与统一建模、小型模型微调、推理服务接入及评测分析等工作。

在本阶段中,项目已经完成了整体技术路线论证,并初步确定了后端与微调部分所采用的数据集与模型。数据侧选定 MIMIC-III、MIMIC-IV、eICU 和 TWOSIDES,分别承担真实临床上下文建模、跨院泛化验证与药物相互作用知识支撑等功能;模型侧选定 Qwen2.5-3B-Instruct、Qwen2.5-7B-Instruct、MedGemma 与 BioMistral,用于结构化抽取、药物风险审查、追问生成及医学领域模型对比实验。报告同时给出了后续阶段的模块拆分、实施流程、实验计划与预期成果,为后续系统开发与中期检查提供明确依据。

关键词: 用药安全,多智能体协同决策,知识图谱,Graph RAG,后端微服务,模型微调


1. 项目背景与问题提出

随着医疗信息化的发展,用药决策逐渐从传统的人工经验判断走向数字化辅助分析。然而,在实际场景中,用药安全问题远比单一处方推荐复杂。尤其在以下情境下,风险尤为突出:

  • 患者同时服用处方药、非处方药(OTC)、中成药或保健品,导致成分叠加或药物相互作用;
  • 医生或患者在信息不完整条件下作出决策,例如未知过敏史、未知孕哺状态、未知基础疾病;
  • 单体大模型虽然具备较强语言理解与生成能力,但在医疗场景中容易出现幻觉、自我确认偏差以及缺乏可追溯证据的问题;
  • 传统的规则系统又往往过于僵化,难以适应自然语言输入、多轮补充问答以及复杂上下文条件下的柔性决策需求。

因此,本项目提出“面向用药安全的多智能体协同决策系统”,希望构建一个能够同时兼顾自然语言交互能力、知识图谱确定性约束、多智能体交叉审核能力与工程可部署性的后端系统。该系统不以“自动开药”为唯一目标,而更强调在候选方案基础上的安全审查、风险解释、追问补全与柔性降级,从而为医生端与患者端提供更可信的数字化辅助能力。

从项目目标看,本系统更接近“用药安全决策护栏”而非“黑盒式自动处方生成器”。其核心价值体现在:一方面通过知识图谱与图检索增强提升风险识别的确定性;另一方面通过多智能体协同与后端状态流控制提升系统输出的可解释性与稳定性。


2. 项目总体目标与第一期任务定位

2.1 总体目标

本项目总体目标是研发一套面向全场景安全用药的 Web 系统原型,使系统能够完成如下核心任务:

  1. 接收用户自然语言输入的主诉、既往疾病、当前用药或疑问;
  2. 将输入解析为结构化患者标签与候选药物信息;
  3. 基于药物知识图谱与图检索能力识别药物相互作用、特殊人群禁忌与重复成分风险;
  4. 借助多智能体内部协同机制对用药草案进行审查、驳回、追问与修正;
  5. 将最终结果以“阻断警示 / 风险建议 / 信息追问 / 防御性免责说明”等形式返回前端。

2.2 第一期报告的任务定位

第一期报告的主要目标不是展示完整实验结果,而是对项目方案进行系统论证,并明确后续开发与实验计划。因此,本阶段工作重点包括:

  • 明确系统目标与总体技术架构;
  • 确定本人负责部分的工作边界;
  • 完成后端与微调方向的数据集选型;
  • 完成候选模型的技术路线选择;
  • 形成统一的数据建模方案与后续实验计划;
  • 为中期阶段的实现与联调提供清晰的执行路线。

换言之,本报告更强调“做什么、为什么这样做、后面怎么做”,属于一份完整的阶段性计划报告。


3. 系统总体方案设计

3.1 总体架构思路

结合项目需求,系统总体上采用“前后端分离 + 多智能体后端调度 + 图谱审查 + 状态机控制”的方案。系统逻辑可划分为四层:

  1. 数据层:临床数据、药物规则数据、药物相互作用知识;
  2. 模型与智能体层:分诊 Agent、药师 Agent、小型语言模型推理模块;
  3. 后端服务层:FastAPI 微服务、图谱检索接口、状态流控制、日志系统;
  4. 前端交互层:基于 Vue3 的动态页面、追问弹窗、风险展示与结果渲染。

其中,本人负责的重点位于数据层、模型与智能体层、后端服务层的交叉区域,即负责将临床数据、图谱约束、模型推理与后端接口整合为可实际运行的服务链路。

3.2 多智能体协同机制

系统采用双智能体协同机制:

  • 分诊 Agent:负责接收用户自然语言描述,完成实体识别、结构化抽取、候选用药方案生成与初步信息组织;
  • 药师 Agent:负责调用图谱检索工具,对候选方案进行药物安全审查,并根据检索结果作出通过、阻断或追问决策。

这种设计的核心优势在于将“生成”与“审查”解耦,避免单一模型在生成与审核过程中形成自我确认偏差,提高系统在医疗场景中的安全性与可解释性。

3.3 知识图谱与检索增强机制

项目中使用的知识图谱主要承载药物—药物、药物—疾病、药物—人群等确定性关系。后端在处理候选用药方案时,会优先调用图谱检索服务检查:

  • 是否存在药物相互作用;
  • 是否存在重复成分叠加;
  • 是否存在特殊人群禁忌;
  • 是否与既有疾病或症状存在冲突;
  • 是否需要补充关键信息后才能继续判断。

检索结果将反向作为证据输入到药师 Agent 中,使模型生成基于证据而非纯语言联想。

3.4 动态追问与柔性降级

考虑到真实用药场景下信息缺失普遍存在,系统设计了“追问—补充—复审”的动态机制。当药师 Agent 发现某项关键信息缺失,例如孕哺状态、过敏史、年龄或基础疾病时,系统并不会直接给出高置信建议,而是进入追问状态。若用户无法提供补充信息,则触发降级逻辑,输出保守性建议与免责提醒,而非冒险给出不安全判断。


4. 本人负责内容与阶段目标

4.1 职责定位

在团队分工中,本人主要负责“后端,微调”。结合项目实际需求,这部分职责可进一步细化为以下五个方面:

  1. 医疗数据集获取、清洗与统一建模;
  2. 后端微服务架构设计与接口实现;
  3. 多智能体调度链路设计与执行控制;
  4. 小型模型的任务适配、微调与对比;
  5. 评测体系、部署流程与异常兜底机制设计。

因此,本人的工作并非单纯写接口或单纯训模型,而是承担“从数据到服务”的关键衔接任务。

4.2 第一期阶段目标

在第一期阶段,本人负责部分的主要目标如下:

  • 完成临床数据集和药物风险数据集的可行性分析与选型;
  • 明确用于结构化抽取、风险审查与追问生成的小模型方案;
  • 设计统一的数据建模结构与后端请求/响应格式;
  • 形成后续微调、评测与系统接入的总体计划;
  • 为第二阶段进入代码实现与样本构造做好准备。

5. 数据集选型与任务建模计划

5.1 数据集选型原则

由于本项目属于“医疗安全审查”场景,数据集选择必须同时满足以下条件:

  1. 具有真实临床上下文,而非纯规则示例;
  2. 包含诊断、病史、药物等与用药安全直接相关的信息;
  3. 支持构建训练样本与外部泛化验证样本;
  4. 允许与外部药物知识图谱或风险知识库对接;
  5. 与项目现有算力条件和工程周期相匹配。

基于上述原则,本项目后端与微调部分最终确定使用 MIMIC-III、MIMIC-IV、eICU 和 TWOSIDES。

5.2 MIMIC-III 的作用

MIMIC-III 作为经典临床数据库,主要用于构建单中心场景下的患者—诊断—历史用药样本。它能够支撑以下内容:

  • 以患者诊断、病史、历史药物为输入,构建候选用药或风险审查样本;
  • 为结构化抽取任务提供标准字段模板;
  • 为后续风险审查模块提供真实临床背景;
  • 作为系统训练阶段的重要基础数据源。

5.3 MIMIC-IV 的作用

MIMIC-IV 相比 MIMIC-III 在数据组织上更细,且药物相关记录更丰富,因此可用于:

  • 扩充训练样本的覆盖范围;
  • 构建更完整的患者上下文与药物事件链;
  • 验证模型在不同时间分布条件下的适应能力;
  • 强化后端状态追踪与药物风险分析的上下文支撑。

5.4 eICU 的作用

eICU 属于多中心重症数据集,最重要的价值在于外部泛化验证。它可以帮助检验:

  • 模型是否过度依赖单一机构的处方分布;
  • 后端风险审查模块在跨院数据上的稳健性;
  • 多智能体审查逻辑在不同数据来源下是否仍然成立。

因此,eICU 更适合用于项目后续的外部测试与比较分析,而不是单纯扩大训练量。

5.5 TWOSIDES 的作用

TWOSIDES 主要提供药物相互作用与不良反应信息,是项目图谱检索与风险审查环节的关键知识来源。其主要作用包括:

  • 构建药物相互作用边;
  • 为药师 Agent 提供确定性审查依据;
  • 为系统输出中的风险解释部分提供证据来源;
  • 支撑 Graph RAG 中“图谱事实 + 模型生成”的混合决策模式。

5.6 统一任务建模方案

针对上述数据集,本项目后续将统一构建三类任务:

(1)结构化抽取任务

输入为自然语言主诉、病历摘要或用户补充描述,输出为统一的 JSON 结构,主要字段包括:

  • 患者基本信息:年龄、性别、孕哺状态、过敏史;
  • 症状与主诉;
  • 诊断与既往病史;
  • 当前用药与候选用药;
  • 缺失信息字段。
(2)药物风险审查任务

输入为“患者上下文 + 候选药物组合 + 图谱检索证据”,输出为:

  • 风险等级;
  • 风险原因;
  • 是否阻断;
  • 替代建议;
  • 是否需要追问。
(3)追问生成任务

输入为当前不完整的患者信息与待判断的用药草案,输出为最关键的补充问题或保守性建议。


6. 模型选型与微调方案设计

6.1 模型选型原则

在模型选型上,本项目重点考虑以下几点:

  1. 模型规模应适合现有算力条件(4 张 4090 至 2 张 H800);
  2. 模型应支持结构化输出、较强的指令遵循和较低的部署成本;
  3. 项目既需要通用模型作为主力,也需要医学领域模型作为对照;
  4. 模型必须适合后续本地微调与本地部署。

基于这些要求,后端与微调部分最终选用四类模型:Qwen2.5-3B-Instruct、Qwen2.5-7B-Instruct、MedGemma 与 BioMistral。

6.2 Qwen2.5-3B-Instruct

该模型主要作为快速原型模型,适合在项目前期完成以下工作:

  • 样本模板验证;
  • 后端接口联调;
  • JSON 结构化输出测试;
  • 小规模指令微调流程打通。

它的价值在于训练成本低、调试效率高,适合项目早期快速迭代。

6.3 Qwen2.5-7B-Instruct

该模型将作为本项目后续的主力通用模型,承担:

  • 正式版结构化抽取;
  • 药物风险审查与解释生成;
  • 追问生成与多轮状态保持;
  • 与图谱检索结果结合后的综合推理。

相比 3B 版本,7B 版本在复杂审查与解释质量方面更具有潜力。

6.4 MedGemma

MedGemma 作为医学方向模型,主要用于:

  • 验证医学模型在药物安全场景中的适配能力;
  • 对比其与通用模型在专业表述、医学术语理解上的差异;
  • 评估其在结构化抽取和审查解释任务上的迁移表现。

6.5 BioMistral

BioMistral 作为生物医学方向模型,主要作用是构建医学领域对照实验,帮助分析:

  • 通用模型与医学模型在抽取、审查、追问三类任务上的性能差别;
  • 小型医学模型在后端本地部署场景中的可行性;
  • 医学领域预训练对药物相关表达理解的实际增益。

6.6 微调任务划分

为适配项目目标,后续微调工作将围绕以下三个任务展开:

(1)结构化抽取微调

目标是让模型从自然语言中稳定抽取患者与药物信息,并输出统一 JSON。

(2)风险审查微调

目标是让模型根据患者上下文与图谱证据,判断候选药物组合是否存在风险,并输出解释与阻断结论。

(3)追问生成微调

目标是在信息缺失时,让模型自动生成关键补充问题,并在无法补全时生成保守性建议。


7. 后端系统设计计划

7.1 后端技术路线

后端部分计划基于 FastAPI 实现异步微服务架构,并在服务内部完成如下能力整合:

  • 请求接入与参数校验;
  • 结构化抽取模型调用;
  • 图谱检索工具调用;
  • 药师 Agent 审查逻辑;
  • 追问与降级状态控制;
  • 日志回放与异常兜底。

7.2 核心接口规划

后端计划实现如下核心接口:

  • POST /api/extract:自然语言输入转结构化标签;
  • POST /api/review:候选用药方案风险审查;
  • POST /api/graph_search:图谱冲突与禁忌检索;
  • POST /api/clarify:追问信息补充后的再次审查;
  • GET /api/case/{id}:请求全过程回放。

7.3 后端工作流规划

后端中的完整工作流设计如下:

  1. 用户输入自然语言主诉;
  2. 分诊 Agent 执行结构化抽取;
  3. 药师 Agent 读取候选药物与患者标签;
  4. 后端调用图谱检索服务;
  5. 药师 Agent 综合图谱证据作出判断;
  6. 若存在冲突则阻断;
  7. 若关键信息缺失则追问;
  8. 若无法补充则降级输出保守建议;
  9. 将最终结果返回前端并记录日志。

8. 实验与评测计划

8.1 实验总体思路

由于第一期阶段尚未进入大规模实验,本阶段主要完成实验设计。后续实验将从两个层面展开:

  • 模型级实验:比较不同模型在结构化抽取、风险审查与追问生成三类任务上的效果;
  • 系统级实验:验证后端接口响应、图谱检索效率、多智能体协同成功率和异常处理能力。

8.2 模型级评测指标

模型评测计划包括以下指标:

  • 结构化抽取:Precision、Recall、F1、JSON 有效率;
  • 风险审查:准确率、召回率、误报率、漏报率;
  • 追问生成:追问命中率、有效补全率、平均追问轮数。

8.3 系统级评测指标

系统评测计划包括:

  • 接口平均响应时间;
  • 图谱检索耗时;
  • 多智能体工作流成功率;
  • 回退机制触发率;
  • 高风险场景阻断准确率。

8.4 对比实验设计

后续模型对比将至少覆盖:

  • Qwen2.5-3B 与 Qwen2.5-7B;
  • Qwen2.5-7B 与 MedGemma;
  • Qwen2.5-7B 与 BioMistral;
  • 通用模型与医学模型在三类任务上的差异分析。

9. 阶段实施计划

结合项目当前周期,本人负责部分拟按以下步骤推进:

9.1 第一阶段:数据与方案确定

完成数据集与模型选型,形成统一的数据建模与任务设计方案,并完成第一期报告撰写。

9.2 第二阶段:后端基础搭建与样本构造

完成 FastAPI 项目初始化、Pydantic 数据结构定义、基础接口搭建,并开始构造三类训练样本。

9.3 第三阶段:小模型微调与图谱工具实现

完成 Qwen2.5-3B 快速实验、图谱检索模块搭建,并逐步接入 Qwen2.5-7B、MedGemma 与 BioMistral 的比较实验。

9.4 第四阶段:联调与中期展示准备

将最优模型接入后端服务,与前端联调,补充日志回放、异常处理和展示案例,为中期检查与演示准备材料。


10. 当前阶段已完成内容

在第一期阶段,截至目前已完成以下工作:

  1. 明确了项目总体目标与系统核心机制;
  2. 梳理了本人在项目中的职责边界;
  3. 完成了后端与微调方向的数据集选型;
  4. 完成了主力模型与对照模型的初步选择;
  5. 形成了统一任务建模与后端接口规划;
  6. 明确了后续阶段的训练、部署与评测路线。

虽然本阶段尚未进入完整实验与联调,但已为下一阶段的工程实现和模型微调打下了清晰基础。


11. 存在的问题与下一步计划

11.1 当前存在的主要问题

尽管项目方案已经初步明确,但在进入实现阶段前仍存在若干问题需要解决:

  • 多源临床数据之间的字段映射与药物名称归一化工作量较大;
  • TWOSIDES 与临床数据中的药物实体需要进一步统一编码;
  • 追问生成任务的数据构造需要人工设计较多模板;
  • 医学模型与通用模型的任务边界仍需通过实验进一步验证;
  • 后端状态机如何与前端交互流程精确对接,还需在第二阶段细化。

11.2 下一步计划

下一阶段将重点推进以下工作:

  1. 完成 MIMIC-III、MIMIC-IV、eICU、TWOSIDES 的字段梳理与初步样本构造;
  2. 完成患者上下文对象、药物实体对象和风险证据对象的统一定义;
  3. 搭建 FastAPI 后端基础服务与核心接口骨架;
  4. 构建结构化抽取与风险审查的首批微调样本;
  5. 启动 Qwen2.5-3B 的原型实验与后端联调测试。

12. 结论

本报告围绕“面向用药安全的多智能体协同决策系统”项目,系统梳理了第一期阶段中本人所负责的后端设计与模型微调工作的总体规划。项目针对当前多药混用、信息不完整、规则系统僵化与单体模型不可靠等问题,提出了一条结合多智能体协同、知识图谱审查、后端状态机控制与小模型本地部署的技术路线。该路线既强调语言模型的理解与生成能力,也强调图谱证据与审查机制对医疗安全的约束作用。

在本阶段中,已完成项目方案论证、数据集选型、模型选型、任务建模与后端规划等基础工作,并明确了下一阶段将围绕数据预处理、样本构造、后端开发和原型实验展开。总体来看,第一期阶段的工作已经完成了从“问题提出”到“技术路线落地计划”的过渡,为后续进入工程实现与中期展示奠定了基础。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐