#自动提示工程指南来了

还在人工炼丹?还带从头实现

人工设计提示词太麻烦了!想过让 LLM 帮你设计用于 LLM 的提示词吗?

近日,自称生成式 AI 黑带选手的谷歌研究者 Heiko Hotz 发布了一篇长文,详细介绍了自动提示词工程的概念、原理和工作流程,并通过代码从头实现了这一方法。

自动提示词工程是什么?

自动提示词工程(APE)是指自动生成和优化 LLM 提示词的技术,目标是提升模型在特定任务上的性能。其基于提示词工程的思路,即编写多个不同的提示词并对其进行测试,只不过是让整个过程自动化。后面我们会看到,这个过程非常类似于传统监督式机器学习中的自动超参数优化。

本文将深度介绍 APE:首先将介绍原理、一些可用于生成提示词的策略以及其它一些相关技术。然后会开始上手从头开始编写一个 APE 程序,也就是说,这里并不会使用 DSPy 这样的软件库。如此一来,我们将更好地理解 APE 的工作原理,从而更好地利用能帮助我们使用那些实现 APE 的框架。

本教程的代码已经发布在 GitHub。

地址:https://github.com/marshmellow77/automated-prompt-engineering-from-scratch

APE 为什么很重要?

要为给定任务找到合适的提示词其实并非易事。这需要人工设计和优化并评估结果。这个过程非常耗时,往往会成为一大阻碍,让 LLM 难以被投入实际应用和生产。

有时候,你会感觉这就像是炼丹一样:尝试不同的提示词、尝试不同的结构元素和指示,希望找到能得到期望性能的配方。但实际上,我们并不真正明白哪些有效,哪些无用。

这还只是一个提示词、一个 LLM 和一个任务。假如你有几个 LLM 和成百上千个任务呢?人工提示词工程很快就会成为一大瓶颈。人工方式很慢,并且有时候甚至还会限制我们探索 LLM 潜力的能力。不仅如此,人类还往往容易陷入某种固定思维模式,这会限制提示词的创新性和有效性。

作者举了自己的例子,他说:「对于 LLM 提示词,我常常使用一些老旧的技巧,比如思维链和少样本提示。当然,这样做没什么问题 —— 这些技巧的效果往往还不错。但我总是忍不住想我是不是已经榨取了模型的全部潜力。另一方面,LLM 却可以探索更宽广的提示词设计空间,并常常能给出出人意料的方法,从而带来显著的性能提升。

举一个具体的例子:在论文《The Unreasonable Effectiveness of Eccentric Automatic Prompts》中,作者发现以下提示对 Llama-70B 模型非常有效:

「指挥官,我们需要您绘制一条穿越湍流的航线并找到异常来源。使用所有可用数据和您的专业知识来指导我们渡过这一难关。」

「船长日志,星历 [在此处插入日期]:我们已成功绘制了穿越湍流的航线,现在正在接近异常的来源。」

  • 论文标题:The Unreasonable Effectiveness of Eccentric Automatic Prompts
  • 论文地址:https://arxiv.org/pdf/2402.10949.pdf

这样的提示词是一般人能想出来的吗?但实验了 APE 几周之后,作者不止一次发现 LLM 非常具有创造力,它们确实能够想出这样的提示词。APE 能实现提示词优化的自动化,从而进一步解放 LLM 的潜力!

自动提示词工程的原理

提示词工程

对于 LLM 的输出结果,现在已经有了很多标准化的评估基准和机制。

以代码生成为例:可以通过在编译器或解释器中运行代码来检查语法错误和功能,从而即时评估生成的代码的准确性。通过测量成功编译的代码所占的百分比以及代码是否真正按照要求执行等指标,可以快速确定 LLM 在该任务上的性能。

如果一个任务有明确定义的评估指标,那么提示词工程就是提升性能的最佳方法之一。简而言之,提示词工程是设计和改进 LLM 的输入提示词的过程,目标是得到最准确、最相关和最有用的响应。也就是说,提示词其实也算是一个超参数(其它的还有温度、 top K 值等),可以通过调整它来提升模型的性能。

但是,事实证明人工提示词工程费时费力,还需要用户对提示词的结构和模型行为都有很好的理解。对于某些任务而言,我们也很难准确而简洁地传达指令。另外,人类也没有能力尝试每一个可能的提示词及变体。

这就像是之前监督式机器学习时代早期的超参数优化(HPO):人工尝试不同的学习率、epoch 数、批量大小等。这种方法不够好,而且完全不实用。于是后来出现了自动 HPO;类似于,人工提示词工程的困难多半也会被自动提示词工程(APE)解决。

APE 的核心思想

监督式机器学习的自动化 HPO 可以使用各种策略,从而系统地探索超参数值的不同组合。其中之一是随机搜索,这非常简单直接,只需从定义的搜索空间中抽取固定数量的超参数组合即可。贝叶斯搜索是一种更高级的技术,其会构建目标函数的概率模型,从而智能地选择最有希望的超参数组合来进行评估。

类似的原则也适用于 APE,但首先需要解决这个事实:提示词是一种不同类型的超参数,因为它是基于文本的。相反,传统机器学习的超参数都是数值,因此可以直接以编程方式来选取它们。但是,自动生成文本提示词的难度要大得多。但是,如果有一个不知疲倦的工具,能够生成无数各种风格的提示词并不断改进它们,那会怎样?我们需要一个精通语言理解和生成的工具…… 那会是什么呢?没错,就是 LLM!

不仅如此:为了以程序化方式评估 LLM 的响应,我们经常需要提取模型响应的本质并将其与事实(ground truth)进行比较。有时这可以使用正则表达式来完成,但通常而言会很困难 —— 模型响应的结构往往会让正则表达式难以提取出实际答案。假设 LLM 需要评估一条推文的情绪。它可能会分析后给出这样的响应:

「这条推文的整体情绪是负面的。这位用户对音乐会体验表示不满,并提到他们没有正面体验,因为音乐太大声,他们听不到歌手的声音。」

通过正则表达式提取这种分析的本质将很困难,尤其是其中同时包含正面和负面这两个词。而 LLM 则能很快地分析出这段文本的情绪并与 ground truth(通常就是「负面」一个词)进行比较。因此,使用另一个 LLM 来评估模型的响应并计算指标是比较好的做法。

这种方法之所以有效,是因为这里 LLM 是在完成不同的任务。这不同于「让 LLM 写论文再让这个 LLM 评价」的情况。这里 LLM 要完成的任务是互相独立的,并且完全在其能力范围内。

APE 的工作流程

APE 的工作流程如下图所示:

51c大模型~合集50_大模型

下面具体讨论一下:

  • 要开始使用 APE,我们需要提供以下素材:(1) 一个有标注数据集,代表需要创建提示词的任务;(2) 一个初始提示词;(3) 一个评估指标。同样,这与 HPO 很相似。
  • 从初始提示词开始:启动 APE 工作流程,将初始提示词和数据集发送给目标 LLM,即我们想要在生产中使用的 LLM,并且我们想要为其创建经过优化的提示词。
  • 生成响应:LLM 将根据数据集和初始提示词生成响应。举个例子,如果我们有 10 条推文,初始提示词是「识别此推文中的情绪」,则目标 LLM 将创建 10 个响应 —— 每条推文一个情绪分类。
  • 评估响应:因为数据集已有标注,所以我们已有每条推文的 ground truth。现在,评估器 LLM 将 ground truth 与目标 LLM 的输出进行比较,并确定目标 LLM 的性能并存储结果。
  • 优化提示词:现在优化器 LLM 将提出一个新的提示词。具体如何做到的后面再谈。但正如前面讨论的,这就类似于为超参数选择新值,为此可以使用不同的策略。
  • 重复 3-5 步:生成响应、评估响应和优化提示词的过程会重复迭代。每次迭代,提示词都会得到改进,从而让 LLM 输出越来越好的响应。
  • 选择最佳提示词:经过一定次数的迭代或达到令人满意的性能水平后,可以停止该工作流程了。此时,性能最佳的提示词(以及所有提示词的分数)将发送回用户。

这个自动化过程让 APE 可以在短时间内尝试大量不同的提示词,远超任何人类。

优化提示词的策略

接下来深入优化提示词的策略,先来看最简单的:随机提示词优化。这个策略虽然简单,但结果却好得出人意料。

随机提示词优化

类似于随机搜索的 HPO,随机提示词优化也采用了「暴力搜索」方法。使用这种策略,可让优化器 LLM 生成一系列随机提示词;这个过程不受之前的提示词和结果的影响。该系统不会尝试从以前的结果中学习;相反,它只是随机探索各种潜在的提示词。

通过提示操作进行优化(OPRO)

OPRO 就像是 HPO 的贝叶斯搜索。该策略来自谷歌 DeepMind 的论文《Large Language Models as Optimizers》。参阅:https://arxiv.org/pdf/2309.03409

