51c大模型~合集14

我自己的原文哦~ https://blog.51cto.com/whaosoft/11603879

# LLM 结构化数据生成原理

如何结合人工规则让 LLM 输出符合 JSON 格式的数据。

目前 LLM（Large Language Model）从文本补全到内容创作，都展示出了强大的生成能力。然而通过 LLM 生成结构化的数据如 JSON 格式的输出，却仍然是一个有挑战性的任务。

生成结构化的数据不仅要求模型输出符合特定的语法规则，还需要确保数据的正确性和一致性。

虽然通过 prompt 工程可能可以实现指定格式的结构化数据生成，但是这也很大程度取决于模型的能力。

本文将探讨如何结合人工规则让 LLM 输出符合 JSON 格式的数据。

结构化生成原理

本文主要是结合 lm-format-enforcer ( https://github.com/noamgat/lm-format-enforcer ) 这个库来讲解如何让 LLM 生成指定格式的 JSON 数据。

目前该库也是被 vllm 作为 JSON 格式输出的后端之一：https://github.com/vllm-project/vllm/blob/main/vllm/model_executor/guided_decoding/lm_format_enforcer_decoding.py

结构化数据生成的原理用一句话概括就是：

每个 step 拿到当前 model 给出的 logits 之后，在采样下一个 token 之前，通过人工设定的规则可以得到当前 step 只允许采样的 token 集合，接着通过加 bias 的方式压制其他不允许采样的 token，从而实现指定的结构化数据生成。

那么怎么得到当前 step 可允许采样的 token 集合，就是本文重点讲解的内容了。

lm-format-enforcer 这个库包含两个核心模块，分别是 tokenizer 前缀树和字符级别的解析器，通过这两个模块就可以实现上述的功能。

构造 tokenizer 前缀树

lm-format-enforcer 这个库在初始化阶段，首先会根据 tokenizer 给出的词表，初始化一个字符级别的前缀树，这个前缀树怎么理解呢？

通过 tokenizer 给出的词表，我们可以得到一个词表中的字符串和对应 token id 的映射。通过这些映射，就可以来构造这个前缀树。

树上每个节点对应词表中某个字符串的其中一个字符，每个节点的子节点就是连着的下一个字符，当字符串中的字符已经遍历完了，这时候就是填入该字符串对应的 token id。

现在通过具体的例子解释一下，这个前缀树是如何构造的。

我们用 llama2 模型的词表来解读，假设就取词表中的一个小子集：

{    "a": 29874,  "ar" : 279,  "are" : 598,  "Y": 29979,  "You" : 3492,  "O": 29949,  "OK": 8949,  
}

下面用图展示树的构造过程：

遍历第1个映射：

遍历第2个映射：

遍历第3个映射：

遍历第4个映射：

遍历第5个映射：

遍历第6个映射：

遍历第7个映射：

通过上面图示，展示了如何通过词表子集构造前缀树，实际的前缀树比这个大多了，整个词表中的字符串和 token id 的映射都会通过这样的方式插入到前缀树中。

约束每个 step 可允许采样 token 范围

构造好前缀树之后，接下来就是讲解怎么得到每个 step 可允许采样的 token 集合。

lm-format-enforcer 还有另一个重要的模块就是字符级别的解析器。

这个解析器的作用简单来理解就是，在初始化的时候，会接收用户指定的 json schema，接着在后续每一步生成过程中，会根据之前生成的内容，判断目前处于什么状态，然后根据当前所处的状态直接给出限定的字符集合。

下面举个简单的例子，比如用户指定的 json schema 是：

JSON_SCHEMA = {  "type": "object",  "properties": {  "city": {  "type": "string",  "description": "Name of the city."  }  },  "required": ["city"]  
}

想要 LLM 生成一个 JSON object ，内容是包含一个 city 属性，该属性的内容是一个字符串，表示一个城市的名字，同时该 city 必须要在结果中出现。

解析器的作用就是，比如目前已经生成好的内容是：

{  "

那么下一步一定是要生成 city 这个字符串，解析器的作用就是根据目前的状态，会给出限定的字符集合 ['c', 'i', 't', 'y'] 。

然后接下来比如生成到了：

{  "city": "

那么接下就是要 LLM 生成一个城市的名字，但是其实对于解析器来说，他只知道接下来要生成的内容是字符串，而且内容只需要符合 JSON 格式就行了，所以这时候给出的限定字符集合就非常大了，词表中的 token 对应的字符串只要符合 JSON 格式的都可以。

最后具体能生成什么城市名字，还有这个城市是否真实存在，就得看 LLM 的能力了。

下面用一个具体的例子讲解一下，怎么结合前缀树和解析器，获取每个 step 限定的 token 集合。

假设用户的输入 prompt 和指定的 json schema 是：

prompt = "Please output a JSON segment representing the name of a city, including fields for city name."  JSON_SCHEMA = {  "type": "object",  "properties": {  "city": {  "type": "string",  "description": "Name of the city."  }  },  "required": ["city"]  
}

第 1 个采样 step

有一点需要注意，获取可允许采样 token 集合在 lm-format-enforcer 库中是通过递归的方式实现的，下面为了讲解方便，会给每一层递归编个号：

第 0 层递归

首先解析器给出的限定字符集合就是

[' ', '\t', '\n', '\r', '{']

包括空格和大括号在内的5个字符。

然后将这个5个字符和前缀树根节点的所有第一层子节点对应的字符集合做一个交集。

获取得到的字符交集还是这 5 个字符：

[' ', '\t', '\n', '\r', '{']

接着遍历这个字符交集。

遍历每个字符的时候会假设目前已经生成了该字符，比如一开始遍历空格字符 ' '，会将空格当作已经生成的内容加入到解析器中，这时候解析器内部状态会变化，同时取前缀树中空格字符节点对应的所有子节点，进入下一轮递归。

下一轮递归开始的时候，首先将会该子节点包含的所有 token id 加入到当前 step 的候选 token 列表中，然后继续重复上述流程。

第 1 层递归

首先看目前遍历到的前缀树节点包含的 token id 集合是

[35, 29871]

分别对应 llama2 词表中的字符串

"<0x20>"  
"▁"

其中， 0x20 表示 ASCII 编码表中的空格字符，所以在 llam2 的词表中，空格对应的 token 有两个。

接着继续看第 1 层的递归，解析器在上一层添加了空格字符之后，给出的限定字符集合仍然是

[' ', '\t', '\n', '\r', '{']

因为假设前面生成的是空格的情况下，接下来的可生成的字符其实还是可以是之前的 5 个中选一个。

然后前缀树当前节点下的所有第一层子节点的字符集合：

[' ', 't', 'a', 's', 'd', 'c', 'w', 'p', 'f', 'm', 'o', 'b', 'i', 'h', 'l', 'n', 'I', '(', 'C', 'S', 'u', 'A', '\\', 'e', 'T', 'v', 'g', '*', 'r', 'M', 'y', 'P', 'B', '=', 'D', 'L', '"', 'H', 'E', 'F', 'R', '$', '#', 'W', 'G', 'N', 'k', '`', '{', 'j', 'J', 'O', 'q', '-', 'п', 'K', 'V', 'в', '}', 'U', 'z', '[', "'", '<', 'с', ':', 'и', 'Y', 'о', 'Q', 'д', 'н', '&', '+', '@', 'з', 'м', '–', 'Z', '—', 'à', 'б', '/', 'С', '«', 'у', '.', '|', '_', 'é', 'x', 'В', 'П', 'к', 'X', 'К', 'г', 'а', 'М', '%', 'А', 'р', '“', 'Б', 'Н', '>', 'Д', 'Р', '?', 'ф', 'Г', 'О', 'е', 'Т', 'т', ')', '!', '„', 'Л', 'і', ',', 'У', '»', ';', 'è', 'И', 'ä', 'я', 'э', 'З', 'ч', 'ü', 'Ф', 'ј', '·', 'î', 'Х', 'É', 'Е', 'ш', 'č', 'л', 'Ч', '~', 'ц', 'ú', 'ö', 'á', 'Ш', 'ș', 'х', 'ж', ']', 'Э', '‘', 'І', 'Ц', 'щ', 'Я', 'ž', 'ś', '^', 'Ö', 'š', '†', '°', '\r', 'Ю', 'Ж', 'Ü', 'Á', 'й', 'Č', 'ê', 'ю', 'À', '№', 'Š', 'å', 'є', '•', '→', 'Ś', 'Å', 'ї', 'Ä', 'Î', '│', '×', 'ż', 'Ž', '−', 'È', 'Ł', 'Є', 'í', 'Ż', 'Й', '£', 'Ј', '…', '’', '§', 'ó', 'Ú', '¿', 'ř', 'â', 'α', '\xa0', 'ő', 'њ', 'ا', '€', '”', 'Ó', 'Щ', 'ł', 'Í', '¡']

其实对应的都是词表中起始字符是空格的 token ，然后两者的交集是：

[' ', '\r', '{']

其实就是对应词表中以空格起始的三个 token ：

"▁▁": 259  
"▁\r": 6756  
"▁{": 426

接着遍历交集 [' ', '\r', '{'] ，进入第 2 层递归。

由于 llama2 词表中包含连续空格的 token 最长的有15个连续空格 token ：

"▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁": 462

但是递归最多只会深入到 12 层，因为 lm-format-enforcer 库中默认限定了最长连续的空格数量是 12 个，所以连续探索空格达到 12 层递归之后就会终止探索，接着回溯到第 1 层，继续那一层其他剩下还没探索的交集字符的递归过程。

一直重复直到所有层前缀树和解析器的所有字符交集都探索完毕。

最终第一个 step 得到的可允许采样的 token 集合是：

"<0x20>": 35 # 对应 ASCII 表中的空格字符  
"▁": 29871  
"▁▁": 259  
"▁▁▁": 1678  
"▁▁▁▁": 268  
"▁▁▁▁▁": 418  
"▁▁▁▁▁▁": 539  
"▁▁▁▁▁▁▁": 4706  
"▁▁▁▁▁▁▁▁": 308  
"▁▁▁▁▁▁▁▁▁": 3986  
"▁▁▁▁▁▁▁▁▁▁": 965  
"▁▁▁▁▁▁▁▁▁▁▁": 9651  
"▁▁▁▁▁▁▁▁▁▁▁▁": 632  
"▁\r": 6756  
"▁{": 426  
"▁{\r": 3336  
"▁{\"": 8853  
"<0x09>": 12 # 对应 ASCII 表中的 \t 字符  
"<0x0A>": 13 # 对应 ASCII 表中的 \r 字符  
"<0x0D>": 16 # 对应 ASCII 表中的 \n 字符  
"\r": 30004  
"<0x7B>": 126 # 对应 ASCII 表中的 { 字符  
"{": 29912  
"{\r": 14626  
"{\"": 6377

第 6 个采样 step

然后我们直接跳到第 6 个 step，假设目前 LLM 已经生成的内容是，

{  
"

前面每个 step 生成的内容按顺序是 ['\n', '\n', '\n', '{', '\n', '"']：

然后根据用户设定的 json schema，接下来其实就是要限制采样必须生成 city 这个字符串，我们来看下递归的过程。

第 0 层递归

首先解析器给出的限定字符集合就是 ['c']

然后前缀树根节点所有第一层子节点的交集就只有 'c' 字符，然后将 c 加入解析器，同时取根节点下 c 对应的所有子节点进入

第 1 层递归

而由于上一层生成了字符 c ，那么对于解析器来说，接下来的字符肯定要是 i ，所以给出的限定字符集合就是 ['i']，和当前树节点的第一层子节点的交集自然也就是只有字符 'i'，然后继续递归。

以此类推，可得当前 step 的限定 token 集合为：

"<0x63>": 102 # 对应 ASCII 表中小写字符 c   
"c": 29883  
"ci": 455  
"cit": 20752  
"city": 12690

第 9 个采样 step

接着跳到第 9 个 step，假设到目前为止已经生成了：

{  
"city": "

那么这时候，根据解析器的判断，接下来其实就是可以自由生成任意符合 json 格式的字符，所以这时候返回的 token 集合会非常大，接近词表大小。

lm-format-enforcer 中对这个情况做了优化，就是这些 token 集合是可以在生成前缀树的过程中拿到。

所以如果当前是自由生成字符模式，则不会进入递归过程，直接返回这些 token 集合即可。

如何在采样过程中压制特定 token

在拿到可允许采样的 token 集合之后，接下来的操作就简单了，只需要给 logits tensor 加一个偏置即可，伪代码实现：

allow_tokens = [xx, yy, zz, ....]  
bias = torch.full((vocab_size,), -math.inf)  
bias[allow_tokens] = 0  
logit += bias

通过给不允许采样的 token 加一个负无穷的方式来压制这些 token 不会被采样得到。

总结

其实除了 lm-format-enforcer 的实现方式之外，还有其他人工规则的结构化生成库比如 github 上 star 更多的 outlines 库。感兴趣的读者可以进一步对比两者的实现有什么不同。

参考资料

[1] https://github.com/vllm-project/vllm/blob/main/vllm/model_executor/guided_decoding/lm_format_enforcer_decoding.py

[2] https://github.com/noamgat/lm-format-enforcer?tab=readme-ov-file#how-does-it-work

[3] https://github.com/outlines-dev/outlines

#用Llama 3.1合成数据改进模型

英伟达最新技术分享适逢Llama 3.1模型刚刚发布，英伟达就发表了一篇技术博客，手把手教你如何好好利用这个强大的开源模型，为领域模型或RAG系统的微调生成合成数据。

Epoch AI上个月刚刚发文预言「数据墙」迫近，结果英伟达转头就甩出了340B开源巨兽Nemotron。

真实数据稀缺可能不再是问题了，Nemotron 9T token的预训练预料中，98%都是合成数据。

也许你还对合成数据存在顾虑，或者不知道如何应用LLM驱动数据生成。或许，英伟达的这篇博客可以提供答案。

原文地址：https://developer.nvidia.com/blog/creating-synthetic-data-using-llama-3-1-405b/?linkId=100000275486093

首先我们需要理解，用LLM合成数据的本质究竟是什么？

合成数据并不是「从无到有」地创造新信息，而是对现有信息进行转换，生成不同的变体。

实际上，合成数据在AI领域的应用已经有十多年的历程，比如物体检测或分类系统中曾经的数据增强技术。

那么，LLM带来了什么新变化呢？

从「需求端」来看，由于模型需要大量训练语料，合成数据的动机被大大增强。

而在「供给端」，生成式语言模型也为合成数据技术带来了质的改变。

用合成数据微调基座模型，可以更好地应用于实际场景。例如，在金融领域改进风险评估、在零售领域优化供应链、在电信领域提升客户服务，以及在医疗领域改善患者护理等等。

尤其是405B开源巨兽Llama 3.1最近正式上线，既可用于批处理和在线推理，也可以作为基座模型，进行特定领域的专门预训练或微调。

尤其是考虑到Llama 3.1有如此大的参数规模，加上丰富的15.6T token训练数据，非常适合用于数据生成。

这篇博客文章将介绍几个合成数据的生成与应用案例，并就其中一个进行深入探讨。

合成数据的生成是推动GenAI在特定领域应用的关键工作流程
将最新的Llama 3.1与英伟达Nemotron-4 340B奖励模型配合使用，非常适用于生成合成数据
要让LLM生成基于最新信息的有根据的响应，构建RAG流程十分重要，而且模型响应的准确性取决于流程的质量。

LLM合成数据如何应用于GenAI

改进语言模型

要通过合成数据来微调模型，大致有两种方法——知识蒸馏（knowledge distillation）和自我改进（self-improvement）。

知识蒸馏是将大模型的能力转移到较小模型的过程，但不是简单地在同一个数据集上训练两个模型，因为较小模型很难学习到底层数据的准确表征。

在这种情况下，我们可以先让大模型完成任务，再使用这些数据指导小模型进行。

自我改进则是让同一个模型评判自己的推理过程，常被用于进一步磨练模型的能力。

让我们来看看如何实现这一目标。训练语言模型通常包括三个步骤：预训练、微调和对齐（alignment）。

预训练

预训练通常需要极其庞大的语料库，使模型了解语言的一般结构。

Llama 3.1、GPT-4这种通用LLM，一般需要互联网规模的数据。而特定领域的LLM（如几何学、放射学、电信行业等）则需要注入相关的领域信息，这个过程被称为领域自适应预训练（Domain Adaptive Pretraining，DAPT）。

除了要贴近相关领域，另一种在预训练阶段使用合成数据的例子当属Phi-1.5模型，目的是注入逻辑推理能力。

微调

掌握了语言的一般结构后，下一步就是微调，让模型更好地遵循指令、完成特定任务。

比如，要让模型提高逻辑推理能力、实现更好的代码生成和函数调用，或者提升阅读理解类任务的表现，都可以通过微调来实现。

Self-Instruct、WizardCoder、Alpaca等模型都通过创建特定领域的数据并进行微调，来定向提升模型能力。

对齐

最后，我们希望确保模型响应的风格和语气与用户期望一致，例如听起来像对话、具有适当的详细程度、复杂性、一致性等。

可以创建一个包含指令模型（instruct model）和奖励模型（reward model）的流水线来实现这个需求。

先让模型对同一问题创建多个响应，然后让奖励模型对这些相应的质量进行反馈。这种方法属于从AI反馈中进行强化学习（Reinforcement Learning from AI Feedback, RLAIF）。

改进其他模型和系统

除了改善语言模型本身，合成数据还可以应用于LLM邻接模型（LLM-adjacent model）以及LLM驱动的流水线。

最经典的例子就是检索增强生成（Retrieval Augmented Generation，RAG），先用嵌入模型来检索相关信息，再让语言模型生成最终答案。

在这个过程中，我们可以使用LLM来解析底层文档和合成数据，从而评估并微调嵌入模型。

类似于RAG，任何智能体（Agentic）流水线都可以被评估，其组件模型也可以被微调，实现方式就是用LLM驱动的智能体来构建模拟。

这些模拟还可以用于研究行为模式，此外，也可以在LLM中设定特定角色，以针对特定任务进行大规模数据生成。

使用合成数据评估RAG

为了更好地理解上述讨论，我们来思考一个基本的流程，应用于一个具体的用例——为检索过程生成评估数据。

下述流程的实现代码已经上传至GitHub。

项目地址：https://github.com/NVIDIA/NeMo-Curator/tree/main/tutorials/synthetic-retrieval-evaluation

要创建用于评估检索流程的数据，主要面临以下2个挑战：

多样性：问题不应只关注信息的单一方面或仅包含提取性问题
复杂性：生成的问题应需要一些推理或多个证据来回答

我们将重点关注多样性，但为了探索复杂性角度——关键是找到具有重叠信息点的内容块。找到重叠信息的几种方法包括计算句子级语义的Jaccard相似度，并利用长上下文模型找到同一文档的不同块之间的关联。

多样性源自不同的视角，比如考虑如下文本：

对于同一篇文档，金融分析师可能对两家公司合并前后的财务状况感兴趣，法律专家可能关注公司面临的来自FTC、欧盟和其他方的法律审查，记者则希望了解事实要点。

所有这些都是有效的视角和用户角色。由于他们以不同的视角看待相同的信息，因此评估流程也需要适应这些视角。

因此，让我们设计一个评估流程，该流程以文档和用户角色作为输入，并以符合角色的语气输出问题。

图1. 三步流程的概述：生成用于评估检索过程的合成数据

如图1所示，这个评估流程有三个主要步骤。

步骤1：生成所有可能的问题

这些问题都是用户角色可能感兴趣的。

步骤2：筛选出相关的问题

从生成的问题中筛选出最相关和有价值的问题。

步骤3：引入用户角色的写作风格

将筛选出的问题转换为符合用户角色写作风格的形式。

通过这三个步骤，可以确保不同用户角色获得他们所需的信息，并以他们熟悉的方式呈现。

步骤1：生成问题

在生成问题之前，我们需要先读取文档并将其分成若干块（chunk）。

然后，让LLM从给定的文本块中，为每个用户角色提取感兴趣的点。

所谓的「用户角色」（persona），实际上就是对潜在用户的描述，比如：

由于多个用户角色可能有相似的兴趣点，因此需要使用嵌入模型来进行语义去重，从而为每个角色映射出段落中不同的相关信息。

多样性的另一个方面是问题类型。

我们需要提出各种类型的问题，如提取性、抽象性、比较性的问题，而不仅仅是简单的「如何/什么」问题。因此，下一步是根据段落中的信息，确定每个兴趣点适用的问题类型。

最后，利用文本块-兴趣点-问题类型的三元组，生成所有可能的问题。通过用户角色和问题类型，开发人员可以将生成的问题引导到用户会问的类型上。

步骤2：过滤问题

生成问题之后，下一步就是过滤并提取最有用的子集。首先，我们需要对所有生成的问题进行去重，因为不同的兴趣点可能会利用相邻的信息点，导致问题重叠。

接下来，我们使用LLM来判断问题与段落的相关性，确保这些问题能够完全通过段落中的信息回答。然后，我们将所有相关问题重写为对话语气。最后，我们会进行另一次过滤，分类并剔除那些可能过于笼统的问题。

步骤3：注入用户角色风格

在前两步中，我们创建并筛选了多样化的问题。最后一步是将用户角色的写作风格融入到问题中。

使用LLM，我们首先根据给定的用户角色描述来制定写作风格。然后，基于这些写作风格重新改写问题。

比如，可以这样描述用户角色的写作风格：

在这个三步流程结束后，我们得到了如下问题：

鉴于现行的监管框架，拟议的合并还需要遵守哪些额外的政策指令，才能获得相关部门的批准？
SolarPower和GreenTech合并的哪些具体方面目前正在接受相关监管部门的审查？
如果在大笔买断之后，GreenTech的研发中心保持单飞状态，那些天才会被炒鱿鱼吗？

可以看出，前两个问题很像Padma的语气，而第三个问题似乎是Aaron会问的。

这些问题各自包含了真实标签，对应特定的文本块，因此不仅限于这一个用例，可以用于评估各种检索流程。

参考资料：

https://developer.nvidia.com/blog/creating-synthetic-data-using-llama-3-1-405b/?ncid=so-twit-933996&linkId=100000275486093

#GTA

真实世界复杂任务，全新基准GTA助力大模型工具调用能力评测

本篇论文已被 NeurIPS 2024 Dataset & Benchmark Track 接收，作者来自上海交通大学 IWIN 计算智能团队和上海人工智能实验室。其中，第一作者王骥泽是上海交通大学自动化系一年级博士生，研究方向涉及大模型智能体、自然语言处理。

利用语言模型调用工具，是实现通用目标智能体（general-purpose agents）的重要途径，对语言模型的工具调用能力提出了挑战。然而，现有的工具评测和真实世界场景存在很大差距，局限性主要体现在以下几个方面：

评估问题通常是 AI 生成的，形式固定；
逻辑链简单，不涉及复杂多步推理；
输入是纯文本形式，模态单一；
没有部署真实可执行的工具，无法端到端评测。

为了突破这些局限，来自上海交通大学与上海人工智能实验室的研究团队提出了 GTA（a benchmark for General Tool Agents），一个用于评估通用工具智能体的全新基准，主要特性包括：

真实的用户问题
真实部署的工具
多模态输入输出

GTA 通过设计真实世界场景的用户问题、真实部署的工具和多模态输入，建立了一个全面、细粒度的评估框架，能够有效评估大语言模型在复杂真实场景下的工具使用能力。

论文标题：GTA: A Benchmark for General Tool Agents
论文链接：https://arxiv.org/abs/2407.08713
代码和数据集链接: https://github.com/open-compass/GTA
项目主页: https://open-compass.github.io/GTA
Hugging Face：https://huggingface.co/datasets/Jize1/GTA

GTA 中的用户问题与现有工具评测的用户问题对比如下表所示。ToolBench 和 m&m's 中的问题明显地包含了需要调用的工具（蓝色字）以及步骤（红色字）。APIBench 中的问题较为简单，仅包含单个步骤。相较而言，GTA 的问题既是步骤隐含的，也是工具隐含的，并且是基于现实世界场景的、对人类有帮助的任务。

GTA 的评估结果表明，GPT-4 在面对真实世界问题时仅完成不到 50% 的任务，而大多数模型完成率低于 25%。揭示了现有模型在处理真实世界问题时面临的工具使用瓶颈，为未来的通用工具智能体提供了改进方向。

设计准则

GTA 主要有三个核心特性，来评估大语言模型在真实世界场景下的工具使用能力：

真实用户查询：包含 229 个人类撰写的问题，问题具有简单的真实世界目标，但解决步骤是隐含的，工具也是隐含的，要求模型通过推理来选择合适的工具并规划操作步骤。
真实部署的工具：GTA 提供了工具部署平台，涵盖感知、操作、逻辑和创作四大类共 14 种工具，能够真实反映智能体实际的任务执行性能。
多模态输入输出：除了文本，GTA 还引入了空间场景、网页截图、表格、代码片段、手写 / 打印材料等多模态输入，要求模型处理这些丰富的上下文信息，并给出文本或图像输出。这使得任务更加接近实际应用场景，进一步提升了评估的真实性和复杂性。

数据集构建

数据集构建流程包含两个步骤：

1. 问题构建。专家设计问题样例和标注文档，标注人员按照标注文档中的指示，进行头脑风暴，基于问题样例设计更多的问题，最终得到问题集。

2. 答案构建。标注人员手动调用部署好的工具，确保每个问题都可以用提供的工具解决。然后，标注人员根据工具调用过程和工具返回结果，对每个问题的工具调用链进行标注。

为了让评测集更全面地覆盖真实场景，研究团队采用了多样化的扩展策略，包括场景多样化、工具组合多样化等。最终得到的评测集包含多图推理、图表分析、编程、视觉交互、网页浏览、数学、创意艺术等多种场景，确保了评估任务的全面性和多样性。

问题示例

最终共得到 229 个真实场景下的任务，所有问题都隐含工具和步骤，并且包含多模态上下文输入。这些任务基于现实世界场景，目标明确且易于理解，完成任务对人类有帮助，但对于 AI 助手来说较为复杂。JSON 格式的数据示例可以在 Hugging Face 上找到。

模型评测

GTA 在两种模式下评估语言模型：

逐步模式 (step-by-step mode)。该模式旨在细粒度地评估模型的工具使用能力。在该模式下，ground truth 工具链的前 n 步作为 prompt，模型预测第 n + 1 步的操作。在逐步模式下，设计四个指标：InstAcc（指令遵循准确率）、ToolAcc（工具选择准确率）、ArgAcc（参数预测准确率）和 SummAcc（答案总结准确率）。
端到端模式 (end-to-end mode)。该模式旨在反映智能体实际执行任务时的表现。在这种模式下，模型会自主调用工具并解决问题，而无外部引导。使用 AnsAcc（最终答案准确率）来衡量执行结果的准确性。此外，还计算了工具选择方面的四个 F1 score：P、L、O、C，分别衡量感知 (Perception)、操作 (Operation)、逻辑 (Logic) 和创作 (Creativity) 类别的工具选择能力。

评测结果表明，目前的大语言模型在复杂真实场景任务的工具调用上仍存在明显的局限性。GPT-4 在 GTA 上仅能完成 46.59% 的任务，而大多数模型仅能完成不到 25% 的任务。

研究团队发现，目前语言模型在完成 GTA 任务的关键瓶颈是参数传递准确率。研究人员计算了各指标与最终结果准确率 AnsAcc 之间的皮尔森相关系数，发现 ArgAcc 的相关系数最高，说明参数传递是目前大多数模型的瓶颈。例如，Llama-3-70B-Chat 的 InstAcc，ToolAcc，SummAcc 都比 Qwen1.5-14B-Chat 高，但 ArgAcc 比 Qwen1.5-14B-Chat 低，导致最终结果准确率更低。

错因分析

为了进一步理解模型在参数传递上的失误原因，研究团队选择两个典型模型 GPT-4-1106-Preview 和 Llama-3-8B-Instruct，对它们进行了深入的错误原因分析，如下表所示。

分析显示，GPT-4 与 Llama-3 的错误分布存在显著差异。GPT-4 模型倾向于生成 “无动作”（No Action）的响应，在 38.7% 的错误中，GPT-4 尝试与用户互动，错误地认为问题表述不够明确，要求提供额外信息。而在 50% 的错误中，模型仅生成内部思考过程，而未采取实际行动。

而 Llama-3 的大部分错误来自于格式错误，特别是调用工具或生成最终答案时。45.4% 的错误是由于参数未能遵循合法的 JSON 格式。此外，在 16.5% 的情况下，Llama-3 试图同时调用多个工具，这并不被智能体系统支持。19.6% 的错误则源于生成冗余信息，导致参数解析不正确。

总结

本文构建了面向复杂真实场景的通用工具智能体（General Tool Agents）评测基准：

构建了通用工具智能体的评测数据集。问题由人类设计，是步骤隐含、工具隐含的，且立足于真实世界场景，并提供了多模态语境输入。每个问题都标注了可执行的工具链，以支持细粒度的工具使用能力评测。
提供了包含感知、操作、逻辑、创作类别工具的评测平台。针对工具调用设计了细粒度的评测指标，揭示工具增强的语言模型在真实世界场景中的推理和规划能力。
评测和分析了主流大语言模型。从多个维度评测了 16 个大语言模型，反映了目前的语言模型在真实世界场景下的工具调用能力瓶颈，为通用目标智能体的发展路径提供建议。

#Modality Integration Rate（MIR）

高效评估多模态预训练对齐质量，中科大提出模态融合率MIR

本文作者来自于中国科学技术大学，上海人工智能实验室以及香港中文大学。其中第一作者黄启栋为中国科学技术大学三年级博士生，主要研究方向包括多模态大模型（MLLM）和可信 / 高效 AI，师从张卫明教授。

是否还在苦恼如何评估自己预训练好的多模态 LLM 的性能？是否还在使用并不靠谱的损失 Loss，困惑度 Perplexity（PPL），上下文 In-Context 评估，亦或是一遍遍地通过有监督微调（SFT）之后下游测试基准的分数来判断自己的预训练是否有效？

来自中科大等单位的研究团队共同提出了用来有效评估多模态大模型预训练质量的评估指标 Modality Integration Rate（MIR），能够快速准确地评估多模态预训练的模态对齐程度。

标题：Deciphering Cross-Modal Alignment in Large Vision-Language Models with Modality Integration Rate
论文：https://arxiv.org/abs/2410.07167
代码：https://github.com/shikiw/Modality-Integration-Rate

研究背景

预训练（Pre-training）是现有多模态大模型（MLLM）在训练过程中一个不可或缺的阶段。不同于大型语言模型（LLM）的预训练，多模态预训练的主要目标聚焦于不同模态之间的对齐。随着近两年的发展，多模态预训练已经从轻量级图像 - 文本对的对齐，发展为基于广泛多样的多模态数据进行深层次模态集成，旨在构建更通用的多模态大模型。

然而，多模态预训练的评估对于业界仍然是一个未被充分解决的挑战。现有最常用的评估手段为通过进一步的有监督微调（SFT）来测试在下游基准上的模型能力，但是其伴随的计算成本和复杂性不容忽视。另外有一些方法通过借用 LLM 的预训练评估指标，包括损失值 Loss、困惑度 PPL 和上下文 In-Context 评估等方式，在多模态预训练评估中都被证明是不稳定和不可靠的。

研究者们通过在不同规模的高质量预训练数据上预训练 LLaVA-v1.5 的 7B 模型，用上述不同的方法评估其预训练质量，并与有监督微调之后在下游测试基准上的得分进行对照。如下图所示，损失值 Loss、困惑度 PPL、以及上下文 In-Context 评估都无法准确的对应 SFT 之后在下游测试基准上的模型性能，而本文提出的模态融合率 MIR 则能完美对应。

实际上，PPL 等指标的不适用主要由于 LLM 与 MLLM 在预训练目标上的差异。LLM 预训练主要学习建模语言的基本模式，而 MLLM 预训练则侧重于缩小不同模态之间的差距。如果用多个不同来源的图像和文本数据，并在 LLaVA-v1.5 的大模型输入层去可视化它们的特征分布，会发现尽管图像或文本内容多样，但在每种模态内，它们的分布相对均匀，而模态之间则存在明显的分布差距，如下图（左）所示。

如上图（右）所示，通过进一步计算现有 MLLM 的在大模型不同层中的模态差距，会观察到浅层的时候仍然有较大差距，但当到越来越深的层，这一差距逐渐缩小，这表明 MLLM 在训练过程中仍需要学习对齐不同分布，以理解新引入的模态。

技术方案

本文提出模态融合率 MIR，能够用于评估多模态预训练的跨模态对齐质量。该指标能准确反映各种预训练配置（如数据、策略、训练配方和架构选择）对模型性能的影响，而无需再进行有监督微调 SFT 并于下游测试基准上评估。

对于一个预训练的多模态大模型 M = (E, P, D)，其中 E 表示视觉编码器，P 表示视觉语言映射模块，D = (D_t, F) 表示包含分词器 D_t 和 K 层 transformer 的底座大模型 F。当输入一组 “图像 - 文本” 对 {v_n, t_n}, n = 1,..., N 给模型，会从大模型第 k 层 F_k 得到该层关于数据对 {v_n, t_n} 的视觉 token 特征 f_k^{v_n} 和文本 token 特征 f_k^{t_n}，即

研究者们将多个样本的特征 f_k^{v_n} 合并到一起得到 f_k^v，同理 f_k^{t_n} 可以合并得到 f_k^t，并且定义 f_{k, i}^v 为第 i 个视觉 token 特征，f_{k, j}^t 为第 j 个语言 token 特征。

文本中心归一化

由于越深层的 token 特征在数值绝对尺度上明显比浅层的大，并且不同模态特征间在绝对尺度上存在差异，直接使用 Frechet 距离等度量函数、或是把所有 token 特征统一归一化后再使用度量函数都是不合适的。为此，研究者们设计了一种文本中心的归一化方法，对于 f_k^t 中的总共 s 个文本 token 特征，计算尺度因子：

然后对第 k 层对应的视觉特征和文本特征都使用该因子进行放缩，在保证跨层对比合理性的同时，保持模态间绝对尺度带来的差异。

离群值筛除

许多工作如 StreamLLM [1]、Massive Activations [2] 都提到，有极少部分绝对数值异常大的 token 会用来在注意力模块的 SoftMax 计算中使总和填充到 1。为了避免此类离群值对整体统计分布的影响，这里使用 “3-sigma” 的准则对于所有 f_k^v 和 f_k^t 中的离群值进行筛除。以下用 omega 表示这个操作。

模态融合率

在经过文本中心归一化以及离群 token 筛除之后，模态融合率 MIR 可以通过累和大模型逐层的模态域间距离来得到：

其中，mu_{v, k} 和 mu_{t, k} 分别是处理后视觉 token 特征和文本 token 特征的均值，而

对应于各自的协方差计算。最后的平方根项通常在 PyTorch 中计算缓慢，这是由于大模型的特征维度普遍较高。因此研究者们使用 Newton-Schulz 迭代近似的方式估计该项，在大大提高计算速度的同时，保证实践中误差不超过 1%。总体上来看，越低的 MIR 代表着越高的预训练模态对齐质量。

可学习模态校准

在对 MIR 的探究推导过程中，证明了底座大模型在训练过程中展现出的在浅层逐渐缩小模态间差距的倾向。这促使研究者们重新思考多模态大模型中一些继承自大型语言模型的设计是否不利于促进跨模态对齐。为此，研究者们提出了 MoCa，一个可插拔轻量级的可学习模块，来促进跨模态对齐。简单来说，即对于每一层的视觉 token 特征单独进行一个可学习的缩放和偏移：

其中缩放向量 u 初始化为全一向量，偏移向量 v 初始化为全 0 向量，两者随着模型一起训练，但是基本不增加额外参数量。

实验探究

研究者们首先展示了 MIR 在在扩大预训练数据规模时衡量预训练质量的有效性。这里采用两种预训练策略：1) 仅训练 MLP 投影模块；2) 解锁视觉编码器后半部分和整个 LLM。在第一种策略下，SFT 后的性能在 800K∼1M 数据规模时逐渐改善但趋于饱和。而在使用第二种策略时，即使在 1.8M 数据规模下，性能仍持续显著提升。该结果说明了了 MIR 在扩大预训练数据时的有效性，也说明了适当地放开视觉编码器或 LLM 在大规模数据上有持续改善预训练的效果。

研究者们也探究了 MIR 在超参数调整、预训练策略选择上的有效性。在超参数调整方面，研究者们发现 MIR 与 SFT 后下游测试基准性能之间存在正相关，这说明 MIR 直接反映不同训练超参数对于在预训练质量的影响，以后对照 MIR 就可以实现预训练调参炼丹！

在训练策略方面，研究者们探讨了 MIR 如何指导选择有效的预训练放开策略。结果显示，放开 LLM 显著降低了 MIR，且显著增强下游基准上的表现。

同时，MIR 也可以帮助选择一些有利于跨模态对齐的模块设计。如下图所示，当使用不同的视觉语言投影模块结构时，MIR 可以很准确的对应到 SFT 之后的测试基准性能。

同样，所提出的可学习模态校准 MoCa 也可以有效帮助不同模型在下游测试基准上涨点，并取得更低的 MIR。

本文仍有较多其他方面的实验和探索，有兴趣的同学可以参考原文！

#Linux之父怒斥90%都是营销

谷歌员工集体打脸劈柴，25%新代码AI生成夸大事实

谷歌超25%新代码由AI生成，却遭到了自家员工的反对。劈柴的一句话，又让谷歌成为了众矢之的。

「谷歌内部超1/4新代码，全是由AI生成的」！

上周，CEO劈柴在Q3财报会议上的一句话，瞬间点燃了全网的激烈讨论。

AI生成的代码再由工程师进行审核，能够帮助工程师完成更多的工作，加快开发效率

然而，也正是这句话，劈柴却遭到了自家员工「打脸」。

在热门新闻网站HK上，一位谷歌程序员发帖，对这个观点并不认同：

我在谷歌刚刚结束了一天的工作，我刚才在写那种称之为「AI生成代码」的东西，但是这个代码补全能力最擅长补全我正在写的代码行。

比如，当我写「function getAc...」时，它足够聪明，可以补全完成「function getActionHandler()」，可能还会建议正确的参数和一个不错的jsdoc注释。

简单来说，它是个有用的生产力工具，但并不能完全进行真正的软件工程设计工作。它可能和Copilot差不多，也许稍差一些。（不过我最近没用过Copilot）

评论区下面一位谷歌员工，更是直言不讳，「这明显就是在夸大事实，他们可能把一些存在了十年的全自动代码审查/Pull Request也算作『AI生成』了」。

如果一个10人团队和一个使用Copilot的8人团队生产力相同，那在我看来可以说「AI替代了2个工程师」。更重要的是，如果这是真的，科技领导者们早就会这样宣称了。

Copilot和类似工具已经存在足够长的时间，足以证明其效果，但没有人说「我们用AI替换了X%的员工」，因此通过「否定后件」的逻辑，使用Copilot并不能实质性地加速开发。

如此戏剧性的反转，让现场吃瓜的网友大受震撼。

就连Linux之父Linus Torvalds在采访中表示，「AI只不过是一种营销策略。人工智能市场状为90%营销和10%现实」。

可以庆幸的是，AI取代程序员工作应该离我们还很遥远。

25%代码AI生成，过度吹捧遭打脸

在所有人看来，25% AI生成代码所占的比例是非常高了。

此外，劈柴在Q3财报讲话中还提到了，不论是从token数量、API调用、业务采用哪个方面去衡量，Gemini模型使用率都处于急剧增长的时期。

除了谷歌自己的平台，Gemini还联手GitHub Copilot，为更多开发者提供能力，支持处理200k上下文的大规模代码库。

实际上，AI编程助手往往会在代码中植入错误，侵犯版权，甚至在某些情况下，导致中断。

这时，程序员被迫成为「AI提示大师」，手动修复AI助手创建的任何问题。

谷歌对AI编码的吹捧，却成为了全网的华点。

有人表示，「问题在于，修复那25%代码中的bug所花费的时间超过了节省下来的时间」。

「现在Copilot这样的工具被广泛使用，研究表明它们实际上并没有提高生产力。所有相反的说法似乎要么是道听途说，要么就是营销噱头」。

另有网友表示，「时间会告诉我们AI输出质量是比熟练的程序员差、相当，还是更好，但对于超出明显的样板代码（比如for循环中需要的所有符号）或命名（如上面那位描述的函数名和注释自动补全）之外的任何建议，我都会非常谨慎」。

与此同时，在Reddit热帖中的网友称，「我认为我们不太关注采用率，而是更关心其他因素。它能提高开发速度吗？能提升代码质量吗？能改进维护性吗？我觉得这些还未可知。

更大的问题是，在大型企业中使用AI的ROI是多少？运行或训练这些AI大模型并不便宜」。

不过，又一位谷歌员工站出来，给了比较中肯的回答。

他首先承认了，AI写代码仅是工程工作的一小部分。

然后依据他个人经验，又认为「不过AI系统要比人们所描述的强大得多，也可能是因为我大多数情况下用C++，它比JavaScript有更大的训练语料。系统已经很擅长的一件事是根据注释写出完整的短函数」。

内部代码模型泄露，专为谷歌员工打造

在谷歌内部，开发者都在用什么模型写代码？

今年2月，BI从一份泄露内部文件中得知，谷歌悄悄推出了一款名为Goose的新模型供内部使用。

Goose是Gemini的一个分支，基于谷歌25年工程专业知识上完成训练，支持28k token上下文。

它不仅可以回答有关谷歌特定技术问题，还能使用颞部技术堆栈编写代码，还支持一些新功能，比如根据自然语言提示编写代码。

一份文件中指出，Goose计划成为谷歌内部编码使用的第一个通用LLM。

而且，谷歌计划是，通过Goose将AI带入产品开发过程的每个阶段。

92%美国码农用AI写代码

用AI辅助代码生成，已经成为大多数程序员的日常。

根据Stack Overflow 2024开发者调查报告称，超76%的人正在使用，或计划在今年开发过程中用上AI工具。其中，62%的人正积极使用AI工具。

上半年发布的GitHub开发者报告中，92%美国软件开发人员已经在工作内/外使用AI编码工具。

AI辅助编码于2021年首次在GitHub Copilot中大规模出现，并在次年6月正式对外发布。

当时，它使用的是OpenAI一个特殊编码的AI模型Codex。

该模型既可建议连续的代码，也可以从英语指令中从头开始创建新的代码。

从那时起，AI编码在全世界铺开。随后加入的玩家，比如Anthropic、Meta、Replit、OpenAI等不断完善解决方案。

最近，GitHub Copilot官宣扩展了新功能。并且，加入了Claude 3.5和Gemini 1.5 Pro模型。

一些人都在吹捧AI编码的强大能力，却也引起了另外一些人的批评。

斯坦福去年的一项研究显示，使用AI编码助手的开发者，代码错误更多。而且，他们比那些不用AI的人，更加相信AI编写了安全的代码。

论文地址：https://arxiv.org/pdf/2211.03622

虽然AI生成错误的编码是危险的，但回看软件开发的历程，也曾遇到过类似有争议的变化。

比如，从汇编语言到高级语言的过渡，在那时，也面临着一些程序员的反对。

他们所担心的是，我们不仅会失去控制，还降低了效率。

类似地，上世纪90年代，面向对象编程的采用，也遭到了复杂性、性能开销大的质疑。

在AI增强编码的最新转变中，也是同样如此。

微软前副总Steven Sinofsky表示，「无论你认为用AI编程在今天是否有效，都不重要」。

「但是，如果你认为GenAI编码会让人类变笨，或不是真正的编程，那么请考虑一下，这类批评其实一直都在（从最早的Fortran编程语言就开始了）」。

AI将如何改变科技就业市场

科技行业曾是众多人才竞相追求的热门领域，但如今却面临着职位减少的挑战。

根据Indeed.com的数据，自2020年2月以来，招聘岗位减少了30%。

Layoffs.fyi网站的报告也显示，今年科技行业的裁员潮仍在继续，自1月份以来，已有约13.7万个工作岗位被裁减。

造成传统科技职位需求下降的一个重要原因是，AI已经能够胜任许多曾经由人类完成的常规编程、编码和技术任务。

随着AI工具持续提高生产力，组织机构能够以更精简的团队实现更好的成果。因此，这一趋势正在减少软件开发和信息技术支持等领域的初级和中级职位需求。

另外，微软和领英最新发布的2024年工作趋势年度报告显示，雇主们对具备AI技能的求职者表现出强烈偏好。

报告指出，66%的企业领导者表示不会考虑没有AI技能的申请者，而71%的领导者更倾向于选择具备AI专业知识的新人，而非缺乏这些技能的资深人士。

在当前形势下，随着各公司纷纷致力于获取和培养AI人才，科技专业人士必须主动适应变化，提升自身在AI相关领域的技能，才能在瞬息万变的就业市场中保持竞争力。

AI在软件领域的崛起正在重塑软件工程师的角色定位，使其工作重心从传统编码转向AI监督和集成。这种转变需要一套全新的技能组合，将AI专业知识与伦理考量和高级系统设计有机结合。

随着领域的不断发展，工程师们必须转型成为具备AI思维的解决方案专家，能够熟练管理AI生成的代码，深入理解其局限性，并在这个新范式中持续创新。

参考资料：

https://news.ycombinator.com/item?id=42002212

https://arstechnica.com/ai/2024/10/google-ceo-says-over-25-of-new-google-code-is-generated-by-ai/#gsc.tab=0

https://www.forbes.com/sites/jackkelly/2024/11/01/ai-code-and-the-future-of-software-engineers/

https://www.reddit.com/r/google/comments/1gfrs03/google_ceo_says_over_25_of_new_google_code_is/

#三年前的AI设计芯片造假？

谷歌深陷学术不端丑闻，吹哨人被开除并已起诉

2021 年，谷歌在 Nature 发表了一篇颇具争议的论文《A graph placement methodology for fast chip design》。（作者包括 Jeff Dean 和 Quoc V. Le 等著名研究者），其中提出了一种基于强化学习的芯片设计方法。据介绍，该芯片设计方法可在不到六小时的时间内自动生成芯片布局，并且设计结果在功耗、性能和芯片面积等所有关键指标上都优于或媲美人类工程师，而后者需要耗费数月的艰苦努力才能达到类似效果。

事实上，谷歌在更早之前就已经发布了该论文的预印本，我们也曾做过报道，详情可参阅《6 小时完成芯片布局，谷歌用强化学习助力芯片设计》。

谷歌当时表示，这项基于强化学习的快速芯片设计方法对于资金紧张的初创企业大有裨益，可帮助初创企业开发自己的 AI 和其他专用芯片。并且，这种方法有助于缩短芯片设计周期，从而使得硬件可以更好地适应快速发展的技术研究。

论文虽然看起来大有前景，但三年来人们一直质疑不断。近日，最近一期 CACM 上，Synopsys 的杰出架构师 Igor Markov 总结了人们对这篇论文的各种质疑。

杜克大学陈怡然教授在微博上分享这篇文章

本文关键见解

谷歌在 Nature 杂志上发表了一篇关于 AI 芯片设计的革命性论文。大众媒体赞誉其是一项重大突破，但它遭到了领域专家的质疑，他们认为这篇论文好得令人难以置信，而且缺乏可复现的证据。

现在，交叉检验的数据表明，由于行为、分析和报告中的错误，Nature 的这篇论文的可信度受到了严重损害。对谷歌这篇论文中的欺诈和研究不当行为的详细指控已在加利福尼亚州提交。

Nature 在执行自己的政策方面进展缓慢。推迟撤回有问题的出版物正在扭曲科研过程。为了维护科学研究的诚实可信，必须迅速果断地采取行动。

导语

Mirhoseini et al. 在 2021 年在 Nature 发表了一篇论文，其中使用了强化学习（RL）来设计硅芯片。这篇论文得到了人们的巨大关注，也因证据不足而引发了争议。这篇来自谷歌的论文隐瞒了关键的方法步骤和重现其结果所需的大部分输入。

本文的元分析（meta-analysis）表明，有两项独立评估填补了这一空白。它们表明谷歌的这个强化学习方法赶不上人类工程师，也赶不上一种已知的算法（模拟退火）和普遍可用的商业软件，同时速度也更慢。通过对数据进行交叉检验后，Igor Markov 表示，由于行为、分析和报告中的错误，Nature 的这篇论文的可信度受到了严重损害。在本文发表之前，谷歌反驳了其内部仍然存在的欺诈指控。

由于 AI 应用需要更大的算力，因此可以通过更好的芯片设计来提高效率。发表于 Nature 杂志的这篇论文声称实现了 AI 芯片设计的突破。它解决了优化芯片上电路元件位置的难题，并描述了对五个张量处理单元（TPU）芯片块的应用。其还表示这个方法是当时学术界或工业界最好的。

该论文还将这些说法推广到芯片设计之外，表示强化学习在组合优化方面的表现优于最先进的技术。「非凡的主张需要非凡的证据」（卡尔・萨根），但该论文缺乏公开测试示例的结果，也没有分享所使用的专有 TPU 芯片块。源代码 —— 在论文发表后七个月发布，以在最初的争议之后支持该论文的发现 —— 缺少重现方法和结果所需的关键部分。

项目代码库已经停止公开或删除，https://github.com/googleresearch/circuit_training

来自谷歌和学术界的十多位研究人员对 Mirhoseini et al. 的实验提出过质疑，并对所报告的研究结果提出了担忧。此后，谷歌工程师多次更新他们的开源代码，填补了一些缺失的部分，但依然不是全部。谷歌这个软件库中的开源芯片设计示例并未清楚地显示谷歌 RL 代码的强大性能。

显然，唯一公开声称独立复现 Mirhoseini et al. 的技术是由加州大学圣地亚哥分校（UCSD）的研究人员于 2022 年秋季开发的。他们对谷歌开源代码中缺少的关键组件进行了逆向工程，并完全重新实现了代码中缺失的模拟退火 (SA) 基线。谷歌没有发布 Mirhoseini et al. 使用的专有 TPU 芯片设计模块，排除了完全外部复现结果的可能性。因此，UCSD 团队分享了他们在现代公共芯片设计上的实验：SA 和商业电子设计自动化 EDA 工具的表现均优于谷歌的强化学习代码。

《纽约时报》和路透社的记者在 2022 年报道了这场争议，并发现早在 Nature 杂志提交之前，一些谷歌的研究人员（见表 1）就对他们负责检查的声明提出了异议。

该论文的两位主要作者抱怨说，他们的研究一直存在欺诈指控。

2022 年，谷歌解雇了内部吹哨人，并拒绝批准发表一篇批评 Mirhoseini et al. 研究的文章。这位吹哨人依据吹哨人保护法，对谷歌提起了错误解雇的诉讼：法庭文件详细列出了与 Mirhoseini et al. 研究相关的欺诈和科学不端行为的指控。

2021 年 Nature 杂志在同一期上刊登了一篇介绍该论文的新闻观点文章，敦促复现该论文的结果。考虑到复现的障碍和复现尝试的结果，文章的作者撤回了该文章。2023 年 9 月 20 日，Nature 杂志为该论文添加了在线编者注。

一年后（2024 年 9 月晚些时候），随着这篇文章的发表，Nature 杂志的编者注已被移除，但出现了一份作者的附录。这份附录重复了早先声明中讨论的作者对批评的回应部分的论点。

但关于 Nature 论文的主要关切点还未得到解决。特别是，论文结果中关于一个额外的专有 TPU 块的未公开统计数据，并未支持任何实质性的结论。这只会加剧对选择性报告和误报的担忧。发布一个未说明预训练数据的预训练模型，也加剧了关于数据污染的担忧。

接下来，本文列出了对该论文的初步怀疑，并表明其中许多怀疑后来得到了证实。然后，本文检查了 Mirhoseini et al. 是否改进了现有技术，概述了作者的回应，并讨论了该工作在实践中的可能用途。最后，本文得出结论并指出了政策含义。

这里我们略过 Igor Markov 这篇文章中对原论文的介绍，详情可参阅《6 小时完成芯片布局，谷歌用强化学习助力芯片设计》。我们重点来看对该研究的怀疑和指控。

最初的怀疑

尽管登上 Nature 的这项研究复杂而又令人印象深刻，但研究有着明显的不足。

举例来说，文中提出的强化学习（RL）被描述为能够处理更广泛的组合优化问题（如旅行商问题）。但是，该研究并没有通过对关键问题的公式化和易于配置的测试示例来展示这一点，而是解决了一个专业任务（芯片设计的宏布局），仅针对谷歌专有的 TPU 电路设计块提供了五个块的结果，而可用的块远不止这些。

此外，RL 公式只是优化了一个包含 HPWL 的简化函数，但并未针对开放电路示例进行纯 HPWL 优化的评估，而这在其他文献中是常规操作。

可以说，这篇论文隐瞒了实验的关键方面，存在严重的遗漏，主要表现在以下几点：

第一点：标题中提到「快速芯片设计（fast chip design）」，然而作者只描述了设计过程时间从几天或几周到几小时的改善，但并没有提供针对每个设计的具体时间，也没有将设计过程细分为不同阶段。文章中并没说明白，几天或几周的基线设计过程是否包括了功能设计变更的时间、闲置时间、使用较低效的 EDA 工具的时间等。这种描述缺乏详细信息，使得读者难以理解设计时间实际缩短到了何种程度，以及这种改进的具体影响。

第二点：文章声称强化学习（RL）在每个测试用例中的运行时间不超过六小时（针对五个 TPU 设计块中的每一个），但这并没有包括全部的 20 个块。此外，RL 的运行时间仅涵盖了宏布局，而 RePlAce 和行业工具会放置所有电路组件。

第三点：Mirhoseini et al. 专注于宏布局，但却没有提供每个 TPU 芯片块中宏的数量、大小和形状，以及面积利用率等关键设计参数。

第四点：Mirhoseini et al. 只给出了五个 TPU 块的结果，其统计明显不足，而且高方差指标会产生噪声结果（见表 2）。通常情况下，使用更多的样本是常见的做法（见上表 1）。

第五点：Mirhoseini et al. 没有说明被强化学习（RL）超越的人类芯片设计师的资质水平。撇开可复现性不谈，这些结果后来在 Cheng et al. 的研究中被证明是可以轻易改进的。

第六点：Mirhoseini et al. 声称改善了面积，但芯片面积和宏面积在布局过程中并未改变，标准单元面积也没有变化（参见表 2）。

第七点：对于结果随时间推移而优化的迭代算法，应该公平地比较每个测试用例在相同运行时间下哪个具有更好的质量指标，或在相同质量下哪个具有更好的运行时间，或两者都有所改进。Mirhoseini et al. 没有提供这样的证据。特别是，如果基于机器学习的优化使用了非凡的计算资源，那么在其最有竞争力的形式中，模拟退火（SA）优化也应当使用同等的计算资源。这意味着在评估和比较这两种方法的效果时，应确保它们在资源使用上处于同一水平，以保证比较的公正性。

对于专家来说，Mirhoseini et al. 提出的方法似乎存在缺陷，主要表现在：

H1. 与 SOTA 相比，提出的 RL 使用了过多的 CPU/GPU 资源。因此快速芯片设计的说法需要仔细证实。

H2. 逐个放置宏是最简单的方法之一。然而即使在深度 RL 的驱动下，逐个放置看起来也很不方便。

H3. Mirhoseini et al. 使用了与 20 多年前类似的电路分区（聚类）方法。众所周知，这些技术与互连优化目标有所不同。

H4. Mirhoseini et al. 将宏的位置限制在一个粗粒度的网格上，而最新的方法则避免了这种限制。在图 1（左）中，宏被自由放置，但谷歌的强化学习倾向于将宏分散开来，并且不允许在如图 1（左）中心这样的大区域内放置单元。图 2 展示了这种差异。这表明，虽然强化学习技术在处理某些设计任务上具有潜力，但其在处理大规模电路设计时可能需要依赖于简化的网格系统，这可能限制了其优化效果和应用范围。

H5.Mirhoseini et al. 使用的力导向放置技术，仍有很大的改进空间。

除了上述内容，还有值得怀疑的基准。Nature 杂志使用了多个基准来宣称所提技术的优越性。然而人类基准没有记录，并且不可复现。

B1. Mirhoseini et al. 和表 1 中的关键结果给出了五个 TPU 设计模块的芯片指标。但与 SA 的比较并没有报告这些芯片指标。

B2. Mirhoseini et al. 提到，强化学习（RL）的结果经过了模拟退火（SA）的后处理，但缺乏消融研究来评估 SA 对芯片指标的影响。

B3. 在 Mirhoseini et al. 的研究中，RePlAce 被用作基准，但这种使用方式与其预期用途不一致。

B4. Mirhoseini et al. 没有描述在模拟退火（SA）中如何初始化宏位置，这表明作者可能采用了一种可以改进的简单方法。后来，Bae et al. 确定了 SA 基线中的更多缺点，而 Cheng et al. 也证实了这些问题。

更多证据

那篇 Nature 论文发表几个月后，那是在最初阶段的争议之后，Bae et al.、谷歌的文档和开源代码、Nature 同行评议、Yue et al. 给出了更多数据。

Nature 给出了对 Mirhoseini et al. 的同行评议文件以及作者的反驳。在漫长的来回沟通中，作者向审稿人保证，宏的位置在 RL 放置后没有被修改，证实了宏是粗粒度网格放置的。在几份投稿中，Bae et al. 实现了 Nature 审稿人的要求，并在 17 个公开芯片设计示例上对谷歌的技术进行了基准测试，结果表明：先前的方法明显优于谷歌 RL。

美国和德国的一些教授公开表达了对这篇 Nature 论文的质疑。当研究人员注意到谷歌开源版本中的缺陷时，例如分组（聚类）流程，谷歌工程师发布了更多代码（但不是全部），这反倒引发了更多问题。

又过了一年，最初的怀疑变大了，因为结果表明，当宏布局不局限于网格时，人类设计师和商用 EDA 工具的表现均优于谷歌这个方法。在 Cheng et al. 的表 2 中，作者估计了通过 RL 优化的代理成本函数与 Nature 论文表 1 中使用的芯片指标的秩相关性。Cheng et al. 在表 3 中估计了基于 RL 的优化之后，芯片指标的平均值和标准差。

本文的表 2 给出了一些总结，可以看到所有芯片指标的秩相关性都很低，而 TNS 和 WNS 的噪声程度很高。

因此，Mirhoseini et al. 对 TNS 和 WNS 的优化依赖于有缺陷的代理，并产生了统计意义可疑的结果。可以注意到，在 Ariane-NG45 以及 BlackParrot-NG45 上的 TNS 的 σ/|μ | > 0.5。除了媒体的批评，Mirhoseini et al. 也受到了三位美国教授的质疑。

未公开使用商业工具的 (x, y) 位置

UCSD 的那篇论文中给出了强有力的证据和谷歌工程师的确认，表明作者隐瞒了一个关键细节：在对输入网表进行聚类时，谷歌代码中的 CT merge 会读取一个位置以根据位置重组集群。为了生成宏的 (x, y) 位置，论文的作者使用了 Synopsys 的商业 EDA 工具生成的所有电路元件（包括宏）的初始 (x, y) 位置。

Mirhoseini et al. 的主要作者确认使用了这一步骤，并声称这并不重要。但在 Cheng et al. 的论文中，该步骤可将关键指标提高 7-10%。因此，Mirhoseini et al. 的结果需要未被明确说明的算法步骤，例如从商业软件中获取 (x, y) 数据。

Cheng et al. 的论文中还列举了更多未在论文中说明的技术，其中还提到了 Nature 论文、其源代码与谷歌芯片设计实际使用的代码之间的差异。这些差异包括代理成本函数中项的特定权重、与电路不同的邻接矩阵构造，以及 Mirhoseini et al. 的论文中没有源代码或完整描述的几个「黑箱」元素。Bae et al.、Cheng et al.、Macro Placement Repo 提供了缺失的描述。此外，Mirhoseini et al. 的结果与所用方法不符，因为论文中没有提到一些关键组件。仅凭描述无法复现其结果和方法。

训练数据和测试数据之间存在数据泄漏

根据 Mirhoseini et al. 的说法，「当我们将策略网络暴露给更多种类的芯片设计时，它就不太容易过度拟合。」

但谷歌 Team 1 后来在 Yue et al. 中表明，对「多样化 TPU 块」进行预训练并没有提高结果质量。对「以前的网表版本」进行预训练会稍微提高质量。对 RL 进行预训练并在类似设计上对其进行评估可能是 Mirhoseini et al. 方法论中的一个严重缺陷。由于谷歌没有发布专有的 TPU 设计或每个设计的统计数据，所以无法比较训练和测试数据。

可能的局限性

Mirhoseini et al. 没有透露其方法的主要局限性，但却表示其可在更广泛的组合优化中取得成功。Mirhoseini et al. 中的 Ariane 设计显示了相同大小的宏模块：这是一个潜在的限制，因为商用芯片设计通常会使用多种不同的宏尺寸。然而，他们没有报告每个 TPU 块的基本统计数据：宏的数量及其形状、设计面积利用率以及宏占用的面积分数。根据同行评议和谷歌工程师对 Cheng et al. 作者的指导，TPU 块的面积利用率似乎低于典型的商用芯片设计。

谷歌 RL 在 Bae et al. 和 Cheng et al. 中使用的 Adya 和 Markov 的具有挑战性的公共基准测试上表现不佳（如图 2 所示），这表明存在未公开的局限性。

另一个可能的限制是对预置（固定）宏的处理不当，这在行业布局中很常见，但 Mirhoseini et al. 没有讨论过。通过干扰预置宏，网格化可能会影响实践中的可用性。

在公共基准测试上的表现不佳的原因也可能是由于对专有 TPU 设计的过度拟合。

使用中等的模拟退火基线

谷歌 Team 2 的更强基准论文《Stronger baselines for evaluating deep reinforcement learning in chip placement》通过在 swap、shift 和 mirror 操作中添加 move 和 shuffle 操作，改进了谷歌 Team 1 在 Mirhoseini et al. 中使用的并行 SA。在优化相同的目标函数时，这种改进的 SA 通常会在更短的时间内产生比 RL 更好的结果。

Cheng et al. 通过独立实现 SA 复现了 Bae et al. 的定性结论，发现 SA 结果的方差小于 RL 结果。

此外，Bae et al. 为 SA 提出了一种简单快速的宏初始化启发式方法，并在比较 RL 与 SA 时可均衡计算时间。

鉴于 SA 在 1980 到 1990 年代被广泛使用，与弱的 SA 基线相比，自然会导致新的 RL 技术被高估。

这篇 Nature 论文是否提高了现有技术水平？

Nature 杂志的社论在讨论该论文时推测：「这是一项重要的成就，将对加速供应链产生巨大的帮助。」

但在多家芯片设计和 EDA 公司进行评估和复现尝试后，可以肯定地得出结论，这篇 Nature 论文没有取得任何重要成就，因为以前的芯片设计软件，特别是来自 Cadence Design Systems 的软件，可以更快地产生更好的布局。如果该论文的审稿人或公众都知道这些事实，那么该论文关于改进 TPU 设计的主张将是荒谬的。

这篇 Nature 论文声称人类比商业 EDA 工具产生了更好的结果，但没有给出证实。

谷歌 Team 2 和 UCSD 团队采用不同的方法将 Mirhoseini et al. 中的方法与基线方法进行比较，累积报告了与商业 EDA 工具、人类设计师、学术软件以及 SA 的两个独立自定义实现的比较结果。

谷歌 Team 2 遵循 Mirhoseini et al. 中的描述，没有提供初始布局信息。UCSD 团队试图复现谷歌实际所做的事情以产生结果（缺乏 Mirhoseini et al. 的详细信息）。

谷歌 Team 2 可以访问 TPU 设计模块，并证明预训练的影响实际上很小。

尽管 UCSD 团队无法访问谷歌的训练数据和代码，但还是获得了与 Mirhoseini et al. 类似的结果，无需预训练。他们还按照谷歌 Team 2 的指令重新实现了 SA，并引入了几个新的芯片设计示例（表 1）。

Nature 论文中 RePlAce 的使用方式与其预期用途不一致。Bae et al.、Cheng et al. 通过正确使用 RePlAce，在 ICCAD 2004 基准测试中为 RePlAce 取得了出色的结果。

Nature 论文中使用的模拟退火的实现存在障碍，消除障碍（在同一源代码库中）改进了结果。如果正确实现，SA 会使用更少的运行时间产生比谷歌 CT/RL 更好的解决方案，并且两者都被赋予相同的代理成本函数。Bae et al.、Cheng et al. 证明了这一点。

与谷歌 CT/RL 相比，SA 持续改进了线长和功率指标。对于电路时序指标 TNS 和 WNS，SA 产生的噪声较小，但与 RL 的结果相当。回想一下，SA 和 RL 优化的代理函数不包括时序指标，这使得 SA 或 RL 实现这些改进的断言显得很可疑。

谷歌 CT/RL 未能在人类基线、商业 EDA 工具和 SA 的质量上有所提高。它也没有改进运行时 SOTA（表 3），并且作者没有透露每个设计数据或设计过程的时间。如果配置 / 实现得当，RePlAce 和 SA 会提供更强的基线。

对这篇 Nature 论文批评的反驳

尽管媒体进行了批评并提出了技术问题，但作者未能消除 Mirhoseini et al. 的方法和结果的复现的剩余障碍。

UCSD 团队的工程努力克服了这些障碍，他们跟进了谷歌 Team 2 批评 Nature 论文的工作，然后分析了其中的许多问题。在 CT 代码库出现之前，谷歌 Team 2 就可以访问谷歌 TPU 设计和论文中使用的源代码。Cheng et al. 和 Macro Placement Repo 的 UCSD 作者可以访问 CT 并受益于谷歌 Team 1 工程师的长期参与，但无法访问 Bae et al. 或 Mirhoseini et al. 中使用的 SA 代码或 CT 框架中缺失的其他关键代码片段。

然而，Bae et al.、Cheng et al. 的结果与 Macro Placement Repo 相互印证，并且他们的定性结论是一致的。UCSD 的 Ariane-NG45 结果与 Google Team 1 工程师的结果非常匹配，Cheng et al. 中表明 UCSD 生成的 Ariane-NG45 的 CT 训练曲线与 Google Team 1 工程师生成的结果相匹配。谷歌 Team 1 工程师仔细审查了该论文以及 2022 年秋季和 2023 年冬季的研究结果，没有提出异议。

Nature 论文的两位主要作者于 2022 年 8 月离开谷歌，但在 2023 年 3 月，他们对 Cheng et al. 的结果提出了反对。没有弥补原工作的缺陷。这些反对意见立即在宏布局代码库的 FAQ 部分得到解决。其中一个问题是 Cheng et al. 的实验中缺乏预训练。

预训练

Cheng et al. 使用谷歌 Circuit CT 库中的代码和指令进行训练，其中指出（2023 年 6 月）：「以下结果是从头开始训练的结果，因为目前无法共享预训练模型。」

根据 Macro Placement Repo 中的 MacroPlacement FAQ，Cheng et al. 没有使用预训练，因为根据谷歌的 CT FAQ，不需要预训练来重现 Mirhoseini et al. 的结果。此外，谷歌没有公布预训练数据。

谷歌 Team 2 使用谷歌内部的代码评估预训练，发现对与 SA 或 RePlAce 的比较没有影响。

谷歌 Team 1 表明「不同 TPU 块」的预训练并没有改善结果，只改善了运行时间。「以前的网表版本」的预训练略有改善。CT 文档或论文本身没有讨论、披露或发布此类先前版本。

换句话说，Nature 论文的主要作者希望其他人使用预训练，但他们没有足够详细地描述它以进行复现，没有发布它的代码或数据，并且已经表明它不会改善预训练的结果。

2024 年 9 月（发表几年后），作者宣布发布预训练模型，但未发布预训练数据。因此，我们无法确保用于测试的特定示例未在预训练中使用。

基准老旧

另一个反对意见是 Bae et al. 和 Cheng et al. 使用的公共电路基准测试据称使用了过时的基础设施。

事实上，这些基准已经使用 HPWL 目标进行了评估，该目标可以在芯片设计的几何 2D 缩放下准确缩放，并且仍然适用于所有技术节点（第 2 节）。ICCAD 基准是由那篇论文的同行评审员 #3 要求的。当 Bae et al. 和 Cheng et al. 实现了这个要求，在路由变得相关之前，谷歌 RL 遇到了麻烦：在 HPWL 优化中，RL 差了 20% 左右（HPWL 是 CT/RL 优化的代理成本中最简单但最重要的项）。

Cheng et al. 的实验中，没有训练到收敛

Macro Placement Repo 中的 FAQ #15 立即解决了这一问题：「CT GitHub 存储库提供的任何指南中都没有描述『训练到收敛』。」

后来，他们的额外实验表明，「训练直到收敛会恶化一些关键芯片指标，同时改善其他指标，凸显了代理成本和芯片指标之间的不良相关性。总体而言，与 ISPD 2023 论文中报告的模拟退火和人类宏放置的结果相比，直到收敛的训练不会发生质的变化。」Bae et al. 的 RL-vs-SA 实验早于 CT 框架，也早于 Mirhoseini et al. 声称的训练不到 6 小时就收敛的方法。

Nature 论文使用的计算资源非常昂贵且难以复现。由于 RL 和 SA 算法都会在早期产生可行的解决方案，然后逐渐改进代理函数，因此 Cheng et al. 的尽力而为的比较使用的计算资源比 Mirhoseini et al. 的计算资源要少，并且 RL 和 SA 之间具有同等性。结果：SA 击败 RL。

Bae et al. 使用与 Mirhoseini 相同的计算资源对 RL 和 SA 进行了比较。Cheng et al. 的结果与 Bae et al. 的结果一致。如果给予更多资源，SA 和 RL 不太可能进一步改善芯片指标，因为其与 Mirhoseini 的代理函数相关性较差。

该论文的主要作者在 Goldie 和 Mirhoseini 在声明《Statement on reinforcement learning for chip design》中提到，该论文被大量引用，但他们没有引用谷歌之外的任何积极的复现结果来清除所有已知的障碍。Bae et al. 和 Cheng et al. 没有讨论在 IC 设计中使用 RL 的其他方法，因此这里不再进行一般性结论。

谷歌这篇论文中的成果可用吗？

发表于 Nature 的这篇谷歌论文声称这些方法可应用于最近的谷歌 TPU 芯片，这似乎佐证了他们声称的东西：即这些方法改进了最新技术水平。但除了含糊的一般性声明外，没有报告明确说明对生产级芯片的芯片指标改进。

前文已经表明，该论文和框架中的方法落后于 SOTA，例如 1980 年代的模拟退火（SA）。此外，谷歌的 Bae et al. 内部实现的 SA 足以替代那篇 Nature 论文中提出的强化学习方法。谷歌既声称在 TPU 设计中使用了这个 RL 方法，但实际上这个方法又落后于 SOTA，为什么会这样？这篇文章试图给出一些解释。

鉴于芯片时序指标 TNS 和 WNS 在强化学习结果中的方差较大，所以使用远远更长的运行时间，尝试使用不同的代理成本函数和超参数设置进行多次独立随机尝试可能会改善最佳结果，但 SA 也能做到这一点。
使用内部方法（即使是较差的方法）是行业实践中称为 dogfooding（吃自己的狗粮）的常见方法。在大多数芯片中，一些块并不重要（不会影响芯片速度），是很好的 dogfooding 候选。这可以解释谷歌为什么选择性地公布生产级使用」和报告。（注：在芯片设计领域，dogfooding 是指芯片设计公司内部的工程团队会使用自己设计的芯片进行测试和验证，以确保芯片满足预期的性能、功能和质量。这种方法可以帮助团队发现潜在的设计缺陷、优化用户体验，并提前解决问题，而不是等到产品发布后才被客户发现。）
强化学习的结果由 SA30 进行过后处理，但 CT FAQ 否认了这种后处理 ——TPU 设计流程中使用了后处理，但在将 RL 与 SA 进行比较时未使用。但由于成熟的 SA 始终胜过强化学习，因此 SA 完全可以替代强化学习（可以使用 SA 中的自适应温度调度来适应初始位置）。

谷歌 Team 1 的后续研究表明（如图 7 所示），仅在对基本相同的设计进行预训练时，预训练才能改善结果。也许，谷歌在对 IC 设计进行多次修订时利用了强化学习 —— 这是一个有效的背景，但这篇 Nature 论文中没有描述这一点。此外，从头开始运行时，商用 EDA 工具的速度比强化学习快几个数量级，因此预训练 RL 并不能缩小差距。

谷歌 CT/RL 代码可以得到改进吗？

RL 和 SA 比 SOTA 慢几个数量级（表 3），但预训练（CT 中没有）仅能将 RL 的速度提高几倍。CT 代码库现在包含尝试过的改进措施，但我们尚未看到芯片指标的重大提升。改进版 CT 库和论文仍然存在四个主要障碍：

RL 优化的代理成本并不能反映电路时序，因此改进 RL 可能无助于改进 TNS 和 WNS。
在优化给定的代理函数时，SA 优于 RL。因此，即使使用更好的代理，RL 也可能会失败。
RL 在粗粒度网格上放置宏会限制它们的位置（图 2）。当人类忽略粗网格时，他们会找到更好的宏位置。商用 EDA 工具也避免了这种限制，并且优于谷歌的 CT/RL。
作为预处理步骤的聚类会导致放置和网表分区目标之间不匹配。

总结

这篇元分析讨论了对 Mirhoseini et al. 那篇 Nature 论文的结果的复现和评估，以及其中方法、结果和声明的有效性。他们发现，那篇论文中包含机器学习中的多种可疑做法，包括不可重复的研究实践、挑选好结果、误报和可能的数据污染。

基于交叉检验的新数据，本文得出了具有足够冗余度的结论：由于研究中实现、分析和报告中的错误，该论文的可信度严重不足。遗漏、不一致、错误和失实陈述影响了他们的方法、数据、结果和解释。

关于那篇 Nature 论文的结论

谷歌 Team 2 可以访问谷歌的内部代码，而 Cheng et al. 对缺失的组件进行了逆向工程和 / 或重新实现。谷歌 Team 2 和 UCSD 团队从类似的实验中得出了一致的结论，并且每个团队都进行了额外的观察。

这里交叉检查了谷歌 Team 2 和 UCSD Team 报告的结果，并考虑了 CT 框架、Nature 同行评议和 Yue et al. ，然后总结了这些工作得出的结论。这证实了对这些声明的许多初步怀疑，并发现了其他缺陷。

因此，很明显，Mirhoseini et al. 的 Nature 论文在多个方面具有误导性，以至于读者无法相信其最重要的声明和结论。Mirhoseini et al. 没有改进 SOTA，而原始论文的方法和结果无法从提供的描述中重现，这违反了 Nature 的既定编辑政策。依赖专有的 TPU 设计进行评估，以及实验报告不足，继续阻碍着方法和结果的可复现性。

这篇 Nature 论文作者试图驳斥批评，但未能成功。

令人惊讶的是，自 Cheng et al. 发表论文以来，Mirhoseini et al. 的作者在一年半内没有提供新的令人信服的实证结果。

对芯片设计的影响

这里仅强调了那篇 Nature 论文方法中的不足之处。但 2024 年来自中国的一项研究成果《Benchmarking end-to-end performance of AI-based chip placement algorithms》使用他们新的独立评估框架比较了七种混合尺寸布局技术，其中有 20 个电路（其中七个带有宏）。

他们在芯片指标上的端到端研究结果表明，基于 ML 的技术落后于 RePlAce（嵌入在 OpenROAD 中）和其他基于优化的技术：DREAMPlace（基于 GPU 的 RePlAce 算法变体）和 AutoDMP（围绕 DREAMPlace 的贝叶斯优化 wrapper）。尽管复现 Mirhoseini et al. 的方法具有明显的必要性，但 Wang et al. 的作者无法提供这样的结果。

政策影响

理论论证和实证证据表明，各个领域发表的大量论文无法复现，而且可能不正确。比如 Nature 杂志这篇论文就加剧了复现危机，破坏了人们对已发表研究的信任。

Retraction Watch 每年能追踪到 5000 起撤稿事件，包括突出的研究不端行为案例。其表示，「研究不端行为是一个严重的问题，而且（可能）越来越严重」，这使得我们更有必要将诚实的错误与故意夸大和不端行为区分开来。机构需要给出回应，包括在 Nature 撤稿通知中进行明确说明。

Nature 的编辑政策应被广泛而严格地遵守。引自《Nature Portfolio》：

「出版的固有原则是，其他人应该能够复现和借鉴作者发表的主张。在 Nature Portfolio 期刊上发表论文的条件是，作者必须及时向读者提供材料、数据、代码和相关协议，而无需要求资格…… 出版后，如果读者遇到作者拒绝遵守这些政策的情况，应联系期刊的主编。」

具体到 Mirhoseini et al. 这篇论文，杂志社论坚称「技术专长必须广泛分享」。但是，当稿件作者忽视公开基准测试的要求并阻碍复现时，他们的技术主张应该受到怀疑（尤其是如果他们后来不同意与他们的工作进行比较）。

根据同行评议文件，这篇论文的接收取决于代码和数据的发布，但在 Mirhoseini et al. 发表时或之后，这都没有发生。

这些作者还对那篇 Nature 论文进行了修改，声称代码已经可用。但发布的代码中仍然存在严重遗漏。这尤其令人担忧，因为该论文省略了关键的比较和细节，并且负责评估该项目的谷歌吹哨人在加州法院宣誓指控存在欺诈行为。这使得复现变得更加关键。

对于已发表的科学主张，得出明确无误的结论符合每个人的利益。作者、Nature 杂志的编辑和审稿人以及研究界都应承担责任。寻求真相是大家共同的义务。

参考链接：

https://cacm.acm.org/research/reevaluating-googles-reinforcement-learning-for-ic-macro-placement/

https://weibo.com/2199733231/OErfamQry

#ChatGPT已经慢了

又一个大垃圾出来吹了把

这是国内AI搜索新高度，免费可用

最近几天，谷歌、微软等老牌搜索巨头们的压力陡增！原来，向他们发起挑战的 AI 搜索领域「战火重燃」。

先是 Meta 被曝出正在开发 AI 搜索引擎，以减少在 AI 实时摘要生成中对谷歌和微软的依赖；紧接着 ChatGPT 正式完成向 AI 搜索的升级，让用户通过网络资源链接快速获取实时搜索结果。

OpenAI CEO 奥特曼直言，「你一用就回不去了」。

Meta、OpenAI 的动作又一次证明了用大模型重塑搜索引擎的巨大潜力。最近一两年，以 GPT 为代表的大语言模型催生了搜索范式的转变，无论是在原有搜索产品上的 AI 能力升级（如谷歌、微软），还是以对话式搜索为代表的 AI 新应用（如 Perplexity），搜索引擎与 AI 的融合已经被按下了「快进键」。

国内玩家也敏锐察觉到了搜索领域变革的新契机，入局者纷纷探索用生成式 AI 大模型重构搜索底层逻辑和整体链路，并构筑起自己的优势。其中，昆仑万维在 2023 年 8 月推出了国内第一款融入大模型能力的 AI 搜索引擎「天工 AI」，成为「第一个吃螃蟹的人」。这同时也是该公司短短一年内连发大语言模型「天工 1.0」到「天工 3.0」并拓展 AI 能力边界的重要举措和一大支点。

不过，AI 搜索厂商想要持续在这个赛道分得一杯羹，则需要丰富自己的「武器库」。一直以来，昆仑万维正是这样做的，通过迭代更新集成更多功能、完善搜索体验，在加速搜索范式革新的同时吸引越来越多的人用起来。

今日，天工 AI 在功能上再次升级，正式发布最新版本的 AI 高级搜索功能，上线即人人可用。与以往版本相比，此次天工 AI 在多个维度都进行了强化。

首先面对复杂问题的解决全面升级了多层次分析推理能力，再难的问题都努力为你解答。其次细分了更明确的目标群体，升级了金融投资和科研学术专业 AI 搜索，将这些领域的解答精准度提升到了前所未有的水平。最后针对文档 AI 阅读分析进行了智能优化，大大提升理解分析、归纳总结能力并支持处理超过 500k 字的超长文本。

体验地址：https://www.tiangong.cn/

在主打的金融投资与科研学术方向，天工 AI 在引用信源的量和质上均做了强化，引入超过 10 亿的专业型数据，覆盖海内外权威学术文档、研报、财报等网页和 PDF 文档，并对这些原始数据进行了深度解析，能够识别文字、图片、图表等多模态内容，输出图文并茂的搜索结果。同时，分钟级的信源收录系统让信息时效性更强，信源排序优化让搜索结果条理更清晰。

但此次升级后的成色如何，能否真正满足这些专业场景的搜索与查询需求，只有用过后才能给出公正评价。第一时间，我们对天工 AI 高级搜索功能进行了一番实测。

你的投资顾问何必是真人

AI 搜索想要变身成为一个可靠的金融投资助手，接入专业、权威、丰富的数据来源是至关重要的第一环。

昆仑万维不仅接入了全球多家权威金融数据库，而且挖掘中国境内 5000 多家上市公司和美国上市中概股的官网、专业财经网站等信源，全方位收录公司资讯、财报、研报等专业数据、以及各大券商资深分析师报告、大 V 分析预测等其他数据。

在此基础上，天工 AI 专为该领域打造了智能财经 Agent，能够第一时间获取市场动态并进行实时、准确的金融分析，扮演起了股票投资顾问、财报分析师的角色。

当你手中有 50 万闲钱想要投身股市，却不知道如何下手时，天工 AI 会手把手地教你，从开设账户、选择股票、分配资金等，都给出了详细的建议。

当你选定了新能源板块，又不知道具体买入哪只股票时，不妨听听天工 AI 给出的分析（PS：结果仅供参考，买股需谨慎）。

当你想了解一家上市公司某天的股价时，天工 AI 快速给出了准确的收盘价，还对市场背景以及可能影响股价的因素展开了全面解读。

当你转入创业板，想了解一些股票的资产负债率情况时，直接问天工 AI，马上就能列出符合条件的股票来。

在帮助用户选股和诊股之余，天工 AI 还具备了更大的视野观察能力，可以深入、客观地剖析宏观经济政策对金融市场的深远影响。从结果来看，总结得面面俱到。

同时，天工 AI 还能帮助用户分析企业财报，包括关键财务数据、各个业务板块的营收表现等，并对下个季度发展前景做出合理展望。

能够做到以上这些，天工 AI 依托的不单单是权威、专业的金融财经数据，以下几个关键方面的深入开发与优化同样必不可少：

对全网研报进行质量分级，通过自然语言处理和内容质量评估模型筛选出高质量研报资源；
内置涵盖各类金融问题的分析方法库，结合使用深度学习模型和专家知识体系，具体「问题场景」具体分析；
智能选择信息来源和识别优质内容，智能信息决策机制可以根据用户查询需求选择合适的、高质量的内容和数据源，并通过内容分析算法自动过滤泛泛信息，确保输出深度和专业内容。

简单总结一下，金融搜索属性加强下的天工 AI，无论是对于初入投资圈的小白、还是已经摸爬滚打很久的老手，相信都能成为他们信赖的信息查询助手。

变身最强科研搭子

作为此次天工 AI 高级搜索着重发力的另一大领域，昆仑万维建立了国内科研学术 AI 搜索方向最全的学术元数据库，基于自研的网页调度系统从全球学术网站分钟级发现、爬取并收录了全学科英文论文 2 亿多篇；同时收录了 X、Substack 等平台的活跃学术讨论观点，进一步加强了学术论文的全方位解读和分析。

如此一来，天工 AI 在学术信源的权威性和时效性方面大大提升，在处理用户的学术问题搜索时更加得心应手、值得信赖。

我们首先让天工 AI 总结了一波「Mamba 架构在学术领域的现状」，它交出了一份内容详实、图文交织的分析报告。仅从这一个案例，我们便发现了很多亮点功能，比如引用大量的 arXiv 学术论文，更能保证搜索结果的专业性。

其中高质量的 PDF 学术信源以悬浮窗的方式引入到搜索结果中，并显示标题、期刊、发布日期、原文等信息。并且对于想要更深入了解引用论文原文的用户，天工 AI 提供了「深度解析」功能，可以利用该功能进行延展精读。

从下图中可以看到，深度解析功能可以对引用学术论文的研究背景、研究方法、实验设计与结果进行一一剖析。同时提供了更贴心的论文点评和论文十问功能，前者通过对论文的整体评价为用户判断论文质量提供参考，后者帮助他们进一步读透论文。

在界面右侧，天工 AI 还支持了对引用原文的多轮次 AI 对话。用户既可以使用示例问题，也可以追问任何问题，打破砂锅问到底。

同时，「脑图」功能可以生成更有条理的思维导图，帮助用户更快了解文章整体脉络，并支持一键保存。

天工 AI 还能快速定位到某个主题的相关论文，并自动生成论文摘要，让用户轻松 get 到核心内容。

另外，搜索结果在一些细节展示上也做得很好，比如在解答对比属性的问题（前缀调优与提示调优的区别是什么）时，生成的表格能够让用户直观地看到关键差异。

我们拿竞品 Perplexity、ChatGPT 做了比较，天工 AI 高级搜索的「含金量」不言而喻，在引用信源、内容详实度、组织结构、图文排版等多个方面显然都更胜一筹。

Perplexity Pro 版本。

GPT-4o 版本。

可以说，在保证搜索结果更加专业、准确之外，天工 AI 让我们切实体验到了 AI 搜索在交互性、易用性、延展性等方面质的变化。

推理规划更像人了

在体验过程中，天工 AI 高级搜索的另一大特点 —— 针对复杂问题的分析推理与逐步解决，也给了我们惊喜。

最近以 OpenAI o1 为代表的大模型展现出 AI 能模拟人类的思考和推理过程，并由此获得更高质量的输出结果。这一次，天工 AI 自研的大模型搜索 Agent 也拥有了这项技能。

如下图所示，天工 AI 像人一样主动进行思考和推理，从多个维度（包括英伟达市值飙升的具体情况、原因、对财务表现和业务发展的影响、以及对整个半导体行业的影响）来理解和剖析问题。

接下来便自动生成搜索任务规划并逐步完成预设任务路径，还在每一步检查任务执行的情况，给出了系统、清晰的推理。

长思考、强推理和多步任务执行下的搜索结果，想必能够符合用户对天工 AI 的预期。

再比如查询今年的诺贝尔物理学奖获得者时，天工 AI 主动提供了两位获奖人的出生日期、毕业院校以及主要贡献等更多信息。

此外，主动扩展能力让 AI「想用户之所想」，面对一个再简单不过的需求，能够给出超级全面、关联性强的搜索结果。

深度回答能力则让搜索结果更有深度、更具说服力、更有实际指导价值，用户可以直接采纳使用。

如大模型一样，当 AI 搜索有了推理能力，它会变得更加聪明、更有逻辑，当然能交出一份比常规 AI 搜索更系统的答案。

再长的文档也能搞定

在上文中，我们已经体验到了天工 AI 对 PDF 学术论文的深度解析，这正是针对文档 AI 阅读分析的智能优化所带来的成果。

在技术实现上，这一功能要归功于自研的 PDF 文档解析引擎以及开发出的文档解析大模型，对文档标题、作者、摘要、引用、图片、表格、公式、子标题等指标进行全方位优化并达到 SOTA，尤其在多列文档、分页换行上精调了识别大模型并超越当前所有模型。底层技术的投入为用户打造了一个 PDF 文档分析小能手。

除了利用 PDF 悬浮窗体验该功能之外，用户也可以在「AI 文档 - 音视频分析」中直接上传 PDF 进行解析。

不只是学术论文，天工 AI 同样支持了对公司财报、券商研报的深度解析。下图中将十几页的财务报表整理成了关键指标表格，帮助投资者更好地洞见企业经营状况。

同样地，篇幅更长（八十几页）的券商研报也能以图文交织的方式呈现给用户。

跨文档摘要问答也搞得定，支持用户上传并解读多个文档（如谷歌母公司 Alphabet 第一二季度财报），还能在联合分析基础上回答各种问题。

几轮测试看下来，这次学术圈以及想要踏足和深耕金融圈的小伙伴终于有了一个用起来顺手、且靠得住的 AI 搜索神器。为了打造出这样一个专业、智能和高效的 AI 解答机器，昆仑万维在背后投入了很多。除了信源和数据方面的优势，天工 AI 能够进化到如今的高级搜索，还离不开以下几项关键的技术支撑：

分钟级实时内容检索能力，快速检索和索引新闻媒体网站最新资讯，以及财经和学术论文等专业垂类站点的权威信息。
高权威信息提供能力，借助人工审核的信源权威度评价体系、识别低质虚假信息的大规模预训练语言模型技术以及融合 PageRank、GNN 等多种算法的信息质量评估模型，三管齐下，为信息权威性多重把关。
高精准信息索引和召回能力，基于大规模预训练语言模型以及使用「分片」和「多域建模」技术的检索模型，对每篇文章进行语义分片和分域建模以提高检索召回精准性。同时，面向不同专业领域设计的特定检索模型又进一步提升相应领域的搜索体验。
更好的搜索结果排序体验，天工搜索引擎构建了一个基于 MoE 结构的大规模预训练语言模型、并结合外部知识库和多目标信息（比如相关性、权威性、时效性和质量）的综合理解和排序系统。

而借助此次高级搜索功能，天工 AI 再次升级了自己的武器库，并将在专业转型的路上走得更稳、更领先于其他竞争对手。

结语

2023 年 2 月，微软 CEO 纳德拉在接受采访时表示，搜索引擎将被 AI 彻底颠覆。如今不到两年时间，AI 搜索已经成为大模型应用的重要方向，入局者更多也更卷。虽然 AI 搜索未来很长时间内无法取代传统搜索引擎，但依然会潜移默化地改变人们的搜索习惯并有可能重塑市场格局。

如果想在全新 AI 搜索时代中立于不败之地，先人一步很重要。因此，作为推出国内首个 AI 搜索引擎的先行者，昆仑万维无疑已经赢在了起跑线。然而，仅有先发优势显然也不够，还要继续打磨底层大语言模型技术，优化算法、创新功能，这样才能将自身在该赛道的优势延续下去。

无论是对标国外的 ChatGPT、Perplexity 还是国内的 Kimi 探索版等，此次高级搜索功能的上线，提高了金融投资和科研学术领域的专业搜索能力，增加了竞争优势，无疑会进一步巩固天工 AI 在各类 AI 搜索产品中的领先地位，吸引更多用户。

从更大战略布局来看，持续加码 AI 搜索也是昆仑万维加速 AI 大模型向多元化场景渗透的重要一环。可以预见，天工 AI 高级搜索将与 AI 音乐、AI 视频、AI 社交和 AI 游戏等其他应用一道，构筑起全方位的大模型能力堆栈，增强昆仑万维的行业影响力，助力其在 AI 行业的发展。

自 2020 年起，昆仑万维便开始布局 AIGC 领域并着力研发大模型与算法。2023 年启动「All in AGI 与 AIGC」长期战略，提出全新使命「实现通用人工智能，让每个人更好地塑造和表达自我」。

短短四年时间，昆仑万维一直在「变」中求进，包括 AI 搜索在内多款 AI 应用的持续进化是该公司实现自身愿景的最大底气。

#Meta前AR眼镜负责人加盟

OpenAI也要做消费类硬件了？

OpenAI 不仅专注于软件，还要深入硬件研究。

Meta 增强现实眼镜项目前负责人 Caitlin Kalinowski 宣布，她将加入 OpenAI，领导机器人和消费类硬件业务。

刚刚，Kalinowski 在领英上写道：「非常高兴地告诉大家我将加入 OpenAI，领导机器人和消费类硬件业务！

OpenAI 和 ChatGPT 已经改变了世界，改善了人们获取和与信息交互的方式，并在全球范围内带来了有意义的利益。AI 是目前技术领域最令人兴奋的工程前沿，我非常高兴能成为这个团队的一员。

在我的新角色中，我将首先专注于 OpenAI 的机器人研究和合作伙伴关系，以帮助将人工智能带入物理世界并释放其对人类的益处。

感谢 OpenAI 团队、Sam、Kevin Weil 以及我在工程和其他领域的朋友和同事！」

在刚刚官宣新动向后，Kalinowski 一众前同事发来祝贺，言语中都透漏出 Kalinowski 的加入，对 OpenAI 来说真的很幸运。

OpenAI 员工们也开始列队欢迎，OpenAI CPO / 首席产品官 Kevin Weil 表示：和 Kalinowski 一起工作真是太激动了！

OpenAI 产品副总裁 Peter Welinder 表示：非常高兴 Kalinowski 的加入。

作为一名硬件高管，Kalinowski 于 2022 年 3 月开始领导 Meta 的 AR 眼镜团队。并负责监督 AR 眼镜 Orion 的创建，这是 Meta 最近在其年度 Connect 大会上展示的增强现实原型。

Kalinowski 还曾领导过 Meta VR 眼镜背后的硬件团队约九年。

在此之前，她在苹果公司负责设计 MacBook 的硬件。

有人猜测，Kalinowski 可能会与她的前老板、前苹果高管 Jony Ive 合作，开发一款新的人工智能硬件设备，该设备由 OpenAI 和 Ive 的初创公司 LoveFrom 共同开发。9 月，Ive 证实了他正在与 OpenAI 合作开发一款硬件产品，并将其描述为「一款利用人工智能创造计算体验的产品，其社交破坏性比 iPhone 要小。」

前不久，OpenAI 还在为一个机器人团队招聘研究工程师，该团队旨在帮助 OpenAI 的合作伙伴将其多模态 AI 整合到他们的硬件中。OpenAI 机器人团队的重启大约是在该公司四年前解散硬件研究部门、专注于软件研发之后。2018 年，OpenAI 曾制造了一只能够自主学习抓取物体的机械手。

Dactyl 系统

据不完全统计，已经有多家公司将 OpenAI 的模型整合到他们的硬件中。最明显的是苹果，该公司将于今年晚些时候为 iPhone 推出 ChatGPT 集成。另一家是机器人公司 Figure，其人形机器人 01 利用 OpenAI 的软件进行自然语音对话。

最近一年，OpenAI 人才流动比较频繁，选择离开的有大家比较熟悉的 Ilya、Mira Murati 等。近期选择加入的有微软人工智能副总裁 Sebastien Bubeck 等人。

新加入的 Kalinowski 工作重心是机器人和消费硬件业务，或许我们可以期待一下 OpenAI 在硬件方面带来 ChatGPT 时刻。

参考链接：

https://techcrunch.com/2024/11/04/metas-former-hardware-lead-for-orion-is-joining-openai/

#LLM超越人类时该如何对齐？

谷歌用新RLHF框架解决了这个问题

让 LLM 在自我进化时也能保持对齐。

我们这个世界是不断变化的开放世界。人工智能要在这个世界长久立足，就需要突破许多限制，包括可用数据和规模和质量以及有用新信息的增长率。

对基于 LLM 的 AI 来说，高质量的人类数据非常关键，但已有研究预计这些高质量数据将在未来几年耗尽。

如果 LLM 保持现在的发展势头，预计在 2028 年（中位数）左右，已有的数据储量将被全部利用完，来自论文《Will we run out of data? Limits of LLM scaling based on human-generated data》

此后，这类数据的质量也将停滞不前：随着 LLM 能力越来越强，它们将能解决越来越复杂和越来越多的难题，而这些难题所需的训练数据已经超出了人类的能力。

因此，我们就需要为 LLM 构建一种能使其实现自我提升的基本机制，让模型可以持续地自我生成和自我求解更困难的问题。

于是，问题就来了：语言模型能否自我创建可学习的新任务，从而实现自我改进以更好地泛化用于人类偏好对齐？

为了提升语言模型的对齐能力，人们已经提出了许多偏好优化算法，但它们都默认使用固定的提示词训练分布。这种固定的训练范式缺乏可扩展性，并不可避免地导致泛化问题和效率问题。

基于这些考虑，谷歌 DeepMind 和芝加哥大学一个研究团队开发了一种可扩展的开放式 RLHF 框架 eva，即 Evolving Alignment via Asymmetric Self-Play，也就是「通过非对称自博弈实现的演进式对齐」。

论文标题：Evolving Alignment via Asymmetric Self-Play

论文地址：https://arxiv.org/pdf/2411.00062

eva 能让自我提升式语言模型的训练分布自动演进，如图 1 所示。

eva 的核心方法

在介绍 eva 的核心方法之前，我们需要先了解一些前提设置，这里截图如下：

概述地讲，eva 可通过一个创建器（creator）将经典 RLHF 扩展成开放式 RLHF，该创建器使用易于实现的估计、采样、进化程序来调整提示词的分布，模仿不对称自博弈的最小最大遗憾（minimax-regret）策略。

原理：用于联合自我提升的开放式 RLHF

直观说明

经典 RLHF 是在一个静态提示词分布上执行优化，这意味着智能体仅与固定的参考点对齐，这使得它难以对应不断变化的现实世界中的新问题。

新提出的开放式 RLHF 框架 eva 则打破了这个静态设置，其目标是开发出一种能很好地泛化到未曾见过的新环境的智能体。为此，该团队必须设计一个新的目标，而不仅仅是在一个固定数据集上执行优化。

形式化描述

π_φ (x) 是可优化的提示词生成策略，其会与响应策略 π_θ (y | x) 一起被联合优化，如下所示：

其中，p_ref (x) 表示所有可能任务（通过提示词实例化）的理想化的可能很难处理的概率，其可作为智能体可能遇到的任务的全部多样性和复杂性的概念参考，同时用作对齐的指导目标。此外，联合优化可确保任务分配和智能体的响应策略同步更新，从而适应日益复杂的任务，进而促进泛化。

机制：通过创建器和求解器博弈实现非对称自博弈

直观说明

由于未指定的参考很难处理以及联合微分存在不稳定问题，因此 (7) 式很难直接优化。为此，该团队提出了一种交替式的优化方案，其做法是将该问题表述成一个非对称的创建器 - 求解器博弈。

直观地讲，创建器可以通过复杂度不断增加的提示词例程来指导求解器，从而实现高效和一般性的学习，以处理现实任务的多样性。
从数学上看，这类似于通过期望最大化进行的 RL 优化，其中提示词分布的 φ 在每个步骤中都是固定的。

形式化描述

该团队将这种交替优化表述成了一种非对称博弈，如下所示：

创建器（Creator：提示词博弈者 π_X，其作用是策略性地为求解器生成提示词。
求解器（Solver：响应博弈者 π_{Y|X}（或 π），其作用是学习生成更符合偏好的响应。

该团队采用了 minimax regret 策略，其中求解器的目标是最小化后悔值，而创建器则是为了最大化这个值，即当前策略和最优策略之间的奖励之差为：

在纳什均衡下，之前已有研究表明：

然而，如果无法获得真正的最优策略，就必须近似后悔值。利用随机策略和奖励信号，该团队设计了基于优势的代理函数：

总之，eva 允许创建一个不断演进的提示词分布，其难度会随智能体的演进而逐步提升。新引入的 minimax regret 可进一步增加这种不断发展的例程的稳健性，其做法是激励智能体在所有情况下都表现良好。他们使用了信息量代理来指导学习。

总之，eva 是将对齐视为一种非对称博弈，其机制是创建器不断挑战求解器，而求解器则不断学习提升。

实际的算法

下面说明如何实际实现算法 1 中的 eva。

1. 创建器步骤：估计，采样，然后演进

显然，创建器会找到最有用的提示词并生成它们的变体，并将这些变体用于偏好优化。创建器的实现分为 3 步。

第 1 步：info (・)—— 估计信息量。对于提示集 X) t 中的每个 x，生成响应、注释奖励并通过 (10) 式估计 x 的信息量指标。
第 2 步：sample (・)—— 对富含信息的子集进行加权采样。使用信息量指标作为权重，对富含信息的提示词子集 X^info_t 进行采样，以便稍后执行演进。
第 3 步：evolve (・)—— 为高优势提示词执行近端区域演进。具体来说，迭代 X^info_t 中的每个提示词，让它们各自都演化为多个变体，然后（可选）将新生成的提示词与对 X_t 的均匀采样的缓存混合以创建 X′_t。

2. 求解器步骤：求解然后优化

此步骤是经典的偏好优化，其中生成响应并执行梯度下降。以逐点奖励模型设置为例，对于每个提示，采样 n 个响应，每个响应都带有奖励注释；这里采用最大和最小奖励的响应来构建偏好对，然后进行优化。

总之，eva 可以使用新的创建器模块统一现有的迭代优化工作流程，该模块可以与求解器策略共享相同的网络，也可独立运行。

实验结果

这里我们仅关注实验的主要结果，实验设置请参看原论文。

总体而言，eva 在对齐方面取得了显著的进步，同时无需依赖任何人工数据，因此更具效率。

是基础设置，即一次迭代微调后的模型，eva 则会在此基础上添加一个创建器，以实现初始迭代的提示词集的自我演进，并使用一个偏好优化算法进行额外的开放式 RLHF 迭代，这会得到

。

eva 能实现自我提升

如表 1 红色标记所示，eva 在不同优化算法中的表现显著优于基础设置，尤其是在更难的 Arena-Hard 基准上，该基准由于其提示词的复杂性和更公平的评分系统而被认为更具挑战性。

具体来说，eva 使用 SimPO 作为求解器时增益为 8.4%，使用 DPO 作为求解器时增益为 8.5%，超越了其 27B 版本并与 Arena-Hard 排行榜上报告的 claude-3-opus-240229 相当，同时还使用了全自动的提示词生成进行对齐。

eva 可以超越人工编写的提示词

实验进一步表明，使用 eva 提示词训练的模型

的表现能够比肩甚至超越那些使用了来自 UltraFeedback 的额外新提示词训练的模型

，这可被视为是人类提示词。同时，前者还能做到成本更低，速度更快。

此外，在 MT-Bench 上，使用新的人类提示词进行训练通常会在第一轮中表现出性能下降，在第二轮中也只会有适度的提升。相比之下，eva 能显著提高第二轮的表现。

针对此现象，该团队给出了自己的假设：eva 可演化出全新的可学习的提示词，并且其中包含第二轮问题的特征，这表明 eva 涌现出了处理后续互动等新技能。

消融研究

为了验证 eva 各组件的有效性，该团队也执行了消融研究，下面我们简单给出其发现，详细实验过程请访问原论文：

信息量指标：新提出的基于后悔值的指标优于其它替代指标；
采样之后执行演化的流程：新方法优于贪婪选择方法；
使用奖励模型进行扩展：eva 的对齐增益会随奖励模型而扩展；
持续训练：新提出的方法可通过增量训练获得单调增益；eva 演化得到的数据和调度可用作隐式正则化器，从而实现更好的局部最小值。

#SAM2Long

无需训练即可大幅提升SAM 2！开源的SAM2Long来了，港中文、上海AI Lab出品

针对这些挑战，该研究团队近日推出了全新的 SAM2Long。在 Segment Anything Model 2（SAM 2）的基础上，提出了创新的记忆结构设计，打造了专为复杂长视频的分割模型。

论文链接：https://mark12ding.github.io/project/SAM2Long/asset/images/paper.pdf
项目链接：https://mark12ding.github.io/project/SAM2Long/
代码链接：https://github.com/Mark12Ding/SAM2Long

，时长01:07

SAM2Long 采用了一种全新的多路径记忆树结构，使得模型可以在每一帧处理时探索多种可能的分割路径，并根据综合得分选择最佳路径进行后续帧的分割。这种设计避免了单一错误掩码对整个视频的影响，使得 SAM2Long 在处理遮挡、目标重现等长视频常见问题时表现得更加稳健。

定性和定量对比 SAM 2 和 SAM2Long 处理遮挡和长时间的性能。

SAM2Long 方法简述

1. SAM 2 的基础概述

SAM 2 是一种用于图像和视频对象分割的基础模型。与 SAM 不同，SAM 2 引入了一个内存模块，该模块利用先前帧的信息和提示帧特征来帮助当前帧的分割。在视频对象分割任务中，SAM 2 会在每个时间步 t 上维护一个内存库，存储最近 N 帧的特征。每个内存条目包含空间嵌入和对象指针，通过这些信息，SAM 2 能够生成当前帧的分割掩码，并预测掩码的 IoU 分数和遮挡分数。SAM 2 采用贪婪选择策略，选择最高 IoU 的掩码作为最终预测，并存储其对应的内存指针。

2. 多路径记忆树结构与不确定性处理

为了提高 SAM 2 在长视频中的鲁棒性，SAM2Long 引入了多路径记忆树结构。该结构允许模型在每个时间步上保留多个分割路径假设，每条路径都有独立的内存库和累积得分。每个时间步上，SAM2 的掩码解码器在每条路径会生成三个掩码候选。

为了防止路径数量过多引起计算和内存开销过高，SAM2Long 实施了剪枝策略。我们计算每个掩码累积 IoU 得分，只保留得分最高的 P 条路径。

此外，SAM2Long 在处理不确定场景时，利用遮挡分数进行不确定性处理。当所有路径的遮挡分数都较低时，意味着模型对输出的结果不确定。在这种情况下，SAM2Long 会强制选择不同 IoU 值的掩码路径，以避免错误路径的过早收敛。

相比 SAM 2，SAM2Long 增加了额外的计算需求，主要体现在掩码解码器和内存模块的多次处理上。然而，这些模块相较于图像编码器来说非常轻量。例如，SAM 2-Large 的图像编码器包含 212M 个参数，而模型其余的参数只有 12M，大约仅占模型的 5%。

因为 SAM2Long 也只需要处理一次图像编码器，所以内存树结构的引入几乎不会增加显著的计算成本，但却显著提高了模型在长时间视频场景中的鲁棒性和对错误的恢复能力。

3. 物体感知的记忆库构建

在每条路径中，SAM2Long 使用物体感知的内存选择策略，通过筛选出具有较高 IoU 分数和没有遮挡的帧，只将高质量的有物体的帧加入记忆内存库。

此外，SAM2Long 对每个内存帧的遮挡分数进行排序，遮挡分数越高，表示该帧中的目标对象越清晰、遮挡越少。为了充分利用这些高质量的帧，SAM2Long 通过以下几个步骤来调整每个内存帧在注意力计算中的权重。

首先，定义一组线性分布的标准权重，用于对内存中的帧进行加权。这些权重在一个预定义的范围 [w_low, w_high] 之间线性分布，较高的权重将分配给那些重要的内存帧。

然后，对每个内存帧的遮挡分数进行排序，得到一个按遮挡分数从低到高排列的帧索引序列。根据遮挡分数的排序结果，将标准权重分配给对应的内存帧，遮挡分数越高的帧用越大的权重线性缩放该帧的特征表示。

最后，使用经过加权调整的内存帧作为输入，进行跨帧的注意力计算。这样，遮挡分数高的帧（表示对象存在且分割质量高）会对当前帧的分割结果产生更大的影响。

实验结果

SAM2Long 在所有模型规模优于 SAM 2

我们对 SAM 2 和 SAM2Long 在不同模型规模和多个数据集上的表现进行了详细对比。在 SA-V 验证集和测试集以及 LVOS v2 验证集上的实验结果显示，SAM2Long 无论在何种模型规模下，均显著超越了 SAM 2。表中共包含了 8 种模型变体，涵盖了 SAM 2 和最新的 SAM 2.1 在四种模型规模下的表现。24 次实验的平均结果表明，SAM2Long 在 J&F 指标上平均提高了 3.0 分。

其中，SAM2Long-Large 在 SA-V 验证集和测试集上，分别比 SAM 2 提升了 4.5 和 5.3 分。在 LVOS 验证集上，各个模型规模下的 SAM2Long 也都展示了显著的性能提升。此结果证明了我们的无训练内存树策略在长时间视频分割中的高效性，大大提升了模型在长视频对象分割中的鲁棒性。

SAM2Long 超越现有方法，实现 SOTA

我们还将 SAM2Long 与当前最先进的视频对象分割方法进行了对比。尽管 SAM 2.1 已经在众多数据集上显著超越了现有方法，但 SAM2.1Long 将这一成绩推向了更高的水平。特别是在 SA-V 验证集上，SAM2.1Long 的 J&F 得分为 81.1，较 SAM 2.1 提升了 2.5 分。在 LVOS 数据集中，SAM2.1Long 在 v1 和 v2 子集上分别达到了 83.4 和 85.9 的 J&F 得分，分别比 SAM 2.1 提升了 3.2 和 1.8 分。

SAM2Long 在应对不同挑战的视频时展现了强大的通用性

除了在 SA-V 和 LVOS 数据集上的出色表现外，我们还在其他视频对象分割基准测试上对 SAM2Long 进行了评估。在复杂的现实场景 MOSE 数据集上，SAM2.1Long 的 J&F 得分为 75.2，超越了 SAM 2.1 的 74.5 分。特别是在 MOSE 基准上，SAM 2.1-Large 并未相较 SAM 2-Large 带来性能提升，因此 SAM2.1Long 在该基准上取得的显著改进显得尤为突出。