光年AI - Page 95 of 101 - AI驱动流量增长 - AI资讯，AI营销，AI大模型，AI知识库

谷歌开源最强端侧小模型：2B参数越级跑赢GPT-3.5-Turbo，苹果15Pro运行飞快

谷歌也来卷「小」模型了，一出手就是王炸，胜过了比自己参数多得多的GPT-3.5、Mixtral竞品模型。今年 6 月底，谷歌开源了 9B、27B 版 Gemma 2 模型系列，并且自亮相以来，27B 版本迅速成为了大模型竞技场 LMSYS Chatbot Arena 中排名最高的开放模型之一，在真实对话任务中比其两倍规模以上的模型表现还要好。如今，仅仅过去了一个多月，谷歌在追求负责任 AI 的基础上，更加地考虑该系列模型的安全性和可访问性，并有了一系列新成果。此次，Gemma 2 不仅有了更轻量级「Gemma 2 2B」版本，还构建一个安全内容分类器模型「ShieldGemma」和一个模型可解释性工具「Gemma Scope」。具体如下： Gemma 2 2B 具有内置安全改进功能，实现了性能与效率的强大平衡； ShieldGemma 基于 Gemma 2 构建，用于过滤 AI 模型的输入和输出，确保用户安全； Gemma Scope 提供对模型内部工作原理的无与伦比的洞察力。其中，Gemma 2 2B 无疑是「最耀眼的仔」，它在大模型竞技场 LMSYS Chatbot Arena 中的结果令人眼前一亮：仅凭 20 亿参数就跑出了 1130 分，这一数值要高于 GPT-3.5-Turbo（0613）和 Mixtral-8x7b。这也意味着，Gemma 2 2B 将成为端侧模型的最佳选择。苹果机器学习研究（MLR）团队研究科学家 Awni Hannun 展示了 Gemma 2 2B 跑在 iPhone 15 pro 上的情况，使用了 4bit 量化版本，结果显示速度是相当快。视频来源：https://x.com/awnihannun/status/1818709510485389563 此外，对于前段时间很多大模型都翻了车的「9.9 和 9.11 谁大」的问题，Gemma 2 2B 也能轻松拿捏。图源：https://x.com/tuturetom/status/1818823253634564134 与此同时，从谷歌 Gemma 2 2B 的强大性能也可以看到一种趋势，即「小」模型逐渐拥有了与更大尺寸模型匹敌的底气和效能优势。这种趋势也引起了一些业内人士的关注，比如知名人工智能科学家、Lepton AI 创始人贾扬清提出了一种观点：大语言模型（LLM）的模型大小是否正在走 CNN 的老路呢？在 ImageNet 时代，我们看到参数大小快速增长，然后我们转向了更小、更高效的模型。这是在 LLM 时代之前，我们中的许多人可能已经忘记了。大型模型的曙光：我们以 AlexNet（2012）作为基线开始，然后经历了大约 3 年的模型大小增长。VGGNet（2014）在性能和尺寸方面都可称为强大的模型。缩小模型：GoogLeNet（2015）将模型大小从 GB 级缩小到 MB 级，缩小了 100 倍，同时保持了良好的性能。类似工作如 SqueezeNet（2015）和其他工作也遵循类似的趋势。合理的平衡：后来的工作如 ResNet（2015）、ResNeXT（2016）等，都保持了适中的模型大小。请注意，我们实际上很乐意使用更多的算力，但参数高效同样重要。设备端学习？MobileNet（2017）是谷歌的一项特别有趣的工作，占用空间很小，但性能却非常出色。上周，我的一个朋友告诉我「哇，我们仍然在使用 MobileNet，因为它在设备端具有出色的特征嵌入通用性」。是的，嵌入式嵌入是实实在在很好用。最后，贾扬清发出灵魂一问，「LLM 会遵循同样的趋势吗？」图像出自 Ghimire 等人论文《A Survey on Efficient Convolutional Neural Networks and Hardware Acceleration》。 Gemma 2 2B 越级超越 GPT-3.5 Turbo Gemma 2 家族新增 Gemma 2 2B 模型，备受大家期待。谷歌使用先进的 TPU v5e 硬件在庞大的 2 万亿个 token 上训练而成。这个轻量级模型是从更大的模型中蒸馏而来，产生了非常好的结果。由于其占用空间小，特别适合设备应用程序，可能会对移动 AI 和边缘计算产生重大影响。事实上，谷歌的 Gemma 2 2B 模型在 Chatbot Arena Elo Score 排名中胜过大型 AI 聊天机器人，展示了小型、更高效的语言模型的潜力。下图表显示了 Gemma 2 2B 与 GPT-3.5 和 Llama 2 等知名模型相比的卓越性能，挑战了「模型越大越好」的观念。 Gemma 2 2B 提供了：性能卓越：在同等规模下提供同类最佳性能，超越同类其他开源模型；部署灵活且经济高效：可在各种硬件上高效运行，从边缘设备和笔记本电脑到使用云部署如 Vertex AI 和 Google Kubernetes Engine (GKE) 。为了进一步提高速度，该模型使用了 NVIDIA TensorRT-LLM 库进行优化，并可作为 NVIDIA NIM 使用。此外，Gemma 2 2B 可与 Keras、JAX、Hugging Face、NVIDIA NeMo、Ollama、Gemma.cpp 以及即将推出的 MediaPipe 无缝集成，以简化开发；开源且易于访问：可用于研究和商业应用，由于它足够小，甚至可以在 Google Colab 的 T4 GPU 免费层上运行，使实验和开发比以往更加简单。从今天开始，用户可以从 Kaggle、Hugging Face、Vertex AI Model Garden 下载模型权重。用户还可以在 Google AI Studio 中试用其功能。下载权重地址：https://huggingface.co/collections/google/gemma-2-2b-release-66a20f3796a2ff2a7c76f98f Gemma 2 2B 的出现挑战了人工智能开发领域的主流观点，即模型越大，性能自然就越好。Gemma 2 2B 的成功表明，复杂的训练技术、高效的架构和高质量的数据集可以弥补原始参数数量的不足。这一突破可能对该领域产生深远的影响，有可能将焦点从争夺越来越大的模型转移到改进更小、更高效的模型。 Gemma 2 2B 的开发也凸显了模型压缩和蒸馏技术日益增长的重要性。通过有效地将较大模型中的知识提炼成较小的模型，研究人员可以在不牺牲性能的情况下创建更易于访问的 AI 工具。这种方法不仅降低了计算要求，还解决了训练和运行大型 AI 模型对环境影响的担忧。 ShieldGemma：最先进的安全分类器技术报告：https://storage.googleapis.com/deepmind-media/gemma/shieldgemma-report.pdf ShieldGemma 是一套先进的安全分类器，旨在检测和缓解 AI 模型输入和输出中的有害内容，帮助开发者负责任地部署模型。 ShieldGemma 专门针对四个关键危害领域进行设计：仇恨言论骚扰色情内容危险内容这些开放分类器是对负责任 AI 工具包（Responsible AI Toolkit）中现有安全分类器套件的补充。借助 ShieldGemma，用户可以创建更加安全、更好的 AI 应用 SOTA 性能：作为安全分类器，ShieldGemma 已经达到行业领先水平；规模不同：ShieldGemma 提供各种型号以满足不同的需求。2B 模型非常适合在线分类任务，而 9B 和 27B 版本则为不太关心延迟的离线应用程序提供了更高的性能。如下表所示，ShieldGemma (SG) 模型（2B、9B 和 27B）的表现均优于所有基线模型，包括 GPT-4。 Gemma Scope：让模型更加透明 Gemma Scope 旨在帮助 AI 研究界探索如何构建更易于理解、更可靠的 AI 系统。其为研究人员和开发人员提供了前所未有的透明度，让他们能够了解 Gemma 2 模型的决策过程。Gemma Scope 就像一台强大的显微镜，它使用稀疏自编码器 (SAE) 放大模型的内部工作原理，使其更易于解释。 Gemma Scope 技术报告：https://storage.googleapis.com/gemma-scope/gemma-scope-report.pdf SAE 可以帮助用户解析 Gemma 2 处理的那些复杂信息，将其扩展为更易于分析和理解的形式，因而研究人员可以获得有关 Gemma 2 如何识别模式、处理信息并最终做出预测的宝贵见解。以下是 Gemma Scope 具有开创性的原因：开放的 SAE：超过 400 个免费 SAE，涵盖 Gemma 2 2B 和 9B 的所有层；交互式演示：无需在 Neuronpedia 上编写代码即可探索 SAE 功能并分析模型行为；易于使用的存储库：提供了 SAE 和 Gemma 2 交互的代码和示例。参考链接： https://developers.googleblog.com/en/smaller-safer-more-transparent-advancing-responsible-ai-with-gemma/