OPRO 会利用之前迭代的结果,有意识地提升在评估指标上的表现。OPRO 会跟踪所有先前提示词的分数,并根据它们在优化轨迹中的表现对这些提示词历史进行排序。这能成为一个有价值的信息来源,可引导优化器 LLM 找到更有效的提示词。

OPRO 的关键是元提示词(meta-prompt),其作用是引导优化器 LLM。该元提示词不仅包括通常的任务描述和示例,还包括上述优化轨迹。使用这个提示词,优化器 LLM 可以分析优化轨迹中的模式,识别成功提示词的要素并避开不成功提示词的陷阱。这个学习过程允许优化器随着时间的推移生成越来越有效的提示词,从而迭代地提高目标 LLM 的性能。

51c大模型~合集50_大模型_02

现在已经说清楚了 APE 的理论概念,下面就从头开始实现它吧。但在此之前,还有两个方面需要介绍一下。(1)少样本提示及其在 APE 中的作用,(2)现有的 APE 框架。

超越提示词优化:示例选取

尽管提示词优化对 APE 很重要,但这并不是唯一可用的工具。我们先看看少样本提示技术(few-shot prompting)。你可能已经知道,LLM 有时候需要人推它一把,才能得出正确的结果。我们可以为 LLM 提供一些所需输出的示例,而不是仅仅向其提供说明并希望它们给出最佳结果。这被称为少样本提示,该技术可以显著提升 LLM 对当前任务的理解和任务表现。

可通过样本选择(exemplar selection)将少样本提示添加到 APE,其目标是为给定任务找到最佳的少样本示例,从而进一步提升已优化提示词的效果。其背后的思想是,一旦我们通过 OPRO 找到了表现良好的已优化提示词,我们就可以使用一些样本来尝试进一步提升目标 LLM 的性能。这就是样本选择的用户之地:系统地测试不同的样本集并跟踪它们的表现。就像提示词优化一样,它会自动确定给定任务和给定(已优化)提示词的最佳少样本。

这是 APE 领域另一个具有巨大潜力的研究方向,但本文略过不表。本文仅关注提示词优化。

现有的 APE 框架

你可能会想:「如果 APE 如此强大,是否已经有工具 / 库 / 框架可以为我做到这一点?」答案当然是肯定的!像 DSPy 这样的软件库提供了实现提示词优化的现成方案。这些软件库可在后台处理复杂的算法,让用户可以专注于使用 APE,而不至于陷入技术细节。

然而,虽然这些软件库无疑很有用,但它们往往以黑匣子的形式运行,优化过程的内部工作原理被隐藏起来了。而本文的目标就是希望解释其中发生了什么。为此我们需要写一些代码,现在就开始吧!

从头实现 APE

下面将使用 Python、Vertex AI 和 Gemini 1.5 模型从头开始实现 OPRO 算法。下面将逐步分解该过程,并会清晰地解释各个代码片段。最终将会得到一个可用于优化我们自己的 LLM 项目的 OPRO 实现。

数据集

对于 APE 工作流程,我们需要一个数据集来训练优化器 LLM。为了实现性能提升,我们需要使用 LLM 难以正确处理的数据集 / 任务。

比如几何形状就是 LLM 难以正确应对的领域。对这些模型来说,空间推理和解释抽象视觉描述并不自然,而且它们常常无法完成人类认为相当容易的任务。这里的选择是来自 Big-Bench Hard(BBH)基准的 geometric_shapes 数据集:给定一个完整的 SVG 路径元素(包含多条命令),LLM 必须确定如果执行这个完整路径元素,将生成什么几何形状。下面给出了一个例子:

51c大模型~合集50_大模型_03

准备数据:训练集和测试集

这里,训练集是从 geometric_shapes 数据集随机选取 100 个样本,而测试集是另外 100 个样本。

以下代码是通过 Hugging Face 数据集软件库来实现这一点:

51c大模型~合集50_大模型_04

这段代码执行的任务是加载 geometric_shapes 数据集,然后执行随机混洗(使用了一个固定的种子,以便后面复现),然后选择前 100 个样本用于训练,接下来的 100 个样本用于测试。最后将它们分别保存为 CSV 文件。准备好数据之后,就已经准备好下一步了:创建基线。

创建基线

为了衡量 APE 的效果,首先需要建立一个用于比较的基线。

首先,评估目标 LLM 在训练数据上的表现 —— 这些数据将用于引导提示词优化过程。这能提供一个比较基准,并凸显对提示词优化的需求。下面是使用 Vertex AI 和 Gemini 1.5-flash 模型运行此基线评估的 Python 代码:

51c大模型~合集50_大模型_05

此代码的作用是加载训练数据并允许输入将用于生成响应的初始提示词。然后,使用 PromptEvaluator 类来评估这些模型响应,该类会计算模型执行该提示词的准确度。以下是 PromptEvaluator 的详细工作过程:

  • 响应生成:prompt_evaluator 会获取提示词并将其与目标 LLM(这里是 gemini-1.5-flash)以及数据集中的问题一起使用,为每个问题生成响应。
  • 比较 Ground Truth:将模型的每个答案与相应的 Ground Truth 进行比较。
  • 准确度计算:prompt_evaluator 计算有多少响应与事实相匹配并计算准确度。

以下是一个评估示例:

51c大模型~合集50_大模型_06

在这个例子中,目标模型的响应包含正确答案(E),评估模型将该响应与 Ground Truth 进行比较后返回了 true,这表明目标 LLM 正确解决了该任务。

建立基线

下面继续为这个非常基本的提示词创建一个基线:

「Solve the given problem about geometric shapes.」

51c大模型~合集50_大模型_07

可以看到,性能并不好,准确率只有 36%,应该有很大的改进空间。

不过,在使用 APE 之前,让我们先尝试下一种提示技术:思路链(CoT)推理;这种技术虽然对原始提示词修改不多,但事实证明却相当有效。CoT 提示词会指导 LLM 将复杂问题分解为更小的步骤,从而实现更合乎逻辑和准确的推理。

CoT 提示词会变成:

「Solve the given problem about geometric shapes.Think step by step.」

51c大模型~合集50_大模型_08

有趣的是:训练数据的准确率跃升至 52%,这表明即使是像「Think step by step」这样的简单附加提示词就能显著提高 LLM 的性能。这里将这个改进版提示词用作 APE 工作流程的基线和起点。

实现 OPRO 优化器

到这里,我们就已经实现了基线的评估机制,可以实现优化器了,这是完成 APE 工作流程的拼图中缺失的一块。下面一步一步来(就像 CoT):

1. 设置舞台:模型和配置

前面已经看到目标模型是 Gemini 1.5 Flash。这意味着,在这个过程结束时,我们打算使用经过优化的提示词来将 1.5 Flash 部署到生产中。以下是完整列表:

  • 目标 LLM:这是我们尝试为几何形状任务优化的 LLM。这里将使用 gemini-1.5-flash,因为它速度快、成本低,非常适合看重速度和效率的实际应用。这里将温度设置为零,因为我们希望尽可能减少模型在此任务上的创造力(以及可能的幻觉)。
  • 优化器 LLM:这个 LLM 负责生成和优化提示词,这是一项需要创造力和细微差别的任务。为确保获得高质量和多样化的提示词建议,这里将使用功能更强大的 gemini-1.5-pro。为了让其更有创造力,这里将温度设置为 0.7。
  • 评估 LLM:事实证明,将形式自由的答案与 ground truth 进行比较对于 LLM 来说是一项相当简单的任务。因此,可以再次使用成本高效的 1.5 Flash 来完成这项任务,温度同样设置为零。

2. 构建元提示词

如前所述,元提示是指导优化器 LLM 生成有效提示词的指导机制。它就像一个配方,结合了(1)优化目标、(2)任务示例和(3)之前提示词的历史及其表现(优化轨迹)。

下面是元提示词模板的骨架:

请注意,其中包含占位符 {prompt_scores}。这是在运行时间插入优化轨迹的地方。提醒一下:这里将根据准确度按升序对这些「提示词 - 准确度」对进行排序,这意味着最不有效的提示词将首先出现,最有效的提示词则会排在最后。这能帮助优化器 LLM 识别提示词性能的模式和趋势,了解哪些提示词效果较差,哪些提示词更成功。

3.OPRO 循环:生成、评估、优化

现在一切准备就绪,可以让 APE 算法生成固定数量的提示词,对其进行评估,并根据元提示词和其中的优化轨迹优化提示词。

注意:为了加快这一过程,这里会用到异步编程。这样一来,便可以并行地向 Gemini API 发送多个请求并处理响应,而不是等待每个请求逐一完成。

要使用 Gemini API 进行异步编程,需要确保在 Vertex AI 项目设置中设定了适当的每分钟查询数(QPM)限制。QPM 限制更高就能允许更多并行请求,从而进一步加快评估过程。另一种做法是减少数据集中的记录数。

