发布时间：2026-07-12
标签：AI Agent｜LLM｜RAG｜知识治理｜数据生命周期｜工程实践

---

系列导航

上一篇：AI Agent 工程实践（14）：MCP——为什么它正在成为 Agent 的 USB 接口？
下一篇： AI Agent 工程实践（16）：Agent 为什么需要状态（State）？

本文是 [AI Agent 工程实践] 系列的第 15 篇（第二季 · 工程实现）。

---

RAG 系统上线的头三个月，一切完美。检索准、回答好、团队觉得终于"AI 能用起来了"。

第四个月，用户开始反馈"答案过时了"——公司上个月把 API 从 v1 升到了 v2，但 RAG 还在引用 v1 的文档。更糟的是，旧文档没删，新旧混在一起，Agent 有时答 v1，有时答 v2，看运气。

我去查向量库——三个月塞了 8000 个 chunk，其中 2000 个已经过期，600 个和新文档直接冲突，根本分不清哪个是对的。

那一刻我才明白：RAG 真正的瓶颈不是检索不准，是知识本身在腐烂。 99% 的 RAG 教程在教"怎么调 chunk size"，但没人教"知识什么时候该删、什么时候该更新、什么时候已失效"。治理，才是 RAG 上生产后真正的第一关。

---

本文你将学到

✓ 为什么 RAG 的瓶颈不在检索——在知识治理
✓ 知识生命周期的完整链路：Document → Chunk → Metadata → Embedding → Retrieve → Evaluate
✓ 三个最关键的治理动作：删（什么时候删）/ 更（什么时候更新）/ 废（什么时候失效）
✓ 如何给知识打上"过期日期"和"冲突检测"

适合阅读

✓ 搭过 RAG、发现"越用越不准"的开发者
✓ 正在把 RAG 从 demo 推向生产的人
✓ 意识到"向量库不是 dump——存进去的知识需要管理"的人

---

问题背景

RAG 的教程 99% 在讲同一条路：文档 → chunk → embed → 存向量库 → 检索。这条"黄金流水线"被讲了无数遍。

但这条路只管"怎么进"，不管"怎么出"。一旦系统跑起来，真正棘手的问题全在"进"之后：

知识变旧了怎么发现？ API 文档升级了、公司政策改了、产品下线了——向量库里对应的 chunk 不会自动消失。

新旧冲突怎么裁决？ 同一问题的两个 chunk，一个来自去年的旧文档，一个来自上周的新文档，Agent 该信谁？

无效知识怎么清理？ 塞进去 8000 个 chunk，3000 个从来没被检索命中——它们只在占用存储和搜索时间，没有产生任何价值。

有人故意塞脏数据怎么办？ 如果 RAG 支持用户反馈或动态写入，投毒攻击会让模型引用伪造的"知识"。

一句话：把文档塞进向量库只是 RAG 的第 0 步。治理，才是第 1 步。 治理缺失的 RAG，不是知识库，是垃圾场——越用越脏。

---

错误尝试

第一次：只管入，不管出

上线时导入一批文档，再没管过。半年后文档过期了、冲突了、没人知道。

结果：Agent 的答案质量随时间单调下降——不是模型变差了，是它引用的知识在腐烂。没有出库策略的知识库，是有机垃圾堆。

第二次：人工定期清理

每季度派一个人"看看哪些文档该删"。人工判断+手动操作。

结果：第一季度的确清了。第二季度忙忘了。第四季度堆了更多。凡是靠人维护的生命周期，最终都不会发生——和第 04 篇 Review"顺便做"是同一个道理。

两次尝试指向同一个教训：知识治理不能靠"人定期看"，需要自动化的生命周期管理——每一份知识入库时就带上有效期、版本号、冲突检测规则。

---

关键观察

我把 RAG 系统里"出过错的答案"追溯了一遍，发现错误根因的分布和所有人想的不一样：

