AI 文摘

大模型未来发展:RAGvs长文本,谁更胜一筹?|Z沙龙第8期





作者: 目标检测和深度学习 来源: 目标检测和深度学习

「Z计划」 是智谱 AI 面向未上市初创企业与优秀独立开发者/团队,提供 Tokens 赞助、投资支持和技术支持等资源的创新加速计划。面向全球,持续招募中!(点击报名)「Z沙龙」 是支持该计划的面向大模型领域的线下活动品牌。为鼓励自由发言,人人发言,我们暂时不披露参与者个人信息。本文不代表智谱公司认同文中任何观点。

编者按:当前,AIGC的迭代速度正以指数级的速度增长。2024 年 2 月,谷歌发布的 Gemini 1.5 Pro;

再次将上下文刷新为 100 万 token,创下了最长上下文窗口的纪录,相当于 1 小时的视频或者 70 万个单词。

由于 Gemini 在处理长上下文方面表现出色,甚至有人高喊“RAG 已死”。爱丁堡大学博士付尧表示:“一个拥有 1000 万 token 上下文窗口的大模型击败了 RAG。

大语言模型已经是非常强大的检索器,那么为什么还要花时间构建一个弱小的检索器,并将时间花在解决分块、嵌入和索引问题上呢?”

随着模型上下文长度的提升,一个问题逐渐显现:RAG技术是否会被取代? 由此,我们在 3 月 9 日举办了 Z 沙龙第八期:Long-context & RAG。

我们邀请了产业界和学术界的朋友们共同碰撞思想,交流观点;他们分享了关于于 Long-context 和 RAG 的看法,并对 Context length 是否存在摩尔定律展开了精彩讨论。

同时,投资人与产业从业者也分享了 Long-context 及 RAG 如何赋能 AI 应用。对于研究人员与大模型从业者关心的点,罗列如下,方便大家结合目录使用:

*Long-context 将取代 RAG(2.2)

*Context length 存在摩尔定律(3.1)

*大海捞针是否是长文本测试唯一的标准(4.3)

*Long-context 与 RAG 未来的发展趋势(5.5)

目录建议结合要点进行针对性阅读。👇

**一、**长文本 & RAG 发展近况

1、长文本发展近况

2、RAG 发展近况

**二、**RAG vs 长文本,谁更胜一筹?

1、观点一:RAG 与长文本各有所长

2、观点二:长文本将取代 RAG

3、观点三:RAG 和长文本分工已经明确,不存在争议空间

4、观点四:长文本和 RAG 需要结合

5、观点五:RAG 是大模型发展的中间态,短期内长文本无法替代 RAG

**三、**Context length是否存在摩尔定律?

1、观点一:存在

2、观点二:不存在

3、观点三:不确定

**四、**模型层:大模型如何优化?如何有效对大模型测试?

1、模型优化——优化数据质量

2、模型优化——节省计算资源

3、模型测试——大海捞针是否是唯一?

**五、**长文本及 RAG 在大模型场景落地时的角色

1、投资人的看法

2、情感陪伴

3、教育产品

4、医疗领域‍

5、未来发展趋势

#1.

长文本 & RAG 发展近况

1、长文本发展近况

随着大模型上下文窗口长度不断增加,各个厂商对于文本生成模型呈现出“军备竞赛”的态势。

目前,主流的文本生成模型是聊天模型,比如GPT、Claude 3 等,也有少部分 Base 模型,例如 Yi-34 开源模型。

两位技术研究人员分享了他们对于大模型的看法:

  • 用户使用最多的是 GPT,但对外开放的版本性能较差,用户交互端无法传输大文件,只能通过 API 接口上传。

  • 月之暗面的 Kimi 模型大海捞针测试分数很高,但实际使用效果没有达到理想状态。

  • 百川 192K 的闭源模型,对于 6 万字的长文本,其表现的推理能力和回答效果很优秀。

  • 各种长文本的跑分数据,最高的是 Claude 3 模型。‍

2、RAG 发展近况

目前,大部分公司倾向于使用RAG 方法进行信息检索,因为相比长文本的使用成本,使用向量数据库的成本更低。

而在 RAG 应用过程中,一些公司会使用微调的 Embedding Model,以增强 RAG 的检索能力;而有些公司会选择使用知识图谱或者 ES 等非向量数据库的 RAG 方法。