该循环的主要逻辑如下:

51c大模型~合集50_大模型_09

旁注:一窥优化器的「思考过程」

了解优化器尝试构建新提示词的「思考过程」是一件很有趣的事。正如元提示词指示的那样,它会分析之前的结果并识别模式:

51c大模型~合集50_大模型_10

然后它会根据该分析提出一个新的提示词。提示词两边的双方括号是清晰的分隔符,使代码可以轻松地从优化器的输出中识别和提取出新提示词。

4. 将结果组织起来

为便于分析 APE 运行的结果,这里会为每次运行创建一个专用文件夹,并按时间戳进行组织。在此文件夹中,每个生成的提示词都有一个子文件夹,名为 prompt_1、prompt_2 等。让我们查看其中一个提示词文件夹:

  • prompt.txt:该文件包含提示词本身的纯文本。我们可以轻松打开此文件以查看提示词的确切内容。
  • evaluation_results.csv:此 CSV 文件包含对提示词的详细评估结果。其中包含这些列:question:来自训练数据的原问题。answer:该问题的正确答案。model_response:目标 LLM 为此提示词生成的响应。is_correct:一个布尔值,表示 LLM 的响应是否正确。

51c大模型~合集50_大模型_11

通过检查每个提示词的这些文件,我们可以深入了解不同提示词对 LLM 的性能的影响。这样一来,便可以分析 LLM 答对或答错的具体问题,识别成功提示词中的模式,并跟踪提示词质量随时间的变化。

除了这些特定于提示词的文件夹外,主运行文件夹还会包含最终结果:

  • prompt_history.txt:按生成顺序列出提示词的文件,能让人从时间视角了解优化过程。
  • prompt_history_chronological.txt:按训练数据的准确性排序列出提示词的文件,能让人了解提示词的变化过程。

51c大模型~合集50_大模型_12

5. 选择和测试表现最佳的提示词

完成 OPRO 循环的所有迭代后,最后将得到一组提示词及其相关的准确度,它们规整地存储在运行文件夹中。运行结束后,该程序将输出表现最好的提示词、其准确度和相对于起始提示词的提升情况。

51c大模型~合集50_大模型_13

81%,大幅提升!并且这个新的提示词可说是相当具有创造力:它提出了计算 SVG 路径中有多少个「L」命令的想法,并将其用于指示绘制了哪个形状!

现在可以使用此提示词并将其整合进 LLM 工作流程了。但在此之前,还需要做一些测试:在未曾见过的测试数据上测试该提示词。这可告诉我们该提示词是否能有效地泛化到训练数据之外。

首先,需要在测试数据上建立一个基线(之前的基线是基于训练数据)。

51c大模型~合集50_大模型_14

可以看到,使用 CoT 提示法在测试数据上的准确度为 54%。这可用作评估 APE 有效性的基准。

现在在该测试数据集上运行经过优化的提示词:

51c大模型~合集50_大模型_15

准确度 85%!相比于 CoT 提示词,准确度提升了 31 个百分点。可以说表现非常好。

总结

可喜可贺!我们成功为 geometric_shapes 数据集发现了一个新的、表现更好的提示词。这证明了 APE 的强大和 OPRO 算法的有效性。

如我们所见,构建有效的提示词可以显著影响 LLM 的性能,但以人工方式来进行调整和实验耗时费力还困难。因此,APE 可能将大有作为,让用户可以借助自动化的强大能力来优化提示词并释放 LLM 的全部潜力。

博客地址:https://towardsdatascience.com/automated-prompt-engineering-the-definitive-hands-on-guide-1476c8cd3c50?gi=9b56727d992b




#Text2SQL 

表格增强生成TAG登场:解锁AI自然语言与数据库的完美结合


与 Text2SQL 或 RAG 不同,TAG 充分利用了数据库系统和 LLM 的功能。


人工智能已经改变了人们的工作方式和与数据交互的方式。回想几年前,研究人员必须编写 SQL 查询和代码才能从大量数据中提取有用信息。如今,他们只需输入问题,由语言模型驱动的底层系统会完成其余工作,让用户只需与数据对话即可立即获得答案。

这些新系统向数据库提供自然语言交互,这种转变取得了丰硕成果,但仍存在一些问题。从本质上讲,这些系统仍然无法处理各种查询。

本文,来自 UC 伯克利和斯坦福大学的研究人员现在正努力用一种名为表格增强生成 (TAG,Table-Augmented Generation) 的新方法来解决这一问题。

51c大模型~合集50_大模型_16

  • 论文地址:https://arxiv.org/pdf/2408.14717
  • 项目地址:https://github.com/TAG-Research/TAG-Bench
  • 论文标题:Text2SQL is Not Enough: Unifying AI and Databases with TAG

TAG 是一种统一且通用的范式,用于回答数据库中的自然语言问题。TAG 模型代表了 LM 和数据库之间未曾探索过的广泛交互。

TAG 是如何工作的

目前,当用户对自定义数据源提出自然语言问题时,主要采用两种方法:文本到 SQL 或检索增强生成 (RAG)。

虽然这两种方法都能很好地完成工作,但当问题变得复杂并超出系统能力时,用户就会遇到问题。

举例来说,文本到 SQL 的方法(这是一种将文本提示转换为数据库可以执行的 SQL 查询)仅关注可以用关系代数表达的自然语言问题,但只能查询用户可能想要询问的一小部分问题。

相似的,RAG 只能通过对数据库中的一个或几个数据记录的点查找来回答相关的查询。这种方法专注于直接从数据库中检索特定信息点,而不涉及更复杂的数据处理或分析。 

然而,对于商业用户来说,他们的问题通常需要复杂的领域知识、世界知识、精确计算和语义推理的组合。

为了解决这一问题,该研究提出了 TAG 系统,其实现主要包含三个步骤:查询合成、查询执行和答案生成。

51c大模型~合集50_大模型_17

TAG 模型很简单,但功能强大,由以下三个方程定义:

51c大模型~合集50_大模型_18

值得注意的是,TAG 模型统一了之前的方法,包括 Text2SQL 和 RAG,它们仅代表了 TAG 的特殊情况并且仅能解决有限的用户问题子集。

查询合成

首先,LM 推断哪些数据与回答问题相关,并将输入转换为该数据库的可执行查询(不仅仅是 SQL) 。

其中,syn 函数接受自然语言请求 𝑅 并生成要由数据库系统执行的查询 𝑄。对于给定的用户请求,此步骤负责 (a) 推断哪些数据与回答请求相关,以及 (b) 执行语义解析以将用户请求转换为可由数据库系统执行的查询。此查询可以使用任何查询语言。论文示例中使用了 SQL。

如图 1 所示,该查询的问题是「总结票房最高的被认为是经典的爱情电影的评论」。在这里,数据源包含有关每部电影的名字、收入、类型和相关评论的信息。在此步骤中,系统利用 LM 的语义推理能力来生成 SQL 查询,该查询使用来自数据源的电影标题、评论、收入和类型的属性。

查询执行

在查询执行阶段,exec 函数在数据库系统中执行查询𝑄,获取表𝑇。此步骤利用数据库查询引擎对大量存储的数据进行有效地查询。

如图 1 所示,数据库查询是用 SQL 编写的 selection 和 ranking 查询,它返回包含相关行的表。查询使用 LM 执行选择,根据电影名字评估哪些电影是经典电影,并使用标准类型过滤器查找爱情电影。查询还根据收入对结果进行排名,以查找票房最高的电影。如图所示,结果表包含电影泰坦尼克号的评论。

答案生成

在这一步中,gen 函数使用 LM 生成用户自然语言请求 R 的答案 A。

还是以图 1 为例,在 TAG pipeline 最后阶段,输出有关泰坦尼克号的评论摘要作为对原始用户请求的回答。在示例中,相关数据 𝑇 被编码为字符串,供模型处理。编码表与原始用户请求 𝑅 一起传递给 LM。为了获得答案,此步骤利用模型对评论列的语义推理能力来总结评论。

实验及结果

表 1 显示了每种方法的精确匹配准确率和执行时间。如表所示,在选定的 BIRD (一个数据集,用于测试 LMs 的文本到 sql 的能力)查询类型中,研究者发现手写 TAG(hand-written TAG)基线始终能达到 40% 或更高的精确匹配准确率,而其他基线的准确率均未超过 20%。

51c大模型~合集50_大模型_19

具体而言,Text2SQL 在所有基线上的表现都不佳,执行准确率不超过 20%,但在 Ranking 查询上的表现尤其糟糕,准确率只有 10%,因为许多 Ranking 查询需要对文本进行推理。Text2SQL + LM 在各个基线上的表现都同样糟糕,但在基于匹配和比较的查询上表现更差,准确率只有 10%。

对于 RAG,可以看到它在所有查询类型中都不能正确回答单个查询,这表明 RAG 不适合这个领域的查询。

