如果一个知识库昨天还在告诉你“某个接口会返回某个字段”今天上游系统悄悄把这个字段下掉了知识库会怎样对大部分系统来说它不会有任何反应。它依然保存着那条知识依然能被检索到依然会被下游服务消费直到线上报错、用户投诉或者人工排查时大家才猛然想起来这条旧知识早就该失效了。所以我们经常看到一句有些“反直觉”的项目描述A knowledge base that notices when it stops being true——一个会察觉自己“不再为真”的知识库。这个描述的后半句才是真正的价值点。它不是要你去堆更多知识也不是再做一个更快更全的检索库。它想解决一个被整个知识工程行业长期搁置的问题知识库能不能知道自己保存的内容已经失去依据能不能自动通知所有信任这条知识的下游结论这篇文章没有在复述某个现成产品的说明书。它会先拆解“知识何时会失真”这个问题再讲清楚知识工程领域里一个被低估的老概念Truth Maintenance System真值维护系统。最后我会用一个不需要任何第三方依赖的 Python 最小实现演示“知识在失去证据后如何自动标记为待失效并沿着依赖链传播”。如果你正在做 RAG、规则引擎、Agent 记忆、数据血缘或者各类文档型知识库这篇文章值得读完。1. 知识库不是死于内存而是死于“悄悄变错”先看一个很常见的工程场景。你维护了一个 API 知识库里面记录了某个内部服务的接口字段。最初信息来源是官方文档 v1你后来还加了一条生产环境的真实探测记录。基于这两条证据系统推导出一个结论登录成功后一定返回refresh_token。下游客户端基于这个结论实现了静默续期逻辑。某个周一服务端升级文档 v1 下线新的文档 v2 里不再保证refresh_token返回。你的知识库里发生了什么什么都没发生。老的文档摘录还在那条“一定返回 refresh_token”的结论还在下游继续按老规则运行。没有新增知识没有语法错误没有缓存超时只有知识的“证据基础”被悄悄抽掉了。这类问题往往比宕机更隐蔽。宕机有告警而“已经失效但看起来一切正常”的知识不会自己举手。等它被发现通常已经是业务事故之后。如果只是偶尔一条知识过时人工处理一下也还好。问题是现代系统里的知识数量早就超过了人工维护的极限。哪怕每天只有 0.5% 的知识因为上游 schema 变更、文档更新、策略调整而过时一万条知识里就有五十条处于“错误但未被发现”的状态。这里面真正值得思考的不是“定时刷新”而是另一个维度一条知识是否仍然为真不应该只看它保存了多久而应该看它背后的支持来源是否仍然成立。这个判断才是 Truth Maintenance System 的核心出发点。2. 从“存储知识”到“维护支持关系”2.1 什么是 Truth Maintenance SystemTruth Maintenance System简称 TMS通常翻译为“真值维护系统”。它不是一个新东西。1979 年Jon Doyle 发表了一篇经典论文《A Truth Maintenance System》之后 Johan de Kleer 又提出了基于假设的 ATMSAssumption-based Truth Maintenance System。在人工智能早期TMS 主要服务于专家系统、定理证明器、规划系统和诊断系统。它的设计目标非常明确知识系统不能只保存“结论”还要保存“结论为什么成立”。当底层事实发生变化时系统要及时找出所有受影响的结论并把它们标记为不再可信。TMS 和普通数据库的一个本质区别是它不再把每条知识看成孤立的记录而是把它们组织成一张支持关系网。每条推导出来的结论都绑定着它依赖的前提。举个例子前提 A官方文档说明登录接口返回refresh_token前提 B生产环境探测确认登录接口返回refresh_token结论 C客户端可以依赖refresh_token做静默续期C 的支持关系是 A 和 B。当 A 失效时C 虽然不会被系统自动“证明为假”但它会立刻从“可信”变成“不可信”。TMS 最反直觉的地方也在这里它不是删除一条知识而是把知识的状态改为“失去支持”。2.2 为什么不是直接删除很多第一次接触 TMS 的人会问既然前提没了为什么不把结论一起删掉原因有三个。第一原始数据仍然有审计价值。我们需要知道这条知识曾经为什么成立、它失效的触发点是什么直接删除会让事后排查失去关键线索。第二要区分“不知道”和“知道是假”。当你删掉结论时知识库变成了“不知道”。但你真正应该让下游知道的往往是“这条结论不再可信别用了”。两者含义不同对下游系统的行为影响也不同。第三有些知识可能存在于多条支持链上。一条证据失效可能只是让某个结论的可信度降低但不是完全摧毁它。如果直接删除你就丢掉了重新组合证据恢复结论的可能性。所以TMS 通常不会直接给知识打上“false”墓碑而是给出一个更细的状态。2.3 知识的几种关键状态一个带真值维护能力的知识库至少应该区分这几种状态而不是只有“真”和“假”状态含义对下游的提示supported有足够证据支持目前可信可以正常使用unsupported曾经可信但支持证据已失效不要作为确定结论使用需要重新验证unknown没有足够信息判断真假不能作为推理依据contradicted同时存在支持为真和支持为假的证据触发冲突消解流程很多系统做不到这一点是因为它们把知识库当成了“静态数据库”只关心写入和读取。而 TMS 的视角是知识库是一个持续运行、依赖不断变化的推理结构维护者。2.4 从微观看宏观一条结论失效后的传播TMS 并不只是处理“第一条结论”的失效。因为知识之间常常会再次组合。结论 C 可能成了结论 D 的支持前提D 又支持 E。所以当底层证据 A 失效时影响不是单点的而是一条传播链。这个传播过程很像数据库里的级联操作但比级联删除更温和它把每一个被波及的节点从“supported”降级为“unsupported”。理解了这一点就可以理解为什么这条路线很适合现代 RAG 和 Agent 场景。现在的 RAG 系统最头疼的问题之一就是“检索到的内容可能是过时的”而且系统无法感知。Truth maintenance 给出的思考方式是把向量库里的每个 chunk 看成“结论”把来源 URL、文档版本号、schema 结构看成“证据”。当这些证据失稳对应 chunk 的可信度应该在索引层面立刻变化而不是等到检索之后再判断。3. 设计一个“会感知失效”的最小知识库在写代码之前我们先厘清数据模型。一个支持“知识失效感知”的知识库不应该只有“知识条目”这一种实体。最少应该拆成三类Evidence证据。来自外部世界的原始事实例如一次接口探测、一个官方文档快照。DerivedStatement推导结论。由一条或多条证据推导出来的知识。Justification支持关系。描述一个结论依赖了哪些证据或结论。在这个模型里一条知识之所以可信不是因为它“被写进了数据库”而是因为它的 justification 仍然成立。3.1 一个可供参考的 JSON 数据模型假设我们要维护一条关于“登录接口返回refresh_token”的知识它在知识库里大概长这样{ knowledge_id: stmt.login_returns_token, type: derived_statement, content: demo-api 的 /login 接口在成功时返回 refresh_token, state: supported, policy: all, justifications: [ { node_id: evidence.docs_v1, node_type: evidence, note: demo-api 官方文档 v1 截图 }, { node_id: evidence.probe_2025_01, node_type: evidence, note: 2025-01 生产环境真实探测结果 } ] }policy 字段用来表示支持策略all所有支持证据都有效结论才有效。any只要有一条支持证据有效结论就继续有效适合多源冗余校验场景。对 evidence 来说最简单的判断是维护一个布尔字段valid。但更真实的系统里证据通常不是永远有效或永远无效的它可能带一个验证周期或者绑定一个外部校验函数。4. Python 实现一个迷你 TMS为了说清楚“失效传播”到底是怎么发生的我们一起来写一个最小可运行的 Python 版本。它不依赖任何第三方库核心思想只有三件事保存证据和结论。保存结论与证据之间的依赖关系。当一个证据失效时重新评估所有下游节点把不再被支持的结论标记为unsupported。这个实现无法覆盖完整 TMS 的所有能力比如矛盾冲突消解和假设集合管理。但它足够说明关键机制。4.1 核心文件mini_tms.py把下面的代码保存为mini_tms.py。from collections import defaultdict class MiniTruthMaintenance: def __init__(self): self.nodes {} self.justifications {} self.dependents defaultdict(set) def add_evidence(self, node_id, content, validTrue): if node_id in self.nodes: raise KeyError(fnode {node_id} already exists) self.nodes[node_id] { type: evidence, content: content, valid: valid } def add_statement(self, node_id, content, justifications, policyall): if node_id in self.nodes: raise KeyError(fnode {node_id} already exists) if len(justifications) 0: raise ValueError(statement must have at least one justification) for premise_id in justifications: if premise_id not in self.nodes: raise KeyError(fjustification node {premise_id} not found) self.nodes[node_id] { type: statement, content: content, state: supported } self.justifications[node_id] { justifications: list(justifications), policy: policy } for premise_id in justifications: self.dependents[premise_id].add(node_id) def set_evidence_valid(self, evidence_id, valid): node self.nodes.get(evidence_id) if node is None: raise KeyError(fnode {evidence_id} not found) if node[type] ! evidence: raise TypeError(fnode {evidence_id} is not evidence) if node[valid] valid: return node[valid] valid self.propagate(evidence_id) def _premise_holds(self, premise_id): node self.nodes.get(premise_id) if node is None: return False if node[type] evidence: return bool(node[valid]) return node[state] supported def _evaluate(self, justifications, policy): values [self._premise_holds(p) for p in justifications] if policy all: return all(values) if policy any: return any(values) raise ValueError(funknown policy: {policy}) def _recompute(self, statement_id): node self.nodes.get(statement_id) if node is None or node[type] ! statement: return ji self.justifications[statement_id] node[state] ( supported if self._evaluate(ji[justifications], ji[policy]) else unsupported ) def propagate(self, changed_node_id): visited set() stack list(self.dependents.get(changed_node_id, set())) while stack: node_id stack.pop() if node_id in visited: continue visited.add(node_id) self._recompute(node_id) for child_id in self.dependents.get(node_id, set()): if child_id not in visited: stack.append(child_id) def snapshot(self): lines [] for node_id, node in self.nodes.items(): if node[type] evidence: state valid if node[valid] else invalid else: state node[state] lines.append( fnode{node_id} type{node[type]} state{state} content{node[content]} ) return \n.join(sorted(lines))这个类有几个关键设计点dependents记录了每个节点“被谁依赖”它是失效传播的反向索引。当某个证据变化时程序能快速找到所有依赖它的结论。add_statement要求所有前提已经存在。这样在加入结论时不需要立刻做全量重算默认状态是supported但真正状态会在后续失效传播中被修正。set_evidence_valid是外部世界影响知识库的入口。它可以表示“文档版本下线”“探测结果不再有效”等事件。propagate使用栈做深度遍历避免重复访问。这个版本没有处理环路但visited集合能防止简单成环时无限循环只是不会给出冲突提示。4.2 编写测试脚本接下来写一个测试用例演示“一条证据失效两条下游结论自动进入 unsupported 状态”。# 文件路径test_mini_tms.py from mini_tms import MiniTruthMaintenance def main(): kb MiniTruthMaintenance() kb.add_evidence( evidence.docs_v1, demo-api 官方文档 v1/login 返回 refresh_token ) kb.add_evidence( evidence.probe_2025_01, 2025-01 生产探测/login 返回 refresh_token ) kb.add_statement( stmt.login_returns_token, 结论/login 接口成功时返回 refresh_token, justifications[evidence.docs_v1, evidence.probe_2025_01], policyall ) kb.add_statement( stmt.silent_renew_available, 结论客户端可以依赖 refresh_token 做静默续期, justifications[stmt.login_returns_token], policyall ) print( 初始状态 ) print(kb.snapshot()) kb.set_evidence_valid(evidence.docs_v1, False) print() print( evidence.docs_v1 失效后 ) print(kb.snapshot()) if __name__ __main__: main()运行方式很简单python test_mini_tms.py预期会看到类似下面的输出 初始状态 nodeevidence.docs_v1 typeevidence statevalid contentdemo-api 官方文档 v1/login 返回 refresh_token nodeevidence.probe_2025_01 typeevidence statevalid content2025-01 生产探测/login 返回 refresh_token nodestmt.login_returns_token typestatement statesupport content结论/login 接口成功时返回 refresh_token nodestmt.silent_renew_available typestatement statesupport content结论客户端可以依赖 refresh_token 做静默续期 evidence.docs_v1 失效后 nodeevidence.docs_v1 typeevidence stateinvalid contentdemo-api 官方文档 v1/login 返回 refresh_token nodeevidence.probe_2025_01 typeevidence statevalid content2025-01 生产探测/login 返回 refresh_token nodestmt.login_returns_token typestatement stateunsupported content结论/login 接口成功时返回 refresh_token nodestmt.silent_renew_available typestatement stateunsupported content结论客户端可以依赖 refresh_token 做静默续期注意输出的关键变化原始的文档证据失效后不仅“登录接口返回 refresh_token”这条直接结论从 supported 变成了 unsupported连“客户端可以做静默续期”这条间接结论也自动变成了 unsupported。这就是依赖链传播。如果知识库只有“真”和“假”两个状态这次传播就会变得很难表达系统无法区分“被证明为假”和“曾经可信但现在失去依据”。多一个unsupported状态下游系统就能明确知道自己面对的是“待重新验证的知识”而不是一条永远不能使用的知识。5. 在 RAG / Agent 场景里这个思路还能怎么用很多人会觉得TMS 是上个世纪专家系统的概念和今天的 AI 应用关系不大。但恰恰相反TMS 的思想在今天 RAG 和 Agent 流行之后又有了新的落点。5.1 静态向量索引起码该加一个“证据层”现在的 RAG 系统通常会做这样一件事把文档切开、向量化、存入向量库。检索时把问题向量和文档向量做相似度计算取出 top_K拼进 prompt。这个流程最大的问题是什么是文档一旦写入索引就没有任何机制提醒系统“它已经过期了”。向量之间没有因果和依赖关系文档是否仍然与外部世界一致完全不在索引考虑范围内。如果我们把 TMS 的思想搬过来至少应该为每个 chunk 增加一个轻量元数据模型。比如{ chunk_id: rag_doc_api_login_001, content: /login 接口成功时返回 refresh_token, source_type: openapi_spec, evidence_id: evidence.openapi_spec_v2025_01, source_url: https://example.demo/openapi.json, version_pin: 2025-01-15, last_verified_at: 2025-01-15T10:00:00Z, verifier: openapi_spec_diff }这样RAG 就不只是一个“文本检索器”而是一个“带证据可审计性的知识库”。每次召回这个 chunk 之前可以先看它的evidence_id是否仍然有效。如果证据已经失效系统可以选择不返回该 chunk或者返回时附带一条警告该知识的上游版本已经变化需要重新验证。5.2 用事件驱动代替笨重的定时全量刷新很多团队维护知识文档时常做“每周全量重新抓取一次”。全量刷新简单但成本高、实时性差而且大量未变化的内容会产生不必要的计算开销。更符合 TMS 思路的做法是事件驱动。以 API 知识库为例当上游发布新的 OpenAPI 描述文件时可以触发一个事件。事件处理逻辑里包含三步def on_source_changed(evidence_id, current_source_digest): # 1. 比较当前 source digest 与知识库中记录的 digest # 2. 如果不一致将对应 evidence 标记为 invalid # 3. 让 TMS 自动传播失效状态 if not is_same_source(evidence_id, current_source_digest): kb.set_evidence_valid(evidence_id, False) affected collect_affected_statements(evidence_id) notify_downstream(affected)这里的关键是把“我更新了这篇文档”翻译成知识库能理解的内部事件某条证据失效了。失效传播之后所有依赖这条证据的结论都会被重新计算。这比“每天凌晨全量重算一次”要精确得多也能让知识库在下一次查询之前就完成状态更新。5.3 Agent 工具调用后的结论也需要保留证据链再举一个 Agent 场景的例子。Agent 调用一个数据库查询工具拿到指标 X 为 100然后基于这个数值生成了一份报表。如果数据库口径调整指标 X 的定义发生变化历史上所有基于旧口径生成的结论都应当重新审查。但如果没有记录“结论依赖了哪种口径的查询”Agent 根本不知道哪些历史结论需要重算。沿着 TMS 的思路答案是给每次工具调用生成的结论带上依赖记录。让结论和工具、参数、返回快照、版本号之间形成一条可以追踪的支持关系。当工具版本变化或者底层 schema 变化系统能主动识别出“哪些历史结论现在失去了支持基础”。这本质上是把现代数据工程里的“数据血缘”概念从表级血缘推进到了语义级。不是只知道“这张表依赖那张表”而是知道“这条结论命题依赖于哪些证据命题”并且能在证据失效时自动更新整个知识状态。6. 常见问题与排查6.1 常见问题速查问题现象可能原因排查方式解决方案证据失效后下游结论没变化结论没有注册 justification检查justifications是否完整证据节点的dependents是否包含目标结论补充支持关系必要时重建注册信息同一份知识多个状态同时出现policy 配置混乱检查每条结论声明的all或any策略统一规则权威文档多源时用any关键决定依赖全部条件时用all结论被标为 unsupported但实际还可用旧证据被误标记失效查看失效事件来源、变更原因重新上线证据版本或补充新证据更新证据后知识状态没有被恢复缺少反向“重新支持”入口检查是否存在从失效节点分发新的支持路径调用set_evidence_valid(evidence_id, True)或加入新的证据知识量增大后失效传播变慢依赖图过大且反向索引不全分析dependents索引、是否有大量无效扫描增加传播队列、按领域分片、改异步传播系统出现循环支持但没有提示数据建模时引入了间接环检查所有justifications的拓扑关系加入环路检测在创建支持关系时拒绝成环6.2 一个必须提前想清楚的坑TMS 的最大坑不是代码本身而是证据模型的设计。很多团队把“一篇文档”当证据但文档本身会频繁改动。如果每次改动都把证据置为失效会导致下游大量结论抖动如果不置为失效又无法感知变化。更稳妥的做法是给证据加一个可比较的“指纹”字段比如接口 schema 的 hash、文档版本的 commit id、数据库结构的 digest。只有当指纹改变时才真正触发失效传播。知识维护的难点是判断“它是否变了”而不是“它现在是不是还活着”。7. 工程落地建议如果要把这套思路用到真实项目里我建议按下面的顺序推进。7.1 先做证据注册表而不是一上来做推理引擎给当前知识库里每一条比较重要的知识补一个evidence_id、source_type、verified_at字段。先让系统知道自己有哪些知识、知识的来源是什么。这一步不需要复杂的推理传播但价值很大。7.2 把状态从二值扩展为多值先不要一直用“有效/无效”来管理全部知识。至少要分出已验证待验证已失效冲突中这样知识库里的数据就能被下游准确使用。查询接口能返回“这条内容可信度受到影响的”提示而不是把一个失效内容当成普通结果返回。7.3 为每条关键知识设置校验器校验器不必很复杂。可以是一个定时任务的 HTTP Head 请求可以是一次 SQL 探测也可以是读取某份文件的 hash。def default_verifier(source_url, current_digest): # 伪代码根据 source 类型选择验证方式 # 返回 True 表示校验通过返回 False 表示证据失效 if source_url.startswith(openapi:): digest fetch_openapi_digest(source_url) return digest current_digest if source_url.startswith(schema:): digest fetch_schema_digest(source_url) return digest current_digest return False校验器的作用是把外部世界的“是否存在”转变成知识库里的“是否仍然成立”。这是证据模型和外部系统的接口也是整个知识保鲜机制最容易自动化的一层。7.4 最小权限变更先跑在测试域如果你要在一个生产知识库中加入失效传播机制不要让一条证据的失效直接触发线上重大动作。先把受影响范围打印出来人工或自动审核一批确认没问题后再接业务告警和自动降级。任何自动失效机制在生产环境中的动作都要有可解释的审计日志和可回滚入口。7.5 给下游暴露“影响范围”接口当一条证据失效时最有用的不是只更新内部状态而是提供出一个影响清单哪几条结论受影响、哪几个下游接口会吃到这些结论、是否需要重新验证。这个能力也可以做成一个简单的内部 APIdef affected_statements(evidence_id): visited set() stack list(kb.dependents.get(evidence_id, set())) while stack: node_id stack.pop() if node_id in visited: continue visited.add(node_id) stack.extend(kb.dependents.get(node_id, set())) return sorted(visited)这样系统管理人员和上层 Agent 都能知道——如果数据库 schema 变了受影响的不只是一张表还有所有基于旧 schema 形成的历史结论。8. 总结与延伸方向“A knowledge base that notices when it stops being true”这句话真正传递的是一个看起来朴素、做起来很难的系统能力让知识库像维护数据一致性一样维护语义一致性。它背后的老概念是 Truth Maintenance System。它的关键不在于“删除错误知识”而在于给每条知识保存一条“支持链”并在支持链断裂时把知识从可信状态自动切换到不可信状态再沿着依赖图传播出去。直观理解它给知识库增加的不是搜索能力而是一种“语义级的外键约束”。如果你正在做 RAG可以先为文档块增加来源和校验器如果你在做 Agent可以先为工具调用结果记录依赖关系如果你在维护规则引擎或知识中台可以尝试引入一个最小 TMS 状态层先让“失效”成为一个系统事件而不是一次口头通知。下一步值得深入的方向是 ATMS 和假设维护。完整 TMS 不仅能处理“证据失效”还能在多个假设之间做冲突消解记录每个结论当前依赖的假设集合并识别“在假设 A、B 下成立但在假设 C 下不成立”的知识。到了这一步知识库的主动性会再上一个台阶。希望这篇文章能给你一个足够清晰的最小起点。