企业官网建设流程全解析

简介：面向毕业设计和项目实战的医疗领域知识图谱问答系统资料包，基于Python语言实现，完整覆盖医疗知识图谱的构建、实体关系抽取、意图识别以及问答匹配等核心环节。包内共含一千四百零三个文件，主要有Python源码、医疗数据文件、深度学习模型文件，以及Java与XML辅助代码，并附有论文资料和说明文档，压缩包约三十八点七二兆字节，文件按模块组织，层次分明，便于查阅。其中Python源码实现问答主流程，JSON与CSV提供医疗数据支撑，H5文件保存模型，Java与XML辅助完成界面和服务。该项目为个人毕业设计，经导师指导并获评审九十八分，所有源码均经过本地编译与调试，能够直接运行，适合计算机相关专业学生完成毕业设计或课程大作业，也适合需要项目实战经验的开发者参考学习。目前已有一百零二人学习下载，配套的论文和文档能帮助深入理解医疗问答系统的整体架构、设计思路与实现细节，整体性价比高。

1. 医疗知识图谱问答系统拆解：一个“实体+关系+模板查询”就够用的毕业设计

医疗“智能问答系统”听上去像要上大模型，但把知识图谱这套拆开看，核心其实是三件事：把疾病、症状、药物、科室这些医疗实体抽出来，把“疾病-症状”“疾病-用药”这类关系存进 Neo4j；把用户的自然语言问句解析成“实体 + 意图”；再照着意图模板拼 Cypher 查图谱、返回人话答案。基于 python 知识图谱医疗领域问答系统实现，就是这三件事串成的一条链路，数据量只有几千条也能跑出像样的效果。这套方案特别适合毕业设计和课程设计：不用微调大模型，不用堆几百条问答对，一份完整代码加数据就能把“构建图谱 → 问答 → 论文图表”全流程走通。python 安装、pycharm 配置 python 环境这类前置动作这里不展开，我默认你的 Neo4j 和本地 python 环境已经能正常跑脚本。

2. 医疗知识图谱构建：从百科数据清洗到本体建模与三元组导出

问答系统的效果上限不取决于算法，取决于图谱里到底存了什么。这一章先把“要存什么、怎么存”定下来，再给出清洗脚本和导出文件，后面所有 Cypher 都是在这两张表上做文章。

2.1 本体建模先行：实体、关系、属性三层怎么定

常见的毕设级医疗图谱只做 6 类实体：疾病（Disease）、症状（Symptom）、药物（Drug）、科室（Department）、检查（Check）、食物（Food）。不要一上来就建模“养生”“护理”“并发症”这些边角关系，否则数据清洗阶段你会被空字段拖死。核心关系全部围绕疾病展开：

属性这里留三个就够：name 是标准实体名，alias 用于存放同义词，first_letter 存拼音首字母。这三个属性不是摆设：问答系统做实体链接时，先匹配 name，再匹配 alias，最后用 first_letter 兜底处理“高血压病”这类带后缀的写法。本体建模阶段多花十分钟维护 alias，比在问答逻辑里写一堆 if 强得多。

数据来源常见做法是抓公开医疗百科的结构化字段，落成一张宽表：每一行是一种疾病，列是症状、用药、科室、忌口、检查。抓回来的原始宽表不能直接用，原因有三个：一个单元格里塞了多个症状，用顿号、逗号、空格混着分隔；同一症状在不同行里有“头晕”“头昏”“眩晕”多种写法；科室名、药名存在全角半角混用。

2.2 数据清洗与同名异形处理：用 pandas 把宽表拆成明细三元组

拿到原始表 raw_medical.csv 后，第一步不是写 Neo4j 导入语句，而是用 pandas 做标准化。注意原始文件大概率是 utf-8 或 gbk，如果你在 Windows 上从 Excel 另存过，编码极可能是 ANSI，这里先统一用 utf-8 读，读失败再尝试 gbk。