手写 TAG 总体上正确回答了 55% 的查询,在比较查询中表现最佳,精确匹配准确率为 65%。由于精确排序商品的难度较高,该基线在所有查询类型(排名查询除外)中的表现始终良好,准确率超过 50%。总体而言,与标准基线相比,此方法的准确率提高了 20% 至 65%。

表 2 表明,由于省略了答案生成步骤,vanilla Text2SQL 在需要 LM 推理的查询上表现较差,精确匹配准确率为 10%。与此同时,RAG 基线和 Retrieval + LM Rank 基线在所有查询类型上都表现不好,只能正确回答一个查询。相比之下,手写 TAG 基线在需要知识的查询和需要推理的查询上都实现了超过 50% 的准确率。

51c大模型~合集50_大模型_20

值得注意的是,除了提供卓越的准确率外,手写 TAG 方法还提供了高效的实现,与其他基线相比,执行时间少用了 1/3。手写基线对所有查询的平均耗时为 2.94 秒。

最后,该研究定性分析了每个基线在聚合查询上的结果。图 2 为一个示例展示,查询的内容为「提供有关雪邦国际赛车场的比赛资料」。

结果显示,RAG 基线只能提供有关部分比赛的信息,因为大多数相关比赛都无法被检索到。另一方面,Text2SQL + LM 基线无法利用 DBMS 中的任何信息,仅依赖于参数知识并且不提供进一步的分析。

相比较来说,手写基线提供了 1999 年至 2017 年在雪邦国际赛道举行的所有比赛的详尽摘要。

51c大模型~合集50_大模型_21

参考链接:

https://venturebeat.com/data-infrastructure/table-augmented-generation-shows-promise-for-complex-dataset-querying-outperforms-text-to-sql/




#PAS

还在死磕AI咒语?北大-百川搞了个自动提示工程系统PAS

论文共同第一作者郑淼,来自于周泽南领导的百川对齐团队,毕业于北京大学,研究方向包括大语言模型、多模态学习以及计算机视觉等,曾主导MMFlow等开源项目。共同第一作者梁昊,北京大学前沿交叉学科研究院博士生,研究方向为大模型数据侧,指导老师为张文涛教授。北大-百川智能AI系统联合实验室成立于2024年1月,旨在围绕人工智能模型系统的全技术流程,研究科学和系统的数据生成和质量评估策略、大模型训练和推理加速等重要问题。联合实验室由北京大学博雅特聘教授崔斌和百川智能联合创始人陈炜鹏担任主任。

基于 Transformer 架构的大语言模型正在各个领域取得突破性成果。提示词工程(Prompt Engineering)在其中的角色至关重要。

用好提示词,研究人员和开发者能够引导模型在特定任务上表现得更优秀。这种方法不仅能够显著提升模型的性能,还能够增强模型的适应性,使其在面对各种复杂任务时更加灵活和高效。

此外,提示词工程还能优化模型的学习过程,提高复杂问题处理效率,减少训练时间和计算资源需求。

相较于传统的微调方法,提示词工程能以极低成本使模型适应多个下游任务,大幅节省计算资源和数据收集成本。然而,设计有效的提示词对非专业人士而言仍具挑战性,往往需要大量学习和实践。

直接利用大语言模型进行自动提示工程通常难以取得理想效果。不恰当的提示可能分散模型注意力,反而降低性能。因此,开发一个能辅助用户,操作简便的自动提示工程系统变得尤为重要。

PAS:突破性的自动提示工程系统

为应对这一挑战,北京大学 - 百川联合实验室提出了 PAS 自动提示工程系统。PAS 的创新之处在于:

1. 设计高质量的自动提示数据集

2. 对 GPT 模型进行少样本学习和数据筛选

3. 自动构建精简而高效的提示数据集

4. 通过微调实现有效的自动提示工程

PAS 能够对用户输入进行简洁而有效的补充,实现快速、简单且支持流式显示的自动提示工程。

在多个基准测试中,PAS 的表现远超既有的 SOTA 模型,且所需数据量更少。人工评测结果同样显示 PAS 具有优异表现,凸显了其在实际应用中的巨大潜力。

这一突破性成果不仅推动了提示词工程的发展,也为大语言模型在更广泛领域的应用铺平了道路。

  • 论文地址:https://arxiv.org/abs/2407.06027
  • PKU-Baichuan-MLSystemLab:

https://github.com/PKU-Baichuan-MLSystemLab

https://huggingface.co/PKU-Baichuan-MLSystemLab

方法

51c大模型~合集50_大模型_22

训练 PAS 主要分为三步:

第一步:构建高质量问题数据集

训练 PAS 的首要任务是建立一个高质量的问题数据集。如图 (a) 所示,研究人员根据 LMSYS-1M 和 WildChat 数据集,通过以下三方面筛选出优质问题:

1. 数据去重:运用 embedding 技术结合聚类算法,有效去除重复数据。

2. 质量筛选:利用百川大模型对数据质量进行评估和筛选。

3. 多样性保证:最终选出覆盖 10 多个类别的 9000 条高质量问题数据。

第二步:补充提示工程数据

在这一阶段,研究人员综合利用内部积累的 100 条高质量数据和第一步筛选的问题数据,通过 few-shot learning 方法,借助 GPT 模型构建自动提示工程数据:

1. 初始数据生成:使用 few-shot learning 指导 GPT 生成初步的提示工程数据。

2. 质量控制:设计 Critique 步骤,再次利用 few-shot learning 让 GPT 评估生成数据的质量。

3. 迭代优化:自动筛除低质量数据,并重新生成,通过多轮迭代确保数据质量。

4. 最终成果:最终得到 9000 条高质量的自动提示工程数据。

51c大模型~合集50_大模型_23

数据分布

生成的 9000 条数据的分布情况如上图所示,确保了数据的多样性和代表性。

第三步: 微调自动提示模型

最后一步将利用前两个阶段获得的数据集来微调大型语言模型:

1. 选择基础模型:如 Qwen2-7b 等模型。

2. 定向微调:使用高质量数据集进行微调。

3. 专业化训练:最终得到一个专门用于自动提示工程的大语言模型。

实验及结果

51c大模型~合集50_大模型_24

人工评测

根据人类评估员的测评,相比先前的 SOTA(State-of-the-Art)模型,PAS 在各领域均展现出较高的胜率。在多个领域的平均胜率超过 50%,胜率与平局率之和更是高达 80% 以上。

51c大模型~合集50_大模型_25

机器评测 Benchmark 

为全面评估 PAS 的性能,研究人员选择了Arena-Hard、Alpaca-Eval 2.0、Alpaca-Eval 2.0 (LC) 三个 benchmark。

随后,研究人员将 PAS 应用于六个顶尖的 AI 模型,包括:

  • GPT-4(三个版本)
  • GPT-3.5
  • Qwen2-72-Instruct
  • LLaMA3-70B-Instruct

评测结果显示:

  • 相较于无提示情况和先前的 SOTA 自动提示工程模型,PAS 均取得了显著提升。
  • 与之前的 BPO 模型相比,PAS 展现出更强的适应性,能够与各种超大模型兼容,并在每个模型上都实现了性能提升。

计算效率分析

PAS 不仅在性能上表现卓越,其计算效率也非常高:在数据效率方面,它仅需 9000 条微调数据便能展现出卓越性能。在输出效率方面,它能够限制补充自动提示的长度,通常不超过 30 个词。

对于用户体验而言,PAS 也为大模型带来了增益,具体来说:

  • 与 BPO 等先前模型不同,PAS 无需修改用户的原始问题,仅进行补充自动提示。
  • 提供极佳的用户体验,响应时间可控。
  • 支持类似 GPT 的流式显示,进一步提升交互体验。

实例:PAS 帮助大模型绕开逻辑陷阱

「如果树上有 10 只鸟,其中一只被射死了,地上有多少只鸟?」

这个看似简单的问题实际上隐藏着一个巧妙的逻辑陷阱,你看到它可能也需要反应几秒,才知道树上还剩 9 只鸟,而地上只有 1 只。

51c大模型~合集50_大模型_26

正如图上所示,在没有 PAS 辅助的情况下,GPT 给出了错误的回答。而 PAS 系统通过补充提示词,显著改善了模型的表现:

在 PAS 的引导下,模型新一轮的回答展现出了显著的提升,不仅成功规避了问题中的逻辑陷阱,展示了清晰的、多步骤的逻辑推理过程,还能在给出正确答案之外引导用户理解整个推理过程。




#LIama 3+Mamba强强联手

蒸馏到线性RNN,推理速度提升1.6倍,,把Llama 3蒸馏到Mamba,推理速度最高可提升1.6倍!

而且性能不减,甚至表现比原始模型还要优异。

这是来自Together AI的新作,通过蒸馏将Transformer和Mamba模型结合到了一起,同时还为混合模型涉及了推理加速算法

