智能医疗档案与知识库构建

2025-11-25 15:40:12
文章摘要
医院里各种资料堆成山，医生想找点东西常常翻半天，病人问的问题也重复又耗时。文章介绍一种基于 RAG 的智能知识库，把散乱文档变成能秒答问题的智能大脑，让医护效率和患者体验都大幅提升。

目录

一、方案逻辑：从文档堆到智能问答

 1. 系统整体架构

 2. 技术选型

二、实操流程：从零搭建医疗知识库

 步骤 1：环境准备

 步骤 2：创建医疗文档知识库

 步骤 3：构建 RAG 检索生成引擎

 步骤 4：封装 FastAPI 接口服务

 步骤 5：接入医院的实际应用场景


前言

在国内医疗机构，知识管理长期被忽视，导致医护效率低下、患者体验受限。

病历资料分散且检索效率低，医生查找相似病例可能需要数小时；诊疗规范、用药指南和科室 SOP 分散在不同文档、微信和系统中，新入职医护难以获取最新版本；患者咨询重复问题占用专家时间，线上问诊平台回复不及时；科研文献利用率低，医生筛选文献耗时。

传统 EMR 系统、知识管理平台和搜索引擎在处理自由文本、非结构化数据和语义理解上存在明显局限。

因此，医院亟需一种能够理解语义、整合多类型文档，并生成可追溯答案的智能问答系统。


一、方案逻辑：从文档堆到智能问答

RAG（检索增强生成）结合了检索和生成模型的优势。用户提问时，系统先检索知识库相关文档，再将文档与问题一起交给大模型生成答案。

与传统搜索相比，RAG 能提供基于真实文档的准确答案、可追溯信息来源，并支持医院内部规范的定制化问答。

系统整体架构包括：

  1. 文档采集与处理：支持 PDF、Word、Excel、扫描件（OCR）导入，来源包括 HIS 系统、内部知识库和影像报告；文档切分为小段，向量化存储在 FAISS 数据库中。
  2. 检索生成：用户提问后，系统先检索最相关文档片段，再交由本地大模型生成答案。
  3. 接口服务：通过 FastAPI 提供 HTTP 接口，可对接微信公众号、企业微信、HIS 系统或导医屏，实现多渠道使用。

技术选型：

  1. 本地大模型：智谱 GLM-4，本地部署，中文医疗语料训练
  2. 向量数据库：FAISS，纯 Python 实现，高速检索
  3. 应用框架：LangChain + FastAPI，成熟 RAG 工具链
  4. 文档处理：PyMuPDF + Tesseract OCR，支持多格式解析

本地部署不仅保证数据隐私和安全，还可微调模型以适应医院特定场景，长期成本低。


二、实操流程：从零搭建智能医疗知识库

步骤 1 环境准备

1.安装 Python 环境

确认 Python 版本（需要 3.10 或更高）：

python --version


创建独立的项目环境（避免依赖冲突）：

python -m venv medical_rag_env
source medical_rag_env/bin/activate # Linux/Mac
medical_rag_env\Scripts\activate # Windows


2.安装核心依赖包

执行以下命令安装必要的库：

pip install fastapi==0.109.0
pip install uvicorn==0.27.0
pip install langchain==0.1.5
pip install langchain-community==0.0.20
pip install faiss-cpu==1.7.4
pip install pymupdf==1.23.8
pip install pytesseract==0.3.10
pip install python-dotenv==1.0.0


各组件作用：

fastapi：构建 HTTP API 接口

uvicorn：高性能异步服务器

langchain：RAG 工具链核心库

faiss-cpu：向量相似度搜索引擎

pymupdf：解析 PDF 文档

pytesseract：OCR 文字识别（处理扫描件）

python-dotenv：管理配置文件


3.部署本地大模型

方案一：使用 Ollama 快速部署（推荐新手）

下载 Ollama：访问 https://ollama.com/download 选择对应系统版本

