我之前有个想法是错的,我以为模型有 1MB 的上下文窗口,就最好把这 1MB 用上。后来我逐渐意识到,哪怕模型有 1MB 的上下文窗口,当真的里面塞了 1MB 的上下文时,也比较容易出现注意力衰减的问题,200KB 之后的部分,模型的处理质量就不那么高了。这可能也是为什么 GPT 模型有 1MB 的上下文窗口,但 Codex 限制到了 256KB 左右(最近提高到了 500KB)。当然这只是原因之一,另一方面好像是超出的部分,成本也会比较高。最新我又知道,更频繁地压缩,有可能反而能提高任务质量、减少 token 消耗。因为当上下文满到 1MB 才压缩:首先,上下文越大,必然压缩损耗会更大;其次,压缩本身也是一次语义理解,也是要消耗模型的 token 的。目前看起来,200KB-300KB 是比较符合最佳实践的区间,除非场景就是需要一次性读入大量内容。
我之前有个想法是错的,我以为模型有 1MB 的上下文窗口,就最好把这 1MB 用上。后来我逐渐意识到,哪怕模型有 1MB 的上下文窗口,当真的里面塞了 1MB 的上下文时,也比较容易出现注意力衰减的问题,200KB 之后的部分,模型的处理质量就不那么高了。 这可能也是为什么 GPT 模型有 1MB 的上下文窗口,但
阅读:0
点赞:0