import re import pandas as pd df = pd.read_csv("raw_medical.csv", encoding="utf-8") df.columns = [c.strip() for c in df.columns] for col in ["disease", "symptom", "medicine", "department", "forbidden_food", "check"]: df[col] = df[col].fillna("").astype(str) df = df[df["disease"] != ""].drop_duplicates(subset="disease") def split_field(text: str) -> list[str]: # 兼容中文逗号、顿号、分号、空格、斜杠 return [x.strip() for x in re.split(r"[,，、;；/]|\s+", text) if x.strip()] rows = [] for _, row in df.iterrows(): for sym in split_field(row["symptom"]): rows.append({"disease": row["disease"], "relation": "has_symptom", "object": sym, "object_category": "症状"}) for med in split_field(row["medicine"]): rows.append({"disease": row["disease"], "relation": "treat_with", "object": med, "object_category": "药物"}) for dep in split_field(row["department"]): rows.append({"disease": row["disease"], "relation": "recommend_department", "object": dep, "object_category": "科室"}) triple_df = pd.DataFrame(rows) print(triple_df.groupby("relation").size())

这个脚本的核心逻辑是把“宽表”拉成“长表”：每一条三元组变成一行，disease 是主语，relation 是关系类型，object 是宾语。split_field 函数用正则统一处理顿号和中文逗号，这是最容易漏的地方——很多人只按英文逗号切，结果“头晕,头痛、心悸”里的“头痛、心悸”变成一整串，图谱里出现一个根本不存在的复合症状。

groupby 打印出来的数量要重点看两个数：has_symptom 的数量级是否合理，recommend_department 是不是接近 0。如果某类关系几乎为空，说明原始数据里该字段本身缺失严重，先去补数据源，不要硬着头皮往下导，否则问答系统永远答不出“挂什么科”。

2.3 导出 Neo4j 能直接消费的节点表与关系表

清洗只是把数据理顺，还得把它整理成 Neo4j 能高效加载的格式。有人喜欢把宽表直接变成属性塞进节点，我建议你导出两个独立的 CSV：一个是实体表，一个是关系表。这样后续想加实体类型、加关系类型，都不用动导入脚本。

实体表字段这样设计：

关系表字段这样设计：

导出脚本里有个容易被忽略的环节是给实体生成稳定 id。直接用疾病名当 id 会导致“高血压”作为疾病节点和“高血压”作为症状节点冲突，所以我一般用 name 加 category 拼起来做哈希。

import hashlib def make_entity_table(triple_df: pd.DataFrame) -> pd.DataFrame: records = [] for _, row in triple_df.iterrows(): records.append({"name": row["disease"], "category": "疾病"}) records.append({"name": row["object"], "category": row["object_category"]}) ent = pd.DataFrame(records).drop_duplicates(subset=["name", "category"]) def gen_id(row): raw = f"{row['name']}|{row['category']}" return hashlib.md5(raw.encode("utf-8")).hexdigest()[:16] ent["entity_id"] = ent.apply(gen_id, axis=1) ent["alias"] = "" # 后续人工或规则补充，如 高血压|高血压病 ent["first_letter"] = ent["name"].map( lambda s: "".join([w[0].upper() for w in lazy_pinyin(s) if w]) ) return ent

pypinyin 库要先 pip install，如果离线环境装不了，first_letter 字段可以先留空，不影响主流程，只是失去一个兜底匹配手段。alias 字段建议从原始数据里自动收集：把“高血压病”“高血压”这类带后缀的写法用规则抽取出来，合并进该字段，分隔符统一用竖线。

导出实体表和关系表时统一用 utf-8-sig 编码。很多人在这里踩坑，后面避坑章会详细说。

3. 把数据灌进 Neo4j：批量导入、索引创建与三类验证查询

CSV 准备好之后，接下来的事就是把它送进 Neo4j。这里有一个和直觉相反的结论：不要用 python 循环一条条 CREATE，几万条三元组你会等到怀疑人生，而且断点续跑会重复建节点。批量导入的正确姿势是 LOAD CSV。

3.1 用 LOAD CSV 批量写入，而不是一条条 CREATE

先把实体表放进 Neo4j 的 import 目录。不同安装方式目录不同，常见位置是安装目录下的 import 文件夹。文件放好后执行：