一个正常的模型使用 RAG 仍然是当前的主流选择。

由于大语言模型信息的滞后性以及不包含业务知识的特点,我们经常需要外挂知识库来协助大模型解决一些问题。

在外挂知识库的过程中,Embedding 模型的召回效果直接影响大模型的回答效果,因此,在许多场景下,我们都需要微调 Embedding 模型来提高召回效果。

来自马里兰大学、劳伦斯利弗莫尔国家实验室、纽约大学的研究学者提出了一个大模型微调的方法;‍

在微调时只需要简单的在Embedding 层上加随机噪声即可大幅度提升微调模型的对话能力,而且也不会削弱模型的推理能力。

用 Alpaca 微调 LLaMA-2-7B 可以在在 AlpacaEval 上取得 29.79%的表现,而用加了噪声的嵌入则提高到 64.69%。不过该工作只在较小的模型上进行微调。

论文地址:

https://arxiv.org/pdf/2310.05914.pdf

代码链接:

https://github.com/neelsjain/NEFTune

#2.

RAG vs 长文本,谁更胜一筹?

1、观点一:RAG 与长文本各有所长

人们普遍认为将文本切片,然后进行相应的检索是最节省资源的方式。但因为检索是速度检索,受到阈值的影响,可能要多次反复检索,反而会造成一些token 消耗的问题。

在多轮对话过程中,特别是在金融分析和客服场景,需要使用长文本来解决问题。如果进行切片处理,可能会丢失上下文之间的相互依赖关系。

对于大模型厂商,选择长文本或者 RAG 应该考虑哪种方式最节省 token。

一位投资人分享了一个项目: 国内有一个做代码生成工具的公司,相比仅仅生成代码,他们更注重软件工程。

因为GitHub 或 Copilot 生成代码分析和代码片段的能力已经很完美,国内真正需要解决的是能够围绕多个指标进行策略生成;

以操作系统为例,当我们想在操作系统中增加 AI 助手时,大模型不仅能实现底层部署,还能生成交互界面。

这种生成能力依赖于向模型输入的数据规模,可能涉及到的代码量会达到百万行、甚至千万行。如果仍然使用比较原始的一次性输入方式,可能会遇到很多问题。

对此,这位投资人分享了两个观点:

*长文本是一种智力能力。 拥有一个更好的上下文窗口,可以更好地解决代码的相互依赖和逻辑性问题。

‍如果只是用 RAG 方式去分段代码,然后再连接起来,再分段提问,是无法满足需求的。

*RAG更像是能力的边界。 如果只使用上下文窗口,而没有好好利用 RAG 基于检索的方式,很难解决同一个代码工程在多个模块,或者在多个功能上的问题。

‍只能解决比较局部的问题,无法处理多个模块之间的相互关联,例如进行联调测试,而合理使用 RAG 辅助可以拓展模型的知识边界。

编者按:

*长文本是一种智力能力: 从认知科学的角度看,人类处理长文本信息的能力是高级智力的体现。

阅读理解一本小说,写作一篇论文,都需要在大脑中维护一个宏大的上下文,同时进行逻辑推理、情节关联等复杂的认知活动。

这种能力区别于对简单句子或短语的机械处理。对语言模型而言,长文本建模能力意味着更强的抽象和归纳能力。

*RAG更像是能力的边界: RAG 通过检索相关片段来辅助生成,在一定程度上弥补了语言模型在长文本建模上的不足。

‍它提供了一种即时获取背景知识的机制,减轻了模型的记忆负担,但它并不能取代模型本身的语言理解和推理能力。

针对代码生成,研究人员分享了一个最新技术:Task Weaver 。Task Weaver 是微软的框架,用 GPT 的一个常规模型来完成。

本质是把一个复杂任务拆成很多小部分,然后再把每个小部分再去做 code intervention,中间用代码的形式来交互。

在每一个小部分里面,开始套各种套模板。这种用在长文本的话,可以解决掉内容丢失的问题。但是这个模型上下文不长,超过 8K 就结束了。

特别是它里面有个 Tools 叫 RAG,它占用上下文很大,每次调用 Tools,就会把 RAG 里面的东西全部抛进来,RAG 会作为一个 Tools 的 Observation 返回给 Agent。