还没排上SearchGPT？比Perplexity更好用的国产开源平替了解一下？

来自上海人工智能实验室。有 AI 在的科技圈，似乎没有中场休息。除了大模型发布不断，各家科技大厂也在寻找着第一个「杀手级」AI 应用的落脚之地。 OpenAI 首先瞄准的是谷歌 1750 亿美元的搜索业务市场。7 月 25 日，OpenAI 带着 AI 搜索引擎——SearchGPT 高调入场。在演示 demo 中，搜索引擎的使用体验不再像以往一样，需要我们逐个点开网页链接，判断信息有没有用。SearchGPT 像端上了一桌精美的套餐，所有答案都帮你总结好了。在演示 demo 中，SearchGPT 分析了在应季最适合种植哪种品种的番茄。不过，鉴于年初发布的 Sora 到目前都还未正式开放，估计很多人排上 SearchGPT 的体验名额也遥遥无期。然而，有一款国产的开源平替，在和能联网的 ChatGPT 和专攻 AI 搜索引擎的 Perplexity.ai 的 PK 中，它的回答在深度、广度和准确度方面都都秒了这两款明星产品。它甚至可以在不到 3 分钟内收集并整合 300 多页相关信息。这换成人类专家，需要大约 3 小时才能做完。这款「国货」就是多智能体框架 MindSearch（思・索），由来自中科大和上海人工智能实验室的研究团队联合研发。正如其名，MindSearch 是一个会「思索」的系统，面对你输入的问题，它将先调用负责充分「思」考问题的智能体，再启用全面搜「索」的智能体，这些智能体分工合作，理解你的需求，并为你呈上从互联网的五湖四海搜罗来的新鲜信息。论文链接：https://arxiv.org/abs/2407.20183 项目主页：https://mindsearch.netlify.app/ MindSearch 演示 demo 那么，MindSearch 是凭什么打败 ChatGPT 和 Perplexity.ai 的呢？和别的 AI 搜索引擎相比，MindSearch 有什么独到之处吗？答案还得从它的名字说起。MindSearch 的核心竞争力在于采用了多智能体框架模拟人的思维过程。如果向 Perplexity.ai 提问「王者荣耀当前赛季哪个射手最强？」它会直接搜索这个问题，并总结网上已有的回复。把这个问题交给 MindSearch，它会把这个问题拆解成一个逻辑链：「当前赛季是哪个赛季？」，「从哪些指标可以衡量王者荣耀的射手的强度？」，再汇总所能查询到的答案。技术实现 WebPlanner：基于图结构进行规划仅依靠向大型语言模型输入提示词的方式并不能胜任智能搜索引擎。首先，LLM 不能充分理解复杂问题中的拓扑关系，比如前一段挂在热搜上的大模型无法理解 9.9 和 9.11 谁大的问题，就是这个问题的生动注脚。字与字之间的关系，LLM 都很难在简单对话中理解，那么「这个季节种哪个品种的番茄最合适？」这种需要深入思考，分解成多个角度来回答的问题，对于 LLM 就更难了。换句话说，LLM 很难将用户的意图逐步转化为搜索任务，并提供准确的响应，因此它总是提供一些模版式的知识和套话。基于此，研究团队设计了高级规划器 WebPlanner，它通过构建有向无环图（DAG）来捕捉从提问到解答之间的最优执行路径。对于用户提出的每个问题 Q，WebPlanner 将其解决方案的轨迹表示为 G (Q) = ⟨V, E⟩。在这个图中，V 代表节点的集合，每个节点 v 代表一个独立的网页搜索任务，包括一个辅助的起始节点（代表初始问题）和一个结束节点（代表最终答案）。E 代表有向边，指示节点之间的逻辑和推理关系。研究团队进一步利用 LLM 优越的代码能力，引导模型编写代码与 DAG 图交互。为了实现这一点，研究团队预定义了原子代码函数，让模型可以在图中添加节点或边。在解答用户问题的过程中，LLM 先阅读整个对话，还有它在网上搜索到的信息。阅读完这些信息后，LLM 会根据这些信息产生一些思考和新的代码，这些代码将通过 Python 解释器添加在用于推理的图结构中。一旦有新节点加入图中，WebPlanner 将启动 WebSearcher 来执行搜索任务，并整理搜索到的信息。由于新节点只依赖于之前步骤中生成的节点，所以这些节点可以并行处理，大大提高了信息收集的速度。当所有的信息收集完毕，WebPlanner 将添加结束节点，输出最终答案。 WebSearcher：分层检索网页由于互联网上的信息实在太多，就算是 LLM 也不能一下子处理完所有的页面。针对这个问题，研究团队选择了先广泛搜索再精确选择的策略，设计了一个 RAG 智能体 ——WebSearcher。首先，LLM 将根据 WebPlanner 分配的问题，生成几个类似的搜索问题，扩大搜索的范围。接下来，系统将调用不同搜索引擎的 API 查询问题，例如分别在 Google、Bing 和 DuckDuckGo 查一下，得到网页的链接、标题和摘要等关键信息。接着，LLM 将从这些搜索结果中选出最重要的网页来仔细阅读，汇总得出最终答案。 MindSearch 中，LLM 如何管理上下文作为一个多智能体框架，MindSearch 为如何管理长上下文提供了全新尝试。当需要快速阅读大量网页时，由于最终答案只依赖 WebSearcher 的搜索结果，WebPlanner 将专注于分析用户提出的问题，不会被过长的网页信息分心。这种明确的分工也大大减少了上下文计算量。如何在多个智能体之间高效共享信息和上下文并非易事，研究团队在实证中发现，如果只依靠 WebPlanner 的分析，有可能会在信息收集阶段由于 WebSearcher 内部的局部感知场丢失有用的信息。为了解决这个问题，他们利用有向图边构建的拓扑关系来简化上下文如何在不同智能体间传递。具体来说，在 WebSearcher 执行搜索任务时，它的父节点以及根节点的回答将作为前缀添加在其回答中。因此，每个 WebSearcher 可以有效地专注于其子任务，同时不会丢失之前的相关上下文或者忘记最终的查询目标。本地部署 7 月初，上海人工智能实验室已经开源了搭载 MindSearch 架构的 InternLM2.5-7B-Chat 模型。除了直接点击链接，跳转到体验 Demo 试玩。研究团队还公开了 MindSearch 的完整前后端实现，基于智能体框架 Lagent，感兴趣的朋友可以在本地部署模型。在线 Demo：https://mindsearch.openxlab.org.cn/ 开源代码：https://github.com/InternLM/mindsearch 在 GitHub 下载 MindSearch 仓库后，输入如下命令就可以打造属于自己的 MindSearch 了： # 启动服务python -m mindsearch.app --lang en --model_format internlm_server## 一键启动多种前端# Install Node.js and npm# for Ubuntusudo apt install nodejs npm# for windows# download from https://nodejs.org/zh-cn/download/prebuilt-installer# Install dependenciescd frontend/Reactnpm installnpm start

