RAG Freshness 生产实战：时间语义、增量索引、版本治理与过期答案拦截

从 Event Time、Valid Time、CDC、Outbox、External Version、Tombstone、Watermark、缓存失效、时间感知检索到 Freshness SLO，构建能够解释“数据何时发生、何时可见、答案依据哪个版本”的生产级 RAG 新鲜度系统。

RAG 接入外部知识，只解决了“模型可以查资料”，没有自动解决“模型查到的是不是当前有效资料”。

生产系统中的过期答案通常不是单点故障，而是一条时间链路上的累计延迟：

业务事实已经变化
→ 来源系统尚未提交
→ CDC 尚未捕获
→ 队列积压
→ Worker 重试
→ Elasticsearch 已写入但尚未对搜索可见
→ 检索仍命中旧 Revision
→ Context 同时包含新旧版本
→ Answer Cache 继续返回旧答案

因此 Freshness 不是给 updated_at 加一个排序权重，而是一个从来源事实、传播、索引、缓存、检索、上下文到答案声明的完整协议。

资料快照：本文核查截至 2026-08-06。时间语义与流式处理主要依据 Apache Flink Event Time / Watermark 文档；增量变更依据 Debezium MySQL Connector；索引顺序与可见性依据 Elasticsearch External Versioning、Refresh 与 Point-in-Time 文档；动态事实评测参考 FreshQA / FreshLLMs。文中的 SLO、阈值和时间窗口是工程示例，必须按真实来源、流量和业务风险校准。

RAG Freshness 生产实战：从业务事实、CDC、索引、缓存、时间感知检索到答案时间声明

图 1：Freshness 是一条端到端时间链，不是单一 updated_at 字段。

一句话结论

一条 RAG 答案只有同时回答下面五个问题，才算“时间上可信”：

事实是什么时候发生或生效的？
系统是什么时候观察到并处理它的？
搜索索引是什么时候对查询可见的？
本次问题要求“当前”“历史”还是“截至某时”的答案？
答案引用的是哪个 Source Revision，数据截至什么时间？

推荐把 Freshness 建模为：

Source Valid Time
+ Source Commit Time
+ CDC Capture Time
+ Queue / Processing Time
+ Index Write Time
+ Search Visible Time
+ Cache Invalidation Time
+ Query Business As-of
+ Citation Revision

1. Freshness 不是一个时间戳，而是一组时间语义

RAG Freshness 时间模型：Valid Time、Commit Time、Ingest Time、Index Time、Visible Time 与 Answer Time

图 2：同一条事实至少需要区分业务有效时间和系统观察时间；否则历史问答、回放和延迟归因都会混在一起。

1.1 Event Time

事实在业务世界中发生的时间：

订单创建时间
政策生效时间
接口版本发布日期
会议发生时间
字幕对应的视频时间

1.2 Source Commit Time

变化在来源数据库或内容系统中正式提交的时间。

Debezium 事件中的 source.ts_ms 可用于表示来源数据库提交变化的时间；事件顶层的 ts_ms 则表示 Connector 处理该事件的时间。二者之差可以用于观察 CDC 处理延迟。

1.3 Processing Time

某个 Worker、Indexer 或 Enrichment Job 实际处理事件的本地时间。

它容易受队列、重试、机器负载和网络影响，不应该替代业务时间。

1.4 Ingest / Index / Visible Time

ingested_at
→ 进入知识摄取系统

indexed_at
→ 写入搜索后端

search_visible_at
→ 搜索请求能够稳定读到

cache_invalidated_at
→ 旧缓存已经失效

Elasticsearch 是 Near Real-Time 搜索系统。写入成功与搜索可见之间可能存在 Refresh 延迟，因此 indexed_at 不等于 search_visible_at。

1.5 Answer Time 与 Business As-of

asked_at
→ 用户发问时间

business_as_of
→ 用户真正要求的业务时间

answered_at
→ 系统完成回答时间

问题：

“现在报销标准是多少？”

通常隐含：

business_as_of = current business time

