按时间切分时，检索知识库允许使用测试时点之后的知识吗？

第115题：按时间切分时，检索知识库允许使用测试时点之后的知识吗？

1. 核心回答

如果实验声称评估：

• 时间外推能力；
• 未来漏洞泛化能力；
• 历史时点真实检测能力；
• “在当时已有信息条件下能否发现漏洞”；

那么检索知识库不能使用测试时点之后才公开的知识。

对于测试样本 $x_i$，定义预测时点为 $t_i$，检索文档 $d$ 必须满足：

$$available\_time(d)\le t_i$$

更严格地，如果文档存在多个版本 $v$：

$$available\_time(d,v)\le t_i$$

系统只能访问 $t_i$ 时实际可获得的文档版本。

否则可能把未来发布的：

• CVE 公告；
• 漏洞补丁；
• 修复 Commit；
• Security Advisory；
• 漏洞分析文章；
• 新增 CWE 映射；
• 后续更新的漏洞描述；

提供给模型，形成 Future Knowledge Leakage，最终结果会高估真实的时间泛化能力。

---

2. 首先要定义“测试时点”

时间切分中最容易含糊的是：

$t_i$ 到底代表什么？

根据任务不同，可以有不同定义。

例如：

2.1 漏洞早期检测

问题是：

在漏洞公开之前，能否根据代码识别风险？

则：

$$t_i=\text{代码版本当时的预测时间}$$

此时未来 CVE、补丁和漏洞报告都不能使用。

2.2 CVE 发布时辅助分析

问题是：

CVE 刚公开时，系统能够做到什么？

则可以定义：

$$t_i=\text{CVE public disclosure time}$$

只能使用这一时间以前已经公开的信息。

2.3 当前漏洞分析系统

如果研究问题是：

今天分析一个历史漏洞，使用当前所有公开知识能做到什么？

那么可以使用今天的知识库。

但这种实验回答的是：

Current Retrospective Analysis

不能再用它证明：

Historical / Prospective Detection

因此论文必须明确实验 Claim。

---

3. 需要区分事件发生时间和知识可获得时间

至少维护两个时间字段。

3.1 Event Time

表示漏洞、代码或 Commit 本身对应的时间：

$$t_{event}$$

例如：

vulnerable commit time

3.2 Knowledge Available Time

表示某条知识什么时候真正变成系统可以获取的公开信息：

$$t_{available}$$

真正用于检索过滤的是：

$$t_{available}\le t_i$$

例如某漏洞在 2024 年已经存在：

$$t_{event}=2024$$

但直到 2025 年才公开 CVE：

$$t_{available}=2025$$

如果模拟 2024 年检测，就不能因为漏洞“已经存在”而使用 2025 年发布的 CVE。

---

4. CVE ID 中的年份不能直接当知识发布时间

例如：

CVE-2025-XXXX

其中年份不能简单解释为：

2025 年某日系统已经知道全部漏洞信息

CVE ID 可以先处于 RESERVED 状态，之后才正式发布记录。

因此需要记录真正的：

• Public Disclosure Time；
• CVE Record Published Time；
• Advisory Published Time；
• Patch Public Time。

CVE 官方也说明，CVE Record 的相关日期并不必然代表漏洞的发现时间或最初向厂商报告的时间。

所以数据构建时应使用明确的公开可获得时间，不能只通过 CVE ID 年份推断。

---

5. 一个更隐蔽的问题：CVE 会持续更新

假设某 CVE：

2024-03：首次发布
2024-05：增加 CWE
2024-07：增加修复版本
2025-01：增加 Patch Reference

现在我要模拟：

$$t_i=2024\text{-}04$$

如果直接从今天的 NVD/CVE 数据库读取这条记录，虽然它的：

Published Date = 2024-03

但内容可能已经包含：

2025-01 才加入的 Patch Reference

这仍然属于未来知识泄漏。

因此不能只检查：

$$publish\_date(d)\le t_i$$

还需要检查文档版本。

---

6. 正确方法是版本化知识库

对于每条文档保存：

document_id
version_id
source
event_time
published_at
modified_at
available_at
ingested_at
content_hash
content

例如：

CVE-X
├── v1  2024-03-01
├── v2  2024-05-10
├── v3  2024-07-13
└── v4  2025-01-08

如果测试时间为：

$$t_i=2024\text{-}06$$

只能访问：

v1 / v2

不能看到：

v3 / v4

因此检索条件应该近似为：

$$
d^*

\arg\max_{d,v}
sim(q,d_v)
$$

subject to：

$$available\_at(d,v)\le t_i$$