错误根因	占比	是否和"检索不准"有关
知识过期/冲突	~40%	否——知识本身错了
元数据缺失导致误召回	~25%	半相关
检索排序不准	~20%	是
Embedding 质量	~15%	是

RAG 真正的瓶颈不是检索不准，是知识本身在腐烂。

40% 的错误不是"没搜到"，是"搜到的本身就是错的"。优化 chunk size 和 embedding 模型解决不了这个问题——它需要的是知识治理。

定位真正原因

问题不在"检索技术不够好"，而在知识从入库那一刻起就没有被管理起来。它是死数据——没有版本、没有有效期、没有冲突检测、没有淘汰机制。

正确做法是给每一条知识打上生命周期标记，让它在整个链路里被追踪、被评估、被淘汰：

Document → Chunk → Metadata → Embedding → Retrieve → Evaluate →（回写更新/删除）

注意最后一步：Evaluate 不是终点，它回到 Document 层触发更新或删除。治理的关键是闭环，不是一次性的"塞进去"。

---

最终方案：知识生命周期治理

你给的六步链路

每一步的治理职责不同，漏掉任何一步就是漏洞：

步骤	治理动作
Document	入库时打上有效期、版本号、来源权威等级
Chunk	拆分时保留文档级元数据，chunk 可追溯到源头
Metadata	治理的核心阵地——存时间戳、版本、状态、来源、冲突标记
Embedding	向量化只是"翻译"，不参与治理决策
Retrieve	检索时过滤——只召回 status=active 且未过期的 chunk
Evaluate	闭环反馈——命中率低的降级、冲突的回溯源文档、过期的触发清理

三个最硬核的治理问题

1. 什么时候删？

时间触发：入库时设 expire_at，到期自动标记为 deprecated。不是硬删除（硬删不可逆），是软标记——先不参与检索，观察一周无投诉再真删。

冲突触发：新版本入库时，旧版本自动标记 superseded_by=new_id。同一问题的多个版本只保留最新，旧的进归档。

无用触发：180 天未被任何检索命中 → 降级标记 cold。再 90 天仍无命中 → deprecated。

2. 什么时候更新？

源文档变更：上游文档（Wiki/Confluence/Git）更新 → webhook 触发对应 chunk 重新 embed。

反馈触发：用户反馈"这个答案过时了" → 人工确认后标记对应 chunk needs_update → 回源头取最新版本。

冲突裁决：检索时发现多个 chunk 回答同一问题但内容矛盾 → 触发冲突告警 → 按 version + source_authority 裁决，保留最新/最权威的，其余标记 deprecated。

3. 什么时候失效？

失效条件	触发方式	处理
expire_at 到期	自动	status → deprecated
源文档被删除	webhook 同步	对应 chunk 全部标记 orphaned
源文档标记"已废弃"	人工或 API	status → deprecated_with_notice
连续 N 次检索命中但用户反馈"不正确"	Evaluate 闭环	status → under_review

实际收益

指标	无治理	有生命周期治理
知识过期导致的错误率	~40%	大幅下降
向量库膨胀速度	线性增长	受控（自动清理）
新旧冲突	常见（人工处理）	自动裁决
运营维护成本	高（人定期清）	低（自动化）

---

架构图 / 流程图

知识生命周期的完整闭环

关键点：Metadata 是治理的中枢——所有生命周期状态的变更都在这里记录。Evaluate 是闭环的闸门——它把 RAG 从"一次性灌入"变成"持续维护的系统"。

一个 chunk 的一生

---

代码或配置示例

带生命周期的 Document 元数据

# knowledge/metadata/doc_20260712.yaml
doc_id: "api-v2-reference"
version: 2
supersedes: ["api-v1-reference"]    # 取代了哪个旧版本
source_url: "https://docs.company.com/api/v2"
source_authority: high               # 来源权威等级
expire_at: "2027-01-12"             # 半年有效期
status: active
chunks:
  - c_001: { status: active }
  - c_002: { status: active }
  - c_003: { status: superseded, superseded_by: c_004 }

