随着内存的增长，您的 RAG 肯定会出错 – 我构建了阻止它的内存层

TL;DR:

纯 Python 中的受控四阶段实验，具有真实的基准数据。没有 API 密钥。没有 GPU。运行时间不到 10 秒。

随着内存从 10 个条目增加到 500 个条目，准确度从 50% 下降到 30%

在相同范围内，置信度从 70.4% 上升至 78.0% — 您的警报永远不会触发

修复了四种架构机制：主题路由、重复数据删除、相关性驱逐和词汇重排序

50 个精心挑选的条目优于 500 个累积条目。约束就是特征。

不应该发生的失败

我对具有长期记忆的客户支持法学硕士进行了一项对照实验。

没有其他改变。不是型号。不是检索管道。

起初，它运行得很好。它以近乎完美的准确度回答了有关支付阈值、密码重置和 API 速率限制的问题。然后系统继续运行。

每次交互都被存储：

会议记录

入职清单

内部提醒

运行噪音

全部与实际答案混合在一起。

三个月后，有用户问：

“如何重置用户帐户密码？”

系统响应：

“VPN 证书将在 30 天后过期。”

置信度：78.5%

三个月前，正确时：

置信度：73.2%

系统并没有变得更糟。在犯错的同时，它变得更加自信。

这里，78.5% 是单次查询的置信度，75.8% 是 10 次查询的平均值。

为什么这现在对您很重要

如果您正在构建以下任何一项：

随着时间的推移累积检索到的文档的 RAG 系统

具有持久内存存储的 AI 副驾驶

记录过去交互的客户支持代理

上下文在会话之间增长的任何 LLM 工作流程

这种故障模式很可能已经在您的系统中发生。您可能还没有测量它，因为应该警告您的信号 - 代理信心 - 正在朝着错误的方向发展。

代理并没有变得更笨。它越来越自信地错误了。标准检索管道中没有任何东西可以在用户之前捕捉到这一点。

惊喜（在编写代码之前阅读此内容）