问题：

“2024 年 12 月报销标准是多少？”

必须使用历史有效版本，而不是当前最新文档。

2. Valid Time 与 System Time：建议使用双时间模型

双时间模型把两个问题分开：

Valid Time
→ 事实在业务世界中何时有效

System Time
→ 系统从何时开始知道并保存这条事实

例如：

政策 6 月 1 日生效
但 6 月 3 日才上传到知识库

则：

valid_from = 2026-06-01
system_observed_at = 2026-06-03

历史回放时可以分别回答：

“6 月 2 日业务上有效的政策是什么？”
“系统在 6 月 2 日当时能够知道什么？”

2.1 推荐字段

{
  "source_id": "policy_remote_work",
  "source_revision": 12,
  "valid_from": "2026-06-01T00:00:00+08:00",
  "valid_to": null,
  "source_committed_at": "2026-06-03T09:14:20+08:00",
  "observed_at": "2026-06-03T09:14:23+08:00",
  "indexed_at": "2026-06-03T09:14:31+08:00",
  "search_visible_at": "2026-06-03T09:14:33+08:00",
  "status": "active"
}

2.2 不能只依赖 `updated_at`

updated_at 可能表示：

用户最后保存时间；
内容系统同步时间；
文件复制时间；
元数据更新；
业务生效时间；
重建索引时间。

一个字段承载多个含义，会让过滤、排序和审计失去确定性。

3. Freshness SLO：从来源变化到答案可见

不要只设：

文档每天同步一次

而应定义端到端 SLO。

Source Change
→ Searchable
→ Answerable
→ Cache Correct

3.1 分阶段 SLO

阶段	指标	示例 SLO
Source Commit → CDC	CDC Capture Lag	P95 < 10s
CDC → Worker	Queue Lag	P95 < 20s
Worker → ES Write	Projection Lag	P95 < 30s
ES Write → Search Visible	Visibility Lag	P95 < 5s
Source Change → Cache Invalidated	Cache Invalidation Lag	P95 < 45s
Source Change → Correct Answer	End-to-End Freshness Lag	P95 < 60s

3.2 分来源等级

freshness_tiers:
  critical_policy:
    e2e_p95: 60s
    stale_answer_tolerance: 0
  product_docs:
    e2e_p95: 10m
    stale_answer_tolerance: 0.001
  historical_archive:
    e2e_p95: 24h
    stale_answer_tolerance: 0.01

不是所有来源都需要同样低的延迟，但每个来源都应该有明确承诺。

4. 端到端传播链路

RAG Freshness 增量传播链路：Source、CDC、Outbox、Queue、Indexer、Elasticsearch、Cache 与 Answer

图 3：Freshness Lag 应被拆到每个阶段；“答案过期”不能只归因于搜索索引。

4.1 推荐保留的阶段时间

{
  "source_committed_at": "...",
  "cdc_captured_at": "...",
  "queue_published_at": "...",
  "worker_started_at": "...",
  "indexed_at": "...",
  "search_visible_at": "...",
  "cache_invalidated_at": "..."
}

这样才能定位：

来源没更新
CDC 没捕获
队列积压
Embedding 过慢
Bulk 部分失败
Refresh 延迟
缓存未失效

5. CDC、Outbox 与顺序保证

5.1 CDC 负责捕获变化，不负责定义业务语义

Debezium 可以输出：

c → create
u → update
d → delete
r → snapshot read

但业务系统仍需要决定：

哪些字段变化需要重建 Embedding；
哪些变化只更新 Metadata；
状态变化是否立即禁用检索；
主键变化如何清理旧文档；
删除是否写 Tombstone；
同一实体如何生成单调 Revision。

5.2 Outbox 用于绑定业务事务

