基于Flask与Neo4j构建三国人物知识图谱：从数据抽取到可视化问答

简介：这是一套面向Python初学者与知识图谱入门者的实战项目资源，基于Flask框架构建三国演义人物关系可视化及智能问答系统，解决古典文学数据结构化分析与交互式探索的实际问题。资源包共364个文件，含12个核心Python脚本（实现后端逻辑、图谱构建与问答接口）、4个HTML前端页面、11个CSS与8个JS文件（支撑Bootstrap+Datatables的响应式可视化界面）、306张人物关系图谱截图及3个JSON格式结构化数据集，整体压缩包仅8.45MB，轻量易部署。已有217人学习下载，配套提供完整部署文档、清晰目录结构说明及开箱即用的数据替换方案。读者可直接运行服务查看动态力导向图谱、检索人物关系链路，并通过自然语言提问获取答案，同时掌握Flask Web开发、Neo4j或NetworkX图谱建模、前端可视化集成等关键技术环节。

1. 项目概述：当三国演义遇上知识图谱

最近在整理个人项目库时，翻出了一个几年前做过的“老伙计”——一个基于Flask和知识图谱的三国演义人物关系可视化及问答系统。这个项目虽然技术栈不算最新潮，但它的设计思路和实现路径，对于想入门知识图谱应用、或者想结合经典文本做点有趣可视化的小伙伴来说，依然有很强的参考价值。它本质上是一个将非结构化的文本（《三国演义》小说）转化为结构化的知识网络，并提供一个交互界面让用户既能“看图说话”，也能“有问必答”的系统。

简单来说，这个项目干了三件事：第一，它把《三国演义》里上百号人物、他们之间的亲属、隶属、敌对、合作等复杂关系，从文字描述里“抽”出来，变成一张巨大的、可追溯的关系网。第二，它用可视化的方式把这张网清晰地呈现出来，你可以像查看地图一样，直观地看到“曹操”周围围绕着哪些文臣武将，他和“刘备”之间隔着多少层恩怨。第三，它内置了一个简单的问答引擎，你不再需要去翻书查“关羽的结拜兄弟是谁？”，直接输入问题，系统就能从构建好的知识图谱里找到答案并返回。对于历史爱好者、文学研究者，或者单纯对数据可视化感兴趣的程序员，这个项目都是一个很好的练手素材，它能让你亲身体验从数据获取、知识建模、存储到应用开发的全流程。

2. 核心架构与工具选型解析

2.1 为什么是Flask + Neo4j这个组合？

当初选择这个技术栈，是经过一番权衡的。核心需求很明确：需要一个轻量级的Web框架来快速搭建前后端，以及一个专门为图数据设计的数据库来高效存储和查询人物关系。

后端框架：FlaskFlask是一个Python的微型Web框架，它的“微”体现在核心简洁，但扩展性极强。对于这个项目来说，它有几个无法拒绝的优点：

1. 快速上手：相比于Django那种“全家桶”式框架，Flask的学习曲线平缓，几行代码就能跑起一个Web服务，非常适合快速原型开发。
2. 灵活自由：没有强制的项目结构，你可以按自己喜欢的方式组织代码。这对于一个融合了数据处理、图谱构建、API服务和前端渲染的综合性项目来说，非常友好。
3. 丰富的扩展：通过Flask-SQLAlchemy、Flask-Login、Flask-RESTful等扩展，可以轻松实现ORM、用户认证、构建REST API等功能。在这个项目中，我们主要用其搭建路由，提供数据API接口。

图数据库：Neo4j存储人物关系，传统的关系型数据库（如MySQL）会非常吃力。想象一下，要查询“所有与曹操直接相关的人物”，你需要频繁地进行多表JOIN，效率低下且查询语句复杂。而Neo4j是原生图数据库，它的数据模型就是“节点-关系”。

• 节点：代表实体，比如“刘备”、“关羽”、“赤壁之战”。
• 关系：代表节点间的连接，有类型和方向，比如“刘备”-[结义]->“关羽”，[参与]->“赤壁之战”。 这种结构对于关系查询是天生的优势，例如查找“孙权的两度联姻对象”，用Neo4j的查询语言Cypher写出来非常直观：MATCH (a:人物 {name:'孙权'})-[r:联姻]->(b:人物) RETURN b.name。其查询性能在深度关系遍历上远超关系型数据库。

