知识时效路由：在生产 AI 中将查询匹配到正确的时间层

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。

生产 AI 系统没有单一的知识存储。它们同时在四个不同的新鲜度层级上承载知识：冻结的参数化权重、定期索引的向量嵌入、会话内的上下文状态，以及实时工具检索。每个层级都有不同的成本、延迟和过时特性。将查询路由到错误的层级——即使该层级返回了听起来十分自信的答案——是一种无声的可靠性故障，比直接的幻觉更难被发现。

四个时序知识层级

理解路由问题，首先需要了解每个层级的实质。

参数化知识是在训练期间嵌入模型权重中的全部内容。它是训练语料库所反映的世界在某一时刻的冻结快照，被压缩成数十亿个浮点参数。你无法查询其新鲜度——没有时间戳，没有版本号，也无法询问"这个事实有多旧？"模型本身也不知道。更糟糕的是，当问题使用相对时间参照（"4 年前"）而非绝对参照（"2020 年"）时，对时间敏感查询的准确率会下降 23–35%——因为相对参照要求模型知道现在是什么时候，而这正是它根本无法做到的。

向量嵌入（即你的 RAG 索引）使模型能够访问更新且特定领域的文档，但它们有自己的过时问题。大多数生产系统的刷新周期为 48 小时到一周。检索器按语义相似度而非时效性对文档进行评分。一份相似度评分 0.91 的过时文档，会胜过一份评分 0.87 的最新文档。正如一个工程团队所描述的，检索器对内容是否仍然准确"完全视而不见"。追踪企业 RAG 部署的研究发现，60% 的项目失败源于时效性管理失误，而非通常意义上的幻觉。

会话上下文是上下文窗口中的内容：对话历史、检索到的段落、本次会话的工具输出。对于在当前交互过程中建立的事实，它是最可信的来源，但随着长度增加会逐渐降级。对生产规模上下文窗口的研究发现，所有测试的模型都随着上下文增长而出现准确度下降，有些模型的有效窗口远低于其宣传的最大值。将上下文窗口视为可靠的永久记忆——用文档塞满它而不是使用选择性检索——只会加剧问题。

实时工具检索是在请求时同步调用 API 或网络搜索。它以最高成本提供最高新鲜度：延迟、API 依赖关系，以及上游服务不可用时的故障模式。但对于答案每小时或每天都在变化的查询类别，这是唯一真正正确的层级。

按时间敏感性对查询分类

这些层级之间的差距足够大，以至于路由决策必须是明确的。发送到错误层级的查询不会可见地失败——它会返回一个自信陈述的错误答案。

按时间敏感性对查询分类大致如下：

历史/静态查询可以安全地从参数化知识中回答。"TCP/IP 是如何工作的？""法国的首都是哪里？""《哈姆雷特》的作者是谁？"这些答案多年来保持稳定。对它们使用实时检索是浪费；模型已经知道答案。

每周过时度可接受的特定领域查询属于 RAG 层级。"我们的内部 API 规范对认证有什么要求？""这个库当前的配置选项有哪些？""数据库连接池的最佳实践是什么？"对于这些问题，参数化答案可能已经过时或过于泛化，但每周索引的内部文档或技术文档就足够准确。

快速演变的查询需要实时检索。"TSLA 现在的交易价格是多少？""美联储今天早上宣布了什么？""这个 API 端点当前是否返回 200？"任何答案可能在数小时内改变的问题都属于这里。将这些查询路由到每周索引的 RAG 存储，必然会产生过时的答案。

多时序查询是最棘手的情况。"与上季度的预测相比，我们的云支出如何变化？"可能需要参数化知识（用于一般财务推理）、RAG 嵌入（用于内部预算文档）和实时工具调用（用于当前账单数据）。这些查询需要明确的多层路由和一个协调步骤——而不仅仅是单次检索。

当层级不一致时

更深层的问题是，当咨询多个层级并且它们相互矛盾时会发生什么。关于 LLM 中知识冲突的研究发现，模型在这方面处理得很糟糕。当参数化记忆和检索到的上下文直接冲突时，模型不会推理矛盾——它要么忽略上下文并默认其参数化信念，要么盲目遵循提示中的内容。包括 GPT-4、GPT-3.5 和 LLaMA-3 在内的模型，在被要求检测知识来源之间的矛盾时，表现仅比随机稍好。