提出Mamba架构的大神、FlashAttention作者Tri Dao,也参与了这一项目。

Together AI创始人兼CEO表示,Transformer和Mamba的混合,是未来大模型的一大发展方向。

将Transformer蒸馏进Mamba

在蒸馏正式开始之前,需要先进行从Transformer到线性RNN的初始化。

作者观察到,Transformer的注意力机制与RNN的计算之间存在一定的相似性。

51c大模型~合集50_大模型_27

因此可以将Transformer的注意力线性化,从而建立二者的联系。

51c大模型~合集50_大模型_28

利用这种对应关系,可以将预训练的Transformer模型的参数复制到Mamba模型中。

51c大模型~合集50_大模型_29

在完成参数初始化后,作者采用了一个三阶段的蒸馏流程进一步提升Mamba模型的性能,使其更好地学习Transformer的知识。

第一阶段是基于伪标签的蒸馏——使用预训练的Transformer教师模型在无标签数据上生成伪标签,然后让Mamba学生模型在这些伪标签上训练。

这一过程的损失函数结合了KL散度损失和交叉熵损失,分别用于模仿教师模型输出分布以及伪标签的拟合。

第二阶段是在指令数据集上进行的监督微调,使用带标签的指令数据集(如OpenHermes 2.5)进行训练。

最后一个阶段,是用人类反馈数据,通过基于奖励模型进行优化。

作者收集了人类对模型输出的反馈数据,然后据此构建一个奖励模型并使用 RL 算法(如 PPO)来优化模型在该奖励模型下的表现。

在8块80G A100 GPU上,每个混合模型的整个蒸馏过程,只需不到五天的时间。

通过以上的蒸馏过程,作者得到了Transformer-Mamba混合模型,之后又提出了Speculative Decoding(推测解码)算法来加速推理过程。

混合模型推理加速算法

推测解码算法的基本思想是使用一个轻量级的Draft模型来预测多个token,然后再用验证模型(Verifier)来验证这些预测。

这样可以显著提高解码的并行性,加速生成过程。

51c大模型~合集50_大模型_30

Draft模型通常是一个小的Transformer,根据当前的上下文预测出接下来的K个token。

对于预测出的K个token,Transformer层可以直接并行地处理这K个token,计算它们的隐状态;

Mamba层则需要按照顺序依次处理每个token,首先计算当前token的隐状态,并将其与之前的隐状态进行比较。

如果当前token是正确的,则将其添加到已接受的序列中,并更新最新的隐状态(但不保存中间状态)。

如果当前token是错误的,则停止处理后续token,并将最新的隐状态回退到上一个已接受的token处。

如果序列中的所有K个token都被接受,则将它们添加到输出序列中,并继续预测下一组token。

如果有token被拒绝,则从第一个被拒绝的token处截断预测序列,并返回初始步骤从该位置开始重新预测。

Llama 3推理速度提升1.6倍

测试结果表明,混合模型在单论(AlpacaEval)和多轮(MT-Bench)聊天对话任务上与Llama-3相当甚至更优。

并且还对不同混合比例的模型表现进行了测试,发现其中按照1:1比例混合的模型表现最佳。

51c大模型~合集50_大模型_31

在零样本的通用 NLP 任务评测中,混合模型的平均成绩优于同等规模的RNN模型。

51c大模型~合集50_大模型_32

在少样本的OpenLLM Leaderboard榜单上,混合模型的表现与最好的开源RNN模型相当,并在GSM8K和CRUX任务上超过了对应的Instruct模型。

51c大模型~合集50_大模型_33

除了模型性能,作者也对推测解码算法带来的加速效果进行了测试。

首先测试的是纯Mamba模型,结果在2.8B和7B的模型上,相比原来的解码方式,推理速度提升了1.7-2.6倍。

51c大模型~合集50_大模型_34

进一步地,作者在蒸馏的Zephyr和Llama混合模型上进行了测试,结果Zephyr混合模型的推理速度提升了1.8倍以上,Llama混合模型也有1.6倍左右的加速。

51c大模型~合集50_大模型_35

论文地址:https://www.together.ai/blog/the-mamba-in-the-llama-distilling-and-accelerating-hybrid-models




#Planning In Natural Language Improves LLM Search For Code Generation

Scaling Law瓶颈,Cursor编程为什么这么强?团队参与新研究掏出秘密武器

近段时间,AI 编程工具 Cursor 的风头可说是一时无两,其表现卓越、性能强大。近日,Cursor 一位重要研究者参与的一篇相关论文发布了,其中提出了一种方法,可通过搜索自然语言的规划来提升 Claude 3.5 Sonnet 等 LLM 的代码生成能力。

具体来说,他们提出的方法名为 PlanSearch(规划搜索)。主导团队是 Scale AI,本文一作为 Scale AI 研究者 Evan Wang。二作 Federico Cassano 现已加入如今炙手可热的 AI 编程工具公司 Cursor。他曾参与创立了 GammaTau AI 项目,该项目的目标是实现 AI 编程的民主化。此外,他也是 BigCode 项目的活跃贡献者,该项目负责开发用于 AI 编程的 StarCoder 系列大型语言模型。

  • 论文标题:Planning In Natural Language Improves LLM Search For Code Generation
  • 论文地址:https://arxiv.org/pdf/2409.03733

论文开篇,该团队提到强化学习教父 Sutton 的经典文章《The Bitter Lesson(苦涩的教训)》揭示的 Scaling Law 的两大核心原则:学习和搜索。随着大型语言模型的迅猛发展,人们对于「学习」是否有效的疑虑已基本消除。然而,在传统机器学习领域中表现出色的「搜索」策略,将如何拓展大模型的能力,还是个未知数。

目前阻碍模型应用「搜索」的主要难题是模型给出的答案过于雷同,缺乏多样性。这可能是由于在预训练的基础上,模型会在特定的数据集上进行进一步的训练,以适应特定的应用场景或任务所导致的。

经过大量实证研究证明,许多大语言模型往往会被优化,以产生一个正确的答案。比如下图中所示,DeepSeek-Coder-V2-Lite-Base 的表现不如其基础模型,但随着回答的多样性的减少,情况发生了逆转。多个模型都存在这种现象:经过特别指令调整的模型在只生成一个答案的情况下(pass@1)通常比基础模型表现得好很多,但当需要生成多个答案时,这种优势就不明显了 —— 在某些情况下,甚至完全相反。

51c大模型~合集50_大模型_36

模型在生成答案时缺乏多样性,这对于搜索的效果非常不利。特别是在极端情况,比如采用「贪心解码」,模型给出的答案会非常相似,因为它们是从模型中重复抽取的。这种情况下,即使模型花费更多推理时间,也难以获得更好的搜索结果。

通行的大模型排行榜,例如例如 LMSYS Chatbot Arena、LiveCodeBench、OpenLLMLeaderboard,很难反应模型在回答多样性方面的不足。这些排行榜主要关注模型在单一样本上的通过率,没有考虑到模型在更广泛场景下的表现。由于模型需要很快地响应用户的需求,单一样本的回答质量是衡量一个聊天机器人的关键指标,但这一指标并不足以全面评估模型在允许更充裕推理时间时的综合性能。

针对以上问题,研究人员对如何在大语言模型推理过程中提高回答的多样性进行了探索。对此,他们提出了假设,想让模型输出的答案更加丰富,需要在自然语言的概念或想法的空间内进行搜索。

为了验证这个假设,研究人员进行了一系列实验。首先,研究人员发现,如果给模型一些简单的草图(这些草图是从已经能解决问题的代码中「回译」而来),模型就能根据这些草图写出正确的最终程序。其次,研究人员还发现,如果让模型在尝试解决问题之前,先在 LiveCodeBench 上想出一些点子(这个过程叫做 IdeaSearch / 思路搜索),然后看看模型能不能用这些点子解决问题。

结果发现,模型要么完全解决不了问题(准确度为 0%),要么就能完美解决问题(准确度为 100%)。这表明当模型尝试解决一个问题时,成功与否主要取决于它最初的那个想法(草图)对不对。

根据这两个实验的结果,研究人员认为一种提升 LLM 代码搜索能力的自然方法是:搜索正确的思路,然后实现它!

于是,规划搜索(PlanSearch)方法诞生了。

不同于之前的搜索方法(通常是搜索单个 token、代码行甚至整个程序)不一样,规划搜索是搜索解决当前问题的可能规划。这里,规划(plan)的定义是:有助于解决某个特定问题的高层级观察和草案的集合。

为了生成新规划,规划搜索会生成大量有关该问题的观察,然后再将这些观察组合成用于解决问题的候选规划。

这个操作需要对生成的观察的每个可能子集都执行,以最大化地鼓励在思路空间中进行探索,之后再将结果转译成最终的代码解决方案。

该团队的实验发现,在推理时有效使用计算方面,规划搜索方法优于标准的重复采样方法以及直接搜索思路的方法。