可视化库：ECharts / D3.js / Vis.js前端可视化是项目的门面。当时可选的有：

• ECharts：百度开源，文档丰富，图表类型多，配置化程度高。对于快速实现一个关系力导向图来说，它的graph组件非常合适，通过简单的JSON配置就能实现交互式图谱，适合大多数场景。
• D3.js：功能无比强大，自由度极高，你可以控制每一个像素的渲染。但学习成本也高，需要深入理解SVG和数据绑定。如果你追求极致的定制化效果（比如为不同关系类型设计独特的动画），D3是终极选择。
• Vis.js：一个轻量级的动态可视化库，它的网络模块（vis-network）专门用于显示网络拓扑图，操作简单，内置拖拽、缩放、物理引擎等交互，开箱即用。 在这个项目中，我最终选择了ECharts，原因在于其与Flask结合简单（后端传JSON，前端用JS初始化），且能满足基本的力导向图布局、高亮关联、点击查看详情等需求，平衡了效果和开发效率。

2.2 数据从哪里来？——数据集构建的两种路径

项目源码包里附带的data文件夹，通常包含了处理好的结构化数据。但这些数据最初是如何从小说文本变成图谱数据的呢？这里有两种主流方法：

路径一：基于规则与词典的信息抽取（本项目采用）这是比较传统但可控的方法，适合领域固定、结构相对规范的文本。

1. 人物清单构建：首先，你需要一个“三国人物白名单”。可以从权威资料（如《三国志》人物列表）或公开的数据集中获取，形成一个基础人物库。这能避免把“店小二”、“老农”这类非重要角色抽取进来。
2. 关系规则定义：人工定义关系类型和触发词。例如：
   • 关系类型：结义，触发词：“结为兄弟”、“桃园结义”。
   • 关系类型：隶属，触发词：“麾下”、“部将”、“拜为”。
   • 关系类型：敌对，触发词：“讨伐”、“大战”、“击败”。
3. 文本扫描与匹配：用Python编写脚本，逐章扫描《三国演义》文本。当句子中同时出现两个白名单中的人物，并且包含了某个关系触发词时，就认为这两人之间存在该关系，并将其记录到结构化数据中（如CSV文件，包含人物A、关系、人物B、出处章节）。

注意：这种方法精度较高，但召回率依赖规则完备性，且无法发现隐含关系。例如“曹操赠予关羽赤兔马”，规则可能需要额外定义“赠予”来表示一种赏识或拉拢的“关系”。

路径二：基于NLP模型的信息抽取（进阶方向）随着自然语言处理技术的发展，现在更流行使用预训练模型进行自动抽取。

1. 命名实体识别：使用NER模型（如HanLP、LTP、或基于BERT的微调模型）自动识别文本中的所有人物实体，即使是不在初始白名单中的人物也能被识别。
2. 关系抽取：使用关系抽取模型，判断句子中两个实体间的关系。这需要标注好的训练数据，或者利用远程监督的方法自动构造数据。对于三国领域，可以寻找开源的RE模型或进行微调。 这种方法自动化程度高，能发现更复杂的关系，但对计算资源和数据标注有要求。对于初学者，建议从路径一开始，理解整个流程后，再尝试用NLP模型替换其中的某些环节。

3. 从零到一：系统搭建详细步骤

3.1 环境准备与依赖安装

假设你已经在本地机器上准备好了Python环境（建议3.7以上版本），接下来是具体的环境搭建步骤。

第一步：安装并启动Neo4j数据库

1. 前往Neo4j官网下载Neo4j Desktop社区版。这是一个集成了数据库实例和图形化管理工具（Neo4j Browser）的桌面应用，非常适合开发和测试。
2. 安装后，创建一个新的数据库实例（例如命名为ThreeKingdoms），设置密码（记住它，后面连接要用），然后点击“Start”启动数据库。
3. 打开Neo4j Browser（通常随Desktop一起启动），在浏览器中输入http://localhost:7474，使用默认用户名neo4j和你设置的密码登录。能看到一个命令行界面，说明数据库服务已经正常运行。

第二步：创建Python虚拟环境与安装包为了避免包冲突，强烈建议使用虚拟环境。