安装后下载智谱 GLM-4 模型：

ollama pull glm4:9b


启动模型服务：

ollama serve


服务默认运行在 http://localhost:11434


方案二：从 Hugging Face 直接部署

访问 https://huggingface.co/THUDM/glm-4-9b-chat 下载模型文件

使用 transformers 库加载：

# 这段代码仅作示意，实际部署时运行
from transformers import AutoTokenizer, AutoModel

tokenizer = AutoTokenizer.from_pretrained("THUDM/glm-4-9b-chat", trust_remote_code=True)
model = AutoModel.from_pretrained("THUDM/glm-4-9b-chat", trust_remote_code=True).half().cuda()

性能要求参考：

CPU 模式：至少 16GB 内存，8 核处理器

GPU 模式：NVIDIA 显卡（至少 12GB 显存），速度提升 10 倍以上


4.测试模型可用性

在命令行测试模型是否正常响应：

ollama run glm4:9b "什么是糖尿病？"

如果返回医学相关解释，说明模型已就绪。


步骤 2：构建医疗文档知识库

1.准备测试文档

在项目文件夹创建 medical_docs 目录，放入以下类型的文档：

示例文档结构：

medical_docs/
├── 糖尿病诊疗规范_2024版.pdf
├── 常见药物相互作用表.xlsx
├── 影像科检查须知.docx
└── 患者教育手册/
    ├── 高血压饮食指南.pdf
    └── 术后康复注意事项.pdf

文档来源建议：

医院内部规范文件

权威医学指南

历史病历数据（需脱敏处理）

医学教材章节


2.创建文档加载脚本

新建 document_loader.py 文件，实现文档导入逻辑。

核心功能：

1. 自动识别文件类型（PDF、Word、Excel、图片）

2. 将文档内容提取为纯文本

3. 支持 OCR 识别扫描件中的文字

关键参数说明：

chunk_size=500：每个文档片段约 500 字，太长模型处理不过来，太短上下文丢失

chunk_overlap=50：相邻片段重叠 50 字，避免关键信息被切断

处理流程示意：

原始文档（3000字）
    ↓ 分块处理
片段1（500字）：第1-500字
片段2（500字）：第451-950字（与片段1重叠50字）
片段3（500字）：第901-1400字
...


3.生成向量索引

新建 indexer.py 文件，将文档转为可搜索的向量。

什么是向量化： 想象每篇文档都有一个"指纹"（一串数字），内容相似的文档指纹也相似。例如：

"糖尿病患者饮食注意事项" → [0.23, 0.87, 0.45, ...]

"糖尿病人能吃什么" → [0.21, 0.89, 0.43, ...]（数字接近）

"骨折后康复训练" → [0.78, 0.12, 0.91, ...]（数字差异大）

当用户提问时，系统也把问题转成向量，然后找到"指纹最接近"的文档。

使用的向量模型：

● 本地方案：bge-large-zh-v1.5（北京智源研究院开源，专为中文优化）

● 下载地址：https://huggingface.co/BAAI/bge-large-zh-v1.5

索引存储： 使用 FAISS 向量数据库，它的优势是：

● 完全本地化，不依赖外部服务

● 检索速度极快（百万级文档毫秒响应）

● 纯 Python 实现，无需额外配置

创建索引流程：

1. 逐个读取 medical_docs 文件夹中的文档

2. 调用 bge 模型将每个片段转为 768 维向量

3. 将所有向量存入 FAISS 索引文件（medical_knowledge.index）

4. 同时保存文档原文到 medical_knowledge.pkl（后续生成答案时需要）

避坑提示：

● 首次生成索引时间较长（1000 份文档约需 10-20 分钟）

● 向量文件较大（1000 份文档约 500MB），确保磁盘空间充足

● 文档更新后需要重新生成索引，建议定期（如每周）执行


步骤 3：构建 RAG 检索生成引擎

1.创建核心查询脚本

新建 rag_engine.py 文件，这是整个系统的大脑。

