你的上下文流水线需要一份新鲜度 SLA

你的智能体（agent）用上个季度的价格回答了客户的计费问题，复盘报告会将此归咎于模型。但不应该如此。Prompt 组装正确，检索评分很高，模型对所给的所有信息进行了合理的推理——而所给的一切在三天前都是真实的。在 CRM 导出、文档同步和向量索引重建之间的某个环节，“世界的当前状态”悄然变成了“截至周二的世界状态”，而你的技术栈中没有任何环节在衡量这种差异。

数据工程师在几年前就解决了这类问题。一个消费十张上游表的下游仪表板拥有血缘关系（lineage）、新鲜度检查以及一个在夜间任务出错时进行呼叫的轮值机制。你的智能体所消费的上下文窗口也是同样的东西——一个由文档、工单、代码、CRM 和记忆连接而成的物化视图（materialized view）——只不过没有人负责这个连接（join），没有任何东西衡量它的陈旧度，当它提供昨天的真相时，失败却被归类为“模型幻觉”。

上下文窗口是一个物化视图

剥离掉 AI 词汇，看看上下文组装到底在做什么。在请求时，编排器从几个上游系统中收集行——来自向量库的一段文档、来自 CRM 的客户记录、来自支持系统的最新工单、来自记忆库的先前对话摘要——将它们连接成一个去正规化的 blob，并提供给消费者。这就是一个物化视图。它有数据源、刷新策略（或者缺失刷新策略），以及一个完全信任它的消费者。

数据库的比喻并非装饰性的，而是具有诊断意义的，因为物化视图的每种失败模式都会在上下文流水线中出现：

• 陈旧读取。 视图在源数据更改之前刷新。你的文档在周日晚上重新嵌入，而定价页面在周一早上发生了变化。
• 不一致连接。 不同的源反映了不同的时间点。CRM 记录显示客户已升级，但使用数据早于升级。智能体基于一个从未真正存在过的世界状态进行推理。
• 血缘断裂。 源系统重组了其架构——有人重构了文档站点，重命名了 Confluence 空间——而视图悄无声息地提供不再指向任何内容的片段。
• 没人负责刷新。 文档团队负责文档。平台团队负责向量库。智能体团队负责 prompt。中间的连接（即模型实际读取的东西）不属于任何人。

数据库通过刷新策略、快照隔离和依赖跟踪来处理这些问题。而上下文流水线大多靠“希望”来处理。

陈旧度对你的检索器在结构上是不可见的

这就是为什么它比普通的数据质量问题更糟糕：检索层对时间是盲目的。语义相似性不会随着事实的过时而衰减。一个废弃的 API 参考的嵌入（embedding）得分与当前的完全一样高——通常甚至更高，因为旧文档有更多时间被链接、重复并被改写进语料库。如果上季度的政策文档的措辞碰巧更接近查询，它就会排在本季度更新的文档之前被检索出来。

这意味着陈旧度不会让你的系统优雅降级。它会静默且自信地失败。没有错误日志条目，没有检索缺失，也没有置信度下降。在第一天用错误答案关闭了 40 张支持工单的智能体——这是一个真实的事件模式，由源文档重组后三天未刷新的索引引起——它在损坏的上下文之上进行了“完美”的推理。技术栈中的每个可观测性工具都显示为绿色。

随着规模的扩大，问题会变得更加复杂。一个包含一千个文档的知识库可以通过简单的全量重建保持亚小时级别的新鲜度。在十万个文档时，同样的架构会产生半天的陈旧度。在一百万个文档时，重建耗时太长，以至于多天的陈旧度变成了常态。在试点阶段有效的架构，正是那些在生产环境中悄然腐烂的架构。

一个令人不安的重构认知：被归类为“幻觉”的问题中有很大一部分根本不是幻觉。模型忠实地报告了上下文库告诉它的内容。上下文库提供的是昨天的真相。因此而归咎于模型，就像因为 ETL 任务没运行而归咎于仪表板一样。

借鉴数据工程的方法论

这都不需要发明新的学科。分析团队花了十年时间构建的正是上下文流水线所缺失的机制。有四个部分可以直接迁移。

血缘关系：了解什么喂给了窗口

对于你的组装器可以注入的每一类上下文，你都应该能够回答：它来自哪个源系统，上次同步是什么时候，中间经历了什么转换？如果智能体引用了一个价格，你应该能够通过该片段（chunk）、嵌入任务和源页面追溯到该 token——并在每个环节都打上时间戳。大多数团队现在还做不到这一点，这就是为什么上下文复盘需要几天时间：根本原因很少是一个损坏的东西，而是略微陈旧的索引、重组后的源数据以及从未预料到这两者的 prompt 共同作用的结果。

加载中…