知识图谱实时性怎么保证?

这道题其实问的是，当[[知识图谱]]和 [[RAG]] 结合时，怎么平衡数据的实时性和系统的稳定性。我的核心思路是分层解耦加增量流水线，而不是搞一个万能方案。

先说分层。我会把知识图谱里的数据按变化速度分成三层。第一层是本体层，就是知识图谱的骨架，比如实体类型、关系定义，这个很稳定，人工维护，季度更新一次就够了。第二层是实体关系层，比如商家信息、商品目录，变化慢但会变，我一般做小时级或者 T+1 的增量更新。第三层是动态事实层，比如实时路况、库存状态、优惠券是否被领完，这种变化快，需要分钟级甚至秒级的流式更新。

这里有个边界划分：不是所有数据都需要实时。实时性是有成本的，对用户决策关键路径上的数据，比如导航终点是否存在、这个订单能不能退款，我会走实时通道；但背景知识，比如商家历史评价、商品详情，准实时就够了。落地时往往是混合方案。

具体到增量更新，我会用 CDC 或者消息队列捕获变更源，然后跑图差分算法，只重建受影响的最小子图，而不是全量重建。向量索引那块，我倾向于用增量 [[HNSW]] 或者分片索引，支持单点更新，避免整个索引重建。

举个例子，在物流配送场景里，配送员的实时位置和路况属于动态事实层，我可能会用 Redis 做热缓存，延迟控制在 100 毫秒以内，然后异步回写到图谱里；而商家的营业时间、联系方式属于实体关系层，用 Flink 流处理，分钟级合并写入。这样既保证了核心查询的实时性，又不会让系统被高频写入压垮。

再说落地风险。完全实时几乎不可能，必须接受最终一致性。我会给每个子图带一个版本号，查询时可以指定时间快照，这样即使短暂不一致，也能保证写入顺序和冲突可溯源。另外，[[智能体]]侧也要适配：召回时优先返回带最新时间戳的结果；如果检测到数据版本冲突，就降低那条路径的推理权重；关键事实还可以主动调实时 API 交叉验证。

还有一个点我特别想提，就是一致性兜底。当高频写入和查询并发时，如果强制要求强一致，查询延迟会飙升。我会在架构上做取舍：对用户决策关键路径，比如“这个门店是否还在营业”，走实时通道；对背景知识，比如门店历史评分，走准实时。上线前我会用一批固定 query 回放，对比召回率和延迟，通过才原子切换，不通过就回滚。

所以整体上，我更倾向把实时性看作一个分层问题，而不是一个技术问题。关键路径用热缓存加异步写，非关键路径用批处理，中间靠版本号和一致性协议兜底。