### Description / 描述 目前的上下文压缩配置,可以实现仅仅4种组合: - 历史轮次达到x轮或对话历史的token达到上限的82%时,丢弃最旧的y轮,并且保留最新z%token的历史 - 历史轮次达到x轮或对话历史的token达到上限的82%时,对最旧的y轮进行上下文压缩,并且保留最新z%token的历史 - 其中x可以配置为-1,隐式表示不限制轮次 实际上,刨除具体的数值配置,可能的组合存在: - 2种触发方式(达到特定轮次/达到token上限的x%) - 2种处理方式(丢弃最旧的特定轮次/压缩特定的最旧轮次) - 2种最低保留(保留特定的最新轮次/保留最新的x%的token) 至少存在2*2*2=8种组合。 如果能重构为更加细粒度的配置,设计的正交,就可以允许用户按需求自行配置上面提到的所有组合。 并且可能存在扩展需求,例如: - 更多的触发上下文压缩的方式(长时间,x分钟后对话没有继续 / llm识别到话题切换) - 更多的上下文压缩处理方式 (丢弃 / 压缩x分钟前的对话历史) - 更多的保留方式(保留最新x分钟内的对话) 这也方便后续扩展,或设计钩子,允许插件介入进行扩展 ### Use Case / 使用场景 更好的上下文压缩配置与管理 ### Willing to Submit PR? / 是否愿意提交PR? - [x] Yes, I am willing to submit a PR. / 是的,我愿意提交 PR。 ### Code of Conduct - [x] I have read and agree to abide by the project's [Code of Conduct](https://docs.github.com/zh/site-policy/github-terms/github-community-code-of-conduct). /
Description / 描述
目前的上下文压缩配置,可以实现仅仅4种组合:
实际上,刨除具体的数值配置,可能的组合存在:
至少存在222=8种组合。
如果能重构为更加细粒度的配置,设计的正交,就可以允许用户按需求自行配置上面提到的所有组合。
并且可能存在扩展需求,例如:
这也方便后续扩展,或设计钩子,允许插件介入进行扩展
Use Case / 使用场景
更好的上下文压缩配置与管理
Willing to Submit PR? / 是否愿意提交PR?
Code of Conduct