不是那种跑 30%就开始降性能的那种模型
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 32 days ago, the information mentioned may be changed or developed.
 |
1
xiaomushen Aug 20
压缩一下呗，带着那么多垃圾历史信息没意义
|
 |
2
lynn1su OP @xiaomushen #1 自动压缩感觉会损失很多细节。期待真 2m 上下文模型
|
 |
3
SHIINASAMA Aug 20
我觉得目前这个上下文大小已经比较甜点了，有用的信息提到项目文档或者个人知识库就好
|
 |
4
ktyang Aug 20
1M 的时候不担心 token 消耗量么？ 2M 那更不敢想了
|
 |
6
hrapunzel Aug 20
上下文太多 记忆力稀释怎么办
|
 |
8
getadoggie Aug 20 via iPhone
能不能引入一种上下文提炼组件，代替压缩呢？自动判断哪些有价值，哪些没有的那种 我觉得比光加要好
|
 |
9
mingtdlb Aug 20
1M 上下文有些模型都丢信息。支持更大的上下文长度 价值不大，压缩要做好 能提取重要的信息，1M 往上 显存兜不住
|
 |
11
Dream4U Aug 20
稀释问题解决不了，再长也没用
|
 |
13
Rickkkkkkk Aug 20
1m 都不好用现在。
|
 |
14
hrdom Aug 20
1m 上下文相对于 512k 性能已经下降了，可以从一些基准测试里看出来
|
 |
15
PerFectTime Aug 20
得了吧, 现在真 1M 且效果好的模型都没有, 还 2M
|
 |
16
dabbit Aug 20
1M context 里有多少是有效 context 我不好说
|
 |
17
fovecifer Aug 20
我觉得还是需要人来控制，有的时候表现出来记忆里不够，有的时候又混杂了很多无关的东西。
但是这样会很累，希望以后模型对于上下文处理的更加合理。 |
 |
18
duanxianze Aug 20
还是研究研究压缩吧，真出了怕是没人用的起
|
 |
19
leonvxe Aug 20
大胆点 100M 上下文 就像当初宽带一样 512K ADSL,现在不也是家家都千八百 M 的
|
 |
20
xiaoz Aug 20 via Android
个人感觉并不是上下文窗口越大越好，太大了精度质量下降，tokens 消耗更快。
长任务还是拆分窗口进行吧。 |
 |
21
Vegetable Aug 20  1
我觉得恰恰相反，现在是 agent 肆无忌惮的的浪费上下文，上下文越长，信噪比越低。这样下去上下文边际能力收益会越来越低。
模型训练那边已经想明白后训练才是最有性价比的付出，agent 也会探索出让上下文更有价值的方法，我并不期待更大的上下文，我期待“Agent 仙人” |
 |
22
shukebeta2004 Aug 21
@xiaoz 没错。即使是支持 1M 上下文的模型，我也主动限制为 256K 上下文，尽早触发上下文压缩可以有效降低使用成本，特别是当 agent 们大部分时候都在自主工作时。超过 400k 每一次工具调用都变得异常昂贵，即使命中 cache 也是。
|
 |
23
txican Aug 21
不只是压缩，还有总结。
压缩是从上下文中去掉一部分，总结是保存为文档，需要的时候再来读。 好比你写论文，记忆里只有一个大概 “XXX 说过一个什么意思的话”， 真要要引用的时候，你再去找原始资料再读一遍， 确认你没记错，确认更多细节。 |
 |
24
Adven Aug 21
我日常超过 256K 上下文使用的话，多轮对话下去成本会骤升，好多 Agent 工具在这个量级附近已经开始自动压缩模型上下文了，1M 以上的上下文需求目前占比应该非常小，但是潜力肯定还是有的，最大阻力是算力成本墙，要成为主流还是得给输入/输出上下文的单价进一步降下来，个人认为至少得目前市场价数倍的降幅，且模型能力还要保持不下降，否则这个短期内市场博弈下，大多数用户盯着消耗账单望而却步。
|
 |
25
guo4224 Aug 21 via iPhone
外面一堆 200 的都一样用
|
|
26
xiaomushen Aug 21
500K 是甜点，1M 上下文大部分用不到---因为上下文有效的，可能就最近几轮对话。再之前的，都是废话
|
|
27
xiaomushen Aug 21
这和人对话一样的道理：说话请说重点，别东拉西扯废话连篇
|
Select Language