检索时的治理过滤（伪代码）

def retrieve_with_governance(query_vec, filters, top_k=5):
    # 1. 结构化过滤：只取 active + 未过期
    candidates = vector_db.filter(
        status="active",
        expire_at__gt=now(),                # 未过期
    )
    # 2. 冲突检测：同一 source 的多个版本只保留最新
    candidates = resolve_conflicts(candidates)   # 按 version desc 去重

    # 3. 语义检索：在干净候选集里搜
    results = vector_db.search(query_vec, ids=candidates.ids, top_k=top_k)

    # 4. 回写命中统计（驱动后续清理决策）
    for r in results:
        metadata.increment_hit(r.id)

    return results


def evaluate_and_cleanup():
    """定期评估：自动降级/清理"""
    # 过期标记
    expired = metadata.filter(expire_at__lte=now(), status="active")
    for doc in expired:
        doc.status = "deprecated"

    # 无用降级
    cold = metadata.filter(last_hit__lt=now()-timedelta(days=180), status="active")
    for doc in cold:
        doc.status = "cold"

    # 硬删除已归档 30 天的
    metadata.hard_delete(status="deprecated", deprecated_at__lt=now()-timedelta(days=30))

治理代码的核心不是"怎么搜"，而是搜之前过滤什么、搜之后反馈什么——这和 10 篇 Memory 的"先过滤再检索"、13 篇 Tool Calling 的"先 Selection 再执行"是同一种设计模式。

---

设计权衡

候选方案	优点	缺点	为什么不选
不管治理（只入不出）	零治理成本	越用越脏，长期崩溃	RAG 不是一次性 dump
人工定期清理	灵活	不可靠，人总是会忘	和第 04 篇 Review 同理——没人做
全自动删除（过期即删）	干净	可能误删仍有效的文档	软标记 + 观察期是安全网
生命周期治理（软标记+自动+人工兜底）	自动化 + 可逆 + 有安全网	需维护元数据	选择理由：唯一把 RAG 从"demo"升级到"生产系统"的方案

治理不是越高频越好。 每天全量扫一遍是过度工程。推荐的节奏：过期检查每日自动、无用清理每周、冲突裁决按事件触发。

---

总结

✅ RAG 真正的瓶颈不在检索，在知识治理——40% 的错误来自知识本身过期/冲突，不是"没搜到"。
✅ 知识生命周期六步：Document（带标记入境）→ Chunk（保留溯源）→ Metadata（治理中枢）→ Embedding → Retrieve（过滤脏数据）→ Evaluate（闭环回写）。
✅ 三个核心治理问题：删（时间/冲突/无用触发）/ 更（源变更/反馈触发）/ 废（过期/孤儿/反馈确认）。
✅ Metadata 是治理的核心阵地——每份知识入库时就必须带上有效期、版本号、来源权威等级。
✅ 治理是自动化的，但软标记+观察期是安全网——宁可多留 30 天，不误删一份有效知识。

---

参考资料

• 第 10 篇：Memory 架构设计 → "先过滤再检索"的同构模式，本文 Retrieve 层治理的逻辑来源
• 第 04 篇：Review——为什么 AI Agent 必须每天复盘 → Evaluate 闭环反馈的驱动机制
• 第 06 篇：Knowledge 如何演化成 Rules → 知识的双向流动，和本文"淘汰/更新"逻辑一致
• Data Governance (DAMA DMBOK) → 数据治理框架，知识生命周期管理的参照
• RAG 评估（RAGAS / TruLens） → Evaluate 环节的技术实现参考

---

系列导航

上一篇：AI Agent 工程实践（14）：MCP——为什么它正在成为 Agent 的 USB 接口？
下一篇： AI Agent 工程实践（16）：Agent 为什么需要状态（State）？

本文是 [AI Agent 工程实践] 系列的第 15 篇（第二季 · 工程实现）。