• Logos

    在dsh的插件商城看到的

    发现支持很多harness

    放在pi或者omp中使用会不会降低生成的质量?

    主楼
  • Delthin

    昨天刚下载,我用的是pi,准备用几天试试,感觉原理挺合理的

    #1
  • frush

    我现在再用magic-context。然后让ai总结了下,说是bilion-context和magix-context是冲突的。纠结

    选择 billion-context,如果你:主要痛点是超长会话下的 token 消耗和上下文窗口限制,希望以最小的缓存性能代价(官方称健康会话可保持 95-97% 的前缀缓存命中率)实现“数十亿 token 穿过一个窗口”的效果。

    选择 magic-context,如果你:更看重跨会话的长期记忆和知识沉淀。它被设计为编码代理的“海马体”,旨在让代理记住项目决策和惯例,实现“一个会话,伴随一生”。但你需要接受其可能带来的缓存命中率波动,并可能需要手动调整 cache_ttl 等参数来缓解。

    #2
  • AmeowCAT

    我在dsh试用过一段时间 感觉比起不用 质量还是有下降 可能跟模型有关 我是用官方ds4.1

    不知道是不是越强的模型下降越少

    #3
  • CKun

    magix-context玩上下文关闭压缩,让压缩用billion咋样

    #4
  • ProudBenzene

    用过一段时间,现在关掉了,因为发现这个压缩太狠了,很容易就丢失重要的上下文记忆导致长对话后半部分忘了前半部分做了什么。

    #5
  • lvyan

    我一直用的 magic context,感觉还是挺不错的

    #6
  • 鸭梨山大

    目前对话和缓存命中感觉还行。可能是我个人小项目基本自动压缩两三轮能解决,所以没什么不好。但是对于tree功能倒是变相削弱了,以前用得挺多的,现在不怎么用了

    #7
  • junshangzui

    在用magix-context,但看billion星数涨的很快

    #8
  • gaodeh

    个人在pi的使用体验:

    缓存命中率billion好一点,超长任务工作billion效果更好。但是不知道是不是我错觉感觉billion每轮响应延迟更高?而且billion没有项目长期记忆,只能单个会话内记忆,有些场景我还是蛮需要跨会话记忆的。

    #9
  • keepclassy

    billion原理就是给模型提供了一组工具,让模型自己每隔xx万token可选是否压缩上下文,响应延迟高可能是某些轮次刚好调了compress工具,压缩本身也是要思考和输出的,就会显得好像慢一点;

    但是相比什么都不用我觉得还是快的,很多harness自带压缩还是有点蠢蠢的

    #10

发表回复

登录后回复