之后,把整个 Agent 的结果成为下一个 RAG 的内容,在下一次 Agent 的时候再套,再把这个记录套回去。如果长文本技术的发展提升,Agent 上限可能会提高。

TaskWeaver 是一款代码优先的 Agent 框架,能将用户的自然语言请求转化为可执行代码,并支持海量数据结构、动态插件选择以及专业领域适应的规划过程。

作为开源框架,TaskWeaver 充分发挥了大语言模型的潜力,通过可定制的示例和插件融入特定领域知识,让用户能够轻松打造个性化虚拟助手。

TaskWeaver 项目已在 GitHub 上开源,并于发布当日登上 GitHub 趋势榜。

论文地址:

https://export.arxiv.org/abs/2311.17541

项目主页:

https://microsoft.github.io/TaskWeaver/

项目地址:

https://github.com/microsoft/TaskWeaver

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、观点三:RAG 和长文本分工已经明确,不存在争议空间

对于一些严肃的场景中,如法规条文、保险或教育等,RAG可以更好解决的问题。 在进行向量化的初期,开发者设计的就是认为里面的内容是法定正确的;

或者至少为大模型提供向量数据库时,我们认为这些是客观事实,不应该对这些事实进行歪曲或改变。

如果将其交给大模型的幻觉或者概率去判断,实际上可能会出现问题。如果完全依赖长文本,结果一定是不准确的。

对于多轮对话的场景,RAG能解决的问题并不是很清晰。 如客服场景,很多大模型会出现与它对话的时候,会做一些后端的成本精简,不需要动用全部算力来解答一个问题。

如果反复去确认,要给一个真实答案,这个时候只能交给长文本去解决这个问题,而 RAG 只是去把它向量化。

此外,对于软件工程领域, 涉及到代码的补全、翻译或重构时,输入 token 会非常大,只交给滑动窗口去处理,会存在理解的障碍。

编者按:

Devin是全球首个 AI 软件工程师,由公司 Cognition 推出。它有全栈技能,包括开发工具集,如 shell、代码编辑器、沙箱浏览器等,并能用它们来高效编程。

Devin 在经过长期的推理训练后,能够规划并完成复杂的任务,包括构建和部署应用程序、自主查找并修复 Bug、训练和微调自己的 AI 模型等。

官方网址:

https://www.cognition-labs.com

4、观点四:长文本和 RAG 需要结合

RAG的特点是准确、事实性和时效性。 用 RAG 的方式,可以将原有系统的元素变成多维标签,甚至将系统本身做成一个端到端的向量,或是一个标签化的端到端的实体,以防信息损失。

但如果只用 RAG 的方法去做模型,可能在多轮对话后,它就不知道说什么了。长上下文在解决问题时,是一个泛化和上下文理解的过程,避免信息丢失。

长文本和RAG 都比较依赖于上游检索的输出。如果大模型对上下文的容纳程度比较低,那对检索的要求就更高,必须把最重要的信息检索出来。

但是,如果大模型可以接受更多的上下文,那么对检索的要求就相对降低,而对数据准备的要求就会相对提高。

对于大模型厂商来说,无论是做大模型基座还是其他,未来最终都是要转向消费端。只有当消费端起来之后,大模型才可能有一个大的爆发。

从消费端来看,一般考虑的是成本性能、泛化能力以及信息丢失。 在消费端应用的场景下,最终是希望成本越来越低,性能越来越快,泛化能力越来越强。

  • 如果不能接受信息损失,需要在系统里面投入更高的 RAG 成本。

  • 如果只是进行角色扮演,或者是给出一个笼统的回答,那么长文本比较合适。

长文本和RAG 的结合更像是一种趋势,在输入大模型之前,我们不仅可以通过向量库去做文本检索;

还可以通过一些 function 去获取更多的文本来做集中的召回,通过大模型做能力整合再做 RAG。长上下文能够代表所有情况,但 RAG 系统仍然会存在。

以大模型基座为例,我们觉得它最终在市场上的竞争方向有两个:

  • 长文本

  • 性能越来越好,可以远程部署

5、观点五:RAG 是大模型发展的中间态,短期内长文本无法替代 RAG

无论是传统还是新架构,不断扩大模型的处理长度后,其性能必然会有所损失。目前的大模型而言,可能较合适的处理窗口是 4K 到 8K,因为预训练是在这个长度范围内。