OpenDevin出技术报告了，大模型Agent开发者必读

热门通用大模型 Agent 平台。今年 3 月，「全球首位 AI 软件工程师」Devin 引爆了 AI 圈。与此前 AI 编程助手不同的是，Devin 并不只是辅助编程的角色，而是能够独立地、端到端地完成整个开发项目。 Devin 的出世让我们领略了大模型 Agent 的强大能力。很快，业界就出现了众多尝试复刻它的开源项目，其中 OpenDevin 脱颖而出，受到了人们最多的关注。 OpenDevin 是一个开发通过软件与世界互动的通用智能体的平台，其特点包括：大模型 Agent、接口和环境之间交互的交互机制； Agent 可用的沙盒操作系统 + Web 浏览器环境；可创建和执行代码的接口；多 Agent 支持；评估框架。目前，OpenDevin 的 GitHub 已经获得了超过 2.9 万 Star 量。近日，OpenaDevin 团队发布了该工具的技术报告。报告地址：https://arxiv.org/pdf/2407.16741 在技术报告中，OpenDevin 的作者，来自伊利诺伊大学香槟分校、卡耐基梅隆大学等机构的学者们详细介绍了 OpenDevin，这是一个社区驱动的平台，旨在开发通过软件与世界交互的通用和专业 AI Agent。更重要的是，OpenDevin 不仅是一个概念框架，它还包括一个全面且可立即使用的 Agent、环境和评估实现。截至本报告发布时，OpenDevin 包含一个 Agent 中心，其中已实现 10 多个智能体，包括一个基于 CodeAct 架构实现的强大的通用智能体，并增加了用于 Web 浏览和代码编辑功能。用户与智能体的交互是通过聊天界面实现的，该界面可视化智能体当前操作并允许实时反馈。此外，评估框架目前支持 15 个基准，可使用它们来评估智能体性能。 OpenDevin 架构本文中，作者从以下几个方面描述 OpenDevin：（1）如何定义和实现智能体；（2）动作执行如何促进观察；（3）如何管理和扩展智能体常用的技能；（4）如何将多个智能体组合在一起以解决任务。如何定义和实现智能体智能体可以感知环境状态，并在解决用户指定的任务时生成要执行的操作。状态和事件流。在 OpenDevin 中，状态是一种数据结构，它封装了智能体执行任务的所有相关信息。此状态的一个关键组成部分是事件流，是按照时间顺序收集过去的动作和观察。动作。受 CodeAct 的启发，OpenDevin 通过一组核心的动作将智能体与环境连接起来。动作 IPythonRunCellAction 和 CmdRunAction 使智能体能够在沙盒环境（例如，安全隔离的 Linux 操作系统）内执行任意 Python 代码和 bash 命令。而 BrowserInteractiveAction 支持智能体与 Web 浏览器交互。观察。观察描述了智能体观察到的环境变化。它可能由智能体的动作引起，也可能不是：它可以是 1) 用户提出的自然语言指令，2) 智能体先前动作的执行结果（例如，代码执行结果等）。实现新的智能体。智能体设计简单但功能强大，从而允许用户轻松创建和定制用于各种任务的智能体。核心在于 step 函数，它将当前状态作为输入并根据智能体的逻辑生成适当的动作。图 2 显示了智能体抽象的简化示例代码。观察动作执行结果 Agent Runtime 为智能体提供了与人类软件开发人员相当的动作空间，使 OpenDevin 能够处理各种软件开发和基于 Web 的任务，包括复杂的软件开发工作流程、数据分析项目、Web 浏览任务等。它允许智能体访问 bash 终端来运行代码和命令行工具，利用 Jupyter notebook 即时编写和执行代码，并与 Web 浏览器交互以执行基于 Web 的任务（例如，信息搜索）。可扩展的智能体 – 计算机接口作者构建了一个 AgentSkills 库，这是一个旨在增强智能体功能的工具箱，能够提供基本 bash 命令或 python 代码无法轻松获得的实用程序。多智能体交互 OpenDevin 允许多个智能体进行交互。为了实现这一目标，作者使用了一种特殊的动作类型 AgentDelegateAction，它允许智能体将特定的子任务委托给另一个智能体。评估本节将 OpenDevin （以下实验结果中简写为 OD）与开源可复现的基线方法进行了比较。这 15 个基准涵盖软件工程、网页浏览等任务。表 3 表明，虽然 OpenDevin 智能体可能无法在每个类别中都达到最佳性能，但其设计考虑了通用性。表 4 报告了智能体在软件工程基准上的结果。具体而言： SWE-bench 旨在评估智能体解决 GitHub 问题的能力，如 bug 报告或功能请求。如表 4 所示，本文最新版本的 CodeActAgent v1.8 ，基于 claude-3.5-sonnet，与其他专门用于软件开发的开源智能体相比，解决问题率高达 26%。 HumanEvalFix。OpenDevin CodeActAgent 成功修复了 Python 拆分中 79.3% 的错误，明显优于所有非智能体方法，几乎是 StarCoder2-15B 性能的两倍。基于 GPT-4o 的 OpenDevin 智能体在 ML-Bench 上实现了 76.47% 的最高成功率，优于 SWE-Agent（42.64%）。 Gorilla APIBench 考察智能体使用 API 的能力。使用 GPT-4o 的 OpenDevin 的成功率为 36.4%，优于未针对 API 调用进行专门微调的基线。 ToolQA 评估智能体使用外部工具的能力。与所有基线相比，采用 GPT-4o 的 OpenDevin 表现出最高的性能。智能体在与 CSV 和数据库工具使用相关的任务上表现更好，但在数学和计算器工具使用方面需要改进。表 5 报告了网页浏览基准的评估结果。表 6 报告了各种辅助基准的结果。其中，GAIA 用于评估智能体解决一般任务的能力，结果显示，智能体在 GAIA 上取得了 32.1 分，比原来的 AutoGPT 有了明显的提高。 GPQA 用于评估智能体在解决具有挑战性的研究生水平问题时协调使用工具的能力。结果如表 6、7 所示，OpenDevin 集成了支持多种工具使用以及 web 搜索的功能，使得智能体能够更好地解决复杂的多步骤问题。

谷歌终于赢了OpenAI一回：实验版本Gemini 1.5 Pro超越GPT-4o

苹果让大模型学会偷懒：更快吐出第一个token，准确度还保住了

