RAG+Neo4j医疗问答系统：LangChain与FastAPI全栈实践

最近实训/毕业设计阶段，医疗问答、医疗知识库这类选题热度一直很高。很多人一上来就堆大模型 API，结果答辩时导师问“你的系统除了调接口还有什么”，一时答不上来。这次看的这个项目，思路不太一样：它把RAG 检索增强生成、LangChain 工作流、Neo4j 知识图谱、FastAPI 后端和 Vue3 前端串成了一个完整的医疗问诊平台，免费可用，特别适合 Python 大模型方向的毕业设计或课程设计。

先说最值得关注的几个点：一是RAG 让大模型回答有据可依，不再是纯靠模型“编”，医疗场景下这一点很重要；二是Neo4j 知识图谱把疾病、症状、药物、科室之间的关联关系可视化，作为系统亮点去答辩很有说服力；三是FastAPI 提供标准接口，前端 Vue3 可以直接对接，前后端分离的思路完整，能展示工程能力。硬件门槛方面，如果使用本地小模型做 embedding 和 LLM 推理，普通 8G 显存显卡就可以起步；如果调用云端 API，一张普通开发机都够。本文会带你把环境准备、项目启动、功能测试、接口调用、批量任务这几个环节全部过一遍。

适合谁来读：正在选毕业设计题目的本科生、想做 AI 应用方向课设的研究生、以及想快速搭一套“RAG + 知识图谱 + 前后端分离”演示系统的开发者。这套技术栈组合放到简历里，覆盖面也比较广。

1. 核心能力速览

说明：上表中的具体参数，比如模型名称、端口号、向量库类型，要根据你拉取到的项目 README 或配置目录最终确认。下面所有命令都是通用部署模板，按实际项目结构替换路径即可。

2. 适用场景与使用边界

这个项目适合三类人。

第一类：毕业设计选题是“大模型 + 垂直行业应用”的同学。医疗问答是典型场景，RAG 解决大模型幻觉问题，Neo4j 解决知识关联展示问题，FastAPI + Vue3 解决系统完整性问题，每一层都有明确“工作量”可写进论文。

第二类：想快速理解 RAG 工程链路的开发者。从文档加载、文本切分、向量化、检索、重排、Prompt 组装到生成回答，整个链路在这个项目里能跑通，并且能看到每一步的输入输出。

第三类：需要演示知识图谱价值的开发者。Neo4j 里疾病、症状、药物、科室之间的多跳关系，比传统关系型数据库的表格展示直观得多，做系统演示时效果明显。

使用边界这里必须说清楚：

• 不能用于真实医疗诊断。这个项目定位是学习演示和科研原型，不是医疗器械，不能给真实患者提供诊疗建议。系统输出只能作为“参考信息”，不能作为处方依据。
• 数据隐私必须控制。如果导入真实病历或患者数据，必须提前脱敏，并遵守相关数据保护法规。建议课程设计和毕业设计阶段只使用公开医学知识库和模拟数据。
• 模型输出需要人工复核。RAG 只能降低幻觉概率，不能完全消除。系统里应该保留“AI 生成内容仅供参考”的免责提示，答辩时这也是一个加分点。
• 商用需谨慎。医疗 AI 商业化有严格的资质要求和审查流程，这个项目作为学习范本没有问题，但不要直接包装成商用产品。

3. 系统架构与核心流程

在动手部署前，先理解这个项目的整体结构，后面排查问题时会更清楚。

3.1 整体技术分层

这个项目的典型分层结构大致如下：

前端层：Vue3 + Vite + Element Plus + ECharts ↓ HTTP 请求 接口层：FastAPI + Uvicorn ↓ 业务服务层： 1. RAG 问答服务（LangChain 编排） 2. 知识图谱查询服务（Neo4j Cypher） 3. 用户会话服务（可选，对接关系型数据库） ↓ 数据层： - 文档知识库 → 加载 → 切分 → Embedding → 向量存储 - 结构化医疗数据 → Neo4j 图数据库 - 大模型服务：云端 API 或本地推理服务