---

7. 建议建立 Point-in-Time Knowledge Snapshot

最稳妥的方法是直接建立知识快照。

例如：

KB_2024_01
KB_2024_02
KB_2024_03
...
KB_2025_01

测试样本发生在：

2024-06-15

只能访问：

KB_2024_06_15

或者最近的前向快照。

整个评测流程变成：

Test Sample
    ↓
Prediction Time t
    ↓
Select KB Snapshot(t)
    ↓
Retrieve
    ↓
Rerank
    ↓
Prompt
    ↓
Prediction

这类设计可以称为：

Point-in-Time Retrieval 或 Time-Sliced Retrieval。

---

8. 检索库中哪些东西特别容易泄漏

代码安全任务中重点审计：

8.1 修复 Commit

如果测试的是漏洞代码：

vulnerable.c

检索库出现之后发布的：

fix CVE-XXXX

几乎直接暴露答案。

8.2 Patch Diff

例如：

- sprintf(buf, input)
+ snprintf(buf, ...)

可能直接告诉模型漏洞位置和修复方法。

8.3 CVE Description

可能包含：

• 漏洞类型；
• 受影响函数；
• 产品；
• 攻击条件。

8.4 Commit Message

例如：

Fix SQL injection in user_query()

属于极强标签泄漏。

8.5 Security Advisory

可能同时包含：

• Root Cause；
• Exploit Condition；
• Fixed Version；
• Mitigation。

8.6 后续 CWE 标注

如果测试任务是预测 CWE，未来增加的 CWE 映射等价于标签泄漏风险。

---

9. Source Code 本身也要遵循时间条件

假设 Repository 在测试时间：

$$t_i$$

之后增加了：

• 修复函数；
• 新注释；
• 测试用例；
• Security Check；
• README 安全说明。

如果 RAG 使用的是 Repository 最新版本，也会出现未来泄漏。

因此仓库检索需要锁定：

$$commit\_time\le t_i$$

并更进一步保存：

repository
commit_hash
branch
file_path
blob_hash
timestamp

测试样本和检索语料都基于对应历史 Commit Snapshot。

---

10. “Commit 时间”本身也需要小心

Git 中至少可能出现：

• Author Date；
• Committer Date；
• Push / Public Availability Time。

如果 Commit 在私有仓库中生成：

2024-01

直到：

2024-03

才公开，那么公开系统在 2024-02 无法看到它。

所以最严格的条件依然是：

$$available\_time$$

即：

系统真实能够获取该信息的最早时间。

---

11. 训练集时间切分和 RAG 时间切分必须同时成立

一个常见错误是：

Train: 2020-2023
Test: 2024

表面看已经做了 Temporal Split。

但 RAG Corpus 使用：

2020-2026 的全部知识

于是测试 2024 样本时能够检索：

2025/2026 的知识

这种情况下：

$$TrainTime<TestTime$$

成立，

但：

$$KnowledgeTime<TestTime$$

不成立。

所以完整约束应该是：

$$TrainTime<t_i$$

并且：

$$KnowledgeAvailableTime\le t_i$$

两者缺一不可。

---

12. Embedding Index 也需要按时间重建或过滤

如果使用向量数据库，需要考虑 Index 本身。

最简单方案是：

每个时间快照建立独立 Index

例如：

index_2024_01
index_2024_02
index_2024_03

另一种方案是在统一索引中保存：

available_at

检索时执行：

vector_search
+
available_at <= t_i

但要确认 ANN 系统的过滤策略不会因为先召回后过滤造成明显 Recall 损失。

因此最好额外比较：

• Exact Search；
• ANN + Time Filter。

确保时间过滤没有改变实验结论。

---

13. BM25 也可能受到未来 Corpus 的影响

这个问题不只存在于 Dense Retrieval。

BM25 中：

$$
IDF(q_i)

\log
\frac{N-n(q_i)+0.5}
{n(q_i)+0.5}
$$

其中：

• $N$：Corpus 文档总数；
• $n(q_i)$：包含词 $q_i$ 的文档数。

如果使用包含未来文档的整个 Corpus 来计算 IDF，即使最终过滤掉未来文档：

$$N$$

和：

$$n(q_i)$$

仍然已经受未来数据影响。

对于严格的历史回放实验，BM25 的：

• Corpus；
• IDF；
• Index；

也应该基于当时快照重新构建。

---

14. 推荐记录 Bitemporal Provenance

如果系统要求非常严格，可以为知识记录两个维度：

14.1 Valid Time

事实在现实世界中什么时候成立：

$$t_{valid}$$

