MedGraph AI：医疗知识图谱驱动的 RAG 智能问答系统

想象这样一个场景：你是一名急诊科医生，深夜值班时收治了一位多药联用的老年患者。患者的病历信息分散在多个科室系统里——用药历史来自药房，检验报告来自检验科，过往诊断来自病历室。传统方式下，你需要分别登录不同系统、逐一查询，再靠人脑把这些碎片拼凑起来。这个过程不仅耗时，而且极易遗漏关键药物相互作用。

MedGraph AI 正是为解决这类问题而生。它是一个以医疗数据为中心的检索增强生成（RAG）系统，核心创新在于：用Neo4j 图数据库替代传统向量数据库，把医院、医生、患者、保险公司之间的复杂关系编织成一张可推理的知识网络，让 AI 能够像"医学专家"一样，沿着关系路径进行多跳查询，而不是简单地在文本中做关键词匹配。

背景：GraphRAG 为何更适合医疗场景

医疗数据的本质是高度关联的结构化信息。患者与医生的关系、诊断与用药的因果、检验结果与病情变化的时序——这些都不是一篇文档能描述清楚的，传统的向量检索 RAG 在面对"查找某医生最近接诊的所有服用某类药物的患者"这类多跳关系查询时力不从心。

知识图谱（Knowledge Graph）天然擅长表达这种关系网络。Neo4j 作为领先的图数据库，以 Cypher 查询语言为核心，能够高效执行多跳路径查询。将 Neo4j 与 LangChain 的 Agent 框架结合，就形成了 MedGraph AI 的技术内核：AI 代理理解用户的自然语言问题，将其转换为 Cypher 图查询，在 Neo4j 中执行推理，再结合 OpenAI 大语言模型生成最终答案。这种架构的另一个优势是可解释性——医生不仅能得到答案，还能追溯到具体的数据来源，是哪个患者、哪位医生、哪次就诊记录。这在医疗场景中至关重要，因为 AI 的每一个建议都可能影响临床决策。

核心功能：从 ETL 到智能问答的全链路

MedGraph AI 不是一个简单的问答机器人，而是一个端到端的医疗数据平台，包含三个核心模块：

hospital_neo4j_etl（数据管道）是整个系统的基础。它从外部 CSV 数据源（hospitals.csv、patients.csv、physicians.csv、visits.csv、payers.csv、reviews.csv）读取医疗数据，清洗后批量写入 Neo4j 图数据库，建立医院、医生、患者、保险公司之间的关联图谱。ETL 模块支持重试机制，确保数据导入的可靠性。对于有自己数据源的机构来说，只需将 CSV 替换为自己的数据格式，即可快速完成图谱构建。

chatbot_api（FastAPI 后端）是系统的智能核心。基于 LangChain 构建的 Agent 框架负责自然语言理解与推理。当用户输入查询（如"找出在过去三个月内接诊高血压患者最多的前五名医生"），LangChain Agent 会自动拆解任务：判断是否需要查询图数据库、生成对应的 Cypher 语句、执行查询、整合结果、调用 OpenAI 生成自然语言回答。API 层通过 Pydantic 定义了规范的数据模型，配合 Uvicorn 异步服务器，确保在生产环境下的并发性能。

chatbot_frontend（Streamlit 前端）提供了医患双方都能上手的交互界面。医生可以直接用自然语言提问，患者可以查询科室信息、医生排班、就诊评价等。Streamlit 的低代码特性使得界面开发非常高效，同时支持图表展示和会话历史管理。

技术架构：模块化设计，便于扩展

从代码结构看，三个模块各自独立解耦，通过 docker-compose 的 depends_on 声明依赖关系：ETL 先于 API 启动，API 先于 Frontend 启动。这种分层设计带来了几个明显好处：

首先，各模块可以独立开发迭代。ETL 团队可以专注于数据清洗规则，后端团队可以独立优化 Agent 提示词，前端团队可以改善用户体验，互不干扰。

其次，技术选型精准匹配各层需求。ETL 层只依赖 neo4j 驱动和重试库，轻量级；API 层引入 LangChain、FastAPI、Pydantic，侧重可扩展性和类型安全；Frontend 层使用 Streamlit，追求快速原型和交互效率。没有过度设计，也没有技术债。

第三，部署灵活性高。虽然当前使用 docker-compose 部署，但三个模块本质上是松耦合的微服务，未来可以很自然地迁移到 Kubernetes 进行容器编排，或将 ETL 替换为 Airbyte/Debezium 等专业数据集成工具。

上手体验：部署门槛与配置要点

MedGraph AI 对部署环境的要求并不高——不需要 GPU，普通云服务器即可运行。但有两个关键依赖需要注意：

OpenAI API Key 是必须的。系统使用 GPT 系列模型进行自然语言理解和生成，国内用户可能需要通过代理或 Azure OpenAI 服务来访问。

Neo4j 数据库是另一个必备组件。推荐使用 Neo4j AuraDB 云服务（有免费 tier），它提供了开箱即用的图数据库环境，无需自行维护服务器。如果对数据主权有更高要求，也可以部署本地 Neo4j Community Edition，但需要自行管理备份和扩展。

部署流程官方文档已经写得比较清晰：配置 .env 文件后执行 docker-compose up，约 10-15 分钟完成三个容器启动，之后访问 http://localhost:8501 即可看到 Streamlit 界面。整体难度评定为"中等"，适合有 Docker 使用经验的开发者。

局限与挑战：不回避的真实问题

必须指出的是，当前版本的 MedGraph AI 在以下方面存在局限：

测试覆盖不足。测试目录只包含两个请求测试文件（async_agent_requests.py、sync_agent_requests.py），没有单元测试和集成测试。对于医疗场景这类对准确性要求极高的应用，测试缺失是一个不容忽视的风险。生产部署前必须补充完整的测试套件。

无开源许可证。项目未声明任何开源许可证，这意味着法律状态不明确，限制了社区贡献和商业使用的可能性。

数据隐私风险。系统设计涉及真实的患者数据（patients.csv 包含患者信息），虽然样例数据是合成数据，但如果机构直接替换为自己的真实数据，需要确保符合 HIPAA/GDPR 等医疗数据合规要求。代码中没有内置任何脱敏或隐私保护机制。

LangChain 版本兼容性。pyproject.toml 中指定了 langchain==0.1.0，这是一个相对早期的版本。LangChain 生态仍在快速演进，生产环境使用特定版本需要锁定依赖并建立回归测试。

行业意义：GraphRAG 在垂直领域的实践范本

MedGraph AI 代表了一个重要趋势：RAG 系统的核心竞争力正在从"检索"转向"推理"。在通用领域，向量检索 + LLM 的组合已经相当成熟；但在医疗、法律、金融等关系密集型垂直领域，知识图谱驱动的 GraphRAG 正在展现出显著的优势。

Neo4j 官方也在积极推动 GraphRAG 生态，LangChain、LlamaIndex 等主流框架都已内置 Neo4j 连接器。MedGraph AI 作为开源社区的一个实践案例，虽然规模不大，但清晰展示了从数据建模（如何将医疗数据设计为图谱节点和关系）、到查询推理（LangChain Agent + Cypher）、再到前端交互（Streamlit）的完整闭环。

对于有意在医疗 AI 方向深耕的开发者，MedGraph AI 是一个值得研究的学习样本；对于有实际需求的机构，它提供了一个可落地的基础框架，在此之上可以叠加更复杂的医学推理引擎、更严格的数据安全机制、以及更丰富的多模态数据支持。