CREATE TABLE knowledge_outbox (
  event_id VARCHAR(64) PRIMARY KEY,
  aggregate_id VARCHAR(64) NOT NULL,
  aggregate_type VARCHAR(64) NOT NULL,
  source_revision BIGINT NOT NULL,
  event_type VARCHAR(32) NOT NULL,
  source_committed_at DATETIME(6) NOT NULL,
  payload JSON NOT NULL,
  published_at DATETIME(6),
  created_at DATETIME(6) NOT NULL,
  UNIQUE KEY uk_aggregate_revision (
    aggregate_id,
    source_revision
  )
);

业务事实和 Outbox Event 在同一事务提交，可以避免“数据库已经更新，但同步消息丢失”。

5.3 Late 与 Out-of-order Event

流式系统中：

Revision 12
可能比 Revision 11 先到达 Indexer

不能按消息到达时间决定最终状态。

accept(event)
only if
event.source_revision > stored.source_revision

Elasticsearch 的 version_type=external 可以使用来源系统维护的单调版本，只接受比当前更高的版本。

5.4 Watermark 思维

Apache Flink 使用 Event Time 与 Watermark 处理乱序和迟到事件。RAG 索引系统不一定直接使用 Flink，但可以吸收其思想：

Watermark
→ 当前认为已经完整处理到哪个 Source Event Time / Revision

每个数据源或分区可以维护：

source_high_watermark
processed_high_watermark
indexed_high_watermark
search_visible_high_watermark

6. Revision、Tombstone 与删除传播

6.1 单调 Revision

source_revision
→ 业务实体内容状态版本

projection_schema_version
→ ES 投影结构版本

physical_index_generation
→ 物理索引代际

三者不能混成一个版本号。

6.2 Tombstone

删除不能只执行：

DELETE ES document

因为旧 UPSERT 可能在稍后重放，使文档复活。

推荐保存：

{
  "entity_id": "doc_001",
  "source_revision": 19,
  "deleted": true,
  "deleted_at": "2026-08-06T10:03:00+08:00",
  "retain_until": "2026-09-06T10:03:00+08:00"
}

Tombstone 保留时间至少覆盖：

最大消息延迟；
Worker 重试；
DLQ 人工重放；
数据恢复；
跨区域同步。

refresh=false
→ 吞吐优先，等待自动 Refresh

refresh=wait_for
→ 等到本次写入可被搜索读取

refresh=true
→ 立即 Refresh，成本较高

生产建议：

批量索引默认依赖自动 Refresh；
高优先级更新使用 wait_for 或专用索引策略；
不要对每条普通更新都强制 refresh=true；
单独测量 search_visible_at。

7.2 Search Visibility Probe

写入后可以通过轻量探测确认：

目标 Document ID
+ expected source_revision

是否已经被 Search API 返回。

7.3 Point-in-Time

Elasticsearch Point-in-Time 可以为分页或评测提供稳定的搜索视图。它解决的是“多次搜索看到同一快照”，不是自动解决业务有效时间；业务 as_of 仍需要显式字段和过滤。

8. 文档与 Chunk 的时间 Schema

{
  "knowledge_id": "policy_remote_work",
  "chunk_id": "policy_remote_work:sec_4",
  "source_revision": 12,
  "projection_schema_version": 4,
  "doc_status": "active",
  "valid_from": "2026-06-01T00:00:00+08:00",
  "valid_to": null,
  "source_committed_at": "2026-06-03T09:14:20+08:00",
  "indexed_at": "2026-06-03T09:14:31+08:00",
  "search_visible_at": "2026-06-03T09:14:33+08:00",
  "supersedes_revision": 11,
  "authority_level": 90,
  "freshness_tier": "critical_policy",
  "content_hash": "sha256:..."
}

8.1 Status

建议至少区分：

draft
active
deprecated
superseded
archived
deleted

deprecated 与 superseded 不一定应该从所有历史问题中排除。

8.2 Open-ended Validity

valid_to = null

表示当前没有已知结束时间，不表示“永久有效”。

9. Query Time：用户问的是“现在”还是“当时”

时间感知检索：Query Classifier、Business As-of、版本过滤、Freshness Ranking、Conflict Set 与答案时间声明

图 4：先判断时间意图，再决定过滤、排序和冲突策略。不能对所有 Query 统一使用“最新优先”。

