那些网站可以给产品做推广,广告公司注册条件,学好wordpress怎么赚钱,yw开头的网络黄页在学习完大语言模型中最热门的两个概念大语言模型落地的关键技术#xff1a;RAG和大语言模型上下文窗口初探后#xff0c;关于RAG和长文本#xff08;long-context#xff09;的优劣比较引起了广泛的讨论#xff0c;本文整理了大语言模型RAG vs. 长文本争论的5种类观点。 … 在学习完大语言模型中最热门的两个概念大语言模型落地的关键技术RAG和大语言模型上下文窗口初探后关于RAG和长文本long-context的优劣比较引起了广泛的讨论本文整理了大语言模型RAG vs. 长文本争论的5种类观点。 1、观点1RAG 与长文本各有所长
人们普遍认为将文本切片然后进行相应的检索是最节省资源的方式。但因为检索是速度检索受到阈值的影响可能要多次反复检索反而会造成一些token 消耗的问题。在多轮对话过程中特别是在金融分析和客服场景需要使用长文本来解决问题。如果进行切片处理可能会丢失上下文之间的相互依赖关系。 对于大模型厂商选择长文本或者 RAG 应该考虑哪种方式最节省 token。
一位投资人分享了一个项目国内有一个做代码生成工具的公司相比仅仅生成代码他们更注重软件工程。因为GitHub 或 Copilot 生成代码分析和代码片段的能力已经很完美国内真正需要解决的是能够围绕多个指标进行策略生成。 以操作系统为例当我们想在操作系统中增加 AI 助手时大模型不仅能实现底层部署还能生成交互界面。这种生成能力依赖于向模型输入的数据规模可能涉及到的代码量会达到百万行、甚至千万行。如果仍然使用比较原始的一次性输入方式可能会遇到很多问题。 对此这位投资人分享了两个观点 长文本是一种智力能力。拥有一个更好的上下文窗口可以更好地解决代码的相互依赖和逻辑性问题。如果只是用 RAG 方式去分段代码然后再连接起来再分段提问是无法满足需求的。RAG更像是能力的边界。如果只使用上下文窗口而没有好好利用 RAG 基于检索的方式很难解决同一个代码工程在多个模块或者在多个功能上的问题。只能解决比较局部的问题无法处理多个模块之间的相互关联例如进行联调测试而合理使用 RAG 辅助可以拓展模型的知识边界。 进一步说明 长文本是一种智力能力从认知科学的角度看人类处理长文本信息的能力是高级智力的体现。阅读理解一本小说写作一篇论文都需要在大脑中维护一个宏大的上下文同时进行逻辑推理、情节关联等复杂的认知活动。这种能力区别于对简单句子或短语的机械处理。对语言模型而言长文本建模能力意味着更强的抽象和归纳能力。RAG更像是能力的边界RAG 通过检索相关片段来辅助生成在一定程度上弥补了语言模型在长文本建模上的不足。它提供了一种即时获取背景知识的机制减轻了模型的记忆负担但它并不能取代模型本身的语言理解和推理能力。 2、观点2长文本将取代RAG
长文本相比于 RAG 在解码过程中检索具有明显的优越性因此有人认为长文本正在取代 RAG。 爱丁堡大学博士付尧在评价Gemini 1.5 Pro 的帖子中写道 “一个有 1000 万 token 上下文窗口的大模型击败了 RAG。LLM 已是强大的检索器那为什么还构建一个弱小的检索器并花时间在解决分块、嵌入和索引问题上呢” 他表示1000 万 token 上下文杀死了 RAG。 Twitter地址 https://twitter.com/Francis_YAO_/status/1758934303655030929 虽然当前上下文模型的计算成本很高上下文窗口的消耗成本和时间消耗是非线性增长的但有人认为未来可能会有更好的方式来重复利用缓存从而释放压力。从 AI 的历史发展来看现有模型的成本能降低90%RAG可能会从现在的50%的应用场景缩减到10%。 在大规模语言模型中重复利用缓存是一种优化策略旨在提高模型的推理效率和速度。它的基本思路是将模型在处理长文本时生成的中间结果如隐藏状态、注意力矩阵等存储在缓存中当遇到相似的上下文时直接从缓存中读取这些中间结果而不是重新计算。比较常见的是Key-Value Cache、Hidden State Cache 等 对于长文本替代RAG有人提出了一个很有意思的 idea如果有一个无限长的上下文模型直接将 wiki 里面所有的文本和相关信息全部输入然后再去问问题。实际上就相当于大模型直接做 RAG不需要有任何外部的知识库再去进行上游检索。模型的推理成本是个门槛即模型输入的信息越多模型推理的时间越长成本越高。 但依旧存在可行的解决方案即信息压缩交给 RAG 或在线数据库处理的信息本质上是可以被压缩的。比如检查 GitHub 里的 Star 数量或者 wiki 上的访问量贡献的数量等都是可以被压缩的进而转化为结构化的信息。但此方法的前提条件是需要找出哪些数据真的可以被压缩并且它的压缩失真情况在接受的范围内。 3、观点3RAG 和长文本分工已经明确不存在争议空间
对于一些严肃的场景中如法规条文、保险或教育等RAG可以更好解决的问题。在进行向量化的初期开发者设计的就是认为里面的内容是法定正确的或者至少为大模型提供向量数据库时我们认为这些是客观事实不应该对这些事实进行歪曲或改变。如果将其交给大模型的幻觉或者概率去判断实际上可能会出现问题。如果完全依赖长文本结果一定是不准确的。 对于多轮对话的场景RAG能解决的问题并不是很清晰。如客服场景很多大模型会出现与它对话的时候会做一些后端的成本精简不需要动用全部算力来解答一个问题。如果反复去确认要给一个真实答案这个时候只能交给长文本去解决这个问题而 RAG 只是去把它向量化。此外对于软件工程领域涉及到代码的补全、翻译或重构时输入 token 会非常大只交给滑动窗口去处理会存在理解的障碍。 4、观点4长文本和 RAG 需要结合
RAG的特点是准确、事实性和时效性。用 RAG 的方式可以将原有系统的元素变成多维标签甚至将系统本身做成一个端到端的向量或是一个标签化的端到端的实体以防信息损失。但如果只用 RAG 的方法去做模型可能在多轮对话后它就不知道说什么了。长上下文在解决问题时是一个泛化和上下文理解的过程避免信息丢失。 长文本和RAG 都比较依赖于上游检索的输出。如果大模型对上下文的容纳程度比较低那对检索的要求就更高必须把最重要的信息检索出来。但是如果大模型可以接受更多的上下文那么对检索的要求就相对降低而对数据准备的要求就会相对提高。 对于大模型厂商来说无论是做大模型基座还是其他未来最终都是要转向消费端。只有当消费端起来之后大模型才可能有一个大的爆发。从消费端来看一般考虑的是成本性能、泛化能力以及信息丢失。在消费端应用的场景下最终是希望成本越来越低性能越来越快泛化能力越来越强。 如果不能接受信息损失需要在系统里面投入更高的 RAG 成本。如果只是进行角色扮演或者是给出一个笼统的回答那么长文本比较合适。 长文本和RAG 的结合更像是一种趋势在输入大模型之前我们不仅可以通过向量库去做文本检索还可以通过一些 function 去获取更多的文本来做集中的召回通过大模型做能力整合再做 RAG。长上下文能够代表所有情况但 RAG 系统仍然会存在。 5、观点5RAG 是大模型发展的中间态短期内长文本无法替代 RAG
无论是传统还是新架构不断扩大模型的处理长度后其性能必然会有所损失。目前的大模型而言可能较合适的处理窗口是4K到8K因为预训练是在这个长度范围内。RAG 相当于我们把模型的存储扩展到了无限我们要做的是把有用的、最重要的信息给大模型。 因此RAG 一定是很重要的只不过它未来可能会有多种形态不一定是现在这种大模型和向量检索分开的形态它的形态可能会有所不同。但是这种通过一些方法提前对信息进行精炼和提取的思想一定会在大模型的发展中长期发挥重要的作用。 长文本处理和RAG 这两个技术会共同发展。对长文本处理已经有一些优化的方法。比如通过微调的方法把训练的参数量已经提升到了十亿或者是百亿在推理上的话减少长文本的处理开销也有一些优化方法比如 MIT 的韩松实验室有一个 Streaming LLM 的方法可以识别出长文本中哪些是重点的 Context 或者 Token然后保留这些部分和最近的一些信息可以进行推理长度的优化从而降低推理的成本。 除了长文本处理在不断进步之外RAG 最近也有很多新的技术未来可能会结合 agent在其他方面提高模型解决具体实际问题的能力。 以目前的推理成本来看RAG必不可少可能会隐藏在产品里。比如说网易的逆水寒它里面做了很多 AI 的具体应用比如 NPC 对话。MiniMax 的模型有一个功能叫做 Glyph它可以去控制模型输出的结果可以标准化它的格式对于很多场景来说它的推理是非常有帮助的。
