跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(75) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) ChatGPT(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) RAG(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) 智能体(4) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) kafka(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 大型语言模型(2) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

category

研究人员为一个令人困惑的问题开发了一个简单而有效的解决方案,该问题可能会恶化大型语言模型(如ChatGPT)的性能。

当人类人工智能对话涉及多轮连续对话时,驱动ChatGPT等聊天机器人的强大的大型语言机器学习模型有时会开始崩溃,导致机器人的性能迅速恶化。

来自麻省理工学院和其他地方的一组研究人员找出了这个问题的一个令人惊讶的原因,并开发了一个简单的解决方案,使聊天机器人能够保持不间断的对话,而不会崩溃或减速。

他们的方法涉及到对许多大型语言模型核心的键值缓存(就像对话内存)进行调整。在某些方法中,当该缓存需要容纳的信息超过其容量时,第一批数据会被挤出。这可能会导致模型失败。

通过确保前几个数据点保留在内存中,研究人员的方法允许聊天机器人无论对话持续多久都能继续聊天。

这种被称为StreamingLLM的方法使模型即使在对话持续超过400万字的情况下也能保持高效。与另一种通过不断重新计算过去对话的一部分来避免崩溃的方法相比,StreamingLLM的执行速度快了22倍多。

这可以让聊天机器人在整个工作日进行长时间的对话,而无需不断重启,从而使高效的人工智能助手能够完成文案、编辑或生成代码等任务。

“现在,有了这种方法,我们可以持久地部署这些大型语言模型。通过制作一个聊天机器人,我们可以随时与之聊天,并根据我们最近的对话随时回复我们,我们可以在一些新的应用程序中使用这些聊天机器人,”电气工程和计算机科学(EECS)研究生、StreamingLLM论文的主要作者肖光宣说。

肖的合著者包括他的顾问、EECS副教授、MIT-IBM Watson人工智能实验室成员、NVIDIA杰出科学家宋涵;以及Meta AI的研究科学家田远东;陈蓓迪,卡内基梅隆大学助理教授;以及Meta AI的研究科学家、资深作者Mike Lewis。这项工作将在国际学习表征会议上发表。

一个令人费解的现象

大型语言模型将数据(如用户查询中的单词)编码为称为标记的表示。许多模型使用所谓的注意力机制,使用这些标记来生成新的文本。

通常,人工智能聊天机器人会根据刚刚看到的文本编写新的文本,因此它会将最近的令牌存储在内存中,称为KV缓存,以便稍后使用。注意力机制构建了一个网格,其中包括缓存中的所有令牌,一个“注意力映射”,映射出每个令牌或单词与其他令牌的关联程度。

理解这些关系是使大型语言模型能够生成类人文本的一个功能。

但是,当缓存变得非常大时,注意力映射可能会变得更加庞大,从而减慢计算速度。

此外,如果对内容进行编码所需的令牌比缓存所能容纳的令牌多,则模型的性能会下降。例如,一个流行的模型可以存储4096个代币,但一篇学术论文中大约有10000个代币。

为了解决这些问题,研究人员采用了一种“滑动缓存”,将最旧的代币取出,添加新的代币。然而,一旦第一个令牌被驱逐,模型的性能往往会急剧下降,从而迅速降低新生成的单词的质量。

在这篇新论文中,研究人员意识到,如果他们将第一个令牌保留在滑动缓存中,即使超过缓存大小,模型也会保持其性能。

但这没有任何意义。小说中的第一个单词可能与最后一个单词无关,那么为什么第一个单词对模型生成最新单词如此重要呢?

在他们的新论文中,研究人员还揭示了这种现象的原因。

注意力下沉

一些模型在其注意力机制中使用Softmax操作,该操作为每个令牌分配一个分数,表示它与每个其他令牌的关联程度。Softmax操作要求所有注意力得分总和为1。由于大多数代币没有强相关性,它们的注意力得分非常低。该模型在第一个令牌中转储任何剩余的注意力分数。

研究人员将这第一个标志称为“注意力汇”

韩说:“我们需要一个注意力库,模型决定使用第一个令牌作为注意力库,因为它是全局可见的——其他每个令牌都可以看到它。我们发现,我们必须始终将注意力库保存在缓存中,以保持模型的动态性。”。

在构建StreamingLLM的过程中,研究人员发现,在滑动缓存的开头有四个注意力汇令牌可以获得最佳性能。

他们还发现,即使添加了新的代币,而其他代币则被淘汰,每个代币的位置编码也必须保持不变。如果标记5被挤掉,则标记6必须保持编码为6,即使它现在是缓存中的第五个标记。

通过结合这两种想法,它们使StreamingLLM能够保持连续的对话,同时优于使用重新计算的流行方法。

例如,当缓存具有256个令牌时,重新计算方法需要63毫秒来解码新令牌,而StreamingLLM需要31毫秒。然而,如果缓存大小增长到4096个令牌,则新令牌的重新计算需要1411毫秒,而StreamingLLM只需要65毫秒。

“StreamingLLM的创新方法以注意力库机制为中心,确保了稳定的内存使用和性能,即使在处理长度高达400万个令牌的文本时也是如此,”新加坡国立大学计算机科学的总统级年轻教授杨友(音)说,他没有参与这项工作

卡内基梅隆大学机器学习和计算机科学系助理教授陈天琦也没有参与这项研究,他对此表示赞同,他说:“流媒体LLM可以顺利延长大型语言模型的会话长度。我们一直在使用它在iPhone上部署Mistral模型,并取得了巨大成功。”

研究人员还通过在所有训练样本中预先准备几个占位符标记,探索了注意力汇在模型训练中的使用。

他们发现,使用注意力汇进行训练可以使模型在缓存中只有一个注意力汇的情况下保持性能,而不是通常需要四个注意力汇来稳定预训练模型的性能。

但是,尽管StreamingLLM使模型能够进行连续的对话,但模型无法记住未存储在缓存中的单词。未来,研究人员计划通过研究检索被驱逐的代币或使模型能够记住以前的对话的方法来解决这一限制。

StreamingLLM已被纳入NVIDIA的大型语言模型优化库TensorRTLLM中。

这项工作的部分资金来自麻省理工学院沃森人工智能实验室、麻省理工大学科学中心和美国国家科学基金会。