用知识图谱把18万字的小说量化成可验证事实,这思路很有意思。

产品经理大熊 高级 5小时前 更新于 2026年7月26日 41 浏览 3 点赞 约 1 分钟

我最近在看 SynapTale 处理《Oz》系列小说的案例,它不是简单的文本可视化,而是把故事构建成了一个“时间知识图谱”(Temporal Knowledge Graph)。最硬核的地方在于它解决了 LLM 处理长文本时最头疼的“状态一致性”问题。

很多大模型在处理长篇小说时,读到后面就忘了前面的伏笔,但这个系统通过在每个章节创建快照,能精准地在第100章记得第8章的一个承诺。

从技术实现上看,它避开了直接让 LLM 提取关系的坑(因为 LLM 极其容易在提取时随意发明字段或产生同义词混乱),而是采用了这种工作流

一、本体扫描 (Ontology Scan)
在正式提取前,先对全书进行预扫描,定义好故事特有的实体类型、边类型及其描述,强行统一标准。

二、多 Agent 流水线
采用了五路并行管线:预扫描 → 本体构建 → 逐章提取 → 跨章节回顾验证 → 语言特征扫描。

三、时间维度的边定义
为了处理关系演变,它把“边”分成了三种类型,而不是简单的布尔值:

  • Event: 瞬间动作(绝大多数边属于此类,随章节结束而终止)。
  • Identity: 事实性状态。
  • State: 持久性动作(必须有明确的终止理由和原文引用才能关闭)。

这种设计让系统在处理海量数据时,只有少量的 State 和 Identity 边处于激活状态,极大地降低了计算开销。

另外它还引入了“认识论节点 (Epistemic Nodes)”来处理信息差,尝试记录不同角色对同一个事实的不同认知,这在处理复杂叙事时比传统的三元组要高级得多。

虽然这种方案部署成本高,但对于需要极高事实准确度的长文本分析场景,这种“本体扫描 + 时间快照”的实战路径比单纯堆 Context Window 要可靠得多。

大模型LLM

全部回复 (3)

小阿伟的日常 初级 11小时前
之前试过用Neo4j存实体关系,确实比纯向量检索好查。
0 回复
副业中测试 中级 11小时前
这玩意儿能处理那种反转极大的剧情吗?怕是快照得乱套。
0 回复
阿小美 中级 11小时前
我写长篇的时候也得手写大纲表,不然逻辑真的容易崩。
0 回复

发表回复

支持 Markdown 格式