基于知识图谱的百科知识问答系统：Django+Neo4j 智能问答平台项目实战

基于知识图谱的百科知识问答系统：Django+Neo4j 智能问答平台项目实战

文章目录

• 基于知识图谱的百科知识问答系统：Django+Neo4j 智能问答平台项目实战
• • @[TOC]
  • 一、项目简介
  • 二、项目背景与研究意义
  • 三、系统定位与核心价值
  • 四、技术栈选型说明
  • • 为什么这套技术组合适合知识图谱问答？
  • 五、系统总体架构设计
  • • 1. 表现层
    • 2. 业务逻辑层
    • 3. 数据层
    • 4. 数据构建层
  • 六、项目功能模块设计
  • • 1. 登录注册模块
    • 2. 用户管理模块
    • 3. 百科问答模块
    • 4. 图谱智能问答模块
  • 七、知识图谱问答核心流程分析
  • • 1. 问题输入
    • 2. 实体识别
    • 3. 问题分类
    • 4. 查询语句生成
    • 5. 图谱查询与答案生成
    • 6. 百科兜底补全
  • 八、知识图谱数据构建机制
  • • 项目内知识资源规模（基于源码文件统计）
    • 典型图谱关系类型
  • 九、数据库设计分析
  • • 1. MySQL 侧
    • 2. Neo4j 侧
  • 十、前端页面与交互设计
  • • 1. 登录注册页面
    • 2. 左侧导航后台布局
    • 3. 问答交互页面
    • 4. 用户管理页面
  • 十一、系统运行效果展示
  • • 1. 登录 / 注册界面
    • 2. 百科问答主页
    • 3. 百科问答结果展示
    • 4. 用户管理成功反馈
    • 5. 用户管理列表页面
  • 十二、适用场景分析
  • 十三、结语

一、项目简介

基于知识图谱的百科知识问答系统，本质上是一个面向自然语言提问场景的智能问答平台。系统以前端可视化交互页面作为入口，后端通过问题分类、实体识别、图谱查询、答案拼接与百科补全等流程，对用户输入的问题进行语义级响应，而不仅仅是字符串检索。

这不是一个只会“关键词匹配”的普通检索页面，而是一个将知识图谱、图数据库检索、规则分类问答、百科摘要补全融合在一起的智能问答系统。项目采用Django + Neo4j + py2neo + MySQL + Layui技术路线，兼顾了后台管理、用户体系、知识问答与数据构建流程，适合作为毕业设计、课程设计、知识工程项目展示与二次开发底座。

从项目源码结构来看，该系统并非单纯的静态演示，而是包含了较完整的技术闭环：

1. 基于 Django 的 Web 服务与页面渲染
2. 基于 MySQL 的用户与系统管理数据存储
3. 基于 Neo4j 的图谱型知识组织与关系查询
4. 基于ahocorasick的实体词典匹配与问题分类
5. 基于py2neo的 Cypher 查询执行
6. 基于BeautifulSoup的百科摘要兜底补全

更值得一提的是，项目内置了知识图谱构建脚本与医学领域图谱样例数据，因此它既可以被包装为“百科知识问答系统”，又具备很强的垂直领域知识问答落地能力。

二、项目背景与研究意义

在传统搜索模式下，用户提问后往往得到的是一组链接，而不是直接答案。尤其当问题带有明确语义关系时，例如：

• 某疾病有哪些症状？
• 某药物常用于治疗什么疾病？
• 某食物是否适合某类患者？
• 某个实体属于哪个类别、具有什么属性？

这类问题如果仅依赖全文检索，往往难以得到结构清晰、可解释、可追踪的结果。而知识图谱的优势恰恰在于：

1. 以实体与关系组织知识，更适合表达复杂语义；
2. 支持图查询与关系推理，能够回答“实体之间如何关联”的问题；
3. 具备较好的扩展性，可从单一领域扩展到多领域知识网络；
4. 天然适合智能问答系统构建，能够将自然语言问题映射为结构化查询。

因此，基于知识图谱构建百科问答系统，既有明显的研究价值，也有实际应用意义。对于毕业设计与项目展示而言，这类系统能够较好体现：

• 数据建模能力
• 知识工程能力
• 图数据库应用能力
• Web 全栈开发能力
• 智能问答系统设计能力

三、系统定位与核心价值

从项目现有实现来看，这套系统具备以下几个非常鲜明的价值点：

简而言之，这个项目不是“知识图谱概念演示”，而是一个能够实际运行、能够实际回答问题、能够继续扩展的知识问答平台原型。

四、技术栈选型说明

