简介基于检索增强生成与大模型技术的医疗问答系统毕业设计源码包面向计算机、人工智能、自动化等专业学生及从业者可用于课程设计、大作业或毕设解决医疗知识问答中的检索与生成结合问题。包内共七十五个文件含 Python 源码、Jupyter 微调解析脚本、医疗实体关系数据、配置与说明文档、界面截图等压缩包整体约八十四点六五兆字节目录覆盖模型微调、命名实体识别、知识图谱构建、问答界面登录等模块。目前已有三百七十八人学习项目为个人毕设且答辩评审达到九十八分代码经过调试可运行。资源附有详细文档说明和全套数据可看到基于 ChatGLM 的 LoRA 微调、医疗命名实体识别、Neo4j 图谱构建与问答界面实现流程适合学习完整落地路径也可在基础上扩展功能。1. 医疗问答系统为什么不能直接裸奔大模型把开源大模型部署好、接上知识库就跑医疗问答是拿到这类项目标题后最容易踩进去的第一个坑。裸奔的大模型面对“高血压患者能不能吃柚子”这类日常问题看上去答得头头是道实际上问题出在两个方面一是幻觉模型会用流畅的句子编造不存在的药品相互作用二是知识时效性预训练阶段的知识截止日期决定了它根本不认识去年才获批的新药。医疗场景里这两个问题任何一个落到真实问询上都是不可接受的所以标题里才会出现 RAG 这个词——它解决的不是“能不能问答”而是“如何让回答有出处、有依据、可追溯”。一套完整的 RAG 医疗问答系统对毕设和工程化落地的价值都在于它把“大模型会编”收敛成“大模型只能在我给它的医学资料范围内说”并且每一条答案都能回指到原文片段。这套链路对新手友好的地方在于每个环节都可以独立替换——知识库可以换成科室资料向量模型可以换成开源的嵌入模型大模型可以走本地部署也可以接 API。整篇文章我们按照“系统怎么拆 → 检索怎么串 → 生成怎么控 → 全程哪翻车 → 怎么验证”的顺序走把每一层的参数和踩坑讲透。2. 先拆系统的四层架构医疗 RAG 的骨架长什么样2.1 数据层医疗问答的地基是知识库切片不是堆文件医疗 RAG 和通用 RAG 最大的区别在知识库的构造方式上。通用场景把 PDF 和网页抓下来切块就能用医疗场景不行因为医学资料对上下文极其敏感——“空腹服用”和“饭后服用”差一个字答案就完全变了检验单上的参考区间通常是连续文本里的一个片段切块切不好就会把“正常值 3.5-5.5”和后面的“异常提示”切成两个独立片段检索时找到一半生成就是错的。我一般会把数据层拆成两级。第一级是原始资料库保留完整的文档结构PDF 按章节、表格、临床指南的条目做结构化解析第二级是切片索引库从原始资料里按语义边界切出检索单元。这里要特别注意切片的粒度不是越小越好from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.schema import Document # 医疗资料切片不是固定字符数硬切而是按标题/段落/句号分层 text_splitter RecursiveCharacterTextSplitter( chunk_size300, # 每片控制住 300 字符附近太长命中不精确 chunk_overlap50, # 相邻重叠 50 字符保住跨片语义 separators[\n\n, \n, 。, , ,] # 中文医疗文本优先按句末符号切 ) doc Document(page_content药品说明书阿托伐他汀钙片口服常用起始剂量为10mg每日一次……) splits text_splitter.split_documents([doc]) for idx, chunk in enumerate(splits): print(f切片{idx}: {chunk.page_content})chunk_size 和 chunk_overlap 这两个参数在医疗场景里没有标准答案但有一个实用经验问诊类问题切 200-400 字符指南类长文本可以放宽到 500-800。太短会丢约束条件太长会把多个适应症混进一个切片里。separators 的排序也很关键中文语料里必须把句号放在英文逗号前面否则长段落会被切得稀碎。数据层做完下一步动作是清洗。医疗资料里经常混着排版产生的孤立页码、目录页的重复标题、表格里的空单元格这些脏数据直接进入索引库会让检索结果里混入大量噪声。清洗用正则按行筛一遍把“第 X 页 / 共 X 页”、连续重复的章节标题、纯数字行过滤掉这步别省。2.2 增强层查询改写与意图识别决定 RAG 是助手还是复读机医疗问答的另一个独特之处是用户提问口语化、信息不完整。普通用户会问“我头晕该挂哪个科”“这个药和降压药能一起吃吗”但知识库里的内容是书面化的“头晕可见于耳石症、体位性低血压、颈椎病等多种情况。”这两种文本之间存在巨大的语义鸿沟直接用原始 query 去向量库里做相似度检索命中率会惨不忍睹。常见做法是在检索之前加一层查询改写也叫 query rewriting再把改写后的结果送进检索器。一套轻量的改写策略包括两步from langchain.prompts import PromptTemplate from langchain.llms import OpenAI # 可按需替换成本地部署的 Ollama / vLLM 服务 rewrite_prompt PromptTemplate.from_template( 你是一个医疗检索助手请把用户口语化、信息不完整的问题改写成适合检索书面医学资料的查询语句。 规则 1. 保留原始问题的关键症状和药物名称不新增未提及的诊断结论 2. 将口语表述转换为正式的医学术语如“头晕”改为“头晕/眩晕症状鉴别” 3. 如果问题包含药物标注药物通用名 【原始问题】{question} 【改写后的查询】 ) def rewrite_query(question: str) - str: llm OpenAI(temperature0, max_tokens100) chain rewrite_prompt | llm return chain.invoke({question: question}).strip()改写这一步的核心约束是 temperature 必须设为 0让输出尽量确定max_tokens 控制住 100 token 以内避免改写语句冗长膨胀。另一个容易被忽略的点是改写不应该做“诊断扩展”——用户说自己头痛可以直接改成“头痛病因排查”但不能扩展成“脑瘤头痛”那是幻觉的前兆。改写后的文本仍然要回到检索流程里和原始 query 并行检索最后合并结果去重排名这比只改写不保底要稳得多。2.3 检索与重排向量检索 关键词召回 重排器的组合拳医疗领域有一个很反直觉的现象向量相似度很高语义上未必相关。“肝功能异常”和“肝囊肿”向量距离可能比“肝功能异常”和“转氨酶升高”更近因为两个词都带“肝”。这就是为什么纯粹依赖向量检索的 RAG 在医学上不够用的原因。这个标题下的系统检索层至少得是三路召回的组合向量检索负责语义扩展BM25 负责字面精确匹配重排器负责把两路结果按相关性重新排序。我一般用 Elasticsearch 同时扛关键词和向量的混合检索再做一次交叉编码器重排。流程是先向量召回 Top 50BM25 召回 Top 50合并去重后交给 bge-reranker 这一类的交叉编码器模型打分取 Top 5 进上下文。止损点在召回阶段单路召回 Top 10 看起来快但医疗术语的电气化表达太严重少了另外一路直接漏检。参数上向量检索的 top_k 我通常取 50 到 80重排后的 top_n 取 3 到 5既保证上下文不长到稀释注意力又有足够余量覆盖漏检。2.4 大模型层上下文装配与输出约束把答案按进“护栏”里RAG 系统的上下文窗口是有限的把重排后的 Top 5 切片全部塞给大模型并不明智。切片太多会让模型注意力分散回答里反而混入不相关切片的信息。一个更可控的拼装策略是“主证据 辅证据”结构# 检索结果按重排分数降序排列第一片作为主证据完整保留其余作为辅助材料 def build_context(ranked_chunks: list, max_len: int 2000) - str: context [] used_len 0 for idx, item in enumerate(ranked_chunks): text item[text] if idx 0: # 主证据不受长度压缩限制但要保证关键段落完整 context.append(f[主证据]\n{text}) used_len len(text) elif used_len len(text) max_len: context.append(f[辅助材料{idx}]\n{text[:300]}) used_len 300 else: break return \n\n.join(context)context 拼好后Prompt 也要做结构约束必须在系统提示里明确告诉大模型三件事只能引用给定材料中的信息、材料里查不到就明确说查不到、不要把不同材料的信息强行缝合。输出侧我建议加一层 JSON 结构化约束把答案、依据引用、置信度分开返回这样前端展示时可以直接把引用标出来。大模型选型上本地部署优先考虑 7B-14B 量级的中文医学指令微调模型如果走 API 则更省事但要注意上下文长度和系统提示词对输出的影响。上下文长度在这里是个关键参数——设置得太短放不下完整主证据太长又拖慢首 token 速度一般上下文集装后控制在 2000 到 3000 字是性价比较高的区间。3. 把链路跑通从零搭建一个最小可用的医疗 RAG 问答3.1 最小系统骨架四个文件组成一个可以交差的工程这个标题里的“源码”落到实际工程里最小可复现的骨架应该包含四个模块数据导入脚本、索引构建脚本、问答接口脚本、配置项。很多人刚开始会去看复杂的 RAG 框架、LangChain 全家桶实际上跑通闭环不需要那么多依赖。先把最小链路搭起来再换组件才是符合工程节奏的做法。# config.yaml 核心参数示意 embedding_model: BAAI/bge-large-zh-v1.5 # 开源中文向量模型显存要求低 chunk_size: 300 chunk_overlap: 50 retrieval: top_k: 50 # 粗召回数量 rerank_top_n: 5 # 精排后进入上下文的切片数 llm: model_path: /models/chatglm3-6b # 本地模型路径也可换成 API temperature: 0.1 max_tokens: 512参数文件独立出来的意义在于毕设答辩时你能对着参数讲清楚为什么这么配而不是临时改代码。embedding 模型选 bge 系列是因为中文医学文本上的表现比同体量的其他模型稳定显存占用也比较能接受temperature 在医疗问答里必须压低0.1 到 0.3 之间再高就开始出现创造性表述了。索引构建的代码我一般会做两个版本——一个开发版用小批量数据快速迭代一个正式版全量跑。批量构建向量索引用 FAISS 还是 Elasticsearch 都不重要重要的是必须做增量更新设计医疗知识库会持续补充资料每次全量重算索引在数据量大时成本很高。增量更新的常见做法是给每个文档切片生成一个 doc_id 哈希新资料进来先比对哈希集合只重建新增和变更的部分。3.2 检索接口的实现Top K 与相关度阈值怎么一起用检索接口是整个系统里最容易调出效果差异的地方。很多现成的 demo 只给你 top_k 一个旋钮实际生产里还要有相关度阈值——低于阈值直接不返回。医疗场景宁可答不上来也不能给个不相关切片硬凑答案。我这里一般设定双阈值粗召回的分数阈值放宽精排分阈值收紧。from elasticsearch import Elasticsearch es Elasticsearch(http://localhost:9200) def hybrid_search(query: str, top_k: int 50, min_score: float 0.35): # 向量检索用 dense_vector 字段做余弦相似度 vec embed(query) vector_body { knn: { field: content_vector, query_vector: vec, k: top_k, num_candidates: 100 }, _source: [doc_id, text, source] } vector_res es.search(indexmedical_kb, bodyvector_body) # 关键词检索BM25 精确命中术语 keyword_body { query: {match: {text: query}}, size: top_k } keyword_res es.search(indexmedical_kb, bodykeyword_body) # 合并去重 重排 combined merge_and_rerank(vector_res, keyword_res, query, min_score) return combined[:5]代码里的 num_candidates 是 HNSW 索引的搜索候选数比 k 大几倍设太小会牺牲召回率。min_score 的取值跟你用的 embedding 模型强相关不能照抄——bge 的分数分布和别的模型不一样建议先抽样 200 个问题看分数分布再定阈值。merge 阶段要处理同一 doc_id 出现在两路结果里的情况按重排分取高值去重。3.3 生成接口流式输出与引用标注问答接口的设计要注意两个细节超时控制和流式输出。直接同步返回大模型的完整输出在慢模型上体验很差不算大问题真正的问题是请求超过网关超时时间后用户端直接断开模型还在算。所以我一般把问答接口设计成异步任务或者是 SSE 流式返回同时加上进程级的超时兜底。# 流式返回答案 引用标注 async def answer_question(query: str): rewritten rewrite_query(query) chunks hybrid_search(rewritten) context build_context(chunks) prompt assemble_prompt(query, context) async for token in llm.stream(prompt): yield token refs [{source: c[source], snippet: c[text][:80]} for c in chunks] yield f\n\n【参考来源】\n \n.join(f{i1}. {r[source]} for i, r in enumerate(refs))引用标注在 RAG 医疗系统里不是可选项。让答案中的关键论断对应到具体资料来源是判断系统可不可信的核心环节。实现上不需要模型自己找引用——直接标记检索返回的 Top 5 切片即可生成的提示词里要求模型在句末用 [1] [2] 这种编号指向对应材料。输出端再做一道格式化把编号映射成来源链接或原文片段。3.4 效果验证别用三个例子论文就写完了验证的时候我习惯准备三类测试集高频常见问题集、边界冷门问题集、对抗性问题集。高频集从真实问诊记录里整理边界集包含“某种罕见药能否与常见药同服”这类知识库里没有完整记录的对抗集是故意构造的知识库冲突问题——比如两篇文献说法不一致时系统能不能判断冲突而不是硬缝合。没有这三类数据参数的调整就全凭感觉。评估指标上召回率看 RAG 的命中质量回答的相关性可以先用大模型打分再把分数人工抽检这一层在毕设里是加分项在工程里是验收底线。4. 医疗 RAG 的避坑指南五条翻车记录与排查思路4.1 切片切断了用药关联回答缺前提条件现象回答“阿托伐他汀可以空腹吃”时没给出“与葡萄柚汁同服需间隔 4 小时”这个关键提示但知识库原文里是有的。原因原文里“用法用量”和“药物相互作用”是两个相邻但独立的段落切片边界正好把一句完整的跨段落在中间分开了重排后上下文里只保留了包含主要答案的那个切片前提条件那个切片被截断。解决第一切片时对药物说明书这类半结构化文档优先按“适应症/用法用量/不良反应/相互作用”等固定标题分块不要用通用分隔符一刀切。第二在构建上下文时检查检索结果的来源字段同一个来源 doc_id 下的切片尽量不做横向切割一起送进去。4.2 检索分数很高回答却驴唇不对马嘴现象问“儿童感冒可以用阿司匹林吗”检索出的切片是“成人使用阿司匹林注意事项”向量距离还很近。原因向量模型把“感冒”和“阿司匹林”的语义相关性拉近了但完全没有捕捉到“儿童”这个限制条件。向量检索本质是语义相似度不是逻辑约束检索年龄段、禁忌人群这类否定约束经常被忽略。解决在查询改写阶段显式提取约束条件把问题改写成“儿童 感冒 阿司匹林 禁忌”。同时关键词路召回在“禁忌”“禁用”“儿童”这类词上做加权。如果知识库里确实有儿科相关切片但没召回检查是否漏了关键词分词。4.3 上下文装太多切片模型被无关信息带偏现象某一轮回答频繁出现“综合以上信息”这样的模板式开场然后生成了四条左右不搭边的建议。原因Top 5 切片里有两三个相关性不够但构建上下文的代码没有做阈值过滤照单全收。大模型在信息矛盾时会选择“和稀泥”。解决在 build_context 阶段加过滤条件重排分低于阈值的切片直接丢弃宁缺毋滥。另一个补偿技巧是对排名的前两片做完整保留后面几片做截断让模型明显感知到哪条是主要证据。医疗场景下 3 片高质量上下文的效果通常好过 5 片中掺了 2 片噪声。4.4 系统跑得慢卡在重排器现象本地部署的重排模型单个 query 就要 300 毫秒并发高一点直接把 API 拖到超时。原因交叉编码器重排模型需要把 query 和每条候选文本拼起来过一遍 Transformer复杂度是 O(N)候选越多越慢。解决不能省重排的前提下做两级加速。第一级把粗召回分数很低的直接过滤掉不让它们进重排器第二级给重排模型单独做并发池调节批大小。如果只是毕设演示可以把重排的候选数从 50 压到 30延迟能掉下来不少效果损失在医疗术语强场景里通常不明显。4.5 大模型把知识库没有的信息补全了现象知识库里只有药品说明书用户问“这种药孕妇能不能吃”回答里出现“孕妇禁用”字样但说明书原文根本没有孕妇相关条目。原因提示词约束太弱。“根据以下资料回答”这类措辞对模型约束力不强模型会靠预训练知识补全。解决提示词里必须加一条否定指令“如果给定材料未提及相关内容必须回答‘未在资料中找到依据建议咨询执业医师’不得自行补充”。这个约束在医疗场景直接决定系统的安全底线。另一个更硬的手段是用输出解析器校验答案检查回答中关键实体是否在检索切片中出现过没出现的标记为低置信度。5. 再往前走一步评估体系、结构化知识补强与私有化部署5.1 用自动化评估集替代“感觉答得不错”我最后会给这个系统加一个离线评估脚本它的价值是让你在调参之后能客观知道效果是提升了还是退化。脚本流程是准备 100 到 200 条测试问题每条标注好标准答案所依赖的文档切片 doc_id系统跑完比对命中情况。核心指标两个——答案命中率生成答案中是否正确引用了目标切片和检索命中率目标切片是否出现在重排结果 Top 5 中。前者衡量生成质量后者衡量检索链路。比对逻辑用规则就够检查答案文本里是否包含目标切片的关键实体。def evaluate(retrieval_top5: list, target_doc_id: str, answer_text: str, key_entities: list) - dict: hit_at_5 any(item[doc_id] target_doc_id for item in retrieval_top5) is_entity_preserved all(entity in answer_text for entity in key_entities) return { retrieval_hit: hit_at_5, entity_preserved: is_entity_preserved, passed: hit_at_5 and is_entity_preserved }这套评估脚本的好处是能跑回归改了切片的粒度、换了 embedding 模型、调了重排阈值重新跑一遍就知道改动是正向还是负向不用靠记忆判断。毕设里把这个脚本和评估表放在源码里比写十页“系统测试”章节有说服力得多。5.2 向量知识库遇到了瓶颈什么时候需要加结构化知识图谱传统的 RAG 知识库在医疗场景有一个大家迟早会撞上的瓶颈——它只能做“线性引用”无法做“逻辑推理”。“患者同时有糖尿病和高血压”这类组合条件、药品相互作用的多跳推理(“A药经肝代谢B药抑制肝酶所以两药合用A药血药浓度升高”)纯向量检索很难支撑。这个场景下 KG 知识库结构知识库会更合适它把药品、成分、靶点、代谢途径建模成图结构系统能够沿着关系边做推理。但图结构的构建成本很高需要专业标注和持续维护不适合直接替换向量知识库。常见做法是双库并存向量知识库管原文片段引用KG 管实体关系推理两者结果都汇入上下文由重排环节决定取舍。对于毕设先跑通向量库把 KG 作为扩展方向写清楚比硬塞一个磕磕绊绊的图谱效果更好。5.3 私有化部署里最容易被忽视的警告医疗数据的敏感性决定了大模型层大概率要靠私有化部署来落。我这边踩过不少坑最隐蔽的一次是显存规划失误——embedding 模型、重排器、大模型三个服务都挤在一张 GPU 卡上embedding 偶尔请求一多就把显存占满大模型推理直接 OOM 重启。后来把 embedding 和重排器迁到 CPU 机器上跑GPU 只留给大模型问题才消失。量化方面也注意模型量化到 4bit 能用但输出稳定性会轻微下降医疗场景建议至少保留 8bit。另外私有化部署不是说代码放到内网就行模型文件的访问控制、问答日志的脱敏存储这些都得在设计里留出位置。回答系统上线前我还习惯做一轮“打破砂锅”测试把同一问题连续问三次看答案是不是稳定把知识库里已有的答案抽出来反向问看系统能否找到正确出处把一个纯编造的问题丢进去看系统能不能诚实回答“不知道”。前两项测试帮我修掉了很多隐性问题——提示词的随机性、检索阈值过松导致的抖动都被翻了出来。医疗问答不像其他领域可以容忍随机发挥稳定性本身就是正确性的一部分。这套测试习惯我保留到了后面的几乎所有项目里希望帮到你。本文还有配套的精品资源点击获取