知识图谱的时效性与向量索引的时效性具有不同的 SLA
向量索引即便有约 10% 的误差,也没人会惊慌。但知识图谱如果缺失了一条边,就可能导致有人向监管机构提交一份错误的答案。从数据工程组织的架构图来看,这两种故障模式如出一辙——都被归类为“索引陈旧”——并且它们共用同一个变更数据捕获(CDC)流水线,具有相同的延迟容忍度。流水线的规格是根据向量负载确定的,因为向量是更“大声”的消费者。图谱默默地继承了这些默认设置,而这种沉默本身就是 bug。
向量检索和图谱检索在数据陈旧时的失败表现截然不同。将它们视为同一种延迟问题,会导致你构建出的系统虽然在 RAG 基准测试中得分很高,但在多跳查询中却会产生隐蔽的错误——当然,这种“隐蔽错误”往往是用户最后才会察觉到的。解决方案不是更快的流水线,而是要认识到“陈旧”具有两种不同的含义,为每种边类别设计新鲜度分层,并在监管机构发现之前,通过评估机制捕捉到这种差异。
向量呈连续性退化 ,而图谱呈不连续性退化
向量索引是一种“软索引”。昨天生成的嵌入(embedding)和今天生成的嵌入在潜空间中通常指向几乎相同的方向。如果底层文档被轻微修改,新嵌入与查询的余弦相似度只会漂移几个百分点。检索到的文档仍然基本正确,模型生成的答案也基本正确。用户察觉不到任何异常。
这就是人们所说的“向量平滑降级”。其故障表面是平滑的:输入的微小变化只会导致检索排名的微小变化,进而导致答案质量的微小变化。你可以落后一天,有时甚至是一周,系统依然能保持在“近似正确”的吸引域内。这就是为什么许多团队可以心安理得地对百万量级的文档库执行每周一次的重新嵌入周期,并称之为“新鲜度策略”。
知识图谱则是一种“硬索引”。节点要么存在,要么不存在。边要么连接两个节点,要么不连接。一个跨越 客户 → 订阅 → 方案 → 地区 的多跳查询,要么找到路径,要么返回空结果。这里没有“近似正确”的路径。其故障表面是一个阶跃函数——缺失一条边就会让答案从“是”变成“否”,从“该客户处于欧盟管辖范围内”变成“未找到记录”。一个被删除的节点会导致所有经过它的查询默默返回空结果,而 LLM 随后会自信地描述为“不存在此类关系”。
这种不对称性会产生复合影响,因为 LLM 对待空图谱结果的方式与对待任何空检索结果一样——将其视为事实标准(ground truth)。向量路径至少能提供一个陈旧的文档供模型推理。而图谱路径返回空,模型就 假设什么都不存在,用户就会得到一段流畅的、断言否定事实的文字。陈旧的向量产生近似正确的答案,而陈旧的图谱产生自信的错误答案。这两者的 SLA(服务等级协议)完全不同。
流水线继承了错误的默认设置
大多数生产架构是通过堆叠演进的。向量检索最先上线,因为它更简单——分块、嵌入、更新、查询。CDC 流水线是围绕其需求构建的:几小时到一天的可接受延迟、批量重新嵌入、最终一致性。接着,有人为了多跳查询增加了图谱层,因为向量无法追踪复杂关系,而这一新层直接接入了现有的 CDC 流。相同的 Kafka 主题,相同的延迟 SLA,相同的监控。
在上线依赖图谱实时性的功能之前,这一切运行良好。比如市场团队推出了新的定价等级。由于下一批处理要等到 7 小时后,定价边需要 7 小时才能进入图谱。在这 7 小时内,每一个询问“德国企业客户有哪些方案可选”的查询都会返回旧结果。向量路径同样会返回旧的市场 PDF,但模型可以留有余地——“根据现有文档,方案为 X,但定价近期可能有更新”。而图谱路径返回一个确定性的列表,模型将其作为事实呈现。
这里的组织故障模式是结构性的。数据工程团队负责维护作为单元的“流水线”,AI 团队负责维护作为单元的“检索”。没有团队为向量新鲜度和图谱新鲜度之间的接缝命名,因此也就没有团队对其负责。当市场定价案例最终引发故障时,复盘报告会归咎于“数据陈旧”,并提议缩短所有人的延迟—— 这既昂贵又是错误的,因为并不是每一条边都需要亚秒级的新鲜度。
按边类别划分的新鲜度层级
第一步是停止将图谱视为整体陈旧的对象。边的关键程度各不相同,正确的 SLA 取决于边所代表的内容:
- 存在边 (Existence edges) —— 该实体是否存在、该客户是否已订阅、该员工是否有权访问。这些边会直接导致答案从“是”变为“否”,不存在平滑降级。目标 SLA:秒级至分钟级。在这些边上,双时态模型(bitemporal models)能体现其价值——同时记录生效时间(事实在现实世界中生效的时间)和事务时间(系统获知该事实的时间),这样在任何时间点的查询都可以问:“在当时,我们认为什么是真实的?”
- 描述边 (Descriptive edges) —— 该实体的名称、地址、当前价格、当前负责人是什么。陈旧的值会产生错误但可补救的答案。用户会发现“联系人应该是 Jane 而不是 John”,但他们会将其视为可修正的错误,而非隐蔽的故障。目标 SLA:分钟级至小时级。
- 派生分析边 (Derived analytics edges) —— 聚合计数、计算得分、物化的汇总数据。陈旧的值会导致仪表盘或解释性文字中的数字略有偏差。目标 SLA:小时级至天级。
在架构上,这意味着 CDC 流水线至少需要两条“车道”。快车道以严苛的 SLA 处理存在边的变更,理想情况下是近乎实时的流处理,而非批量 ETL。慢车道处理描述边和分析边,为了节省成本进行强力批 处理。向量重索引通常属于慢车道——嵌入的变动极少会导致答案从“是”反转为“否”。
大多数团队拒绝这样做,是因为它会让流水线的运维复杂度增加两倍。他们的想法没错。但权衡之处在于,你用流水线的复杂度换取了在核心查询上的可衡量正确性。只有当陈旧性成为一个可衡量的业务问题时——例如错误的访问决策、错误的管辖区路由、错误的监管披露——你才需要致力于这种双流水线架构。在此之前,你可以用单一流水线和更严苛的全局 SLA 来掩盖问题,但你将为此付出代价:重新嵌入的成本将随着语料库中最大的数据块同步增长。
揭示图谱谎言的评估方法
大多数 RAG 评估套件都根据答案字符串进行评分。它们会问:模型返回的文本是否在语义上与标准答案匹配?这对向量(vectors)有效,因为向量的失败模式通常是答案产生偏移,而不是完全缺失。但这对于图(graphs)并不奏效,因为图的失败模式是“无结果,模型根据上下文编造了一个看似合理的答案”——而一个听起来合理的编造,其语义往往足以匹配标准答案并经常通过评估阈值。
针对图数据过时性的评估准则应当是结构性的,而非词法性的。它需要三个组成部分:
首先,一个模拟受控缺失边的基准测试。近期研究界在拓扑不完整性(topological incompleteness)基准测试上的努力,构建了在测试快照中刻意缺失某些边的查询,然后衡量系统是标记了不确定性,还是生成了一个答案。TI 风格的基准测试迫使我们面对一个 问题:当图不完整时,模型是会说“我没有足够的信息”,还是会给出一个流利但错误的答案?
其次,基于快照的回归测试。获取一个已知的正确图状态,再获取一个刻意过时的状态(例如,比实时 CDC 滞后 24 小时),针对两者运行相同的多跳查询,并断言系统要么返回相同的答案,要么显露其过时性。如果两个快照都产生了相同的流利答案,说明你的系统完全没有感知过时性的信号——它是开环的。
第三,拒绝校准(Refusal calibration)。你需要的指标是:在图缺失相关子图的情况下,模型拒绝回答或采取模糊措辞的频率(前提是人类也会认为该查询无法回答)。这是“不可回答、不可作弊、多跳”类型的评估——测试框架必须奖励那些在图确实不知情时说“我不知道”的行为。大多数现成的 RAG 评估根本不对拒绝回答进行评分,这就是为什么图数据过时导致的回归问题在发布时往往难以被察觉。
相关工具链仍显粗糙。Agent 记忆社区中的双时态图存储(bitemporal graph stores)方法正在接近原生支持——它们记录每条边的生效时间(valid-time)和交易时间(transaction-time),这意味着任何历史时间点的查询都是可重现的,且过时快照可以作为一等公民对象进行查询。如果没有这一点,你最终只能通过 CDC 日志重建快照,评估成本将变得难以承受。
组织是如何陷入失败的
预测你的团队是否会交付一个面向监管机构的错误答案,一个有效的方法是观察以下三个结构性问题:
- 谁负责 决定每个边类别的新鲜度层级(freshness-tier)? 如果答案是“流水线团队”或“AI 团队”,那么实际上无人负责——流水线团队将边视为行,而 AI 团队将检索视为黑盒。负责人必须是理解哪些查询依赖于边的存在性并据此路由 SLA 的人。
- 评估套件是否区分了“尽管检索正确但模型仍产生幻觉”与“因为检索结果为空而导致模型编造”? 如果评估套件只对答案字符串评分而不考虑检索状态,那么这两种失败模式会被归结为一个准确率数值,图数据的回归问题就会被掩盖在底噪之下。
- 评估中是否有强制拒绝(forced refusal)类别? 如果每个测试都期望得到肯定的答案,那么那个永远给出回答的模型会在评估中胜出,但在实际生产环境中那些不可回答的流量面前败北。拒绝覆盖率(Refusal coverage)就是系统的金丝雀。
当这三者都处于无人负责的状态时,系统会悄无声息地进入失败状态。评估分数保持平稳,客户投诉呈长尾分布——每天一个错误答案,难以归因,很容易被斥为“模型幻觉”。只有当有人将特定的错误答案追溯到特定的缺失边以及特定的延迟时,这种模式才会变得可见,而到那时,系统可能已经错误运行了一个季度。
将图视为不同的系统
在架构上需要内化的认知是:知识图谱不是“另一个检索索引”。它是一个具有不同失败语义、不同新鲜度要求以及与模型不确定性具有不同关系的系统。向量存储是语义的软缓存(soft cache)。而图则是对 现实的硬性断言(hard claim)。如果流水线和 SLA 将它们等同视之,那么其中一个必然运行在错误的容错度下——通常是图,因为向量工作负载主导了最初的设计,而当图出现时,没有人重新进行协商。
这种准则的实践版本是:对你的边进行分类,按类别拆分 CDC 通道,构建具备拒绝感知的评估体系(评分标准基于结构正确性而非词法匹配),并指定一名负责人专门负责“这种边类别的新鲜度容忍度是多少”这一问题。最后一点是这四项中最廉价的,也是大多数团队最容易忽略的。而忽略它的代价,则体现在那些无人察觉的错误答案中。
- https://ragaboutit.com/the-silent-failure-loop-why-real-time-knowledge-graphs-are-your-only-defense-against-production-rag-degradation/
- https://atlan.com/know/vector-database-vs-knowledge-graph-agent-memory/
- https://ragaboutit.com/the-knowledge-decay-problem-how-to-build-rag-systems-that-stay-fresh-at-scale/
- https://glenrhodes.com/data-freshness-rot-as-the-silent-failure-mode-in-production-rag-systems-and-treating-document-shelf-life-as-a-first-class-reliability-concern-3/
- https://medium.com/@eyosiasteshale/the-refresh-trap-the-hidden-economics-of-vector-decay-in-rag-systems-f73bc15aa011
- https://redis.io/blog/rag-at-scale/
- https://medium.com/@claudiubranzan/from-llms-to-knowledge-graphs-building-production-ready-graph-systems-in-2025-2b4aff1ec99a
- https://datanucleus.dev/rag-and-agentic-ai/what-is-rag-enterprise-guide-2025
- https://arxiv.org/html/2510.02827v1
- https://www.ijraset.com/research-paper/query-time-knowledge-graph-synthesis-for-multi-hop-rag
- https://arxiv.org/html/2510.11956v1
- https://arxiv.org/abs/2502.12442
- https://neo4j.com/blog/developer/change-data-capture-cdc-ga/
- https://www.mdpi.com/2227-7390/13/13/2109
- https://link.springer.com/chapter/10.1007/978-3-032-05281-0_15
- https://github.com/getzep/graphiti
- https://www.freecodecamp.org/news/how-to-solve-5-common-rag-failures-with-knowledge-graphs/