9.1 Query 类型

current
→ 当前有效事实

historical
→ 某个过去时间点

range
→ 一段时间内的变化

compare_versions
→ 比较新旧版本

latest_available
→ 系统当前能看到的最新数据

event_time
→ 某个业务事件发生时的状态

unknown
→ 时间意图不明确，需要追问

9.2 Query Plan

{
  "temporal_intent": "historical",
  "business_as_of": "2024-12-31T23:59:59+08:00",
  "require_complete_period": true,
  "prefer_current": false,
  "allow_superseded": true,
  "must_explain_revision": true
}

9.3 Current Query Filter

{
  "bool": {
    "filter": [
      {
        "term": {
          "doc_status": "active"
        }
      },
      {
        "range": {
          "valid_from": {
            "lte": "now"
          }
        }
      }
    ],
    "must_not": [
      {
        "range": {
          "valid_to": {
            "lt": "now"
          }
        }
      }
    ]
  }
}

9.4 Historical Query Filter

valid_from <= business_as_of
AND
(valid_to IS NULL OR valid_to > business_as_of)

9.5 不要把 Recency Boost 当作时间正确性

Recency Score 只能在已满足有效期、状态和权限约束的候选之间排序。

Hard Filter
→ Validity / ACL / Status

Soft Score
→ Relevance / Authority / Recency

10. Freshness Ranking：相关性、权威和时间衰减

可以构造：

final_score =
  relevance_score
  × authority_factor
  × validity_factor
  × freshness_decay

10.1 时间衰减不适合所有来源

新闻
→ 强时间衰减

产品 Release Note
→ 中等时间衰减

正式政策
→ 以有效期和 Supersession 为主

历史档案
→ 不应因为旧而降权

10.2 Source-specific Policy

freshness_ranking:
  news:
    strategy: exponential_decay
    half_life: 7d
  product_docs:
    strategy: supersession_then_recency
    half_life: 90d
  policy:
    strategy: valid_time_then_authority
  archive:
    strategy: no_decay

10.3 Authority 优先级

最新内容不一定更权威：

个人笔记：今天更新
正式制度：上周发布

对于政策问题，正式制度仍应优先。

11. 新旧冲突与 Supersession Graph

11.1 Supersession 关系

revision 12
supersedes
revision 11

可以保存：

{
  "source_id": "policy_remote_work",
  "revision": 12,
  "supersedes": [11],
  "supersession_reason": "annual_policy_update"
}

11.2 冲突类型

Temporal Conflict
Definition Conflict
Numeric Conflict
Authority Conflict
Locale Conflict
Draft vs Active Conflict

11.3 Context 处理

Current Query
→ 正文使用当前有效版本
→ 旧版本作为 Historical / Contradicting Evidence
→ 必要时解释变更

Historical Query
→ 使用对应 As-of 版本
→ 不把当前版本替换进去

Compare Query
→ 两个版本并列
→ 显示 Diff 与有效期

12. Cache Freshness：TTL 不是正确性保证

12.1 Versioned Key

answer_cache_key =
  tenant
  + permission_scope_hash
  + normalized_query
  + business_as_of
  + corpus_revision
  + context_pack_hash
  + answer_prompt_version
  + model_key

12.2 主动失效

Source Update Event 应触发：

Retrieval Cache
Context Cache
Answer Cache
Citation Preview Cache

失效事件也需要版本：

{
  "event_type": "knowledge_revision_changed",
  "knowledge_id": "policy_remote_work",
  "new_revision": 12,
  "affected_cache_namespaces": [
    "retrieval",
    "context",
    "answer"
  ]
}

12.3 Stale-while-revalidate

适合低风险内容：

先返回短期 Stale
→ 后台刷新

不适合：

权限撤销；
紧急政策；
价格；
法律、医疗与安全；
用户明确要求“最新”。

12.4 Negative Cache

“没有结果”也可能过期。

昨天没有文档
今天刚上传

Negative Cache TTL 应比普通成功缓存更短，并绑定 Corpus Revision。

