跳转至内容
  • 版块
  • 最新
  • 热门
  • 标签
  • 搜索
  • 成员
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
LocalAIHub 中文社区

LocalAIHub 中文社区

  1. 主页
  2. AI 工程讨论
  3. 长上下文模型是不是可以不用 RAG 了

长上下文模型是不是可以不用 RAG 了

已定时 已固定 已锁定 已移动 AI 工程讨论
long-contextragcontext-enginee
15 帖子 12 发布者 0 浏览 1 关注中
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • 小 离线
    小 离线
    小风扇
    编写于
    #3

    我反对完全不用 RAG。资料多的时候,先检索再喂模型还是必要的,不然成本和延迟都爆。

    1 条回复 最后回复
    0
    • 小 离线
      小 离线
      小蓝
      编写于
      #4

      但 RAG 也很麻烦。切块、向量、rerank、权限,全是坑。

      1 条回复 最后回复
      0
      • 陈 离线
        陈 离线
        陈一
        编写于
        #5

        所以不是 RAG 必须上,是任务决定。几十页临时合同可以长上下文,几万份制度肯定要检索。

        1 条回复 最后回复
        0
        • 普 离线
          普 离线
          普通网友A
          编写于
          #6

          长上下文不是越长越聪明吗?

          1 条回复 最后回复
          0
          • G 离线
            G 离线
            Grace
            编写于
            #7

            不是。长上下文只代表窗口更大,不代表模型会稳定关注每个细节。位置、重复、冲突内容都会影响答案。

            1 条回复 最后回复
            0
            • 半 离线
              半 离线
              半截薯条
              编写于
              #8

              我们试过把整本手册塞进去,模型会引用旧条款,因为旧条款也在上下文里。

              1 条回复 最后回复
              0
              • N 离线
                N 离线
                nora
                编写于
                #9

                这叫上下文污染。不是资料越多越安全,过期资料混进去更危险。

                1 条回复 最后回复
                0
                • 小 离线
                  小 离线
                  小吴
                  编写于
                  #10

                  那怎么判断放多少?

                  1 条回复 最后回复
                  0
                  • 林 离线
                    林 离线
                    林小北
                    编写于
                    #11

                    先按任务放。用户问报销流程,就不要把入职、采购、绩效都塞进去。

                    1 条回复 最后回复
                    0
                    • M 离线
                      M 离线
                      melo
                      编写于
                      #12

                      我现在做法是:检索召回一批,rerank 留少量,再把文档标题、更新时间、权限一起进上下文。

                      1 条回复 最后回复
                      0
                      • 小 离线
                        小 离线
                        小鼠标
                        编写于
                        #13

                        那长上下文主要适合什么?

                        1 条回复 最后回复
                        0
                        • 陈 离线
                          陈 离线
                          陈一
                          编写于
                          #14

                          适合长文总结、合同审阅、代码仓库片段阅读、会议资料综合。前提是资料集合本身可控。

                          1 条回复 最后回复
                          0
                          • 阿 离线
                            阿 离线
                            阿航
                            编写于
                            #15

                            还有一点:长上下文贵。能用 8k 解决的问题,不要硬上 200k。

                            1 条回复 最后回复
                            0

                            你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                            厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

                            有了你的建议,这篇帖子会更精彩哦 💗

                            注册 登录
                            回复
                            • 在新帖中回复
                            登录后回复
                            • 从旧到新
                            • 从新到旧
                            • 最多赞同


                            • 登录

                            • 没有帐号? 注册

                            • 登录或注册以进行搜索。
                            Powered by NodeBB Contributors
                            • 第一个帖子
                              最后一个帖子
                            0
                            • 版块
                            • 最新
                            • 热门
                            • 标签
                            • 搜索
                            • 成员