前端负责对话界面、知识图谱可视化、问诊表单和结果展示；FastAPI 负责接收请求、编排 RAG 流程、查询知识图谱、返回统一 JSON；Neo4j 负责存储和查询疾病、症状、药品、科室等实体关系；LangChain 把“检索 — 组装 Prompt — 调用大模型 — 输出回答”串成一条可维护的链路。

3.2 RAG 问答链路

这个项目的核心是 RAG，整体流程可以这样理解：

1. 知识入库：把医学教材、公开疾病百科、药品说明书等文档放入指定目录。
2. 文档加载与切分：LangChain 读取文档，按标题、段落或固定 chunk_size 切分。
3. 向量化：调用 Embedding 模型把文本块转成向量并存入向量数据库。
4. 用户提问：用户输入症状或疾病描述。
5. 检索召回：把用户问题向量化，在向量库中检索 TopK 相关文本块。
6. 重排与组装：把检索结果作为上下文，与系统提示词、用户问题组装成最终 Prompt。
7. 生成回答：大模型基于提供的上下文生成回答，并可在回答后面附上参考来源。

为什么要做 RAG，而不是直接让大模型回答？因为医疗场景对准确性要求高，直接用大模型“背”答案，容易出现事实性错误。RAG 让模型“先查资料再回答”，问题对应的知识来自本地知识库而不是模型参数记忆，提高可解释性。

3.3 知识图谱问答链路

Neo4j 在系统里承担“关系查询 + 知识推理”的职责。常见查询包括：

• “感冒有哪些症状？”
• “头痛应该挂哪个科室？”
• “某某药物和某某药物能否同服？”
• “糖尿病患者需要注意什么？”

这些查询如果用传统关系型数据库做，需要多次 JOIN，而且关系深了以后 SQL 会非常复杂。Neo4j 用 Cypher 直接遍历关系：

// 示例：查询与"糖尿病"相关的症状节点 MATCH (d:疾病 {name: '糖尿病'})-[:关联症状]->(s:症状) RETURN s.name LIMIT 20

项目里通常会预置一批 Cypher 查询模板，把用户问题通过规则或大模型映射成对应的图查询，再把查询结果拼进回答上下文。这部分做好了，答辩时可以重点展示知识图谱如何增强回答的解释性。

4. 环境准备与前置条件

部署这个项目需要的环境比较多，建议按照下面清单准备。

4.1 硬件基础要求

如果你的方案是调用云端大模型 API，那么显卡要求可以忽略，普通开发笔记本即可。

4.2 软件环境清单

IDE 推荐 VS Code，装好 Python、Vue 插件。数据库可视化工具可以准备 DBeaver 或 Neo4j Browser，方便查看图数据。

5. 安装部署与启动方式

这个项目涉及多个服务，启动顺序建议是：先启动 Neo4j，再启动后端 FastAPI，最后启动前端 Vue3。

5.1 获取项目代码

# 把项目克隆到本地，网址以你找到的项目仓库为准 git clone <项目仓库地址> cd <项目目录>

如果你的项目是通过网盘下载压缩包，解压后注意路径不能包含中文，避免依赖安装时出现编码问题。

5.2 启动 Neo4j 图数据库

Neo4j 是知识图谱的存储引擎，必须最先启动。

安装方式有两种。第一种是桌面安装，直接下载 Neo4j Desktop，创建新数据库即可。第二种是 Docker 方式，开发环境比较推荐：

docker run -d \ --name neo4j \ -p 7474:7474 \ -p 7687:7687 \ -e NEO4J_AUTH=neo4j/yourpassword \ neo4j:5-community

启动后访问http://localhost:7474，用neo4j和设置的密码登录，然后在 Neo4j Browser 里执行项目提供的 Cypher 初始化脚本，导入疾病、症状、药品、科室等节点和关系。

如果项目的初始化脚本是.cypher文件，也可以用命令行执行：

# 以 neo4j-admin 方式导入，实际路径按你的安装位置调整 neo4j-admin database import full \ --nodes=<节点CSV路径> \ --relationships=<关系CSV路径> \ --database=neo4j