RAG 相当于我们把模型的存储扩展到了无限,我们要做的是把有用的、最重要的信息给大模型。

因此,RAG 一定是很重要的,只不过它未来可能会有多种形态,不一定是现在这种大模型和向量检索分开的形态,它的形态可能会有所不同。

但是,这种通过一些方法提前对信息进行精炼和提取的思想,一定会在大模型的发展中长期发挥重要的作用。

长文本处理和RAG 这两个技术会共同发展。对长文本处理已经有一些优化的方法。比如,通过微调的方法把训练的参数量已经提升到了十亿或者是百亿;

在推理上的话,减少长文本的处理开销也有一些优化方法,比如 MIT 的韩松实验室有一个Streaming LLM 的方法,可以识别出长文本中哪些是重点的 Context 或者 Token;‍

然后保留这些部分和最近的一些信息,可以进行推理长度的优化,从而降低推理的成本。

除了长文本处理在不断进步之外,RAG 最近也有很多新的技术,未来可能会结合 agent,在其他方面提高模型解决具体实际问题的能力。

来自MIT、Meta AI、CMU 的研究者提出了一种名为 Streaming LLM 的方法,使语言模型能够流畅地处理无穷无尽的文本。

使用 StreamingLLM,包括 Llama-2- 7/13/70B、MPT- 7/30B 在内的模型可以可靠地模拟 400 万个 token,甚至更多。

与唯一可行的 baseline——重新计算滑动窗口相比,StreamingLLM 的速度提高了 22.2 倍,而没有损耗性能。

论文地址:

https://arxiv.org/abs/2309.17453

论文代码:

https://github.com/mit-han-lab/streaming-llm

以目前的推理成本来看,RAG必不可少,可能会隐藏在产品里。比如说网易的逆水寒 ,它里面做了很多 AI 的具体应用,比如 NPC 对话。

MiniMax 的模型有一个功能叫做Glyph ,它可以去控制模型输出的结果,可以标准化它的格式,对于很多场景来说,它的推理是非常有帮助的。

逆水寒:

  • 《逆水寒》手游中的智能 NPC 系统,是利用网易伏羲 AI 技术,实装了国内首个游戏 GPT。

这是一种基于深度学习的自然语言生成模型,可以根据上下文和输入,生成合理的文本输出。

在游戏中,这意味着 NPC 不再是固定的对话框和任务分配者,而是可以与玩家自由对话,并且基于对话内容,自主给出有逻辑的行为反馈。

MiniMax

  • 限制返回格式(glyph):该功能可以帮助用户强制要求模型按照配置的固定格式返回内容。

逆水寒AI NPC

#3.

Context length 是否存在摩尔定律?

1、观点一:存在

目前,Context length正在持续增长,并且其增长速度远超摩尔定律。如果按照 18 个月翻倍的标准来计算,从之前的几百万、几千万,到现在达到十兆;

Context length 在一年内的变化就已经远远超过翻倍。这种增长速度本身就已经打破了摩尔定律所描述的增长曲线。

随着Context length 的增长,算力将成为一个瓶颈。当所有的推理和训练任务都转移到处理 Context 时,我们会发现仍然需要大量的能源。

以前可能只需要一张 A100 显卡,而现在可能需要一整台 A100 服务器才能完成任务。从产业界的角度来看,无论是算力还是能源,都会限制其增长速度。

因此,在考虑 Context 增长的同时,还需要考虑到成本和资源限制的问题

近日,Kimi 智能助手在长上下文窗口技术上再次取得突破,无损上下文长度提升了一个数量级到 200 万字。

从模型预训练到对齐、推理环节月之暗面均有原生的重新设计和开发。月之暗面认为,大模型无损上下文长度的数量级提升,也会扩大对 AI 应用场景的想象力;

包括完整代码库的分析理解、可以自主帮人类完成多步骤复杂任务的智能体 Agent、不会遗忘关键信息的终身助理、真正统一架构的多模态模型等等。

月之暗面创始人杨植麟表示,“上下文长度可能存在摩尔定律,但需要同时优化长度和无损压缩水平两个指标,才是有意义的规模化。”

新闻地址:

