知识图谱怎么动态更新?

这道题其实是在问，[[Agent]]系统怎么让[[知识图谱]]跟得上外部世界的变化。我理解，本质上就是Agent感知外部世界的能力，既要准又要快。

先说最常见的更新机制。先看增量抽取，说白了就是只抓变化的部分，别每次都重建整个图谱。实现上，对结构化数据可以用 CDC 工具，比如监听数据库的 binlog，像 Debezium 就能干这个；对非结构化数据，比如文档，就用[[滑动窗口]]比对 [[Embedding]] 差异。接着说事件触发，用消息队列加流处理引擎，比如 Kafka 配 Flink。典型事件包括文档上传、人工修正、或者 LLM 抽取结果的置信度低于某个阈值，这时候就触发更新。再补充版本管理，就是给每条三元组打个版本号，查询时可以指定版本或者默认取最新。这样能支持回滚，比如做 A/B 测试时，对比新旧版本的效果。

这里有个边界划分的问题。增量抽取适合数据源稳定、变更频繁的场景，比如电商的库存价格，每秒钟都在变；事件触发适合突发性、不可预测的变更，比如客服系统里用户上传了一个退款截图，需要立即更新图谱；版本管理则适合需要审计或实验的场景，比如金融风控，需要追溯历史。但真正落地时，往往不是只用一种，而是增量抽取加事件触发混着用。举个例子，在客服退款场景里，一个用户发起退款申请，事件触发机制会立刻把这条工单数据推送到图谱，同时增量抽取模块定期同步后台订单系统的状态变更，两者配合，既保证实时响应，又不漏掉批量变更。

不过，动态更新最大的挑战是实时性和一致性之间的取舍。实时性要求高，一致性就容易出问题。比如分布式环境下，两个节点同时更新同一个实体的属性，就可能产生冲突。常见的做法是用向量时钟或 Lamport 时钟来确定先后顺序，实在解决不了就丢人工审核。还有一个坑是语义漂移，比如“苹果”这个实体，以前指水果，现在可能指公司，实体消歧模块得检测到这种变化，然后触发子图重链接。另外，事务边界也是个问题，图数据库像 Neo4j 或者 Nebula 有 ACID 保证，但分布式场景下，两阶段提交会阻塞查询，所以生产环境我通常采用最终一致性加冲突可读的策略，让 Agent 知道数据可能过期，然后自己决定怎么处理。

这里有个延伸的点，就是当图谱更新频率非常高时，比如每秒上千次变更，版本管理的快照隔离会带来很大的存储开销。这时候我会考虑用事件溯源或者 CQRS 模式，把写操作和读操作彻底分离。

所以，我的整体看法是，，核心是根据业务场景在实时性和一致性之间做取舍。我更倾向先保证可用性，再通过补偿机制兜底，而不是一开始就追求强一致性。