• yu1745

    # Codex最新滚动窗口上下文机制在GLM5.3测试报告

    ## 主要观察

    本次比较Pi Native 原生压缩、Pi Smart Compact 与 Codex滚动窗口的Pi实现 在DeepSWE Bench中表现。

    滚动窗口指的是在切换前保存 Notes,切换后读取检查点,必要时通过 History 回查旧对话,实现完全复刻自Codex开源代码,并加入了我对OpenAI服务端实现的猜测,因为OpenAI的服务端代码不开源。

    共有10项任务取得完整有效的三组结果,另有1项因滚动组异常而不计入总比较。以下结果仅适用于GLM 5.3,上下文召回场景受模型后训练影响非常之深,换一个模型需重测。

    - 滚动窗口的上下文重置次数更少,且多数任务耗时较短。 10项任务共轮换18次,对应Native压缩30次、Smart配置组压缩27次;滚动窗口在 6/10 任务中Agent耗时最短。猜测任务解决更快的原因是在切换上下文窗口时,滚动窗口机制相比压缩,上下文召回更快。

    - 完全未观察到滚动窗口导致普遍、明显的任务质量下降,部分场景反而更好。 相比Native,滚动窗口新增测试通过数为3项更高、6项持平、1项较低;相比Smart为4项更高、4项持平、2项较低。完整通过任务数为滚动窗口6/10、Native 4/10、Smart 4/10。反例包括HTTPX流式JSON与HTTPX multipart,说明滚动窗口并非每个场景都更好。

    - Notes通常足以完成恢复。 18次轮换共成功写入Notes 34次,只调用History 2次,说明模型通常不需要反复读取完整旧对话。所有有效三组的原有测试均全部通过,质量差异主要集中在新增需求实现完整度。

    每任务每方案仅运行一次,以上仍是小样本观察。Smart Compact配置为 auto,已核查到的Smart执行模式为 fast,同时存在回退及未标明Smart模式的事件,不能将其视为全部fast或纯EESV实验。

    ## 图表

    ### 上下文重置次数

    图片

    ### 完整通过任务数

    图片

    ## 任务结果

    表中通过数为新增功能测试;所有已完成组的原有测试均全部通过。耗时为 Agent 执行墙钟时间(含API排队、工具执行,不含容器准备和Verifier),不是纯模型生成时间。

    图片

    ## 项目链接与致谢

    - Smart Compact(本次测试版本):[yu1745/pi-smart-compact]

    - 我的 OpenAI Toolkit Fork:[yu1745/pi-openai-toolkit] 感谢上游:[awoaCrim/pi-openai-toolkit]· 作者:[awoaCrim] 预先完成的所有工作

    主楼
  • yu1745

    (帖子已被作者删除)

    #1
  • Max_Verstappen

    被人举报是ai了?md格式不太对?用了几个月smart-compact看样子又有新东西换了^-^

    #2
  • yu1745

    第一次发帖的时候,不知道为什么我的Markdown粘贴上来之后,格式直接爆炸了 ^-^ 然后我就改了几次

    #3
  • ansusu

    有具体的报告吗,捞

    #4
  • Max_Verstappen

    看起来不错啊,多多更新^-^

    #5
  • ansusu

    谢谢佬了,对我很有帮助

    #6
  • Rao

    为什么完整通过任务数这么差,有点不是很敢相信,有实际的测试题集吗,我目前使用 pi 来说, 完成任务没有什么问题, 由于提示词少,所以流程上需要明确。

    #7

发表回复

登录后回复