Medical RAG — 用医学大模型回答专业诊疗问题

一位基层医生的"第二大脑"

2024年某天凌晨两点，一位来自乡镇卫生院的内科医生遇到了难题——病房里一位患者的症状组合非常罕见，她需要快速查阅权威医学文献来辅助判断。在传统工作流中，这意味着要打开电脑、登录数据库、输入检索词、筛选结果……整个过程可能耗时半小时以上。

但如果她打开了一个本地部署的对话界面，输入"转移性癌症的临床表现和处理原则"，系统立刻从已索引的医学文献中检索出最相关的段落，结合医学大模型的能力，给出了一段结构清晰、有据可查的回答。

这就是 Medical RAG using Meditron-7B-LLM 项目试图解决的核心问题——让一线医疗工作者拥有可信赖的、基于真实文献的 AI 助手。

项目起源：为什么需要专门的医疗 RAG

通用大模型在医疗场景面临一个根本性挑战：幻觉问题。模型可能自信满满地给出看似合理但完全错误的诊断建议，这在医疗领域是致命的。

Medical RAG 项目的解决方案是：不依赖模型的"记忆"，而是让模型在回答时实时检索权威医学文献，并严格规定回答必须基于检索到的证据。模型的角色从"知识的输出者"转变为"文献的解读器"。

该项目的技术选型也体现了这种务实思路：

• Meditron-7B：专门在医学文献数据集上微调过的 Llama 变体，兼顾了专业性和推理效率
• Qdrant 向量数据库：高性能的向量检索引擎，负责从海量医学文献中快速找到相关内容
• PubMedBERT 嵌入模型：专门针对生物医学文献训练的文本向量化模型，检索精度高于通用 embedding

技术架构：一条清晰的 RAG 流水线

项目的代码结构非常精简，核心只有四个 Python 文件：

rag.py        — FastAPI 服务主程序，处理用户查询
retriever.py  — 向量检索测试脚本
ingest.py     — PDF 文献导入工具（构建向量数据库）
requirements.txt — 依赖清单

数据导入流程（ingest.py）

整个流程从 ingest.py 开始：

1. DirectoryLoader 从 data/ 目录加载所有 PDF 文件（项目中已包含两篇肿瘤学文献）
2. RecursiveCharacterTextSplitter 将长文档切分为 1000 字符的块（chunk），相邻块之间有 100 字符的重叠以保持语义连贯性
3. PubMedBERT 模型将每个文本块转换为 768 维向量
4. 向量连同原文一起存入 Qdrant 的 vector_db 集合

查询回答流程（rag.py）

当用户在 Web UI 输入问题时：

1. 问题同样通过 PubMedBERT 转换为向量
2. 在 Qdrant 中执行最近邻检索，取 k=1（即只返回最相似的一个文档块）
3. 检索到的文档块被拼入 prompt 模板，要求模型"仅基于提供的上下文回答"
4. Meditron-7B 在本地 GGUF 量化模式下推理（Q4_K_M 量化，约 4GB 显存）
5. 返回答案及来源文档

这个流程的关键设计在于限制检索结果数量为 1——这是一个有意的工程选择，在减少幻觉风险的同时也限制了模型对复杂问题全面回答的能力。

核心依赖与技术栈

组件	技术选型	作用
LLM 推理	CTransformers + GGUF	本地量化推理，避免云端调用
向量数据库	Qdrant	高性能向量存储与检索
Embedding	PubMedBERT	医学文献专用向量化
Web 框架	FastAPI + Jinja2	提供 REST API + Web UI
链式调用	LangChain	串联 RAG 各环节

部署体验：没有捷径

这是项目最需要正视的短板。

没有 Docker 支持，意味着每个组件都需要手动配置：

• Qdrant 需要单独启动（Docker 或二进制）
• Meditron-7B GGUF 模型需要手动下载（约 4GB）
• Python 依赖通过 pip 安装，但 ctransformers 可能需要编译 C++ 后端
• PDF 文献数据需要放在 data/ 目录后运行 ingest.py

Web UI 本身设计得较为简洁，基于 Bootstrap 5 + Poppins 字体，黑色主题，风格偏工具化而非产品化。标题显示"Investment Banking Chatbot"（可能是从模板复制未修改），界面顶部有查询输入框和提交按钮。

局限性与改进空间

这个项目在工程完成度上存在几个明显不足：

第一，缺少生产级组件。 没有测试代码、没有 CI/CD、没有版本管理机制，数据管道完全依赖本地文件系统的 PDF 文件。

第二，prompt 模板硬编码。 所有 prompt 都在 rag.py 中写死，无法在不修改代码的情况下调整检索策略或回答风格。

第三，k=1 的检索策略过于保守。 医学问题的复杂性差异很大，简单的单一文档块可能无法支撑需要综合判断的问题。

第四，Web UI 有明显的模板遗留痕迹。 标题显示"Investment Banking Chatbot"与医学问答的定位不符，暗示这是一个早期原型或快速验证项目。

行业意义：本地化医疗 AI 的轻量化实践

尽管存在诸多不足，这个项目代表了一个有价值的探索方向：在完全本地化、数据自主的环境下，为医疗工作者提供可信的文献辅助工具。

与需要网络调用和数据上传的云端医疗 AI 相比，Medical RAG 的所有数据处理都在本地完成，敏感的患者信息或内部医学文献不会离开医院内网。这种部署模式在隐私合规要求严格的医疗场景中具有实际价值。

从技术演进的角度看，该项目采用的 GGUF 量化 + CTransformers 推理栈，代表了 2024 年初本地大模型部署的主流方案。它的代码虽然简单，但完整覆盖了 RAG 的核心环节，是一个值得参考的入门级医学 RAG 架构范例。

---

推荐人群：对医疗 AI 应用有实际需求（如医学院学生、基层医生）、愿意花时间配置本地环境的用户。

不推荐：追求开箱即用、无缝体验的用户，或需要高可靠性的生产环境部署。