‍https://mp.weixin.qq.com/s/UjXKic9IAaf55ARqbnJ3Pg

2、观点二:不存在

Context的增长是包含了各个单元之间的逻辑关系,其复杂度的增长会高于计算能力的增长。

而且,现在大模型还是有非常多问题的,即使是顶尖的大型模型,在应用于工业产品时,也需要将需求范围缩小到非常具体的领域。

当需求被高度收敛时,相应的用户需求也会减小,这可能导致一种螺旋下降的趋势:投资减少,进一步导致研究和开发的动力减弱。

编者按:

*应用价值的不确定性: Context length 的增加能带来多大的应用价值提升,还缺乏足够的实证支撑。

一些研究表明,过长的 Context 可能引入噪音,对模型性能的提升效果并不明显。如果投入产出不成正比,继续增加 Context length 的动力会减弱。

*数据质量的瓶颈制约: 高质量的长文本数据是Context length 增长的基础,但现有的数据质量普遍不高,噪音、错误、不一致等问题严重。

数据瓶颈可能成为 Context length 增长的羁绊,单纯增加 Context length 而不解决数据问题,效果可能适得其反。

3、观点三:不确定

摩尔定律是基于一段时间技术积累后观察到的规律,需要大量的资本投入和成本控制来驱动。

对于大模型和RAG 这类技术,业界目前可能还处于探索阶段,从时间窗口来看还非常短暂,仅仅一两年的时间,并且没有大规模投入到特定场景中应用;

因此还没有足够的数据来进行经验总结。从这个角度来看,与晶体管发展的摩尔定律相比,Context length 的增长规律还不够成熟。

#4.

模型层:大模型如何优化?如何有效对大模型测试?

1、模型优化——优化数据质量

在训练模型的时候,数据量并不是越大越好。真正重要的是训练数据的质量,而不仅仅是数量。 使用 RAG 进行搜索的过程中,当数据量大了以后,它匹配出来的结果可能会有很多冗余。

比如,我们去搜索一个新的领域,不知道哪些文章是最好的,如果搜索出了 100 篇,不可能让模型全部去处理,需要加一些权重;

比如,文章的影响因子,或者是它的引用率、引用次数等,把这些因素考虑进去,然后对结果进行排序。

但这涉及到一些问题,有些优秀的文章并不一定引用率很高,特别是在一些特定的领域,它们可能引用的文章也相对较少。针对此问题,研究人员提出了一些想法:

*学科的交叉会使得大模型效果更好。 对于学科交叉的问题,最好的解决办法既不是依赖于长文本处理,也不是 RAG,而是微调。

‍在训练模型的过程中,我们需要考虑如何控制在各个大的领域里进行搜索。我们现在面临的是海量的文献,不可能把所有的数据都加进去,还需要人工智能来辅助。

‍现在面临的一个挑战,不仅要深度学习,还要广度学习,而且还要控制好搜索的范围,否则成本就会急剧上升。

  • 我们的平台每天都有大量的科研数据,包括用户的行为数据和点赞数据等,这些数据对我们来说非常有用,当我们将这些数据纳入训练时,效果就非常明显。

‍所以现在的挑战是如何检索出大量的文本,并从中筛选出真正有价值的信息,将其他的信息过滤掉,然后再将这些信息放入模型中。

  • 在应用层面,包括成本和产品质量,问题的核心在于是否需要数据的可靠性。如果要可靠的数据,就要使用Agent。如果数据可以压缩或者有损,需要考虑其他的方法。

2、模型优化——节省计算资源

现在大部分模型,即使是长文本模型,在反向传播阶段,从第一步到最后一步文本窗口不可能一直保持很长。

一定是在最后的时候去解决这个问题,以节约计算资源。在科研中,我们接触到的预训练阶段的长度是4k 或 8k。

学术界也有人提出,我们应该尽量让一个窗口内的数据尽可能相似,即在一个窗口或者一个数据条中,数据应该是相似的主题或内容。从论文来看,这可能对预训练有好处。

3、模型测试——大海捞针是否是唯一?

目前主流测试还是靠大海捞针,现在有一些新的测试,提出了一个更加复杂的大海捞针 Benchmark。

从产品侧,需要看受众端的用户。 来自教育产品的从业者分享其观点:我们去试过把哈利波特做成一个鲜活的角色,帮助用户了解哈利波特内容。