这很重要，因为多层流水线会常规性地产生矛盾。考虑一个合规查询：

• 参数化知识说：GDPR 要求数据处理协议包含 X、Y、Z 条款（基于 2022 年指南训练）。
• RAG 说：GDPR 执法已扩展为包含 W 条款（来自去年法律文件的索引）。
• 实时检索说：欧盟上周发布了增加 V 条款的最新执法指南。

没有协调策略就咨询所有三个层级的系统，要么任意选择其中之一，要么不一致地合并它们，或者——最危险的情况——以完全的自信返回最高分的参数化答案，尽管有两个相互矛盾的更新。

失败是无声的。没有错误，没有异常，没有低置信度标志，只是一个自信陈述的响应，反映的是两年前的世界。

构建路由层

路由逻辑应该是明确且可检查的，而不是从提示工程中涌现出来的隐式行为。

将查询分类作为第一步。 在将查询分发到任何知识来源之前，先按时间敏感性对其分类。这可以是一个轻量级分类器，一组小型启发式规则（查询是否包含时间敏感信号，如"当前"、"现在"、"今天"、"最新"、"本周"），或者一个专用路由模型。关键纪律是使这种分类明确且记录在案，这样你就可以审计系统在生产中做出了哪些路由决策。

对所有检索内容添加时效性元数据。 RAG 索引中的每个文档都应携带 last_indexed 时间戳，以及在可能的情况下携带 valid_as_of 或 source_updated 时间戳。对于时间敏感的查询类别，检索评分应该融入时效性因素——六个月前的文档在"当前政策"查询上的评分，应该低于在"历史背景"查询上的评分。

按信息类型设置明确的过时阈值。 并非所有信息都有相同的可接受保质期。金融数据：数小时。监管指南：数天到数周。内部技术文档：数周。通用工程最佳实践：数月。你的路由策略应该编码这些阈值，并在检索到的文档超出该查询类别的阈值时，升级到更新鲜的层级。

多层查询的协调步骤。 当查询需要咨询多个层级时，将综合步骤视为独立操作——而不是基础 LLM 隐式完成的事情。按查询类别的时效性对来源进行排序。明确呈现矛盾（要么到更高层级的协调模型，要么在适当时候呈现给用户）。KCR 框架（知识冲突解决）表明，在生成最终答案之前明确推理矛盾，相比让模型掩盖不一致性，能显著减少错误。

运营过时度监控。 过时度是一个可靠性指标，而不仅仅是数据工程关注点。按文档类别追踪 (距上次索引更新的时间) / (可接受的更新频率)，就像追踪错误率或延迟一样。当过时度超过阈值时，要么触发刷新，要么降低该领域答案的置信度。彭博社的金融 RAG 团队发现，向量衰减是他们主要的质量瓶颈——而这一发现来自监控，而非用户投诉。

值得预防的失败模式

时序路由失败最危险的特性是它们看起来像成功。基于过时的参数化或 RAG 知识的自信错误答案不会产生任何警报、异常或对用户可见的信号。模型返回了听起来合理的内容，只不过它恰好反映的是一个已不复存在的世界。

这里的运营纪律与大多数 AI 系统的构建方式相悖。它要求将知识新鲜度视为第一类系统属性——配备 SLA 级别的监控、明确的路由策略和协调逻辑——而不是假设模型检索到的任何内容都足够新鲜。

研究表明，对于时间敏感查询，实时 RAG 集成相比静态知识库，幻觉率降低了 40–60%。这个数字足够高，以至于忽视时序路由是一种蓄意接受大幅准确性惩罚的选择。对于大多数生产应用来说，这是你无法继续承受的代价。

修复在技术上并不困难。一旦分类是明确的，路由逻辑就很简单。困难在于组织纪律：接受你的 AI 系统的知识有其年龄，不同的查询类型有不同的年龄容忍度，路由到错误的年龄层是一种可靠性失败——不是检索问题，不是提示工程问题，也不是用更大的上下文窗口就能改善的事情。