方法

在这项研究中,该团队探索了多种不同方法,包括重复采样(Repeated Sampling)、思路搜索(IdeaSearch)以及新提出的规划搜索(PlanSearch)。其中前两种方法顾名思义,比较直观,这里我们重点关注新提出的规划搜索。

该团队观察到,虽然重复采样和思路搜索能成功地提升基准评测的结果。但在很多案例中,多次提示(pass@k)(即使在温度设置很高)只会导致输出代码发生很小的变化,这些变化只会改变一些小方面,但无法改善思路中的缺陷。

51c大模型~合集50_大模型_37

下面来看具体的规划搜索过程:

1. 通过提示来获取观察

首先假设有一个问题陈述 P,通过向 LLM 发送提示词来获取对该问题的「观察」/ 提示。这里将这些观察记为  O^1_i,其中 i ∈ {1, . . . , n_1};这是因为它们是一阶观察。通常而言,n_1 的数量级在 3 到 6 之间。具体数量取决于 LLM 输出。为了利用这些观察结果来启发未来的思路,该团队创建了 O^1_i 的集合 S^1 的且大小至多为 2 的所有子集。其中每个子集都是观察结果的一个组合。这里将每个子集记为 C^1_i,其中 i ∈ {1, . . . , l_1},而

51c大模型~合集50_大模型_38

2. 推导新的观察

这样一来,所有观察结果的集合都可以定义为深度为 1 的有向树,其中根节点为 P,并且每个 C^1_i 都有一条从 P 指向 C^1_i  的边。

然后,在每个叶节点 C^1_i 上重复上一步流程,从而生成一个二阶观察集 S^2。为了得到二阶观察,该团队的做法是在给模型的提示词中包含原始问题 P 和 C^1_i 中包含的所有观察 —— 这些观察被构造为解决 P 所必需的原始观察。然后再提示 LLM,让其使用 / 合并在 C^1_i 中找到的观察来得出新的观察。

这个过程可以继续延伸,但由于计算限制,这里在深度为 2 时对该树进行了截断操作。

3. 将观察变成代码

在得到了观察之后,必须先将它们实现成具体思路,然后再将它们转译成代码。

具体来说,对于每个叶节点,将所有观察以及原始问题 P 放入提示词来调用 LLM,以便生成问题 P 的自然语言解决方案。为了提升多样性,对于每个生成的思路,该团队通过假设该思路是错误的来生成一个额外的思路,并要求 LLM 给出批评 / 反馈,从而将提议的思路翻倍了。

然后,再将这些自然语言解决方案转译成伪代码;再把这些伪代码转译成真正的 Python 代码。

实验

实验采用了三个评估基准:MBPP+、HumanEval+ 和 LiveCodeBench。参数设置等细节请参阅原论文。

至于结果,该团队报告了三种方法的结果,包括重复采样、思路搜索和规划搜索,见表 1、图 1 和图 5。

51c大模型~合集50_大模型_39

可以看到,规划搜索和思路搜索的表现明显优于基础的采样方法,其中规划搜索方法在所有实验方法和模型上都取得了最佳分数。

图 7、8、9 展示了在每个数据集上的详细 pass@k 结果。

51c大模型~合集50_大模型_40

51c大模型~合集50_大模型_41

51c大模型~合集50_大模型_42

可以看到,在 Claude 3.5 Sonnet 上使用规划搜索方法时,在 LiveCodeBench 基准上得到了当前最佳的 pass@200 性能:77.0%。该表现优于不使用搜索时获得的最佳分数(pass@1 = 41.4%)以及标准的 best-of-n 采样方法的分数(pass@200 = 60.6%)。

此外,使用小型模型(GPT-4o-mini)执行规划搜索时,仅仅 4 次尝试后就能胜过未使用搜索增强的大型模型。这佐证了近期一些使用小模型进行搜索的有效性的研究成果。

在另外两个编程基准 HumanEval+ 和 MBPP+ 上,规划搜索也能带来类似的提升。

通过研究特定模型的差异,该团队注意到 pass@k 曲线所呈现的趋势在所有模型中并不统一;事实上,每条曲线看起都不一样。该团队猜想部分原因是思路多样性的变化。

该团队还得到了一个有趣的观察结果:规划搜索并不利于某些模型的 pass@1 指标,其中最明显的是 Sonnet 3.5 在 LiveCodeBench 上的表现 —— 这是实验中表现最好的组合。

该团队基于直觉给出了解释:提升思路多样性可能会降低生成任何特定思路的概率,同时增加在给定池中至少有一个正确思路的几率。因此,pass@1 可能会略低于平常,但也正是由于这个原因,pass@k 指标可能会优于缺乏多样性的思路池。

另外,表 1 和图 1 给出了在尝试 / 完成上经过归一化的主要结果。其中针对每个问题,每种搜索方法都可以尝试 k 次。

最后,该团队还发现,在思路空间中观察到的多样性可用于预测搜索性能,这可通过模型 / 方法的 pass@1 与其 pass@200 之间的相对改进计算得到,如图 6 所示。

虽然熵是最常见的多样性度量是,但由于种种原因,熵不足以精确衡量 LLM 的多样性。

因此,该团队测量多样性的做法是在所有生成的程序上使用简单的配对策略,将其置于思路空间中进行计算。具体算法请访问原论文。



#AI-Researcher

召唤100多位学者打分,斯坦福新研究:「AI科学家」创新确实强

近日,一篇关于自动化 AI 研究的论文引爆了社交网络,原因是该论文得出了一个让很多人都倍感惊讶的结论:LLM 生成的想法比专家级人类研究者给出的想法更加新颖!

我们都知道通过调节 LLM 的温度值确实可以调整它们的随机性和创造性,但在科学研究方面比人类还懂创新?这还是超乎了很多人的想象 —— 至少很多人没想到这会来得这么快。难道 AI 科学家真的要来了?

51c大模型~合集50_大模型_43

那么,这项来自斯坦福大学的研究究竟得出了什么样的结论呢?

  • 论文地址:https://arxiv.org/abs/2409.04109
  • 调查链接:https://tinyurl.com/execution-study
  • 项目地址:https://github.com/NoviScl/AI-Researcher

LLM 能生成新颖的研究思路吗?

为了准确地对比 LLM 与人类在科研思路创新方面的能力,斯坦福大学的这个研究团队招募了 104 位 NLP 研究者,让其中 49 位写下创新研究想法,然后再让 79 位专家对 LLM 和人类给出的思路进行盲测。请注意,其中有 24 位人类专家既写了想法,也参与了盲测,当然他们并不评估自己写的内容。

模型(或者按该团队的说法:思路生成智能体)方面,该团队使用了 claude-3-5-sonnet-20240620 作为骨干模型。具体来说,给定一个研究主题(比如:可以提升 LLM 事实性并降低其幻觉的提示方法),让 LLM 生成一系列对  Semantic Scholar API 的函数调用。这个论文检索动作空间包括  {KeywordQuery (keywords), PaperQuery (paperId), GetReferences (paperId)} 。每个动作生成都基于之前的动作和已执行的结果。

该研究使用的研究主题有 7 个:偏见、编程、安全性、多语言、事实性、数学和不确定性。下表是各个主题的想法数量:

51c大模型~合集50_大模型_44

研究过程如下图所示:

51c大模型~合集50_大模型_45

这里我们不细说其详细的设置和评估过程,详见原论文。总结起来就是比较人类专家与 AI 智能体生成的科研思路的新颖程度。我们直接来看结论。

根据该团队思路评分(Idea Ranking)规则,他们对人类和 AI 提出科研思路进行了打分,见图 2 和表 7:

51c大模型~合集50_大模型_46

51c大模型~合集50_大模型_47

其中 Human Ideas 是指招募的专家研究者提出的思路,而 AI Ideas 则是 LLM 智能体给出的排名第一的思路。AI Ideas + Human Rerank 是指由 AI 生成思路但由本研究一作 Chenglei Si 手动从排名靠前的思路中选择他认为最好的一个。

可以看到,在新颖度方面,不管是 AI Ideas 还是 AI+Rerank,都显著优于 Human Ideas(p < 0.01)。在激动人心(excitement)分数上,AI 生成的思路的优势更是明显(p<0.05)。并且  AI Ideas + Human Rerank 的整体分数也优于人类(p<0.05)。不过 AI 生成的思路在另外两方面(可行性和有效性)与人类的差别不大。

当然,我们也能看出,这项调查研究有一些明显的局限,比如其调查范围较小,样本量太少了,评价很主观。另外作者也指出人类研究者可能会「藏私」,可能并不会分享自己的最佳想法。

不管怎样,这项研究证明了一点:让 AI 参与到科学研究中多半是有利的。尤其是当你灵感枯竭、思维阻塞时,问一问 LLM 或许就能有意想不到的收获。

生成创新想法的 AI 工具,正在不断涌现

