简介：本资源是一套完整的基于知识图谱的医疗问答系统毕业设计源码，面向计算机、软件工程及医学信息工程等专业的本科生与课程设计学习者，解决传统医疗咨询响应慢、专业性弱、知识关联浅等问题。压缩包共1207个文件，含33个核心Python后端模块、225个JavaScript交互脚本、176个PNG界面资源、101个CSS样式文件、41个HTML模板页，以及Neo4j图数据库原始存储文件（如neostore.*、auth、cypher-shell.bat等）和MySQL结构SQL脚本，完整覆盖前后端开发、双库部署与知识图谱构建全流程，总大小186.79MB。已有108人学习下载，资源附带详细说明文档与毕业论文（LW），涵盖环境配置（Python 3.6.8 + Django + MySQL 5.7 + Neo4j）、数据库建表逻辑、Cypher查询示例、用户认证加密实现及问答匹配算法说明，目录结构分层清晰，便于理解知识图谱在医疗语义推理中的落地实践。
1. 项目概述：一个能“听懂”医学问题的智能助手
最近几年，无论是学生做毕业设计，还是企业做原型验证，基于知识图谱的智能问答系统都是一个非常热门的方向。特别是结合医疗这个垂直领域，它的实用价值和挑战性都足够高。我手头这个项目，就是一个典型的“毕业设计级”但“五脏俱全”的实战案例：一个基于知识图谱的医疗问答系统，用Python的Django框架搭建，前后端完整，数据库用的MySQL，还附带了知识图谱构建和可视化的环节。
简单来说，这个系统要干的事，就是让用户能用自然语言（比如“糖尿病人可以吃西瓜吗？”或者“阿司匹林和布洛芬能一起吃吗？”）提问，然后系统不是去全网搜索，而是从一个结构化的“医学知识大脑”——也就是知识图谱里，精准地找到答案并组织成通顺的句子回复给你。这背后，Django负责处理用户请求和业务逻辑，MySQL存放结构化的实体和关系数据（也可以作为图谱数据的一种存储或缓存），而知识图谱则是整个系统的“智慧核心”，负责理解问题背后的语义关联。
对于计算机、软件工程相关专业的同学来说，这个项目含金量很高。它几乎覆盖了本科毕业设计所需的所有技术栈：Python基础、Web开发（Django）、数据库设计（MySQL）、以及当下最火的人工智能应用分支——知识图谱与自然语言处理（NLP）的结合。你不是在做一个简单的增删改查管理系统，而是在实现一个有一定智能交互能力的应用，这在答辩和简历上都是亮点。
2. 核心架构与设计思路拆解
2.1 为什么是“Django + 知识图谱”这个组合？
首先得明白，我们不是在从头训练一个像ChatGPT那样的通用大语言模型（LLM）。对于医疗这种专业、严谨且容错率极低的领域，直接让LLM自由发挥是危险的，它可能会“幻觉”出不存在或错误的医学知识。因此，我们的策略是“知识驱动”，而非“模型驱动”。
知识图谱的作用，就是把散乱、非结构化的医学知识（教科书、指南、药品说明书等），变成一张巨大的、相互关联的网络。在这个网络里，节点是实体（如疾病、症状、药品、检查项目），边是关系（如“疾病-包含-症状”、“药品-治疗-疾病”、“药品-禁忌-人群”）。当用户问“糖尿病人可以吃西瓜吗？”，系统需要识别出“糖尿病”是疾病实体，“西瓜”是食物实体，然后去图谱里查找“糖尿病”与“食物”之间，特别是与“西瓜”这个具体食物之间，是否存在“推荐食用”、“谨慎食用”或“禁止食用”这样的关系链。
那么，Django在这里扮演什么角色？它是一个高效、稳健的“总调度中心”。Django的MTV（Model-Template-View）模式非常适合快速构建此类系统：
- Model层：定义与MySQL数据库交互的数据结构。比如，我们可以设计
Disease（疾病）、Symptom（症状）、Medicine（药品）等模型，用于存储实体的基本属性。这些数据可以作为知识图谱的底层数据源，或者作为图谱查询结果的缓存，加速频繁问答的响应。 - View层：这是业务逻辑的核心。它接收用户通过前端提交的问题，调用后端的自然语言理解（NLU）模块和知识图谱查询模块，获取答案，再渲染给前端模板。例如，一个
question/ask/的视图函数，会处理整个问答流水线。 - Template层：负责生成用户看到的HTML页面。对于问答系统，主要是问题输入框和答案展示区域。
这个组合的优势在于，Django提供了快速开发Web服务的能力，而知识图谱提供了深度的语义理解能力，两者结合，既能快速上线一个可交互的系统，又能保证回答的专业性和准确性。
2.2 系统核心模块分解
一个完整的基于知识图谱的医疗问答系统，通常包含以下几个核心模块，我结合这个毕业设计项目，来拆解一下它们是如何协同工作的：
知识获取与构建模块：这是最基础也是最耗时的一步。我们需要医学知识。对于毕业设计，数据来源可以是公开的结构化数据集（如CMeKG、医学百科爬取的数据），或者是模拟数据。这部分代码可能包含数据爬虫（使用
requests,BeautifulSoup）、数据清洗和格式转换脚本。最终，我们需要把数据整理成“头实体-关系-尾实体”的三元组形式，例如<糖尿病， 常见症状， 多饮>。知识存储模块：三元组数据存到哪里？虽然项目标题提到了MySQL，但在知识图谱领域，图数据库（如Neo4j）才是更原生、查询效率更高的选择。一个常见的架构是：使用Neo4j存储和查询复杂的图谱关系，同时用MySQL存储实体的详细属性信息（如疾病的描述、药品的剂量），两者通过实体ID关联。在毕业设计中，为了简化，也可能全部用MySQL模拟，但会牺牲一些关联查询的便捷性。源码中需要关注
models.py的设计，看它是如何设计表结构来体现实体和关系的。自然语言理解（NLU）模块：这是系统的“耳朵”和“大脑皮层”。用户输入的自然语言问题，需要被转化为系统能理解的结构化查询。这个过程通常包括：
- 实体识别：从问题中找出医学实体。例如，从“阿司匹林能治头疼吗？”中识别出“阿司匹林”（药品）和“头疼”（症状）。可以使用预训练好的医疗领域NER模型（如BERT-CRF），或者基于词典匹配的方法（对于毕业设计，词典法更简单可控）。
- 关系抽取/意图分类：判断用户想问什么。是问“治疗方法”？还是问“症状”？还是问“禁忌”？这可以看作一个分类问题。例如，问题“糖尿病的症状有哪些？”其意图是“查询疾病的症状”。
- 查询生成：根据识别出的实体和意图，生成对知识库（图谱）的查询语句。如果用的是Neo4j，那就是生成Cypher查询语言；如果用的是MySQL，可能就是构造复杂的SQL JOIN语句或者多次查询。
知识检索与答案生成模块：执行上一步生成的查询，从知识库中获取答案的三元组或子图。然后，需要把结构化的查询结果（可能是一堆三元组）组织成通顺的自然语言句子。例如，查询得到
[<糖尿病， 常见症状， 多饮>， <糖尿病， 常见症状， 多尿>]，答案生成模块就要把它组织成“糖尿病的常见症状包括多饮、多尿等”。Web服务与交互模块：这就是Django大显身手的地方了。它提供一个Web界面（前端可以用HTML/CSS/JS，或者Vue/React简化开发），让用户输入问题，提交到后端Django的View。View调用NLU和检索模块，得到答案后，再通过Template渲染回页面展示给用户。
urls.py和views.py是这一部分的重点。
注意：在真实的工业级系统中，模块划分会更细，可能会引入问答排序、多轮对话、置信度计算等。但对于毕业设计，实现上述核心流程并稳定运行，就已经是一个优秀作品了。
3. 关键技术点深度解析与实操要点
3.1 知识图谱的构建：从数据到“图谱”
构建知识图谱是整个项目的基石。很多同学拿到项目后，最懵的就是“知识图谱数据从哪来？”。
数据来源策略： 对于毕业设计，我强烈建议采用“公开数据集 + 模拟数据”相结合的方式。
- 公开数据集：中文医学知识图谱CMeKG是一个非常好的起点。它提供了大量已经标注好的医学三元组数据。你可以直接下载它的数据，导入到你的系统中。这能保证知识的准确性和一定的规模。
- 模拟/自制数据：如果只想聚焦在系统实现逻辑上，可以自己用小规模数据模拟。比如，创建一个Excel，列分别是“实体1类型”、“实体1名称”、“关系”、“实体2类型”、“实体2名称”，手工录入几十条到几百条数据，如“疾病、感冒、有症状、症状、流鼻涕”、“药品、布洛芬、用于治疗、疾病、头痛”。然后用Python脚本（Pandas库很方便）将这些数据转换成你数据库需要的格式。
存储方案选择与实操： 如前所述，存储有两种思路：
纯MySQL方案（简化版）：设计两张核心表。
entity表：存储所有实体。字段如id（主键），name（实体名），type（实体类型，如‘disease’， ‘symptom’）。relation表：存储所有关系。字段如id，head_entity_id（头实体ID，外键关联entity.id），relation_type（关系类型，如‘has_symptom’），tail_entity_id（尾实体ID）。- 查询时，需要通过JOIN操作来“拼凑”出关系。例如，查询“感冒的症状”，SQL大概是：
SELECT e2.name FROM entity e1, relation r, entity e2 WHERE e1.name = ‘感冒’ AND e1.type = ‘disease’ AND r.head_entity_id = e1.id AND r.relation_type = ‘has_symptom’ AND r.tail_entity_id = e2.id AND e2.type = ‘symptom’;
这种方式的优点是依赖少，只用MySQL，环境配置简单。缺点是当关系复杂、查询涉及多跳时（如“治疗感冒的药有哪些副作用？”），SQL会非常复杂且效率可能较低。
Neo4j图数据库方案（推荐版）：这才是知识图谱的“正统”存储。Neo4j的查询语言Cypher非常直观，与图谱思维完美契合。
- 安装Neo4j Desktop，这是一个图形化工具，非常适合学习和开发。
- 将三元组数据（如CSV文件）通过Cypher的
LOAD CSV命令导入Neo4j。 - 查询“感冒的症状”在Cypher中极其简单：
MATCH (d:Disease {name:‘感冒’})-[:HAS_SYMPTOM]->(s:Symptom) RETURN s.name - 对于多跳查询，优势更明显：“治疗感冒的药有哪些副作用？”
MATCH (d:Disease {name:‘感冒’})<-[:TREATS]-(m:Medicine)-[:HAS_SIDE_EFFECT]->(se:SideEffect) RETURN m.name, se.name
在Django中，你需要使用
neo4j的Python驱动（pip install neo4j）来连接和操作Neo4j数据库。
实操心得：如果你的毕业设计时间紧张，想快速出效果，可以用纯MySQL方案，重点演示Web问答流程。但如果想深入技术前沿，让项目更有亮点，强烈建议上Neo4j。在答辩时，展示Neo4j自带的炫酷图谱可视化界面，能极大提升评委的印象分。你可以在项目中同时使用两种数据库：Neo4j处理核心图谱关系查询，MySQL存储用户信息、问答历史日志等业务数据。
3.2 自然语言理解（NLU）模块的实现策略
这是项目的“智能”所在，也是难点。完全自己训练深度学习模型对本科生来说挑战较大，因此我们需要采用务实、高效的策略。
实体识别（NER）的简易实现： 对于垂直领域，基于词典和规则的方法往往比通用模型更精准、更快速。
- 构建领域词典：从你的知识图谱中，提取出所有实体名称，按类型（疾病、药品、症状等）整理成多个词典文件（如
disease_dict.txt，每行一个病名）。 - 使用AC自动机进行高效匹配：AC自动机是一种多模式串匹配算法，能一次性扫描问题文本，快速找出里面包含的所有词典中的实体词。Python有
ahocorasick库可以实现。import ahocorasick def build_actree(wordlist): actree = ahocorasick.Automaton() for index, word in enumerate(wordlist): actree.add_word(word, (index, word)) actree.make_automaton() return actree # 使用：遍历问题句子，用actree.iter(question)即可得到所有匹配到的实体及其位置。 - 解决歧义与重叠：一个词可能属于多个实体类型（如“苹果”可能是水果也可能是公司），或者长实体包含短实体（“Ⅱ型糖尿病”包含“糖尿病”）。简单的策略是优先选择更长的匹配，并结合上下文进行简单判断。
意图分类的简易实现： 我们可以将医疗问答意图归纳为有限的几类，如query_symptom（查症状）、query_treatment（查治疗）、query_compatibility（查配伍禁忌）、query_cause（查病因）等。
- 定义意图模式：为每种意图编写一些关键词或模式规则。
query_symptom: 包含“症状”、“表现”、“有什么感觉”等词，且主语是疾病实体。query_treatment: 包含“怎么治”、“治疗方法”、“吃什么药”、“手术”等词。query_compatibility: 包含“能不能一起吃”、“同时服用”、“禁忌”等词，且包含至少两个药品或药品与食物实体。
- 规则匹配：对用户问题进行分析，匹配上述规则。可以使用正则表达式，或者更灵活地，计算问题与各意图关键词集的相似度（如Jaccard相似度）。
- 结合机器学习（进阶）：如果想让系统更智能，可以收集或生成一批标注了意图的训练数据（问题-意图标签），使用
scikit-learn的文本分类模型（如SVM、朴素贝叶斯）或者简单的BERT微调来进行意图分类。这对于毕业设计是很好的加分项。
查询生成： 这是将NLU结果“翻译”成数据库查询语言的过程。我们需要一个“模板”或“规则”引擎。
- 输入：识别出的实体列表
[{'entity': '糖尿病', 'type': 'Disease'}, ...]和 意图query_symptom。 - 处理：根据意图和实体类型，选择预定义的Cypher或SQL查询模板。
- 输出：将实体名称填充到模板中，生成可执行的查询语句。 例如，对于意图
query_symptom和疾病实体‘糖尿病’，对应的Cypher模板是：MATCH (d:Disease {name:‘[实体名]’})-[:HAS_SYMPTOM]->(s:Symptom) RETURN s.name。将‘糖尿病’填充进去即可。
3.3 Django后端与前端交互的工程化实现
有了核心算法模块，我们需要用Django把它们“粘合”起来，并提供Web接口。
项目结构规划： 一个清晰的Django项目结构至关重要。我建议这样组织：
medical_qa_project/ ├── manage.py ├── medical_qa/ # 主应用 │ ├── __init__.py │ ├── settings.py # 配置数据库（MySQL和Neo4j）、静态文件等 │ ├── urls.py # 项目级URL路由 │ └── wsgi.py ├── kg_core/ # 知识图谱核心模块（Python包） │ ├── __init__.py │ ├── ner.py # 实体识别代码 │ ├── intent.py # 意图分类代码 │ ├── query_generator.py # 查询生成代码 │ └── answer_generator.py # 答案生成代码 ├── qa_app/ # 问答主应用 │ ├── migrations/ │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── models.py # 定义MySQL模型（用户、日志等） │ ├── views.py # 核心视图，处理问答请求 │ ├── urls.py # 应用级路由 │ └── templates/ # 前端模板 │ └── qa_app/ │ ├── index.html # 主页，问答界面 │ └── result.html # 答案展示页 └── data/ # 存放词典、数据文件等 ├── disease_dict.txt └── ...核心视图（View）逻辑： 在qa_app/views.py中，核心的问答视图函数可能如下所示：
from django.shortcuts import render from django.http import JsonResponse # 如果采用前后端分离，则用JsonResponse from kg_core.ner import EntityRecognizer from kg_core.intent import IntentClassifier from kg_core.query_generator import QueryGenerator from kg_core.answer_generator import AnswerGenerator import neo4j # 或使用MySQL连接 # 初始化各个模块（可以使用单例模式或Django的启动信号来优化） ner = EntityRecognizer() intent_clf = IntentClassifier() query_gen = QueryGenerator() answer_gen = AnswerGenerator() # 连接知识库 graph_db = neo4j.GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password")) def ask_question(request): if request.method == 'POST': question_text = request.POST.get('question', '').strip() if not question_text: return render(request, 'qa_app/index.html', {'error': '问题不能为空'}) # 1. 实体识别 entities = ner.recognize(question_text) # 2. 意图分类 intent = intent_clf.classify(question_text, entities) # 3. 查询生成 query = query_gen.generate(intent, entities) # 4. 执行查询 with graph_db.session() as session: result = session.run(query) data = [record for record in result] # 获取结果数据 # 5. 答案生成 answer_text = answer_gen.generate(intent, entities, data) # 6. 记录日志（可选，存入MySQL） # QuestionLog.objects.create(question=question_text, answer=answer_text, ...) # 返回结果，渲染到模板 context = { 'question': question_text, 'answer': answer_text, 'entities': entities, # 前端可以高亮显示识别出的实体 'intent': intent, } return render(request, 'qa_app/result.html', context) # GET请求则返回问答页面 return render(request, 'qa_app/index.html')前端交互： 前端可以很简单，一个表单足矣。如果想提升体验，可以使用jQuery或Vue.js实现异步提交（Ajax），在不刷新页面的情况下获取并显示答案。在index.html中：
<form id="qa-form"> {% csrf_token %} <input type="text" name="question" placeholder="请输入您的医疗问题，例如：感冒的症状有哪些？" style="width: 80%;"> <button type="submit">提问</button> </form> <div id="answer-area"></div> <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script> <script> $(‘#qa-form’).on(‘submit’, function(e) { e.preventDefault(); var formData = $(this).serialize(); $.post(‘{% url "ask_question" %}’, formData, function(data) { // 假设后端返回JSON，更新#answer-area $(‘#answer-area’).html(‘<h3>答案：</h3><p>’ + data.answer + ‘</p>’); }, ‘json’); }); </script>4. 完整部署与测试流程实录
4.1 本地开发环境搭建步骤
假设你从零开始，拿到一个类似的项目源码压缩包（基于知识图谱的医疗问答系统(django)源码.zip），你应该如何把它跑起来？
解压与预览：解压文件，先用文本编辑器或IDE（如VSCode、PyCharm）打开项目根目录。快速浏览
README.md（如果有）和requirements.txt文件，了解项目依赖。创建虚拟环境（强烈推荐）：在项目根目录打开终端（命令行）。
# 使用venv创建虚拟环境 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate激活后，命令行提示符前会出现
(venv)字样。安装依赖：
pip install -r requirements.txt如果项目没有
requirements.txt，你需要根据代码判断并手动安装，通常包括：Django,mysqlclient或pymysql,neo4j,ahocorasick,pandas,numpy等。可以用pip install django mysqlclient neo4j ahocorasick逐个安装。数据库配置与迁移：
- MySQL：确保本地安装了MySQL，并创建一个数据库（如
medical_qa）。然后修改Django项目的settings.py文件中的DATABASES配置，填入你的数据库名、用户名和密码。 - 执行迁移：在终端运行以下命令，Django会根据
models.py创建数据表。python manage.py makemigrations python manage.py migrate - Neo4j：下载并安装Neo4j Desktop，创建一个新的数据库，设置好密码（默认用户是
neo4j）。记住Bolt连接地址（通常是bolt://localhost:7687）和密码。在Django代码中（通常在settings.py或单独的配置文件中）配置这个连接信息。
- MySQL：确保本地安装了MySQL，并创建一个数据库（如
导入知识图谱数据：这是关键一步。找到项目里提供的数据文件（可能是
data/triples.csv或.json文件）。编写一个数据导入脚本（例如import_data.py），使用Neo4j的Python驱动或SQL语句，将数据批量插入到图数据库或MySQL中。如果源码包中已有此脚本，直接运行它。加载词典与模型：运行项目前，确保NER和意图分类模块所需的词典文件（如
disease_dict.txt）放在正确的路径（如data/目录下），并且代码中的文件读取路径是正确的。如果是机器学习模型，确保模型文件存在。运行开发服务器：
python manage.py runserver在浏览器中访问
http://127.0.0.1:8000，你应该能看到系统的前端界面。尝试输入几个问题，测试核心功能是否正常。
4.2 核心功能测试用例与效果评估
系统跑起来后，不能只问一两个问题就完事。需要设计系统的测试用例，来评估其效果和健壮性。你可以从以下几个维度设计测试问题：
| 测试类型 | 示例问题 | 预期结果 | 测试目的 |
|---|---|---|---|
| 简单单实体查询 | “糖尿病的症状是什么？” | 返回糖尿病相关的症状列表，如多饮、多尿、消瘦。 | 测试基础实体识别和单跳关系查询。 |
| 多实体/关系查询 | “阿司匹林和布洛芬能一起吃吗？” | 应识别出两个药品实体，意图为“配伍禁忌查询”，并从图谱中查找两者是否存在相互作用关系。 | 测试多实体识别、复杂意图判断和多跳查询。 |
| 实体歧义 | “苹果（指水果）对健康有什么好处？” vs “苹果（指公司）发布了新产品” | 在医疗上下文中，应正确将“苹果”关联到“水果”实体，并查询其营养价值等关系。 | 测试NER的消歧能力（如果系统有上下文处理）。 |
| 意图边界 | “我最近头疼，可能是什么病？” | 这属于诊断咨询，超出了知识图谱事实问答的范围。系统应友好提示“本系统仅提供医学知识查询，无法进行诊断，请及时就医。” | 测试系统的意图处理边界和回复策略。 |
| 未登录词/关系 | “量子波动对感冒有疗效吗？” | “量子波动”不是医学实体，或图谱中没有此关系。系统应回复“未找到相关信息”或给出相近实体提示。 | 测试系统的鲁棒性和友好性。 |
| 长句、口语化 | “我奶奶有高血压，平时吃那个硝苯地平，最近老是咳嗽，跟这个药有关系不？” | 应识别出“高血压”（疾病）、“硝苯地平”（药品）、“咳嗽”（症状），意图是查询药品副作用，并查找“硝苯地平”是否可能导致“咳嗽”。 | 测试NLU模块对复杂句子的处理能力。 |
在测试过程中，详细记录系统的返回结果，分析错误原因：是实体没识别出来？还是意图判断错了？或者是图谱里根本没有这条知识？根据测试结果，回头去优化对应的模块，比如补充词典、增加意图规则、完善图谱数据。
5. 常见问题排查与项目优化方向
在实际开发和答辩演示中，你肯定会遇到各种各样的问题。这里我总结几个最常见的坑和解决办法。
5.1 开发与部署中的典型问题
MySQL连接错误：
django.db.utils.OperationalError: (2003, “Can’t connect to MySQL server”)- 原因：MySQL服务没启动，或者Django配置中的主机、端口、用户名、密码错误。
- 解决：
- 确保MySQL服务已运行（Windows在服务中查看，Linux/Mac用
sudo systemctl status mysql）。 - 检查
settings.py中的DATABASES配置，HOST如果是本地，通常是‘localhost’或‘127.0.0.1’。 - 确认数据库用户有远程或本地连接权限（对于本地开发，通常用root用户即可，但生产环境务必创建专用用户）。
- 确保MySQL服务已运行（Windows在服务中查看，Linux/Mac用
Neo4j连接错误：
ServiceUnavailable: Failed to establish connection to res://localhost:7687- 原因：Neo4j数据库没启动，或Bolt协议端口（默认7687）被防火墙阻止，或认证失败。
- 解决：
- 打开Neo4j Desktop，确保你的数据库状态是“Running”。
- 点击“Manage” -> “Settings” -> “Connection Settings”，确认Bolt端口号。
- 在Python连接代码中，使用正确的密码。Neo4j Desktop创建的数据库，密码是你自己设置的。
Django静态文件（CSS, JS, 图片）无法加载
- 原因：开发环境下，Django的
runserver会自动处理静态文件，但需要正确配置STATIC_URL和STATICFILES_DIRS。如果使用了DEBUG=False，则需要收集静态文件。 - 解决：
- 确保
settings.py中DEBUG = True（开发时）。 - 检查
STATIC_URL = ‘/static/’。 - 在模板中引用静态文件要使用
{% load static %}标签，如<link href=“{% static ‘css/style.css’ %}” rel=“stylesheet”>。 - 如果问题依旧，运行
python manage.py collectstatic命令收集静态文件。
- 确保
- 原因：开发环境下，Django的
中文编码或乱码问题
- 场景：从文件读取词典、网页显示、数据库存储时出现乱码。
- 解决：
- 在Python文件开头统一使用
# -*- coding: utf-8 -*-。 - 读写文件时，明确指定编码：
open(‘file.txt’, ‘r’, encoding=‘utf-8’)。 - 确保MySQL数据库、表和字段的字符集是
utf8mb4（支持所有Unicode字符，包括表情符号）。 - 在Django的
settings.py中，设置DEFAULT_CHARSET = ‘utf-8’。
- 在Python文件开头统一使用
5.2 项目深度优化与扩展思路
如果你的基础功能已经实现，想让项目更出彩，可以从以下几个方向进行优化和扩展：
引入词向量与语义匹配：当前的词典匹配NER对未登录词（新词）无能为力。可以引入预训练的词向量（如腾讯AI Lab的中文词向量），计算问题中的词与词典中词的余弦相似度，进行模糊匹配。对于意图分类，也可以使用句子向量（如Sentence-BERT）来计算问题与各意图示例句子的相似度，比单纯的关键词匹配更智能。
结合RAG与LLM提升答案生成质量：这是当前最前沿的方向之一。你可以保留知识图谱作为“精准事实检索器”，然后将检索到的三元组信息作为上下文（Context），输入给一个开源的大语言模型（如ChatGLM、Qwen、Llama的本地部署版），让LLM来组织生成更流畅、更人性化的答案。这构成了一个简单的RAG（检索增强生成）系统。这能极大改善“答案生硬”的问题。例如，图谱返回
[<硝苯地平， 可能引起副作用， 咳嗽>， <硝苯地平， 属于， 钙通道阻滞剂>]，LLM可以生成：“硝苯地平是一种钙通道阻滞剂类降压药，其常见的副作用之一就是引起咳嗽。如果您的奶奶在服用此药后出现咳嗽，需要警惕可能是药物副作用所致，建议咨询医生是否需要调整用药方案。”实现简单多轮对话：目前的系统是单轮问答。可以增加对话状态管理。例如，用户问“高血压有什么症状？”，系统回答后，用户接着问“那该怎么治疗呢？”。系统需要记住上一轮对话的焦点实体（“高血压”），将当前问题“那该怎么治疗呢？”与上一轮上下文结合，生成查询“高血压的治疗方法”。这需要在Django的Session中存储对话历史或焦点实体。
增加知识图谱可视化展示：在返回答案的同时，将查询涉及的知识子图用图形化方式展示出来。可以使用ECharts、D3.js或Neo4j自带的可视化组件。这不仅能提升系统观感，也能让用户更直观地理解知识间的关联。你可以在答案页面嵌入一个区域，通过Ajax请求后端，后端从Neo4j查询出相关的节点和关系数据，以JSON格式返回给前端，前端再用图形库渲染。
构建Web管理后台：使用Django强大的Admin功能，快速搭建一个后台管理界面，用于管理知识图谱的数据（增删改查实体和关系）、查看用户问答日志、监控系统运行状态等。这能让你的项目看起来更完整、更专业。
这个项目就像一个精密的仪器，每一个模块都需要仔细调试。从数据准备到算法实现，再到Web集成，每一步都可能遇到坑。但正因为如此，当你最终看到系统能正确回答出一个医学问题时，那种成就感是无与伦比的。它不仅仅是一个毕业设计，更是一个你亲手构建的、具备实用价值的智能系统原型。
本文还有配套的精品资源，点击获取