项目采用的是一条非常典型、也非常适合知识图谱问答系统教学与实战落地的技术路线。

为什么这套技术组合适合知识图谱问答？

因为它同时满足三个关键条件：

1. 图谱存储能力强：Neo4j 对实体关系表达天然友好；
2. 问答逻辑容易实现：Django 负责 Web 层，Python 负责规则与查询组装；
3. 展示与管理能力完整：相比只做命令行问答，这个项目具备完整可展示页面。

五、系统总体架构设计

从源码结构与实际功能来看，系统可以抽象为以下四层架构：

1. 表现层

表现层主要负责用户交互，包括：

• 登录 / 注册页面
• 首页导航页面
• 百科问答页面
• 用户管理页面
• 修改密码页面

这一层重点解决“用户如何提问、如何查看结果、如何管理账号”的问题。

2. 业务逻辑层

业务逻辑层是系统的核心，负责：

• 接收用户输入问题
• 调用问答主流程
• 控制查询优先级
• 在图谱无答案时转入百科兜底
• 返回最终自然语言结果

项目中的chatbot_graph.py、question_classifier.py、question_parser.py、answer_search.py共同构成了这一层的主要实现。

3. 数据层

系统采用“双数据库协同”设计：

• MySQL：保存用户数据、会话数据、权限相关数据；
• Neo4j：保存知识图谱节点、属性、关系与图谱检索结果。

这种设计能够兼顾“业务管理”和“知识推理”两类完全不同的数据结构需求。

4. 数据构建层

项目不仅有查询，还包含图谱构建逻辑，包括：

• 从medical.json读取原始知识数据
• 抽取疾病、症状、药物、食物、检查、科室、厂商等实体
• 构建实体属性
• 建立图谱关系
• 导出词典文件供问答阶段识别使用

这意味着系统不是只消费现成图谱，而是具备了知识图谱构建能力。

六、项目功能模块设计

从页面与代码实现来看，系统主要分为以下功能模块。

1. 登录注册模块

系统提供了完整的登录与注册页面，前端通过 Ajax 与后端交互，实现账户验证与用户创建。对于毕业设计类项目来说，这一点很重要，因为它让系统从“算法 Demo”升级成了“可使用的平台”。

2. 用户管理模块

用户管理模块支持：

• 按姓名模糊搜索
• 分页展示用户列表
• 新增用户
• 修改用户信息
• 删除用户

该模块增强了系统的后台管理属性，也体现了项目的工程完整性。

3. 百科问答模块

这是系统的核心展示功能。用户输入自然语言问题后，系统先走图谱问答逻辑；若图谱未命中，则尝试通过百科页面摘要进行结果补全，提升了系统回答的覆盖率与演示效果。

4. 图谱智能问答模块

这是最能体现项目技术深度的部分，其内部流程为：

用户问题 -> 实体识别 -> 问题分类 -> 查询语句生成 -> Neo4j 执行 -> 答案模板化输出

七、知识图谱问答核心流程分析

这一部分是整篇项目文章里最值得展开的内容。

1. 问题输入

用户在前端输入自然语言，例如：

• 糖尿病怎么治
• 中国的首都？
• 某疾病有哪些症状？
• 某药品治疗什么病？

2. 实体识别

系统通过词典文件加载领域关键词，包括：

• 疾病词典
• 症状词典
• 药物词典
• 食物词典
• 检查项目词典
• 科室词典
• 厂商词典
• 否定词词典

项目使用ahocorasick.Automaton()构造 AC 自动机，实现高效多模式匹配。这种做法比简单遍历字符串更适合做词典型实体识别。

3. 问题分类

系统并不是只判断“有没有实体”，而是进一步结合问句特征进行分类。例如：

• disease_symptom：疾病有哪些症状
• disease_cause：疾病成因
• disease_prevent：疾病预防方式
• disease_cureway：疾病治疗方法
• disease_drug：疾病对应药物
• disease_check：疾病相关检查
• symptom_disease：某症状可能对应什么疾病
• food_do_disease/food_not_disease：饮食建议与禁忌

这说明系统已经具备了较清晰的问答意图识别框架。

4. 查询语句生成

在识别出问题类型后，系统会自动组装对应的 Cypher 查询语句，例如：

MATCH (m:Disease)-[r:has_symptom]->(n:Symptom) WHERE m.name = '糖尿病' RETURN m.name, r.name, n.name

或者：

MATCH (m:Disease) WHERE m.name = '糖尿病' RETURN m.name, m.cure_way

这一步实际上完成了“自然语言问题 -> 图数据库查询”的映射，是整个知识问答系统的关键转换环节。

