微信扫码
添加专属顾问
如何让AI导诊像真实医生一样问诊?Qwen3-8B结合GraphRAG,实现从症状到诱因的多轮智能对话。 核心内容: 1. 传统AI导诊的常见问题与局限性分析 2. 基于Qwen3-8B与GraphRAG的新一代技术方案设计 3. 实际部署架构与性能优化策略
不知道读到这篇文章的朋友们,有没有感受到,目前一些较大的门诊医院中,已经存在了 AI 导诊的功能了,目的就是为了能在就诊前能提前收集一些用户的信息。
博主所在公司,开发的医疗产品,针对导诊,预问诊,电子病历,His 联动一整套 AI 体系产品,这篇文章主要是给大家介绍,在导诊过程中如何借助Qwen3-8B怎么才能不做成问卷表单,而是能真实感觉到你在跟一个医生聊天(我不是打广告,也不是想给公司卖产品,当然有想买产品的可以私信我)
在导诊这方面,我们一共做过两版。
第一版是去年的时候,那时候想着,用一个 Qwen3-30B 的原始模型结合本地的一个简易工作流实现基础版的导诊信息收集。但是很快就发现暴露出来的问题:
诸如此类的问题,还有很多,就不一一列举测试数据了。提示词也改了非常多版本,但起效依旧不大。
所以这一版做出来很轻易的就被甲方 pass 了,所以才有了接下来文章中介绍的这一版。
我们在第二版的技术设计中考虑到了以下问题:
在硬件层面,由于国产信创的要求,我们采用的是 4+8 的海光 K100_AI 显卡来部署整个产品。导诊层面我们采用 30B 的对话模型+8B 模型用于 RAG 的查询改写和知识图谱实体抽取。
对话模型采用四卡推理,对外提供两个服务,搭载 Nginx 实现负载均衡,8B 模型使用 2 卡推理,同样采用 Nginx 实现负载均衡,对外就形成一个模型组。同时提供 2w 条基础真实医患对话信息作为8B 模型训练的基础数据以及 2w 条文本 chunk 信息作为知识图谱的实体抽取基础数据。
这样做的好处就是:患者对话信息过来后,先经历查询改写,拿到标准的医疗术语问题以及相关联的实体信息如下:
在常规的 RAG 流程中,通常会这样去完成整个链路的编写:
问题输入 -> 查询改写 -> 向量检索 -> 元信息返回
但是这种简单的方案一般就会遇到上下文对不上的问题,所以我们在此基础上,借助 GraphRAG 的思想,结合我们现有医疗知识搭建一整套医疗层面的GraphRAG。
同时,我们为 RAG 设计自学习机制:通过每日的医患对话信息以及真实 His 系统病历信息,为每一个患者或者每一个科室以及每一种病症类型建立完善的知识图谱体系,最终呈现出的信息就是这样:
在医疗领域中,知识文档的来源各种各样,那么就需要针对每一种文档来源建立不同的切分方式,所以我们暂定设计了以下几种切分:
以上不同的切分方式用来适配不同的医疗文档。
定义好切分方式以后,我们又发现了一个新问题。医疗领域方面数据格式千奇百怪,针对大文档的处理,特别是扫描件信息,传统的 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 检索,所以能看到的效果就如下:
最后给大家一份我们项目中最最详细的 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+中大型企业
欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。
在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。
一、 定义
本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。
会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。
知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。
二、 账号注册与登录
登录方式:本网站支持以下登录方式,您可根据实际情况选择:
微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。
手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。
账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。
实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。
未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。
三、 服务内容与规范
知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。
服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。
禁止行为:您在使用服务时不得实施以下行为:
利用技术手段批量爬取、下载、转存知识库内容;
将知识库内容用于商业目的或未经授权地向第三方传播;
干扰本网站正常运行或侵犯其他用户合法权益;
发布违法违规信息或从事违反公序良俗的活动。
四、 知识产权声明
权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。
有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。
侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。
五、 个人信息保护
我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。
您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。
您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。
六、 免责声明
内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。
不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。
第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。
七、 违约责任
如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。
如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。
八、 法律适用与争议解决
本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。
因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。
九、 其他
本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。
本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。
我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。