AI 查到了新文档，为什么还拿旧规定回答？
新文件进了知识库，旧规则却未必退出。用一个虚构的园艺工作坊，拆开发布时间、生效时间与入库时间，讲清 RAG 怎样选择当前规则，又怎样保留历史答案。
假设你报名了一个 demo 园艺工作坊，问它的 AI 助手：“八月这场还要自带工具吗？”
助手回答：“需要，请准备小铲子和手套。”后面还认真附了一份参加须知。你点开，确实写着自带工具。可工作坊六月就发过新通知：七月一日起，工具由现场提供。那份新通知也已经上传到知识库。
这个工作坊、规则和日期都是为解释问题构造的例子。它让人不舒服的地方在于，AI 并没有凭空编一句话。引用是真的，文字也读对了，只是引用的那条规定已经不适用于八月。
我现在看这类答案，会先把“有没有依据”和“依据是否适用”分开。前者防止模型胡说，后者决定这句话能不能拿来办眼前的事。给答案加上引用，还没有走完后半步。
新文件进来了，旧文件未必退场
RAG 的基本做法，是先找资料，再把找到的内容交给模型回答。如果知识库采用最简单的追加方式，新公告来了就切成片段、建立索引，那么老公告仍然留在里面，拥有继续被选中的机会。
在工作坊的例子里，旧须知可能写得特别完整：“参加园艺工作坊需要带哪些工具？”新公告却只写：“自七月一日起，相关器材统一提供。”旧文与用户问法更接近，新文又需要前后文才能看懂。最终谁排在前面，要看检索系统，但不能指望“较新”这件事自动赢得比赛。
甚至两份文件都被找到了，问题也未必结束。假如片段丢了标题、日期和适用范围，模型看到的就只是“需要自带”和“统一提供”。我们把辨别依据拿掉了，又希望它猜出哪句算数。
NAACL 2025 的 ERASE 研究正是从入库环节着手：新文档加入时，尝试删除或改写已有知识条目，而不只改善回答时的检索和推理。这里借用的是它提出的问题意识，不把特定实验里的收益当成任何知识库都能复制的保证。
来源：Language Modeling with Editable External Knowledge
这与模型训练后丢掉旧本领不同。权重可以完全没变，只是外部材料里同时放着前后不兼容的说法。也与直接拿出上一次完整回答的缓存不同：系统可能真的重新查了资料、重新组织了答案，仍然选错规则。
一份公告，至少有三只钟
先把工作坊的新通知展开：六月二十日发布，七月一日开始执行，负责维护资料的人到七月三日才把它录入系统。
这三个日期回答不同的问题。发布时间告诉我们何时公开说了这件事；生效时间告诉我们哪场活动该照它做；入库时间告诉我们系统什么时候才有机会查到它。把任意一项叫成“最新时间”，都容易遮住另外两项。
六月二十八日的活动仍要自带工具，虽然新公告已经发布。七月二日的活动应该提供工具，但系统如果只知道旧文件，就可能答错。等七月三日补录以后，不能反过来说“新规从今天才算生效”。
我会给这类条目单独记录生效起止时间，另外保留文档发布和系统处理时间。范围的边界也要写清楚：如果新规从七月一日零点起生效，旧规到这一刻结束，两者就不该在交界处同时算有效。
数据库里已经有表达这类区间的基础工具。PostgreSQL 的范围类型支持日期、时间戳，以及包含或排除端点的写法。不过它只能准确保存我们给出的边界，不能替我们判断一份公告真正从哪天实施。
还有一个更隐蔽的情况：六月那份旧须知八月被重新排版，文件修改时间于是变成八月。如果直接按修改时间取最新，它反而会压过七月已经执行的新规。版式变新，内容的适用期并没有随之延长。
先找到“该用的那堆”，再比较“最像的那篇”
假如我来整理这个助手，会先让系统知道用户问的是哪类活动、哪个场次、哪一天，再决定哪些资料有资格进入候选集合。
例如八月的普通班，只保留用户有权访问、覆盖该活动类别、且在目标日期有效的规则。接下来再按问题相关性找具体段落。顺序的用处是：过时文件即使措辞再像，也不能因为高分重新拿到资格。
这不需要把所有事情都交给向量判断。Pinecone 文档展示了把元数据条件与语义搜索结合的方法；Azure AI Search 也提供向量查询的筛选机制。这些是实现筛选的工具，至于“哪种班适用哪份规则”，仍然要由资料和应用定义。
来源：Pinecone 元数据筛选、Azure 向量查询筛选
筛选放在哪里也有区别。先从整个库取五个最相近片段，再删掉其中四个过期条目，只能剩一个；它不能证明库里只存在一个合格片段。Azure 的文档也提醒，某些后置筛选方式在筛选严格或候选数少时可能漏掉结果。这里没有通吃所有系统的参数，至少要知道自己是在合格集合里找，还是找完以后再删。
“目标日期”还不一定是今天。用户说“下个月的场次”，就要核对下个月是否已有确定生效的新规。用户只问“要带工具吗”，而几个班的规则不同，先确认场次会更有用。当前时间写进提示词，并不能补上缺失的活动对象。
还有一步发生在资料切块的时候。整份公告的日期写在第一页，工具说明却被切到第三个片段；如果入库时只保存片段正文，搜索阶段就算想筛选，也没有字段可用。给模型补一句“注意时效性”救不了已经丢失的日期。应当先检查每个片段是否继承了那份公告的适用条件。
但继承也要有依据。文件名叫“七月版”，可能只是整理月份，不代表七月一日生效。系统拿不准时，应该把日期标为未知，保留原文位置供人确认。填一个看似合理的时间，反而会让后面的精确筛选稳定地做错事。
新旧冲突，不能永远靠“新的优先”
继续扩展这个假设：七月新规只覆盖普通班，另有进阶班仍要求自带专业剪刀。两份文件不是互相作废，而是各管一部分。
如果只保存一个“当前最新版本”，就会把进阶班的有效说明一起挤掉。版本必须属于某个明确的规则对象。普通班的工具规则更新，并不意味着所有活动须知都更新了。
再假设八月有人上传了一篇参加者的体验笔记，说自己带了工具。它发布日期更晚，也提到同一场活动，但不能据此撤销主办方正式公告。材料是谁发布的、有没有权限修改规则，需要和时间一起看。
我倾向于在整理时明确标出替代关系：这份通知替代的是哪个条目，替代其中哪一部分，从哪一天开始。原文没有说清的地方，就保留为待确认，而不是让模型凭“看起来像更新”自动宣布旧规失效。
一个常见反例是补充通知：“因场地调整，本周改在东门集合。”它更新的是集合地点，不是工具要求。若整份旧须知因此退出，交通、年龄限制和注意事项可能一起丢失。需要细到什么程度，取决于规则如何变化，不是切块越小越好。
切得太碎也会出事。只留下“统一提供”四个字，连提供什么都不知道。更稳妥的片段应保留可独立理解的内容，并继承来源、规则对象、版本和有效期。这样以后更新时，才能定位哪些片段属于同一份旧说明。
旧规则退出当前回答，不等于抹掉历史
八月的新用户问“这场要带工具吗”，应该得到新规。另一位用户问“为什么六月那场让我自带”，则需要六月的旧规。两个答案不同，都可以正确。
因此我更愿意把“当前可用”与“历史留存”分开。旧材料可以退出默认的当前规则检索，同时在有权限的历史查询里保留。直接把全部旧文件删除，虽然暂时减少冲突，却可能让后来的人无法解释过去发生的事。
这里还可以再问得细一点：“七月二日按规定应该怎样”，与“七月二日系统当时掌握了什么”，不是同一个问题。前者按真实生效时间查，后者还需要当时的入库记录。维护者七月三日补录，能纠正以后答案，却不能证明系统前一天已经知道新规。
SQL Server 的系统版本化时态表可以保留行的历史状态；它记录的是数据库事务对应的时间。因此，即使采用这种现成能力，也不能把数据库行变化的时间直接当成公告的业务生效日。这两层记录各有用途。
当然，不是每个个人资料助手都需要完整的历史系统。如果只回答当前的公开操作说明，一份维护清楚的当前版本清单就可能够用。真的需要回溯再保留历史，避免为一个简单问答先造一套沉重的档案馆。
对于更新频繁的资料，我还会保留一次更新涉及的条目清单。假设旧须知原来切成六段，新版只有四段，只覆盖写入前四段，就可能留下两段无人认领的旧内容。它们没出现在新文件里，却仍躺在检索库中。维护时需要能沿文档标识找到全部旧片段，而不是只盯着新文件导入成功。
反过来，更新失败时也不能随手把所有东西恢复到旧版，再继续宣称“当前有效”。如果现实中的新规则已经生效，旧索引只是技术上还能用，事实仍然过时。可以暂时说明资料正在更新，或回到可核验的原始公告；恢复服务与恢复正确事实，需要分别检查。
验收时，别只问一道“现在是什么”
新规上传之后，我会保持问题措辞基本不变，只切换活动日期。六月二十八日应该自带，七月一日起应该提供；再切换普通班与进阶班，检查例外有没有被吞掉。这样检查的是规则选择，不只是模型能否复述新文档。
还会故意调整文件的排列顺序，把旧说明放前面，把新说明放后面，或重新上传一遍旧文。如果答案随文件位置、导入顺序改变，就要回头看版本和生效条件究竟有没有真的参加筛选。
维护动作也要留一点验证时间。Pinecone 文档说明其数据可见性采用最终一致性，新建或修改资料后，查询可能稍有延迟。这个具体系统的提醒，也给出一条通用的验收思路：收到写入成功的响应以后，再实际检索，确认目标版本已经可见、旧版本已经按预期退出。
如果两份同样正式、同样有效的文件仍然冲突，我希望助手把冲突说出来，并指明需要确认的地方。把两种要求揉成一句折中话，比如“建议自带，但可能提供”，看着圆滑，却可能只是掩盖资料没有整理好。
回答里也不必展示整张元数据表。一句“按七月一日起执行的普通班说明，现场提供工具”，就足以让用户知道结论用了哪条规则；有历史问题时，再说明当时版本。依据应当帮助人判断，而不是只在句尾挂一个链接。
我觉得知识库最容易被低估的工作，是决定哪些内容还该被当成现在的事实。资料越积越多以后，继续上传很容易，认真让旧规则退场才更需要人把关。AI 能查到一句话，只是起点；它还得知道，这句话到底管哪件事、哪一天。
评论