5. 图谱查询与答案生成

系统通过py2neo.Graph连接 Neo4j，并执行 Cypher 查询，随后根据不同问题类型套用不同答案模板进行输出。例如：

• “XX 的症状包括……”
• “XX 可能的成因有……”
• “XX 可以尝试如下治疗……”
• “XX 通常使用的药品包括……”

这比直接返回原始字段更友好，也更符合问答系统的交互习惯。

6. 百科兜底补全

如果图谱侧未检索到答案，系统会进一步访问公开百科搜索页，解析相关词条摘要并返回结果。这一设计使系统在演示场景下具备更高的问题覆盖率。

当然，在实际部署中，建议增加：

• 请求频率限制
• 缓存机制
• 合规抓取策略
• 异常重试与超时控制

这样会更适合生产环境。

八、知识图谱数据构建机制

很多项目只展示“查”，但这个项目同时展示了“建”。

在build_medicalgraph.py中，系统从medical.json中读取知识数据，并自动完成以下工作：

1. 抽取疾病、症状、药物、食物、检查、科室、厂商等实体
2. 为疾病节点附加描述、成因、预防方式、治愈概率、治疗周期、治疗方案等属性
3. 构建疾病与症状、药品、食物、科室、检查项目之间的关系
4. 将结构化知识导入 Neo4j
5. 导出词典数据，供问答阶段实体识别使用

项目内知识资源规模（基于源码文件统计）

以下统计来自项目内置样例数据与词典文件：

这说明项目已经具备了较有分量的知识资源基础，不是只有几十条测试数据的演示样本。

典型图谱关系类型

从构建脚本可见，系统已实现的关系主要包括：

这类关系设计已经具备较强的知识工程特征，能够支撑多样化问答。

九、数据库设计分析

项目采用关系数据库与图数据库协同设计。

1. MySQL 侧

MySQL 主要用于存储平台管理数据。从knowledge_graph.sql可以看出，系统包含 Django 默认表与自定义用户表。

其中，自定义user表主要字段包括：

这部分结构较适合支撑登录、注册、用户管理等后台功能。

2. Neo4j 侧

Neo4j 侧主要用于管理知识实体与关系网络。以疾病为例，节点属性包含：

• name
• desc
• cause
• prevent
• easy_get
• cure_way
• cure_lasttime
• cured_prob
• cure_department

这种“节点属性 + 边关系”的设计，使系统既能回答属性型问题，也能回答关系型问题。

十、前端页面与交互设计

虽然这是一个以知识图谱为核心的系统，但它的前端页面并不简陋，而是已经具备较好的演示完整性。

1. 登录注册页面

系统提供左右分栏式登录/注册一体化页面，具备明显的产品化展示风格，适合作为系统入口与答辩演示首页。

2. 左侧导航后台布局

后台采用左侧菜单 + 顶部栏 + 内容区的布局方式，包含：

• 首页
• 用户管理
• 百科问答
• 修改密码

结构清晰，符合管理系统使用习惯。

3. 问答交互页面

问答页面采用输入框 + 搜索按钮的极简交互形式，能直观展示“输入问题 - 返回答案”的核心流程。对于项目宣传来说，这种页面展示很有效，因为用户一眼就能理解系统用途。

4. 用户管理页面

用户管理页面提供了表格、分页、搜索、编辑、删除与新增功能，说明该系统具备基础的平台运营能力，而不只是一个问答接口。

十一、系统运行效果展示

下面结合项目截图，对系统界面效果做一个简要说明。

1. 登录 / 注册界面

图：系统登录与注册入口界面，采用一体化切换布局，具备较好的展示性。

2. 百科问答主页

图：问答功能主界面，用户输入问题后即可发起查询，界面简洁直接。

3. 百科问答结果展示

图：系统能够返回问题对应的文本答案，适合演示知识图谱问答效果。

4. 用户管理成功反馈

图：用户管理模块支持操作反馈提示，交互链路完整。

5. 用户管理列表页面

图：用户信息支持分页展示、搜索、编辑与删除，体现出系统的平台化属性。

十二、适用场景分析

这套系统可应用于以下方向：

十三、结语

真正有价值的项目，不只是能爬到数据，更重要的是能把数据处理清楚、分析明白、展示直观，并且具备继续扩展为完整系统的能力。

如需项目源码、部署文档、功能解析、二次开发、界面优化、项目定制、课程设计或毕业设计辅导，可通过评论区或个人主页方式交流。支持 Python 爬虫、数据分析可视化、大数据项目、算法模型、全栈系统开发与技术咨询。