更常见的做法是项目里有 Python 脚本，通过neo4jPython 驱动批量写入数据：

python scripts/init_graph.py

启动后端前，先在 Neo4j Browser 里确认知识图谱数据已经存在，否则后面查询为空。

5.3 配置并启动后端 FastAPI

先创建 Python 虚拟环境并安装依赖：

cd backend # 创建虚拟环境，避免污染系统 Python python -m venv venv # Windows venv\Scripts\activate # Linux / macOS source venv/bin/activate # 安装依赖 pip install -r requirements.txt

如果 requirements.txt 里包含fastapi、uvicorn、langchain、neo4j、openai、sentence-transformers等常见包，国内网络环境下建议配置 pip 镜像加速：

pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

安装完成后，检查项目里是否有.env或config.py之类的配置文件。通常需要配置：

• Neo4j 连接地址、用户名、密码。
• 大模型 API Key、Base URL、模型名称。
• Embedding 模型名称或本地路径。
• 向量数据库地址。
• 运行端口。

配置完成后启动后端服务：

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

启动成功后在浏览器访问http://127.0.0.1:8000/docs，如果能看到 Swagger 接口文档页面，说明 FastAPI 后端已经正常运行。

5.4 启动前端 Vue3

打开新的终端，进入前端目录：

cd frontend # 安装依赖 npm install # 如果依赖多或网络慢，可以换淘宝镜像源 npm install --registry=https://registry.npmmirror.com # 启动开发服务器 npm run dev

启动后终端会显示本地访问地址，一般是http://localhost:5173。打开页面，如果能看到登录页或问诊对话页，说明前端已经跑起来了。

5.5 联调验证

前后端都启动后，需要确认前端能正常请求后端接口。

在 Vue3 项目中，后端地址通常配置在.env.development文件里：

# 前端开发环境配置 VITE_API_BASE_URL=http://127.0.0.1:8000

确认配置无误后，在前端页面发起一次问诊测试。如果浏览器控制台出现跨域报错，需要在 FastAPI 后端的配置中加上 CORS 中间件，允许前端地址访问：

