AI 为什么总在执行旧需求？给 RAG 加上“版本闸门”，别让 V1 毁了 V4

你有没有经历过这种崩溃瞬间？

客户说：“Logo 缩小，片尾换成新口号，原来的旁白删掉。”

你把需求更新到 V4，丢给 AI。它一顿操作，最后交出一份完全遵循 V1 的方案：Logo 放大、旧口号保留、旁白还加长了。

更气人的是，它看起来特别自信。

这不是 AI 故意跟你作对。很多时候，问题出在 RAG（检索增强生成）的一个致命盲区：检索命中了“相关内容”，却没有识别“哪条内容已经失效”。

有组很值得琢磨的数据：同一底座的 Qwen3.6，在调整经验筛选与保留机制后，结果能从 24.5% 提到 47.6%。差距接近翻倍。

模型没换，需求也没变。变的是：系统终于知道该把哪些话当回事。

最危险的知识，不是没找到，而是找到了过期知识

很多团队做知识库时，流程很朴素：

1. 把文档、聊天记录、需求单全部丢进去。
2. 切成文本块。
3. 做向量化。
4. 用户一提问，就找最相似的几段内容。

听上去没毛病。

问题在于，向量检索只擅长回答一个问题：“哪段话和当前问题最像？”

它不天然关心另一个更关键的问题：“哪段话现在还有效？”

比如知识库里有四条记录：

| 版本 | 时间 | 指令 | 状态 | | --- | --- | --- | --- | | V1 | 3 月 1 日 | 成片时长控制在 60 秒 | 已废弃 | | V2 | 3 月 3 日 | 时长改为 90 秒 | 已废弃 | | V3 | 3 月 5 日 | 增加产品特写 | 已废弃 | | V4 | 3 月 7 日 | 时长 90 秒，产品特写删掉，改用用户反馈镜头 | 生效中 |

用户问：“这支片子要不要加产品特写？”

如果检索只看语义相似度，V3 里的“增加产品特写”很容易冲到第一名。于是 AI 会干脆利落地回答：加。

答案和问题高度相关，和现实完全相反。

这就是为什么有时检索越准，翻车越狠。它精准命中了那条最像、却已经作废的指令。

别把知识库当仓库，要把它当“有生效日期的决策系统”

一份需求不是静态资料。

它更像合同的补充条款：新版本一签，旧版本就得退出舞台。你可以保留旧记录用来追溯，但不能让它继续指挥 AI 干活。

给每一条可执行经验加上这几个字段：

{
  "content": "片尾使用新口号：让选择更简单",
  "project_id": "video_2025_031",
  "type": "requirement",
  "version": 4,
  "status": "active",
  "created_at": "2025-03-07T14:30:00+08:00",
  "supersedes": ["req_v1", "req_v2"],
  "priority": "high",
  "scope": "final_cut"
}

核心字段就 6 个：

• project_id：这条经验属于哪个项目。别让 A 客户的要求串到 B 客户项目里。
• version：版本号。数字越大，不代表一定优先，但它是重要信号。
• status：active、deprecated、draft、archived，必须分清。
• created_at：时间戳。没有时间，你就没法处理“新旧冲突”。
• supersedes：明确写出它替代了谁。
• scope：适用范围。比如“脚本阶段”与“终版剪辑”不能混为一谈。

这一步看着像在给文档填表，实际上是在给 AI 建立记忆秩序。

检索前先过滤：过期内容别进候选池

很多人会在召回 20 条资料后，让大模型自己判断哪些该用。

这招很省事，也很不稳。

因为过期指令一旦混进上下文，模型就可能把它当成有效依据。尤其当旧文档写得更详细、更像用户原话时，它的“存在感”会非常强。

更靠谱的做法是：先用元数据过滤，再做语义检索。

一条实用的过滤规则

filters = {
    "project_id": current_project_id,
    "status": "active",
    "scope": current_scope
}

results = vector_db.search(
    query=user_query,
    filters=filters,
    top_k=8
)

业务规则也可以写得更明确：

• deprecated：默认禁止召回。
• draft：只能作为参考，不能生成最终执行指令。
• active：允许进入候选池。
• 同一事项出现冲突：优先选择更新时间更晚、版本更高、优先级更高的记录。
• 用户在本轮对话里刚刚说的话：优先级高于知识库历史内容。

注意最后一条。

用户刚说“别加字幕”，知识库里哪怕有一百条“视频必须加字幕”，也得让路。现实沟通的最新决定，应该压过历史经验。

给检索结果加“新鲜度分”，别只迷信相似度

向量相似度很重要，但它不能一票定生死。

可以给每条资料算一个综合分：

最终分数 = 语义相似度 × 0.55
         + 新鲜度分 × 0.20
         + 状态分 × 0.15
         + 优先级分 × 0.10

一个简单的新鲜度公式：

新鲜度分 = exp(-经过天数 / 30)

含义很直白：记录放得越久，分数越低。

当然，不是所有知识都会过期。

“品牌主色是 #0057FF”可能半年都有效；“本周活动主推 3 天游”过了周末就该直接失效。更成熟的方案，是按知识类型设置不同的衰减周期：

| 知识类型 | 建议处理方式 | | --- | --- | | 项目需求 | 强制版本管理，旧版自动失效 | | 产品参数 | 设置负责人和审核日期 | | 活动规则 | 必须配置有效期 | | 通用写作规范 | 长周期保留，定期复审 | | 客户偏好 | 保留历史，但标注最近确认时间 |