# 在项目根目录下 python -m venv venv # 创建虚拟环境 # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖，假设你有requirements.txt文件 pip install -r requirements.txt

如果项目没有提供requirements.txt，你需要手动安装核心包：

pip install flask neo4j py2neo pandas jieba # 基础必备 # 如果涉及更复杂的NLP处理，可能还需要 # pip install hanlp transformers

这里解释一下几个关键包：

• flask: Web框架核心。
• neo4j: Neo4j官方的Python驱动，用于执行Cypher查询。
• py2neo: 另一个流行的Neo4j Python工具包，它提供了更高级的OGM（对象图映射）功能，使用起来有时比官方驱动更便捷。本项目示例中可能用的是它。
• pandas: 数据处理和分析，用于清洗和准备CSV数据。
• jieba: 中文分词库，在基于规则的信息抽取中，用于对句子进行分词，辅助实体匹配。

3.2 知识图谱的构建与数据导入

这是项目的核心“数据工程”部分。我们假设你已经通过规则或NLP方法，得到了一个relationships.csv文件，格式如下：

person_a	relation	person_b	chapter
刘备	结义	关羽	第一回
曹操	隶属	郭嘉	第十回
周瑜	敌对	诸葛亮	第四十四回

编写数据导入脚本import_data.py这个脚本的任务是读取CSV文件，并将数据转化为节点和关系，批量插入Neo4j。

from py2neo import Graph, Node, Relationship import pandas as pd # 1. 连接Neo4j数据库 # 注意：将 `your_password` 替换为你启动Neo4j时设置的密码 graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) # 2. 清空现有图谱（谨慎操作，仅用于初始化） graph.delete_all() # 3. 定义唯一性约束（确保人物节点不重复） graph.run("CREATE CONSTRAINT ON (p:Person) ASSERT p.name IS UNIQUE") # 4. 读取数据 df = pd.read_csv('data/relationships.csv') # 5. 创建节点和关系的缓存字典，避免重复创建节点 node_cache = {} for index, row in df.iterrows(): p_a_name, rel_type, p_b_name, chapter = row['person_a'], row['relation'], row['person_b'], row['chapter'] # 获取或创建人物A节点 if p_a_name not in node_cache: node_a = Node("Person", name=p_a_name) graph.create(node_a) node_cache[p_a_name] = node_a else: node_a = node_cache[p_a_name] # 获取或创建人物B节点 if p_b_name not in node_cache: node_b = Node("Person", name=p_b_name) graph.create(node_b) node_cache[p_b_name] = node_b else: node_b = node_cache[p_b_name] # 创建关系。关系可以带有属性，例如出处章节。 rel = Relationship(node_a, rel_type, node_b, chapter=chapter) graph.create(rel) print("数据导入完成！")

实操心得：在导入大量数据前，先创建唯一性约束（CREATE CONSTRAINT）至关重要。这能保证刘备这个人物在数据库中只存在一个节点，后续所有关于刘备的关系都会挂接到这个唯一的节点上，避免数据冗余和查询混乱。另外，使用node_cache字典缓存已创建的节点对象，能大幅提升导入效率，否则每处理一行数据都要去数据库查询一次节点是否存在，速度会非常慢。

运行这个脚本后，打开Neo4j Browser，输入查询MATCH (n) RETURN n LIMIT 25，你应该能看到可视化的人物节点和连接线。

3.3 Flask后端API开发

后端的主要任务是提供数据接口，供前端调用。我们会在Flask中创建几个核心路由。

项目结构建议

ThreeKingdoms-KG/ ├── app.py # Flask应用主入口 ├── config.py # 配置文件（数据库连接等） ├── kg/ # 知识图谱操作模块 │ ├── __init__.py │ └── neo4j_connector.py # 封装所有Neo4j查询 ├── static/ # 静态文件（CSS, JS, 图片） │ └── js/ │ └── main.js ├── templates/ # Jinja2模板 │ └── index.html └── data/ # 原始数据 └── relationships.csv

核心API接口实现（app.py部分代码）

