自动摘要错误地将最新的后续提示视为原始用户请求

说明

当一个长期运行的代理会话达到上下文限制,并被 Crush 自动摘要化时,续行提示可以错误地将最新的用户后续消息识别为原始任务.

就我而言,最初的任务是一个编码/货币调试请求。 在运行中,我后来打断了代理,因为其中一项测试被吊死,并发出类似以下的后续信息:

你的测试一直坚持下去 增加超时.

自动总结后,Crush恢复使用:

前一个会话由于时间太长而中断,最初的用户请求是:"你的测试永远卡住. 添加超时。

这是不正确的。 这一信息只是后来的后续指示,而不是最初的任务。

概要本身仍然包含了关于原始编码任务的有用上下文,但新的合成用户提示,然后围绕后续信息重新设定会话. 该模型随后开始将超时处理作为主要目标,而不是继续原任务.

预期行为

总结后,粉碎应保留原任务目标.

例如,它可以:

利用摘要上下文继续前次任务。

或者,如果它想重复原始用户请求,它应该从会话中检索实际的第一个/根用户提示,而不是重复当前运行中相关的提示.

实际行为

延续快取由当前会话代理Call所建. 快点

在I测试的版本中,相关代码是有效的:

电话 提示 = fmt. (中文(简体) ). 冲刺f(
"前会话由于时间过长而中断,最初的用户请求是:"'s'",".
电话 即时
(中文(简体) ).

因此,如果当前运行是由后续消息启动的,该后续被误贴为"初始用户请求".

这可以悄悄地改变长期代理会话的目标.

一个典型的序列是:

用户: 最初的复杂任务 助理:工作一段时间 用户:小更正/"接续"/"添加超时" 助理:继续 达到上下文限制 粉碎:总结 粉碎:声称小后续是最初的要求

模型然后看到两个相竞的信号:

摘要-描述真正的原始任务 新合成用户提示 ~ 说后续是最初的任务

由于合成快件较新,并作为用户信息呈现,该模型可能优先排序并偏离实际目标.

可能的补救

而不是使用当前调用. 迅速,要么:

获取会话的根/ 第一个用户消息, 或 避免完全重复原请求并依赖生成的概要.

大致如下:

前一届会议由于时间过长而中断。 利用上文概述的背景继续开展这项工作。

避免意外地覆盖任务目标。

翻译:

页:1

环境

费多拉 KDE 45