尝试使用Jev来检查代理应该记住什么

我们一直在尝试使用Jev来处理代理记忆，主要是为了捕捉保存的笔记比原始对话内容更多的情况。想象一下，“我们可能使用Postgres”变成了“我们选择了Postgres”。一旦保存，下一次对话就会从一个没人实际做出的决定开始。我们将原始文本和提议的记忆交给Jev，然后使用其判断来决定是保存、跳过还是留待决定。我们使用相同的设置与Luna进行比较。在100个合成案例中，使用0.40的阈值，Jev保留了50个标记为值得保留的记忆中的39个。Luna保留了41个。两者都没有保存标记为跳过或延迟的候选记忆。中位筛选延迟，Jev为250毫秒，Luna为1,593毫秒，包括网络时间。然后我们检查了当这些记忆被使用时的情况。我们选择了20个后续问题，让Luna在所有条件下回答。相同的读者，相同的问题，不同的可用记忆。保留所有候选记忆导致了10个错误答案。使用任一过滤器时，这些问题中错误答案为零。但使用Jev的过滤器时，尽管原始文本中有答案，但有8个问题未得到回答。使用Luna的时，有10个。一个分歧是关于谁当前拥有发布清单。Luna认识到提议的记忆有来源支持，但拒绝了它，因为它认为信息是临时的。对于项目助手，我仍然期望它记住这一点，至少直到所有者改变。这让我们怀疑，“以后有用”的想法是否需要区分持久的偏好和对未来几个任务有用的项目细节。还有提议的记忆确实错误的情况。丢弃它可以防止该错误传达给读者，但不会给读者一个更正的版本。我们的测试没有回到来源并重试的步骤。一些值得提及的限制：案例和标签是AI编写的，没有独立的人工审查。我们在看到早期Jev结果后选择了20个后续问题，所以这不是一个盲测。每个示例只有一个候选记忆，而不是完整的记忆系统。使用相同的置信度阈值并不意味着两个模型的得分校准方式相同。我们将其视为需要进一步调查的事情，而不是选择一个模型而不是另一个的原因。对于任何构建记忆系统的人，当提议的记忆在你的设置中未通过检查时会发生什么？你是直接丢弃它，保留来源，还是尝试提取新的记忆并再次检查？