14.2 Transaction / Available Time

系统什么时候知道这个事实：

$$t_{known}$$

例如：

漏洞从 2023 年版本开始存在

但：

2024 年才被公开发现

则：

$$t_{valid}=2023$$

$$t_{known}=2024$$

预测时必须依据：

$$t_{known}$$

过滤知识。

这类设计可以理解为 Bitemporal Provenance。

---

15. 应该设计一个 Future-Leak 对照实验

未来知识通常不能进入正式实验。

但可以故意加入一个诊断实验。

例如四组：

Variant	Retrieval Corpus
No Retrieval	无
Historical RAG	仅 $t\le t_i$
Future-Leak RAG	全量最新知识
Historical Oracle	$t\le t_i$ 内人工最佳证据

定义：

$$M_{hist}$$

和：

$$M_{future}$$

如果：

$$M_{future}\gg M_{hist}$$

说明未来知识对性能影响巨大。

定义：

$$
LeakageGain

M_{future}-M_{hist}
$$

可以直接量化未来知识造成的乐观偏差。

---

16. 为什么 Historical Oracle 很重要

假设：

$$M_{hist}$$

很低。

可能有两个原因：

1. 当时已经存在有用知识，但 Retriever 没找到；
2. 当时根本没有足够外部知识。

因此建立：

$$M_{oracle}$$

即人工从 $t_i$ 之前知识中选择最佳证据。

如果：

$$M_{oracle}\gg M_{hist}$$

说明 Retriever 是主要瓶颈。

如果：

$$M_{oracle}\approx M_{hist}$$

且两者都低，可能说明当时公开知识本身不足。

这能够把：

Retriever Failure

和：

Historical Information Scarcity

区分开。

---

17. 时间切分最好使用滚动回放

可以建立多个测试窗口。

例如：

Train / Development:
<= 2023-12

Test Window 1:
2024-Q1

Test Window 2:
2024-Q2

Test Window 3:
2024-Q3

Test Window 4:
2024-Q4

每个时间窗口 $T_k$ 使用：

$$
KB(T_k)

{d\mid available(d)<T_k}
$$

然后得到：

$$Metric(T_1),Metric(T_2),\dots$$

这样还能观察：

• Temporal Drift；
• 新漏洞类型；
• 新框架；
• 新 API；
• 新攻击模式；

对模型性能的影响。

---

18. 时间戳策略必须预先写清楚

源文件明确要求本题“必须补时间戳策略”。

我会在实验协议中定义：

Prediction Time:
测试样本被认为需要做出判断的时刻。

Document Available Time:
文档第一次可被系统公开获取的时间。

Version Available Time:
某个文档版本首次公开可获取的时间。

Repository Snapshot:
prediction_time 前最后一个允许访问的 commit。

CVE Snapshot:
prediction_time 前最后一个公开版本。

Retrieval Rule:
available_time <= prediction_time。

同时统一使用 UTC 或其他统一时区。

这样实验才可以被复现。

---

19. 还需要保存 Knowledge Cutoff

每一次实验报告：

dataset_cutoff
model_cutoff
retrieval_cutoff
repository_cutoff
CVE_snapshot_version
evaluation_time

例如：

dataset_cutoff: 2024-06-30
retrieval_cutoff: 2024-06-30T23:59:59Z
CVE_snapshot: 2024-06-30
repo_snapshot: commit <= cutoff

这样别人才能判断系统到底看到了哪些信息。

---

20. 什么情况下可以允许测试时点之后的知识

存在一种合理场景。

研究问题明确是：

在今天已有全部公开知识的条件下，分析历史代码。

例如企业当前正在扫描十年前的 Legacy Code。

那么今天的：

• CVE；
• CWE；
• Patch；
• Advisory；

当然可以使用。

此时实验应该明确称为：

Retrospective Analysis

它衡量的是：

$$P(y\mid x,K_{\text{current}})$$

如果评估历史时点能力，则衡量：

$$P(y\mid x,K_{\le t})$$

这是两个不同研究问题。

报告结果时应分别命名。

---

21. 一个推荐的完整实验矩阵

我会至少比较：

实验	模型	检索知识
A	Base	无检索
B	Base	时间一致 Knowledge
C	Base	Random Historical Knowledge
D	Base	Historical Oracle
E	Base	最新全量 Knowledge

其中：

• B：真实 Point-in-Time RAG；
• C：排除额外上下文本身的作用；
• D：评估历史知识条件下的上界；
• E：量化未来知识泄漏可能带来的增益。

重点观察：

$$B-A$$

代表时间合法 RAG 的实际增益；