偷懒才能更好地工作。 Llama 3.1 刚刚发布，你是否已经尝试了呢？就算你的个人计算机是最近的顶尖配置，运行其中最小的 8B 版本可能也依然会有明显延迟。为了提升模型的推理效率，研究者想出了多种多样的方法，但其中很多都会让模型牺牲一些准确度。近日，苹果和 Meta AI 的一个研究团队提出了一种新方法，可在保证准确度不明显下降的同时，将 Llama 2 预填充阶段的推理速度提升到原来的 2 倍以上，这或许能为 Llama 3.1 的加速提供一些启发。他们把这种方法称为 LazyLLM，即懒惰大型语言模型。论文标题：LazyLLM: Dynamic Token Pruning for Efficient Long Context LLM Inference 论文地址：https://arxiv.org/abs/2407.14057 那么他们是怎么让 LLM 偷懒的呢？要理解他们的方法，我们首先需要知道标准的基于 prompt 的 LLM 推理过程是怎样的。简单来说，该过程分为两个阶段：预填充和解码，如图 1 所示。在预填充阶段，模型计算和保存 prompt 中每个 token 的 KV 缓存，并预测首个 token。我们将预填充阶段所耗费的时间称为「首个 token 时间（TTFT）」。预填充阶段之后是解码阶段。在这个阶段，模型再次使用缓存的 KV 来迭代式地解码下一个 token，直到满足停止标准。在预填充阶段，所有 Transformer 层都会使用 prompt 中的所有 token。当 prompt 较长时，TTFT 可能很慢，因为当前最佳的基于 Transformer 的 LLM 既深又宽，并且计算注意力的成本会随 prompt 中 token 数量而呈二次增长。举个例子，Llama 2（7B 版本）堆叠了 32 层 Transformer，模型维度为 4096。在这种情况下，TTFT 需要的 walltime 是每个后续解码步骤的 21 倍，在 LongBench 基准上这些时间大约占用了总生成时间的 23%。因此，要让 LLM 推理高效进行，优化 TTFT 是非常关键的步骤。尽管 LLM 推理优化方面是一个活跃的研究领域，但很多方法关注的重心都是提升解码阶段的推理速度。研究者很少关注 TTFT 的改进。一些基于压缩的研究成果可通过减少 LLM 的大小隐式地提升 TTFT。另一个研究方向是在静态的 Transformer 架构下实现对 TTFT 的改进。对于这个研究方向，很自然会引出一个问题：在生成首个 token 时，所有 prompt token 都必不可少吗？图 2 给出了在 LongBench 基准上的 LLM 分析结果。可以看到，对于首个生成的 token，输入 token 的注意力分数非常稀疏，这说明输入 prompt 中的许多 token 是多余的，就算移除也不会影响到下一 token 预测。这一观察正是该团队提出 LazyLLM 的基础。 LazyLLM 的优势包括适用范围广、无需训练、效果好。图 3 对比了标准 LLM 与 LazyLLM。 LazyLLM 图 4 展示了 LazyLLM 的整体框架。从完整上下文开始，LazyLLM 会逐渐对 token 进行剪枝，从而逐渐减少得到最终模型所使用的计算数量。请注意，LazyLLM 允许模型在不同的生成步骤选取不同的 token 子集，即便它们中的一些可能在之前的步骤中被剪枝了。相比于静态剪枝（一次性对所有 token 进行剪枝），动态剪枝会在每个生成步骤对下一 token 预测进行优化，这有助于维持模型的性能表现。渐进式 token 剪枝之前也有一些研究成功使用过 token 剪枝来优化 LLM 推理。但是，这些方法需要积累预测前几个 token 的完整注意力图，以便在剪枝开始之前分析 prompt token 的重要性。也因此，它们不适合用于降低 TTFT，因为它们在预填充阶段仍需要计算所有 KV 缓存。相较之下，LazyLLM 「很懒」，会从推理的第一轮迭代（预填充步骤）开始，只计算对预测下一 token 重要的 token。在第一轮迭代中，一大关键难题是确定各个 token 的重要性。受之前已有研究（其中表明 token 隐藏状态会在穿过 Transformer 层时发生演进）的启发，该团队的解决方案是在每个生成步骤使用逐层 token 剪枝。具体来说，他们是使用各层的注意力图来确定输入 token 对将要预测的 token 的重要性。在计算了 token 的置信度分数之后，另一个难题是确定剪枝 token 的阈值。具体来说，对于不同的层和不同的任务，该阈值可能会随注意力分数的变化而改变。该团队的解决思路是使用 top-k 百分位数选取策略。具体来说，如果一个 token 的置信度分数小于输入 token 中的第 k 个百分位数，便将其剪枝掉。一旦 token 被剪枝去掉了，它就不再参与所有后续层的计算。也就是说，后续层使用的 token 是之前层所使用 token 的子集。后面的实验表明，剪枝层的位置和剪枝的 token 数量不同时，也会导致性能发生变化。具体来说，对于同一 Transformer 层，随着被剪枝去掉的 token 越来越多，模型的性能也会逐渐下降。他们还发现，相比于早期层的剪枝，在后期层执行剪枝时会得到更好的性能，这说明后期层对 token 剪枝的敏感度更低。为了更好地平衡速度与准确度，该团队使用了如图 4 所示的渐进式剪枝法，从而在早期层保留更多 token，然后在 token 流向后期层的过程中逐渐减少 token 的数量。 Aux Cache（辅助缓存）预填充阶段没有 KV 缓存，每个 token 都表示成隐藏状态。因此，可通过移除已被剪枝 token 的隐藏状态来实现渐进式 token 剪枝。但是，要将渐进式 token 剪枝扩展到后续的解码步骤，却并不简单。原因是每个解码步骤都会使用预填充阶段计算的 KV 缓存来计算注意力。由于 LazyLLM 是在预填充阶段执行渐进式 token 剪枝，因此在某一层被剪枝的 token 的 KV 不会出现在下一层的 KV 缓存中。这里提醒一下，LazyLLM 框架允许在每一步让每个生成步骤从完整的输入 token 序列中挑选一个不同的 token 子集，无论它们是否已在之前的步骤中被剪枝。举个例子，在接下来的解码步骤中，那些在 KV 缓存中不存在的已被剪枝的 token 可能会被重新选取出来用于计算注意力。在这种情况下，模型无法检索到这些 token 的 KV 缓存。对此，一个基于直觉的解决方案是再让这些 token 通过该 Transformer 的起点。但是，这会导致对同一 token 的重复计算，并最终减慢整体的生成速度。为解决这个难题，该团队在原有的 KV 缓存之外引入了另一种缓存：Aux Cache（辅助缓存）。如果已被剪枝 token（如图 4 中 T4 和 T7）的 KV 并未出现在后续层的 KV 缓存中，则会由 Aux Cache 保存它们的隐藏状态以供后续迭代检索。如图 4 所示，在每个解码步骤，每个 Transformer 层首先会检索过去 token 的 KV 缓存（如果存在的话）。对于那些不在 KV 缓存中的 token，则直接从其前一层的 Aux Cache 中检索它们的隐藏状态，而不必再次经过之前的层。Aux Cache 可确保每个 token 在每个 Transformer 层中最多被计算一次，还能确保 LazyLLM 最慢时也比标准 LLM 快。实验该团队在两个大型语言模型上检验了这种「懒惰」新方法：Llama 2 7B 和 XGen 7B。作为对比的标准 LLM 是同样的公开发布的预训练检查点模型，同时不进行任何附加训练。实验基准是 LongBench，这是一个针对长内容理解的多任务基准。LongBench 基准包含 16 个数据集，涉及 6 个任务，包括单文档问答、多文档问答、总结、少样本学习、合成任务和代码补全。评估指标是每种方法在 TTFT 加速与准确度权衡方面的效果和效率。结果表 1 给出了 LazyLLM、标准 LLM 和其它基线方法的 TTFT 加速和准确度结果。在此表中，baseline 是指标准 LLM 推理。random token drop 是指对 token 执行随机剪枝。static token pruning 是指在预填充阶段基于前面几个 Transformer 层的注意力方法来对输入 token 执行一次性剪枝。Prompt Compression 就是 prompt 压缩方法，也就是使用 LLM 去除输入上下文中的冗余。从表 1 可以看到，LazyLLM 在 TTFT 加速方面全面优胜，同时准确度方面的下降基本可以忽略不计。需要指出，使用 LLM 来压缩 prompt 需要大量计算。因此，即使 Prompt Compression 能让推理速度更快，但其实际的 TTFT 却比标准 LLM 还长。对总体生成速度的影响为了评估新方法对总体生成速度的影响，该团队分析了计算使用的 prompt token 百分比和生成加速情况，见表 2。可以看到，LazyLLM 计算使用的 token 的占比总是低于 100%，这说明 LazyLLM 在生成结束时也没有用完 prompt 中的所有 token，但理论上讲该模型可以使用所有 token。这能为不同任务的整体生成过程提供额外的加速。不同层的丢弃率该团队也分析了剪枝层的位置和被剪枝 token 的数量的影响。结果见图 6。可以看到，当在同一 Transformer 层进行剪枝时，留下的 token 越少，模型的性能越差。这也符合我们的直观认知。此外，相比于在更前期 Transformer 层执行剪枝，在后期层进行剪枝会得到更好的性能，这说明后期层对 token 剪枝的敏感度更低。基于这些观察，可以说渐进式 token 剪枝的效果得到了证明。渐进式 KV 增长最后，该团队也尝试了理解使用 token 剪枝逻辑的模型的内部情况。具体来说，他们想要了解 prompt token 中的累积使用比例以及相应的不被使用的比例。这种「累积 token 使用量」可以等价地定义成每一步的 KV 缓存大小。图 7 给出了 LazyLLM 的每个阶段这些累积的 prompt token 使用量。该结果支持这一假设：许多 token 永远不会被模型选择（即便理论上讲模型可以使用 prompt 中的所有 token。考虑到模型依然能维持执行任务的准确度，因此可以得出结论：模型可以有效地丢弃不影响输出质量的 token。

