网文校对系统 - 存储实体和关系

上一节我们已经用大模型从文本中识别提取出实体和关系，接下来要考虑存储的问题。

R1最初给我们的方案是向量化存储。

但后来讨论到实体的动态属性特性时又提到可以使用NoSQL数据库，如MongoDB。

也就是说实体存储现在至少有两种方案：向量数据库和NoSQL数据库。

具体怎么权衡，听听R1怎么说。

这个解释我觉得非常到位。特别是最后这张表，针对不同数据类型采用不同的存储方案。

经过进一步探索，我决定用MongoDB存储实体数据，用图数据库Neo4j存储关系数据。

虽然这两个数据库以前都没接触过，但现在有了AI，要用起来应该问题不大。

MongDB存储实体

存储的关键是对实体建模。实体的数据模型除了要保存最新的信息，也需要记录历史数据。比如主角一路打怪升级，不同时期的修为都需要记录。

在与R1多轮讨论后，最终得到了如下数据模型：

canonical_state 是最新的状态，version_chain 里是状态更新的历史。

当往MongoDB中存储实体数据时，需要考虑不同的情况：

1. 实体不存在。

   这个简单，创建实体，初始化canonical_state和version_chain

2. 实体已经存在。

   需要更新canonical_state，并将当前状态加入到version_chain

代码实现方面主要靠R1输出，里面用了大量MongoDB的语法，看不懂没关系，只要知道大致意思就可以了。

Neo4j存储关系

关系的数据模型比较简单，就是两个实体（节点）和它们之间的关系（边）。

编码实现

前面基本上已经把知识图谱的技术方案讨论清楚了，接下来可以开发了。

先让R1生成项目目录结构，然后再分模块开发。

对于具体的代码，与R1讨论模块的时候基本上都有输出，我们需要整合在一起。当然，必要的优化和debug是少不了的。

整个过程走下来，开发这部分工作量占了50%。主要是因为对MongoDB和Neo4j不熟，需要边学边debug比较花时间。但难度不大，基本上都是体力活儿。真正有价值的还是前面讨论技术方案的部分。只要方案定了，编码实现怎么都能搞定。

完整代码已经上传到Github。https://github.com/cloudman6/novelpad

下面CloudMan就带着大家过一下代码，并运行程序搭建知识图谱。

1-51章已经存放到知识图谱中了，下一节我们讨论校对模块。

公众号Cloudman6