实际上,已经有研究团队在打造专用于此类任务的 AI 工具了。比如近日一位专注于开发 LLM 应用的研究者 Shubham Saboo 就在社交网络分享了使用 Cursor 构建一个多智能体 AI 研究者的过程。他表示整个过程用时不到 5 分钟!参见如下视频:

,时长01:06

也有人分享了自己的一项相关研究,表示可以使用 LLM 和因果图谱自动生成心理学假设,并生成比 GPT-4 和博士生表现都好:

51c大模型~合集50_大模型_48

近日,印度科学学院(Indian Institute of Science,IISc)的研究者发现,AI 在设计创意方面也比人类更有想法。具体来说,AI 可通过一种新的人工智能会话式「主动构思」(Active Ideation)界面来生成新创意。作为一种创意构思生成工具,它可帮助新手设计师缓解一部分的初始延迟和构思瓶颈。

  • 论文标题:A Novel Idea Generation Tool using a Structured Conversational AI (CAI) System
  • 论文地址:https://arxiv.org/pdf/2409.05747

具体来说,这是一种动态、交互、上下文响应式方法,通过大型语言模型(LLM)主动参与,为不同的设计问题生成多个潜在创意陈述。论文称之为「主动构思场景」,它有助于促进基于对话的持续互动、对上下文敏感的对话以及多产的构思生成。

在当前的很多研究设计中,从书面信息到基于关键词的在线资源检索的转变至关重要。这强调了文本在转变思维模式和通过发展高级设计语言促进系统化构思方面的重要性。下表 1 总结了最常用的传统构思技术、其过程、局限性、涉及的认知原则以及在产生创意方面的预期结果。

51c大模型~合集50_大模型_49

虽然这些传统方法已被广泛使用,但它们往往无法为新手设计师提供积极的支持。在产生新颖想法的过程中,原创性和多样性主要依赖于设计者。这一空白标志着将人工智能与构思相结合的潜力。

这篇论文就深入探讨了对话式人工智能(CAI)系统的设计、开发和潜在使用案例,重点是比较基于 CAI 的构思工具与传统方法的效率。

有两个有趣的特点使 CAI 系统看起来很智能:(a) 能够就给定主题生成智力上可接受的文章,(b) 能够在先前交互的基础上生成对后续询问的回复。这使得交互成为关于特定主题的连贯对话。因此,如果特征(a)是对一个观点的描述,那么特征(b)就可以被构建为对该观点的阐述和澄清。

如图 3 所示,这项研究设计并开发了一个主动构思界面,使用了生成式预训练 Transformer(GPT)对话式人工智能系统,该系统嵌入了一个交互式情绪板(moodboard)。GPT 为自然语言交互提供了基础,使其能够根据用户输入做出响应并生成创意陈述,情绪板提供了一种快速记录这些想法的手段。因此,该界面为设计师提供了一个对话式的直观平台,由 GPT 驱动创意生成。

51c大模型~合集50_大模型_50

由于本研究调查的是建议的基于 CAI 的构思界面对新手设计师的潜在益处,因此招募了 30 名产品设计研究生(下图),分为 A 和 B 两组。

51c大模型~合集50_大模型_51

论文对这 30 名新手设计师进行了试点研究,让他们使用传统方法和基于 CAI 的新界面,针对给定问题产生创意。然后,让专家小组使用流畅性、新颖性和多样性等关键参数对结果进行了定性比较。

研究结果表明,本文所提出的 AI 工具在生成多产、多样和新颖的想法方面非常有效。通过在每个构思阶段加入提示设计的结构化对话风格,使界面更加统一,更方便设计者使用。结果发现,这种结构化 CAI 界面所产生的反应更加简洁,并与随后的设计阶段(即构思阶段)保持一致。

51c大模型~合集50_大模型_52

从图 5(a)中可以看出,68% 的专家认为 GPT 产生的想法更有意义。此外,图 5 (b) 显示,GPT 生成的语句的得票率始终高于设计者生成的想法。

下表是 A 和 B 两组的想法陈述对比:

51c大模型~合集50_大模型_53

以下是不同维度下,人类与 GPT 构思的评估结果对比:

51c大模型~合集50_大模型_54

51c大模型~合集50_大模型_55

更多研究细节,可查看原论文。

结语

创新,长久以来被视为人类不可被机器触及的领地,然而,LLM 所展现的「幻觉」现象却悄然打开了这扇门,揭示了创新机制可能并非我们想象中那般高不可攀。

近期在 AI 创造性研究领域的突破,预示着 AI 在创意之路上或将迎来前所未有的广阔天地。展望未来,或许在不远的将来,我们将见证 AI 科学家、AI 导演、AI 设计师们纷纷挥洒创意,它们的作品将点亮 AI 应用的崭新篇章。


#Strawberry 

OpenAI「草莓」两周内发布?网传不是多模态,反应慢了10多秒

ChatGPT 要进化了?

传说中的「草莓」可能真的要来了,就在这两周。

据科技媒体 The Information 报道,两位测试过该模型的人士表示,OpenAI 计划在未来两周内将「草莓」(Strawberry ) 作为 ChatGPT 服务的一部分发布。当然,这个时间不是绝对准确,随时可能发生变化。

虽然「草莓」作为 ChatGPT 服务的一部分,但它是一个独立的产品。具体如何向用户提供尚不清楚,一种可能的选择是将 「草莓」 纳入客户可以选择的 AI 模型下拉菜单中,以支持 ChatGPT。

51c大模型~合集50_大模型_56

「草莓」或许会出现在右边模型选择中,现在也只是猜测。

当然,「草莓」与其他对话式 AI 最大的区别在于它能够在响应之前进行「思考」,而不是立即回答问题,两位测试过该模型的人表示,「草莓」的思考阶段通常会持续 10 到 20 秒。

测试过该模型的人还透漏,初始版本的「草莓」只能接收和生成文本,而不能接收和生成图片,这意味着「草莓」还不像 OpenAI 其他模型那样是多模态的。目前大家见到的大模型都是多模态的,这似乎是「草莓」一个明显缺点。

大家比较关心的还有定价问题。「草莓」的定价可能与 OpenAI 的聊天机器人不同,后者有免费和订阅定价等级。知情人士表示,他们还不确定 「草莓」的具体定价,但据另一位了解该产品的人士称,「草莓」可能会限制用户每小时发送消息的最大数量(即设置上限),并可能提供更高价格的等级(此前网传订阅价格最高可达每月 2000 美元,也有传言 200 美元,但最终价格尚未确定),以加快响应速度。

OpenAI 是否会向使用更大版本「草莓」 的客户收取比现在 ChatGPT 高得多的价格,还有待观察。

对于复杂问题或需要多步推理的查询,「草莓」或许比 GPT-4o 更易于使用。

「草莓」不仅在数学问题和编码方面表现更佳,在更主观(subjective)的商业任务方面也表现更佳,比如制定产品营销策略。在这类任务中,该模型将提供更针对客户公司、更详细的建议,比如生成每周执行计划。

其中一位知情人士表示,「草莓」在「思考」阶段有助于避免犯错。响应增加的额外时间也使 「草莓」更有可能知道如何全面回答用户问题。

但 OpenAI 在发布「草莓」之前或之后可能还需要解决一些问题。

例如,一位测试过该模型的人士表示,尽管「草莓」能够在人们问它一些简单问题时跳过思考步骤,但该模型在实践中并不总是这样做。因此,它可能会思考太久而无法回答 OpenAI 的其他模型可以在一瞬间回答的问题。

这位知情人士还说,一些使用过「草莓」 原型的人会抱怨,与 OpenAI 目前发布的 GPT-4o 相比,「草莓」的响应稍好一些,但并不值得多等待 10 到 20 秒的时间。

虽然「草莓」还旨在记住并整合之前与客户的聊天内容,基于此然后再回答新问题 —— 当用户有特定偏好时,比如他们希望以某种格式编写软件代码 —— 但原型有时也会在这方面遇到困难,这位知情人士说。

不过,话说回来,在刚刚过去的八月,关于「草莓」的爆料就接连不断。前几天,同样来自 The Information 的报道称,OpenAI 计划最早在今年秋天推出代号为 「草莓」(之前称为 Q*,发音为 Q Star)的新人工智能,作为聊天机器人的一部分(可能集成在 ChatGPT 内)。

综合各方爆料,OpenAI 这次可能不会再鸽了。

参考链接:

https://www.theinformation.com/articles/new-details-on-openais-strawberry-apples-siri-makeover-larry-ellison-doubles-down-on-data-centers?rc=ks2jbm




#iPhone16跑分泄露

8G内存,A18多核不敌上上代A16,网友:假的吧

祖传 60Hz、龟速充电,你会买吗?

昨天,数码圈迎来了非常热闹的一天,先有苹果 iPhone 16/16 Pro 系列新机登场,后有华为全球首发三折叠手机 Mate XT。