from flask import Flask, render_template, jsonify, request from kg.neo4j_connector import Neo4jConnector app = Flask(__name__) kg_connector = Neo4jConnector() # 实例化图谱连接器 @app.route('/') def index(): """渲染主页面""" return render_template('index.html') @app.route('/api/graph', methods=['GET']) def get_full_graph(): """获取全局图谱数据（用于初始化）""" # 限制返回节点和关系的数量，防止前端卡死 limit = request.args.get('limit', default=100, type=int) data = kg_connector.get_graph_data(limit=limit) return jsonify(data) @app.route('/api/search/person', methods=['GET']) def search_person(): """根据人物名搜索其关联子图""" name = request.args.get('name', '') if not name: return jsonify({'nodes': [], 'links': []}) data = kg_connector.get_person_subgraph(name) return jsonify(data) @app.route('/api/qa', methods=['POST']) def answer_question(): """简单问答接口""" question = request.json.get('question', '') if not question: return jsonify({'answer': '请输入问题。'}) # 这里是一个极其简单的规则匹配问答示例 answer = kg_connector.simple_qa(question) return jsonify({'answer': answer})

Neo4j查询封装（kg/neo4j_connector.py）

from py2neo import Graph import re class Neo4jConnector: def __init__(self): self.graph = Graph("bolt://localhost:7687", auth=("neo4j", "your_password")) def get_graph_data(self, limit=100): """获取图谱数据，格式化为ECharts Graph所需格式""" query = f""" MATCH (p1:Person)-[r]->(p2:Person) RETURN p1.name as source, p2.name as target, type(r) as relation LIMIT {limit} """ result = self.graph.run(query).data() nodes_set = set() links = [] for record in result: source, target, relation = record['source'], record['target'], record['relation'] nodes_set.add(source) nodes_set.add(target) links.append({ 'source': source, 'target': target, 'name': relation # 关系类型作为连线名称 }) nodes = [{'name': node_name, 'category': 0} for node_name in nodes_set] # category可用于分类 return {'nodes': nodes, 'links': links} def get_person_subgraph(self, person_name, depth=2): """查询某个人物在指定深度内的关系网络""" query = """ MATCH path = (p:Person {name: $name})-[*1..%s]-(related:Person) UNWIND relationships(path) as r RETURN startNode(r).name as source, endNode(r).name as target, type(r) as relation """ % depth result = self.graph.run(query, name=person_name).data() # ... 类似地格式化为nodes和links return formatted_data def simple_qa(self, question): """基于规则的简单问答""" # 示例：处理“关羽的结义兄弟是谁？” if '结义' in question and '谁' in question: # 使用jieba或正则提取人物名，这里简化处理 match = re.search(r'(\w+)的结义', question) if match: person = match.group(1) query = """ MATCH (p:Person {name: $person})-[:结义]-(brother:Person) RETURN brother.name as name """ result = self.graph.run(query, person=person).data() names = [r['name'] for r in result] return f"{person}的结义兄弟是：{', '.join(names)}。" return "抱歉，我暂时无法回答这个问题。"

注意事项：在生产环境中，绝对不要像上面simple_qa函数那样将用户输入直接拼接到Cypher查询字符串中（f-string或%格式化），这会导致严重的Cypher注入安全风险。正确的做法是始终使用参数化查询，即$param语法，如self.graph.run(query, name=person_name)所示。上面的get_graph_data函数中的limit参数拼接仅用于演示，在实际接受用户输入时也应参数化。

3.4 前端可视化与交互实现

前端页面templates/index.html主要负责布局，而交互逻辑在static/js/main.js中。这里的关键是如何使用ECharts绘制力导向图。

ECharts力导向图核心配置

// main.js function initChart(graphData) { var chartDom = document.getElementById('graph-container'); var myChart = echarts.init(chartDom); var option = { tooltip: {}, legend: { data: ['人物'] // 可以根据节点类别显示图例 }, series: [{ type: 'graph', layout: 'force', // 力引导布局 data: graphData.nodes.map(function (node) { return { id: node.name, name: node.name, category: node.category, symbolSize: 20, // 节点大小，可根据度数动态计算 draggable: true }; }), links: graphData.links.map(function (link) { return { source: link.source, target: link.target, name: link.name, lineStyle: { color: getRelationColor(link.name) // 根据关系类型设置颜色 } }; }), force: { repulsion: 200, // 节点之间的斥力 gravity: 0.1, // 向中心的引力 edgeLength: [50, 150] // 边的长度范围 }, roam: true, // 允许拖拽缩放 label: { show: true, position: 'right' }, emphasis: { // 高亮样式 focus: 'adjacency', lineStyle: { width: 3 } } }] }; myChart.setOption(option); // 添加点击事件，点击节点时查询并更新为该节点的子图 myChart.on('click', function (params) { if (params.dataType === 'node') { var personName = params.data.name; fetch('/api/search/person?name=' + encodeURIComponent(personName)) .then(response => response.json()) .then(data => { myChart.setOption({ series: [{ data: data.nodes, links: data.links }] }); }); } }); } // 初始化加载全局图谱 fetch('/api/graph?limit=150') .then(response => response.json()) .then(data => initChart(data));

这段代码实现了基本的力导向图渲染和交互。节点可拖拽，布局力参数（repulsion,gravity）需要根据节点数量多次调整以达到最佳视觉效果。点击节点时，会向后台请求该人物的局部关系网络并更新图表，实现了“下钻”查看的交互。

4. 问答系统的进阶思考与优化

项目自带的问答系统通常比较简单，基于规则匹配。要让问答变得更智能，我们可以从以下几个方向进行优化，这也是当前知识图谱与NLP结合的热点。

4.1 从规则匹配到语义解析

简单的关键词匹配（如判断问题里是否有“结义”、“谁”）脆弱且局限。进阶的方法是进行语义解析，将自然语言问题转化为结构化的查询条件（即Cypher查询模板的参数）。

1. 意图识别：判断用户问题属于哪种查询意图。例如，“关羽的结义兄弟是谁？”意图是查询关系_结义对象；“曹操参与了哪些战役？”意图是查询人物_参与事件。可以用一个分类器（如基于BERT的文本分类模型）来实现。
2. 实体链接：识别问题中提到的实体（如“关羽”、“曹操”），并将其链接到知识图谱中对应的节点ID。这需要解决别名问题（如“关云长”、“曹孟德”）。
3. 查询模板填充：为每种意图预定义Cypher查询模板。例如，对于意图查询关系_结义对象，模板是MATCH (p:Person {name: $entity})-[:结义]-(o:Person) RETURN o.name。系统识别出意图和实体后，将实体名$entity=关羽填入模板，执行查询得到答案。

4.2 结合RAG增强复杂问答能力

对于更复杂、需要综合多段信息才能回答的问题，或者图谱中不存在直接关系的问题，可以引入检索增强生成技术。

1. 知识库构建：除了结构化图谱，将《三国演义》原著每一回的内容，或者人物生平介绍等非结构化文本，进行切片并向量化，存入向量数据库（如ChromaDB、Milvus）。
2. 混合检索：当用户提问时：
   • 图谱检索：先尝试用上述语义解析的方法，从知识图谱中查找精确的结构化答案。
   • 向量检索：如果图谱检索失败或答案不完整，则将用户问题也向量化，去向量数据库中检索语义最相关的文本片段。
3. 答案生成：将检索到的图谱查询结果（结构化三元组）和相关文本片段一起，作为上下文，输入到大语言模型（如ChatGLM、Qwen等经过指令微调的模型）中，让模型生成一个连贯、完整的自然语言答案。 例如，问题“诸葛亮和司马懿在军事上有过哪些经典对决？”。图谱可能只记录了两人[敌对]关系。向量检索则可以找到“六出祁山”、“空城计”、“上方谷之战”等详细描述文本。LLM综合这些信息，就能生成一段精彩的总结。

4.3 性能优化与部署考量

当数据量变大（人物上千，关系上万）时，前端一次性加载全图会导致浏览器卡死，后端查询也可能变慢。

1. 后端分页与懒加载：修改/api/graph接口，不再返回全量数据。首次只返回中心度最高的前N个核心人物及其直接关系。当用户拖动视图或搜索时，再按需加载新区域的人物数据。
2. 数据库索引优化：确保在Person节点的name属性上建立了唯一约束（它同时也是索引）。对于频繁按关系类型查询的场景，可以考虑对关系类型建立索引（Neo4j 4.x+ 支持关系属性索引）。
3. 查询优化：避免使用[*]这种无界深度的查询，它会导致性能爆炸。始终指定深度范围，如[*1..3]。对于复杂的多跳查询，使用APOC库中的路径扩展过程，性能更好。
4. 部署：开发完成后，可以使用Gunicorn或uWSGI作为Flask应用的WSGI服务器，配合Nginx进行反向代理，部署到云服务器上。Neo4j也可以部署在服务器或使用云服务（如Neo4j Aura）。

5. 常见问题与调试实录

在实际开发和运行过程中，你几乎一定会遇到下面这些问题。

5.1 数据导入与连接问题

问题1：运行导入脚本时，报错“Unable to connect to Neo4j using...”

• 排查：这是最常见的连接问题。
  1. 检查Neo4j服务是否启动：确认Neo4j Desktop里的数据库实例是“Running”状态。
  2. 检查连接协议和端口：默认的Bolt协议端口是7687，HTTP端口是7474。在代码中确保使用的是bolt://localhost:7687。
  3. 检查认证信息：用户名默认是neo4j，密码是你第一次启动时设置的。如果你修改过密码，代码中的密码也必须更新。
  4. 防火墙：确保本地防火墙没有阻止7687端口。

问题2：导入数据后，在Neo4j Browser中查询不到节点。

• 排查：
  1. 事务提交：确保你的创建操作被提交了。在使用py2neo的graph.create()时，它是自动提交的。但如果你使用了graph.begin()开启事务，必须最后执行graph.commit(tx)。
  2. 标签匹配：在Neo4j Browser中查询时，你创建的节点标签是Person，那么查询语句应为MATCH (p:Person) RETURN p。如果查询MATCH (n) RETURN n，会返回所有标签的节点，也能看到。
  3. 清空缓存：Neo4j Browser有缓存，尝试在查询输入框旁点击“清除”按钮，或者运行:clear命令。

5.2 前端图表显示异常

问题3：ECharts图一片空白，控制台无报错。

• 排查：
  1. 检查容器：确保<div id="graph-container">有明确的宽度和高度（例如style="width: 100%; height: 600px;"），没有高度图表无法渲染。
  2. 检查数据格式：在浏览器开发者工具的“网络”标签页中，查看/api/graph接口返回的JSON数据是否符合ECharts Graph要求。核心格式是{ nodes: [{name: '...', category: 0}, ...], links: [{source: 'A', target: 'B'}, ...] }。确保source和target的值在nodes的name中存在。
  3. 检查JS控制台：虽然可能没报错，但可能有警告信息，比如“Invalid data”。

问题4：节点和连线重叠严重，布局混乱。

• 调整力导向参数：这是力导向布局的常见问题，需要耐心调整series[0].force下的参数：
  • repulsion：节点间的斥力。值越大，节点越分散。节点多时需调大（如300-500）。
  • gravity：向中心的引力。值越大，图越向中心收缩。通常设一个较小的值（0.1）防止图飞散。
  • edgeLength：连线的理想长度。可以是一个范围，如[30, 100]，布局器会尝试让边长接近这个范围。
  • 多次尝试：没有标准值，需要根据你的数据量和视觉效果反复调整。可以提供一个滑块控件让用户实时调整，这也是很多专业可视化工具的做法。

5.3 问答功能不准确

问题5：问答系统只能回答预设的几种问题模式，泛化能力差。

• 这是规则系统的固有局限。解决方案就是向4.1和4.2节提到的语义解析和RAG方向升级。
• 短期改进：可以大幅扩充规则库。使用更灵活的正则表达式，并加入同义词。例如，对于“父亲”，规则可以匹配“爸爸”、“爹”、“父皇”等。建立一个更全面的意图-模板映射表。

问题6：问答接口响应慢。

• 排查：
  1. Cypher查询优化：使用PROFILE或EXPLAIN命令在Neo4j Browser中分析你的问答查询语句，看是否有全节点扫描。确保查询利用了索引。
  2. 减少查询深度：检查你的问答查询是否使用了过深的路径查询（如[*1..10]），尝试降低深度。
  3. 后端缓存：对于常见、答案不变的问题（如“刘备的结义兄弟是谁？”），可以在Flask后端使用内存缓存（如functools.lru_cache）或Redis缓存查询结果，避免重复查询数据库。

这个项目就像一座桥梁，连接了古老的文本与现代的数据技术。从最基础的规则抽取到接入大语言模型，其扩展路径非常清晰。动手实现一遍，你会对知识图谱的应用逻辑有深刻的理解。

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