简介这份资源是面向计算机、人工智能及自动化等相关专业师生与技术人员的高分毕业设计源码基于检索增强生成RAG框架与前沿大语言模型技术构建医疗领域智能问答系统答辩环节获得98分所有功能模块均通过完整测试并确保可执行。压缩包共89个文件约94.7MB以Python脚本、Jupyter Notebook、JSON与YAML配置、PNG/JPG界面截图及TXT数据说明为主涵盖模型微调、命名实体识别、知识图谱构建与Web交互等模块目录结构清晰便于按功能检索。目前已有99人学习下载。读者可据此掌握RAG问答系统的完整实现路径参考微调与推理脚本、图谱构建流程及界面设计并在此基础上进行功能扩展与个性化定制适合具备一定专业基础的用户用于教学研究与实践应用。1. 医疗问答系统为什么不能只靠大模型硬答做过医疗问答的人大多有过同一种翻车体验模型把一段用药建议说得头头是道语气笃定、格式工整可一旦追问「这个剂量出自哪一版指南」它就开始含糊其辞。医疗场景和通用闲聊最大的区别在于答案错了不是尴尬而是可能误导。纯靠大模型参数里记的那点医学知识既无法保证时效也无法给出可核查的出处这就是「基于 Python 的 RAG 与大模型医疗问答系统」要解决的核心问题。RAG检索增强生成的思路很直接把权威医学资料切块、向量化、存进知识库用户提问时先检索出最相关的若干片段再把这些片段作为上下文交给大模型组织答案。这样模型不再凭记忆硬答而是「看着资料回答」出处可追溯更新资料也不用重新训练。这套方案适合做毕业设计的学生、想搭企业内部医疗知识助手的工程师以及需要私有化部署、数据不出内网的团队。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。2. 把 RAG 医疗问答的链路拆成可落地的四段2.1 检索增强生成到底在补大模型的哪个短板大模型有三个绕不过去的短板知识截止、幻觉、不可溯源。RAG 分别用「外部知识库」「上下文约束」「引用片段」来补。整条链路是文档加载 → 文本切分 → 向量化 → 存入向量库 → 用户提问向量化 → 相似度检索 → 拼装 Prompt → 大模型生成 → 返回答案与出处。医疗场景对这条链路有额外要求。第一切分不能太碎否则一条完整的用药禁忌被切成两半检索到半句反而危险第二检索必须能召回同义表述用户说「心梗」和资料里写「心肌梗死」要能对上第三Prompt 里必须明确约束模型「只依据给定资料回答资料没有就说不知道」。这三点决定了后面所有参数怎么调。2.2 医疗知识库的选型向量库、KG 还是混合热搜里常出现「rag 知识库和结构知识库区分」「ontology rag」这类问题落到医疗场景确实要选。纯向量库擅长语义模糊匹配适合大段叙述性文本比如诊疗指南、药品说明书结构化知识库知识图谱 KG擅长精确关系推理比如「某药 → 禁忌 → 某疾病」这种三元组。医疗问答里两者各有盲区向量库可能召回语义相近但结论相反的内容KG 覆盖不全时又答不出开放问题。我的做法是混合用向量库做第一层召回用轻量 KG 或规则表做第二层校验重点校验药品名、剂量、禁忌这类高风险字段。毕业设计规模下KG 不必上重型图数据库用 Python 字典或 SQLite 存三元组就够。选型理由很简单——先把召回率做上去再用结构化校验兜住安全底线比一上来堆复杂架构更稳。2.3 用 Python 跑通最小检索链路先装依赖向量库用轻量的 FAISS嵌入模型和生成模型都走本地或兼容接口避免依赖外部服务。pip install langchain faiss-cpu sentence-transformers pypdf# minimal_rag.py from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载医学资料指南、说明书 PDF loader PyPDFLoader(medical_guide.pdf) docs loader.load() # 2. 切分chunk_size 控制单块长度overlap 保证跨块语义不断裂 splitter RecursiveCharacterTextSplitter( chunk_size500, # 医疗文本建议 400-600 chunk_overlap80, # 约 chunk_size 的 15% separators[\n\n, \n, 。, , ] ) chunks splitter.split_documents(docs) # 3. 向量化并建索引 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_medical_index) # 4. 检索测试 query 高血压患者能不能用布洛芬 results vectorstore.similarity_search(query, k4) for r in results: print(r.page_content[:120])逻辑说明加载器负责把 PDF 转成文本对象切分器决定检索粒度嵌入模型把文本映射成向量FAISS 负责近邻搜索。参数上chunk_size500是医疗文本的经验值太小会丢上下文太大会稀释关键信息chunk_overlap80防止一句话被切断k4是召回条数医疗场景建议 3 到 5太多会塞满上下文让模型分心。嵌入模型选中文优化的 bge 系列比通用多语言模型在中文医学语料上召回更准。2.4 把检索结果拼成受约束的 Prompt检索只是前半程真正决定答案质量的是 Prompt 怎么拼。医疗场景必须把「只依据资料」写死。# prompt_build.py def build_prompt(query, retrieved_docs): context \n\n.join( f[资料{i1}] {d.page_content} for i, d in enumerate(retrieved_docs) ) prompt f你是一名严谨的医疗问答助手。请严格依据下面提供的资料回答问题。 要求 1. 只使用资料中的信息不得编造 2. 若资料不足以回答直接回复「现有资料无法回答该问题」 3. 涉及药品剂量、禁忌时必须标注来源编号。 资料 {context} 问题{query} 回答 return prompt逻辑说明context把召回片段编号拼装方便模型引用三条约束分别对应防幻觉、防硬答、防无出处。参数上召回条数k和chunk_size共同决定 context 长度要留出空间给模型生成别把上下文顶满。如果模型支持较长上下文可以适当放宽k但医疗场景宁可少召回、保准确也不要塞一堆弱相关内容干扰判断。3. 大模型选型与本地部署免费 API 还是私有化3.1 医疗数据合规下的部署路线对比医疗问答绕不开数据敏感性。热搜里「企业大模型私有化部署」「ollama 部署大模型」「免费大模型 api」都指向同一个决策模型放哪。三条路线各有取舍。路线代表方式优点代价适用场景公有 API兼容接口调用零部署、模型强数据出内网、按量计费演示、非敏感问答本地小模型Ollama 跑 7B/14B数据不出内网显存要求、能力弱于大模型毕设、内网助手私有化大模型本地部署大参数模型能力强且可控硬件成本高企业生产毕业设计阶段我一般推荐 Ollama 跑一个 7B 到 14B 的中文模型配合 RAG 检索效果足够撑起答辩还能讲清「私有化」这个加分点。真到企业生产再考虑更大参数或混合方案。3.2 用 Ollama 起一个本地生成模型# 安装后拉取中文能力较好的模型 ollama pull qwen2.5:7b # 启动服务默认监听本地端口 ollama serve# generate.py import requests def ask_llm(prompt): resp requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: prompt, stream: False, options: { temperature: 0.2, # 医疗场景压低随机性 top_p: 0.9, num_ctx: 4096 # 上下文窗口需容纳检索片段 } } ) return resp.json()[response]逻辑说明temperature0.2是关键医疗问答要的是稳定复现而非创意温度越低答案越保守num_ctx要大于「检索片段 Prompt 模板 生成」的总长度否则会被截断导致答非所问。参数怎么改如果发现答案过于死板、漏掉资料里的细节可把温度提到 0.3 到 0.4如果出现胡编就往 0.1 压。top_p一般保持 0.9 即可不必频繁动。3.3 检索与生成的衔接参数怎么定很多人把检索和生成当两件事调结果两边都还行、合起来就崩。衔接处有三个参数要一起看召回条数k、单块长度chunk_size、上下文窗口num_ctx。约束关系是k × chunk_size不能超过num_ctx减去模板和生成预留的空间。比如num_ctx4096模板加生成预留约 1000 token那检索内容最多 3000 token按中文约 1.5 字/token 估算k4、chunk_size500大致合适。调参时先固定两个、动一个别三个一起改否则出了问题根本不知道是谁的锅。4. 医疗 RAG 避坑五个真实踩过的坑4.1 坑一检索召回的是「语义相近但结论相反」的片段现象问「某药能否用于孕妇」系统召回了一段讲该药「孕妇禁用」和一段讲「哺乳期可用」模型把两者混在一起答成「孕妇可用」。原因向量检索只看语义相似度不区分否定、禁忌、适用人群这些关键限定词禁用和可用在向量空间里可能很近。解决在切分时保留标题层级把「禁忌」「适用人群」作为元数据存进向量库检索后加一层规则过滤命中禁忌类字段时强制走高优先级提示。更稳的做法是对药品名、人群词做关键词加权别让纯语义相似度一锤定音。4.2 坑二切分把一条完整医嘱拦腰截断现象资料原文「每日一次每次 5mg肾功能不全者减半」被切成两块检索只召回前半句模型答出完整剂量却漏了减半条件。原因chunk_size设太小或分隔符没考虑中文标点导致语义单元被破坏。解决把chunk_size提到 500 以上分隔符加上中文句号、分号对药品说明书这类强结构文本按「适应症 / 用法用量 / 禁忌」小节切而不是按固定字数切。切完抽查几条看有没有半句话。4.3 坑三模型无视资料凭参数记忆硬答现象资料里明明没有某罕见病的治疗方案模型还是编了一套出来语气还很自信。原因Prompt 约束不够硬或温度偏高模型倾向于「补全」而非「承认不知道」。解决Prompt 里把「资料不足就说不知道」写成硬性第一条温度压到 0.2 以下再加一道后处理检查答案里的关键实体是否出现在召回片段中没出现就标记为「待人工复核」。这道校验在医疗场景几乎是后悔药级别的存在。4.4 坑四中文医学语料用通用嵌入模型召回率低现象用户口语化提问「心脏供血不足」资料里写「心肌缺血」检索召回一堆不相关片段。原因通用嵌入模型对中文医学同义词、缩写覆盖不足。解决换用中文医学语料微调过的嵌入模型或在检索前做一层同义词扩展把口语词映射到规范术语。规模不大时维护一张同义词表比重新训练模型划算得多。4.5 坑五本地模型上下文窗口不够检索片段被静默截断现象检索明明召回了正确片段答案却答非所问像是没看到资料。原因num_ctx设小了拼好的 Prompt 超出窗口前面的检索内容被截掉模型只看到问题和半截资料。解决先算清k × chunk_size加模板的 token 量再设num_ctx开启日志打印实际送入模型的 Prompt 长度超限就报警。这个黑匣子不打开调参全靠玄学。5. 让医疗 RAG 答得更准的两个进阶技巧5.1 用重排序把「召回多、命中少」救回来第一层向量检索为了保召回率k往往设得偏大但真正相关的可能只有一两条。这时加一个重排序rerank模型对召回的候选片段重新打分排序只把 top 2 到 3 送进生成。做法是先粗召回 10 条再用交叉编码器精排。# rerank.py from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def rerank(query, candidates, top_n3): pairs [(query, c.page_content) for c in candidates] scores reranker.predict(pairs) ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [c for c, _ in ranked[:top_n]]逻辑说明交叉编码器把「问题 片段」成对输入比向量点积更能捕捉细粒度相关性代价是慢所以只用在精排阶段。参数top_n3是医疗场景的稳妥值送太多反而稀释重点。粗召回k可以放到 8 到 10精排后收敛到 3整体准确率通常有明显提升。5.2 用引用校验做最后一道防线生成完答案后别急着返回。写一个校验函数检查答案里出现的药品名、剂量数字是否都能在召回片段里找到对应找不到就降级为「建议咨询医生」并附上原始片段。# verify.py import re def verify_answer(answer, retrieved_docs): context .join(d.page_content for d in retrieved_docs) # 抽取答案中的剂量数字检查是否在资料中出现 doses re.findall(r\d\s?(mg|g|ml|片|粒), answer) missing [d for d in doses if d.replace( , ) not in context.replace( , )] if missing: return {safe: False, missing: missing, fallback: 该剂量未在资料中找到依据请咨询专业医生。} return {safe: True, answer: answer}逻辑说明正则抽取剂量是低成本高收益的校验点医疗问答里剂量错误最致命。missing非空就触发降级宁可少答也不乱答。这套校验不追求覆盖所有风险但能拦住最常见的一类错误。5.3 我自己的习惯做这类系统我养成了一个习惯每加一个新资料源先手动问十个刁钻问题看召回和答案对不对再决定要不要入库。医疗 RAG 的难点从来不在模型多强而在资料切得对不对、检索召回准不准、约束写得硬不硬。把这三件事做扎实7B 的本地模型也能答得让人信服这三件事糊弄再大的模型也照样翻车。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向计算机、人工智能及自动化等相关专业师生与技术人员的高分毕业设计源码基于检索增强生成RAG框架与前沿大语言模型技术构建医疗领域智能问答系统答辩环节获得98分所有功能模块均通过完整测试并确保可执行。压缩包共89个文件约94.7MB以Python脚本、Jupyter Notebook、JSON与YAML配置、PNG/JPG界面截图及TXT数据说明为主涵盖模型微调、命名实体识别、知识图谱构建与Web交互等模块目录结构清晰便于按功能检索。目前已有99人学习下载。读者可据此掌握RAG问答系统的完整实现路径参考微调与推理脚本、图谱构建流程及界面设计并在此基础上进行功能扩展与个性化定制适合具备一定专业基础的用户用于教学研究与实践应用。1. 医疗问答系统为什么不能只靠大模型硬答做过医疗问答的人大多有过同一种翻车体验模型把一段用药建议说得头头是道语气笃定、格式工整可一旦追问「这个剂量出自哪一版指南」它就开始含糊其辞。医疗场景和通用闲聊最大的区别在于答案错了不是尴尬而是可能误导。纯靠大模型参数里记的那点医学知识既无法保证时效也无法给出可核查的出处这就是「基于 Python 的 RAG 与大模型医疗问答系统」要解决的核心问题。RAG检索增强生成的思路很直接把权威医学资料切块、向量化、存进知识库用户提问时先检索出最相关的若干片段再把这些片段作为上下文交给大模型组织答案。这样模型不再凭记忆硬答而是「看着资料回答」出处可追溯更新资料也不用重新训练。这套方案适合做毕业设计的学生、想搭企业内部医疗知识助手的工程师以及需要私有化部署、数据不出内网的团队。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。2. 把 RAG 医疗问答的链路拆成可落地的四段2.1 检索增强生成到底在补大模型的哪个短板大模型有三个绕不过去的短板知识截止、幻觉、不可溯源。RAG 分别用「外部知识库」「上下文约束」「引用片段」来补。整条链路是文档加载 → 文本切分 → 向量化 → 存入向量库 → 用户提问向量化 → 相似度检索 → 拼装 Prompt → 大模型生成 → 返回答案与出处。医疗场景对这条链路有额外要求。第一切分不能太碎否则一条完整的用药禁忌被切成两半检索到半句反而危险第二检索必须能召回同义表述用户说「心梗」和资料里写「心肌梗死」要能对上第三Prompt 里必须明确约束模型「只依据给定资料回答资料没有就说不知道」。这三点决定了后面所有参数怎么调。2.2 医疗知识库的选型向量库、KG 还是混合热搜里常出现「rag 知识库和结构知识库区分」「ontology rag」这类问题落到医疗场景确实要选。纯向量库擅长语义模糊匹配适合大段叙述性文本比如诊疗指南、药品说明书结构化知识库知识图谱 KG擅长精确关系推理比如「某药 → 禁忌 → 某疾病」这种三元组。医疗问答里两者各有盲区向量库可能召回语义相近但结论相反的内容KG 覆盖不全时又答不出开放问题。我的做法是混合用向量库做第一层召回用轻量 KG 或规则表做第二层校验重点校验药品名、剂量、禁忌这类高风险字段。毕业设计规模下KG 不必上重型图数据库用 Python 字典或 SQLite 存三元组就够。选型理由很简单——先把召回率做上去再用结构化校验兜住安全底线比一上来堆复杂架构更稳。2.3 用 Python 跑通最小检索链路先装依赖向量库用轻量的 FAISS嵌入模型和生成模型都走本地或兼容接口避免依赖外部服务。pip install langchain faiss-cpu sentence-transformers pypdf# minimal_rag.py from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载医学资料指南、说明书 PDF loader PyPDFLoader(medical_guide.pdf) docs loader.load() # 2. 切分chunk_size 控制单块长度overlap 保证跨块语义不断裂 splitter RecursiveCharacterTextSplitter( chunk_size500, # 医疗文本建议 400-600 chunk_overlap80, # 约 chunk_size 的 15% separators[\n\n, \n, 。, , ] ) chunks splitter.split_documents(docs) # 3. 向量化并建索引 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_medical_index) # 4. 检索测试 query 高血压患者能不能用布洛芬 results vectorstore.similarity_search(query, k4) for r in results: print(r.page_content[:120])逻辑说明加载器负责把 PDF 转成文本对象切分器决定检索粒度嵌入模型把文本映射成向量FAISS 负责近邻搜索。参数上chunk_size500是医疗文本的经验值太小会丢上下文太大会稀释关键信息chunk_overlap80防止一句话被切断k4是召回条数医疗场景建议 3 到 5太多会塞满上下文让模型分心。嵌入模型选中文优化的 bge 系列比通用多语言模型在中文医学语料上召回更准。2.4 把检索结果拼成受约束的 Prompt检索只是前半程真正决定答案质量的是 Prompt 怎么拼。医疗场景必须把「只依据资料」写死。# prompt_build.py def build_prompt(query, retrieved_docs): context \n\n.join( f[资料{i1}] {d.page_content} for i, d in enumerate(retrieved_docs) ) prompt f你是一名严谨的医疗问答助手。请严格依据下面提供的资料回答问题。 要求 1. 只使用资料中的信息不得编造 2. 若资料不足以回答直接回复「现有资料无法回答该问题」 3. 涉及药品剂量、禁忌时必须标注来源编号。 资料 {context} 问题{query} 回答 return prompt逻辑说明context把召回片段编号拼装方便模型引用三条约束分别对应防幻觉、防硬答、防无出处。参数上召回条数k和chunk_size共同决定 context 长度要留出空间给模型生成别把上下文顶满。如果模型支持较长上下文可以适当放宽k但医疗场景宁可少召回、保准确也不要塞一堆弱相关内容干扰判断。3. 大模型选型与本地部署免费 API 还是私有化3.1 医疗数据合规下的部署路线对比医疗问答绕不开数据敏感性。热搜里「企业大模型私有化部署」「ollama 部署大模型」「免费大模型 api」都指向同一个决策模型放哪。三条路线各有取舍。路线代表方式优点代价适用场景公有 API兼容接口调用零部署、模型强数据出内网、按量计费演示、非敏感问答本地小模型Ollama 跑 7B/14B数据不出内网显存要求、能力弱于大模型毕设、内网助手私有化大模型本地部署大参数模型能力强且可控硬件成本高企业生产毕业设计阶段我一般推荐 Ollama 跑一个 7B 到 14B 的中文模型配合 RAG 检索效果足够撑起答辩还能讲清「私有化」这个加分点。真到企业生产再考虑更大参数或混合方案。3.2 用 Ollama 起一个本地生成模型# 安装后拉取中文能力较好的模型 ollama pull qwen2.5:7b # 启动服务默认监听本地端口 ollama serve# generate.py import requests def ask_llm(prompt): resp requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: prompt, stream: False, options: { temperature: 0.2, # 医疗场景压低随机性 top_p: 0.9, num_ctx: 4096 # 上下文窗口需容纳检索片段 } } ) return resp.json()[response]逻辑说明temperature0.2是关键医疗问答要的是稳定复现而非创意温度越低答案越保守num_ctx要大于「检索片段 Prompt 模板 生成」的总长度否则会被截断导致答非所问。参数怎么改如果发现答案过于死板、漏掉资料里的细节可把温度提到 0.3 到 0.4如果出现胡编就往 0.1 压。top_p一般保持 0.9 即可不必频繁动。3.3 检索与生成的衔接参数怎么定很多人把检索和生成当两件事调结果两边都还行、合起来就崩。衔接处有三个参数要一起看召回条数k、单块长度chunk_size、上下文窗口num_ctx。约束关系是k × chunk_size不能超过num_ctx减去模板和生成预留的空间。比如num_ctx4096模板加生成预留约 1000 token那检索内容最多 3000 token按中文约 1.5 字/token 估算k4、chunk_size500大致合适。调参时先固定两个、动一个别三个一起改否则出了问题根本不知道是谁的锅。4. 医疗 RAG 避坑五个真实踩过的坑4.1 坑一检索召回的是「语义相近但结论相反」的片段现象问「某药能否用于孕妇」系统召回了一段讲该药「孕妇禁用」和一段讲「哺乳期可用」模型把两者混在一起答成「孕妇可用」。原因向量检索只看语义相似度不区分否定、禁忌、适用人群这些关键限定词禁用和可用在向量空间里可能很近。解决在切分时保留标题层级把「禁忌」「适用人群」作为元数据存进向量库检索后加一层规则过滤命中禁忌类字段时强制走高优先级提示。更稳的做法是对药品名、人群词做关键词加权别让纯语义相似度一锤定音。4.2 坑二切分把一条完整医嘱拦腰截断现象资料原文「每日一次每次 5mg肾功能不全者减半」被切成两块检索只召回前半句模型答出完整剂量却漏了减半条件。原因chunk_size设太小或分隔符没考虑中文标点导致语义单元被破坏。解决把chunk_size提到 500 以上分隔符加上中文句号、分号对药品说明书这类强结构文本按「适应症 / 用法用量 / 禁忌」小节切而不是按固定字数切。切完抽查几条看有没有半句话。4.3 坑三模型无视资料凭参数记忆硬答现象资料里明明没有某罕见病的治疗方案模型还是编了一套出来语气还很自信。原因Prompt 约束不够硬或温度偏高模型倾向于「补全」而非「承认不知道」。解决Prompt 里把「资料不足就说不知道」写成硬性第一条温度压到 0.2 以下再加一道后处理检查答案里的关键实体是否出现在召回片段中没出现就标记为「待人工复核」。这道校验在医疗场景几乎是后悔药级别的存在。4.4 坑四中文医学语料用通用嵌入模型召回率低现象用户口语化提问「心脏供血不足」资料里写「心肌缺血」检索召回一堆不相关片段。原因通用嵌入模型对中文医学同义词、缩写覆盖不足。解决换用中文医学语料微调过的嵌入模型或在检索前做一层同义词扩展把口语词映射到规范术语。规模不大时维护一张同义词表比重新训练模型划算得多。4.5 坑五本地模型上下文窗口不够检索片段被静默截断现象检索明明召回了正确片段答案却答非所问像是没看到资料。原因num_ctx设小了拼好的 Prompt 超出窗口前面的检索内容被截掉模型只看到问题和半截资料。解决先算清k × chunk_size加模板的 token 量再设num_ctx开启日志打印实际送入模型的 Prompt 长度超限就报警。这个黑匣子不打开调参全靠玄学。5. 让医疗 RAG 答得更准的两个进阶技巧5.1 用重排序把「召回多、命中少」救回来第一层向量检索为了保召回率k往往设得偏大但真正相关的可能只有一两条。这时加一个重排序rerank模型对召回的候选片段重新打分排序只把 top 2 到 3 送进生成。做法是先粗召回 10 条再用交叉编码器精排。# rerank.py from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def rerank(query, candidates, top_n3): pairs [(query, c.page_content) for c in candidates] scores reranker.predict(pairs) ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [c for c, _ in ranked[:top_n]]逻辑说明交叉编码器把「问题 片段」成对输入比向量点积更能捕捉细粒度相关性代价是慢所以只用在精排阶段。参数top_n3是医疗场景的稳妥值送太多反而稀释重点。粗召回k可以放到 8 到 10精排后收敛到 3整体准确率通常有明显提升。5.2 用引用校验做最后一道防线生成完答案后别急着返回。写一个校验函数检查答案里出现的药品名、剂量数字是否都能在召回片段里找到对应找不到就降级为「建议咨询医生」并附上原始片段。# verify.py import re def verify_answer(answer, retrieved_docs): context .join(d.page_content for d in retrieved_docs) # 抽取答案中的剂量数字检查是否在资料中出现 doses re.findall(r\d\s?(mg|g|ml|片|粒), answer) missing [d for d in doses if d.replace( , ) not in context.replace( , )] if missing: return {safe: False, missing: missing, fallback: 该剂量未在资料中找到依据请咨询专业医生。} return {safe: True, answer: answer}逻辑说明正则抽取剂量是低成本高收益的校验点医疗问答里剂量错误最致命。missing非空就触发降级宁可少答也不乱答。这套校验不追求覆盖所有风险但能拦住最常见的一类错误。5.3 我自己的习惯做这类系统我养成了一个习惯每加一个新资料源先手动问十个刁钻问题看召回和答案对不对再决定要不要入库。医疗 RAG 的难点从来不在模型多强而在资料切得对不对、检索召回准不准、约束写得硬不硬。把这三件事做扎实7B 的本地模型也能答得让人信服这三件事糊弄再大的模型也照样翻车。希望帮到你。本文还有配套的精品资源点击获取
