版本混在一起，是检索里的"慢性病"
文档会改版：政策更新、接口变更、产品迭代 ✔。如果索引里旧版与新版并存 ✗，
检索会同时召回两者 ✔，模型就可能把旧规则当成现行规则讲出来 ✗ —— 而且很难被发现 ✗。
要求：每个片段都能回答"它属于哪个版本" ✔，并且默认只检索现行版本 ✔。
一、索引里要带的版本字段
doc_id（同一份文档的稳定标识 ✔）
version（版本号或日期 ✔）
status（current / superseded / draft ✔）
effective_from / effective_to（生效区间 ✔）
要点：doc_id 要在改版前后保持不变 ✗ ✔（否则无法判断"这两段是同一文档的新旧版" ✔）。
二、检索时的默认行为
- 默认只取
status = current✔（最安全 ✔）； - 需要历史时显式开启（"查历史版本" ✔），并在结果里标注版本 ✔；
- 若问题明确指向历史（"2023 年的规定是什么" ✔）→ 自动放宽到对应版本 ✔。
关键：默认安全、放宽显式 ✗→✔。
三、迁移与失效怎么处理
- 新版上线后，旧版不要立刻删 ✔（可能仍被引用 ✔）→ 标为
superseded并保留 ✔； - 回答里标注生效时间（"依据 2024-05 版" ✔）；
- 若检索到
superseded且没有current→ 明确提示"该内容已被新版替代，未找到现行版本" ✔（而不是直接答旧版 ✗）。
四、三个常见坑
- 同一文档多次入库（改版时新插入而不是更新 ✗）→ 索引膨胀且新旧并存 ✔；
effective_to缺失 ✗ → 无法判断过期 ✔（至少给superseded标记 ✔）；- 版本字段不参与过滤 ✗ → 检索到旧版却浑然不觉 ✔（与权限过滤同一个错误类型 ✔）。
五、怎么验证
- 抽 20 个"规则类"问题 ✔，检查回答依据的版本 ✔ 是否为现行版本 ✔；
- 构造"新旧冲突"样本 ✔（旧版说 A、新版说 B ✔）→ 期望答案用 B 并说明版本 ✔；
- 定期检查：
status=current的片段里，是否存在同一doc_id的多个 current ✗（数据错误 ✔）。
一条判据
随机抽 10 条回答，能否说出"它依据的是哪个版本" ✔？
说不出，说明版本还没有进入检索链路 ✗。