Transformer作者回流谷歌，Character.AI创始团队被「收购」，只要人不要公司

AI 初创者的归宿还是大厂？一觉醒来，生成式 AI 的「吃鸡大赛」再次缩圈了。初创公司 Character.AI 周五宣布已与谷歌签署协议，谷歌将获得 Character.AI 的大型语言模型（LLM）技术的非独家许可。谷歌还宣布重新雇佣 Noam Shazeer 和 Daniel De Freitas。其中，Noam Shazeer 是 Character.AI 的创始人、CEO，也是 Transformer 论文作者之一，他曾在谷歌任首席软件工程师。而 Daniel De Freitas 是 Character.AI 的总裁，曾在谷歌担任高级软件工程师。 Daniel de Freitas（左）和 Noam Shazeer。图源：https://www.bizjournals.com/sanjose/inno/stories/news/2023/03/24/q-a-interview-with-characterai-founders.html 2021 年，Noam Shazeer 和 Daniel De Freitas 因对谷歌这家搜索巨头的官僚主义感到失望而离开谷歌，并在 2022 年创办了 Character.AI。而现在，他们又将与约 30 人的研究团队一起回到 Google DeepMind 工作。谷歌发言人在一封电子邮件中表示：「我们特别高兴地欢迎 Noam 回来，他是机器学习领域的杰出研究员。」 Character.AI 剩余的大约 140 名员工将留下来，面临着下一步抉择。Character.AI 官方发布了一份公开信，内容如下： 2022 年，我们创立了 Character.AI，旨在为全球用户带来个性化的超级智能。在过去的两年里，我们在这一目标上取得了巨大进展。我们构建了越来越智能的模型，推出了与虚拟角色对话的沉浸式新功能，并迅速发展到服务数百万用户，成为他们日常生活的一部分。当 Noam 和 Daniel 创办 Character.AI 时，我们实现个性化超级智能的目标需要全栈式方法。我们必须对模型进行预训练和后训练，以保证用户在 Character.AI 上能够获得独特的体验，并构建一个能够使全球用户共同使用的平台。然而，在过去的两年里，技术环境发生了变化 —— 现在有更多的预训练模型可用。鉴于这些变化，我们认为联合利用第三方大型语言模型（LLM）和我们自己的模型将具有优势。这使我们能够投入更多资源用于后训练和为不断增长的用户群体创造新的产品体验。我们很高兴地宣布，我们已与谷歌达成协议，这将使我们能够加速进步。根据该协议，Character.AI 将为谷歌提供现有 LLM 技术的非独家许可。这项协议将为 Character.AI 提供更多资金，以继续增长，并专注于为全球用户构建个性化 AI 产品。 Noam、Daniel 和我们研究团队的部分成员也将加入谷歌。Character.AI 的大多数才华横溢的团队成员将继续留在公司，继续构建 Character.AI 产品并服务于我们不断增长的用户群。 Character.AI 的总法律顾问 Dominic Perella 已担任临时首席执行官一职。Perella 之前是 Snap Inc. 的长期高管，自 2023 年中期以来一直是 Character.AI 核心领导团队的一员。这些变动将立即生效。在我们进入下一个增长阶段时，我们将继续投资于我们的后训练能力，灵活使用我们自己的或外部可用的大语言模型。我们对 Character.AI 的未来充满期待，并致力于通过创新型产品来服务我们的用户。我们对 Noam、Daniel 和其他团队使 Character.AI 从梦想化为现实表示无比感激。我们期待在他们已有贡献的基础上，Character.AI 在下一个增长阶段继续航行。虽然在技术层面上，公司的股份没有易手，但谷歌会以 25 亿美元的估值向 Character.AI 的投资者支付其股权价值。据消息人士透露，Character.AI 的员工也将根据其已归属的股份按该估值获得现金，并且随着其现有股票转移归属，他们还将获得偿付。 Character.AI 此前从包括 Andreessen Horowitz 在内的投资者处筹集了 1.93 亿美元的风险资本，其最后一次已知估值为 10 亿美元。该公司也曾在谈判中表示希望从谷歌筹集数亿美元资金。这一协议类似于微软、亚马逊等公司在过去几个月与初创公司达成的协议。这些协议正受到监管机构的审查。科技巨头正投入数十亿美元来增强其 AI 基础设施，并从初创公司中招聘最优秀的研究人员。今年 3 月，微软支付 6.5 亿美元引入 AI 初创公司 Inflection 的联合创始人及数十名员工。前 Inflection 首席执行官 Mustafa Suleyman，已成为微软执行副总裁和新成立的微软 AI 组织的首席执行官。前 Inflection 首席执行官 Mustafa Suleyman。与之相似，6 月，亚马逊则从另一家 AI 初创公司 Adept 中招聘了多名联合创始人和员工。这场从 AI 初创公司招募人才以扩展羽翼，为业务再开发赋能的战略部署已初见端倪。大型科技企业对 AI 初创公司的「蚕食」可能才刚刚开始。参考链接： https://www.theverge.com/2024/8/2/24212348/google-hires-character-ai-noam-shazeer https://www.reuters.com/technology/artificial-intelligence/google-hires-characterai-cofounders-licenses-its-models-information-reports-2024-08-02/ https://blog.character.ai/our-next-phase-of-growth/

全员离开老东家，Stable Diffusion一作带团创业，出手即击败MJ v6、SD3，还开源

