主要观点总结
本文主要讨论了知识图谱的存储方案和技术实现。作者首先介绍了遇到的存储问题，并探讨了两种实体存储方案：向量数据库和NoSQL数据库。经过与R1的讨论，作者决定使用MongoDB存储实体数据，使用图数据库Neo4j存储关系数据。文章还介绍了实体数据模型的设计，包括记录历史数据和更新状态的机制。此外，文章还涉及了Neo4j存储关系数据模型以及编码实现的细节。最后，作者提到了将完整代码上传到Github，并介绍了下一节的计划。
关键观点总结
关键观点1: 知识图谱的存储方案选择
作者面临存储问题，探讨了向量数据库和NoSQL数据库两种实体存储方案。最终决定使用MongoDB和Neo4j分别存储实体数据和关系数据。
关键观点2: 实体数据模型设计
实体数据模型需记录历史数据和更新状态。作者提到了canonical_state和version_chain的概念，用于存储最新状态和状态更新的历史。
关键观点3: 关系数据模型及编码实现
Neo4j用于存储关系数据，数据模型包括两个实体和它们之间的关系。作者还介绍了编码实现的细节，包括与R1讨论模块的输出、整合、优化和debug。
关键观点4: 代码上传及知识图谱搭建
作者将完整代码上传到Github，并介绍了运行程序搭建知识图谱的过程。目前1-51章的数据已经存放到知识图谱中，下一节将讨论校对模块。
文章预览
上一节我们已经用大模型从文本中识别提取出实体和关系，接下来要考虑存储的问题。 R1最初给我们的方案是向量化存储。 但后来讨论到实体的动态属性特性时又提到可以使用NoSQL数据库，如MongoDB。 也就是说实体存储现在至少有两种方案：向量数据库和NoSQL数据库。 具体怎么权衡，听听R1怎么说。 这个解释我觉得非常到位。特别是最后这张表，针对不同数据类型采用不同的存储方案。 经过进一步探索，我决定用MongoDB存储实体数据，用图数据库Neo4j存储关系数据。 虽然这两个数据库以前都没接触过，但现在有了AI，要用起来应该问题不大。 MongDB存储实体 存储的关键是对实体建模。实体的数据模型除了要保存最新的信息，也需要记录历史数据。比如主角一路打怪升级，不同时期的修为都需要记录。 在与R1多轮讨论后，最终得到了如下数据模型： cano
………………………………