LOAD CSV WITH HEADERS FROM "file:///medical_entity.csv" AS row CREATE (e:Entity { entity_id: row.entity_id, name: row.name, category: row.category, alias: row.alias, first_letter: row.first_letter });

注意这里用 CREATE 而不是 MERGE，因为第一次导入时实体表里没有重复 id。如果脚本跑一半中断，重跑时 CREATE 会生成重复节点。稳妥做法是先建唯一约束再导入：

CREATE CONSTRAINT entity_id_unique IF NOT EXISTS FOR (e:Entity) REQUIRE e.entity_id IS UNIQUE;

这是 Neo4j 5.x 的写法，4.x 里把 REQUIRE 换成 ASSERT 即可。约束建好后，重复导入会直接报错而不是静默堆积，这个报错就是你的后悔药。

关系表导入要处理一个动态关系类型问题：relation 列里有 has_symptom、treat_with 等好几种，Neo4j 不能用变量直接当关系类型。两个方案：装 APOC 插件后一行搞定动态关系；不装 APOC 就把每种关系拆成一条 LOAD CSV 语句。我优先推荐 APOC，它省代码、也方便后期扩展关系类型：

LOAD CSV WITH HEADERS FROM "file:///medical_relation.csv" AS row MATCH (s:Entity {entity_id: row.subject_id}) MATCH (o:Entity {entity_id: row.object_id}) CALL apoc.create.relationship(s, row.relation, {}, o) YIELD rel RETURN count(rel);

如果你不想引入 APOC，就把关系表按 relation 列拆开，分别写：

LOAD CSV WITH HEADERS FROM "file:///medical_relation.csv" AS row WITH row WHERE row.relation = "has_symptom" MATCH (s:Entity {entity_id: row.subject_id}) MATCH (o:Entity {entity_id: row.object_id}) MERGE (s)-[:has_symptom]->(o);

这段脚本的语义是先过滤出 has_symptom 类型，再找到两端节点，最后 MERGE 关系。MERGE 在这里的价值是幂等——同一组实体重复执行也不会产生两条关系。数据量上万行时，建议给 LOAD CSV 加 PERIODIC COMMIT 或使用 CALL {} IN TRANSACTIONS 分批提交，避免一个超大事务把内存打满。

3.2 py2neo 连接、索引创建与连接验证

数据灌完后，用 py2neo 连接 Neo4j 验证一下。py2neo 的 Graph 对象是所有问答查询的入口：

from py2neo import Graph graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) # 验证连接并确认实体数量 result = graph.run("MATCH (e:Entity) RETURN count(e) AS cnt").data() print(result)

连接串里 bolt://localhost:7687 是 Neo4j 默认的 Bolt 端口，如果改过配置，以你本机为准。auth 里 neo4j 是默认用户名，密码是你在初始化 Neo4j 时设置的，不是浏览器页面上临时改的那个可视化密码。

连上之后立刻创建两个索引，问答阶段最频繁的查询就是按 name 和 alias 精确匹配：

graph.run("CREATE INDEX entity_name_idx IF NOT EXISTS FOR (e:Entity) ON (e.name)") graph.run("CREATE INDEX entity_alias_idx IF NOT EXISTS FOR (e:Entity) ON (e.alias)")

索引不是越多越好。初学者很容易给 first_letter 也建索引，但我们的查询基本都是精确匹配，不会用它做范围扫描，建了反而拖慢写入。如果后面想按 category 统计数量，可以再补一个 category 索引，这会直接决定你后续问答系统的响应速度。

3.3 跑通三类验证查询：实体邻接、属性回填、路径查询

导入完成不等于万事大吉，我习惯先跑三类查询验证图谱质量，这三类查询也分别对应问答系统的三种能力。

第一类是实体邻接查询，看某个实体周围连了什么：

MATCH (d:Entity {name: "高血压"})-[r]-(n:Entity) RETURN d.name, type(r) AS relation, n.name LIMIT 50;

这个查询用来快速判断“高血压”节点是否连接了症状、药物、科室。如果返回结果全是 has_symptom，说明其他关系没导进去，问题多半出在关系表过滤逻辑上。