AI 图像和视频生成领域又加入了一个颇有实力的玩家。还记得今年 3 月底，从 AI 初创公司 Stability AI 离职的研究科学家 Robin Rombach 吗？作为开发出文生图模型 Stable Diffusion 的两位主要作者之一，他于 2022 年加入 Stability AI。如今，在从 Stability AI 离职近五个月后，Robin Rombach 发推宣布了自己创业的好消息！他成立了「Black Forest Labs」，旨在推进用于图像和视频的 SOTA 高质量生成式深度学习模型，并开放给尽可能多的人使用。团队成员由杰出的 AI 研究者和工程师组成，他们之前的代表性工作包括 VQGAN 和 Latent Diffusion、图像和视频生成领域的 Stable Diffusion 模型（包括 Stable Diffusion XL、Stable Video Diffusion 和 Rectified Flow Transformers）以及用于超快实时图像合成的 Adversarial Diffusion Distillation。值得注意的是，除了 Robin Rombach 之外，Stable Diffusion 还有三位作者成为了创始团队成员，包括 Andreas Blattmann、 Dominik Lorenz 和 Patrick Esser。他们都在今年早些时候离开了 Stability AI，有人猜测他们当初离开就是为了自己创业。目前，该 Labs 已经完成 3100 万美元的种子轮融资，由 Andreessen Horowitz 领投。其他投资者包括了天使投资人 Brendan Iribe、Michael Ovitz、Garry Tan、Timo Aila、Vladlen Koltun 以及一些知名 AI 研究和创业专家。此外还获得了来自 General Catalyst 和 MätchVC 的后续投资。该 Labs 还成立了顾问委员会，成员包括在内容创作行业具有广泛经验的科技大佬 Michael Ovitz 和神经风格迁移先驱、欧洲开放 AI 研究的顶级专家 Matthias Bethge 教授。当然，Black Forest Labs 推出了首个模型系列「FLUX.1」，包含了以下三个变体模型。第一个变体是 FLUX.1 [pro]，它是全新的 SOTA 文生图模型，具有极其丰富的图像细节、极强的 prompt 遵循能力和多样化风格。目前可以通过 API 使用。 API 地址：https://docs.bfl.ml/ 第二个是 FLUX.1 [dev]，它是 FLUX.1 [pro] 的开放权重、非商用变体，并直接基于后者蒸馏而成。该模型的表现优于 Midjourney 和 Stable Diffusion 3 等其他图像模型。推理代码和权重已经放在了 GitHub 上。下图是与竞品图像模型的比较。 GitHub 地址：https://github.com/black-forest-labs/flux 第三个是开源的 FLUX.1 [schnell]，它是超高效的 4-step 模型，遵循了 Apache 2.0 协议。该模型在性能上与 [dev]、[pro] 非常接近，可以在 Hugging Face 上使用。 Hugging Face 地址：https://huggingface.co/black-forest-labs/FLUX.1-schnell 与此同时，Black Forest Labs 也开始宣传自己了。下一步的目标是推出所有人可用的 SOTA 文生视频模型，大家可以期待一波了！一出手即王炸：文生图模型系列「FLUX.1」来袭这次 Black Forest Labs 推出的三款模型，均采用了多模态和并行扩散 Transformer 的混合架构。不同于其他家将一系列模型按参数量分为「中杯」、「大杯」、「超大杯」，FLUX.1 家族的成员统一扩展为 120 亿参数的庞大规模。研究团队采用了流匹配（Flow Matching）框架对之前 SOTA 扩散模型进行了升级。从官方博客的注释中可以推测，研究团队沿用了还在 Stability AI 任职时（今年 3 月）提出的 Rectified flow+Transformer 方法。论文链接：https://arxiv.org/pdf/2403.03206.pdf 他们还引入了旋转位置嵌入和并行注意力层。这些方法有效提高了模型生成图片的性能，在硬件设备上生成图片的速度也变得更快了。这次 Black Forest Labs 并未公开模型的详细技术，不过更详细的技术报告将很快公布。这三款模型在各自的领域都确立了新标准。无论是生成图像的美观度、图像与文本提示词的附和度、尺寸 / 宽高比可变性、还是输出格式的多样性， FLUX.1 [pro] 和 FLUX.1 [dev] 都超越了一系列当红图片生成模型，如 Midjourney v6.0、DALL・E 3 (HD) 以及老东家 SD3-Ultra。 FLUX.1 [schnell] 是迄今为止最先进的少步骤模型（few-step model），不仅超越了同类竞争对手，还超越了像 Midjourney v6.0 和 DALL・E 3 (HD) 这样的强大非蒸馏模型。模型经过专门微调，以保留预训练阶段的全部输出多样性。与当前最先进的技术相比，FLUX.1 系列模型还保留了充分的进步空间。所有 FLUX.1 系列的模型都支持多种纵横比和分辨率，从 0.1 到 2 百万像素，都能拿下。已经有动作快的网友抢先体验上了，看来 Black Forest Labs 反复强调的「最强」，并不只是自卖自夸。简单的提示词，就可以打造出这样的效果，仔细看羊驼身上垫子的花纹，也没有出现扭曲和变形。提示词：An emerald Emu riding on top of a white llama. 如果不说这是 AI 生成的图片，也挺难分辨这是不是摄影师拍下的照片。提示词：A horse is playing with two aligators at the river. 含有文字的图像，也能轻松拿捏，景深也处理得很符合真实的镜头感。三款模型中，性能稍弱的 FLUX.1 [schnell]，用起来也是又快又强，有网友晒出在 Mac 上运行的体验，不得不感慨，真是立等可取。不太了解 Stable Diffusion 的作者们和 Stability AI 之间「恩怨情仇」的网友感叹道：不知道从哪里冒出来了个文生图模型，简直强到可怕。关于 Stable Diffusion 作者和前司 Stability AI 的故事，可以看看机器之心之前的报道：价值1亿美金时，Stable Diffusion背后的团队开始互撕，谁才是真官方？除了三款最强的文生图模型，Black Forest Labs 还憋着「大招」呢。有了如此强大的图片生成模型的能力，Black Forest Labs 为视频生成模型打下了坚实的基础，正如他们所预告的，这些计算机视觉的顶级科学家们正朝着为所有人提供的最先进文生视频技术的目标前进。参考链接：公司博客：https://blackforestlabs.ai/announcements/

ICML 2024演讲爆火！Meta朱泽园揭秘大模型内心世界：不同于人类的2级推理