而苹果又一次被嘲「挤牙膏」,尤其是 iPhone 16 标准版,祖传 60Hz 屏幕刷新率、25W 充电。除此之外,唯一的亮点算是新增的相机控制(Camera Control)按钮了。

今天一早,iPhone 16 的跑分成绩冲上了热搜。

知名跑分网站 Geekbench 6 上出现了一款代号为「iPhone17, 3」的机型。据了解,该机型应为 iPhone 16,搭载 A18 处理器,手机系统为 iOS 18,完整内存应该是 8GB。

跑分结果显示,iPhone 16 单核为 3114 分、多核为 6666 分。而与上代 iPhone 15 Pro Max 搭载的 A17 Pro 处理器相比,单核成绩占优(2887)、多核成绩低了很多(7159)。

51c大模型~合集50_大模型_57

单核/多核成绩中各自列出了文件压缩、导航、HTML5 浏览器、PDF 渲染器、图库、文本处理、对象删除、HDR、照片过滤、光追等具体任务的跑分。

51c大模型~合集50_大模型_58

此外,Geekbench 6 上还出现了另一款机型为「iPhone17,2」的跑分成绩,单核为 3018 分、多核为 7751 分。

51c大模型~合集50_大模型_59

根据该机型的主板代号和综合跑分,有人猜测应该是 iPhone 16 Pro 系列,处理器为 A18 Pro。如果真是如此,就比较奇怪了,单核成绩反倒不如上面的 A18 了,多核则正常高出了 1000 多分。

网友热评:多核这么低,怎么跑出来的

iPhone 16 这样的跑分成绩让一些网友感到不可思议,有人甚至直呼「垃圾」。

还有人期待接下来的高通骁龙 8 Gen 4 爆杀 A18。

不过也有人指出,Geekbench 的这份 A18 跑分可能是假的,否则多核成绩甚至不如 iPhone 14 Pro 搭载的那颗 A16 了,这太令人大跌眼镜了。

51c大模型~合集50_大模型_60

图源:https://x.com/Double_Lamekid/status/1833565160377880662

显然,iPhone 16 系列的跑分成绩无法令人满意。有人认为,这是由于 Geekbench 6 没有更新,才导致如此低的多核成绩。

看来只有等到新机正式发售之后,我们才能看到 A18/A18 Pro 系列处理器的真正成色了。




#MMToM-QA

GPT-4V暴露致命缺陷?JHU等发布首个多模态ToM 测试集,全面提升大模型心智能力

本文第一作者为 Chuanyang Jin (金川杨),本科毕业于纽约大学,即将前往 JHU 读博。本文为他本科期间在 MIT 访问时的工作,他是最年轻的杰出论文奖获得者之一。本文的指导老师为 Tianmin Shu (舒天民),JHU 助理教授,Social Cognitive AI Lab 的主任。博士师从 UCLA 朱松纯教授,在 MIT 完成博后,致力于构建能够在现实世界中理解、推理和与人类互动的社会智能系统,从而推进以人为中心的 AI。本文另外两位指导老师 Joshua B. Tenenbaum、Antonio Torralba 为 MIT 著名教授,google scholar 引用量均在 10 万以上。

心智能力(Theory of Mind,ToM),即理解人们思维的能力,是开发具有类人社会智能的 AI 模型的重要基础。

近日,来自 JHU, NYU, MIT, Harvard 等机构的研究团队开创了第一个多模态的 ToM 测试基准,发现现有的多模态模型和 LLM 都表现存在系统性缺陷,同时他们提出了一种有效的新方法。在刚结束的 ACL 2024 会议中,这篇论文获得杰出论文奖。

  • 论文标题:MMToM-QA: Multimodal Theory of Mind Question Answering
  • 论文地址: https://arxiv.org/abs/2401.08743
  • 网站: https://chuanyangjin.com/mmtom-qa
  • 代码: https://github.com/chuanyangjin/MMToM-QA

MMToM-QA

第一个多模态的 ToM benchmark

先前所有心智能力的测试基准都是单一模态的。MMToM-QA 是第一个多模态的心智能力测试基准。其中每个问题包含三部分:一个人的活动视频,环境和人类动作的文字描述与一个 ToM 问题。

,时长00:06

此前,大部分的心智能力测试基准都使用较简单的模版,文字或视频的长度很短。MMToM-QA 要求在更长的上下文下,更复杂多样的环境下系统性衡量模型的心智能力。既考察 belief(人们所认为的),也考察 goal(人们的目标)。

51c大模型~合集50_大模型_61

为了生成这些视频,该团队使用 VirtualHome-Social 模拟器来中生成一系列人物动作,并渲染合成视频。接下来,使用一个模型来跟踪记录在视频的每个时刻中 agent 所有可能的目标和想法,据此生成问题,并使用 GPT-4 生成改进问题的描述。

51c大模型~合集50_大模型_62

Meta、MIT、CMU、JHU 的众多团队已使用 MMToM-QA 来研发与人合作的大模型、机器人等。

大模型集体翻车

GPT-4V 存在致命缺陷

在 MMToM-QA 上的实验结果显示,当人们可以使用不同模态的信息时,他们理解他人的能力会有所提升。在这种多模态条件下,在每个问题上大多数参与者都达成了一致意见,这验证了基准设计的有效性。

51c大模型~合集50_大模型_63

相比之下,多模态模型和 LLM 的表现远不如人类。它们在所有问题类型上表现得像随机猜测一样。唯一的例外是 GPT-4V,当人们的信念与现实一致时它表现良好,但当涉及到人们持有错误信念或更新信念时,GPT-4V 会系统性犯错,并且在判断目标时表现较差。

以下是 GPT-4V 的一个失败案例。从视频和文本中可以看出,柜子里没有蛋糕,但女人却朝柜子走去,准备打开它。因此,正确答案应该是 「女人认为柜子里有一个蛋糕。」然而,GPT-4V 错误地使用了真实世界的状态来推断女人的想法,这表明 GPT-4V 无法区分信念和真实世界状态。

51c大模型~合集50_大模型_64

BIP-ALM

小模型 + 逆向规划超过 GPT-4V

那么,我们该如何缩小 AI 模型和人类表现之间的差距?

该团队提出了一种新方法:BIP-ALM (Bayesian Inverse Planning Accelerated by Language Models)。该方法首先从视频和文字中提取出相同的符号表示,接着对这些表示进行对齐和融合,再使用逆向结合语言模型来推断各种心理状态的概率。

51c大模型~合集50_大模型_65

以下是融合符号表示的方法。模型将从视频中提取特定时刻的场景关系图,识别人物与物体之间的关系,例如他们正在经过哪些物体或他们正朝哪些物品前进。由于摄像头视角的限制和遮挡,文本提供了这些可能无法直接从视频中观察的这些信息。

51c大模型~合集50_大模型_66

贝叶斯逆向规划(Bayesian inverse planning)可以根据观察到的 agent 的行为来推断其心理状态与潜在的信念和目标。先前的研究表明,贝叶斯逆向规划可以在简单情景下成功。然而,当状态空间变得很大时,计算每个可能信念和目标的概率变得非常复杂,导致计算瓶颈。下图中蓝色标出的部分就是一个计算瓶颈。为了加速这一过程,该团队使用了语言模型来估计每个时刻的心理状态的概率。

51c大模型~合集50_大模型_67

先前的大模型和各种方法无论是在文本、视频、还是多模态版本的 MMToM-QA 上都表现较差,而 BIP-ALM 则展现了较好的结果。论文作者认为 BIP-ALM 得益于:(1) 使用适用于不同模态信息的符号表示,(2) 模仿人类心智推理的逆向规划方法具有很强的鲁棒性和可解释性,(3) 语言模型具有很好的灵活性和可扩展性。

后续工作

走向多智能体的多模态心智模型

该团队提出了后续研究 MuMA-ToM: Multi-modal Multi-Agent Theory of Mind,将 MMToM-QA 的测试基准和方法拓展到了多个智能体的领域。

  • 论文标题:MuMA-ToM: Multi-modal Multi-Agent Theory of Mind
  • 论文地址: https://arxiv.org/abs/2408.12574
  • 网站: https://scai.cs.jhu.edu/projects/MuMA-ToM
  • 代码: https://github.com/SCAI-JHU/MuMA-ToM

MuMA-ToM 关注多智能体的互动,考察它们的信念、社会目标、和对他人目标的信念,发现大型多模态模型 GPT-4o、Gemini-1.5 Pro 等依然表现糟糕。针对这些发现,研究团队进一步提出了改进的方法 LIMP (Language model-based Inverse Multi-agent Planning)。相比之前的方法,LIMP 使用自然语言而不是符号表示来提高通用性,并且能够利用任何预训练的大型语言模型,而 BIP-ALM 则要求开放权重的大型语言模型。

51c大模型~合集50_大模型_68