网文校对系统 - 新方案

坦白讲，我对上一节基于知识库的校对方案本是抱有很大期望的。想着所有的内容都在那儿了，再加上R1强大的推理能力，还不是手到擒来？

可事实是如此残酷，脸被打得啪啪响。

失望归失望，问题还是得面对。

这里要特别说明一下：

知识库肯定是有用的，特别是对于问答系统，只是不适合网文校对的场景。

我们必须找新的方案。

这又一次进入到CloudMan的知识盲区，我没有任何经验可以依赖。

但AI有经验啊！

我先把需求提交给DeepSeek R1，让它推荐方案。下面是R1的回复：

可以看出R1对需求理解得还是很准确的，知道把校对的重点放在一致性上。

不过方案的核心也是构建知识库。看到这里我就忍不住要问了：既然都是知识库，那用coze的知识库行不行？

于是我赶紧把这个问题提交给R1：

R1细数了厂商知识库的核心短板与网文需求之间的矛盾。

而且R1还给出一个例子，进一步说明厂商知识库的不足：

我已经被说服了我。R1所描述的厂商知识库的工作方式确实与咱们上一节在调试窗口看到情况一致。

既然R1对厂商知识库的缺点认识得这么深刻，那我们就不得不好好看看它提出的知识库方案了。

构建知识库有三个步骤：

1. 文本分块切割，这个好理解。

2. 关键信息提取，这步看上去是重点，待会儿仔细研究。

3. 向量化存储，应该是把上一步提取的信息保存起来。

看看关键信息提取：

在跟R1的后续对话中，我了解到“实体”和“关系”是最重要的信息。按照二八原则和开发最小可行产品的思路，先搞定这两个。

对于网络小说,

实体就是角色，物品，事件及其属性。比如实体“萧炎”类型“人物”属性有“身份-斗帝”，“功法-焚决”，“伴侣-彩鳞”，“职业”等。

关系当然就是实体之间的关系了。比如师徒关系，归属关系等。

看到这里，不知道大家有没有这样的疑问：

这种知识库跟厂商的知识库本质区别在哪里？

我理解主要在信息的准确度和颗粒度大小上。

还记得上一节咱们创建的知识库是如何存储信息的吗？

是按分块存的。每个分块几百字，这种粒度是比较粗的。好处是大模型可以按语义快速匹配相关分块，这对于问答系统是相当有效的。

但对于网文校对，则需要更多细节信息，这样粗粒度的分块显然是不够的。所以R1的方案是先把这些关键信息提取出来，校验的时候直接比对关键信息，而不用在分块中大海捞针。

这个知识库的搭建方案大概是这个样子：

知识库对于CloudMan是完全陌生的领域，我不确定R1给的这个方案是不是行业主流方案。为了防止被它忽悠，我把同样的问题拿去咨询了其他大模型。还好，证明这个方案是靠谱的，大家都是这么做的。

这种方案其实有个专业名称，叫构建“知识图谱”。

知识图谱是一种结构化的信息表示方法，它将知识以节点和边的形式组织起来，节点表示实体，边表示实体之间的关系。

说实话，理清楚这个方案和里面的诸多概念CloudMan还是花了不少力气。与R1来来回回几十轮对话。因为是小白，经常得要求R1进一步解释，比如“到底什么是命名实体识别？”，“请举例说明实体识别对网文校对的好处”，“实体和关系如何结合起来使用？”

有时候问题A扯出问题B，然后又扯到C。多轮对话后想回到A继续探讨，结果发现R1已经跟不上趟了，完全忘了之前讨论的内容 :-)

估计R1当时上下文里已经没有A了。这种时候我只能先把前面A的讨论成果总结出来，然后新开个对话窗口丢给R1。

但瑕不掩瑜。有了AI，探索新领域可比以前高效多了。

有时候我不禁感叹，现在真是个好时代啊！

把AI当作这个领域专家，有什么不懂的尽管问。

可能刚开始我们的问题比较粗浅，AI答复得也比较笼统，不过没关系啊，可以继续追问啊。反正它又不会烦，也不会累，更不会给我们白眼。

提问，回答，再问，再回答，继续追问，继续回答……

这是过程既兴奋又愉悦，完全沉浸其中。

对AI，有时我们还可以提一些前瞻性的问题，看看它有何高见。

比如用平台的知识库校对网文效果不好，一个重要原因是上下文窗口的限制导致大模型无法获取足够的章节内容。那如果这个限制没有了会怎样？下面是R1的答复：

结论就是：理论上可行，但可能存在“超长文本可能导致注意力机制的计算复杂度增加，影响速度和准确性”的问题。同时效率和成本也是一个挑战。

也就是说，按照目前的技术能力，即便没有上下文窗口的限制，厂商的知识库也不是最优方案。

那就不纠结了，下一节详细讨论R1知识图谱方案的各个模块。

公众号Cloudman6