第二类是属性回填查询，验证 alias 和 first_letter 是否写进节点：

MATCH (e:Entity {name: "高血压"}) RETURN e.name, e.alias, e.first_letter;

这里要重点看 alias 字段是否真实存在值。如果 alias 为空，问答系统遇到“高血压病”就无能为力，而现在补救还来得及：回到实体表，把别名合并进 alias，重新导入。

第三类是路径查询，这是问答系统做解释型答案的基础：

MATCH path = (d:Entity {name: "高血压"})-[:has_symptom|treat_with|recommend_department*1..2]-(n) RETURN path LIMIT 30;

路径深度限制在 1 到 2 是有意的：医疗问答需要跨一跳查询，比如“高血压用什么药”可能经过 疾病 → 症状 → 药物 的路径，但超过两跳会引入大量无关分支，答案变得不可解释。这条查询跑出来的路径数量也能侧面反映图谱密度，如果返回为 0，说明关系类型名和查询模板里的不一致，常见于 LOAD CSV 导入时关系名被空格或大小写污染。

4. 问答引擎实现：意图识别、实体链接到 Cypher 生成的完整链路

前面两章把图谱准备好了，这部分才是“基于 python 知识图谱医疗领域问答系统”的核心区块。问答引擎的常见做法不是上了不起的模型，而是三段式流水线：意图识别 → 实体识别与标准化 → Cypher 组装与答案渲染。每一步都不难，但每一步都有参数和边界要说明。

4.1 意图识别：正则模板覆盖四类高频问句

毕业设计级问答系统最常见的意图就是症状、用药、科室、忌口、检查五类。选型上我建议用正则模板而不是训练分类模型：原因很实在，规则可解释、好调试，答辩时你能当场讲清楚“高血压吃什么药”为什么命中医嘱意图；而训练一个意图分类模型需要标注至少几千条问句，毕设周期撑不住。等后期数据量上来了，再换 BERT 分类不迟。

意图识别的实现用一组预编译的正则：

import re INTENT_PATTERNS = [ ("medicine", [ r"(?:吃|用|服用).{0,10}(?:什么|哪些)(?:药|药物)", r"(?:什么|哪些)(?:药|药物)(?:能|可以)?(?:吃|用|服用)" ]), ("symptom", [ r"(?:什么|哪些)(?:症状|表现|征兆)", r"(?:症状|表现)是(?:什么|怎么样的)" ]), ("department", [ r"(?:挂|去)(?:什么|哪个)科", r"(?:什么|哪个)(?:科室|科)" ]), ("forbidden", [ r"(?:不能|不可以|不要|忌)(?:吃|食用)", r"(?:什么|哪些).{0,8}不能吃" ]), ("check", [ r"(?:做|查)(?:什么|哪些)(?:检查|项目)", r"(?:需要|应该)(?:做|查)什么检查" ]), ] def parse_intent(question: str) -> str: for intent, patterns in INTENT_PATTERNS: for pattern in patterns: if re.search(pattern, question): return intent return "symptom" # 兜底意图，避免后续流程崩溃

正则顺序是有讲究的，medicine 必须放在最前面。“高血压吃什么药”这个句子同时包含“吃”和“什么”，如果不先匹配 medicine，symptom 模板里的“什么……症状”不会命中，但“吃什么药”里的“什么药”可能被 department 模板误判——所以越具体的意图越要前置。兜底返回 symptom 是刻意设计，让“高血压”这种纯实体问句至少能走一次查询，而不是直接提示“无法识别意图”。

参数说明：正则里的.{0,10}控制实体和疑问词之间的距离，距离设太大会把“高血压患者平常应该注意什么并吃什么药比较好”这种长句也归为 medicine，设太小又会漏掉带修饰语的说法。我一般把距离卡在 0 到 8 个字符之间，兼顾覆盖率和准确率。

4.2 实体识别与标准化：别名表、拼音首字母与最长匹配

意图只解决了“用户想问什么”，还得知道“用户在问哪个实体”。医疗问句里实体通常就是一个疾病名或症状名，且大多是图谱里有的标准名或别名。我常用的方案是把图谱里的 name 和 alias 都拉出来构建词典，按长度倒序排列后做最左最长匹配。

