AI系统的"失忆"问题不是模型缺陷，而是基础设施缺陷
有一个场景，人工智能产品团队再熟悉不过。用户花了二十分钟与一个助手建立上下文：预算、饮食限制、无法更改的日期、家人的偏好。然后，三轮对话之后，系统的表现仿佛那段对话从未发生过。用户联系客服支持。客服将问题升级至产品团队。产品团队联系模型供应商。而模型供应商则有理有据地回应：他们的模型运行完全符合设计规范。
因为模型没有遗忘任何东西。模型从一开始就从未获取过那些信息。
这种区别看似技术性且微不足道，但一旦你计算出它的代价，就会改变看法。企业级助手中每一次连续性失败，不仅仅是用户体验上的摩擦：它意味着系统在要求模型进行推理之前，已经错误地重构了世界。当这种模式在每天数千个会话中不断重复，其代价就不仅仅体现在客服资源的消耗上，更体现在失去的信任、被放弃的工作流程，以及永远无法实现的投资回报率上。
好消息是，这个问题有解决方案。坏消息是，大多数组织仍然不清楚真正的问题出在哪里。
模型是无辜的。管道才是罪魁祸首。
大型语言模型在设计上是无状态的实体。每一次API调用都是一个独立的数学事件。模型在各轮对话之间没有记忆，无法访问之前的会话，也无从知晓用户已经说过自己的预算是四千美元。模型在每一轮中看到的，恰好就是系统在那一轮发送给它的内容，不多也不少。
这意味着，所有连续性的假象——所有让助手看起来"记得"事情的表现——完全依赖于请求到达模型之前所发生的事情。这个过程有一个技术名称，并且具有越来越重要的战略意义：上下文管道。
一个构建良好的上下文管道在每一轮对话中执行三个阶段。第一阶段是"注水"（hydration）：从存储中提取相关历史记录、用户元数据以及捕获先前内容的向量嵌入。第二阶段是"组装"（assembly）：过滤这些原始材料，将其压缩并结构化为一个连贯的负载（payload）。第三阶段是"执行"（execution）：将编译好的负载发送至推理端点。当系统在模拟记忆方面出现故障时，故障发生在这三个阶段中的某一个，而非模型内部。
诊断此类故障的工程团队识别出管道最频繁断裂的四个区域。第一是检索不足：系统未能从存储中提取正确信息。第二是有损压缩：滚动摘要将精确的限制条件降级为毫无用处的泛泛之词。第三是上下文稀释：向模型发送过多材料，将相关数据淹没在噪音之中。第四是组装错误：信息块排序错误、缺少分隔符，或在用户的修正内容之前注入了过时的版本。
从用户角度来看，以上每一个故障区域的表现都是一样的：一个遗忘了被告知内容的助手。但它们指向的是技术栈中完全不同的组件。试图通过重写系统提示来解决检索故障，就好比给一台硬盘损坏的服务器增加更多内存。
将成功试点与长期停滞试点区分开来的真实架构
从一个在演示中运行良好的AI实施，跃升为一个在真实生产负载下依然稳定运行的实施，在很大程度上取决于为问题的每一层选择正确的内存架构。不存在万能的解决方案。每种方法都能解决一个瓶颈，同时制造另一个。
滑动窗口——只包含最后N条消息并忽略其余内容——是零基础设施的选项。可在数小时内完成部署。但它同时保证了：在一次长会话开始时设置的任何限制条件，都将从活跃上下文中消失。对于处理简短无状态事务的助手来说，这已经足够。对于任何依赖二十轮之前所建立条件来进行决策的企业工作流程而言，这是一个陷阱。
向量语义搜索部分解决了这个问题。系统不再抓取最后N条消息，而是对当前查询进行嵌入处理，并从数据库中检索历史上最相关的片段。当用户提出一个依赖于会话开始时所说信息的问题时，即使已经过了数十轮对话，向量搜索也能够获取到那些信息。其代价并不微小：它需要索引基础设施、排名阈值校准、时效性逻辑以及对检索性能的持续评估。向量数据库映射的是数学上的相近性，而非操作上的重要性。这种区别需要持续不断地调整。
向量搜索在结构上失效的地方，是硬性限制条件。最高预算、食物过敏、账号信息、合同SLA。这些信息不应该在语义相似度排名中与其他信息竞争。它们是系统必须能够在每一轮中确定性注入的事实，而不依赖搜索来检索它们。实体存储——一种将这些限制条件作为离散的、可更新字段存储的结构化数据库——以确定性检索解决了这个问题。如果用户将预算从四千美元修改为五千美元，后端更新的是一个特定字段，而不是在文本摘要末尾追加一条修正。模型始终收到正确的数字，因为信息的存储方式不存在任何歧义。
对于实体之间的复杂关系，基于图的检索增加了另一层精确度。如果系统需要知道用户的女儿对花生过敏、配偶偏好靠过道座位、父母需要一楼房间，语义搜索可能会检索到这三个事实，但会迷失于哪项限制适用于哪个人。图架构将这些关系作为实体之间的显式链接存储，并允许在检索期间遍历这些链接。运营开销相当可观，从本体设计到图的持续维护，但在医疗健康、旅行或金融服务等领域，由于限制条件本质上具有关联性，这种复杂性并非可选。
生产环境中最强健的架构将这些层结合在一个分级技术栈中：一个近期对话轮次的缓冲区，用于维持即时的对话流；一个向量层，用于处理会话事实和中期的关键节点；以及一个结构化数据库，用于存储用户配置文件和长期偏好。在此技术栈之上，一个上下文路由器根据消息类型决定激活哪些层。一条简单的确认消息不需要查询任何数据库。一个预订请求则会激活实体存储、近期历史记录和工具状态。目标不是尽可能繁重的管道，而是尽可能具有选择性的管道。
没有人构建的可观测性——直到系统在生产环境中出现故障
有一种模式重复出现的频率足以让人将其视为结构性问题。团队部署了一个助手，收到用户反馈说系统"不记得"内容，于是第一反应是重写系统指令。大写字母短语被添加进去："始终记住用户的预算"。行为没有改善。将模型升级到更昂贵的版本。行为仍然没有改善。最终，有人审查了故障发生时实际到达模型的负载，发现预算从未从数据库中被检索出来，或者虽然被检索出来但在组装前被过滤掉了，又或者虽然被包含进去了，但却被放置在一个三万个token的提示末尾——在那个位置，模型实际上并未对其进行有效处理。
上述每一种情形都意味着完全不同的干预措施。如果对管道在推理时刻的精确状态没有可见性，诊断就是在盲目猜测。而在AI系统中盲目猜测是有代价的：白白浪费的工程时间、无法解决任何问题的提示词迭代，以及在技术团队在技术栈的错误位置工作期间不断累积的用户信任损耗。
确定性追踪解决了这一问题。在推理之前的精确时刻，记录完整的编译提示，连同激活的路由决策和工具的原始输出。有了这种可见性，诊断问题就从"为什么模型表现如此"变成了"模型究竟收到了什么"。这就是有请求日志和没有请求日志的情况下调试微服务之间的区别。
离线评估对生产追踪起到补充作用。构建包含多轮对话的测试集——其中正确答案依赖于会话开始时建立的限制条件——可以在部署之前衡量系统是否正确检索并使用了这些数据。在此语境下真正重要的指标，并不是模型基准测试的那些指标：而是检索命中率、记忆召回精度、注入上下文的实际利用率，以及检索层的累积延迟。没有这些指标，团队优化的是那些在孤立测试中看起来不错的代理指标，但这些指标并不能预测完整系统的行为。
竞争优势不再在于你选择了哪个模型
随着前沿模型在推理能力上趋于收敛，差异化正在向围绕这些模型的基础设施转移。2023年部署了最大模型的组织，相比那些部署了更小模型但拥有更精确上下文管道的组织，已不再具有结构性优势。企业数据团队发布的研究显示，在没有结构化上下文的方案上运行的系统与拥有受治理上下文层的系统之间，在响应准确度上存在显著差异——这种差异是任何提示词调整都无法弥补的。
这对产品战略规划的意义不可小觑。首先，模型供应商的选择变得不如内存架构更具决定性。其次，在自有开放基础设施上构建了上下文层的团队拥有可移植性：他们可以在不重建知识表示的情况下更换模型。而那些将限制条件直接注入专有提示词的团队则不具备这种灵活性。第三，上下文治理——谁可以在什么条件下、以何种审计方式更新实体存储中的哪个字段——成为一个组织架构问题，产品团队无法无限期地将其委托给数据团队。
对于最终用户来说，感觉最有能力的助手，不一定是运行在参数最多的模型上的那个。通常，它是背后拥有最严格状态管理系统的那个。这就是表面智能与可在规模上持续实现的智能之间的区别。构建后者，需要以与任何其他关键基础设施组件同等水平的工程纪律来对待上下文管道：建立接口契约、模式验证、版本控制和持续可观测性。
那些继续将上下文故障诊断为模型故障的组织，将持续把投资砸向技术栈中最不需要它的那一部分。
