检索里的版本与变更：别让旧版和新版混在一起

旧版与新版并存会让模型把旧规则当现行规则。本文给出索引该带的版本字段、检索的默认行为（只取 current）、迁移与失效处理、三个常见坑与验证方法。

版本混在一起，是检索里的"慢性病"

文档会改版：政策更新、接口变更、产品迭代 ✔。如果索引里**旧版与新版并存** ✗，

检索会同时召回两者 ✔，模型就可能把旧规则当成现行规则讲出来 ✗ —— 而且**很难被发现** ✗。

**要求**：每个片段都能回答"**它属于哪个版本**" ✔，并且**默认只检索现行版本** ✔。

```

doc_id（同一份文档的稳定标识 ✔）

version（版本号或日期 ✔）

status（current / superseded / draft ✔）

effective_from / effective_to（生效区间 ✔）

```

**要点**：`doc_id` 要在改版前后**保持不变** ✗ ✔（否则无法判断"这两段是同一文档的新旧版" ✔）。

**默认只取 `status = current`** ✔（最安全 ✔）；

需要历史时**显式开启**（"查历史版本" ✔），并在结果里**标注版本** ✔；

若问题明确指向历史（"2023 年的规定是什么" ✔）→ 自动放宽到对应版本 ✔。

**关键**：默认安全、放宽显式 ✗→✔。

新版上线后，旧版**不要立刻删** ✔（可能仍被引用 ✔）→ 标为 `superseded` 并保留 ✔；

**回答里标注生效时间**（"依据 2024-05 版" ✔）；

若检索到 `superseded` 且没有 `current` → 明确提示"该内容已被新版替代，未找到现行版本" ✔（而不是直接答旧版 ✗）。

1. **同一文档多次入库**（改版时新插入而不是更新 ✗）→ 索引膨胀且新旧并存 ✔；

2. **`effective_to` 缺失** ✗ → 无法判断过期 ✔（至少给 `superseded` 标记 ✔）；

3. **版本字段不参与过滤** ✗ → 检索到旧版却浑然不觉 ✔（与权限过滤同一个错误类型 ✔）。

抽 20 个"规则类"问题 ✔，检查回答依据的版本 ✔ 是否为现行版本 ✔；

构造"新旧冲突"样本 ✔（旧版说 A、新版说 B ✔）→ 期望答案用 B 并说明版本 ✔；

定期检查：`status=current` 的片段里，是否存在**同一 `doc_id` 的多个 current** ✗（数据错误 ✔）。

> 随机抽 10 条回答，能否说出"它依据的是哪个版本" ✔？

> 说不出，说明版本还没有进入检索链路 ✗。