from py2neo import Graph graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) def load_entity_dict(graph: Graph) -> list[str]: names = set() for record in graph.run( "MATCH (e:Entity) RETURN e.name AS name, e.alias AS alias" ): names.add(record["name"]) if record["alias"]: for item in str(record["alias"]).split("|"): item = item.strip() if item: names.add(item) return sorted(names, key=len, reverse=True) ENTITY_DICT = load_entity_dict(graph) def extract_entity(question: str, entity_dict: list[str]) -> str | None: for name in entity_dict: if name and name in question: return name return None

这里的核心技巧是“按长度倒序”的字典序。如果不排序，词典里“高血压”排在“高血压病”前面，问句“高血压病吃什么药”会先匹配到“高血压”，虽然也能查，但查出来的结果可能是标准实体名的数据，丢掉“高血压病”特有的信息。倒序排列后，优先匹配最长实体名，命中率明显更高。

实体词典加载需要一次全表扫描，几千实体量级毫秒级完成，不用优化。如果实体量到几十万，就把词典缓存到本地文件或 Redis，每次服务启动先加载快照。

这里有个边界情况要说明白：一个问句可能包含两个实体，比如“高血压和糖尿病都要注意什么”。规则系统一般只取第一个实体，因为后续 Cypher 组装按单实体设计。处理这种问句的常见做法是拆句，拆成两个独立问句分别查询，再合并答案，毕业设计阶段可以先不做。

4.3 把“意图 + 实体”组装成 Cypher：模板字典与参数化查询

意图和实体都有了，下一步是映射到 Cypher。不要在每个函数里单独写查询语句，把所有模板集中在一个字典里，方便维护和扩展：

QUERY_TEMPLATES = { "symptom": "MATCH (d:Entity {name: $entity, category: '疾病'})" "-[:has_symptom]->(s:Entity) " "RETURN s.name AS answer LIMIT 20", "medicine": "MATCH (d:Entity {name: $entity, category: '疾病'})" "-[:treat_with]->(m:Entity) " "RETURN m.name AS answer LIMIT 15", "department": "MATCH (d:Entity {name: $entity, category: '疾病'})" "-[:recommend_department]->(dep:Entity) " "RETURN dep.name AS answer LIMIT 5", "forbidden": "MATCH (d:Entity {name: $entity, category: '疾病'})" "-[:forbidden_food]->(f:Entity) " "RETURN f.name AS answer LIMIT 20", "check": "MATCH (d:Entity {name: $entity, category: '疾病'})" "-[:check]->(c:Entity) " "RETURN c.name AS answer LIMIT 10", } def ask_kg(question: str): intent = parse_intent(question) entity = extract_entity(question, ENTITY_DICT) if not entity: return intent, None, "暂时没从知识图谱里认出你提到的实体，换个规范名称试试。" cypher = QUERY_TEMPLATES[intent] results = graph.run(cypher, entity=entity).data() return intent, entity, results

这段代码里最关键的是graph.run(cypher, entity=entity)这种参数化写法，而不是把 entity 直接拼进字符串。原因有两个：一是防止 Cypher 注入，用户输入如果带有特殊引号，拼接会让整个查询变非法；二是参数化查询让 Neo4j 能缓存执行计划，同一模板反复执行时性能会好很多。实体名前后加了 category 过滤条件，这一步能让匹配更精确，避免疾病实体和症状实体同名时互相污染。

4.4 答案组织与容错：去重、截断和“库里没有”回退

Cypher 查出来的是一个字典列表，直接原样返回给用户是没法看的，必须转成自然语言句子。答案渲染的逻辑很简单，但坑不少：

ANSWER_TEMPLATE = { "symptom": "「{}」的常见症状包括：{}。", "medicine": "「{}」常用药有：{}。", "department": "「{}」建议就诊科室：{}。", "forbidden": "「{}」建议忌口：{}。", "check": "「{}」常做的检查有：{}。", } def render_answer(intent: str, entity: str, results: list[dict]) -> str: values = [r["answer"] for r in results] if not values: return "知识图谱里还没有收录「{}」的{}信息，换个说法再试试。".format( entity, intent ) value_text = "、".join(dict.fromkeys(values))[:500] return ANSWER_TEMPLATE[intent].format(entity, value_text)