别拿“统一的 30 天有效期”糊弄所有资料。财务制度、临时活动、客户口味，寿命完全不是一回事。

冲突不能靠模型猜，要把裁决规则写死

当 AI 同时检索到两条互相打架的要求时，最差的处理方式是让它“综合判断”。

模型一综合，常见结果就是：两边都沾一点，交出一份谁都不满意的怪东西。

比如：

• V2：语气要专业克制。
• V4：这次面向年轻用户，语气要有梗、短促、带点情绪。

AI 若把两条都平均吸收，成品可能会变成：

我们以轻松而严谨的方式，为年轻消费者提供卓越解决方案。

这话像不像一杯放凉的白开水？

建议直接设置冲突裁决顺序：

本轮用户明确指令
> 当前项目的 active 版本需求
> 当前项目已确认的长期规范
> 团队通用规范
> 历史案例与旧版本记录

把这段规则放进系统提示词：

当检索内容存在冲突时，严格按以下优先级执行：
1. 当前对话中用户最新的明确要求；
2. 当前项目状态为 active 的最高版本需求；
3. 当前项目已确认的固定规范；
4. 团队通用规范。

状态为 deprecated 或 archived 的内容不得作为执行依据。
若 active 内容之间仍存在无法自动裁决的冲突，停止猜测，列出冲突项并向用户提问。

这条“停止猜测”特别值钱。

AI 不知道时就问，远比它自作聪明后让你返工两小时强。

一个剪辑需求的完整示例

假设你在做一支新品视频，需求经历了四轮修改。

原始记录

[V1｜已废弃]
- 时长：60 秒
- 重点：功能展示
- 结尾：品牌口号 A

[V2｜已废弃]
- 时长改为 90 秒
- 增加产品开箱镜头

[V3｜已废弃]
- 删除开箱镜头
- 加入创始人采访

[V4｜生效中]
- 时长：90 秒
- 核心镜头：用户真实使用反馈
- 删除创始人采访
- 结尾改为品牌口号 B

用户问：“帮我列一个终版分镜结构。”

错误做法

把 V1 到 V4 全塞进上下文。

AI 会看到“功能展示”“开箱镜头”“创始人采访”“用户反馈”四种方向。它很可能每种来一点，拼成一个 90 秒大杂烩。

正确做法

检索时只召回：

• V4 的完整需求；
• 没有被 V4 覆盖、且状态仍为 active 的品牌视觉规范；
• 当前对话里的补充要求。

旧版本留在数据库里，方便你回看“为什么改掉开箱镜头”，但不进入生成上下文。

终版分镜才会干净：

1. 0-8 秒：用户遇到真实痛点
2. 8-28 秒：产品介入，展示关键使用动作
3. 28-65 秒：三组用户反馈，突出具体变化
4. 65-80 秒：产品优势的简短收束
5. 80-90 秒：品牌口号 B + 统一视觉落版

没有开箱，没有创始人采访，也不会莫名其妙缩回 60 秒。

实操清单：今天就能给你的 RAG 补上这几刀 ✂️

• [ ] 给所有需求类文档加 status、version、updated_at 字段。
• [ ] 旧需求不要删除，标成 deprecated 并写明替代版本。
• [ ] 检索接口默认过滤 status=active。
• [ ] 把“当前对话最新指令优先”写进系统提示词。
• [ ] 按项目、客户、任务类型做权限隔离，防止串库。
• [ ] 为活动、报价、排期这类内容设置明确的 valid_until。
• [ ] 给冲突内容设计追问机制，禁止模型擅自折中。
• [ ] 每周抽查 20 个真实问题，看看召回结果里有没有过期指令。

常见坑：很多团队就是在这里掉坑里

1. 只更新文档正文，不更新状态

你在文档顶部写了一句“以新版为准”，然后把旧内容原封不动留着。

对人类来说，这句话够了。对检索系统来说，旧句子依旧会被切块、向量化、召回。它根本不知道哪段该退休。

**解决办法：**状态要做成结构化字段，别只靠自然语言备注。

2. 版本号有了，替代关系没了

V4 不一定覆盖 V3 的全部内容。有些要求保留，有些要求推翻。

**解决办法：**记录 supersedes 和变更项。别让系统靠猜。

3. 把聊天记录当永久真相

群聊里一句“先按这个试试”，可能只是临时想法。你把它直接入库，三个月后 AI 还会把它奉为圣旨。

**解决办法：**聊天记录进入知识库前，加一道确认流程。未确认内容标记为 draft。

4. 只测“有没有检索到”，不测“有没有检索错版本”

很多 RAG 测试集只问：答案对不对。

更该加一道题：答案引用的是不是当前有效版本？

因为 AI 偶尔能靠常识答对，底层检索却早就乱了。等问题换个问法，翻车就来了。

判断你的系统有没有“旧指令病”

拿下面 3 个问题去测：

1. 用户改了一个要求后，旧要求会不会还出现在下一次召回结果里？
2. 两个版本有冲突时，系统能不能明确说出它选了哪一个、为什么？
3. AI 不确定当前版本时，会不会主动追问，而不是硬编？

三个问题里只要有一个答不上来，你的知识库就还在靠运气工作。

模型能力当然重要。可对真正落地的 AI 应用来说，记忆该留什么、该忘什么，往往更决定结果。

别再让 AI 抱着 V1 的圣旨，去干 V4 的活了。