本文主要讨论了知识图谱的存储方案和技术实现。作者首先介绍了遇到的存储问题，并探讨了两种实体存储方案：向量数据库和NoSQL数据库。经过与R1的讨论，作者决定使用MongoDB存储实体数据，使用图数据库Neo4j存储关系数据。文章还介绍了实体数据模型的设计，包括记录历史数据和更新状态的机制。此外，文章还涉及了Neo4j存储关系数据模型以及编码实现的细节。最后，作者提到了将完整代码上传到Github，并介绍了下一节的计划。
作者面临存储问题，探讨了向量数据库和NoSQL数据库两种实体存储方案。最终决定使用MongoDB和Neo4j分别存储实体数据和关系数据。
实体数据模型需记录历史数据和更新状态。作者提到了canonical_state和version_chain的概念，用于存储最新状态和状态更新的历史。
Neo4j用于存储关系数据，数据模型包括两个实体和它们之间的关系。作者还介绍了编码实现的细节，包括与R1讨论模块的输出、整合、优化和debug。
作者将完整代码上传到Github，并介绍了运行程序搭建知识图谱的过程。目前1-51章的数据已经存放到知识图谱中，下一节将讨论校对模块。
上一节我们已经用大模型从文本中识别提取出实体和关系，接下来要考虑存储的问题。
R1最初给我们的方案是向量化存储。
但后来讨论到实体的动态属性特性时又提到可以使用NoSQL数据库，如MongoDB。
也就是说实体存储现在至少有两种方案：向量数据库和NoSQL数据库。
具体怎么权衡，听听R1怎么说。
这个解释我觉得非常到位。特别是最后这张表，针对不同数据类型采用不同的存储方案。
经过进一步探索，我决定用MongoDB存储实体数据，用图数据库Neo4j存储关系数据。
虽然这两个数据库以前都没接触过，但现在有了AI，要用起来应该问题不大。
MongDB存储实体
存储的关键是对实体建模。实体的数据模型除了要保存最新的信息，也需要记录历史数据。比如主角一路打怪升级，不同时期的修为都需要记录。
在与R1多轮讨论后，最终得到了如下数据模型：
canonical_state 是最新的状态，version_chain 里是状态更新的历史。
当往MongoDB中存储实体数据时，需要考虑不同的情况：
-
这个简单，创建实体，初始化canonical_state和version_chain
-
需要更新canonical_state，并将当前状态加入到version_chain
代码实现方面主要靠R1输出，里面用了大量MongoDB的语法，看不懂没关系，只要知道大致意思就可以了。
Neo4j存储关系
关系的数据模型比较简单，就是两个实体（节点）和它们之间的关系（边）。
编码实现
前面基本上已经把知识图谱的技术方案讨论清楚了，接下来可以开发了。
先让R1生成项目目录结构，然后再分模块开发。
对于具体的代码，与R1讨论模块的时候基本上都有输出，我们需要整合在一起。当然，必要的优化和debug是少不了的。
整个过程走下来，开发这部分工作量占了50%。主要是因为对MongoDB和Neo4j不熟，需要边学边debug比较花时间。但难度不大，基本上都是体力活儿。真正有价值的还是前面讨论技术方案的部分。只要方案定了，编码实现怎么都能搞定。
完整代码已经上传到Github。
https://github.com/cloudman6/novelpad
下面CloudMan就带着大家过一下代码，并运行程序搭建知识图谱。
1-51章已经存放到知识图谱中了，下一节我们讨论校对模块。