但家长对于内容的真实性和准确性要求是很高的,我们的产品无法达到他们的要求,所以这个方案就暂时搁置了。

对于非家长的产品,用户直接面向小孩,这种精确度就比较适合孩子体验。所以,从应用侧讲,测试大模型需要考虑受众端的内容。

来自情感陪伴的从业者分享观点:我们较关注用户的使用时长、满意度、分页系数等,对于不同的模型,我们直接进行AB 测试,哪个测试高,我们就会选择这个模型。

编者按:

目前大海捞针广泛用于长文本测试,这种方法并不完全合理,尤其是对于需要检索多个事实并在此基础上进行推理的应用。

对此,研究人员提出了多针检索加推理测试 ,通过扩展 Greg Kamradt 的“LLMTest_NeedleInAHaystack”项目,以支持多针评估,评估工具使用了 LangSmith 。

项目地址:

https://blog.langchain.dev/multi-needle-in-a-haystack/

#5.

长文本及 RAG 在大模型场景落地时的角色

1、投资人的看法

*投资人目前关注内存的增长。 内存的增大使任务或应用有了更丰富的展现,从以前玩的简单游戏,到现在复杂的 3A 大作,上下文窗口的提升肯定能提升整个应用的能力。

*RAG的外挂知识库可能是很重要的资产。 有些人会把 RAG 或者留存下来的外挂知识库看作是没有长期价值的资产。

‍有些人认为 RAG 里面会留存下来一些有价值的东西,例如,对于某些客户或某一类行业的客户,会在库里面封装一些客户业务逻辑的知识。

‍将来去服务这一类客户,或者满足这个客户的长期需求的过程中,无论用哪个模型,这个模型是无法知道这些私密、个人化的信息或路径的。

‍这一部分对于公司将来能持续在这一类行业里面交付能力,是有长期价值的。投资人会评估哪种行业能够留存下这方面的东西。

‍比如代码生成能力,在不断地积累人和代码生成的监督过程中,RAG 里面留存下来的信息可以持续帮助到模型。

2、情感陪伴

一位情感陪伴行业的从业者分享了他的观点:我们认为RAG 是对 Long-Context 的补充,特别是对外部知识的补充。

如果没有 RAG,每次都需要将知识输入到 Context 中,但 Context 的长度有限,而且 Token 的使用也要成本。因此,RAG 可以使 Context 的内容更丰富,同时节省成本。

在情感陪伴方面,为了让人物更加细腻,我们通常会使用prompt 来解决问题。在面向消费者的应用层面,将 Context 和 RAG 结合在一起是每个人在情感上最需要的。

对于情感陪伴来说,回忆是非常重要的。如果能让 Context 和 RAG 结合,直接作为大脑使用,那就达到了目的。

图片和其他角度可以增加想象力,就像微信可以发送图片、视频、语音和进行语音电话一样。这些功能对于微信的发展非常重要。

对于情感应用来说,如果你可以发送图片,然后你的朋友圈下面有人可以回复,这将为用户提供很大的情绪价值。目前,Agent 聊天仍然能够明显感觉到对方不是真人。

3、教育产品

一位教育产品领域的从业者分享了他的见解:在教育产品中,我们需要打通孩子不同年龄段的信息,以提供更有逻辑性的服务。

比如,学龄前的一个产品,它的登录是通过家长的手机端的APP,就是他的微信和手机号。目前我们只能通过标签的方式把这件事给连接起来,但这种方式是比较低效的。

会场上一位专家提供了解决思路:可以采用特定的Agent,比如 Read Agent,来处理这个问题。

他建议将 3-6 岁和 7-12 岁儿童的信息分别存储在两个数据库中,并使用大型模型对 3-6 岁儿童的信息进行总结,然后在每次需要读取时将其放入第二个数据库。

这种方法的核心是利用数据压缩技术,以提高处理效率。

Read Agent 是由 Google DeepMind 开发的一个类似人类阅读的 LLM 智能体系统,它能将有效上下文长度扩大 3-20 倍,同时取得更高的准确率和 ROUGE 得分。

