问的是二月的规定，RAG为什么不能只找最新版？

用户问：“二月二十日，普通读者能不能把这本资料借回家？”RAG找到了三月入库的最新通知，答得很肯定：不能。

接着，用户又问：“那二月二十五日，助手为什么告诉我可以？”系统把同一份最新通知再引用一遍，仿佛过去那次回答从来没有发生过。

问题不一定出在检索相关性上。“按今天掌握的资料回看过去”与“还原系统当时知道什么”，是两种不同的查询。 一条updated_at，通常表达不了它们之间的区别。

本篇把数据库里的双时间思路用于历史资料问答：不是提出一种统一的RAG标准，而是解释如何给检索明确时间视角，避免拿后来的知识改写当时的证据。

AI原创概念插画：冬景立体书、绿树纸卷与柜中的季节玻璃板并置，比喻同一段历史的不同记录视角。画面不是历史现场、数据库截图或真实时间装置。

一、先把“哪一天”拆成两个问题Copy Anchor Link

RAG，即检索增强生成，先从资料库取出相关内容，再让模型据此组织答案。遇到历史问题，仅仅找到“内容有关”的片段还不够，还得确定它适用于哪段时间，以及系统在哪个时点掌握了它。

可以先记住两个维度：

• 业务生效时间：这条规定声称在哪段时期适用。例如“自二月一日起，仅研究员可以外借”。
• 系统记录时间：本系统从何时起把这项说法纳入自己的记录，以及何时被新的认识替代。

Martin Fowler在《Bitemporal History》中把它们称为actual history和record history，也说明了valid/effective与transaction等常见术语。[1] 本文采用“生效”和“记录”，避免把“actual”误读为数据库已经独立证明了现实真相。

双时间保存的是我们如何记录、修正关于过去的说法。错误通知、误录和后续更正仍然可能存在；多加日期不会自动让来源变真。

二、一份迟到的通知，怎样产生两个都需要保留的答案Copy Anchor Link

下面是虚构的图书馆案例。日期均按同一业务日历解释，不涉及跨时区换算；制度、通知与记录都是教学设计，未调用真实图书馆、模型或检索服务。

事情按这个顺序发生：

1. 一月五日，系统录入制度A：“普通读者可以外借”，注明自一月一日起适用，尚未登记结束日期。
2. 二月二十五日，助手依据当时的资料回答：二月二十日普通读者可以外借。
3. 三月十日，系统才收录一份三月八日发布的权威更正通知：从二月一日起，外借已限制为研究员。案例假定这份通知确实具有追溯效力，不存在其他例外。

三月十二日再问，就要分开答：

第二行不是说旧回答在现实制度上正确，而是说明它依据的历史知识状态。解释过去为什么答成那样，不能偷偷把三月才知道的通知塞回二月。

更重要的是，知识状态重建只能说明“当时哪些资料可用”。要证明那次助手实际读到了什么，还需要保存那次请求采用的证据版本、模型输入或足够的运行记录。可用过，不等于实际用过。

三、只有版本号，为什么仍然不够Copy Anchor Link

版本号能区分内容；生效区间与记录区间则说明内容应该在哪个视角下出现。它们不能互相替代。

下面是上述案例的一种逻辑表示。区间采用左闭右开：包含起点，不包含终点；“未结束”表示本记录尚未登记上界。三月十日的变化应作为一次一致的记录修订处理，表格不是数据库DDL或可直接运行的迁移方案。

A保留了旧的知识状态；B和C表达三月十日之后对制度历史的新认识。不能只往库里追加C，却让A在当前记录视角下继续覆盖整个二月，那会制造两个互相冲突的当前说法。

也不要把A的生效结束日直接改成二月一日、却完全不留旧认识：这样虽然能回答现在怎么看过去，却无法还原二月二十五日系统曾经如何记录。

IBM Db2文档区分了应用时期与系统时期：前者表达业务数据何时有效，后者维护行的历史版本；双时间表把两者结合。[2] 这支持的是数据建模机制，不是某个RAG框架自动具备历史推理能力的证明。

四、ValidFrom这个名字，也可能让人误会Copy Anchor Link

看到数据库字段叫ValidFrom，很容易以为它就是“制度开始生效的日子”。但字段名不能代替产品契约。

SQL Server的系统版本化时态表会根据事务开始时间记录行版本的起止，使用UTC；文档示例恰好把这些列命名为ValidFrom和ValidTo。[3] 它们描述的是该机制下的系统时间历史，不会从通知正文自动识别“本规定追溯至二月一日”。

因此，至少应分别定义：

• 来源的发布日期：文件对外发布的时间；
• 资料进入本系统并被接纳的时间：本系统的记录视角；
• 规定声明的生效区间：业务适用范围；
• 索引可检索时间：检索副本何时实际准备好。

这几项可以偶尔相同，但不能默认相同。PDF文件修改时间、下载时间或向量库写入时间，都不能凭空充当业务生效日期。

“系统何时知道”也必须指定是谁的系统：发布部门、采集器、审定资料库和问答索引可能各有记录时间。Fowler特别讨论了不同主体在不同时间得知同一事实的问题。[1] 如果你的产品把“知道”定义为通过审定且检索就绪，就应明确采用这个入口，不把更早的下载时间混进来。

五、让检索先固定视角，再谈相关性Copy Anchor Link

