当前位置：首页 > news >正文

Qwen3-8B+GraphRAG在医疗领域的应用

news 2026/4/28 21:29:43

本文介绍了在医疗导诊场景中，如何利用Qwen3-8B模型实现更自然的医患对话，而非传统的问卷形式。作者对比了第一版使用Qwen3-30B模型的不足，如口语理解差、幻觉问题等，并详细阐述了第二版的技术方案设计，包括小模型结合多级缓存提升响应速度，GraphRAG实现多轮问询，模型私有化部署和微调训练解决口语化问题。此外，还介绍了硬件选型、模型服务搭建、多切分方式处理医疗文档、Mineru工具用于OCR处理、Milvus存储chunk数据、BAAI/bge-m3模型组合提升召回率等关键技术细节，最终实现了一个完整的GraphRAG体系。

业务背景

不知道读到这篇文章的朋友们，有没有感受到，目前一些较大的门诊医院中，已经存在了 AI 导诊的功能了，目的就是为了能在就诊前能提前收集一些用户的信息。

博主所在公司，开发的医疗产品，针对导诊，预问诊，电子病历，His 联动一整套 AI 体系产品，这篇文章主要是给大家介绍，在导诊过程中如何借助Qwen3-8B怎么才能不做成问卷表单，而是能真实感觉到你在跟一个医生聊天（我不是打广告，也不是想给公司卖产品，当然有想买产品的可以私信我）

在导诊这方面，我们一共做过两版。

第一版是去年的时候，那时候想着，用一个 Qwen3-30B 的原始模型结合本地的一个简易工作流实现基础版的导诊信息收集。但是很快就发现暴露出来的问题：

针对口语问题，模型总是无法理解到医疗场景下的口语（例如患者说：我脑阔痛啷个办，而模型偶尔会跑偏无法识别到脑阔痛是什么，而且还无法结合上下文的口语来输出）
对常见的门诊病症容易出现幻觉和上下文对不上以及强大的理解偏差。啥意思？就比如我说我手昨天烫伤了，小手臂起了水泡，模型回复一句小手臂哪个位置
模型经常出现重复性问题输出，明明在回复中已经强烈的表示了意愿，但依旧会出现。

诸如此类的问题，还有很多，就不一一列举测试数据了。提示词也改了非常多版本，但起效依旧不大。

所以这一版做出来很轻易的就被甲方 pass 了，所以才有了接下来文章中介绍的这一版。

技术方案设计

我们在第二版的技术设计中考虑到了以下问题：

响应速度，既然是对话，而且是面对小程序的用户量庞大的情况下，并发量上来了也扛不住，所以采用小模型+多级缓存解决。
问卷型对话如何修改？引入 GraphRAG 来实现像真实医生那样从病症到诱因再到症状的多轮问询。
口语化如何解决？患者大多来源于各个省份，虽然四川话居多，但是口语依旧是需要识别的。解决方案：模型私有化部署+微调训练。

在硬件层面，由于国产信创的要求，我们采用的是 4+8 的海光 K100_AI 显卡来部署整个产品。导诊层面我们采用 30B 的对话模型+8B 模型用于 RAG 的查询改写和知识图谱实体抽取。

对话模型采用四卡推理，对外提供两个服务，搭载 Nginx 实现负载均衡，8B 模型使用 2 卡推理，同样采用 Nginx 实现负载均衡，对外就形成一个模型组。同时提供 2w 条基础真实医患对话信息作为8B 模型训练的基础数据以及 2w 条文本 chunk 信息作为知识图谱的实体抽取基础数据。

这样做的好处就是：患者对话信息过来后，先经历查询改写，拿到标准的医疗术语问题以及相关联的实体信息如下：

在常规的 RAG 流程中，通常会这样去完成整个链路的编写：

问题输入 -> 查询改写 -> 向量检索 -> 元信息返回

但是这种简单的方案一般就会遇到上下文对不上的问题，所以我们在此基础上，借助 GraphRAG 的思想，结合我们现有医疗知识搭建一整套医疗层面的GraphRAG。

同时，我们为 RAG 设计自学习机制：通过每日的医患对话信息以及真实 His 系统病历信息，为每一个患者或者每一个科室以及每一种病症类型建立完善的知识图谱体系，最终呈现出的信息就是这样：

RAG的切分与检索

在医疗领域中，知识文档的来源各种各样，那么就需要针对每一种文档来源建立不同的切分方式，所以我们暂定设计了以下几种切分：

父子切分
固定长度切分
行切分
语义切分
结构化切分

以上不同的切分方式用来适配不同的医疗文档。

定义好切分方式以后，我们又发现了一个新问题。医疗领域方面数据格式千奇百怪，针对大文档的处理，特别是扫描件信息，传统的 OCR 在时效性上无法满足需求，在做技术调研时发现 Mineru 这款开源工具：Mineru

这款工具无论是在文件识别上，还是最终返回的格式化信息上都能最大程度的达到效果，再配合上自己本地的一些文本识别补偿，于是解决切分问题，看看效果：

数据存储方面，我们将上方的文档进行切分后得到的 chunk 存储到 Milvus 中（如果你有 pgsql 或者 es 也可以用 es），配合上我们的元信息（页码，分段，章节，标题等等）

对于 embedding 模型和 rerank 模型我们选用的是BAAI/bge-m3 + BAAI/bge-reranker-v2-m3一套，这一套组合在中英文领域都比较友好，且在医疗领域的发挥也非常出色。

bge-m3

bge-reranker-v2-m3

况且这里我们就直接采用单独的模型服务对外提供 api 进行访问，直接采用 Transformer 即可本地推理。

接下来重点说召回问题：如何在这么庞大的知识库中去提高召回率，而不是简单的问题检索转向量得到答案那么简单，召回一共做了以下的设计。

方言转医疗术语借助我们训练后的 8B 模型做查询改写，会得到三个信息：原始查询，改写查询，实体信息
query 多路召回，设计三个不同的权重：original、normalized、rewrited，让三个 query 全部去查询汇总结果，主要思想是“以覆盖换召回”
针对原始查询，top_k 进行放大，这一步主要是为了尽可能的检索出多个相关信息
召回设计多种机制：向量召回+关键词召回+RRF 融合机制。关键词召回中可以选用 es 做全文检索，也可选用 mysql 设计 FULLTEXT 和 LIKE 匹配。但是建议是使用 es，对分词更友好
最后图谱检索，将上方的查询改写拿到的实体，结合图谱的 node 和 Relationship，实现二级跳或者三级跳跃查询，并且在实体层面，建立多级动态实体维护：

经过以上几个步骤，最终形成一个完整的 GraphRAG，同时我们在入口层面，设计 AgentRAG，让模型本身判断是否需要经过 RAG 检索，所以能看到的效果就如下：

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。