简介基于 RAG 与大模型技术的医疗问答系统完整项目包面向人工智能、计算机相关专业学生及企业开发者可应用于毕业设计、课程设计、项目初期立项或医疗智能问答研究。项目以 DiseaseKG 数据集和 Neo4j 图数据库为核心构建医疗知识图谱利用 BERT 实现命名实体识别、34b 大模型完成意图识别并结合检索增强生成RAG技术让问答结果更准确、可解释改善了大模型在医疗咨询场景下的可靠性与可用性。压缩包共 76 个文件、约 84.65MB涵盖 Python 与 Jupyter Notebook 源码、JSON/YAML 配置、Markdown/TXT 说明文档、CSV 与 NPY 预处理数据以及多张架构图和界面截图目录覆盖数据增强、图谱构建、NER 模型训练、LoRA 微调、WebUI 登录交互等完整链路。目前已有 213 人学习下载附带详细文档、全部测试数据与授权说明项目代码经运行验证并获导师认可适合直接二次开发、快速复用或作为优秀课设/毕设参考。1. 医疗问答为什么必须上 RAG模型背书的诊断没人敢用一个医生把「服用氯吡格雷的患者同时用奥美拉唑有没有药物相互作用风险」抛给通用大模型模型答得头头是道却没有给出任何来源追问「换成泮托拉唑是否更安全」时它顺着上文继续编。这种体验放在通用闲聊场景可以接受放在临床辅助决策里就是事故隐患——医疗问答系统的核心约束不是答得流畅而是每一句结论都能钉在权威来源上。RAG检索增强生成的价值恰恰是把「模型凭记忆回答」替换成「先检索证据再受控生成」用户问题先进知识库检索相关片段作为上下文送给大模型模型只依据这些片段作答并标注引用出处。这套方案适合做院内知识库、患者咨询、药师审方辅助的技术团队落地。资料包里那套文档、代码和数据集本质上就是把四件事教给你做扎实知识库构建、检索调优、生成约束、评估回归。拿到这种打包资料我习惯先按文档、代码、数据三个目录归置好再跑最小链路而不是上来就动模型。2. 医疗 RAG 的架构与知识库构建从临床文档到可检索的向量库2.1 医疗场景下的 RAG 链路为什么不能照抄通用问答通用 RAG 的链路看起来很简单文档解析、文本切分、向量化入库用户提问时检索 top_k 片段拼进提示词大模型生成答案。这套流程在客服问答、政策解读里能跑通直接搬进医疗场景却会被打回来因为医疗问答有三个通用 RAG 不关心的约束。其一是来源权威性。通用问答引用一篇博客、一条论坛帖无伤大雅医疗答案的引用必须指向临床指南、药品说明书、专家共识这类权威文档而且版本要对得上。其二是答案可追溯。医生和药师拿到一个答案第一反应是「这句话出自哪里、哪一年发布、哪个机构发布」没有元数据支撑就没法做审核。其三是责任边界。模型在通用场景可以自由发挥医疗场景必须能说「不知道」必须能拒绝回答知识库覆盖不到的问题。所以医疗 RAG 的组件选型会明显偏向可解释、可审计的方向我一般按下面这张表去定初始方案组件医疗场景倾向理由文档解析版面分析 OCR而非直接抽文本临床指南多为扫描 PDF、双栏排版文本切分按标题层级切分而非固定窗口医疗证据以「章节」为语义单元Embedding通用中文模型先跑基线必要时领域微调医疗术语密集通用模型有上限向量库Qdrant / Milvus支持 payload 过滤按年份、文档类型、机构做过滤检索检索混合检索BM25 向量 重排商品名/通用名、缩写词光靠向量不稳生成模型Qwen / GLM / Llama 等可私有化部署的模型患者数据不出院内网部署是硬约束这个阶段容易犯的错是追新技术。看到 agentic RAG 火就去上智能体编排看到 GraphRAG 就去做实体图谱。医疗问答第一步应该先把朴素 RAG 的检索质量做扎实让答案有稳定出处再谈多跳推理和工具调用。知识库里的实体关系药物相互作用、疾病合并症确实是 GraphRAG 的用武之地但那是后话不是地基。2.2 文档解析与切分把 PDF 变成能检索的“证据碎片”医疗知识库的原料来源很杂临床指南 PDF、药品说明书、医院内部操作规程、医学教材、检验手册。每种格式的坑不一样。PDF 分两类处理。文本型 PDF 直接解析扫描型必须走 OCR否则检索出来的是一堆乱码。双栏排版的指南要先做版面分析把左右栏还原成正常阅读顺序不然切出来的片段是「左半句 右半句」拼接的怪文本。表格是单独的难题转成纯文本后结构信息会丢失我一般把表格单独识别出来转成 Markdown 表格或 JSON 结构再入库这一条后面避坑章细说。切分策略是关键。固定按 512 个 token 硬切会把一个完整的「治疗原则」拦腰截断——上半段在 chunk 42下半段在 chunk 43。检索时如果只有 chunk 42 被命中模型看到的证据是不完整的答案自然偏。医疗文档应该按标题层级切分一个章节、一个条目作为语义单元超长的章节再按句子边界二次切分并带上前后重叠。我常用的切分逻辑是这样# 按标题层级切分而不是固定 token 数硬切 import re def split_by_heading(text: str, max_chars: int 1500) - list[dict]: # 用正则识别第X章 / X.X / 一这类标题行作为切分锚点 heading_pattern ( r^\s*(第[一二三四五六七八九十百千0-9][章节部篇] r|[0-9](?:\.[0-9])*\s\S{2,20} r|[一二三四五六七八九十]) ) lines text.splitlines() chunks [] current {title: , content: []} for line in lines: # 遇到新标题且当前小节已有内容时先落盘再开新小节 if re.match(heading_pattern, line.strip()) and current[content]: chunks.append(assemble_chunk(current)) current {title: line.strip(), content: []} else: current[content].append(line) # 小节太长时按句子边界二次切分保留 200 字重叠避免断句 joined .join(current[content]) if len(joined) max_chars: split_long_chunk(chunks, current, overlap_chars200) if current[content]: chunks.append(assemble_chunk(current)) return chunksassemble_chunk 的职责是把标题路径和正文拼成一个完整片段并把片段元数据文档 ID、章节路径、页码标记好。split_long_chunk 是处理超长小节的兜底找到最后一个句号或分号的位置切断下一段从切断点往前推 200 字开始保证「药物用法」这类跨切分点的句子不会被截掉一半。这两个函数不难写但切片质量直接决定后续检索上限值得先花时间写好。overlap 参数我一般取 200 到 300 字符。太短兜不住跨段语义太长会让同一段内容在多个 chunk 里重复出现检索时互相干扰重排阶段还会出现多个相似片段挤占名额。max_chars 控制在 1200 到 1800 字符之间比较合适超过这个长度一个片段的向量语义会被稀释低于 800又容易碎片化。2.3 元数据与入库给每个片段贴上来源标签医疗 RAG 的引用必须精确到「哪份文档的哪一章哪一页」所以入库的每个 chunk 都要带完整元数据。我设计 payload 时至少包含这些字段字段示例用途document_idguid_2023_antithrombotic关联原始文档title抗栓治疗临床指南答案里展示来源chapter_path第三章 抗血小板药物 相互作用定位到具体章节page_start / page_end42 / 43纸质溯源knowledge_typeguideline / instruction / textbook按类型过滤publish_year2023版本筛选与加权is_activetrue / false控制新旧版本是否参与检索没有这套元数据引用溯源就是空话。模型给了一个编号你顺着编号找不到原文审核就卡住了。入库这一步的代码其实很薄核心是向量化和写库# 向量化并写入 Qdrantpayload 里带全量元数据 from qdrant_client import QdrantClient from qdrant_client.models import PointStruct, VectorParams, Distance client QdrantClient(urlhttp://localhost:6333) client.recreate_collection( collection_namemedical_kb, vectors_configVectorParams(size1024, distanceDistance.COSINE), ) for chunk in chunks: vector embed_model.encode(chunk[text]) # 示例bge-m3 输出 1024 维 client.upsert( collection_namemedical_kb, points[PointStruct( idchunk[id], vectorvector.tolist(), payloadchunk[metadata], )], )维度数必须和嵌入模型对齐bge-m3 是 1024 维换成别的模型要先重建集合。距离度量我固定用 Cosine文本语义检索场景它比 L2 稳定对向量模长不敏感。到这里rag 知识库的地基才算打好——之后所有检索实验都在这套数据上跑。向量库选型要贴合部署环境。院内内网部署是硬约束Qdrant 和 Milvus 都能离线跑数据量在几十万片段以内 Qdrant 单机足够更轻的场景用 Chroma 或 SQLite-VSS 也能顶住省去运维一个独立服务的成本。别一上来就上分布式医疗知识库的体量通常到不了那个规模。3. 检索链路实战Embedding 选型、向量库参数与重排策略3.1 Embedding 选型通用模型还是领域微调检索质量的上限由 embedding 决定这句话在医疗场景尤其成立。医疗文本术语密集药品有商品名、通用名、化学名疾病有学名、俗称、缩写同一个概念在不同文档里的表达方式可能完全不同。我的选型路径是先跑基线再决定要不要微调。基线阶段用 bge-m3 这类通用中文 embedding 模型把整套链路跑通记录 hit rate。如果检索命中率明显偏低且失败案例集中在术语匹配上——比如用户问「波立维」知识库里写的是「硫酸氢氯吡格雷」——再考虑用标注数据做领域微调。不建议一上来就微调因为标注数据本身需要成本而且微调前的基线能帮你判断问题到底出在 embedding 还是切分还是检索策略。模型维度中文医疗术语表现适用阶段bge-m31024通用尚可商品名/缩写易失配基线首选text-embedding-v31024通用较强长文本稳定基线备选领域微调模型按底座术语对齐明显提升基线不达标后一个重要的参数细节bge-m3 在检索时建议给 query 加上「为这个句子生成表示以用于检索相关文章」这类指令前缀否则效果会有几个百分点的波动。这个点很多人会忽略属于白捡的分数。3.2 向量库与相似度度量chunk_size、top_k 怎么定向量库层的参数看似简单实际影响很大。以 Qdrant 的 HNSW 索引为例有两个参数要调明白ef 控制查询时探索的候选节点数量值越大召回越全但延迟越高m 控制每个节点的连接数建索引时定死影响内存占用和召回。我的经验是数据集在十万级以下ef 从 64 起步调到 128 就够m 默认 16不需要动。chunk_size 和 top_k 要联动调。chunk 越大单个向量承载的语义越杂检索精度下降chunk 越小片段越碎片化上下文不完整。医疗场景我建议从 1200 字符起步配合重排使用。top_k 不是越大越好top_k 取 5可能漏掉正确答案所在片段取 50又会在生成阶段塞入大量无关上下文干扰模型判断。我通常把检索拆成两段召回阶段 top_k 取 30 到 50重排后取 5 到 8 送给大模型。这组参数要按你自己的知识库跑实验确定没有通用最优值。下面是两组常见参数组合的对照来自我跑过的类似项目chunk_sizeoverlap召回 top_k重排后取现象500100205术语类问题命中尚可跨段结论经常答错1200200508召回更全重排后答案完整性明显提升2000300508片段过长稀释语义部分问题命中率下降3.3 混合检索与重排把命中率从 60% 提到 85% 的调参实验纯向量检索在医疗问答上有两个明显的短板。第一专有名词精确匹配不如关键词用户问「低密度脂蛋白偏高怎么办」向量检索可能召回「高密度脂蛋白」的相关段落因为两者语义接近。第二商品名与通用名的映射问题向量模型可能知道「波立维」和「氯吡格雷」意思接近但「立普妥」和「阿托伐他汀」这种组合未必都认识。常见的补救方案是混合检索BM25 做关键词精确召回向量做语义召回两者用 RRF倒数排名融合合并再用重排模型精排。这样商品名、化学名、缩写都能被关键词路召回而语义相近的表述被向量路召回两条路互补。# 混合召回向量语义召回 BM25 关键词召回RRF 融合排序 def hybrid_search(query: str, top_k: int 50): vec_hits vec_index.search(query, top_k) # 向量召回 kw_hits bm25_index.search(query, top_k) # 关键词召回 # RRF 融合score Σ 1/(k rank)k60 是常见保守取值 fused reciprocal_rank_fusion(vec_hits, kw_hits, k60) return fused[:30] # 30 条交给重排模型精排RRF 的 k 参数取 60 是有原因的k 越小排名靠前的文档权重越大融合结果越激进k 越大两条召回路的排名差异被抹平。60 是一个折中值不会让某一路的结果完全主导。召回之后接重排。我用 bge-reranker-v2-m3 这类交叉编码器模型把「query 片段」拼起来打分比向量相似度准得多。重排后的 top 5 到 8 条才真正送进大模型上下文。重排这个环节容易被忽略但它对最终答案质量的影响经常比换一个大模型更明显。我见过不少项目检索 hit rate 只有 60% 出头加了混合检索和重排后直接拉到 85% 以上。这一步调好之前不要在生成端投入太多精力——上下文里没有正确答案提示词写得再好也白搭。4. 生成端调优提示词结构、引用溯源与幻觉兜底4.1 提示词模板让模型只读材料、不许脑补检索做扎实之后生成端的核心任务是约束。通用对话里模型的自由发挥是优点医疗场景里是风险。提示词要解决三件事让模型只依据给定片段作答、让答案可溯源、让模型敢于拒答。我用的系统提示词骨架是这样的SYSTEM_PROMPT 你是医疗问答助手。回答时严格遵守以下规则 1. 只能依据 参考资料 中给出的片段作答禁止使用外部记忆补全。 2. 每个结论后标注引用编号格式如[1][2]编号对应参考资料顺序。 3. 若参考资料不足以回答问题直接回复“当前知识库资料不足请咨询临床医生”不要编造。 4. 涉及用药剂量时同时给出服用方式、疗程与注意事项中的原文关键句。 5. 不要输出免责声明之外的自行解读不要给出个人意见。 规则 2 和规则 3 是关键。引用编号让审核方可以逐条核对答案来源拒答规则堵住了幻觉最大的来源——模型「觉得自己知道」。参数上temperature 要调到 0.2 以下采样随机性越强答案越不稳定医疗场景经不起这种抖动。如果生成模型支持 JSON 输出格式建议开启方便后处理解析答案和引用编号。4.2 引用溯源实现答案里的 [1][2] 是怎么接上的提示词要求模型带引用编号但模型生成的编号未必可靠——它可能引用了一个与结论不符的片段甚至编造一个不存在的编号。这是大模型的黑匣子问题不能信必须校验。我一般会在生成后加一道引用校验def validate_citations(answer: str, source_chunks: list[dict]) - dict: # 正则取出 [1][2] 这类编号 used_idx set(int(x) for x in re.findall(r\[(\d)\], answer)) valid {i for i in used_idx if i len(source_chunks)} # 编号越界或引用缺失时标记为引用不可靠 missing used_idx - valid return {valid: not missing, used: sorted(valid), missing: sorted(missing)}校验不通过时我的处理策略是整段答案走拒答兜底而不是删掉某一句话。因为模型一旦开始编编号说明它没有真正依据片段作答这种情况下局部修补不如直接拒绝。宁可让用户觉得系统笨也不能让医生拿到一个出处对不上的答案。4.3 知识版本与更新新旧指南冲突怎么办医疗知识有时效性临床指南定期更新药品说明书会修订而旧版不能直接删——历史诊疗记录可能引用旧版标准患者可能还在用旧方案。所以知识库是「版本共存」的不能简单覆盖。我在元数据里加了 publish_year 和 is_active 两个字段。检索时优先 is_activetrue 的片段旧版本只在特定场景比如用户明确问「2020 年版指南怎么写的」才参与召回。同主题的新旧片段都命中时提示词里要明确「以下引用包含不同版本指南答案以最新版本为准」避免模型把旧版和新版混在一起答。知识库更新本身要按版本走新数据先写入新 collection验证检索效果后再切换线上流量而不是在原 collection 上边删边写。这种版本化发布方式在踩坑章里还会再提——更新后旧答案还在是医疗 RAG 上线后最容易踩的坑之一。5. 医疗 RAG 避坑排查检索不到、答非所问与数据污染5.1 现象医生问“波立维和泰嘉能不能互换”检索结果为空原因知识库里写的是「硫酸氢氯吡格雷」用户用的是商品名「波立维」和「泰嘉」。向量模型没有把商品名和通用名对齐BM25 关键词检索也完全无法匹配。这是医疗场景典型的术语鸿沟问题。解决维护一张同义词映射表把商品名、俗称、缩写映射到标准通用名。查询进入检索引擎前先做一次 query 改写识别出「波立维」→「硫酸氢氯吡格雷」再把改写后的 query 同时送进向量检索和 BM25。同义词表不用一开始做全从检索日志里挖失败案例逐步补。5.2 现象检索命中了正确片段模型却把剂量答错原因送进上下文的多个片段来自不同文档其中规格、年份、适用人群不一致模型在拼接时把不同片段的剂量信息混用了。例如片段 A 写「成人 75 mg 每日一次」片段 B 写「老年患者 50 mg 每日一次」模型可能把老年患者的答案答成 75 mg。另一个诱因是 temperature 偏高生成结果随机性大。解决提示词里显式声明「若多个片段信息冲突以最新版本指南为准」并在送入上下文时按 publish_year 降序排列。temperature 压到 0.2 以下。对剂量、频次这类关键信息我还会在生成后加一道规则校验——正则提取答案中的剂量表述与知识库原文做一致性比对不一致就拒绝。5.3 现象同一个问题隔一天问得到了不同的答案原因这是最典型的检索不稳定问题。HNSW 索引的 ef 参数过低召回结果抖动向量检索本身有随机性重排模型的输出也会随候选集变化波动大模型采样更增加了不确定性。四个环节叠在一起答案自然不稳定。解决固定检索参数ef 调到 128 以上重排后按分数二次排序保证确定性temperature 设为 0。对高频常见问题如「某某药的用法用量」我会加一层答案快照缓存命中缓存直接返回既稳定又省算力。5.4 现象肾功能分期、药物剂量表这类表格内容怎么检索都查不准原因PDF 解析把表格转成纯文本后行列结构丢失表头和内容被拆成两段。切分时表头可能落在一个 chunk数据行落在另一个 chunk检索时只命中其中一半模型看到的是没有表头的裸数据根本理解不了。解决表格单独走结构化解析。把表格转成 Markdown 表格或 JSON按「表头 行内容」重组语义单元再入库。切分规则对表格网开一面不做普通文本的标题切分。检索时如果检测到 query 包含「剂量」「分期」「用量」这类表格型意图可以优先匹配结构化片段。5.5 现象知识库更新了一周老答案还在线上返回原因最常见的原因是向量集合没有重建新数据还没真正生效其次是答案缓存没有失效用户命中了旧快照再有一个隐蔽原因是新旧版本同时被检索旧版本权重没降。三件事叠在一起线上表现就是「改了个寂寞」。解决发布流程固定为新数据入新 collection → 跑回归测试 → 切换检索指向 → 清空缓存。缓存 key 必须带知识库版本号。检索时按 publish_year 加权旧版本片段降低排序分数而不是完全排除——防止用户明确问历史版本时找不到。5.6 排查工具把检索链路完整记到日志医疗问答系统上线后最痛苦的事是「用户说答案不对但不知道哪一环错了」。没有检索日志排查只能靠猜。我在系统里固定输出一条结构化检索日志字段如下字段内容query用户原始问题normalized_query改写/同义词映射后的问题recall_hits召回阶段 top 50 片段 ID 与分数rerank_hits重排后 top 8 片段 ID 与分数context_sources实际送入模型的片段来源文档、章节、年份answer模型输出citation_result引用校验通过/失败这条日志是知识库迭代的唯一依据。哪个问题检索不到、哪个问题引错来源、哪些 query 频繁触发拒答全部从这里看。医疗 RAG 没有这条日志优化就是盲人摸象。6. 上线前如何验证hit rate、忠实度与回归闭环6.1 先测检索再测生成两个指标分开盯检索质量和生成质量要分开评估混在一起看会把问题搞糊涂。检索侧看 hit rate正确答案所在片段是否出现在召回结果里。生成侧看忠实度答案的每个断言是否都能被参考资料支撑我通常按 1 到 5 分人工打分3 分以下算失败。这两个指标分开记录才能定位问题出在召回还是生成。6.2 用固定测试集做回归五十条问题跑一个晚上固定测试集是这套系统的后悔药。我从药物相互作用、适应症、禁忌症、剂量、患者教育五类问题里各抽 10 条凑 50 条固定标注集每个版本更新后都跑一遍完整回归。hit rate 掉了就看是新文档挤掉了旧文档还是 embedding 更新引入了偏差忠实度掉了就翻检索日志看上下文里到底送了哪些片段。我自己的习惯是每个版本上线前先跑这 50 条回归对比上一版指标检索日志保留三个月。医疗问答最怕的不是模型不够聪明而是引错来源还引得很流畅等用户发现时已经产生了信任损伤。这套回归闭环能拦住大部分问题希望帮到你。本文还有配套的精品资源点击获取