第一个坑是去重。图谱里“头晕”可能同时挂在“高血压”和“高血压病”两个节点下，查询返回的列表会重复。用dict.fromkeys(values)而不是 set，是因为 set 会打乱顺序，而 dict.fromkeys 在保留顺序的同时去重。第二个坑是截断，一个疾病可能挂了几百个症状，全部拼进一句话既刷屏又难读，截断到 500 个字符足够覆盖大部分答案。第三个坑是空结果处理，直接说“没有”用户体验太差，提示用户换实体名或换问法，至少把意图名带出来，方便排查是图谱缺数据还是意图识别错了。

到这里，一个最小可用的问答闭环已经跑通了：用户问“高血压吃什么药”，系统识别出 medicine 意图和“高血压”实体，查出药物列表，渲染成“高血压常用药有：硝苯地平、氨氯地平……”。这个版本足够撑起毕业设计的核心 demo，也足够支撑你在论文里画出完整的系统架构图。

5. 医疗问答系统避坑与排错：导入乱码、实体匹配不上到版本兼容的 5 个问题

这套方案我前后搭过不止一次，每次翻车都集中在几个固定位置。下面五条按“现象 → 原因 → 解决”写出来，基本覆盖了从数据导入到问答响应的所有高发问题。

5.1 CSV 里的中文导入 Neo4j 后全是问号或节点消失

现象：LOAD CSV 执行成功，count 数量也对，但浏览器里查出来的 name 是乱码，或者整行数据为空。

原因：CSV 文件编码不统一。Windows 下用记事本另存时默认是 ANSI 编码，Neo4j 按 UTF-8 去读就变成乱码；还有一种情况是用 utf-8 保存时带了 BOM，首列列名变成\ufeffname，导致 WITH HEADERS 匹配不上。

解决：所有落地 CSV 一律用 pandas 的encoding="utf-8-sig"导出。utf-8-sig 会自动写入 BOM，Neo4j 识别 BOM 后能正确处理。导入前先做一次检查，用一条 Cypher 看一眼列名：

LOAD CSV WITH HEADERS FROM "file:///medical_entity.csv" AS row RETURN row LIMIT 1;

如果返回的列名带\ufeff前缀，说明文件是带 BOM 的 UTF-8 且没有被正确识别，重新用 utf-8-sig 导出即可。如果列名正常但中文乱码，就是源文件本身编码不对，用 pandas 指定 gbk 重新读一遍。

5.2 用户问“高血压病”查不到，但图谱里明明有“高血压”

现象：实体链接返回 None，系统提示“没认出实体”。

原因：实体词典里只有标准名“高血压”，用户说的是“高血压病”“高血压症”这类带后缀的变体。实体名称没有做别名归一化，这是问答系统最容易忽略的一环。

解决：清洗阶段把别名整理进 alias 字段，实体链接函数先匹配 name 再匹配 alias。匹配时还要处理“库里存的是症状名，用户用口语说”的情况，比如库里只有“眩晕”，用户说“头晕”，此时可以在 alias 里维护“头晕|眩晕”的映射。这类别名数据不需要太多，覆盖最高频的一两百个词就能把实体识别准确率从 70% 拉到 90% 以上。

5.3 py2neo 连不上 Neo4j：AuthenticationError 或 ServiceUnavailable

现象：Neo4j 浏览器能正常打开，py2neo 连接却报认证失败，或者握手时直接抛 ServiceUnavailable。

原因：py2neo 版本和 Neo4j 的 Bolt 协议不匹配。py2neo 4.x 对应 Neo4j 3.x，py2neo 2021.2.x 对应 Neo4j 4.x，Neo4j 5.x 对驱动要求更高。很多人从网上复制一段老代码，本地装的是新 Neo4j，结果就是连不上。

解决：先确认 Neo4j 版本，再装对应 py2neo 版本。如果你用的是 Neo4j 5.x，py2neo 生态跟进较慢，我一般直接换官方驱动：