大语言模型 (LLM) 是如何解数学题的？是通过模板记忆，还是真的学会了推理思维？模型的心算过程是怎样的？能学会怎样的推理技能？与人类相同，还是超越了人类？只学一种类型的数学题，是会对通用智能的发展产生帮助？LLM 为什么会犯推理错误？多大多深的 LLM 才能做推理？论文地址：https://arxiv.org/abs/2407.20311 近日，来自 Meta FAIR、CMU 和 MBZUAI 的叶添、徐子诚、李远志、朱泽园四人团队最新公布 arXiv 论文《语言模型物理学 Part 2.1：小学数学与隐藏的推理过程》用可控实验，巧妙地回答上述问题。推特网友 @xlr8harder 评价，「这一结果将一劳永逸地平息关于 LLM 是否具有推理能力，或者只是随机鹦鹉的争论。」编者注：《语言模型物理学》全系列受邀于 7 月 22 日在 ICML 2024 国际机器学习顶级大会上进行了两小时的专题报告，反响热烈，据悉现场掌声不断。这里为大家呈现系列中的 Part 2.1。图 1 论文详解首先，根据本系列的惯例，作者认为不应通过与 GPT-4 等大模型对话来猜测其思维方式，这类似于动物行为学，虽可行但不够严谨，无法科学地揭示 GPT-4 的内心思考过程。此外，从数据角度看，只有完全访问模型的预训练集（pretrain data），才能明确哪些题目是模型见过的，哪些是通过推理学会的。即使模型在 GSM8k（包含 8000 道小学数学题的基准测试集）上获得高分，也难以判断它是否见过这些题目的变体（如不同语言或 GPT-4 改写后的变体）。为此，作者创建了 iGSM，一个人工合成的、模拟小学数学级别的思维题集，并让模型从零开始在 iGSM 上预训练，以控制模型接触的问题类别。值得注意的是，iGSM 不包含常识信息，只包含 mod 23 范围内的加减乘，并且所有计算都使用 CoT 逐步进行。通过 iGSM，可进行可控实验，专门研究模型的推理能力，而忽略了其他因素（如大整数运算）。图 2 展示了一个简单的例题。图 2 通过这个数据集，作者首先测试了 GPT2（RoPE 版）的表现。用 op 代表解题所需的数学运算步数，作者发现，当在 op≤21 的题目上进行训练时，模型不仅能达到 99% 正确率，还能在更高难度的题目（如 op=32）上保持 83% 的正确率（见图 3）。这表明模型学会了某种推理技能，毕竟它从未见过 op>21 的题。（顺带一提，GPT-4o 在该数据集上仅能应对 op=10 的题目，超过这个难度就如同盲猜，文末我们会讨论这个问题。）那模型究竟学会了怎样的推理技能呢？解决 iGSM 的数学题至少有两种思路。一种是作者称为「0 级推理」，即「暴力计算能算则算」。由于题目中的变量可能存在复杂的依赖关系，有些可以直接计算，有些则需要先算出其他变量 —— 譬如小张比小王多 3 倍的水果，那么就要先算出小王有多少苹果、梨子并求和，才可以开始计算小张的水果数。「0 级推理」就是尽可能枚举所有变量，每次随机找到一个可计算的变量，算出结果并继续。与之对应的是「1 级推理」：通过拓扑排序，从问题开始反推，确定哪些变量需要计算，然后从叶子节点开始向上计算，力求「最短解答」。常见的数学题解通常采用 1 级推理，不会去计算「不必要的变量」。例如小张比小王多 3 倍的水果，问小张有多少水果，那小李的苹果数就是不必要的变量，而小王的苹果、梨子数都是必要的。如图 3 所示，作者发现，GPT-2 可以学会 1 级推理，几乎每次都给出最短解答。这非常不简单！因为在模型生成第一句话之前，必须已经在脑海中完成了整个拓扑排序 —— 否则它怎么知道哪个变量是不必要的？如果模型一开始就生成了「小李的苹果有 7 个」，那就无法回头，得不到最短解答。图 3 那么，模型是如何学会「1 级推理」的？为此，作者对模型的内部参数进行了探针 probing 研究（见图 4）。结论显示（具体探针方法详见论文），在模型生成第一句话之前，它已经通过心算确定了哪些变量 A 是「必要的」（nece (A)=True）。同时，模型在说每句话之后，也心算出了接下来所有「可计算的」的变量 A（cannext (A)=True）。因此，模型只需对 nece 和 cannext 不断进行逻辑与（AND）运算，就能从叶子节点开始，一步步给出完整的计算过程。值得注意的是，这些复杂的心算能力并没有显现在训练集中。模型只接触过 iGSM 数据，只见过「语言」部分（题目和答案），但它却自主学会了类似人类的思维过程（mental process），并得出了最优解！换言之，这项研究反驳了我们一周前在《语言≠思维，大模型学不了推理：一篇 Nature 让 AI 社区炸锅了》中的报道，用科学方法证明了大模型通过语言确实能学会思维。更神奇的是，模型学到的不止如此。在图 4 中，作者还发现模型会心算许多对解题无用的信息。比如，在变量关系刚被描述完，甚至在问题尚未提出之前，模型已经知道任意两个变量 A 和 B 之间是否存在递归依赖 —— 即使这些变量与解题无关。对人类来说，我们通常会从问题开始反推，忽略不必要的变量，而 GPT-2 这样的语言模型则会将整个关系图梳理一遍，以应对将来可能被问及的任何问题。作者将这种能力称为「2 级推理」。虽然「2 级推理」对解题不必须，但它确实是一种更通用的技能。模型利用并行能力，对信息进行大量因果梳理。这一能力是语言模型在学习解题中自行掌握的，没有人 (数据) 教过它这么做。作者猜测，这或许是通用人工智能（AGI）中「通用」一词的潜在来源，即语言模型可以超越数据集所教的技能，学会更为通用的能力。图 4 接下来，作者研究了模型为何会犯错。总结来看，在 iGSM 数据集上，模型几乎只会犯两类错误：一是计算不必要的变量，二是计算当前不可算的变量，如图 5 所示。对于前者，作者发现，如果模型在生成答案之前就心算出错，误认为某个变量 A 是「必要的」（nece (A)=True），那么模型在生成答案时很可能会对 A 强行计算，从而产生非最短解答。这一发现非常有趣，它表明许多错误是系统性的，在生成第一个 token 之前，模型还没张嘴就可以确信它会犯错（通过探针的方法）。这类错误与模型生成过程中的随机性或 beam search 无关。至于后者，作者也将其归因于心算错误，并将用一整篇的后续 Part 2.2 论文，来针对性提高模型的心算能力，以最终提高解题正确率。该论文尚未发布，我们会在公众号中继续关注并报道。图 5 下一个结论是，作者反驳了大模型缩放定律（scaling law）中强调的「唯大独尊」，即模型的表现只与参数数量相关，而与宽度或深度无关。这一观点最早由 OpenAI 的缩放定律论文提出，并在后续几乎所有研究中得到遵循。作者通过 iGSM 数据集进行了一个可控实验，如图 6 所示。通过对比更小更深的模型与更大更宽的模型，发现对于解决 iGSM 中的数学题，模型的深度显然比宽度更为重要。例如，一个 20 层、9 个 head 的模型，表现远好于 4 层、30 个 head 的模型，尽管后者有两倍的参数。更进一步，作者发现对深度的依赖源于模型心算的复杂性。通过对模型不同深度的探针研究，作者发现，对于那些与问题较远的变量 A，心算 nece (A) 往往需要更多层数。具体来说，若变量 A 与问题变量的距离为 t，则需要进行 t 步心算才能知道 nece (A)=True。t 越大，模型所需的层数也越多，如图 6 所示。作者强调，模型对深度的依赖无法通过思维链（Chain-of-Thought, CoT）来抵消。事实上，iGSM 中的数学题解已经尽可能地使用了 CoT，即所有计算都被拆解为一步一步。即便如此，模型仍需要通过心算来规划 CoT 的第一步该算什么 —— 这个心算过程可能依然需要多个步骤。这解释了模型对深度依赖的原因。图 6 综上所述，与 99% 以上的研究 LLM 行为过程（behavior process）的论文不同，本文作者另辟蹊径，揭示了 LLM 在解决数学问题时的心理过程（mental process），为理解 LLM 的智能提供了新的视角。文章最后作者指出，即便是 GPT-4，在 iGSM 数据集上也只能进行最多 10 步的推理。这表明，即使是当前最强的模型，利用了据称所有的互联网数据，仍无法精准地完成超过 10 步推理。这暗示现有大模型使用的预训练数据集（pretrain data）可能还有很大的改进空间。通过本文的方法，建立人工合成数据来增强模型的推理能力以及信息梳理能力，或许是一种新的可能。

首届大模型顶会COLM 高分论文：偏好搜索算法PairS，让大模型进行文本评估更高效