13. 答案必须声明 As-of 与 Evidence Revision

{
  "answer": "当前远程办公补贴上限为每年 5,000 元。",
  "as_of": "2026-08-06T10:20:00+08:00",
  "data_freshness": {
    "source_committed_at": "2026-08-06T10:18:30+08:00",
    "search_visible_at": "2026-08-06T10:18:43+08:00",
    "freshness_lag_seconds": 13
  },
  "citations": [
    {
      "source_id": "policy_remote_work",
      "source_revision": 12,
      "valid_from": "2026-06-01",
      "source_span_id": "page12_p3"
    }
  ]
}

13.1 用户可读声明

依据：远程办公政策 v12
生效时间：2026-06-01
数据同步截至：2026-08-06 10:18

13.2 Preliminary 与 Final

统计数据可能存在：

preliminary
final
revised

答案应明确：

当前为初步数据，可能因迟到事件修订。

14. Freshness Manifest

{
  "freshness_manifest_id": "fm_20260806_001",
  "query_id": "q_001",
  "business_as_of": "2026-08-06T10:20:00+08:00",
  "source_watermarks": [
    {
      "source_id": "cms_policy",
      "source_high_watermark": 128812,
      "indexed_high_watermark": 128812,
      "search_visible_high_watermark": 128812,
      "lag_seconds": 13
    }
  ],
  "selected_revisions": [
    {
      "knowledge_id": "policy_remote_work",
      "source_revision": 12,
      "valid_from": "2026-06-01",
      "status": "active"
    }
  ],
  "stale_candidates_removed": 3,
  "conflict_ids": [
    "conf_policy_v11_v12"
  ],
  "cache": {
    "answer_cache_hit": false,
    "cache_namespace_revision": 128812
  },
  "freshness_status": "within_slo"
}

它用于：

Answer Trace；
Freshness Evaluation；
Bad Case Replay；
Cache Debug；
发布门禁；
审计。

15. Observability：Freshness Lag 必须可分解

rag.freshness
├── source.observe
├── cdc.capture
├── queue.consume
├── projection.write
├── search.visibility
├── cache.invalidate
├── temporal.retrieve
└── answer.freshness

15.1 核心指标

指标	含义
Source-to-CDC Lag	来源提交到捕获
CDC-to-Queue Lag	捕获到发布
Queue Lag	队列等待
Projection Lag	Worker 处理和写入
Search Visibility Lag	写入到可搜索
Cache Invalidation Lag	变化到旧缓存清除
End-to-End Freshness Lag	来源变化到正确回答
Stale Retrieval Rate	检索命中过期版本
Stale Context Rate	过期证据进入 Context
Stale Answer Rate	最终答案依赖过期事实
Watermark Gap	Source 与 Search Watermark 差
Supersession Miss Rate	旧版本未被识别

15.2 Debezium Lag

connector_processing_lag =
payload.ts_ms - payload.source.ts_ms

注意还需要单独测量：

source commit
→ connector event
→ queue
→ index
→ search visible

16. 评测：动态事实、历史事实和错误前提

FreshQA 包含需要快速变化知识的问题，也包含错误前提问题。它提醒我们：

“最近”“当前”“谁是现任”

与静态知识问题必须分开评测。

16.1 Dataset Cohort

Fast-changing
Slow-changing
Historical As-of
Future-effective
Superseded
False Premise
Late-arriving
Deletion
Primary-key Change
Timezone Boundary
Preliminary vs Final
Permission Revocation

16.2 样本

{
  "case_id": "fresh_001",
  "question": "当前远程办公补贴上限是多少？",
  "asked_at": "2026-08-06T10:20:00+08:00",
  "business_as_of": "2026-08-06T10:20:00+08:00",
  "expected_revision": 12,
  "forbidden_revisions": [11],
  "expected_status": "active",
  "freshness_slo_seconds": 60,
  "expected_behavior": "answer_with_as_of_and_citation"
}

16.3 指标