Read Agent 系统通过三个主要步骤实现:

  • 分割成片段,根据 LLM 的提示决定在连续文本中的何处暂停,形成片段;

  • 摘要记忆,将每个片段压缩成更短的摘要,关联上下文信息;

  • 交互查找,在给定任务和完整的摘要记忆中,决定查找哪些片段,将摘要与原始文本结合,解决任务。

ReadAgent 系统可以通过提示经过训练的 LLM 来实现。

论文链接:

https://arxiv.org/abs/2402.09727

项目链接:

https://read-agent.github.io/

4、医疗领域

在医疗领域,大模型在理解文本和图像方面表现出色,但它们在Mapping 上存在不足,传统的 RAG 和 Embedding model 可能效果不佳。

与医疗公司建立合作关系成为一种有效的解决策略。通过合作,让医疗公司在 Embedding 的过程贡献他们的算法;

包括他们对病例的诊断,将这些信息加到 Embedding 的工具库里,这些数据的向量数大致在百万到千万之间。同时,为保证技术真正应用,需找到有实际付费能力的客户。

有研究人员发现,引入了In context learning,可以显著提升了效果。以 COVID-19 的 X 光诊断为例,我们可以先向模型展示一些样本,包括阴性和阳性病例。

先给模型看一张阳性病例的图片,然后是阴性病例的。接下来,当模型再次看到新图片并询问其是阳性或阴性时,通过学习,判断效果会比无预先学习的情况下好很多。

相比于那些已经通过人工标注训练的模型,如果能够实现 CNN 方法,它可能会比使用 RAG 方法更加经济高效。

5、未来发展趋势

随着视频和图像时代的到来,信息传递的方式将发生显著变化,这时传统的文本编码和解码方式将不再适用。

在这个新时代,“Token"不再仅仅代表一个文字,而是可能代表更复杂的信息单元,因此传统的NLP 方法将不足以处理计算机视觉领域的问题。

在算力方面,一些公司下一代的计算芯片放弃GPU 架构,自己有一套硬件架构做深度学习,而且性能更高,耗电量会更少。

从 2014 年至今,谷歌已经构建了 6 种不同的 TPU 芯片。虽然单体性能仍然与 H100 差距明显,但 TPU 更贴合谷歌自己生态内的系统。

这也促使 Gemini 的内容生成速度非常快的,虽然精度没有那么高,但生成速度远超 GPT 和 Claude。下图以 Gemini pro 和 Claude 3-Haik 代码生成速度为例。

Gemini pro 代码生成速度示例

Claude 3-Haik 代码生成速度示例

在谷歌发布 Gemini 大模型的同时,DeepMind 团队还写了 60 页技术报告阐述 Gemini 多模态的技术原理,报告提到谷歌用 TPU v5e 和 TPU v4 来训练 Gemini。

当日,谷歌还发布了 TPU v5p,称训练速度比前代快 2.8 倍,有望帮助开发者和企业客户更快地训练大规模生成式 AI 模型。

训练大模型需要大量的计算能力,因为它们通常在包含数十亿个单词的数据集上进行训练。

传统的CPU 和 GPU 架构难以处理这种计算负载,通常会减慢训练过程并限制大模型的功能。Google TPU 专门针对矩阵乘法和二维卷积进行了优化。

据谷歌的解析 TPU v4 论文,相较用英伟达 A100 构建的超级计算机,用谷歌 TPUv4 建的超级计算机速度快 1.2-1.7 倍,功耗降低 1.3-1.9 倍。 目前,谷歌超过 90% 的 AI 训练都在 TPU 上。

技术报告地址:

https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf

‍‍ ‍ ‍

#合作伙伴招募

🐋 回顾:往期所有 Z 沙龙活动纪要合集

Z 计划发布至今积累了 700 + 早期优质大模型创业项目。Z 计划面向大模型创业投资领域的行业伙伴,开放产业生态资源**。** 如果你是关注大模型领域的VC 投资机构、大模型方向开发者社区 等,欢迎直接找我们聊聊!🙋 微信联系:zhipu_eco

—end—

作者 | Z 沙龙 25 位参会者

主持|严宽、zR

整理|崔浩、Yizheng、严宽、郑寒、汪柯璇

排版|郑寒

审核|李文珏、邓瑞恒‍‍‍‍

*本文不代表智谱认同以上任何观点。

更多AI工具,参考Github-AiBard123国内AiBard123

可关注我们的公众号:每天AI新工具