AI落地者/案例库/Qwen3-8B +GraphRAG 在医疗领域的应
医疗健康RAGai医疗问诊ai技术在医疗领域的应用

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

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

本页目录

  1. 业务背景
  2. 技术方案设计
  3. RAG的切分与检索

不知道读到这篇文章的朋友们，有没有感受到，目前一些较大的门诊医院中，已经存在了 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
← Anthropic 亲自示范，如何使用金融S拦截率从15%到55%：快手智能Oncall →返回案例库

把方法用到你自己的项目上

读完了，落地是另一回事。企业 AI 落地诊断：90 分钟，先看清再决定投不投。

申请企业 AI 诊断 加入社区