Revision Accuracy
Valid-time Accuracy
As-of Interpretation Accuracy
Stale Retrieval Rate
Stale Context Rate
Stale Answer Rate
False Premise Rejection
Deletion Propagation Accuracy
Supersession Accuracy
Freshness SLO Pass Rate

17. Release Gate

Hard Gate

hard_gates:
  unauthorized_revision_rate:
    max: 0
  deleted_document_resurrection_rate:
    max: 0
  stale_answer_rate_critical:
    max: 0
  invalid_valid_time_rate:
    max: 0
  false_premise_answer_rate:
    max: 0
  missing_as_of_for_time_sensitive_answers:
    max: 0

Soft Gate

soft_gates:
  e2e_freshness_lag_p95_seconds:
    max_increase_ratio: 0.10
  search_visibility_lag_p95_seconds:
    max_increase_ratio: 0.20
  cache_invalidation_lag_p95_seconds:
    max_increase_ratio: 0.15
  revision_accuracy:
    max_drop: 0.005
  supersession_accuracy:
    max_drop: 0.005

Canary

观察：

新旧 Revision 命中分布；
Watermark Gap；
Queue Lag；
Cache Stale Hit；
Critical Source Freshness SLO；
Temporal Query 错误；
Delete Resurrection；
用户纠错和追问。

18. Freshness Incident 与 Runbook

18.1 常见事故

CDC 停止
队列积压
Embedding Provider 限流
Bulk 部分失败
Refresh 异常
Tombstone 丢失
Cache Invalidation 失败
Timezone 配置错误
Supersession Link 缺失

18.2 止损

critical source stale
→ 禁止确定性回答
→ 展示数据截至时间
→ 返回原始材料
→ 降级到实时 Source API
→ 人工升级

18.3 Repair

MySQL Source of Truth
→ 扫描当前 Revision
→ 对比 ES Revision
→ 对比 Cache Namespace
→ 补写 Missing / Stale
→ 删除 Orphan
→ 重建 Watermark

18.4 Evidence Freeze

事故时保存：

Source Revision；
CDC Offset；
Queue Offset；
Worker Attempt；
ES Physical Index；
Search Visible Result；
Cache Key；
Context Pack；
Answer；
Citation；
Timestamp / Timezone。

19. 分阶段落地路线

P0：先避免明显过期答案

valid_from / valid_to / status / revision；
Source of Truth；
CDC 或 Transactional Outbox；
External Version；
Tombstone；
Current / Historical Query 分类；
Cache Key 绑定 Corpus Revision；
Answer As-of；
Freshness Trace；
Critical Hard Gate。

P1：端到端 Freshness SLO

Source / CDC / Queue / Index / Visible Watermark；
Search Visibility Probe；
Source-specific Freshness Tier；
Supersession Graph；
Temporal Conflict；
Freshness Manifest；
Cohort Evaluation；
Canary Dashboard；
Repair Job。

P2：自适应与预测式 Freshness

变化频率预测；
Source Priority Scheduling；
Proactive Refresh；
Learned Freshness Ranking；
Streaming Embedding；
Live Source API + Indexed RAG Fusion；
Preliminary / Final Revision Forecast；
Agentic Freshness Verification；
自动根因归类。

20. 上线检查清单

总结

RAG Freshness 的目标不是让所有文档都“越新越好”，而是让系统知道：

什么时间发生
什么时间生效
什么时间被系统观察
什么时间进入索引
什么时间对搜索可见
用户问的是哪个时间点
答案引用的是哪个 Revision
当前数据是否满足 Freshness SLO

最重要的工程原则是：

时间正确性必须先由 Valid Time、Revision、Status 和 Scope 决定，再由 Recency 参与排序。没有端到端 Watermark、Source Revision、Cache Invalidation 和 Answer As-of，就无法证明“最新答案”真的使用了最新事实。

参考资料

讨论

继续讨论这篇笔记

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。

RAG Freshness 生产实战：时间语义、增量索引、版本治理与过期答案拦截

继续讨论这篇笔记

On this page