1m 上下文感觉面对 agent 还是少了？预测下接下来哪家会先出真*2m 上下文？

[lynn1su]

不是那种跑 30%就开始降性能的那种模型

[xiaomushen]

压缩一下呗，带着那么多垃圾历史信息没意义

[lynn1su]

@xiaomushen #1 自动压缩感觉会损失很多细节。期待真 2m 上下文模型

[SHIINASAMA]

我觉得目前这个上下文大小已经比较甜点了，有用的信息提到项目文档或者个人知识库就好

[ktyang]

1M 的时候不担心 token 消耗量么？ 2M 那更不敢想了

[lynn1su]

@ktyang #4 公司给买了

[hrapunzel]

上下文太多 记忆力稀释怎么办

[lynn1su]

@hrapunzel #6 所以我说真*2m 上下文，不会因为长上下文稀释降低性能的

[getadoggie]

能不能引入一种上下文提炼组件，代替压缩呢？自动判断哪些有价值，哪些没有的那种 我觉得比光加要好

[mingtdlb]

1M 上下文有些模型都丢信息。支持更大的上下文长度 价值不大，压缩要做好 能提取重要的信息，1M 往上 显存兜不住

[m0mo]

@lynn1su 请教下现在真 1m 上下文的有哪些

[Dream4U]

稀释问题解决不了，再长也没用

[ktyang]

@lynn1su #5 供应量无限嘛 羡慕啊

[Rickkkkkkk]

1m 都不好用现在。

[hrdom]

1m 上下文相对于 512k 性能已经下降了，可以从一些基准测试里看出来

[PerFectTime]

得了吧, 现在真 1M 且效果好的模型都没有, 还 2M

[dabbit]

1M context 里有多少是有效 context 我不好说

[fovecifer]

我觉得还是需要人来控制，有的时候表现出来记忆里不够，有的时候又混杂了很多无关的东西。
但是这样会很累，希望以后模型对于上下文处理的更加合理。

[duanxianze]

还是研究研究压缩吧，真出了怕是没人用的起

[leonvxe]

大胆点 100M 上下文 就像当初宽带一样 512K ADSL,现在不也是家家都千八百 M 的

[xiaoz]

个人感觉并不是上下文窗口越大越好，太大了精度质量下降，tokens 消耗更快。

长任务还是拆分窗口进行吧。

[Vegetable]

我觉得恰恰相反，现在是 agent 肆无忌惮的的浪费上下文，上下文越长，信噪比越低。这样下去上下文边际能力收益会越来越低。
模型训练那边已经想明白后训练才是最有性价比的付出，agent 也会探索出让上下文更有价值的方法，我并不期待更大的上下文，我期待“Agent 仙人”

[shukebeta2004]

@xiaoz 没错。即使是支持 1M 上下文的模型，我也主动限制为 256K 上下文，尽早触发上下文压缩可以有效降低使用成本，特别是当 agent 们大部分时候都在自主工作时。超过 400k 每一次工具调用都变得异常昂贵，即使命中 cache 也是。