from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins=["http://localhost:5173"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"], )

代码块示例，实际以项目现有代码为准。到这里，一套完整的“Neo4j + FastAPI + Vue3 + RAG”系统就起来了。

6. 功能测试与效果验证

系统跑通后，逐个验证核心功能。

6.1 医疗问诊对话测试

这是系统的主入口。测试步骤如下：

1. 在前端对话输入框输入“我最近头痛、发热、咳嗽，可能是什么问题？”
2. 观察前端是否返回结构化回答。
3. 观察回答中是否包含症状解释、可能疾病、建议科室。
4. 检查回答末尾是否引用知识库来源。

预期结果是：模型结合 RAG 检索到的医学文本 + 图谱查询到的关系信息，生成一段带参考依据的回答，而不是直接凭“记忆”输出。

判断成功标准：回答内容与知识库中的疾病、症状描述一致，且没有明显错误或过度断言。

如果回答质量很差，优先检查：

• 知识库文档是否成功向量化并入库。
• 检索 TopK 是否过小，比如只检索了 2 个文本块，信息量不足。
• 系统 Prompt 是否约束了回答范围。

6.2 RAG 知识库检索效果测试

如果项目提供了独立的“知识库管理”或“检索测试”页面，可以单独测试检索效果。

输入查询“高血压患者饮食注意事项”，预期能返回知识库中相关的高血压饮食建议文本块。如果没有独立页面，可以在 Python 脚本里直接调用检索函数测试：

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS # 按实际项目路径和模型名称修改 embeddings = OpenAIEmbeddings(model="text-embedding-ada-002") vectorstore = FAISS.load_local( "./vectorstore", embeddings, allow_dangerous_deserialization=True ) query = "高血压患者饮食注意事项" docs = vectorstore.similarity_search(query, k=5) for i, doc in enumerate(docs): print(f"Top {i + 1}: {doc.page_content[:100]}") print("---")

这一步主要验证两个问题：一是文档切分是否合理，二是语义检索能不能找到真正相关的文本块。如果检索结果不相关，需要检查 embedding 模型是否选对、文档内容是否和问题领域一致。

6.3 知识图谱问答测试

在 Neo4j Browser 里执行几条 Cypher 查询，验证图谱数据完整性：

// 查看所有节点类型 CALL db.labels(); // 查看所有关系类型 CALL db.relationshipTypes(); // 查询"感冒"节点及其关联关系 MATCH (d:疾病 {name: "感冒"})-[r]-(n) RETURN d.name AS disease, type(r) AS relation, n.name AS related_node LIMIT 30;

如果在 SQL 式的关系型数据库里做同样查询，需要关联疾病表、症状表、药品表、科室表，SQL 很长；而在 Neo4j 里只是几条 Cypher 语句。这也是知识图谱在关联查询上的核心优势。

如果项目前端集成了知识图谱可视化组件，在页面上应该能看到“疾病 — 症状 — 药品 — 科室”节点组成的关系图，节点可以点击展开。验证时重点看节点是否有数据、关系是否正确、图是否卡顿。

6.4 多轮对话与上下文测试

测试场景：

1. 第一轮问“我最近总是失眠”。
2. 第二轮问“应该挂什么科”。
3. 第三轮问“需要注意什么”。

预期结果是模型能识别第二轮的“应该挂什么科”是指“失眠应该挂什么科”，而不是独立回答。RAG 检索时如果只检索当前轮次问题，往往会丢失上下文，所以支持多轮对话的项目通常会增加“历史对话重写”环节，把多轮对话压缩成包含上下文的独立问题，再去做检索。

如果发现多轮效果差，改进方向有两个：一是把历史对话拼接进 Prompt，让模型理解当前问题；二是单独调用大模型把“前几轮 + 当前问题”重写为独立问题，再做检索。

6.5 知识库扩展测试

如果你有额外的医学知识文档，可以放入知识库目录，执行知识库更新脚本，再测试新内容能否被检索到。这个步骤在毕业设计中可以写成“知识库动态更新”功能，工程上很有价值。

7. 接口 API 与批量任务

FastAPI 自带 Swagger 文档，这是项目展示时很好用的一点。打开http://127.0.0.1:8000/docs，可以看到所有接口的定义、参数和返回格式，演示效果直观。

7.1 核心接口示例

项目常见的接口包括以下几个方面。以下接口路径是通用示例，实际路径以项目代码为准：

# 问诊接口示例 @app.post("/api/chat") async def chat(request: ChatRequest): # 1. 根据用户问题检索知识库 # 2. 查询知识图谱 # 3. 组装 Prompt # 4. 调用大模型生成回答 return {"answer": result} # 知识库上传接口示例 @app.post("/api/knowledge/upload") async def upload_knowledge(file: UploadFile): # 解析文档并写入向量库 return {"status": "success"} # 知识图谱查询接口示例 @app.get("/api/graph/disease/{name}") async def get_disease_graph(name: str): # 查询疾病关联关系 return {"nodes": nodes, "relations": relations}

7.2 使用 curl 测试接口

curl -X POST "http://127.0.0.1:8000/api/chat" \ -H "Content-Type: application/json" \ -d '{"question": "我最近头痛发热咳嗽，可能是什么问题？"}'

返回结果一般是 JSON 格式：

{ "answer": "根据您提供的症状信息，常见可能性包括上呼吸道感染、感冒等。建议先测量体温，多休息。如果症状持续，建议前往呼吸内科就诊。", "sources": ["doc1.pdf", "doc2.txt"], "nodes": ["感冒", "头痛", "发热"] }

7.3 使用 Python 调用接口

import requests url = "http://127.0.0.1:8000/api/chat" payload = { "question": "胃痛应该挂哪个科室？", "history": [] } response = requests.post(url, json=payload, timeout=60) data = response.json() print(data["answer"])

7.4 批量问答与数据导入

批量任务在这个项目里主要有两类。

第一类：批量文档导入。把多份医学文档放入输入目录，脚本统一加载、切分、向量化，写入向量库。建议设计成“输入目录 + 输出日志”的方式：

import os from pathlib import Path input_dir = Path("./knowledge_docs") for doc_path in input_dir.glob("*.txt"): print(f"正在处理: {doc_path.name}") # 1. 加载文档 # 2. 切分文本 # 3. 生成向量 # 4. 写入向量库 # 5. 记录日志

批量导入的关键是失败重试和日志记录。单个文件解析失败时，不应该中断整个批处理流程，而是记录错误并继续处理下一个文件。

第二类：批量问答测试。准备一组测试问题和预期关键词，批量调用接口，检查回答是否包含预期内容。这个可以用来量化评估 RAG 系统的检索准确率，写论文时很有用。

import json import time import requests BASE_URL = "http://127.0.0.1:8000/api/chat" test_cases = [ {"question": "感冒有什么症状？", "expected_keywords": ["发热", "咳嗽"]}, {"question": "头痛挂什么科？", "expected_keywords": ["神经内科"]}, {"question": "糖尿病患者饮食注意事项？", "expected_keywords": ["控糖"]}, ] for case in test_cases: resp = requests.post(BASE_URL, json={"question": case["question"]}, timeout=60) answer = resp.json().get("answer", "") hit = [kw for kw in case["expected_keywords"] if kw in answer] status = "PASS" if hit else "FAIL" print(f"[{status}] {case['question']} 命中关键词: {hit}") time.sleep(1)

8. 资源占用与性能观察

运行这套系统，资源占用主要来自四个部分：Neo4j 图数据库、Python 后端、向量检索服务和前端开发服务器。

8.1 Neo4j 资源占用

Neo4j 启动后通常会占用 1GB 到 3GB 内存，具体取决于导入的数据量。如果配置不高，可以在neo4j.conf中调低内存参数：

# 限制 Neo4j 堆内存，单位是字节或缩写 server.memory.heap.initial_size=512m server.memory.heap.max_size=1g server.memory.pagecache.size=512m

注意调低内存后，复杂 Cypher 查询可能变慢，需要根据机器配置权衡。

8.2 后端与模型推理资源占用

如果使用云端大模型 API，后端进程本身占用很小，主要内存消耗来自加载 embedding 模型和向量库。embedding 模型一般占用 1GB 到 2GB 内存。

如果使用本地大模型推理，显存占用就会大幅上升。以 7B 量化模型为例，常见情况下需要 6GB 到 10GB 显存。具体数字要按你使用的模型、量化方式和推理框架来测。

8.3 降低资源占用的手段

• 如果只做演示，优先使用云端 API，本地只跑 FastAPI。
• embedding 模型可以选更小的，比如bge-small-zh，比bge-large-zh更省内存，中文效果也不错。
• 向量检索库如果量不大，用 FAISS 本地模式就够，没必要单独部署向量数据库服务。
• Neo4j 只保留演示必要的数据，不要一次性导入海量语料。

8.4 性能观察方法

• 后端 Uvicorn 启动后，观察 Python 进程的内存变化。
• 调用批量问答脚本时，用nvidia-smi或任务管理器观察显存变化。
• 前端知识图谱渲染大量节点时，如果页面卡顿，适当限制节点返回数量，比如 Cypher 查询后面加上LIMIT 100。
• 接口响应时间可以先记录单次问答时长，再对比知识库检索命中后和未命中时的差异。

9. 常见问题与排查方法

9.1 启动与访问问题

9.2 依赖安装问题

“pip install 很慢”或“安装超时”是国内最常见的问题，换国内镜像源即可：

pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

npm 同理：

npm config set registry https://registry.npmmirror.com

如果某些包安装时要求编译，比如hnswlib、sentence-transformers的部分依赖，需要确认本机安装了对应版本的 C++ 编译工具链。安装失败时优先搜索错误信息中的关键包名。

9.3 模型与知识库问题

Neo4j 创建索引的示例：

CREATE INDEX disease_name_index FOR (d:疾病) ON (d.name); CREATE INDEX symptom_name_index FOR (s:症状) ON (s.name);

9.4 大模型调用问题

9.5 批量任务卡住

批量导入知识文档时，如果脚本长时间没有输出，很可能是单条数据解析卡住。建议给每条文档处理逻辑加上超时控制，并使用日志查看当前处理到哪个文件。批量问答测试同理，逐条打印结果而不是全部完成后一次性输出。

10. 最佳实践与使用建议

10.1 工程化建议

第一次跑通后，建议做几件事：

先保留一套最小可运行配置。把 Neo4j 连接、模型 API、向量库路径写进.env文件，提交一份.env.example到代码库，方便换机器部署。

再整理目录结构。模型文件、输入素材、输出结果分开存放。建议目录结构如下：

project/ ├── backend/ │ ├── app/ │ ├── scripts/ │ ├── requirements.txt │ └── .env ├── frontend/ │ ├── src/ │ └── package.json ├── data/ │ ├── knowledge_docs/ │ ├── graphs/ │ └── outputs/ └── README.md

RAG 调优时建议固定变量。先固定模型、固定文档，只调整 chunk_size 和检索 TopK，记录每次调整后的问答效果。不要同时改多个参数，否则无法判断是谁影响的结果。

10.2 医疗场景数据合规

医疗 AI 项目必须把合规放在第一位：

• 演示数据必须脱敏。任何真实患者姓名、身份证号、联系方式都不能出现在知识库和演示数据中。
• 使用公开医学知识库时，注意确认来源和授权。即使是公开内容，在毕业设计文档里也应该标注参考来源。
• 系统界面需要显示“AI 生成内容仅供参考，不构成医疗建议”的提示。这不是形式，而是医疗 AI 应用的基本边界。
• 如果需要接入真实医疗数据做研究，需要走正规的伦理审查和数据授权流程，不能自行采集。

10.3 答辩与演示准备

毕业设计答辩时，系统演示和论文写作都需要提前准备：

• 演示数据量控制在能“秒回”的范围。演示现场不需要展示大量数据导入过程，重点展示效果。
• 准备 2 到 3 个“有对比”的用例。比如同一个问题，直接问大模型和 RAG 增强后回答的差异。这种对比最能体现 RAG 的价值。
• 知识图谱的可视化页面值得多花时间打磨。Neo4j 图结构本身就具有展示优势，答辩时讲清楚“实体 — 关系 — 查询”的链路，比讲一堆模型结构更容易让评委理解。
• 论文里画好系统架构图和数据流程图，把 RAG 和知识图谱两条链路分别画清楚。

10.4 模型选型建议

如果你打算把大模型替换成本地部署，推荐路线是：

• 先从 “云端 API + 小 embedding 模型” 开始，尽早跑通全流程。
• 再尝试把 LLM 替换成本地模型。优先选择中文表现好的量化模型。
• 显存不足时，使用 CPU 推理或更小的量化版本，或者直接放弃本地 LLM，继续使用云端 API。

11. 总结与下一步

回到最初的问题：这个项目值不值得选作毕业设计或课程设计？答案是值得，前提是你要理解它解决的核心问题。它不是“套壳大模型”的演示项目，而是把 RAG 的知识检索、LangChain 的流程编排、Neo4j 的知识表示、FastAPI 的接口工程、Vue3 的前端交互整合成了一个完整系统。每一个环节都能展开成论文的一章，也有独立的验证方法。

最先应该验证的功能，是把“问诊问答 + 知识图谱查询”这条链路跑通。最容易踩的坑有三个：Neo4j 没启动导致图查询报错、向量库没有构建导致 RAG 检索为空、前端请求后端的跨域和地址配置不对。

下一步可以继续扩展的方向包括：接入更完整的医学知识库、增加多轮对话上下文重写、把检索结果按置信度排序、加入用户反馈按钮形成数据闭环，或者把本地大模型接入进来做纯本地部署。这些方向既可以继续作为毕业设计的深化内容，也可以作为后续简历项目的能力亮点。

如果你正在选毕业设计题目，建议直接把这个项目作为起点，先跑通，再按自己的思路做改进。跑通一个完整系统，比只看论文和教程的收获大得多。