大模型展现出了卓越的指令跟从和任务泛化的能力，这种独特的能力源自 LLMs 在训练中使用了指令跟随数据以及人类反馈强化学习（RLHF）。在 RLHF 训练范式中，奖励模型根据排名比较数据与人类偏好对齐。这增强了 LLMs 与人类价值观的对齐，从而生成更好地帮助人类并遵守人类价值观的回应。近日，第一届大模型顶会 COLM 刚刚公布接收结果，其中一项高分工作分析了 LLM 作为文本评估器时难以避免和纠正的分数偏见问题，并提出了将评估问题转换成偏好排序问题，从而设计了 PairS 算法，一个可以从成对偏好（pairwise preference）中搜索和排序的算法。通过利用不确定性和 LLM 传递性（transitivity）的假设，PairS 可以给出高效，准确的偏好排序，并在多个测试集上展现出和人类判断更高的一致性。论文链接: https://arxiv.org/abs/2403.16950 论文标题：Aligning with Human Judgement: The Role of Pairwise Preference in Large Language Model Evaluators Github 地址: https://github.com/cambridgeltl/PairS 用大模型评估有什么问题？最近大量的工作展示了 LLMs 在评估文本质量上的出色表现，形成了一种无需参考的生成任务评估新范式，避免了昂贵的人类标注成本。然而，LLM 评估器（evaluator）对提示（prompt）设计高度敏感，甚至会受到多种偏见的影响，包括位置偏见、冗长偏见和上下文偏见。这些偏见阻碍了 LLM 评估器的公平和可信，导致与人类判断的不一致和不对齐。为了减少 LLMs 的偏见预测，之前的工作开发了校准技术（calibration）以减少 LLM 预测中的偏见。我们先对校准技术在对齐单点（pointwise） LLM 评估器的有效性进行了系统分析。如上图 2 所示，即使提供了监督数据，现有的校准方法仍然不能很好的对齐 LLM 评估器。如公式 1 所示，我们认为评估不对齐的主要原因并非 LLM 评估分数分布的先验具有偏见（biased priors over evaluation score distribution），而是评估标准（evaluation standard）的错位，即 LLM 评估器的似然（likelihood）。我们认为做成对（pairwise）评估时，LLM 评估器会与人类有更一致的评价标准，因此，我们探索了一种新的 LLM 评估范式，以促进更对齐的判断。 RLHF 带来的启发如下图 1 所示，受到 RLHF 中通过偏好数据对奖励模型进行对齐的启发，我们认为 LLM 评估器可以通过生成偏好排序（preference ranking）来得到更和人类对齐的预测。最近已有一些工作开始通过让 LLM 进行成对比较（pairwise comparison）来得到偏好排序。然而，评估偏好排序的复杂性和可扩展性在很大程度上被忽视了。它们忽略了传递性假设（transitivity assumption），使得比较次数的复杂度为 O (N^2)，让评估过程变得昂贵而不可行。 PairS：高效偏好搜索算法在本工作中，我们提出了两种成对偏好搜索算法（PairS-greedy 和 PairS-beam）。PairS-greedy 是基于完全的传递性假设和合并排序（merge sort）的算法，只需要通过 O (NlogN) 的复杂度就可以得到全局的偏好排序。传递性假设是指，比如对于 3 个候选项，LLM 总是有如果 A≻B 以及 B≻C，则 A≻C。在这个假设下我们可以直接用传统的排序算法从成对偏好中获得偏好排序。但是 LLM 并不具有完美的传递性，所以我们又设计了 PairS-beam 算法。在更宽松传递性假设下，我们推导并化简了偏好排序的似然函数（likelihood function）。PairS-beam 在合并排序算法的每一次的合并操作（merge operation）中按似然值做集束搜索，并通过偏好的不确定性（uncertainty）来减枝成对比较的空间的搜索方法。PairS-beam 可以调整对比复杂度和排序质量，高效的给出偏好排序的最大似然估计（MLE）。在下图 3 中我们展示了一个 PairS-beam 如何做合并操作的例子。实验结果我们在多个具有代表性的数据集上进行了测试，包括闭合式生成的缩写任务NewsRoom 和 SummEval，和开放式的故事生成任务HANNA，并对比了多个 LLM 单点评估的基线方法，包括无监督的 direct scoring, G-Eval, GPTScore 和有监督训练过的 UniEval 以及 BARTScore。如下表 1 所示，PairS 在每个任务上和他们相比都有着和人类评分更高的一致性。GPT-4-turbo 更是能达到 SOTA 的效果。在文章中，我们还对比了两种偏好排序的基线方法，win rate 和 ELO rating。PairS 可以仅用约 30% 的对比次数就能达到他们同样质量的偏好排序。论文还提供了更多关于如何使用成对偏好来量化计算 LLM 评估器的传递性，以及成对评估器如何在校准中受益的见解。

从现在起，GitHub上超1亿开发者可直接访问全球顶级大模型，构建AI应用

GitHub 推出的全新功能「GitHub Models」将有望加快 AI 工程师时代的到来。什么？大家熟悉的代码托管平台 GitHub 又进化了！该平台也开始提供 AI 大模型的 Playgroud 了。所有你能叫得上名字的业界流行大模型，包括微软的 Phi-3、OpenAI 的 GPT-4o、Meta 的 Llama 3.1、Cohere 的 Command R+、Mistral AI 的 Mistral Large，都可以在一个交互式沙盒中试用。在未来几个月，Github 也将添加更多语言、视觉以及其他类型的模型。也就是说，这张图上的模型都可以「白嫖」到了！相当于又多了一个可以免费测试各家大模型的新途径！不仅如此，开发者还可以轻松地将合适的模型导入到自己的 AI 项目中。Github 创建了一条能直接把模型放在 Codespaces 和 VS Code 开发环境中的快速通道，一下把部署 AI 模型的门槛打下来了。这就是 GitHub 今天推出的「GitHub Models」功能！对于开发者来说，只要有合适的工具并训练，每个人都可以成为 AI 工程师。开发者选择模型，在 GitHub 代码空间（Codespaces）中进行编码，然后通过 Azure 进行生产部署，提供了「一条龙」服务。具体来说，你可以调用 GitHub CLI 中的 GitHub Models 命令，通过一系列 JSON 文件在 GitHub Actions 用，还可以用 GitHub Models 构建 GitHub Copilot 扩展，覆盖应用开发的全周期。当项目迈入上线阶段时，Github 还提供了与 Azure AI 的无缝集成，Github 的身份验证可以通过 Azure 订阅，AI 应用部署到生产环境的门槛就这么被打下来了。现在，你可以通过 Github 在全球 25 个以上的 Azure 区域部署 AI 应用，并获取 Azure 的企业级安全保护。与 GitHub 和 Microsoft 对隐私和安全的持续承诺一致，GitHub 模型中的任何提示或输出都不会共享给模型提供者，也不会用于训练或改进模型。当然，试玩「GitHub Models」也不是完全不受限制。个人用户每天限制访问次数 150 次，每分钟不能超过 15 次，每次请求最多可以处理 8000 个 token，最多输出 4000 个 token。对此，GitHub CEO Thomas Dohmke 表示，该功能的推出标志着 GitHub 的又一次转型，从通过开源协作创建 AI 到借助 AI 的力量创建软件，再到如今利用 GitHub Models 推动 AI 工程师的崛起。并且基于 OSS 存储库、Copilot Extensions 和 GitHub Models 功能，GitHub 希望将尽可能多的合作伙伴引入到自己的平台。有开发者展示了在 GitHub 的代码空间中直接运行模型的案例，不需要安装什么东西，几秒内就可以启动。图源：https://x.com/DanWahlin/status/1819113874689610133