简介一个基于 RAG 与大模型技术的医疗问答系统完整实践项目面向 AI 大模型应用开发者、医疗信息化从业者及知识图谱与检索增强生成爱好者。项目采用 DiseaseKG 数据集与 Neo4j 构建知识图谱利用 BERT 完成命名实体识别借助 34b 大模型进行意图识别并通过精确的知识检索与问答生成改善医疗咨询场景下的回答可靠性为大模型在医疗领域落地提供了一套可复现的工程方案。资源包共75个文件约84.65MB以 Python 脚本、Jupyter Notebook、JSON/YAML 配置、PNG/JPG 图片以及 TXT 文档为主覆盖数据预处理、知识图谱构建、NER 训练、模型微调和 Web 界面展示等完整环节。包内不仅包含数据增强脚本和 SFT、LoRA、P-Tuning v2 等微调配置还提供了推理代码、运行截图与目录说明能够帮助读者快速理解整个系统链路并动手复现。目前已有839人学习下载适合希望从零搭建医疗 RAG 问答系统、深入掌握知识图谱与意图识别工程实现的开发者。1. 为什么一套带界面的医疗问答系统不只是一台搬文档的聊天机器人解压这套基于 RAG 与大模型技术的医疗问答系统之后第一眼让我改变想法的不是回答有多流畅而是里面同时躺着一套评测集和一个“引用回显”模块。基于 RAG 与大模型技术的医疗问答系统真正的难点从来不是接一个大模型接口而是答完之后能证明自己哪一句来自哪本指南、哪一项用法对应哪份文献。这个项目适合三类人想在企业内部做私有化知识库落地的工程师、医疗信息化方向的开发者以及手里有大量临床指南但不知道怎么把它们变成可查询资产的科室信息员。全文会从项目拆解、本地复现、参数调节、故障排查一直讲到如何建立自己的回归评测确保你拿到手不是只会跑 demo而是能根据自己的语料改出可用的医疗问答基座。2. 拆开 .zip 看 RAG 医疗问答系统的骨架datasets、vector store、LLM 三层怎么分工2.1 先立住普通 RAG再看 Agentic RAG医疗场景的检索链路为什么不能上来就“让模型自己找”普通 RAG 的链路很直白用户问题 → 向量化 → 向量库召回 → 取 top_k 原文片段 → 拼进提示词 → 大模型生成回答。它的优点是每一层都可以检查和回滚为什么召回不到看向量相似度分数为什么答错看提示词里到底喂了什么。医疗问答系统对“证据链”的要求几乎排在第一位所以第一版必须把普通 RAG 跑稳而不是让大模型自由穿梭在多个工具之间。检索增强生成里的“增强”两个字在医疗场景里的含义不是增强发挥而是增强约束。Agentic RAG 这类把检索决策交给大模型的方案适合做多跳推理比如患者主诉“糖尿病合并肾功能不全”时系统需要先查糖尿病指南再查肾功能不全相关的用药禁忌最后把两条指南拼成一个推理链。但 agentic rag 的不确定性也在这里模型决定“下一步调哪个工具”一旦决策路径错了责任很难定位。常见做法是把多跳检索拆成确定性的 pipeline第一跳查什么、第二跳过滤什么都写死在编排代码里等以后评测集足够大、日志足够全再逐步放开让模型规划。也就是说这个压缩包里如果已经有 graphrag 或 ontology rag 的影子它们更适合作为第二阶段增强把药品、疾病、禁忌之间的实体关系建图而不是推翻第一版的线性检索。2.2 一段典型的检索问答代码长什么样向量召回、阈值过滤、引用回显解压后你大概率会看到一个呈三层结构的工程datasets 放原始语料和人工标注的评测集vector store 负责把切好的文档块编码成向量并落盘LLM 这层只做“基于给定材料的生成”。这三层的边界必须清晰否则排查问题的时候会陷入黑匣子。我一般会先找项目的核心查询函数它在项目里通常以query、retrieve或kg_qa命名逻辑结构几乎都是下面这样import numpy as np def answer_medical_query(query: str, top_k: int 20) - dict: # 1. 把用户问题编码成向量注意要和建库时使用同一个 embedding 模型 q_emb embedding_model.encode(query, normalize_embeddingsTrue) # 2. 在 FAISS 索引中检索返回相似度分数和对应的 chunk 编号 scores, indices index.search(np.array([q_emb]), top_k) # 3. 按阈值过滤避免把明显不相关的文本塞给大模型 hits [] for score, idx in zip(scores[0], indices[0]): if idx 0: continue if score 0.45: hits.append({ chunk_id: int(idx), text: docstore[int(idx)], score: float(score) }) # 4. 拼接引用列表和 question让大模型只能基于 hits 回答 prompt build_clinical_prompt(query, hits) answer llm.chat(messagesprompt, temperature0.1) return {answer: answer, citations: hits}这段代码里最关键的两个参数是normalize_embeddings和score 0.45。前者决定相似度计算是余弦距离还是内积建库和查询必须保持一致否则分数分布完全错位后者的阈值不能拍脑袋我习惯先用 50 条真实问题跑一遍检索看命中分数的分布情况再来定阈值常见的坑是阈值设太高导致召回为空大模型只能对着空列表编答案。top_k通常先给 20因为后面的 rerank 阶段还要再筛一轮第一轮宁可多召回一些候选。2.3 评测集里的 hit_rate 到底在算什么先看检索对不对再谈生成好不好医疗问答系统最怕“生成很流畅但检索是错的”。所以这个项目里一定存在一个离线评测脚本用来算检索命中率也就是热搜里反复出现的 rag hit rate。hit_ratek 的定义很简单对于一条测试问题预先标注好“正确答案应该来自哪几个文档块”然后看系统检索出的前 k 个块里是否包含这些黄金块只要包含一个就算命中。def hit_rate_at_k(retrieved_chunk_ids, gold_chunk_ids, k5): retrieved_topk set(retrieved_chunk_ids[:k]) gold set(gold_chunk_ids) return 1.0 if len(retrieved_topk gold) 0 else 0.0 # 一条来自医疗评测集的样本 query 慢性肾脏病患者的二甲双胍剂量是否需要调整 gold_chunk_ids [1024, 1025] retrieved_chunk_ids [1024, 88, 2031, 77, 512] print(hit_rate_at_k(retrieved_chunk_ids, gold_chunk_ids, k5)) # 1.0注意这里用的是 chunk id 而不是文本匹配因为医学指南里同一个知识点可能用不同措辞表达文本匹配会误判。标注黄金块的过程确实耗费人力但它是整个项目能持续迭代的地基。我在做医疗类 rag 项目时第一周通常不碰任何模型参数先把 100 条高频问题逐条映射到指南原文的页码和段落上这份标注表之后既是评测依据也是排查“为什么答错”的线索。3. 在本地把医疗问答跑起来文档切分、向量化、接口生成三段式落地3.1 指南类 PDF 的文本切分用 langchain 按章节边界切不要按固定字数硬切从 zip 里的原始语料看医疗数据大多来自 PDF 版临床指南、药品说明书和专家共识。PDF 抽取后会有大量换行、页码页脚和表格噪声如果不做预处理切出来的 chunk 会一半是目录、一半是正文。我习惯先把 PDF 用 pdfplumber 转成带结构化标记的文本然后交给 langchain 的文本切分器处理from langchain.text_splitter import RecursiveCharacterTextSplitter # 先按 markdown 标题把指南切成大段再在大段内按语义切块 splitter RecursiveCharacterTextSplitter( separators[\n## , \n### , \n\n, \n, 。, ], chunk_size450, chunk_overlap80, keep_separatorTrue, ) chunks splitter.split_text(guide_text) print(len(chunks), chunks[0][:120])切分器的核心参数是separators和chunk_overlap。这里把\n##和\n###放在最前面是为了让“治疗原则”“用药禁忌”这类章节标题和正文待在同一块里chunk_size450不是拍脑袋因为中文医学指南一句话动辄 80150 字一个完整的诊断标准往往要 24 句话才能说清450 字既能装下一段完整描述又不至于让向量检索因为文本太长而稀释语义。chunk_overlap80是必须的它能避免知识点恰好被拦腰切断尤其是药品用法里的“成人一次 0.5 g每 12 小时一次”这类句子如果被切开检索到的块会缺失关键剂量。切分参数适用场景风险chunk_size200药品说明书、条目式问答医学指南里的病因分析被截断chunk_size450临床指南、专家共识需要配合 overlap否则句间逻辑断裂chunk_size1000疾病综述、单篇文献解读混合多个主题检索噪声变大切完一定要抽样打印几个 chunk 人工检查我见过太多项目倒在这一步后续所有调参努力都被糟糕的切分抵消了。3.2 向量化与建库本地优先选 BGE 系列FAISS 落盘后就能脱离原始文档运行医疗文本里专业术语密集泛化 embedding 效果会明显变差。这个项目里如果默认向量模型是 text2vec 或 m3e我建议换成 BGE-large-zh-v1.5它在中文长文本和领域术语上的表现更稳定维度是 1024用 CPU 建索引也不会慢到不可接受。如果你的机器显存只有 8G 左右bge-base-zh-v1.5 也行只是维度降到 768区别体现在长文档的召回精度上。from sentence_transformers import SentenceTransformer import faiss import numpy as np embedder SentenceTransformer(BAAI/bge-large-zh-v1.5) # 注意BGE 系列在编码查询时推荐加上指令前缀建库时不用加 query_instruction 为这个句子生成表示以用于检索相关文章 vectors embedder.encode( chunks, normalize_embeddingsTrue, show_progress_barTrue, batch_size16 ).astype(float32) # 用 IndexFlatIP 配合归一化向量效果等价于余弦相似度 index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) faiss.write_index(index, medical_guide.index) # 用 joblib 或 json 保存 chunk 文本确保编号一一对应这里容易踩坑的是 BGE 的查询指令建库时对文档正文直接 encode查询时要在用户问题前面加上 “为这个句子生成表示以用于检索相关文章” 这个前缀否则线上命中率会比离线评测低不少。normalize_embeddingsTrue必须同时用在建库和查询两侧索引和 docstore 的编号也要保持一致否则会出现“检索回来一个 id但原文对不上”的诡异故障。3.3 生成层把召回片段拼成受限提示词用带温度的本地大模型生成层不需要复杂 prompt 工程重点是设边界。医疗问答的大模型调用可以兼容 OpenAI 格式很多项目默认支持本地部署的 Qwen或者跑一个兼容 API 网关。我一般会先把召回片段按 “参考文档” 的格式拼好再要求模型只能基于参考文档回答并强制输出引用角标。def build_clinical_prompt(query: str, hits: list) - list: context_parts [] for i, hit in enumerate(hits, start1): context_parts.append(f[{i}] {hit[text]}) system_prompt ( 你是一名医疗知识库问答助手。请仅根据参考文档回答问题 不允许使用文档之外的医学知识每条结论后面用 [序号] 标注来源。 如果文档中没有相关信息直接回答“未在指南中找到相关描述”。 ) user_prompt ( 参考文档\n \n.join(context_parts) f\n\n问题{query}\n回答 ) return [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ]这里最关键的不是提示词写得多漂亮而是temperature一定要调低0.1 比较合适。大模型在低温下生成更保守更倾向于使用原文语句。另一个容易被忽略的细节是当hits为空时不要硬拼提示词直接返回“未找到相关资料”给用户一个明确信号而不是让模型自由发挥。我在生产环境的代码里会在这儿打一条 warn 日志方便后续排查是切分问题、向量模型问题还是阈值问题。4. RAG 医疗问答的四个必调参数top_k、score_threshold、chunk_size 与 rerank4.1 chunk_size 直接影响“诊断依据完整性”为什么 256 会切碎知识1000 会混入噪声医疗问答的检索单元是 chunk不是句子。chunk 太小比如 256 字一个“疾病概述 诊断标准 治疗建议”的完整逻辑链会被拆到三个块里向量检索时每块都只包含局部信息召回结果看似相关实则零散。chunk 太大比如 1000 字以上一个块里可能同时包含“适应症”和“不良反应”它们语义权重互相稀释检索“不良反应”时返回的块里有一半内容在讲适应症生成时也会被无关信息干扰。我的经验是先用 450500 字作为基线然后针对自己语料的特点微调。指南类语料段落工整可以稍微放大到 600药品说明书里条目繁复则缩到 300。调 chunk_size 一定要同时观察两组数据hit_rate 有没有上升以及生成回答里的“无用上下文噪声”有没有变多。只看前者容易被大块带来的高召回骗到因为块越大黄金块越容易被包含进去但生成质量反而可能下降。4.2 top_k 和 score_threshold先放宽再收紧避免空召回和噪声并存top_k 和 score_threshold 是一对联动参数。常见错误是只调 top_k不管阈值结果检索回来的 20 个块里有 15 个都是分数低于 0.3 的垃圾片段。另一个极端是阈值设太高比如 0.7在中小型知识库上很容易把有效召回全部滤掉。def retrieve_with_threshold(query, top_k50, min_score0.4, max_return6): q_emb embedder.encode( [query_instruction query], normalize_embeddingsTrue ) scores, indices index.search(np.array(q_emb), top_k) filtered [] for score, idx in zip(scores[0], indices[0]): if idx 0 or float(score) min_score: continue filtered.append((float(score), int(idx))) # 按分数排序只保留前 max_return 个 filtered.sort(keylambda x: x[0], reverseTrue) return filtered[:max_return]这里的思路是第一轮召回放得很宽top_k50保证任何可能相关的块都有机会进来然后用 score_threshold 去掉明显不相关内容最后按分数截断到 max_return6控制喂给大模型的上下文长度。min_score 的初始值可以看索引的分数分布来定跑 30 条测试 query 打印分数直方图取“明显噪声段”的上界作为阈值比凭感觉写 0.5 可靠得多。4.3 加入 rerank 的二阶段检索rerank 拉高的是“答案正确率”不是召回率热门话题里的 rerank 属于二阶段重排在第一阶段向量召回 top_k50 的基础上用 cross-encoder 对每一条候选重新打分。向量模型算的是 query 和 chunk 的整体语义相似度而 rerank 模型是让 query 和 chunk 做深度交互对“问题真正问的那个点”更敏感。医疗文本里专业术语多这种交互式打分带来的提升尤其明显。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-v2-m3, max_length512) pairs [(query, docstore[idx]) for _, idx in first_stage_results] scores reranker.predict(pairs) # 重新排序取前 6 条同时保留原始分数便于日志分析 ranked sorted( zip(scores, first_stage_results), keylambda x: x[0], reverseTrue )[:6]使用 rerank 后score_threshold 可以适当放宽因为错误候选会被第二轮拉低第一轮的目的只是“别漏掉”真正决定最终答案质量的是 rerank 之后的截断。重排器建议只在最后一段使用不要为所有 query 都跑因为 cross-encoder 比双塔向量慢得多。线上如果对响应时间敏感可以用 20 个召回结果做重排而不是 50 个。5. 医疗问答 RAG 避坑指南五个必须提前处理的故障5.1 检索明明命中了原文大模型却给出原文里不存在的剂量现象系统检索出的 chunk 里明确写着“成人每次 0.5 g”但模型回答变成了“每次 0.25 g”。答案读起来很像那么回事核查引用却对不上。原因提示词没有强制“不能超出参考文档”模型在生成时把预训练阶段记住的通用知识混了进来尤其是剂量和禁忌这类高频常识模型非常容易“自由发挥”。解决在 system prompt 里写明“如果你给出的内容不在参考文档中属于违规回答”。并且要求每个结论后面必须带 [序号]在代码层面对模型输出做后校验检查回答中出现的阿拉伯数字和单位是否能在引用的 chunk 中找到。任何找不到来源的药名或剂量都要像防御 sql 注入一样拦下来。5.2 同一药品的通用名、商品名、别名互相检索不到现象用户问“阿莫西林胶囊过敏怎么办”指南里写的是“阿莫西林克拉维酸钾”vector 检索出的关联度很低hit_rate 直接掉到 0.5 以下。原因中文医疗实体存在大量同义不同名的说法embedding 模型并不能理解阿莫西林和它的复方制剂之间的从属关系单纯靠向量相似度扛不住这种实体级语义鸿沟。解决在检索之前加一道 query 改写把用户问题里的常见别名映射到知识库的标准名再做向量化。常见做法是维护一个小型同义词词典比如{阿莫西林: [阿莫西林克拉维酸钾, amoxicillin, 再林]}命中后直接做查询扩张。第一次做不要求覆盖全部药品覆盖高频前 50 个药品就能挽回大半精度。5.3 药品说明书里的表格被文本切分器拦腰切断现象检索“一次 250 mg每日两次”这种用法时返回的 chunk 里只有“250 mg”没有“每日两次”或者剂量和适应症被分到两个块里。原因PDF 里的剂量表格转成纯文本后一行一个单元格RecursiveCharacterTextSplitter 不知道表格在语义上是完整的按换行符切开。解决在 PDF 解析阶段先用 pdfplumber 的表格提取接口把表格整体转成 markdown再把整张表格作为一个不可分割的单元送进切分器。做法是先把表格识别出来转成字符串后临时用特殊占位符包裹切分完成后再恢复或者把separators里的\n去掉强制避免按单行换行切分。5.4 数值检索失效“肌酐 120 μmol/L”和“正常值范围”混淆现象用户问“肌酐 120 算不算高”系统召回回来的内容全是讲慢性肾病分期的没有把化验单数值和正常参考范围对应起来。原因向量检索擅长抓语义不擅长抓精确数值。120 和 125 两个数在向量空间里几乎没距离查询“肌酐 120”和文档里的“上限 115”无法通过相似度直接建立起数值比较关系。解决不要只依赖向量检索加一路 BM25 或全文检索做混合检索把包含“肌酐”和具体数字的句子直接拉出来同时对医学数值做规则解析先判断用户问题里有几个数值再去检索结果里做数值范围匹配。医疗场景用混合检索不是加分项而是刚需。5.5 评测集只有 10 条调参调到过拟合现象在某 10 条内部测试集上 hit_rate 从 0.6 调到 0.9换一批真实问题立刻跌回 0.6。原因测试集太小chunk_size、top_k 这些参数在 10 条样本上很容易被个别样本带偏这不是模型问题而是统计噪声。解决至少准备 80100 条覆盖不同科室的高频问题每条都要有黄金 chunk 标注。调参时先固定 chunk_size 和 embedding 模型只调 top_k 和阈值确认 hit_rate 稳定后再动 chunk_size。改任何一个参数都要重跑完整评测集不要只看你印象里那几条“难问题”。6. 把医疗问答从“能跑”推进到“能用”用 hit_rate 与引用空置率做回归盯梢最后一公里也是最容易被忽略的一步把评测固化到流程里。项目能跑通 demo 只证明管道是通的不能证明答案可依赖。我习惯在工程里加一个eval/regression.py每次改完切分参数或替换向量模型都自动跑一遍评估集输出 hit_rate、引用空置率和上下文精确率。# eval/regression.py 核心逻辑 results [] for item in eval_set: response answer_medical_query(item[query], top_k20) hit hit_rate_at_k( [c[chunk_id] for c in response[citations]], item[gold_chunk_ids], k5 ) citation_null 1.0 if len(response[citations]) 0 else 0.0 results.append({ query: item[query], hit_rate: hit, citation_null_rate: citation_null }) hit_rate_mean sum(r[hit_rate] for r in results) / len(results) null_rate_mean sum(r[citation_null_rate] for r in results) / len(results)引用空置率指的是“检索结果为空导致模型无法回答”的比例。这个指标非常值得盯因为它比 hit_rate 更容易暴露阈值过高或切分丢失问题。我在交付医疗问答项目时给自己定的及格线是 hit_rate5 大于 0.75引用空置率低于 0.05低于这个水平说明知识库的底子还没打好直接上大模型只会放大人眼可见的“一本正经胡说八道”。另一个我坚持做的习惯是让每次线上查询的检索日志落盘存下 query、chunk_id、score、最终回答、是否包含引用至少保留 30 天。排查用户投诉时先看这条日志立刻就能判断是检索没召回、重排选错、还是大模型没有遵循提示词。这个项目真正值钱的部分不是那套 Flask 或 Gradio 界面而是你把医疗语料变成可追溯知识资产的那套流程。先把回归评测跑起来再谈增加 agentic rag 或多跳推理这既是工程顺序也是责任顺序。希望帮到你。本文还有配套的精品资源点击获取