一个可操作的应用设计是：在检索前生成一张简短的查询卡。这是本文的工程建议，不是上述资料定义的通用API。

对象：本馆、指定资料及读者类别
问题模式：按当前知识回看历史 / 按历史知识状态复盘
业务生效日：2025-02-20
记录视角日：2025-03-12 或 2025-02-25
边界规则：左闭右开
权限：按本次请求的当前授权核验

这里的2025年只是给虚构案例补全日期，不表示真实事件。

随后按所用系统的能力，把业务日期和记录视角共同纳入候选准入；相关性排序在这个明确范围内进行，进入模型前再核对证据身份与时间字段。若检索系统不能原生支持双区间查询，可以由受控资料清单先解析出允许使用的版本ID，再按这些ID检索。具体实现仍须验证过滤能力与召回范围，本文没有运行向量库或比较性能。

不要先无条件取一小批“最新、最相关”的片段，再指望后置日期过滤一定找齐历史证据。过滤只能移除不适用项，不能补回没有进入候选集的历史版本。

每个送入模型的片段，应能回到明确的来源版本和条款位置，并携带适用区间。答案也应说清视角，例如：

按三月十二日已收录的更正通知，二月二十日的规定是仅研究员可外借。二月二十五日系统尚未收录这份更正，当时资料记为普通读者可外借；是否为那次实际回答的直接依据，还需核对该次运行记录。

如果用户只说“当时怎么规定”，而两种视角会改变结论，有交互时应澄清；无法澄清时可以并列说明两种视角，不应默默选一个再装作没有歧义。

六、时间过滤解决不了的事Copy Anchor Link

第一，追溯生效必须有依据。 通知三月发布，不代表它天然可以追溯到二月。生效字段需要来自权威条款或可信业务流程；提取不确定时标为未知，而不是让模型补一个日期。

第二，同一时段可能有地区、读者类别和资料类型例外。 两个区间都匹配，仍可能选错业务对象。遇到冲突或重叠，应按明确的优先关系处理，不能简单取更新时间最大的一条。

第三，过去能访问，不等于今天仍有权访问。 历史复盘不能恢复已经撤销的访问权限；当前访问控制与历史内容选择是两道不同的门。

第四，资料历史不等于行动撤销机制。 更正后是否补发通知、撤销旧审批或重新处理业务，需要另行授权与业务规则。Fowler也指出，双时间本身不足以解决追溯变更带来的全部后果。[1]

第五，不是所有知识库都值得引入完整双时间。 如果只回答当前政策、不做追溯更正，也不要求历史复盘，清楚的生效字段加可靠的请求证据快照可能已经够用。完整双时间会增加存储、修订、查询、留存及用户理解成本，不该为一个术语把简单系统做复杂。

七、历史问答上线前的检查清单Copy Anchor Link

• 明确产品回答“今天怎么看过去”，还是“过去当时知道什么”。
• 生效日期、来源发布日期、记录时间、索引就绪时间分别定义，未知值不猜。
• 记录视角明确到具体系统或审定入口，不混用不同主体的时间。
• 同一来源的迟到通知和追溯更正保留旧认识，不直接抹掉历史。
• 修订后核对两种时间区间及对象范围，能识别不合理重叠和空档。
• 原文、切片、邻文扩展和最终引用都使用同一历史视角，不拿当前版补历史版缺口。
• 缓存区分查询模式、业务日期、记录视角及证据版本；历史答案仍可被当前授权或撤销政策阻断。
• 测试迟到更正、预告未来生效、结束边界、缺失日期和来源冲突，并分别写出预期答案。
• 需要解释某次真实回答时，读取该次实际证据记录；缺少记录就说明无法精确重建。

这份清单及前面的案例是建议测试设计，未执行模型评测、数据库时态查询或生产故障演练。

历史RAG最容易犯的错，不只是引用了旧资料。有时恰恰相反：它把新资料放回了一个新资料尚不存在的时点。 在让模型回答之前，先决定要站在哪个时间视角看问题。

来源与阅读范围Copy Anchor Link

本文由AI创作，图书馆、制度及日期均为虚构教学材料。把双时间用于RAG准入、查询卡和缓存的部分是工程推导，不是来源声称的模型效果或行业统一规范。

检索截止：2026年10月24日02:04 UTC。动态文档以本轮读取内容为准；没有核实独立原始发布日期的页面不猜日期。

1. Martin Fowler：Bitemporal History，2021年4月7日。实际读取The Two Dimensions、Changing the Retroactive Change、Using Bitemporality、Append-only History、Consequences of Retroactive Changes及Perspectives for Record Time相关正文；初次提取截断后，以公开HTML补读。支撑双时间、追溯更正、主体视角与复杂度取舍，不是RAG实验报告。
2. IBM Db2 11.5.x官方文档：Bitemporal tables、Application-period temporal tables、System-period temporal tables。实际读取三个概念页中双时期组合、BUSINESS_TIME和SYSTEM_TIME相关说明；未锁定补丁版或核实原始发布日期。三页来自同一厂商，不算独立复现。
3. Microsoft Learn：Temporal tables，SQL Server ver17文档视图。实际读取公开HTML的行版本维护、事务开始时间、UTC与AS OF条件章节。提取元数据中的内容日期为2025年5月19日，另列页面更新于2026年1月23日；它们不是产品首次发布日期。本文只引用已读系统时间机制，不把它等同于业务生效时间。