完整工作流程：

第一步：接收用户问题

用户输入："2 型糖尿病患者能吃西瓜吗？"


第二步：问题向量化

● 将问题转为 768 维向量

● 用的是和文档一样的 bge 模型，保证"语言一致"

第三步：检索相关文档

● 在 FAISS 索引中搜索最相似的 5 个文档片段

● 相似度算法：余弦相似度（数学上衡量向量夹角）

检索结果示例：

相似度 0.89 → 《糖尿病饮食指南》第 3 章："水果选择应优先低糖品种，西瓜含糖量约 5%，可适量食用..."
相似度 0.85 → 病历 #2024031501："患者询问水果摄入，建议每日水果总量不超过 200g，西瓜可选..."
相似度 0.82 → 《内分泌科培训教材》："西瓜血糖生成指数（GI）为 72，属中等水平..."
相似度 0.78 → 患者教育材料："糖尿病患者夏季饮食注意，西瓜可以吃，但需要控制量..."
相似度 0.75 → 营养科咨询记录："西瓜水分多，糖分相对不高，餐后 2 小时食用为宜..."


第四步：组装提示词

将检索到的内容和用户问题组合成一个完整的提示：

系统角色：你是一位专业的医疗知识助手，基于医院内部规范回答问题。

参考资料：
[文档1] 《糖尿病饮食指南》："水果选择应优先低糖品种，西瓜含糖量约 5%，可适量食用..."
[文档2] 病历 #2024031501："患者询问水果摄入，建议每日水果总量不超过 200g..."
[文档3] 《内分泌科培训教材》："西瓜血糖生成指数（GI）为 72，属中等水平..."

用户问题：2 型糖尿病患者能吃西瓜吗？

要求：
1. 必须基于上述参考资料回答，不要编造信息
2. 如果资料中没有明确答案，说明"暂无相关资料"
3. 回答要通俗易懂，避免专业术语堆砌
4. 标注信息来源（如引用了哪份文档）


第五步：调用本地大模型生成答案

将组装好的提示发送给 GLM-4 模型，模型会：

● 理解用户问题的意图

● 综合多份资料的信息

● 生成连贯、准确的自然语言回答

生成的答案示例：

2 型糖尿病患者可以适量食用西瓜，但需要注意以下几点：

1. 控制摄入量：根据《糖尿病饮食指南》建议，每日水果总量不超过 200 克，西瓜约相当于 2-3 小块。

2. 选择合适时间：餐后 2 小时血糖相对稳定时食用更佳，避免空腹或睡前食用。

3. 监测血糖反应：西瓜的血糖生成指数（GI）为 72，属于中等水平。建议首次食用后测量血糖，观察个体反应。

4. 计入每日碳水总量：如果当天吃了西瓜，需要相应减少主食摄入，保持总热量平衡。

信息来源：
- 《糖尿病饮食指南》第 3 章
- 《内分泌科培训教材》水果章节
- 本院营养科咨询记录



2.关键参数调优

检索数量（k 值）：

● 设置为 5：返回最相关的 5 个片段

● 太少（k=1-2）：信息不够全面，可能漏掉关键内容

● 太多（k>10）：无关信息干扰，模型容易"跑偏"

相似度阈值：

● 可以设置最低相似度 0.7，低于此值的结果不采纳

● 避免检索到完全不相关的文档

提示词模板优化： 针对医疗场景的特殊要求：

● 强调"不确定时说不知道"，避免误导患者

● 要求标注信息来源，提升可信度

● 禁止给出诊断结论（防止医疗事故）

步骤 4 封装 FastAPI 接口服务

1.创建 API 主程序

新建 main.py 文件，将 RAG 引擎封装成 Web 服务。

为什么需要 API 接口：

● 知识库可以被多个系统调用（公众号、小程序、HIS 系统）

● 支持并发访问，多个医生同时查询互不影响

● 可以记录查询日志，分析常见问题

