利用"专家模型"实现低成本类 AugmentCode 效果的设想

查看 40|回复 3
作者:sxueck   
先说效果:这个做法能实现 AugmentCode 模式 80% 的效果,成本的话因人而已,我订阅的一直是 50usd 的套餐,因此如果我替换成这个方案其实能省下将近 40% 的成本
专家模型的灵感来自于 MoE 模型,前置的门控分类器根据输入的权重下发给 topk 靠前的子模型,我也是仿照了这个思路并调整,不过我们并不基于 Tokens ,而是基于 Query ,这个在 Higress 里面已经有了一个 LLM 意图识别插件(但是配置太麻烦了)
针对 Vibe 场景,我将 Query 分类为
  • chat_simple
  • code_generation
  • code_refactor_edit
  • code_debug_analysis
  • testing
  • docs_and_comments
  • other

    (可惜 V2EX 发不了图)
    这里关键节点来了,我将 code_debug_analysis 配置为 Claude Sonnet 4.5 (找的中转站逆向),其他的可以按需分配,例如 testing 可以为 GLM 4.6 ,docs 可以为 Gemini 2.5 Pro
    测试结果:
    公司项目,一个 Golang CRI 调度器,纯 Go 代码行大概在 1.5w 左右,在没有给出具体文件路径和函数的情况下,修复一个 BUG ,请求约 6 次,一次通过,查看了一下后台记录,其实关键的逻辑处理部分,是 Claude sonnet 4.5 在承担并且保持整个 debug 方向,对于调用工具和输出文档,以及修改代码部分,都是交给其他模型进行的,所以整体测试下来体验都非常好
    我也在想商业插件例如 Cursor 是不是也是这样实现的,不过他们更专业,可能可以使用 BERT 进行精准分类,同时低级任务交给 haiku 等

    专家模型, 低成本, AugmentCode

  • sxueck
    OP
      
    https://github.com/sxueck/llm-gateway/blob/main/docs/screenshot.md
    这里可以看具体的模型配置和选择
    blushyes   
    之前偶然刷到的:
    https://www.archgw.com/
    他们就是专门训练了一个路由专用的小模型
    sxueck
    OP
      
    @blushyes 我试一下,感谢
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部