几周前，我正在测试一个支持代理设置——没什么花哨的，只是一个
附加了记忆层的大语言模型，以便它能够在不同会话中记住关于用户的基本事实
。订阅层级、收货地址，诸如此类的事情。
我运行了一个简单的场景：用户已经处于企业版套餐中。我
确认记忆检索功能正常工作——当我查询“用户的订阅属于哪个层级”时，事实 subscription_tier: 正确返回。
enterprise
然后，我以支持聊天的提示风格询问代理，用户当前使用的是哪个套餐。
回复如下：
“当然，升级到我们的企业版套餐将为您解锁该功能。”
用户已经处于企业版套餐中。代理在其上下文中拥有正确的事实。它只是……错误地使用了它。并不是“忘记了”——
那是另一种更常被讨论的故障模式。这种故障在特定方面更糟糕：检索成功，事实已注入，但回复仍然自信地错误。没有任何明显的失败迹象。没有任何报错。如果我没有亲自盯着原始上下文看，除了事后由困惑（或恼怒）的用户告诉我之外，我将无法知道发生了这种情况。
我开始研究流行的记忆框架如何处理这个问题——Mem0、
Zep、Letta，以及那些常见的框架。它们都在解决实际问题：存储、
检索，以及随着时间推移事实发生变化时的矛盾处理。特别是 Zep 在
时间准确性基准测试中表现良好。
但据我所知，它们都没有检查在我的测试中实际出错的地方：大语言模型的回复是否真正反映了为其检索到的记忆？ 我查看的每个框架似乎都假设一旦事实进入上下文，模型就会正确使用它。我的测试表明，这一假设并不总是成立。
所以现在我很想知道其他人观察到了什么。如果你在生产环境中运行带有某种持久性记忆的代理——
- 你是否实际检查过你的代理是否正确使用了检索到的事实，还是你仅仅相信只要检索正常工作，回复就会正确？
- 有没有人构建过能够捕捉此类问题的工具——不是“检索是否返回了正确的事实”，而是“回复是否真正反映了该事实”？
- 这是一种我已知的、有名称的故障模式，只是我之前没听说过，还是大家基本上都……不去检查？
真诚发问——我已经深入研究这个问题一段时间了，我不确定
我是发现了一个讨论不足的问题，还是对一个众所周知的问题反应迟钝。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