FastAPI 的核心优势：

● 异步处理：一个医生在等模型生成答案时，其他医生的请求不受影响

● 自动文档：访问 /docs 可以看到可视化的 API 测试界面

● 类型检查：自动验证输入参数，避免错误调用

【这里插入 FastAPI 架构示意图】


2.定义查询接口

创建 endpoints.py 文件，定义具体的 API 路径。

接口设计：

请求路径：GET /query/
参数：query（问题文本）
返回格式：
{
  "query": "用户的原始问题",
  "answer": "生成的答案",
  "sources": ["文档1", "文档2", ...],
  "confidence": 0.85 // 答案可信度
}


异步处理的好处：

传统同步模式：

医生 A 提问 → 等待 5 秒 → 返回答案
医生 B 提问 → 排队等待 A 完成 → 再等 5 秒
医生 C 提问 → 继续排队...


异步模式：

医生 A、B、C 同时提问 → 并行处理 → 5 秒后同时返回



3.启动服务

在命令行执行：

uvicorn main:app --reload --host 0.0.0.0 --port 8000

参数说明：

reload：代码修改后自动重启（开发阶段使用）

host 0.0.0.0：允许局域网内其他设备访问

port 8000：服务运行在 8000 端口

服务启动后，访问 http://localhost:8000/docs 可以看到自动生成的接口文档。


4.测试接口

在 Swagger 界面或使用 Postman 测试：

请求示例：

GET http://localhost:8000/query/?query=高血压患者能喝咖啡吗


预期返回：

{
  "query": "高血压患者能喝咖啡吗",
  "answer": "高血压患者可以适量饮用咖啡，但需注意以下几点：1. 每日咖啡因摄入不超过 200mg（约 2 杯美式咖啡）；2. 避免在服用降压药后 1 小时内饮用；3. 监测血压变化，部分患者对咖啡因敏感。具体建议请咨询主治医师。",
  "sources": [
    "《高血压防治指南》第 5 章",
    "心内科患者教育材料"
  ],
  "confidence": 0.87
}


步骤 5：对接实际应用场景

1.接入企业微信机器人

医生在企业微信群里 @机器人提问，自动返回答案。

配置步骤：

1. 在企业微信管理后台创建群机器人

2. 获取 Webhook 地址

3. 在 `main.py` 中添加接收企业微信消息的接口

4. 调用 RAG 引擎生成答案后，通过 Webhook 发回群聊


2.构建患者自助查询终端

场景：医院大厅放置触摸屏，患者自助查询就诊须知。

实现方案：

1. 用 Electron 或 H5 开发触摸屏前端

2. 前端调用 FastAPI 接口获取答案

3. 界面设计简洁，支持语音输入

常见问题预设：

各科室位置指引

检查项目注意事项（如"CT 需要空腹吗"）

就诊流程说明

医保报销政策


3.集成到 HIS 系统

场景：医生在电子病历系统中遇到疑问，点击"知识库辅助"按钮查询。

技术对接：

HIS 系统通过内网 HTTP 请求调用 RAG 接口

传入当前患者的诊断、症状等上下文信息

返回相关诊疗建议和参考文献

示例场景： 医生正在书写病历，患者主诉"反复咳嗽 2 周，伴夜间加重"。点击辅助按钮后，系统自动检索：

类似症状的历史病例

鉴别诊断要点

推荐的检查项目


 总结

通过构建本地部署的 RAG 智能医疗知识问答系统，医院可以将分散、非结构化的文档资源转化为可检索、可追溯、可生成自然语言答案的知识库。

实现医护查找资料秒级响应，患者自助查询便捷化。

整体而言，该方案不仅解决了传统 EMR 系统和知识管理平台在语义理解、信息整合上的局限，也为医院提供了一个可持续、高效、安全的智能知识管理解决方案。


声明：该内容由作者自行发布，观点内容仅供参考，不代表平台立场；如有侵权，请联系平台删除。