免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

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

发布日期:2026-05-12 02:00:23 浏览次数: 1521
作者:Java开发者笔记

微信搜一搜,关注“Java开发者笔记”

推荐语

如何让AI导诊像真实医生一样问诊?Qwen3-8B结合GraphRAG,实现从症状到诱因的多轮智能对话。

核心内容:
1. 传统AI导诊的常见问题与局限性分析
2. 基于Qwen3-8B与GraphRAG的新一代技术方案设计
3. 实际部署架构与性能优化策略

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家


业务背景

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

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

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

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

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

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

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

技术方案设计

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

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

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

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

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

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

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

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

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

RAG的切分与检索

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

  1. 父子切分
  2. 固定长度切分
  3. 行切分
  4. 语义切分
  5. 结构化切分

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

定义好切分方式以后,我们又发现了一个新问题。医疗领域方面数据格式千奇百怪,针对大文档的处理,特别是扫描件信息,传统的 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 即可本地推理。

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

  1. 方言转医疗术语借助我们训练后的 8B 模型做查询改写,会得到三个信息:原始查询,改写查询,实体信息

  2. query 多路召回,设计三个不同的权重:original、normalized、rewrited,让三个 query 全部去查询汇总结果,主要思想是“以覆盖换召回”

  3. 针对原始查询,top_k 进行放大,这一步主要是为了尽可能的检索出多个相关信息

  4. 召回设计多种机制:向量召回+关键词召回+RRF 融合机制。关键词召回中可以选用 es 做全文检索,也可选用 mysql 设计 FULLTEXT 和 LIKE 匹配。但是建议是使用 es,对分词更友好

  5. 最后图谱检索,将上方的查询改写拿到的实体,结合图谱的 node 和 Relationship,实现二级跳或者三级跳跃查询,并且在实体层面,建立多级动态实体维护:

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

最后给大家一份我们项目中最最详细的 mermaid 图:

flowchart TD
    subgraph "用户与入口"
        U["用户 / 前端对接方"]
        RAG["/rag 测试页<br/>Vue2 单页"]
        DOCS["/docs / redoc / openapi.json"]
    end

    subgraph "hospital_rag 主服务"
        MAIN["FastAPI<br/>app/main.py"]
        ROUTER["api/router.py"]
        RET_API["/api/v1/retrieval/search"]
        ING_API["/api/v1/ingestion/*"]
        TEST_API["/api/v1/rag-test/*"]
    end

    subgraph "检索主链路"
        RET_SVC["RetrievalService"]
        KB_RESOLVE["知识库范围解析<br/>tenant_id + knowledge_base_ids"]
        QR["QueryRewriteService<br/>normalized_query + rewrite_queries + entities"]
        VARIANTS["多路 Query 变体<br/>original / normalized / rewrite"]
        EMBED_Q["查询向量化<br/>EmbeddingService.embed_texts"]
        VEC["Milvus 向量召回"]
        KW["MySQL 关键词召回<br/>FULLTEXT -> LIKE fallback"]
        FUSION["Hybrid Fusion<br/>RRF(vector + keyword)"]
        PAYLOAD["回表加载 Chunk / Document / Citation"]
        RERANK["候选重排<br/>EmbeddingService.rerank"]
        DIVERSE["结果去重与分散<br/>每文档最多 2 条"]
        GRAPH["GraphSearchService"]
        GRAPH_TREE["graph_tree 构树<br/>动态实体分组 + 结构加分"]
        RESP["统一响应包装<br/>code / message / data"]
        LOG["RetrievalLogWriter"]
    end

    subgraph "入库与异步任务"
        UPLOAD["本地上传<br/>upload-local"]
        PREVIEW["预览切分<br/>/preview"]
        VECTORIZE["提交向量化 / 重跑<br/>/documents"]
        DELETE["异步删除<br/>/deletions"]
        ING_SVC["IngestionService"]
        DEL_SVC["DeletionService"]
        CELERY["Celery"]
        REDIS["Redis Broker"]
        WORKER["IngestionWorkerService"]
        DEL_WORKER["DeletionWorkerService"]
        FETCH["按 download_url 拉取原文件"]
        PARSER["DocumentParser"]
        CLEAN["DocumentCleaner"]
        CHUNK["ChunkingService<br/>fixed / character / structured / parent-child / semantic / table"]
        EMBED_DOC["批量 chunk 向量化"]
        GRAPH_EX["GraphExtractionService<br/>LLM 抽取实体 / 关系"]
        MYSQL_WRITE["写 MySQL"]
        MILVUS_WRITE["写 Milvus"]
        NEO4J_WRITE["写 Neo4j"]
    end

    subgraph "外部推理与解析服务"
        MODEL_SVC["rag_model_server<br/>embedding + rerank"]
        EMB_EP["/v1/embeddings"]
        RERANK_EP["/v1/rerank"]
        LLM_SVC["Qwen3-8B vLLM<br/>查询改写 / 图谱抽取"]
        CHAT_EP["/v1/chat/completions"]
        MINERU["MinerU Pipeline<br/>文档解析服务"]
    end

    subgraph "数据与配置"
        MYSQL["MySQL<br/>knowledge_base / document / chunk / jobs / graph_* / retrieval_log"]
        MILVUS["Milvus<br/>rag_chunk_vectors"]
        NEO4J["Neo4j<br/>知识图谱"]
        FILES["对象存储 / 本地测试文件<br/>download_url"]
        ENTITY_CAT["GraphEntityCatalog<br/>实体目录表"]
        KB_ENTITY["KnowledgeBase.graph_entity_codes<br/>知识库绑定实体"]
    end

    U --> RAG
    U --> DOCS
    RAG --> MAIN
    DOCS --> MAIN
    MAIN --> ROUTER
    ROUTER --> RET_API
    ROUTER --> ING_API
    ROUTER --> TEST_API

    RET_API --> RET_SVC
    RET_SVC --> KB_RESOLVE
    RET_SVC --> QR
    QR -->|调用生成模型| LLM_SVC
    LLM_SVC --> CHAT_EP
    QR --> VARIANTS

    KB_RESOLVE --> VEC
    KB_RESOLVE --> KW
    KB_RESOLVE --> GRAPH

    RET_SVC -->|query_db = 0 / 1| EMBED_Q
    EMBED_Q --> MODEL_SVC
    MODEL_SVC --> EMB_EP
    EMBED_Q --> VEC

    RET_SVC -->|query_db = 0 / 1| KW
    VEC --> FUSION
    KW --> FUSION
    FUSION --> PAYLOAD
    PAYLOAD --> MYSQL
    PAYLOAD --> RERANK
    RERANK --> MODEL_SVC
    MODEL_SVC --> RERANK_EP
    RERANK --> DIVERSE

    RET_SVC -->|query_db = 0 / 2| GRAPH
    VARIANTS --> GRAPH
    QR --> GRAPH
    KB_ENTITY --> GRAPH
    GRAPH --> NEO4J
    GRAPH --> GRAPH_TREE
    ENTITY_CAT --> GRAPH_TREE

    DIVERSE --> RESP
    GRAPH_TREE --> RESP
    RESP --> RET_API
    RET_SVC --> LOG
    LOG --> MYSQL

    TEST_API --> UPLOAD
    TEST_API --> PREVIEW
    ING_API --> VECTORIZE
    ING_API --> DELETE

    UPLOAD --> ING_SVC
    UPLOAD --> FILES
    VECTORIZE --> ING_SVC
    DELETE --> DEL_SVC

    ING_SVC --> MYSQL_WRITE
    DEL_SVC --> CELERY
    ING_SVC --> CELERY
    REDIS --> CELERY
    CELERY --> WORKER
    CELERY --> DEL_WORKER

    WORKER --> FETCH
    FETCH --> FILES
    WORKER --> PARSER
    PARSER --> MINERU
    PARSER --> CLEAN
    PREVIEW --> PARSER
    PREVIEW --> CLEAN
    CLEAN --> CHUNK
    PREVIEW --> CHUNK

    CHUNK --> MYSQL_WRITE
    CHUNK --> EMBED_DOC
    CHUNK --> GRAPH_EX

    EMBED_DOC --> MODEL_SVC
    EMBED_DOC --> MILVUS_WRITE

    GRAPH_EX -->|调用生成模型| LLM_SVC
    ENTITY_CAT --> GRAPH_EX
    KB_ENTITY --> GRAPH_EX
    GRAPH_EX --> MYSQL_WRITE
    GRAPH_EX --> NEO4J_WRITE

    MYSQL_WRITE --> MYSQL
    MILVUS_WRITE --> MILVUS
    NEO4J_WRITE --> NEO4J

    DEL_WORKER --> MYSQL
    DEL_WORKER --> MILVUS
    DEL_WORKER --> NEO4J

看到这里如果对你有帮助或者有疑问欢迎后台留言私信。


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询