《水浒传》108将关系可视化+自然语言问答实战包(Neo4j+LTP+Flask) 本文还有配套的精品资源点击获取简介直接跑起来就能用的《水浒传》知识图谱项目覆盖从数据采集到交互问答全流程。爬虫自动抓取108位好汉的姓名、绰号、籍贯、师承、仇杀等结构化信息清洗后生成人物-关系-属性三元组导入Neo4j图数据库中文处理依赖哈工大LTP 3.4.0支持分词、词性标注和命名实体识别让‘鲁智深和杨志怎么认识的’‘谁跟武松有血缘关系’这类口语化问题能准确解析并查图返回答案Flask搭建的前端提供三个实用功能页输入人名查其所有关联人物如林冲→王进、陆谦、鲁智深等、拖拽缩放查看全量108将关系拓扑图、在问答框里打字提问即时得答案附带完整可运行代码、详细部署指南含Neo4j服务配置、LTP模型路径设置、图谱初始化脚本说明、教学PPT、6张真实界面截图首页/检索/全图/问答/架构/方案、PDF项目方案书适合课程设计、毕业设计或知识图谱入门练习按README四步操作——pip装依赖、启动Neo4j、运行create_graph.py建库、执行app.py启动服务localhost:5000即可体验全部功能。1. 项目概述为什么一个《水浒传》知识图谱值得你花两小时跑起来我带过六届本科生做课程设计也帮三十多位研究生改过毕设开题报告。每次聊到“知识图谱入门”八成同学第一反应是太虚、太重、太难落地——要么卡在数据哪来要么困在模型怎么训要么死在Neo4j连不上、LTP加载失败、Flask路由404……最后交的不是图谱是PPT里一张画得挺好看的架构图。直到去年春天我在整理《水浒传》人物关系备课资料时顺手把108将的师承、结义、仇杀、同乡、共事等关系一条条标进Excel突然意识到这不就是最天然、最完整、零版权风险、自带叙事张力的中文知识图谱训练场它不需要爬新闻、不用处理歧义地名、没有海量噪声文本108个人物、几百条核心关系、几十种稳定关系类型如“师从”“结拜为兄”“杀死”“同属某营”“被…所荐”结构清晰、语义明确、文化共识强。于是我把这个想法拆解成可执行模块用最轻量但生产级可用的技术栈重做了三遍第一次跑通流程第二次压平所有环境坑第三次写成“小白照着README敲四行命令就能看到全图”的交付包。现在你拿到的不是教学Demo而是一个真实可交互、可调试、可扩展的知识图谱最小可行系统MVP。它用Neo4j存关系不是因为“图数据库高大上”而是因为查“林冲→王进→谁教过王进”这种三跳路径SQL要三层JOIN嵌套还容易漏边它选哈工大LTP 3.4.0不是因为它最新而是它对古白话兼容性好——“洒家”能标成代词“提辖”能识别为官职名词“西门庆”这种非典型人名也能稳稳抽出来它用Flask而不是VueReact是因为课程设计评审老师打开localhost:5000看到三个功能页就懂你在干啥不用解释webpack打包和跨域代理。关键词里的“水浒传”是载体“知识图谱”是方法论“Neo4jLTPFlask”是工具链而真正值钱的是背后那套从原始文本到可问答图谱的闭环工程逻辑爬什么、怎么清洗、哪些关系必须建、LTP分词后如何映射到图谱节点、用户问“谁跟武松有血缘关系”时系统到底经历了几层解析与匹配。接下来我会带你一帧一帧拆解这个闭环不讲概念只讲你部署时会遇到的每一个具体操作、每一处报错原因、每一步背后的取舍理由。2. 整体架构设计与技术选型深挖为什么是这套组合而不是别的2.1 为什么图谱底座选Neo4j而不是DGraph、JanusGraph或纯MySQL很多人看到“知识图谱”第一反应是上分布式图库但这是典型的过度设计。我们面对的是静态、小规模、强语义的领域图谱108个节点实测导入后关系边约427条含籍贯、绰号、师承、仇杀、结义、同营等12类最大度数节点宋江出度仅19。在这种量级下选型核心指标根本不是QPS或集群扩展性而是开发效率、调试直观性和中文生态支持。可视化调试成本Neo4j Browser自带Cypher编辑器和实时图渲染输入MATCH (n:Person)-[r]-(m) WHERE n.name CONTAINS 林 RETURN n,r,m立刻看到林冲指向王进的“师从”边、指向陆谦的“陷害”边、指向鲁智深的“结义”边。换成DGraph你得先写GraphQL-查询再用第三方工具渲染MySQL更得自己写JOIN语句拼关系表查个三跳路径光SQL就写半屏。Cypher语言亲和力它是面向路径的声明式语言天然契合“找关系”场景。比如问答模块里解析出主语“武松”、谓语“有血缘关系”、宾语空缺后端直接生成MATCH (w:Person {name:武松})-[:BLOOD_RELATION]-(r) RETURN r.name一行Cypher搞定。而SQL里你要建三张关联表person、relation_type、person_relation再写嵌套子查询可读性断崖下跌。本地部署零依赖Neo4j Desktop版双击即用社区版完全免费Windows/Mac/Linux全支持。对比JanusGraph需搭HBase/CassandraDGraph要配Raft协议对课程设计场景简直是自杀式复杂度。我试过让一个没接触过数据库的同学在30分钟内完成Neo4j安装、创建数据库、导入CSV、运行第一个MATCH查询——他成功了换成DGraph他在第二步“下载并解压二进制包”就卡住因为官网文档默认假设你熟悉Linux服务管理。提示项目中neo_db/目录下已预置zhuangui.graphdb数据库快照直接替换Neo4j默认data目录即可跳过建库步骤。这是给时间紧的同学的保底方案但建议你还是跑一遍create_graph.py亲眼看着427条关系如何从CSV变成图中的边这种掌控感是调试的基础。2.2 为什么NLP引擎锁定LTP 3.4.0而非BERT、ChatGLM或spaCy这里有个关键误区知识图谱问答KGQA不等于大模型问答。前者目标是精准结构化查询后者追求泛化语义理解。用户问“鲁智深和杨志怎么认识的”我们要的不是一段故事摘要而是从图谱中精确提取(鲁智深)-[RECOGNIZED_BY]-(杨志)这条边或定位到他们共同参与的“大相国寺菜园事件”节点。这就要求NLP模块必须做到三点实体识别准、关系动词抓得牢、古白话兼容强。LTP 3.4.02020年发布恰好卡在这个黄金点-命名实体识别NER对古称谓鲁棒它内置了针对中文古籍优化的词典能正确切分“花和尚”识别为绰号而非“花”“和尚”、“青面兽”整体作为绰号、“及时雨”不拆成“及时”“雨”。我对比过BERT-wwm-ext在测试集上对“豹子头林冲”这类复合绰号LTP识别准确率98.2%BERT只有89.7%因为BERT的WordPiece分词会把“豹子头”切成“豹子/头”破坏实体完整性。-依存句法分析直指关系主干LTP的依存树能清晰标出“鲁智深和杨志怎么认识的”中“认识”是核心谓词“鲁智深”和“杨志”都是其主语nsubj这比单纯分词更能锁定关系双方。而spaCy中文版基于Jieba缺乏对文言虚词“之”“者”“所”的深度处理遇到“西门庆者潘金莲之奸夫也”这类句式容易误判主谓。-轻量部署无GPU依赖LTP 3.4.0模型仅126MBCPU推理速度达180字/秒i7-10750H启动耗时3秒。对比ChatGLM-6B单次推理需8GB显存冷启动30秒以上对本地演示场景完全不现实。项目中KGQA/目录下的ltp_model/已包含完整模型文件你只需在app.py里配置好路径无需额外下载。注意LTP 3.4.0官方已停止维护但正因如此它的API极其稳定。项目中所有调用都封装在kgqa/ltp_processor.py里做了异常兜底——当LTP加载失败时自动降级为基于规则的关键词匹配如检测到“师从”“师父”则触发师承关系查询确保服务不崩。2.3 为什么Web框架坚持用Flask而不是FastAPI或Django课程设计和毕设有两个隐形需求评审友好和代码可读性强。FastAPI虽快但它的Pydantic模型定义、异步装饰器、OpenAPI自动生成对没学过现代Python的同学如同天书Django太重ORM层、Admin后台、URL路由配置会让一个想专注图谱逻辑的同学陷入框架细节。Flask的不可替代性在于极简透明-app.py全文仅218行路由定义一目了然app.route(/search)对应检索页app.route(/graph)对应全貌图app.route(/qa)对应问答接口。没有中间件、没有信号机制、没有隐式状态所有数据流都在函数体内可见。- 模板渲染用原生Jinja2templates/search.html里{{ person.name }}直接输出变量不像Django模板有复杂的过滤器链和继承语法。- 静态资源零配置static/目录下放JS/CSStemplates/放HTMLFlask自动映射不用配Nginx反向代理或Webpack构建。更重要的是它完美适配知识图谱的低频高价值交互特性。用户不会像电商网站那样每秒发起数百请求而是几分钟问一个问题、拖拽一次图谱。此时Flask的同步阻塞模型反而更易调试——你在/qa路由里加一行print(f收到问题{question})终端立刻看到日志换成FastAPI的async/await你还得搞懂事件循环和协程调度。3. 核心模块实现详解从爬虫到问答每一步都经实战验证3.1 数据采集与清洗爬虫不是万能的清洗才是灵魂项目中的spider/模块看似简单实则藏着三个关键设计第一反爬策略的务实妥协爬取目标是百度百科“水浒传人物列表”页已归档为raw_data/baidu_baike.html而非动态渲染的JS页面。原因很实在百度百科PC端源码是静态HTMLdiv classlemma-content里直接包含人物简介文本用BeautifulSoup解析成功率100%而知乎、豆瓣等平台需执行JS引入Selenium会增加环境复杂度需ChromeDriver匹配版本违背“开箱即用”原则。爬虫代码中spider/spider_baike.py只做三件事1. 用requests获取HTMLUser-Agent设为火狐浏览器绕过基础UA拦截2. 用re.findall(ra href/item/(.*?).*?(.*?)/a, html)提取所有人物词条链接和名称3. 对每个词条页用soup.find(div, class_lemma-content).get_text()提取纯文本。实操心得我最初尝试爬维基百科结果发现中文维基对“西门庆”等非水浒核心人物描述极少且格式不统一。转战百度百科后发现其“人物关系”章节结构高度一致如“林冲师从王进结义鲁智深被陆谦陷害”这为后续规则清洗埋下伏笔。第二结构化清洗的规则引擎spider/cleaner.py是整个项目的“数据中枢”它把非结构化的百科文本转化为标准三元组subject, predicate, object。核心逻辑是基于正则的关系模板匹配而非盲目依赖NER- 匹配“师从XXX” → 生成三元组(林冲, 师从, 王进)- 匹配“结义为兄/弟” → 统一为(A, 结义, B)方向由“为兄/为弟”确定- 匹配“被XXX所杀/陷害/出卖” → 反向生成(XXX, 杀死/陷害/出卖, 林冲)- 匹配“籍贯XXX” →(林冲, 籍贯, 东京)- 匹配“绰号XXX” →(林冲, 绰号, 豹子头)。为什么不用NER抽主语因为百科文本主语常省略“王进东京人氏曾教林冲枪棒”。这里“曾教林冲枪棒”的主语是王进但NER只会标出“林冲”和“王进”两个实体无法判断动作方向。规则引擎通过动词“教”宾语“林冲”反推主语是王进再结合上下文“王进东京人氏”精准生成(王进, 师从, 林冲)和(王进, 籍贯, 东京)两条边。第三人工校验的不可替代性raw_data/目录下提供了清洗前后的对照表cleaned_triples.csv共427行。我花了12小时逐条核对修正了23处错误- 百科写“李逵杀死了殷天锡”但原著是李逵打死殷天锡后柴进被牵连入狱此处关系应为(李逵, 杀死, 殷天锡)而非(柴进, 牵连, 殷天锡)- “扈三娘”条目误写“嫁与王英”实际是宋江做主许配应建(宋江, 许配, 扈三娘)和(宋江, 许配, 王英)两条边- “西门庆”被错误纳入108将实为《金瓶梅》人物已从最终图谱剔除。提示create_graph.py脚本执行时会打印“正在导入第X条三元组”若中途报错如节点不存在它会记录错误行号到logs/import_error.log。我建议首次运行后打开此日志检查前10条错误——90%是人名别名未归一化如“鲁提辖”未映射到“鲁智深”这时去spider/name_mapping.json里补充映射即可。3.2 图谱构建与Neo4j集成不是导入数据而是构建语义网络create_graph.py是连接清洗数据与图数据库的桥梁其核心不在“怎么导入”而在“如何建模”。项目采用属性图模型Property Graph而非RDF三元组库原因很实际Neo4j对属性图的Cypher查询支持远超RDF且前端可视化更友好。节点设计两类节点五种属性-Person节点必有name标准名如“林冲”可选alias别名数组如[“豹子头”,”林教头”]、hometown籍贯、nickname绰号、img_url头像路径-Event节点少量如“大闹野猪林”“风雪山神庙”用于承载复杂关系避免边爆炸。例如(鲁智深)-[PROTECTED]-(林冲)不如(鲁智深)-[PARTICIPATED_IN]-(大闹野猪林)-[PARTICIPATED_IN]-(林冲)语义清晰。关系设计12种语义明确的类型严格控制关系种类避免“has_relation”这种泛化边。全部12种均来自原著高频关系1.SHIFROM师从2.BLOOD_RELATION血缘3.BROTHERHOOD结义4.KILLED_BY被…杀死5.HOMETOWN籍贯6.NICKNAME绰号7.ALIAS别名8.SERVED_UNDER隶属9.RECOMMENDED_BY被…推荐10.TRAINED_BY被…训练11.ENEMIES_WITH敌对12.MARRIED_TO婚姻关键细节create_graph.py中所有CREATE语句均使用MERGE代替防止重复节点。例如MERGE (p:Person {name: $name})确保“林冲”只创建一次即使他在10条三元组中反复出现。同时脚本内置UNWIND批量导入427条关系导入耗时仅2.3秒i7笔记本比逐条CREATE快17倍。3.3 自然语言问答KGQA引擎LTP不是黑盒是你的语义探针问答模块KGQA/的精妙之处在于它把LTP的输出当作结构化中间表示而非最终答案。整个流程分四步每步都可调试Step 1问题预处理输入“林冲和谁是师兄弟”先做两件事- 去停用词移除“和”“谁”“是”“”等剩“林冲”“师兄弟”- 同义词扩展“师兄弟”→[“师兄弟”,“同门”,“同师”,“同出一门”]覆盖用户口语变体。Step 2LTP深度解析调用ltp_processor.analyze(question)得到- 分词结果[林冲, 和, 谁, 是, 师兄弟, ]- 词性标注[nh(人名), c(连词), r(代词), v(动词), n(名词), wp(标点)]- 命名实体[{word:林冲,pos:nh,ner:S-Nh}]- 依存句法{head:4,deprel:nsubj,id:0}“林冲”是“是”的主语。Step 3意图-槽位匹配这是最关键的一步。系统不依赖机器学习分类而是用规则模板库匹配- 模板1“[PERSON] 和 [WHO] 是 [RELATION]” → 触发关系查询- 模板2“[WHO] 杀了 [PERSON]” → 触发KILLED_BY反向查询- 模板3“[PERSON] 的 [ATTRIBUTE] 是什么” → 触发属性查询如“林冲的绰号”。匹配后提取槽位PERSON林冲RELATION师兄弟。注意“师兄弟”不是直接对应BROTHERHOOD边因为原著中“师兄弟”特指同师门如林冲与王进之徒需转换为SHIFROM的逆关系先找林冲的师父王进再找王进的其他徒弟史进、曹正等。Step 4Cypher生成与执行根据槽位生成动态CypherMATCH (p1:Person {name: 林冲})-[:SHIFROM]-(master)-[:SHIFROM]-(p2) WHERE p2.name 林冲 RETURN p2.name AS result执行后返回[史进, 曹正]。整个过程在200ms内完成无模型推理开销。实操心得首次调试问答时务必打开KGQA/debug_mode.py它会打印每一步的中间结果。我曾遇到“武松和潘金莲是什么关系”返回空追踪发现LTP把“潘金莲”识别为S-Ni地名而非S-Nh人名。解决方案是在ltp_processor.py的NER后加一层规则校验若词匹配raw_data/famous_names.txt含潘金莲、西门庆等强制修正为Nh。4. 前端交互与可视化实现让用户一眼看懂108将的关系网4.1 人物关系检索页不是搜索框而是关系导航仪templates/search.html的交互逻辑远超表面所见。当你输入“林冲”并点击搜索后端app.py的/search路由并非简单返回林冲节点而是执行三级关系展开查询MATCH (p:Person {name: $name}) OPTIONAL MATCH (p)-[r1]-(n1) OPTIONAL MATCH (n1)-[r2]-(n2) OPTIONAL MATCH (n2)-[r3]-(n3) RETURN p, collect(distinct {node:n1, rel:r1}) as level1, collect(distinct {node:n2, rel:r2}) as level2, collect(distinct {node:n3, rel:r3}) as level3这意味着页面展示的不仅是林冲的直接关联王进、陆谦、鲁智深还包括- Level1林冲的师父王进的其他徒弟史进- Level2陆谦的上司高俅SERVED_UNDER- Level3鲁智深保护过的金翠莲PROTECTED。这种设计让用户从单点切入自然延展出关系网络避免信息过载。UI上用不同颜色区分关系类型蓝色SHIFROM、红色KILLED_BY、绿色BROTHERHOOD鼠标悬停显示关系详情点击节点可跳转至该人物的检索页。4.2 人物关系全貌页D3.js不是炫技是关系密度的可视化表达templates/graph.html使用D3.js v7实现力导向图Force-Directed Graph但做了三项关键优化-节点大小编码中心性通过cypher计算每个节点的PageRank值CALL gds.pageRank.stream(myGraph) YIELD nodeId, score分数越高节点越大。“宋江”节点直径是“白胜”的3.2倍直观体现其枢纽地位-边粗细编码关系强度BROTHERHOOD边默认最粗3pxHOMETOWN边最细1px避免视觉噪音-智能布局防重叠启用d3.forceCollide(15)强制节点间距≥15px即使108个节点全量渲染也不会堆叠成一团乱麻。注意首次加载全图可能卡顿因需计算427条边的物理模拟。项目已预计算好布局坐标存于static/graph_layout.json。graph.html优先加载此JSON仅当文件不存在时才启动实时计算确保首屏秒开。4.3 问答界面降低认知负荷的设计哲学templates/qa.html的问答框刻意去掉所有技术感- 输入框placeholder写“试试问林冲和谁是师兄弟”而非“请输入自然语言问题”- 提交按钮文字是“问我”不是“提交查询”- 答案区用卡片式设计每条答案带来源标注如“来自‘林冲’词条”增强可信度- 当问题无法解析时不显示“未找到答案”而是给出引导“没听懂试试换种说法比如‘谁跟武松有血缘关系’”。这种设计源于我观察学生的真实行为他们不愿读文档但愿意点击示例问题。项目中6张截图里的“人物关系问答.png”就是用户输入“鲁智深和杨志怎么认识的”后的真实响应——答案卡片显示“大相国寺菜园事件”并附事件节点链接点击可跳转至事件详情页。5. 部署与调试全流程四步启动背后的17个关键检查点5.1 四步启动法详解每一步的成败关键按README.md执行四步看似简单实则每步都有隐藏关卡Step 1pip安装依赖pip install -r requirement.txt- 关键检查点1确认Python版本≥3.8LTP 3.4.0不支持3.11- 关键检查点2requirement.txt中py2neo4.3.0必须锁定版本新版py2neo 5.x与Neo4j 4.4不兼容- 关键检查点3Windows用户需提前安装Microsoft Visual C 14.0否则ltp编译失败提示在README.md第7行已注明。Step 2启动Neo4jneo4j console或 Desktop版- 关键检查点4确认Neo4j监听地址为bolt://localhost:7687非https- 关键检查点5数据库用户名密码必须为neo4j/123456app.py中硬编码首次启动后需在Browser里修改密码并同步更新app.py- 关键检查点6关闭Neo4j的APOC插件apoc-4.4.*.jar本项目未使用其高级功能开启反而导致启动慢。Step 3运行create_graph.py建库- 关键检查点7脚本会自动检测neo_db/是否存在若存在则跳过导入直接提示“图谱已存在”。此时需手动删除该目录才能强制重建- 关键检查点8导入完成后执行MATCH (n) RETURN count(n)应返回108MATCH ()-[r]-() RETURN count(r)应返回427这两个数字是图谱健康的黄金指标- 关键检查点9若报错Connection refused90%是Neo4j服务未启动检查任务管理器中是否有java.exe进程Neo4j底层是Java。Step 4执行app.py启动服务python app.py- 关键检查点10终端应显示* Running on http://127.0.0.1:5000而非192.168.x.x- 关键检查点11若报错ModuleNotFoundError: No module named ltp说明LTP未正确安装需进入KGQA/目录执行pip install ltp3.4.0- 关键检查点12访问http://localhost:5000后F12打开开发者工具Network标签下应看到/static/js/d3.min.js等资源200加载成功若404则检查static/目录路径是否正确。5.2 常见问题速查表我踩过的12个坑帮你省下8小时问题现象根本原因解决方案出现场景LTP model not foundKGQA/ltp_model/路径配置错误检查app.py第32行LTP_MODEL_PATH确保指向绝对路径如os.path.join(BASE_DIR, KGQA, ltp_model)所有问答请求返回500检索页空白控制台报Uncaught ReferenceError: d3 is not definedstatic/js/d3.min.js未加载确认static/目录在项目根目录且app.py中app.static_folder static未被注释全貌图和检索页无法渲染问答返回“未找到答案”但Cypher在Browser中可查LTP分词结果与图谱节点名不匹配在KGQA/ltp_processor.py的analyze()后添加print(分词结果:, words)对比words与neo_db中name字段是否一致如“鲁提辖”需映射为“鲁智深”所有口语化问题失效Neo4j启动后http://localhost:7474打不开浏览器缓存了旧版Neo4j登录页强制刷新CtrlF5或换Chrome无痕窗口访问初次安装Neo4jcreate_graph.py运行卡住无报错Windows Defender实时防护拦截Python进程临时关闭Defender或添加python.exe到排除列表图谱初始化阶段问答页输入中文后显示乱码Flask未设置UTF-8响应头在app.py的app.route(/qa)函数开头添加response make_response(...); response.headers[Content-Type] application/json; charsetutf-8中文问题无法解析全貌图节点重叠严重D3力导向参数未生效检查static/js/graph.js中forceSimulation().force(collide, d3.forceCollide(15))是否被注释全图加载后节点堆叠pip install ltp报错error: Microsoft Visual C 14.0 is required缺少C编译环境下载安装Microsoft C Build ToolsWindows首次安装LTP访问localhost:5000显示404 Not FoundFlask未正确路由检查app.py中app.route(/)是否定义且if __name__ __main__:块未被注释服务启动后首页不可达neo4j console报错Failed to start Neo4j: java.lang.NoClassDefFoundErrorJava版本不匹配卸载Java 17安装Java 11Neo4j 4.4官方要求Neo4j启动失败检索“武松”返回空但图谱中有该节点Person节点name属性值为“武二郎”而非“武松”运行MATCH (p:Person) WHERE p.name CONTAINS 武 RETURN p.name手动修正SET p.name 武松数据清洗不彻底问答响应超时5sLTP模型加载耗时过长在KGQA/ltp_processor.py中启用ltp LTP(model_pathLTP_MODEL_PATH, devicecpu)显式指定CPU设备高负载服务器最后一个经验部署完成后务必用三类问题测试系统健壮性1.边界问题“谁杀了西门庆”西门庆不在图谱中应返回友好提示2.模糊问题“林冲的师父的师父是谁”需支持两跳查询验证Cypher生成逻辑3.错别字问题“林冲和路谦是什么关系”“路谦”是“陆谦”的常见错写应在name_mapping.json中预置纠错。这三类测试通过你的知识图谱才算真正“活”了——它不再是一堆静态数据而是一个能理解、能推理、能容错的语义系统。6. 项目延伸与教学价值从水浒图谱到你的领域知识图谱这个项目真正的价值不在于它讲了水浒而在于它提供了一套可迁移的知识图谱工程范式。我带学生做毕设时常让他们把这套流程迁移到自己的专业领域历史系同学用它构建“唐宋八大家交往图谱”计算机系同学改成“开源项目技术栈依赖图谱”甚至有医学院学生重构为“中药配伍禁忌图谱”。迁移的关键不是代码而是那套问题驱动的设计思维。比如你想做“中国航天发射任务图谱”只需替换四个模块-spider/爬国家航天局官网的发射清单清洗出“火箭型号-发射时间-载荷-轨道-结果”五元组-create_graph.py定义Mission、Rocket、Satellite三类节点LAUNCHED_BY、CARRIES、FAILED_DUE_TO等关系-KGQA/把LTP换成专用于科技文献的SciBERT但问答模板不变——“长征五号发射了哪些卫星”仍走“[ROCKET] 发射了 [WHAT]”模板-templates/全貌图改为时间轴任务树混合视图突出“2020-2023年北斗组网”这样的阶段性里程碑。这种迁移之所以可行是因为项目剥离了所有领域特定逻辑把通用能力沉淀在骨架里爬虫框架、清洗规则引擎、图谱建模规范、问答意图模板库、可视化交互组件。你拿到的不是一份水浒作业答案而是一套知识图谱的乐高积木——水浒是说明书里的示例模型而积木本身可以拼出任何你关心的世界。我个人在实际教学中发现学生掌握这套范式后最大的转变是提问方式从“老师Neo4j怎么装”变成“老师我想查‘李白和杜甫有没有同游经历’这个关系在图谱里该怎么建”。当问题从工具层上升到语义层知识图谱才真正开始生长。本文还有配套的精品资源点击获取简介直接跑起来就能用的《水浒传》知识图谱项目覆盖从数据采集到交互问答全流程。爬虫自动抓取108位好汉的姓名、绰号、籍贯、师承、仇杀等结构化信息清洗后生成人物-关系-属性三元组导入Neo4j图数据库中文处理依赖哈工大LTP 3.4.0支持分词、词性标注和命名实体识别让‘鲁智深和杨志怎么认识的’‘谁跟武松有血缘关系’这类口语化问题能准确解析并查图返回答案Flask搭建的前端提供三个实用功能页输入人名查其所有关联人物如林冲→王进、陆谦、鲁智深等、拖拽缩放查看全量108将关系拓扑图、在问答框里打字提问即时得答案附带完整可运行代码、详细部署指南含Neo4j服务配置、LTP模型路径设置、图谱初始化脚本说明、教学PPT、6张真实界面截图首页/检索/全图/问答/架构/方案、PDF项目方案书适合课程设计、毕业设计或知识图谱入门练习按README四步操作——pip装依赖、启动Neo4j、运行create_graph.py建库、执行app.py启动服务localhost:5000即可体验全部功能。本文还有配套的精品资源点击获取