Agent-memory-摘要评估中的覆盖率以及可用性

随着记忆的增加，如果不对记忆进行压缩形成摘要，那么检索的速度只会越来越慢，假设记忆库中有10条记忆时，检索的时间是10ms，那么增加到110条时，检索时间大概就是110ms，而在实际的使用中，记忆库动辄就会达到几十万几百万的量级，要是真的这么慢，那agent也不会有人用了。

关键点与关键词

在用代码实现摘要的过程中，有一些可能会令人混淆的概念，记忆摘要生成时的关键点以及摘要质量评估时的关键词。这两个听起来差不多，但是实际的逻辑却完全不一样。前者是agent用聚合原理，将相同主题或者相同会话的记忆聚合为一个个簇，每个簇摘要形成内容、来源、压缩率，关键点和时间。这里的关键点是LLM根据记忆内容提取出来的关键点，比如做了数据报告，学习了数据分析等。

而摘要质量评估中的关键词，主要是用在评测摘要对于来源中记忆的覆盖率检测。这里的关键词是我们在学习RAG中粗排的关键词匹配，是直接分词后做的关键词提取，防止摘要过于抽象而忽略一些细节，比如摘要里说浪费了大量token，但是这个给人的感觉，其实是可以在接受范围里的，无非就是成本大一点，但是如果换成几十万token，那这就是一场事故了，需要引起重视。

可用性

在质量评估中，通过检查摘要形成的长度来判断可用性，通俗点说就是形成的摘要要适中一些。这听起来有点反直觉，因为从字面理解，可用性应该是在后续的检索召回中对用户提问来说有没有用。

但实际上，这个是从形成摘要的出发点来理解的。我们一开始想要形成摘要不是为了更便捷地储存信息，毕竟，除了检索速度变慢以外，无论是什么形式的压缩，都会或多或少地丢失信息。所以最直观的就是，要减少记忆所花的空间的同时保留有用信息。那么长度其实就能透露这个重要的细节，太短的摘要，不管怎么概括，怎么浓缩，受到篇幅的限制，怎么都做不到完美，就像限定了只能用一百个字来概括一份报告，就是会比四百字的概括少很多细节。而比较长的摘要，在检索召回时又会挤占很多上下文窗口，还是会降低很多检索速度，既然如此那还不如不压缩。