$$D-B$$

代表 Retriever 剩余瓶颈；

$$E-B$$

代表未来信息可能产生的 Leakage Gain。

---

22. 什么结果会推翻实验结论

我会提前定义 Falsification Criteria。

22.1 去掉未来知识后提升消失

如果：

$$M_{future}>M_{baseline}$$

但：

$$M_{historical}\approx M_{baseline}$$

则不能声称 RAG 在真实历史条件下有效。

22.2 Future-Leak 与 Historical 差距巨大

说明当前结果高度依赖未来信息。

22.3 更新后的 CVE 版本贡献了主要增益

说明知识版本管理存在泄漏。

22.4 去掉 Patch / Commit Message 后性能明显下降

需要怀疑模型利用修复答案或标签捷径。

22.5 跨时间窗口性能迅速下降

需要把结论限制在已经验证的时间范围，不能声称长期稳定泛化。

---

23. 一个容易忽略的反例

假设测试样本是：

2024 年 3 月的漏洞代码

知识库里有一条：

CVE Published: 2024-02

看起来满足：

$$Published<t_i$$

但该 CVE 在：

2024-06

才增加了关键 Patch Reference。

今天下载的 CVE JSON 已经包含这个 Reference。

如果直接使用今天的记录：

Published = 2024-02

进行过滤，就会误认为整条文档在 2024-03 都可见。

正确处理单位应该是：

$$(document,version)$$

而不是只有：

$$document$$

这是时间一致 RAG 中非常关键的数据工程问题。

---

24. 与普通数据泄漏原则的关系

通用机器学习中的 Data Leakage 可以定义为：

在预测时使用了真实部署时无法获得的信息。

时间切分 RAG 只是这个原则的一个特殊情况。

对于测试时点 $t_i$：

$$
InformationAvailableAtInference

I_{\le t_i}
$$

正式评测必须保证：

$$ModelInpu{t}_i\subseteq I_{\le t_i}$$

如果出现：

$$I_{>t_i}$$

进入模型、检索、索引统计或 Prompt，

最终得分就可能成为过度乐观估计。

---

25. 面试时可以压缩成下面这段

如果我的实验声称测试时间外推或真实历史时点的检测能力，检索知识库就不能使用测试时点之后才公开的知识。对每个测试样本，我会定义明确的 prediction time $t_i$，检索条件要求文档的 available_at <= t_i。

我还会做版本级控制，因为 CVE、NVD、Advisory 等内容发布以后还会继续修改。如果一个 CVE 2024 年发布，但 2025 年才加入 Patch Reference，模拟 2024 年时只能使用 2024 年当时的版本，不能直接读取今天更新后的记录。因此我会建立 Point-in-Time Knowledge Snapshot，并记录 document version、published_at、modified_at 和 available_at。

Repository 也一样，只允许使用预测时点之前已经公开的 Commit。BM25、Dense Index 和其他索引也要基于同一历史 Corpus 构建，避免未来文档通过索引统计间接进入实验。

实验上我会比较 No-Retrieval、Time-Consistent RAG、Historical Oracle 和一个只用于诊断的 Future-Leak RAG。如果允许未来知识后的效果显著提高，我会把这部分差值视为 leakage gain，而不会把它计入真实时间泛化能力。

只有当论文目标明确是“今天利用当前全部知识分析历史代码”时，才允许使用之后发布的知识，此时结论应明确限定为 retrospective analysis。

目前原始资料没有给出实际时间戳策略和实验结果，所以这部分需要补实验，不能声称已经完成时间一致性验证。

---

26. 来源

1. 原始题目表格，第115题：要求审计仓库、标签、切分、检索库、Prompt 和预测的数据血缘，并明确指出“必须补时间戳策略”。
2. scikit-learn Documentation, Common pitfalls and recommended practices — Data leakage：预测时不可获得的信息进入模型会造成过度乐观的性能评估。
3. CVE Program, CVE FAQs / CVE Process：CVE Record 的公开时间与漏洞发现时间等概念需要区分，CVE Record 发布后也可以继续更新。
4. NIST NVD：CVE 页面分别记录 Published Date 和 Last Modified，并保存记录更新历史，说明漏洞知识具有版本演化特征。
5. Jain et al., LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, 2024：通过持续引入新发布问题构建时间窗口，降低训练数据污染并评估更真实的代码能力。
6. Gastinger et al., TGB 2.0: A Benchmark for Learning on Temporal Knowledge Graphs and Heterogeneous Graphs, NeurIPS 2024：强调面向未来预测的时间数据需要可复现、符合时间顺序的评测协议。