简介：这是一份基于Python知识图谱的红楼梦人物关系可视化与问答系统完整源码包，来自高分毕业设计项目，评审分数99分，代码经导师指导认可，完整可运行。面向计算机相关专业正在准备毕业设计、课程设计或期末大作业的学生，也适合希望借助实际项目快速上手知识图谱与问答实战的学习者。资源共247个文件，压缩包大小约5.71MB，其中包含8个Python源码文件、4个HTML页面及配套的CSS/JS前端样式文件，另有大量JPG图片资源用于展示人物画像或界面效果，整体目录结构清晰，便于按模块查阅。目前已有133人学习下载。配套文档说明覆盖需求分析、系统设计、实现思路与运行方法，可帮助读者理解从数据构建到图谱可视化再到问答检索的完整流程，节省自行搭框架与排查环境的时间，适合作为毕业设计参考或功能扩展基础。
1. 毕业设计里的“红楼梦人物关系可视化+问答系统”到底是什么：先把技术边界讲透
你搜到“毕业设计-Python基于知识图谱实现的红楼梦人物关系可视化及问答系统”这串名字，大概率不是在找一篇论文，而是在评估这套东西做毕业设计划不划算。这套系统的关键词其实是知识图谱，不是人工智能。真正的技术栈就四块：Python文本处理、Neo4j图数据库、Flask后端、ECharts前端。工作量大头不在算法，而在脏活——把120回文本清洗干净，把“宝玉”归一成“贾宝玉”，把“贾政—贾宝玉”这种父子关系整理成结构化三元组，之后才轮到入库和渲染。它能解决的实际问题是：答辩现场老师问一句“贾宝玉的爸爸是谁”，系统能在图谱里检索出关系路径、给出答案，再把人物关系网投到屏幕上。适合零基础起步、想用Python工具链快速出成果的同学，也适合想弄清楚知识图谱落地边界的人。先把这个认知立住：这套项目成不成，八成取决于数据整理，两成取决于代码。
2. 把《红楼梦》文本变成可入图的数据：人物词典与关系三元组从哪里来
2.1 全本语料的获取与清洗：不给后续步骤留暗坑
常见做法是先从公开的古籍文本站抓一份《红楼梦》全本txt，120回齐全就行。很多版本混着全角空格、多余换行和校对注释，直接喂给后面的人名切词会出一堆乱子。你写好爬虫去拉也好，手动另存为也算，格式尽量统一成UTF-8纯文本。拿到txt之后第一步不是分词，是清洗和分回。我一般会把每回单独存成一个文件，后面做“在某回出现”的统计就方便很多。
import re from pathlib import Path raw = Path("hongloumeng.txt").read_text(encoding="utf-8", errors="ignore") raw = raw.replace("\u3000", " ") # 全角空格归一，防止词被切开 raw = re.sub(r"[ \t]{2,}", " ", raw) # 连续空白压成一个空格 raw = re.sub(r"\n{3,}", "\n\n", raw) # 多余空行去掉 # 按“第×回”切分，保留回目标题用于后续证据标注 parts = re.split(r"第[一二三四五六七八九十百千0-9]+回", raw) out_dir = Path("texts") out_dir.mkdir(exist_ok=True) # parts[0] 通常是楔子或前言，从 parts[1] 开始才是第1回正文 for idx, body in enumerate(parts[1:121], start=1): out_dir.joinpath(f"{idx:03d}.txt").write_text(body.strip(), encoding="utf-8")这段代码的逻辑分两层：先做字符级归一，再做文档级切分。\u3000是中文全角空格，切词时会干扰词典匹配，必须提前换掉。按“第×回”切分时，如果你的源文本里用的是“第001回”这种阿拉伯数字，把正则换成r"第\d+回"就行。切分后每回一个文件还有一个额外好处：之后抽取人物共现时，可以直接记录“贾政和贾宝玉在第3回和第16回共同出现”，这条证据能写进关系属性里，答辩问答展示时会显得很扎实。
清洗这一步容易翻车的地方是编码。Windows 下记事本另存为 ANSI 会把read_text(encoding="utf-8")直接搞崩溃，所以拿到文件第一件事是用 Python 读一遍，读不出来就先转码，别急着往下走。还有就是某些网络版本会混入“脂砚斋批语”或注释行，批量清洗时会干扰共现统计，稳妥做法是先把所有括号注释行删掉。
2.2 人物词典与别名词表：知识图谱的实体边界
清洗完文本，下一个要解决的问题是“哪些词是人名”。红楼梦里人物称呼极其混乱：贾宝玉又叫宝玉、宝二爷、怡红公子；林黛玉又叫黛玉、颦儿、潇湘妃子。如果不做别名归一，后面图谱会出现“宝玉”和“贾宝玉”两个节点，问答系统也会因为匹配不到词而失效。这一步要建两张表：一张标准人物词表，一张别名映射表。
import jieba # 每行格式：词 词频 词性 # nr 表示人名，这个词性标记来自 jieba 的标准词库 jieba.load_userdict("honglou_dict.txt")honglou_dict.txt内容大致是这样：
贾宝玉 100 nr 林黛玉 100 nr 王熙凤 80 nr 贾政 80 nr 贾母 80 nr 薛宝钗 80 nr词典建好之后，再建别名表。这里的关键不只是“把别名替换成标准名”，还要保留别名的原文，因为问答时用户很可能是按“宝玉”来问的，系统得能把输入映到标准实体上再查图。
aliases = { "宝玉": "贾宝玉", "宝二爷": "贾宝玉", "怡红公子": "贾宝玉", "黛玉": "林黛玉", "颦儿": "林黛玉", "潇湘妃子": "林黛玉", "凤姐": "王熙凤", "凤姐儿": "王熙凤", "贾宝玉": "贾宝玉", # 标准名也放进映射，统一走一条路 } def normalize(name): return aliases.get(name, name)这段代码的写作逻辑是：所有文本里出现的人名，在进词典匹配之前先过一遍normalize，确保图谱里真的只有一个“贾宝玉”节点。你可能会问，为什么标准名也放进映射表？因为问答模块里用户输入“贾宝玉的爸爸是谁”和“宝玉他爹是谁”，最终都要落到同一个图上实体，统一走映射最省事。参数上唯一要注意的是词频，我给常见主角设 80～100，配角设 30～50，这个值决定 jieba 在分词时把词识别成人名的倾向，不用太纠结，量级对就行。
2.3 从人工标注到规则补充：关系三元组的两种来源
关系三元组是这套系统真正的核心竞争力。常见的毕业设计做法是：主要人物的核心关系（父子、夫妻、主仆、兄弟姐妹）由人工整理成一份 CSV，大约覆盖 40～60 个主要人物就够了；然后再写一个共现统计脚本，从全本里抽“同一窗口内同时出现的两个人名”作为辅助关系，用来补权值和做关系验证。纯靠算法做关系抽取对本科生来说不可控，人工整理加规则补充是性价比最高的组合。
from collections import defaultdict persons = list(aliases.keys()) # 包含别名，便于窗口内命中 window = 60 # 以字符为单位的共现窗口 co_occur = defaultdict(int) for txt in sorted(Path("texts").glob("*.txt")): text = txt.read_text(encoding="utf-8") for person in persons: start = 0 while True: idx = text.find(person, start) if idx == -1: break left = max(0, idx - window) right = min(len(text), idx + len(person) + window) ctx = text[left:right] for other in persons: if other != person and other in ctx: if normalize(person) != normalize(other): co_occur[(normalize(person), normalize(other))] += 1 start = idx + len(person) # 过滤掉低频共现，阈值取 3 以上 strong = {k: v for k, v in co_occur.items() if v >= 3}这段代码的思路很笨但很有效：在每个回目里逐个人名去find，命中后截取前后各 60 字作为上下文窗口，窗口里再查其它人名。每次命中就累加计数。注意我用的是字符级窗口，不是分词后窗口，这样能减少因分词错误导致的漏报。参数上，window=60大约覆盖两三句对话，太小漏关系，太大引入无关人物。v >= 3是经验阈值，低于 3 的共现多数是巧合，写进图谱会变成噪音。
人工整理的关系 CSV 长这样，作为参考：
source,target,type,evidence,weight 贾政,贾宝玉,PARENT_OF,第17回引出大观园题对句,3 贾母,贾宝玉,GRAND_PARENT_OF,贾母常称宝玉为命根子,3 王熙凤,贾宝玉,COUSIN,第14回协理宁国府,2到这一步，你已经有了三类数据：清洗后的分回文本、人物词典与别名表、关系三元组 CSV。这些是后端入库的原料，也是全文质量的地基。别急着写 Neo4j 导入，先把这三份文件用pandas.read_csv打开看一遍，检查有没有 duplicate、有没有normalize漏掉的别名，再进入下一章。
3. 知识图谱建模与 Neo4j 入库：关系不是 Excel，是图结构
3.1 本体设计：实体类型与关系类型定得越小越好收敛
很多同学一上来就想做“语义层”“本体建模”，恨不得把红楼梦里的社会关系、家族历史全建模进去，结果图数据模型越画越大，最后连查询都写不利索。知识图谱工程里，本体设计的第一原则是收敛：实体类型控制在 2～3 类，关系类型控制在 10 类以内，够回答问题就行。常见做法是只用两类实体，人物和地点，关系用下面这张表来约束：
| 关系类型 | 含义 | 示例 |
|---|---|---|
| PARENT_OF | 父子/母子 | 贾政 → 贾宝玉 |
| SPOUSE_OF | 夫妻 | 贾琏 → 王熙凤 |
| SIBLING_OF | 兄弟姐妹 | 贾珠 → 贾宝玉 |
| GRAND_PARENT_OF | 祖孙 | 贾母 → 林黛玉 |
| MASTER_OF / SERVANT_OF | 主仆 | 贾宝玉 → 袭人 |
| FRIEND_OF | 玩伴/好友 | 贾宝玉 → 柳湘莲 |
| VISIT_OF | 拜访/常去 | 贾宝玉 → 潇湘馆 |
| MENTIONED_WITH | 共现补充 | 辅助关系，带权重 |
这些关系类型为什么不叫“父亲”“儿子”而叫PARENT_OF？因为知识图谱的边是无向可遍历的，你要查“贾政的儿子”和“贾宝玉的爸爸”其实是同一条边。如果只录入“贾政是贾宝玉的父亲”，那就只能答前者，后者答不出来。一个成熟做法是：入库时按单向方向存，但查询时用无向匹配，或者干脆录入两条对称关系。我建议建模阶段先定方向，查询阶段再处理对称性，这样数据更干净。
3.2 Flask 后端接 Neo4j：py2neo 的版本坑与连接写法
Neo4j的驱动选型有一个血泪经验：py2neo 和 Neo4j 服务端版本要匹配，否则连接时报ServiceUnavailable。Neo4j 4.x 配 py2neo 2021.2 通常没问题，Neo4j 5.x 我建议直接用官方提供的neo4j驱动，少踩坑。这里先给一套稳定的连接和导入写法，用 py2neo 的merge保证幂等：
from py2neo import Graph, Node, Relationship import csv graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password"), name="neo4j") with open("relations.csv", encoding="utf-8") as f: rows = list(csv.DictReader(f)) BATCH_SIZE = 500 start = 0 while start < len(rows): tx = graph.begin() for r in rows[start:start + BATCH_SIZE]: source = Node("Person", name=r["source"]) target = Node("Person", name=r["target"]) rel_type = r["type"] rel = Relationship(source, rel_type, target, evidence=r["evidence"], weight=int(r["weight"])) # key 是 (节点标签, 属性值)，merge 保证不会重复建点 tx.merge(source, "Person", "name") tx.merge(target, "Person", "name") tx.merge(rel, rel_type, evidence=r["evidence"]) tx.commit() start += BATCH_SIZE这段代码的逻辑是逐条merge：先 merge 起点和终点，确保节点存在，再 merge 关系。merge和create的区别在于，create无条件新建，跑两遍就出现两个“贾宝玉”；merge按 key 去匹配，key 是标签 + name 属性，所以同一人物只会有一个节点。BATCH_SIZE=500是事务大小，太小事务多、太慢，太大会撑爆 Neo4j 事务内存，一般 500～1000 是安全区间。
3.3 约束、索引与全局唯一：避免“两个王熙凤”
即便你在 Python 端做了 merge，还是建议在 Neo4j 服务端显式创建唯一约束。这是知识图谱项目里最容易忽略的一步。没有约束前，并发写入或者数据重复时，可能会出现两个name = "王熙凤"的节点，后续所有查询结果都带着歧义。约束建好之后，数据库层面强制唯一，错误会立即暴露，而不是悄悄产生脏数据。
CREATE CONSTRAINT person_name_unique IF NOT EXISTS FOR (p:Person) REQUIRE p.name IS UNIQUE;这段 Cypher 是 Neo4j 4.4+ 的语法。如果你还在用 Neo4j 3.5，约束语法是CREATE CONSTRAINT ON (p:Person) ASSERT p.name IS UNIQUE。版本差异很大，写进文档说明时记得标注你的版本号。地点实体数量少，不需要唯一约束，建个普通索引就够了：
CREATE INDEX place_name_index IF NOT EXISTS FOR (p:Place) ON (p.name);为什么地点不需要唯一约束？因为地点实体数量小，而且后面的问答基本只按人物走，独特的约束会带来额外的写库开销。索引则是为了加速查询“林黛玉住在哪里”这类需要按地点名过滤的场景。
这章小结一个工作流：先建约束，再跑导入脚本，最后用MATCH (n) RETURN n.name, labels(n) LIMIT 25抽查节点。入库完成后，进入可视化阶段前，先在图数据库浏览器里手动验证关系数量级，别带着脏数据去写前端。
4. 人物关系可视化：API 输出图 JSON，前端一次渲染 200 个节点
4.1 可视化选型与架构：ECharts 还是 Gephi？为什么不是 Neo4j Browser
到可视化这一步，有三个常见选择，很多人会纠结。我直接给结论：交付给毕设演示的，用 ECharts；自己做关系分析，用 Gephi；临时验证数据，用 Neo4j Browser。ECharts 是纯前端组件，能嵌到 Flask 页面里，答辩时打开浏览器就是一个可交互系统，这是最符合“可视化和问答系统”交付形态的做法。
| 方案 | 优势 | 劣势 |
|---|---|---|
| Neo4j Browser | 零代码跑 Cypher | 演示界面太技术化，非专业老师看不懂 |
| Gephi | 布局算法强 | 需另存 JSON，部署和演示麻烦 |
| ECharts | 前端集成容易，力导向图免费 | 数据量上万会卡，需做减载 |
架构上，整个链路是：Flask 提供/api/graph返回图数据 JSON，前端页面用fetch拉取后用 ECharts 渲染。后端做的唯一重要事情是控制返回规模，不然你把 Neo4j 里全量关系倒给浏览器，老师一拖拽就卡死，现场演示就叫“翻车现场”。
4.2 后端输出 Graph JSON：节点和边的数据结构设计
ECharts 的 graph 类型需要两个核心数组，nodes和links。后端要把 Neo4j 查询结果转成这个结构。注意这里不能直接返回全部节点，要按“度”过滤，也就是只返回至少和多少个人有关系的角色。
from flask import Flask, jsonify, request from py2neo import Graph app = Flask(__name__) graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) @app.route("/api/graph") def api_graph(): min_degree = int(request.args.get("min_degree", 2)) cypher = """ MATCH (a:Person)-[r]-(b:Person) WHERE size((a)--()) >= $min_degree RETURN a.name AS source, b.name AS target, type(r) AS rel, r.weight AS weight LIMIT 500 """ data = graph.run(cypher, min_degree=min_degree).to_table() node_dict = {} links = [] for source, target, rel, weight in data: if source not in node_dict: node_dict[source] = {"name": source, "degree": 0} if target not in node_dict: node_dict[target] = {"name": target, "degree": 0} node_dict[source]["degree"] += 1 node_dict[target]["degree"] += 1 links.append({"source": source, "target": target, "rel": rel, "weight": weight}) nodes = list(node_dict.values()) return jsonify({"nodes": nodes, "links": links})关键点是size((a)--()) >= $min_degree这个条件，它把图谱中有边的人都统计了一遍度，只保留连接数足够高的“主角”。参数min_degree=2意味着至少和两个人有关系的角色才显示，这一步能砍掉大量只出现过一次的边缘人物。LIMIT 500是边数的硬上限，防止接口返回过大。这个接口写出来之后，先用浏览器访问http://localhost:5000/api/graph?min_degree=3，确认 JSON 结构正常，再去写前端。
4.3 前端 ECharts force 布局参数：让“四大家族”一眼可见
前端页面直接写在 Flask 的templates/index.html里。渲染的核心是 ECharts 的 graph 系列，布局用force，也就是力导向布局。这里有几个参数直接决定演示效果，值得细调。
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script> </head> <body> <div id="chart" style="width:100%;height:90vh;"></div> <script> const chart = echarts.init(document.getElementById("chart")); fetch("/api/graph?min_degree=3") .then(r => r.json()) .then(data => { chart.setOption({ series: [{ type: "graph", layout: "force", data: data.nodes, links: data.links, roam: true, // 允许拖拽缩放 label: { show: true, fontSize: 12 }, force: { repulsion: 300, // 节点间斥力，越大越散 edgeLength: 80 // 边的期望长度 }, lineStyle: { opacity: 0.3 } }] }); }); window.addEventListener("resize", () => chart.resize()); </script> </body> </html>这里repulsion: 300是力导向参数里最值得调的一个。值太小，人物全挤成一团看不清；值太大，关系远的人会被甩出屏幕。edgeLength: 80控制有边相连的两个人的“期望距离”，值越小家族内部越紧，直观效果是贾府、王家、薛家各自聚成一团。roam: true允许鼠标拖拽和滚轮缩放，这是答辩演示时最常用到的交互。最后那行chart.resize()是写页面的人经常忘的：浏览器窗口变化后图表会变形，加一个监听事件是必要的。
到这一步，你已经有了一个可以演示的交互图谱。但演示只是面子，里子还得靠问答系统撑住。进入下一章之前请先自己玩十分钟页面：拖一拖、放大缩小、看看关系线是不是符合常识，特别是贾府内部有没有出现明显断连。
5. 避坑排查：关系错乱、节点爆炸与中文乱码的几个真实现场
5.1 图谱里同时出现“宝玉”和“贾宝玉”两个节点
现象：可视化页面里，“宝玉”孤零零待在一个角落，“贾宝玉”连着一大堆关系，两个人明明是同一个人，却被当成了两个实体。
原因：导入脚本里只用了关系 CSV 里的source字段，没经过normalize。人工整理时你可能一会儿写宝玉，一会儿写贾宝玉，或者共现统计脚本漏掉了别名替换。Neo4j 只看字符串相等，不会帮你识别指代。
解决：在 Python 导入脚本开头统一跑一遍归一。给每个 Node 的name赋值之前，强制走normalize()函数。最稳妥是关系 CSV 生成的时候就做一次校验：用set(数据源)和set(normalize(数据源))对比长度，不一致就说明有漏网的别名。血的教训是，这一步必须前置，别等到图建完再反思。
5.2 LOAD CSV 导入中文变成乱码
现象：很多同学不写 Python 脚本，而是在 Neo4j Browser 里用LOAD CSV WITH HEADERS FROM 'file:///relations.csv' AS row导入。结果节点名变成一堆问号，或者 CSV 里有中文的地方读出来是乱码。
原因：Windows 上另存的 CSV 是 ANSI 编码，Neo4j 服务端默认按 UTF-8 读取，两边不一致必然乱码。还有一个隐蔽问题是，有些编辑器会往文件头加 BOM，导致第一行“source”读成“\ufeffsource”，字段名对不上。
解决：不用 Windows 记事本保存。在 Python 里统一写出：open("relations.csv", "w", encoding="utf-8-sig")，utf-8-sig会自行处理 BOM。如果你坚持要手写 CSV，就从 Excel 里导出时选“CSV UTF-8(逗号分隔)”格式，这是最容易记住的后悔药。如果已经是乱码数据，别修文件了，直接重新导一遍。
5.3 ECharts 力导向图节点一多就卡死
现象：图谱页面一开始是好的，但把min_degree降到 1 后，浏览器直接卡成幻灯片，风扇狂转，演示时老师一拖拽，页面无响应。
原因：ECharts 的 force 布局每隔一帧就要重新计算所有节点之间的斥力，复杂度大致是 O(n²)。红楼梦配角几百个，全部铺上去以后，普通笔记本的 CPU 根本扛不住。这不是代码 bug，是力导向算法的固有瓶颈。
解决：三招并用。第一，后端接口设LIMIT 500，不要让全量数据进页面。第二，前端默认只展示min_degree >= 3的主角，加一个开关，点击“显示全部”时再拉一次接口。第三，关掉不必要的动画，force: { layoutAnimation: false }，减少每帧重算。这样既能保住演示流畅度，又能说“我们系统支持全量切换”。
5.4 py2neo 报 ServiceUnavailable，连不上 Neo4j
现象：脚本跑起来第一行就报py2neo.errors.ServiceUnavailable，查了半天找不到原因，甚至以为是 Neo4j 密码错了。
原因：最常见的是 Neo4j 服务端版本和 py2neo 版本不兼容。Neo4j 5.x 对 py2neo 2021.2 的支持有坑，特别是连接串协议从 http 换到 bolt 时的握手差异。另外一个高频原因是，Neo4j 虽然装好了，但服务没启动，或者你写的是localhost:7474，那是 HTTP 端口，Py2neo 默认走 7687 的 bolt 端口。
解决：先验证服务本身，用浏览器打开http://localhost:7474，能登录说明就服务端没问题；再用cypher-shell跑一句测试，能通后就检查 Python 连接串，统一写成bolt://localhost:7687。如果是 py2neo 和 Neo4j 5.x 的版本冲突，干脆换官方驱动，连接方式大同小异，别恋战。
5.5 问答系统答不出“贾政的儿子是谁”，却能答“贾宝玉的爸爸是谁”
现象：问“贾宝玉的爸爸是谁”答得飞快，问“贾政的儿子是谁”却说没有数据。同一组人，换了个问法就扑街。
原因：人工整理关系 CSV 的时候只录了“贾政,贾宝玉,PARENT_OF”这一个方向，数据库里只有这一条边。知识图谱的关系虽然理论上可以双向遍历，但你在查询时如果写的是(a)-[:PARENT_OF]->(b)，那反方向查就永远没结果。
解决：查询端用无向匹配，Cypher 里把箭头去掉，写成(a)-[:PARENT_OF]-(b)，配合WHERE a.name = $name就能同时回答两个方向。另外一个保险做法是，人工关系在导入时就复制一份反方向的边，但这样数据量会翻倍，而且容易维护混乱。我更推荐在问答模块统一按无向图处理，这也是知识图谱相对传统关系型数据库的一大优势。
6. 问答系统：模板匹配生成 Cypher，再用 30 条回归问题验证效果
问答系统能不能扛住答辩，不取决于你上了什么模型，而取决于你把问题边界收缩得多清楚。我一般把红楼梦问答系统限制在 6 类以内：关系查询（A和B什么关系）、单方关系查询（A的爸爸是谁）、人物介绍（A是谁）、地点查询（A住在哪）、亲属链查询（A的爷爷是谁）、共现查询（A和谁关系最近）。超出范围的问句直接回复“这个问题知识库还答不上来”，比硬答要好得多，因为硬答错误会给评委留下系统不靠谱的印象。
import re from py2neo import Graph graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) RULES = [ (r"(.+)和(.+)是什么关系", "relation_between", ["name1", "name2"]), (r"(.+)的(爸爸|母亲|儿子|女儿|丈夫|妻子|哥哥|弟弟)是谁", "relation_of", ["name", "rel"]), (r"(.+)住在哪里", "place_of", ["name"]), ] def answer(question): for pattern, intent, slots in RULES: m = re.search(pattern, question) if m: values = [normalize(g) for g in m.groups()] return run_intent(intent, dict(zip(slots, values))) return "这个问题我还答不上来，换个问法试试" def run_intent(intent, args): if intent == "relation_between": cypher = """ MATCH (a:Person {name:$name1})-[r]-(b:Person {name:$name2}) RETURN type(r) AS rel, r.evidence AS ev LIMIT 5 """ result = graph.run(cypher, **args).to_table() if result: rel = result[0][0] return f"{args['name1']}和{args['name2']}的关系是：{rel}" return "我能查到一些线索，但不保证准确"这段代码的核心是正则优先匹配，而不是用一堆 if-else 判断。正则的顺序很关键：长的、具体的问法放前面，短的、泛的问法放后面，否则“贾宝玉和林黛玉是什么关系”会被后面的单方规则误吞。normalize在参数抽取时就做，保证问题里的“宝玉”能落到数据库里的“贾宝玉”节点上。关系类型映射我一般会做一张表，把用户的“爸爸”映射到图里的PARENT_OF，再配合无向匹配，才能答全两个方向。
验证方法也很简单：建一个test_questions.json，放 30 条你能想到的问题，配上期望回答里的关键实体词，用脚本循环调一遍answer()，统计命中率。我当年的习惯是 20 条关系类、10 条边界类，边界的专门用来测系统会怎么拒绝。每次改正则或者改别名表，就重跑一遍这套题，防止修一个 bug 带翻三个老问题。这套功夫花不了两小时，但答辩时老师随便问几个问题你都能兜住，比临时抱佛脚强太多。希望这套流程能帮你把项目顺利收尾，少踩几个我已经替你踩过的坑。
本文还有配套的精品资源，点击获取