from neo4j import GraphDatabase driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "your_password")) def query(tx, cypher, **params): return tx.run(cypher, **params).data() with driver.session() as session: result = session.execute_read(query, "MATCH (e:Entity) RETURN e.name LIMIT 5") print(result)

官方驱动的连接方式和 py2neo 有差别，但参数化查询的用法一致，核心代码改造成本很低。还有一个常见低级坑：首次启动 Neo4j 后浏览器会让你改初始密码，如果你用旧密码连接就会一直 AuthenticationError，去浏览器确认一遍当前密码再写进代码。

5.4 有实体有意图，但答案永远是“知识图谱里还没有收录”

现象：问“高血压应该挂什么科”，实体识别出“高血压”，意图识别也正确，但返回空结果。

原因：图谱里根本没有 recommend_department 关系，或者只有少部分疾病有这个关系。这个不是代码问题，是数据缺失。原始宽表里 department 字段大量为空，清洗时把它拆成了空行，Neo4j 自然查不到。

解决：清洗阶段就要统计每类关系的数据密度，而不是等问答跑起来才发现。用 pandas 快速看缺失率：

for col in ["symptom", "medicine", "department", "forbidden_food"]: empty_rate = (df[col].fillna("") == "").mean() print(f"{col}: {empty_rate:.2%} 为空")

department 字段缺失率超过 30% 时，建议回到数据源补一轮，或者把该关系从问答模板中暂时移除，避免用户频繁触发空答案。空结果不是不可接受，但空结果的比例要可控，否则答辩演示时非常尴尬。

5.5 查询越来越慢：几万条数据，回答一个问题要四五秒

现象：数据量刚过万，一个问题响应时间就飙到秒级，浏览器 Neo4j 里执行同样的 Cypher 也很慢。

原因：大概率是索引缺失。查询按 name 精确匹配，但 name 上没有索引，Neo4j 只能全图扫描。另一个原因是模板里没有限制路径深度，比如用可变长关系*1..5一次遍历出大量路径。

解决：先确认索引是否生效，用 EXPLAIN 查看执行计划：

EXPLAIN MATCH (d:Entity {name: "高血压"})-[r]-(n) RETURN n.name LIMIT 20;

执行计划里如果出现NodeByLabelScan而不是NodeIndexSeek，说明索引没走。检查上一章创建的索引是否存在，并确认查询语句里的条件字段是索引字段。另外，问答模板统一加上LIMIT，限制返回条数，能避免答案渲染阶段处理超大列表。还有一个习惯：只给需要精确匹配的字段建索引，不要给全字段建索引，索引过多会拖慢写入和存储扫描。

6. 质量验证与进阶改造：测试集、评估脚本与后续扩展方向

问答系统最怕的不是没跑通，而是跑通了但不知道效果好不好。我搭完第一版后做的第一件事不是调界面，而是建一个小规模测试集，把“问句 → 预期意图 → 预期实体 → 预期答案关键词”固化成表格。测试集不用大，50 条足够拦住大部分回归问题。

评估时按两个维度算：实体识别准确率和最终答案命中率。实体识别错，答案一定错；实体对但答案空，多半是图谱缺三元组，两类问题用一张测试集就能区分开。评估脚本很朴素，遍历测试集调 ask_kg，比对意图、实体和答案里是否包含预期关键词，最后打印准确率。这组数字直接写进论文，比你截几个 demo 图有说服力得多。

进阶改造有两个方向性价比最高。一是把意图识别从正则升级成小模型或基于候选模板的相似度匹配，图谱侧数据不变，问答准确率能再上一截；二是给答案附带图谱路径展示，把“高血压 → has_symptom → 头晕”渲染成可视化的路径图，这类图谱前端插件能把演示效果拉高一个档次。我现在的习惯是拿到任何新数据集，先打印缺失率和别名覆盖度，再写问答逻辑——这个顺序反过来的话，后期八成要推翻重来。希望这份从数据到答案的实践梳理，能帮你把这个方向做成一个真正跑得起来、讲得清楚的作品。

本文还有配套的精品资源，点击获取