Qiushi Sun

OS-Genesis：自动构造 GUI Agent 所需的训练数据 (ACL 2025)

2025-05-15T10:00:00+08:00

论文题目：[ACL 2025] OS-Genesis: Automating GUI Agent Trajectory Construction via Reverse Task Synthesis

项目地址：https://qiushisun.github.io/OS-Genesis-Home/

论文地址：https://arxiv.org/abs/2412.19723

研究机构：上海AI Lab，香港大学，上海交通大学，约翰霍普金斯大学，牛津大学，香港科技大学

1 背景与动机

自二十世纪的科幻小说《R.U.R.》首次提出Agent（智能体）概念以来，从文学到影视，自动化智能体的愿景便深植于人类想象之中。无论是早期的机械人形，还是《钢铁侠》中高度智能的JARVIS，人们始终憧憬着能够辅助甚至取代人类完成日常任务的数字代理（Digital Agents）。如今，随着视觉语言模型（VLMs）等多模态技术的快速发展，这一梦想正逐步迈向现实。

1-1 构建通用GUI Agent的关键能力与挑战

要构建一个真正有效的Computer-Use Agent，必须同时具备两个关键能力：（1）规划能力（Planning），即能够将用户给出的高层次指令拆解为可执行的子目标；（2）执行能力（Action），即根据当前目标，在环境中执行相应的操作。

现有研究沿着这两个能力的划分发展出两类代表性路径：（1）以 OS-Copilot 和 UFO-Agent 为代表的GUI Agents，它们依赖调用系统API或访问无障碍树（a11y tree）等手段，实现对移动应用、网页等数字界面的交互控制；（2）以经典模型SeeClick 和 OS-ATLAS 为代表的GUI动作模型（GUI Action Models），通过感知环境状态并执行具体操作（如点击、拖动），以完成用户指令/意图的落实。

尽管这些方法已在部分任务中展现出了一些可行性，但它们在实际部署中仍面临很大的局限：前者严重依赖闭源的大模型（如GPT-4o，Claude），交互方式受限于prompt engineering，API的成本也很高；后者虽然更轻量，但需要额外搭配一个规划模型（Planner）才能发挥完整作用，系统复杂度和部署成本高。

从通用性和可落地性的角度来看，构建一个统一的、端到端的、基于开源VLM的GUI Agent，对于大规模推广通用人机交互系统具有重要意义。然而，这一目标的最大挑战在于高质量训练数据的缺乏 —— 如何大规模构建多样化、真实有效的GUI交互轨迹，仍是当前亟待解决的关键问题。

1-2 数据瓶颈

在构建高质量的GUI agent时，GUI轨迹数据能最有效地让agent学习如何完成任务，其数据稀缺性是当前digital agent领域最关键挑战之一。以下是一个典型的GUI轨迹数据示例，它包括以下部分：

高阶指令：明确规定任务目标，例如“将菜单应用中的‘Avocado Toast with Egg’标记为收藏”。
低阶指令：分解为具体的操作步骤，例如“点击‘Avocado Toast with Egg’以查看更多选项”。
动作（Action）：与低阶指令相关的具体操作，如“CLICK [Avocado Toast with Egg]”。
状态（State）：包括执行动作前后的可视化和文本化表示，例如屏幕截图和GUI的a11ytree结构。

这类结构化、多模态的数据对于支持智能体进行任务规划、状态感知和动作决策具有不可替代的价值。然而，如何高效、自动化地大规模生成此类高质量轨迹，仍是一个亟待突破的研究难题。

当前的GUI轨迹数据构建方式主要包括两类：依赖人工监督的人工（Human annotation）采集，以及基于预定义任务（Task-Driven）的自动合成。然而，这两种方法在实际应用中均面临显著的局限性：

人工采集的成本高昂：人工构建高质量交互轨迹不仅需要设计具有代表性的高阶任务指令，还需逐步记录细化的操作过程。这一流程高度依赖人力资源，数据规模受限，成本与效率难以兼顾，难以满足大规模训练的需求。
合成数据的可用性受限：虽然利用模型自动生成轨迹在一定程度上缓解了人工成本，但大多数方法依赖预先定义的任务目标，生成的轨迹缺乏多样性和环境适应性。当任务目标与环境状态不匹配，或模型在中间步骤出现错误时，生成的轨迹往往表现为不完整、不连贯，甚至不可执行。

因此，如何在成本可控的情况下构建一种高效、低成本且具多样性与真实性的轨迹数据生成机制，已成为推进GUI Agent训练的关键挑战之一，在此动机下，本文提出了OS-Genesis：一套无需人工监督的高质量GUI数据合成框架，支持端到端的GUI Agents训练

2 OS-Genesis概览

OS-Genesis的核心思想是通过探索性地与GUI环境交互，捕捉每个动作及其引起的状态变化。

基于这些状态变化，系统首先逆向生成高质量的低阶指令（Low-level instruction，如 “Click Calendar APP”），然后根据环境状态推导出相应的高阶指令（High-level instruction，如 “添加日程：看AINLP的推文”）。模型随后执行这些合成的指令，整个过程无需人工干预和预定义任务，从而实现了高效且多样化的GUI轨迹数据生成。我们认为，这一方法为构建通用GUI agent提供了创新思路，具体实现方式包括（1）反向任务合成构建任务与轨迹与（2）轨迹奖励建模控制数据质量

2-1 反向任务合成

反向任务合成（Reverse Task Synthesis）是OS-Genesis的核心，它帮助我们在构建GUI轨迹数据时摆脱需要人工/机器预定义任务的局限。其流程如下所示

动作记录与状态捕捉

在没有预定义任务的情况下，OS-Genesis通过在GUI环境中系统性地执行基本动作（例如CLICK、TYPE、SCROLL等），生成大量的三元组数据 ⟨状态前，动作，状态后⟩，即 ⟨spre, action, spost⟩。这些三元组记录了每个动作对环境状态的影响，为后续的任务合成提供了原始数据。

低阶指令生成（Low-Level Isntruction）

基于GPT-4o模型，OS-Genesis会将每个三元组 ⟨Screen1, Action, Screen2⟩ 转换为描述具体操作的低阶指令（Low-level Instruction）。例如，当CLICK动作导致菜单展开时，对应的低阶指令可能是”点击下拉菜单以显示选项”。

高阶任务生成（High-Level Isntruction）

基于低阶指令，OS-Genesis进一步生成高阶指令（High-level Instruction）。这些高阶指令通过整合低阶步骤和当前GUI环境的信息，描述更抽象且明确的任务目标，如”配置应用程序设置”。这种从低阶到高阶的渐进式生成方法不仅保证了指令的逻辑连贯性，还充分利用了GUI环境的动态特性。

在采集三元组的过程中，只需要使用CLICK和TYPE就可以遍历绝大多数探索空间中的功能，而所生成的任务则是开放式的，可能包含了大量会被执行的动作，动作空间如下所示

通过上述反向任务合成，OS-Genesis可以在没有人工干预的情况下构建多样化、语义丰富的任务集合，显著提升了数据生成的效率和质量。

2-2 轨迹构建与奖励建模

生成的高阶指令将作为探索GUI环境的起点，用于构建完整的轨迹数据（Trajectory）。为了保证轨迹质量，OS-Genesis引入了奖励模型（Trajectory Reward Model, TRM）来评估和筛选生成的轨迹。以下是轨迹构建与奖励模型的详细流程：

轨迹执行

利用反向任务合成生成的高阶指令，GUI agent会执行一系列动作以完成任务。每条轨迹由以下内容组成：高阶指令、低阶指令、动作序列以及状态（包含截图和a11ytree）。

轨迹奖励模型（Trajectory Reward Model）

为避免低质量或不完整轨迹对模型训练的负面影响，OS-Genesis使用TRM对每条轨迹分配一个奖励分数。奖励分数基于以下两个指标：

完成度（Completion）：衡量一条GUI轨迹是否成功完成High-level 任务，包括每个步骤的正确性和逻辑连贯性。
一致性（Coherence）：评估轨迹的逻辑是否恰当，确保动作序列能够高效地实现任务目标。

Reward-driven的数据筛选方法

根据奖励分数，轨迹数据会被优先用于模型训练。与传统的二元过滤方法（即抛弃执行失败的任务）不同，TRM允许部分不完整但具有探索价值的轨迹保留在数据集中，从而最大化地利用生成的数据。

通过结合反向任务合成和奖励模型，OS-Genesis实现了从任务生成到轨迹构建的端到端流程。实验结果表明，OS-Genesis生成的数据在质量和多样性上均显著优于现有方法，为构建通用GUI agent提供了可靠的数据支持。

3 实验、训练与测评

为了验证OS-Genesis生成高质量轨迹数据的能力，我们在多个动态环境中进行了实验。在移动端场景中，我们选择了AndroidWorld和AndroidControl作为测试平台；在网页端场景中，我们使用WebArena作为测评基准。通过这些复杂环境的实验，我们对比了使用OS-Genesis合成数据训练的agent与传统方法的表现。

3-1 模型与基线方法

VLMs. 我们在实验中选择了代表性的VLSs作为GUI agent的基础模型，以便全面评估OS-Genesis生成的数据在不同模型上的的影响：

InternVL2-4B/8B：一种支持高分辨率动态输入的开源VLM，主要用于视觉任务。其扩展版本InternVL2-8B具有更大的模型容量。
Qwen2-VL-7B-Instruct：一种多模态模型，具备一定的GUI交互能力，专为指令执行任务优化。

此外，我们还额外添加了GPT-4o作为一个强baseline，来比较我们所训练的开源模型和商业模型之间的差距

Baselinse. 所有的baseline接受的状态信息均为 Screenshots + a11ytree（即视觉信息和结构化的文本表示）

Zero-Shot：直接使用未经过额外训练的模型完成任务。这种方法用于评估模型的原始能力。
Task-Driven：利用预定义任务和固定策略生成数据，广泛应用于传统数据生成流程。
Self-Instruct：在Task-Driven的基础上，引入自我指令生成机制来扩展任务的和覆盖范围。

3-2 训练技法

基于VLMs构建 GUI Agents 的训练过程，本质上是一种监督微调（SFT）。之前的工作鲜有涉及如何将planning & reasoning 与 action统一训练，因此，为充分发挥合成轨迹的效用，OS-Genesis 别出心裁的设计了两个互补的训练目标：

1.规划训练（Planning Training）

旨在提升 Agent 的任务拆解能力。对于每条轨迹$g_i \in \mathcal{G}$，在给定多模态输入$s$、高阶指令$h_i$和历史上下文$c$的前提下，Agent $\theta$同时预测低阶指令 $\ell$ 和相应动作 $a$： $\mathcal{L}_1=-\sum_{t_i \in \mathcal{T}} \log \left(p_\theta\left(\ell \mid s, h_i, c\right) \cdot p_\theta\left(a \mid s, h_i, c, \ell\right)\right)$ 2.动作训练（Action Training）

强化 Agent 在已有低阶指令下，执行正确动作的能力： $\mathcal{L}_2=-\sum_{t_i \in \mathcal{T}} \log p_\theta(a \mid s, c, \ell)$ 训练完成后，Agent 会采用 ReAct 风格的输出形式，记录其逐步推理过程并执行交互操作。

3-3 Mobile（移动端自动化）

在AndroidWorld（In-domain实验）中，OS-Genesis生成的数据显著提升了GUI agents的任务成功率，从基线的9.82%提升至17.41%，几乎翻倍。尤其是在任务规划和复杂操作中，OS-Genesis的数据展现了更强的适应性和泛化能力。
在AndroidControl中（OOD实验），OS-Genesis生成的轨迹在高阶和低阶任务中均表现优异，尤其在高阶任务中展现出显著提升的规划能力。此外，OS-Genesis在从未见过的应用场景中也表现出强大的泛化能力，充分验证了其生成数据的质量和多样性。

3-4 Web（网页端自动化）

OS-Genesis在WebArena中的表现显著优于基线方法。在复杂的交互式网页任务（如GitLab自动化和Reddit论坛）中，OS-Genesis数据所构建的agent比Task-Driven方法提升了约50%的性能。在多个动态网页场景下，通过OS-Genesis生成的数据，agent展现出更强的多样性和泛化能力。特别是在需要多步操作的任务中，其生成的轨迹更符合逻辑和用户意图。

4 分析

本项工作对GUI Trajectory Data的质量进行了非常详尽的分析，特别是将OS-Genesis生成的数据与人工标注（Human-annotated）数据进行了对比，以全面评估其在实际应用中的可行性和有效性。

4-1 高阶指令对比

我们首先比较了OS-Genesis生成的高阶指令与人工编写的高阶指令在任务执行中的效果。实验基于AndroidWorld的500个人工标注轨高阶任务，采用GPT-4o探索其对应轨迹，并用这些轨迹训练基于InternVL2-8B和Qwen2-VL-7B。为保证公平性，OS-Genesis和各baseline的轨迹数量保持一致。

结果分析

在任务成功率上，OS-Genesis生成的高阶指令显著优于人工编写的指令。这主要归因于以下两点：

动态环境适配性：人工编写的任务往往难以与复杂环境完全匹配，而OS-Genesis通过反向任务合成生成的指令能够自适应GUI动态特性，更符合环境需求。
逐步生成策略：OS-Genesis从低阶指令逐步构建高阶指令，确保了指令的逻辑连贯性和可执行性，而人工编写的高阶指令有时会因缺乏细节而导致轨迹不完整。

4-2 轨迹数据对比

为了进一步验证轨迹质量，我们将OS-Genesis生成的完整轨迹与人工标注（Human-annotated）轨迹在GUI agent训练中进行了对比分析。我们从AndroidControl的训练集中抽取了1,000条众包标注的轨迹用于训练和评估。如图所示，OS-Genesis成功地显著缩小了合成轨迹与人工标注轨迹之间的性能差距。

这种提升在高阶任务中非常显著，表明基于OS-Genesis轨迹训练的agent在任务规划和问题解决方面表现更接近于人类操作方式。从平均任务SR来看，将人工标注数据视为gold standard，OS-Genesis数据的性能保留率超过了80%。

4-3 轨迹奖励模型

作者们进一步探究了所使用的Trajectory Reward Model所起的效用，如图所示

可以看到，TRM 在提升 Agent 的高层次能力方面尤为有效，特别是在如 AndroidControl-High 与 AndroidWorld 等任务中表现显著。尽管引入外部标签器（Labeler）可带来一定的高层任务性能提升，但却会在低层任务中导致性能下降。

在低层级场景中，由于 OS-Genesis 所生成的轨迹数据本身质量较高、语义明确，即使是单步操作也具有较强的信息价值，因此无论采用何种训练策略，模型在此类任务上均能获得稳定提升。

4-4 多样性评估

对于 GUI Agent 的训练而言，数据多样性是模型泛化能力的关键保障。然而，传统基于预定义任务的合成方法天然受到限制——在复杂环境中几乎不可能穷举所有潜在交互路径。作者们从两个维度评估其多样性：（1）指令多样性：使用 Sentence-BERT 嵌入高阶指令，并计算平均embedding距离，结果显示 OS-Genesis 在移动端和网页端均获得最高的指令多样性；（2）轨迹多样性：对低阶动作应用同样的方法，OS-Genesis 同样表现出最广泛的行为覆盖。

有趣的是，人工标注数据尽管具有较高的指令多样性，却在轨迹层面明显受限，这说明人类在想象任务时更具创造性，但在实际操作中往往依赖熟悉的动作模式（这也很好理解，人都有自己的思维定势）。相比之下，OS-Genesis 同时实现了指令与行为层面的高多样性，更有助于全面激活环境探索的潜力。

5 总结与展望

OS-Genesis 为构建通用 GUI Agents 提供了全新的思路与方法。通过引入一种交互驱动的轨迹合成机制（Interaction-Driven Synthesis），OS-Genesis 有效突破了传统数据采集中难以构建（1）语义合理（2）形式多样的任务轨迹这一核心瓶颈。在多个具有挑战性的online benchmark中，我们实证表明：基于 OS-Genesis 生成的数据能够显著同时提升 GUI Agents 的规划能力与动作执行能力。同时，相比传统合成方法，OS-Genesis 所生成的轨迹具备更高的多样性与可用性，并在质量上显著缩小了与人工标注数据之间的差距。在当前 GUI Agent 研究迅速发展的背景下，OS-Genesis 所代表的任务反推式轨迹构建范式，展示出构建高质量、多模态、通用 GUI Agent 数据的广阔前景。

参考文献

OS-Copilot: Towards Generalist Computer Agents with Self-Improvement https://huggingface.co/OS-Copilot
UFO: A UI-Focused Agent for Windows OS Interaction https://arxiv.org/abs/2402.07939
SeeClick: Harnessing GUI Grounding for Advanced Visual GUI Agents https://aclanthology.org/2024.acl-long.505/ ACL’24
OS-ATLAS: A Foundation Action Model for Generalist GUI Agents https://arxiv.org/abs/2410.23218 ICLR’25 Spotlight
Navigating the Digital World as Humans Do: Universal Visual Grounding for GUI Agents https://arxiv.org/abs/2410.05243 ICLR’25 Spotlight
Ferret: Refer and Ground Anything Anywhere at Any Granularity ICLR’24 Spotlight
ReAct: Synergizing Reasoning and Acting in Language Models ICLR’23
A Survey of Neural Code Intelligence: Paradigms, Advances and Beyond https://arxiv.org/abs/2403.14734
AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents https://arxiv.org/abs/2405.14573 ICLR’25
On the Effects of Data Scale on UI Control Agents https://openreview.net/forum?id=yUEBXN3cvX NIPS’24
WebArena: A Realistic Web Environment for Building Autonomous Agents https://openreview.net/forum?id=oKn9c6ytLx ICLR’24
Breaking the Data Barrier – Building GUI Agents Through Task Generalization https://arxiv.org/abs/2504.10127
ScienceBoard: Evaluating Multimodal Autonomous Agents in Realistic Scientific Workflows https://arxiv.org/abs/2505.19897

大型语言模型真的擅长逻辑推理吗？(IEEE TKDE)

2025-03-20T10:00:00+08:00

论文题目：Are Large Language Models Really Good Logical Reasoners? A Comprehensive Evaluation and Beyond

作者机构：西安交通大学、新加坡南洋理工大学

论文链接：https://arxiv.org/abs/2306.09841

数据集链接：https://github.com/DeepReasoning/NeuLR

背景

在人工智能和自然语言处理的浪潮下，大型语言模型（LLMs）正以前所未有的速度发展。它们在各种任务中表现出色，从文本生成到信息检索，几乎无所不能。然而，当涉及到真正的逻辑推理能力时，LLMs 真的能像人类一样进行严谨的推理吗？本研究针对这一问题，构建了系统化的评估体系，并提出了一系列创新性的分析方法，以揭示 LLMs 在逻辑推理方面的真实能力。

全面评估 LLMs 的逻辑推理能力

本研究首次在大规模逻辑推理任务上，对 LLMs 进行了全方位、多角度的评估。研究团队选取了 15 个典型的逻辑推理数据集，并将其划分为四种类别：

演绎推理（Deductive Reasoning）：从一般性规则推导具体结论。
归纳推理（Inductive Reasoning）：从具体实例归纳出普遍性规律。
溯因推理（Abductive Reasoning）：在已有观察事实的基础上，推测最可能的解释。
混合推理（Mixed-form Reasoning）：结合多种推理模式进行复杂推理。

此外，本研究涵盖了 3 个早期代表性 LLMs（text-davinci-003、ChatGPT 和 BARD）以及 4 个最新的 LLMs（LLaMA3.1-Chat、Mistral-Instruct-v0.3、Claude-3 和 GPT-4），通过精细化的指标对比，为行业提供了系统化的性能分析。

本测评工作的主要结果，可以可视化为以下热力图：

逻辑推理准确率评估

下表中展示了大语言模型在逻辑推理任务上的正确率评估结果。

根据上述评估，可以得出了以下关键结论：

不同推理类型上的表现差异。 LLMs 在演绎推理（Deductive Reasoning）任务上整体表现较好，而在归纳推理（Inductive Reasoning）任务上表现较差。在溯因推理（Abductive Reasoning）任务中，各模型的表现参差不齐，部分 LLMs 能够较好地推测最有可能的解释，但整体仍有较大提升空间。
Few-shot对逻辑推理结果的影响。 与 NLP 领域的其他任务不同，在逻辑推理任务中，Few-shot 推理并未显著提升 LLMs 的推理能力，甚至在某些情况下反而降低了模型的准确率。其中，在归纳推理和混合推理任务中，Few-shot 提示效果最不稳定，而在演绎推理任务中，少量 Few-shot 样本能略微提升模型表现。
不同任务形式的影响（生成 vs. 选择） 在分类任务（选择题）中，LLMs 的正确率普遍高于生成任务（自由回答）。这表明 LLMs 在面对结构化选项时更容易做出正确推理，而在开放性任务中，其推理链条更容易出现错误或冗余内容。

创新性评估方法：超越简单准确率

与以往仅关注答案正确率的研究不同，本研究提出了一种更为细粒度的评估方法，从多个维度深入挖掘 LLMs 在逻辑推理方面的表现：

答案正确性（Answer Correctness）：衡量 LLMs 是否能够给出正确答案。
解释正确性（Explanation Correctness）：分析 LLMs 给出的推理解释是否符合逻辑。
解释完整性（Explanation Completeness）：确保推理过程不遗漏关键信息。
解释冗余性（Explanation Redundancy）：评估 LLMs 是否提供了过多或无关的解释。

更进一步，本工作首次对 LLMs 的逻辑推理错误进行了归因分析，提出了五大错误类别：

错误的证据选择（Wrong Evidence Selection）
推理过程中的幻觉（Hallucination in Reasoning）
缺乏推理（No Reasoning）
错误的推理方向（Mistaken Reasoning Perspective）
推理过程中的逻辑错误（Reasoning Process Mistake）

这一细化的错误归因体系，使得我们能够深入理解 LLMs 在逻辑推理任务中失败的根本原因，为未来的模型优化提供了明确方向。

细粒度分析实验

研究团队对 LLMs 在不同推理任务上的表现进行了深入分析，实验结果与分析如下。

1. LLMs是严谨的逻辑推理者吗？

虽然 LLMs 在某些任务上能够给出正确答案，但当同时要求提供完整且正确的解释时，模型的表现明显下降。例如，ChatGPT 在演绎推理任务 EntailmentBank 上的答案正确率达到 83.82%，但其能够提供正确且完整解释的比例仅为 25.88%。发现：LLMs 在溯因推理（abductive reasoning）环境中最擅长保持严谨的推理，而在演绎推理（deductive reasoning）和归纳推理（inductive reasoning）环境中则较为薄弱。

2. LLMs是自知的逻辑推理者吗？

实验结果发现，在某些推理任务中，LLMs 生成的解释存在冗余问题，导致推理过程不够精炼。由于当前的大模型在后训练阶段引入了长思维链的优化，所以推理步骤冗余的现象较为普遍。尤其是在归纳推理上，模型的自知性较差。

3. LLMs存在明显的逻辑性谬误吗？

主动性分析：BARD 在推理过程中表现得最为“主动”，能够在较高比例的任务中进行完整推理。然而，ChatGPT 在某些情况下会表现出“懒惰”行为，仅列出已知事实而非进行有效推理。

方向性选择：实验发现，ChatGPT 虽然在逻辑推理任务中偶尔表现较弱，但在选择正确的推理方向上具有明显优势。在归纳推理任务中，BARD 和 text-davinci-003 更容易从错误方向展开推理，从而导致错误的推理结果。

幻觉问题：幻觉现象在 LLMs 的推理过程中依然存在。例如，在 AbductiveRules 任务中，LLMs 生成了与上下文矛盾的推理内容，其中 BARD 产生幻觉的比例高达 57%。相比之下，ChatGPT 在多数任务中能较好地避免幻觉问题。

全新数据集 NeuLR：消除内容偏见，中立评估逻辑能力

目前的逻辑推理评估数据集往往受到文本内容的影响，使得 LLMs 在推理时可能依赖于训练数据中的知识，而非真正的推理能力。为了解决这一问题，本研究提出了一个全新的中立性逻辑推理数据集——NeuLR，其核心特性包括：

内容中立：避免语言模型因训练数据的影响而产生偏见。
涵盖多种推理类型：包含 3,000 道逻辑推理题，涵盖演绎、归纳和溯因推理。
多跳推理（Multi-hop Reasoning）：样本的推理步数从 1 到 5 不等，以测试 LLMs 在复杂推理任务中的表现。

实验结果表明，NeuLR 数据集能够更加公平地评估 LLMs 的逻辑推理能力，并揭示其在归纳和溯因推理方面的明显短板。

研究发现与未来方向

研究结果表明，尽管当前 LLMs 在逻辑推理方面取得了一定进展，但仍然存在诸多局限性。例如：

归纳推理能力较弱，难以从具体案例中归纳出普遍规律。
在多步推理任务中，推理链条容易断裂，导致答案错误。
由于训练数据的偏见，LLMs 在某些推理任务中倾向于过度自信，并生成幻觉内容。

本研究的系统评估不仅揭示了当前 LLMs 在逻辑推理方面的优势与不足，还为未来 LLMs 的优化方向提供了重要参考。随着 AI 领域的不断发展，我们期待更强大、更可靠的 LLMs 能够真正实现接近人类智能的逻辑推理能力！基于提出的全面的创新性评价体系，本工作也提供了自动化评测脚本，支持一键评测大模型的逻辑推理能力！

OS-Atlas：面向通用 GUI Agent 的基础动作模型

2025-02-25T10:00:00+08:00

论文题目：OS-ATLAS: A Foudation Action Model For Generalist GUI Agents

作者单位：上海AI Lab、上海交通大学、香港大学、MIT

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

项目地址：https://osatlas.github.io

开源地址：https://huggingface.co/OS-Copilot/

1 研究背景与动机

随着大语言模型 (LLM) 和多模态大模型 (VLM) 的发展，许多面向手机、电脑等智能设备的智能体研究开始涌现，研究者们希望在这些场景下通过大模型为智能设备赋能，将冗杂的人工操作转换成口头化的语言表达和自动化的机器执行，达到智能体自动托管的目的。近期，图形用户界面智能体 (GUI Agent) 的开发逐渐成为一个重要方向，研究者们试图以 GUI 为基础范式构建数字化智能体 (Digital Agent)。当前, VLM-based GUI Agent 通常以屏幕截图和任务指令为输入，完成复杂的决策任务。

GUI Agent的核心组件是Action Model：将自然语言指令转化为可执行的动作指令（例如，在屏幕中点击某个位置）。然而，现有的开源GUI Action Models普遍存在两大局限：（1）GUI元素定位（GUI Grounding）能力较弱；（2）无法泛化到OOD场景。这些局限性主要归因于：（i）现有的VLM几乎没有在GUI屏幕截图上进行预训练；（ii）现有训练数据集内容格式各异，影响泛化性。

为了应对上述不足，我们开发了 OS-Atlas系列，专为 GUI Agent 设计的基座动作模型（Foundation Action Model）。该系列模型包含4B和7B两个参数版本。 OS-Atlas主要具备三项重要能力模式（如下图所示）：

GUI Grounding Mode：支持与先进规划器（Planner）协作，完成真实环境中的挑战性任务。
Action Mode：将自然语言指令转化为可执行的动作指令，支持多平台、多系统、多应用场景（Windows、Linux、MacOS、Android、Web）。
Agent Mode：支持用户自主训练，构建专有化的GUI智能体。

除此以外，本工作还开发了跨平台GUI Grounding数据合成工具，并开源了迄今为止最大的GUI Grounding数据集，包含230万张屏幕截图和超过1300万个GUI元素。

2 数据采集与合成

当前 GUI Agent 的训练从数据角度出发，主要面临以下问题: (1) 训练数据可获取规模不足，且各个平台 (Web, Desktop, Mobile) 因数据收集的难度不同而导致数据量分布不均；(2) 缺少针对真实 GUI 任务场景下的高质量合成数据和轨迹数据。

为了解决这些问题，我们搭建了一个多平台的 GUI 数据生成工具库，并通过采集得到的数据构建和开源了一个跨平台的 GUI 语料库（包含超过 1300 万个 GUI 元素）。针对不同平台，我们设计了特定的数据采集来源和方式:

网页端: 先从 Common Crawl 收集大量 URL，再获取每个 URL 包含的网页信息。
桌面端: 分成 Windows, Linux 和 MacOS 三个系统进行构建，使用随机游走（random walk）策略和脚本筛选相结合的方式采集真实操作系统环境下的屏幕截图和动作信息。
手机端: 以 AndroidWorld 环境为基础开发并在环境中采集了大量的 Android 数据。

得益于我们的数据生成工具库，与先前的工作相比，OS-Atlas 获取了更为庞大和多样的 GUI 数据，并且这些数据也在我们后续的训练和实验中被证明了是非常高质量和有效的。

3 模型训练

我们分别使用了InternVL2-4B 和 Qwen2VL-7B-Instruct模型作为初始基座。OS-Atlas 的训练可以分为两个阶段: (1) GUI Grounding 预训练； (2) Action数据微调。

3-1 GUI Grounding 预训练

在 GUI Grounding 预训练阶段，我们整合了现有的开源数据和我们通过搭建工具库生成的数据，并将其组织成了 REG(Referring Expression Grounding) 和 IG(Instruction Grounding) 两种类型。

REG 数据通常容易获取，可表示为<screenshot, element referring expression, element coordinate>三元组，主要包含截图、对元素的直接描述和对应的坐标信息，而 IG 数据则需通过人工或 GPT-4o 等模型标注的方式得到，可表示为<screenshot, instruction, element coordinate>三元组，与 REG 数据最大的不同便是通过一个指令或任务来间接描述需要定位的元素。

这个阶段最终使用了包含约230万张截图(约1350万的元素信息)的图文对数据进行训练，预训练得到的模型记为 OS-Atlas-Base，其拥有出色的 GUI Grounding 能力。

3-2 Action 微调

为了使模型进一步具备Action Mode的能力，我们对 OS-Atlas-Base 进行了 Action Finetuning, 使得其能够根据不同场景中的自然语言指令，输出相应的执行动作。在具体实现中，本工作首先统一了GUI Agent的动作空间（Unify Action Space），解决了跨平台操作定义不一致的问题。在统一的动作空间中，我们定义了通用的动作类型和各平台特有的动作类型，并通过调整运行时的 prompt，以支持OS-Atlas的跨平台使用。基于动作空间的格式定义，本工作收集了现有的训练数据集（如AMEX，AITZ，Mind2Web等），并将它们转化为统一的格式进行微调。最终，得到GUI场景下的基座动作模型OS-Atlas。

4 主要实验结果

4-1 GUI Grounding 能力评测

作为GUI Agent的核心能力之一，评测模型的 GUI Grounding 能力尤为重要。本工作引入当前使用最广泛的的ScreenSpot作为评测基准。为了全面地证明OS-Atlas的优越性，本工作采用了直接推理和接入 GPT-4o Planner 两种评测方式。结果表明，OS-Atlas-Base 大幅提升了先前的SOTA性能。特别地，在单模型直接推理的设定下，OS-Atlas在多平台的平均性能上超越同等量级的 UGround-7B (ICLR’25 Oral) 模型8.32%。

同时，在评测中我们也发现了 Screenspot 测试集中的一些错误数据，我们对此进行了人工纠正并发布了修正版的 Screenspot-V2。

4-2 真实 OS 环境评测

除了静态的Grounding数据集评测之外，我们也引入了更有挑战性的真实场景 OSWorld 对OS-Atlas进行了在线评测。在测试中，我们以 GPT-4o 为 Planner，OS-Atlas 为 Grounder 构建简易 Agent。结果显示，OS-Atlas 将GPT-4o的性能提升超过9%，同时也远超先前的Grounding SOTA 模型 SeeClick。这也应证了 GUI Grounding的能力对提升GUI Agent在下游场景中的执行性能起着至关重要的作用。

4-3 下游 GUI 任务能力

本工作也进行了大量实验来证明模型在 Action Mode 和 Agent Mode 上的巨大使用价值。我们采用了6个流行的下游数据集进行评测，涵盖了Web、Desktop和Mobile的场景。针对 Action Mode，本工作设计了Zero-shot OOD Setting，模型需要直接依据自然语言指令，来生成可执行的动作。由于当前的开源模型不具备零样本泛化的能力，我们将OS-Atlas与GPT-4o进行对比。结果显示，我们的开源基座动作模型 OS-Atlas ，在跨平台的多个数据集中大幅度超越了GPT-4o，解决了当前GUI模型OOD泛化能力不强的局限性。针对 Agent Mode，本工作设计了 Supervised Fine-tuning Setting，通过特定数据集的微调，构建GUI Agent来完成决策任务。与先前的SOTA模型SeeClick对比，OS-Atlas在动作类型匹配（Type）、元素定位（Grounding）和任务成功率（SR）指标上，取得了一致的优越性。尤其对于Omniact网页端和桌面端的场景，OS-Atlas更是领先SeeClick超过20个百分点。

5 分析实验

5-1 数据有效性

为了证明我们数据的有效性，我们从以下两个问题出发进行了实验论证: (5-1-1) 扩大数据量是否会持续提升模型的 GUI Grounding能力？ (5-1-2) 多平台的数据收集以及引入高质量 IG 数据是否有其必要性？

对于(5-1-1), 我们用不同数据规模训练了多个 checkpoint，并使用 IOU 和准确率两个指标进行了测评，发现随着数据规模的不断扩大，模型的 Grounding 能力整体呈现上升趋势。

对于(5-1-2), 我们进行了数据消融实验，设计了三个对照组: (1) 使用全量数据训练; （2）去除 IG 数据进行训练；(3) 去除 IG 数据、手机端数据和桌面端数据进行训练。结果表明组(1)的效果要明显好于 (2) 和 (3)，证明了 IG 数据以及多平台数据对于模型 Grounding 能力是很有必要的，为后续研究提供了参考。

5-2 Scaling Law

在GUI Grounding的预训练实验过程中，我们还发现，下游任务（ScreenSpot）的性能并不是衡量Scaling law的理想指标。这是因为GUI Grounding的评测无法准确反映真实的数据分布，且评估指标过于粗略（正确点击元素并不等价于完全正确地预测坐标）。

因此，为了更加严谨地展示GUI Grounding上的scaling law，我们拟合并绘制了损失函数的下降曲线，如下图。

横轴表示模型训练步骤的数量，每个步骤包含1024个样本，每个样本最多包含15个GUI元素。深蓝色曲线表示平滑的损失轨迹。从图中可以观察到明显的下降趋势，表明持续扩展GUI Grounding预训练数据具有显著潜力。通过我们的scaling law分析，我们估算增加8倍的训练数据可以带来40%的相对损失减少。而将数据扩展64倍，可能会使损失相对减少57%。

6 总结

OS-Atlas 解决了现阶段 GUI Agent 在 Grounding 能力上的不足以及OOD泛化能力上的局限性。本工作开源了OS-Atlas系列基础动作模型，包含4B和7B两个版本。同时，我们也开源了跨平台GUI Grounding数据合成工具，和截至目前最大的GUI Grounding数据集，包含230万张屏幕截图和超过1300万个GUI元素。这些开源成果将会为学术界和工业界构建更加先进的GUI Agent，提供有力帮助。

OCEAN：离线多步推理评估与对齐 (ICLR 2025)

2025-02-20T10:00:00+08:00

随着大型语言模型（LLMs）的迅猛发展，它们在自然语言处理领域展现出了惊人的推理与生成能力。但当前对 LLM 多步推理过程的评估和优化，往往依赖于在线实验或庞大的人力标注，这带来了几个显著挑战：

高昂成本：持续的在线交互与人工打分需要消耗大量资源与时间；
可扩展性不足：复杂多步推理场景中，人工标注往往受到知识背景和专业能力的限制，难以全面覆盖各类推理需求；
标注难度激增：对生成的思维链（Chain-of-Thought）进行细致反馈时，标注工作量呈指数级增长，难以实现高效指导。

为了解决这些问题，来自 UC San Diego、Adobe Research、ECNU 等机构的研究团队在 ICLR 2025 上发表了突破性论文 《OCEAN: Offline Chain-of-thought Evaluation and Alignment in Large Language Models via Knowledge Graph Exploration》。该工作提出了一套全新的离线评估与优化框架——OCEAN，其核心贡献主要包括：

离线推理评估框架：通过利用离线日志数据和逆倾向评分（IPS）等技术，OCEAN 能够在无需实时交互的情况下，精确评估 LLM 多步推理的表现，大幅降低评估成本。
知识图谱自动反馈机制：该方法利用知识图谱中多跳推理路径的自动“口头化”，为 LLM 提供实时的、低成本的反馈信号，从而实现推理路径与外部知识结构的对齐。
策略优化与鲁棒性提升：在理论上证明了基于知识图的 KG-IPS 估计器的无偏性和低方差，通过直接策略优化显著提升了 LLM 的推理准确性和一致性，同时保证模型在其他任务上的通用能力不受影响。

论文链接：https://arxiv.org/abs/2410.23703

OCEAN 框架：离线评估与对齐

OCEAN 全称为 Offline Chain-of-thought Evaluation and Alignment，围绕以下几个核心思路展开：

离线推理评估框架
- 将 LLM 的多步推理过程视为一个马尔可夫决策过程（MDP），无需额外在线数据收集。
- 通过离线的数据日志 + 知识图自动打分，利用逆倾向评分（IPS）等技术，评估目标策略（即 LLM 的思维链生成）在不同推理轨迹上的表现。
知识图谱偏好建模
- 研究团队用一个“小语言模型”来对知识图谱进行探索和建模，得到“知识图偏好策略”。
- 该策略能将知识图上的多跳路径口头化（verbalize）成自然语言，让 LLM 的推理步骤与知识图轨迹进行对比或对齐。
KG-IPS 估计器
- 融入逆倾向评分（IPS）理念，提出 KG-IPS，对“实体 token”由知识图策略进行赋权，对“非实体 token”由基础策略 $\pi_0$ 管理，降低长序列推理导致的方差累积风险。
- 在论文中，作者证明了该估计器的无偏性，并给出了其方差下界与置信区间。
直接策略优化
- 基于离线数据，通过最大化 KG-IPS 估计的策略价值，可以直接使用梯度更新来优化 LLM 的多步推理策略，而无需在线采集新数据。

理论分析

在理论层面，该研究从以下角度对 OCEAN 进行了深入探讨：

KG-IPS 的无偏性：展示了在离线情形下，如何保证估计到的策略价值不会产生系统性偏差；
方差下界与置信区间：通过次高斯（sub-Gaussian）不等式，给出了方差下界与估计误差上限；
最优策略一致性：文中附录进一步分析了实体 token 奖励与非实体奖励之间的协同作用，说明实体部分主导推理过程的关键作用，而非实体部分则作为正则项，不会影响最终最优策略。

性能表现

该研究在多种问答与推理任务上对 OCEAN 进行了广泛验证，包括：

多步推理 (如 HotpotQA, StrategyQA, MuSiQue)
知识密集型推理 (如 ARC, PubMedQA, SciQA)
常识问答 (如 CSQA, OpenBookQA, WinoGrande)

实验亮点：

显著性能提升：在多步推理、知识密集推理等场景，OCEAN 相对于基线和有监督微调（SFT）均表现优异，尤其在 HotpotQA、StrategyQA 等复杂任务上优势明显。下图示意了在多步 QA 中，OCEAN 微调后模型的表现相较于基线模型的提升：
稳健性：与传统有监督微调相比，OCEAN 不会带来“灾难性遗忘”；在常识性任务上，模型依旧能保持或略微提升原本的准确率。
多样性与忠实度：在生成质量评估指标（Self-BLEU, Distinct-2, AlignScore）上，OCEAN 同样能维持或提升文本多样性与“对上下文的忠实度”。

该方法使得LLM生成的思维链更加精准与简洁，下图是一个对比的推理示例

更多分析：在不影响通用能力的前提下提升推理水平

对齐的灵活性：
- 自动反馈：OCEAN 利用知识图谱自动生成反馈信号，无需人工制定大量规则，也不依赖大规模评分，从而适应多种推理场景。
- 领域保留：在面对下游任务变化时，模型依然保留原有领域知识，并在新的推理路径上实现有效对齐，保证整体能力不受影响。
兼容性：
- 与其他微调方式协同 ：论文中还讨论了 OCEAN 与 In-Context Learning、Instruction Tuning 等方法的结合。整体来看，OCEAN 在优化推理策略的同时，不会破坏模型在其他微调范式上的表现，体现了较强的兼容性。
研究启示：
- 低成本、自动化评估：离线评估方法为多步推理任务提供了新的方向，将知识图等外部知识库作为自动反馈源，大幅降低对人工监督的依赖。
- 未来发展潜力：OCEAN 的成功展示有望激发更多类似的离线对齐方法，将 Chain-of-Thought 与外部知识结构相结合，促使 LLM 更好地“走对路径”。

未来展望

OCEAN 在离线评估与优化 LLM 推理能力方面展示了强大的潜力，但也为后续研究留下了若干值得思考的方向：

更多类型知识图探索：如在医疗、法律等垂直领域应用，以检验 OCEAN 的可迁移性；
进一步降低方差与增强安全性：如何在保持不偏的前提下，进一步减小长序列 IPS 的方差累积问题？
协同外部工具：结合检索、计算等外部API，打造更强大的多步推理框架。

结语

OCEAN 框架为大型语言模型提供了一套全新的离线多步推理评估与对齐方案，以知识图为辅助，在保证模型通用能力的同时，使多步推理过程更准确、更可靠。这不仅为 LLM 的推理评估提供了强有力的工具，也为后续研究和应用留下了广阔的发展空间。我们期待更多研究者关注并扩展这项工作，让大型语言模型在认知与推理能力上迈向新的高度。

AgentStore：迈向通专融合的自动化计算机助手

2025-02-15T10:00:00+08:00

论文题目：AgentStore: Scalable Integration of Heterogeneous Agents as Specialized Generalist Computer Assistant

论文地址：https://arxiv.org/abs/2410.18603

项目地址：https://chengyou-jia.github.io/AgentStore-Home/

1 引言

随着操作系统的持续发展和应用程序数量的急剧增加，探索自动化计算机助手已成为一个关键的研究领域。尽管现有的通用智能体能够处理多样的任务，它们往往缺乏完成高度专业化任务（如Task_1）所需的深度知识和精确性。另一方面，专业智能体虽在其领域内表现优异，但其应用范围受限，难以承担超出专业领域的任务（如Task_2）。为了克服这些局限性，本文提出了一种通专融合的自动化计算机助手。该方法旨在拓宽智能体系统在泛化和专业化方面的能力边界，通过整合现有两类智能体的优势，以适应不断变化的操作系统环境和多样化的任务需求。这种方法不仅增强了智能体系统的适应性和灵活性，也为自动化助手技术的未来发展打开了新的可能性。

2 可扩展智能体集成平台：AgentStore

AgentStore是一个创新的可扩展智能体集成平台。它能够动态地整合多种异构智能体，从通用智能体到高度专业化的智能体，以独立或协作的方式执行复杂的操作系统任务。AgentStore的核心特性包括其高度模块化的架构和灵活的智能体管理系统，这些设计使得它能够快速适应操作系统的变化。

AgentStore由两个主要组成部分构成：AgentPool和MetaAgent。AgentPool（见第2-1节）存储具有特定功能的智能体，并定义了添加新智能体的集成协议。MetaAgent（见第2-2节）从AgentPool中选择最合适的智能体，以独立或协作的方式完成任务。这两部分的设计使AgentStore能够灵活应对各种任务需求，提高任务处理的效率和质量。

2-1 AgentPool

AgentPool 是 AgentStore 中所有可用智能体的集合。开发者在创建新智能体并希望将其集成到 AgentStore 时，必须按照标准化的格式注册该智能体的信息。为了确保集成流程的一致性，我们设立了一个集成协议。在注册过程中，开发者需填写预定义表格，详述智能体的功能、限制、适用场景及其功能演示。

所有注册的智能体集合被形式化表示为: $\mathcal{A} = \{(a_1,d_1), (a_2,d_2), ..., (a_n,d_n)\})$

其中每个智能体 $a_i$ 的填写表格构成一个文档 $d_i$。为了构建 AgentStore 的原型，我们创建了 20 个计算机应用智能体和 10 个移动应用智能体，分别处理其所在平台的任务。我们同时采用了手动和自动的智能体生成方法。

手动生成计算机应用智能体

由于计算机应用间的操作不一致，统一的自动化智能体生成仍是一大挑战。因此，我们手动设计了适用于常见应用程序的计算机智能体。通过向基于 GUI 的 MMAgent 和基于 CLI 的 FridayAgent 注入领域特定知识文档，使这些智能体得以进化。这些智能体从单模态到多模态，从开源到闭源，从 GUI 到 CLI，形式各异。这种多样的组合为验证 AgentStore 概念的有效性提供了坚实基础。相关智能体列表如下表所示。

自动生成移动应用智能体

移动应用的操作完全基于 GUI，具有更统一的设计，使我们能够自动化生成领域特定的智能体。遵循 APPAgent 的方法，我们最初开发了一个通用的基于 GUI 的 APPAgent。随后，我们通过自我探索引导其与九个常见移动应用进行导航和互动，最终将其发展为专门的移动平台智能体。这种方法大幅减少了人工工作，确保了为移动应用创建定制智能体的效率。

2-2 MetaAgent with AgentToken

MetaAgent 在 AgentStore 中扮演着至关重要的角色，它负责从 AgentPool 中选择最适合的智能体来独立或协作完成任务。这一过程的核心是 AgentToken 机制，它为智能体的选择和任务分配提供了一种高效可靠的方法。

2-2-1 AgentToken推理

为了提高智能体集成和管理的效率与可扩展性，我们提出了 AgentToken 策略。AgentToken通过在MetaAgent 的词汇表中添加token来注册智能体。添加的token被参数化为嵌入矩阵 $W{\mathcal{A}} \in \mathbb{R}^{

\mathcal{A}

\times d}$，并附加到原始词表头$W{\nu} \in \mathbb{R}^{

\mathcal{V}

\times d}$。假设智能体token $W_{\mathcal{A}}$ 已经训练并可用，连接后的结果形成了 MetaAgent 的新语言模型头。MetaAgent 预测下一个token的概率为：

$P_M(t_i | t_{<i}) = \text{softmax}([W_{\nu}; W_{\mathcal{A}}] \cdot h_{i-1}),$ 其中下一个token可以是词token或智能体token，即$t_i \in \mathcal{V} \cup \mathcal{A}$。这样，MetaAgent 通过以下两种主要功能实现高效的智能体管理：

MetaAgent as Router

MetaAgent 作为一个高效的Router，通过最大化条件概率来预测最可能的下一个token： $t_i^* = \operatorname{arg\,max}_{t \in \mathcal{V} \cup \mathcal{A}} \left(P_{M}(t_i | t_{<i}) \right).$ 一旦预测出智能体token，即 $t_i^* \in \mathcal{A}$，MetaAgent 停止解码，并调用相应的智能体来执行任务。

MetaAgent as Manager

在处理需要多智能体协作的复杂任务时，MetaAgent 表现出哈希Manager的功能。训练过的智能体token常出现在下一个token预测的Top-K候选中，使 MetaAgent 能够预测对任务最相关的 $K$ 个智能体： $T_i^* = \operatorname{TopK}_{t \in \mathcal{A}} \left( P_M(t_i | t_{<i}),\ K \right),\\$ 这些预测token代表与此任务最相关的 $K$ 个智能体。MetaAgent 则通过使用包含这些选定智能体的在上下文文档的新提示，指导如何为复杂任务生成子任务并将其分配给相应的智能体。这种设计与哈希方法类似，将任意大小的输入转换为固定大小的输出，以便进行有效的检索和任务分配。

2-2-2 AgentToken训练

为了提高智能体的适应性并减轻训练负担，我们采用了自我指导（self-instruct）的自动化过程来训练 AgentToken。这一过程主要涉及智能体token $W_{\mathcal{A}}$ 的训练，这些token是系统中唯一需要训练的参数。然而，训练这些智能体token需要大量的任务描述和初始操作系统状态的演示，但我们的场景中，开发者仅提供有关智能体的文档，无法提供大量的演示数据。

为了解决这个问题，我们设计了一种迭代算法，这个算法从有限的原始演示开始，引导生成额外的演示数据。首先，我们使用现有的演示和智能体描述$S_i, c_i$来激活 MetaAgent，生成一组新的演示： $S'_i = M(S_i, c_i),$ 然后，为了确保生成输出的质量，我们应用 BERTScore 来评估新生成的输出，确保它们的一致性和多样性： $\tau_1 \leq \text{BETRScore}(y_k, y_j) \leq \tau_2, \\ \forall y_k, y_j \in S_i \cup S_i^{new} \text{ and } k \neq j.$ 最后，我们使用贪婪算法迭代筛选生成的演示，最终得到一组经过精炼的演示，这组演示在相似性和多样性之间达到平衡，满足预定的标准。算法细节展示如下：

整个过程是自动化的，MetaAgent 将持续生成额外的示例，直到收集到足够的演示以满足训练需求。在训练阶段，每个任务描述和初始状态都作为输入前缀，特殊智能体token作为预测的下一个token。这种方法不仅简化了训练流程，还确保了语言模型在智能体token被激活时不受影响，从而可以无缝地应用到不同的智能体调用中，极大地提高了系统的灵活性和扩展性。

3 主要实验

3-1 实验设定

为了评估 AgentStore 的有效性和多功能性，我们在多种任务上进行了全面的实验。首先，我们在三个实际操作系统基准测试中展示了其卓越的性能，这些测试验证了 AgentStore 在实际环境中的应用效果。我们还提供了一些实际运行案例进行定性分析，通过这些案例展示 AgentStore 在解决复杂任务时的策略和效果。

3-2 OSworld Benchmark

上表展示了我们的方法与当前最优的通用智能体在 OSworld 上的性能比较。虽然更先进的基础模型可以提高性能（例如，GPT-4o 在CogAgent中表现优于 GogVLM），但即便是最好的基础模型仍面临重大挑战。值得注意的是，这些方法不仅整体表现不佳，而且在特定任务类别中还存在明显的弱点。例如，MMAgent 和 CRADLE在处理 Excel 计算任务时因缺乏知识和操作能力而表现不佳，而基于 CLI 的Friday 和 Open-Interpreter 在执行 Chrome 或 Thunderbird 等 GUI 操作任务时也未能有效执行。

相比之下，AgentStore 通过集成多种专业智能体克服了这些限制，每个智能体被指派执行特定擅长的软件和操作。 “AgentStore(GT)” 指的是每个任务都被分配给最合适的智能体，代表了当前 AgentStore 实现的性能上限。如数据所示，使用专业智能体在其各自领域处理任务，使得整个系统在所有领域中都没有显著的性能短板。这强调了多样化能力的重要性。

3-3 OSWorld-Multi Benchmark

我们基于 OSWorld 开发了一个全新的基准 OSWorld-Multi，包括超过 100 个需要多个智能体协作的多样化任务。这个新提出的基准测试使我们能够在真实世界环境中评估任务分解和子任务处理的准确性。此外，我们提出了三个指标：AgentMatch、SubtaskAcc 和 ExecutionAcc，分别用来测量多智能体预测的准确性、子任务分解的准确性以及执行成功率。

如下表所示，单一通用智能体 MMAgent 在这个基准测试中表现不佳，这是因为它缺乏智能体预测和任务分解能力。由于智能体组合的无限可能性，Fine-Tuning方法在此场景中不适用，因为其无法预先组织训练所需的数据。此外，尽管 In-context learning 方法在某种程度上是有效的，过长的上下文和庞大的组合空间的限制也导致了次优的结果。相比之下，AgentToken 利用其固有的任务感知能力，显著缩小了选择的智能体范围。它在所有指标上展示了出色的性能。

3-4 APPAgent Benchmark

我们还使用了APPAgent基准测试来验证 AgentStore 是否可以泛化到移动操作系统平台。该基准包括 9 个流行的移动应用程序，每个应用程序都服务于不同的目的，共同构成了 45 个任务。

下表比较了 AgentStore 与 APPAgent单一通用智能体的性能。如数据所示，通用智能体由于缺乏对每个应用的具体知识，在许多应用中的表现都不尽人意。相比之下，AgentStore 构建了针对各自应用程序的专用智能体，有效解决了某些应用中的性能不足，并显示出从 26.7% 到 57.8% 的显著性能提升。这突显了 AgentStore 概念适用于其他操作系统平台的可能性。

4 可视化运行实例

在下图中，我们提供了运行示例，以展示 AgentStore 如何增强整个系统的能力。在任务一中，智能体的任务是设置自动邮件转发，这涉及频繁的 GUI 交互并需要理解 Thunderbird 设置。MetaAgent 指派专业的 MailAgent 来处理这一任务，它精确地导航配置转发设置的具体步骤。特别是在第三步中，它执行一系列操作以准确填写所需的表格和选项，展示了其在邮件领域的高级理解能力。同样，在任务二中，需要处理复杂的电子表格处理，MetaAgent 从 AgentPool 中选择 SheetAgent 来处理任务，避免了过于复杂的 GUI 交互。SheetAgent 掌握了 openpyxl 库的知识，并深入理解操作表格所需的步骤，有效完成了这一任务。此外，任务三展示了一个需要多个智能体协作的系统级任务。MetaAgent 成功地将任务分解为子任务，并指派合适的智能体完成每一个子任务。这些案例突出了 AgentStore 在处理领域特定和系统级任务方面的专业通才能力。

Corex：通过多模型协作增强推理能力 (COLM 2024)

2025-01-15T10:00:00+08:00

论文题目：Corex: Pushing the Boundaries of Complex Reasoning through Multi-Model Collaboration

论文地址：https://openreview.net/forum?id=7BCmIWVT0V

项目地址：https://github.com/QiushiSun/Corex

1 引言

大语言模型（LLMs）通过超大规模的训练数据展示了强大的语言理解能力，并成功推动了许多NLP任务的性能飞跃。然而，尽管这些大模型在执行典型任务时表现卓越，但它们在复杂推理任务中的表现仍受到诸多限制，如推理链（思维链）的累积错误以及缺乏灵活性。

本文提出了一种名为 Corex 的框架，利用Multi-Model Collaboration（多模型协作），突破单一模型的推理瓶颈，通过三种解推理问题的模式（Discuss、Review 和 Retrieve）有效提高了推理的准确性，事实性（Factuality）和忠实性（Faithfulness）。实验结果表明，Corex 在多个基准数据集上显著优于现有的baselines的方法。

2 背景与动机

单模型解推理任务的局限性。在Chain-of-Thought (CoT) prompting出现后，通过生成一系列中间步骤引导模型得出最终答案成为了解推理任务的主流，相比仅生成“答案”的提示策略表现更好。此后，研究者又提出了多种改进方法，如采样更多推理链或加入code来辅助推理（详见baselines）。

尽管这些方法在一定程度上都改进了推理性能，但仍然局限于LLMs是一个静态的”Black Box”，即模型完全依赖其Internal Representation（内部表征）生成答案，这种方式容易导致不可靠的结果。此外，单纯依赖解码策略和curated prompting也无法完全解决复杂推理任务。

其中典型的错误可以被总结为以下几类，即（1）模型计算错误（2）模型理解错误（3）代码生成错误

因此，本文提出了Corex，一个受人类启发的模型协作策略集合，通过多模型协作激发复杂任务的推理能力。为促进模型之间的协同作用，我们首先为不同的LLM Agents在推理过程中分配角色，随后设计了多种协作范式来解决问题。这种基于集体智能的方法旨在克服当前推理领域的主要挑战，如下图所示。

具体而言，Corex将若干个LLM配置为一组reasoning agents，并拥有如下多模型协作范式：

Discuss 模式：通过模型间的群组讨论，有效提高推理链的事实性（factuality）和多样性（Diversity），减少累计错误和幻觉。
Review 模式：模型间对推理链或生成的代码进行review，以确保生成内容的正确性，同时支持潜在的改进。
Retrieve 模式：通过对多个推理链进行评分和排序，帮助模型从中选择最可信（faithful）的答案，提高最终结果的可靠性。

3 Corex：多模型协作推理

3-1 基本设定

假设有一组基于LLM agents $A_1,A_2,…,A_n$ 参与多模型协作。在面对一个问题 $q$ 时，每个agent $A_i$ 会生成相应的推理链 $c_i$ 和预测结果 $p_i$。这些推理链和预测结果将作为协作过程的基础，分别用于不同模式的任务分工和协作优化。以下为Corex中的三种协作模式解读：

3-2 Discuss

模型间的信息交换能够显著提升推理的准确性。在 Discuss 模式中，Corex 将基于LLM的智能体随机分为两组并指定一个Judge模型 $A_j $ 负责最终评估。讨论过程由多个轮次组成，最多进行 T 轮交互。

在每轮交互 $t (t=1, 2, \dots, T)$ 中，各组agents通过迭代讨论不断优化推理链 $c_i^t$ 和预测结果 $p_i^t$。这种动态交互机制允许模型针对问题 $q$ 持续调整和改进观点。

Discuss mode的工作流程如下：

组内优化：每轮结束时，蓝队和绿队分别提交优化后的预测结果 $p_{\text{blue}}^t$ 和 $p_{\text{green}}^t$。
结果一致性检查：如果两组在整个过程中始终保持一致（即 $p_{\text{blue}}^t = p_{\text{green}}^t$ ），讨论顺利结束，直接得出结论。
Judge评估：若两组预测结果存在分歧，每轮的所有输出（包括推理链和预测结果）都会交由裁判 A_j 审查。裁判通过决策过程 h，综合评估蓝队和绿队在各轮讨论中的推理链 $c_{\text{blue}}^t$、$c_{\text{green}}^t$ 以及预测结果 $p_{\text{blue}}^t$、$p_{\text{green}}^t$，最终作出决策。

先前的方法往往依赖一组模型直接进行相互Debate，这容易导致（1）强模型主导了整个交互的过程，覆盖了其他模型能为解决问题所作出的贡献（2）错误的consensus在交互过程中被传播；而Corex的Discuss则通过分组 + Judge的方式，避免/缓解了上述问题。

3-3 Review

在推理任务中，CoT和PAL是两种行之有效的方法，但它们各有优劣：CoT方法以自然语言为基础，具有通用性和解释清晰的优势，但存在以下局限：

累积误差：推理链中的错误会逐步放大并影响最终结果。
输出瓶颈：文本质量无法通过进一步优化提示词显著提升。

PAL方法通过程序生成保证了计算的准确性，但也面临以下问题：

问题误解：LLMs可能误解问题，生成技术上正确但逻辑上错误的程序。
代码错误：生成的代码可能存在问题，例如引用未定义变量或“除零”等错误。

为了解决这些问题，Corex引入了Review模式，利用多智能体协作对推理链和代码进行逐步review与 optimization。这一模式受LLMs互评机制以及软件工程中协作编码实践的启发。除了使用NL推理链，还可以结合代码生成来辅助推理。

Review mode的工作流程如下：

初始生成：随机选定一个Agent A_p 作为主模型，负责对问题 $q$ 构建初始推理链、预测答案和生成代码（如果需要）。其初始解决方案集合表示为：$S_{p}^{(0)} = {a_p, c_p, m_p}$ 其中，$a_p$、$c_p$、$m_p$ 分别表示答案、推理链和代码。

逐轮review：其他Agents依次作为审查者，对主模型 A_p 或之前的审查者修改后的NL推理链和生成的代码进行严格审查。每个审查者基于前一轮的反馈和结果提出改进，推动解决方案的逐步优化。

Review过程可形式化表示为：$S_{p}^{(i+1)} = R_i(S_{p}^{(i)}, F_i)$，其中，$R_i$ 表示第 $i$ 轮的审查结果，$F_i$ 是该轮反馈，$S_{p}^{(i+1)}$ 是改进后的解决方案集合。

最终输出：审查完成后，采用最后一轮的解决方案集合 $S_{p}^{(n-1)}$。

对于推理任务，最终答案为 $a_{p}^{(n-1)}$。
对于涉及代码生成的任务，执行修订后的代码版本 $m_{p}^{(n-1)}$ 来得出最终结果。

此模式中，每轮审查都基于前一轮反馈，逐步改进对一个推理问题的解决方案。通过多轮交互修复推理链和代码中的累积错误。

3-4 Retrieve

Retrieve模式专注于通过模型间的协作，识别推理过程中最可信的答案。相比于投票机制，Retrieve模式有效解决了以下两个主要问题：

错误干扰：正确答案可能被大量错误答案掩盖，从而影响最终结果。
计算成本高：尽管多数投票机制在性能上有所提升，但其计算成本随着采样推理链数量的增加而增长，且最终会达到性能的饱和点。

这些问题的根源在于多数投票方法的局限性：它们只关注预测结果，而忽视了推理链的可信度。为了解决这些不足，Retrieve模式被设计为一种全新的方法，用于评估答案是否能够被推理过程中的内容（解释）支持。

Retrieve mode的工作流程如下：

Candidates生成

针对查询 q，随机选定一个Agent $A_r$ 作为retriever，其余Agents ${A_1, A_2, \ldots, A_{n-1}}$ 独立解决问题。
每个Agent生成其推理链 $c_i$ 和对应的预测结果 $p_i$，构成候选池 $\mathcal{P} = {(c_i, p_i)}_{i=1}^{n-1}$。

可信度评估

Retriever A_r 对候选池中的每组推理链-预测结果对 $(c_i, p_i)$ 进行审查，评估推理链 $c_i$ 与预测结果 $p_i$ 之间的可信度。
每个candidate分配一个范围在 [0,1] 的confidence $s_i$，表示为：

$s_i = f_r(c_i, p_i)$

其中，$f_r$ 表示retriever的评估过程。

答案选择：从候选池中选择可信度最高的推理链-预测对 $(c^, p^)$，作为问题 $q$ 的最终答案。

Retrieve模式的特点与优势

推理链与答案的高一致性：Retrieve模式确保选出的答案能够与推理链内容高度一致，解决了多数投票中错误答案占优的问题。
高效且独立：不同于依赖序列对数概率的文本质量评估方法，Retrieve模式完全基于模型间的交互，无需依赖额外的外部参考资源。

4 实验

4-1 实验设置

实验主要依托GPT-3.5-Turbo模型（以及分析实验中的GPT-4和Claude），在大量的主流benchmarks上进行了测试。

4-2 Baselines

我们将Corex与几种广泛使用的强基线方法进行了比较：

Chain-of-Thought prompting (CoT) ：经典baseline方法
Self-Consistency (CoT-SC) ：采样多个推理链的结果，选择一致性最高的答案作为最终结果
Complexity-based consistency (ComplexCoT) ：从具有更高推理复杂性的候选答案中选择多数结果
Program-aided language model (PAL/PoT) ：利用LLMs进行代码生成作为中间推理步骤，并将计算任务offload到Python解释器执行，从而减少计算误差。

4-3 主实验

Math Reasoning. 下表展示了Corex在不同难度math reasoning任务上的表现。总体来看，Corex相比大多数baselines取得了显著的性能提升。即使只使用5个reasoning agents，Corex的表现也优于使用10条推理链的CoT-SC方法。此外，Corex的任务无关性使其能通过Reviewing + Code Generation来应对像GSM-Hard这样的高度复杂计算任务。而对于较低复杂度的问题，Retrieve模式能够选择出优于多数投票机制的答案。

Commonsense Reasoning. 下表展示了Corex在commonsense / factual reasoning任务中的表现。由于这类任务的性质无法直接转换为计算任务，Review模式在此类任务中仅使用NL作为推理链。从实验中可以看到，不同模式的协作都对性能提升有明显贡献。

相比于ComplexCoT，Corex可以在StrategyQA任务上获得6%的提升。方法层面来看，Discuss mode带来的提升最大，也侧面反映了模型交互可以减少unfactual信息的传递。

Symbolic Reasoning. 以下展示了Corex在Symbolic reasoning任务中的表现。实验结果表明，多模型协作在Big-Bench任务中显著优于大多数现有baselines。需要注意的是：(1) CoT-SC方法在处理Repeat Copy任务时难以确保一致的输出，而通过整合code generation来协作，Corex成功达到了更高的准确率；(2) 在Counting任务中，相较于多数投票，Review mode和Retrieve mode能够做出更为明智的答案选择。

Table Reasoning. 最后，Corex在FinQA和ConvFinQA这两个半结构化推理（表格推理）任务上的表现。可以观察到，这两个任务需要同时理解异构信息和执行复杂计算，在此类任务中，CoT-SC等方法的性能提升有限。然而，Corex通过多种协作模式显著提高了性能。

此外，本文还在后续分析中补充了 TAT-QA 的性能，详见原文。总体来说，在18个benchmarks的广泛实验中，Corex的Discuss mode在处理基于事实知识的任务时表现良好；对于复杂的数学推理和计数任务，Review模式（结合code generation）能够有效减少推理链中的错误并修复不正确的代码。而在一般场景下，Retrieve mode持续地对性能提升起到了积极作用。本文的附录中还添加了更多（1）基于开源模型的实验（2）错误类型分析等。

5 分析实验

本文还进行了大量分析实验，来探讨多模型合作方法中（1）Corex内部的模型行为（2）与其他方法的比较（3）使用不同LLM作为backbones进行协作。

5-1 Corex策略分析

Discuss轮次分析. 我们首先研究了Corex的Discuss mode在五个任务中的交互轮次分布情况，如下图7所示。对于大多数问题，每个sub-group能够迅速达成一致。然而，对于难以快速达成共识的问题，Corex允许LLMs进行更深入的讨论。例如ConvFinQA任务中，有超过10%的问题需要超过3轮交互才能达成共识。尽管仅有一小部分问题需要较多轮次的讨论，但这种深入的互动过程为Judge的决策提供了良好的依据。

Review性能增益分析. 我们还分析了Review mode中每轮审查对特定任务性能提升的贡献。如图8所示，我们对Repeat Copy和GSM8K任务（Review + Code模式）以及BoolQ和Penguin任务（Review + NL模式）进行了分析。结果表明，每轮审查通常都会带来性能的逐步提升。然而，在某些情况下，性能可能会出现小幅波动。这种现象表明，尽管整体上Review模式能够显著改进任务表现，但具体的增益效果可能受任务特性和模型生成的中间输出质量的影响。

5-2 多模型协作方法比较与融合

与其他协作推理方法的比较. 为了对比当前在推理任务中使用多模型协作的方法（详见论文第2节），我们选择了两种具有代表性的研究进行性能比较：

Multi-Agent Debate (MAD) ：多个模型分别表达自己的观点，由一个Judge管理辩论过程并最终决定解决方案。
Exchange of Thought (EoT) ：一种基于网络拓扑结构的跨模型通信策略来增强推理能力的方法。

如表5所示，Corex在不同模式下的表现始终优于这两种创新性方法。这表明，Corex的协作框架不仅能够整合多模型的优势，还可以在性能和效率上超越现有的协作方法。

各策略间的协同效应. 在主要实验中，为了公平对比，我们分别独立评估了Corex的每种模式。接下来，我们探讨将不同模式结合使用是否能够进一步提升性能。我们采用了一种相对简单且计算成本适中的方法：在其他模式协作后应用Review模式，同时将Self-Refine 作为baseline，用于验证协作所带来的额外增益。

如图6所示，我们发现以下几点：

任何形式的协作都优于单纯的Self-Refine，表明多模型协作在推理任务中具有明显优势。
结合不同Corex模式的协作通常能进一步提升性能，尤其是在处理LLMs的弱项（如数值计算任务）时，这种协作效果尤为显著。

以上结果表明，各模式间的协同作用可以更有效地克服单一模式的局限性，为复杂任务的解决提供更好的支持。

5-3 不同LLMs协作

不同LLMs作为Judge时的性能变化. Corex的reasoning agents可以基于多种不同的LLM。在本部分中，我们先讨论在Discuss mode中使用不同LLMs作为Judge时的性能表现。如下图9所示，我们使用GPT-3.5-Turbo作为candidates，并分析了不同模型作为Judge对任务表现的影响。观察表明，Judge的能力与任务性能正相关，尤其是在任务复杂度较高的情况下更为明显。这可以归因于裁判在Corex中的关键角色——不仅需要理解任务问题，还需要评估双方的推理过程并作出决策。

使用不同LLMs作为Retriever的影响. 在Retrieve mode中，retriever的角色可以由不同的LLM担任。我们探讨了选择不同LLM作为retriever对性能的影响（见图10）。与Discuss mode不同，分析结果显示retriever的模型能力对性能的影响较小。由于性能上限由候选答案的质量决定，不同LLMs作为retriever在任务（如ARC-c）上的表现差异甚微。值得注意的是，我们的研究表明，即使不使用特别强大的模型作为retriever，也能取得令人满意的结果。

5-4 效费比分析

最后，本文对 Corex vs 不同CoT模式的效费比进行了分析。

从上图所示的AddSub任务分析可以看出，Corex的三种协作模式在性能上始终能够匹敌或超越其他强baselisne。更为重要的是，与使用多数投票机制的方法相比，Corex的计算成本大幅降低。Corex在实现相同性能的情况下，其资源消耗仅为其他策略的5%-10%。

除了上述分析实验外，原文中还提供了更多对比和分析实验，并细究了推理问题的错误原因等，为后续研究提供了许多insights。

6 结论

作为Multi Agent的早期工作，Corex为基于LLMs的智能体生态系统提供了初步探索。通过激发LLMs之间的协同作用，Corex能够通过多种协作模式提升各项推理性能。它还证明了（1）对于不同类型的推理问题，多模型协同工作比传统单模型推理/多推理链独立推理能有更好的效果。（2）多模型推理可以通过更少的计算成本达到采样大量推理链才能达到的任务性能。（3）Corex的任务无关性使得其具有潜力被adapt到新的任务和场景上。我们希望这项工作能为复杂推理和集体智能提供新的视角和发展方向。

ChatGen：自动化文生图系统

2024-11-25T10:00:00+08:00

论文题目：ChatGen: Automatic Text-to-Image Generation From FreeStyle Chatting

论文地址：https://arxiv.org/abs/2411.17176

项目地址：https://chengyou-jia.github.io/ChatGen-Home/

1 引言

文本到图像（T2I）生成模型因其图像的高质量和文本对齐能力而受到极大关注。尽管开源模型的发展为用户提供了广泛的定制化选择，但同时也给普通用户带来了显著的学习挑战。用户在创建具有特定需求的图像时，常常需要经历多个复杂且不确定的步骤，例如制定合适的提示词、选择合适的模型及配置特定参数，整个过程既繁琐又耗时。为了解决这一问题，我们提出了一个全新的挑战：能否自动化文生图过程中的繁琐步骤，使用户仅需通过聊天方式简单描述其需求，便能轻松获得所需图像？

2 自动化T2I生成基准：ChatGenBench

我们首先提出了一个专为自动化T2I生成任务设计的新型基准数据集。它包含了大量高质量的配对数据，这些数据覆盖了多样化的自由风格用户输入，使得研究者能够全面评估自动化T2I模型在各个步骤中的性能。每个数据对包括用户的自由风格聊天输入、经过精炼的提示词、适当的模型选择，以及最优的参数配置，为自动化T2I模型的评估提供了一个步骤化的评估路径。

该数据集的构建如下图所示，主要涉及两个关键部分：高质量人类示范收集和使用大语言模型驱动的角色扮演来模拟用户输入。高质量人类示范收集确保了数据集中包含的每个示例都能够代表真实世界中高效和准确的T2I生成需求。这些示范通过严格的质量控制流程筛选，确保数据的可靠性和有效性。而LLM驱动的角色扮演则通过模拟各种日常生活中的角色，如学生、医生和教授等，将这些示范转换为自由风格的聊天输入。这种方法显著增强了数据的多样性和现实感，为自动化T2I模型提供了丰富和真实的训练材料。

此外，ChatGenBench集成了各种类型的数据，包括单一输入、多模态输入，以及具有对话历史的输入，以模拟实际应用场景。这种设计不仅增加了数据集的实用价值，而且通过精确的标定和系统化的分析，揭示了潜在的自动化瓶颈，从而推动了自动T2I技术的发展。通过这一基准测试，研究人员可以更深入地理解和优化自动化T2I生成过程，从而推动自动化图像生成技术向前发展。比起之前的数据集基准，ChatGenBench的优势总结如下：

3 多阶段进化训练策略：ChatGen-Evo

该研究的目标是训练一个能够处理自由风格用户输入$c$并生成图像生成所需的各个组成部分（提示词$p$、模型$m$和参数$a$）的模型，从而实现自动化的文本到图像（T2I）转换。为此，我们提出了ChatGen-Evo，采用一种创新的多阶段进化训练策略，旨在逐步培养模型完成自动文本到图像（T2I）生成所需的关键技能。这种方法通过将整个生成任务分解为几个清晰定义的阶段，每个阶段都专注于培养模型的一个特定能力，从而实现高效且目标明确的训练。

3-1 SFT实现提示词改写

在此阶段，模型首先接受训练，以便从用户的自由风格输入中生成高质量的提示词。这一过程利用监督式微调（SFT）技术，确保生成的提示词能够准确反映用户的需求。

\[L_{sft}^{stage1} = -\sum_{t} \log P_{\pi}(p \mid c', *_{<t}).\]

3-2 ModelToken实现模型选择

经过初步的训练后，模型在第二阶段学习如何根据生成的提示词选择最合适的T2I生成模型。这一阶段引入了“模型令牌”（ModelToken）策略，通过扩展语言模型的词汇表来包含特定的模型令牌，使模型能够有效地识别并选择适当的图像生成模型。

ModelToken训练

在训练过程中，用户输入 $c$ 和提示词$p$被拼接作为前缀，特殊的模型令牌被添加作为下一个词预测的真值。训练目标是：

\[L(W_{\mathcal{M}}) = -\log P_{\pi}(\texttt{<Model\_i>} | c,p)\]

模型挑选推理

一旦ModelToken训练完成，推理过程将模型令牌和原始词令牌进行拼接，形成多模态大语言模型（MLLM）的新语言模型头。通过这种方式，MLLM使用以下概率预测下一个词令牌:

\[P_{\pi}(m |c,p) = \text{softmax}([W_{\nu}; W_{\mathcal{M}}] \cdot h_{i-1})\]

一旦预测出模型令牌，多模态大语言模型（MLLM）将停止解码，并选择相应的模型$m$。此外，还会加载模型的描述和示例等信息以供后续使用。在第二阶段之后，模型不仅保留了其提示词生成的能力，还学会了模型选择能力。

3-3 上下文学习实现参数配置

在成功选择模型后，最后一个阶段聚焦于根据所选模型和生成的提示词配置生成参数。这一阶段不再需要传统的训练，而是利用在上下文中的示范来引导模型完成参数的正确配置。

\[a = M(c, p, D(m))\]

由于在前期阶段已经获取了相关模型和提示词，这种方法释放了上下文空间，使得可以进行更广泛的示例。此外，这种无需训练的方法避免了干扰前两个阶段已经训练好的模型。

4 主要实验

4-1 实验设定

在本研究中，本文通过在新型基准数据集ChatGenBench上进行广泛的实验来全面评估了自动文本到图像（T2I）生成模型的性能。我们首先比较了多阶段进化策略的ChatGen-Evo模型与基线模型。接着，我们进行了深入的消融研究，探讨了每个训练阶段对最终图像生成质量的具体影响，并通过逐步评估指标如Prompt BERTScore、模型选择精度和参数配置精度来验证模型性能。此外，我们还利用HPS v2、ImageReward、FID和CLIP Score等多种度量标准对生成图像的质量进行了综合评估。

4-2 主要实验结果

主表展示了ChatGen-Evo与其他Baseline模型的定量结果比较。总体而言，ChatGen-Evo在所有指标上，包括逐步和最终图像质量评估中，显著优于其他方法。具体来说，Baseline的低性能突显了有效的提示词重写和多模型选择的重要性，强调了专门的自动文本到图像（T2I）方法的必要性。此外，使用逐渐增大的参数规模（从2B到8B）对多模态大语言模型（MLLMs）进行微调，可以稳步提升性能。值得注意的是，尽管使用的参数规模仅为2B，ChatGen-Evo的性能与使用8B参数的ChatGen-Base相当。

4-3 人工评估

我们通过进行成对比较的用户研究，进一步评估ChatGen-Base(8B)和ChatGen-Evo(2B)。参与者将看到两幅从相同输入生成的图像：一幅由ChatGen-Base生成，另一幅由ChatGen-Evo生成。参与者的任务是选择更符合给定输入的图像质量和相关性的图像。我们为监督设置抽样了2000对图像，为少样本设置抽样了1000对。如图所示，人类评估结果与定量指标一致，突出显示了ChatGen-Evo在图像质量和相关性方面均优于ChatGen-Base。此外，在少样本设置中，ChatGen-Evo展示出更高的胜率，证明了ChatGen在数据稀缺场景下的有效性。

4-4 消融实验

我们在ChatGenBench上进行了消融实验，以评估各个步骤对最终性能的贡献，同时为其他步骤提供了真值结果作为对比。实验表明，不同方法在提示词生成方面与经人工验证的提示相比存在显著差距，突显了提示词重写的复杂性。正确的模型选择和参数配置可以显著提升性能，尤其是在基线方法中。此外，提示词的变化对最终结果有重大影响，凸显了其在自动T2I中的关键作用。在模型选择方面，当提供精心制作的提示词和参数时，ChatGen-Evo显示出显著的性能提升，从32.8％提升到55.3％，验证了提示质量对模型选择精度的强烈影响。参数配置方面，ChatGen-Evo在提供高质量提示词和适当的模型选择后，展示出显著的性能改进，配置精度从53.7％提高到87.1％，统一评分从65.9提高到70.3。这些发现表明，早期步骤的结果显著影响后续步骤的预测，因此，探索更多的推理方法以推进自动化T2I是一个有前景的研究方向。

5 可视化结果展示

5-1 定性比较

下图展示了不同方法生成的图像示例。从第一行可以明显看出，ChatGen-Evo能够理解用户需求并识别合适的模型来生成风格匹配的图像。第二行展示了基于多模态用户输入的结果，其中ChatGen-Evo表现出对参考图像的深入理解，并保留了更多细节以生成更精细的输出。第三行则展示了ChatGen-Evo处理历史数据的能力，确保每个步骤都能继承之前的风格，同时根据用户需求进行适当的修改。这些展示不仅证明了ChatGen-Evo在理解和生成任务方面的高效性，也展示了其在不同类型输入处理上的灵活性和高适应性。

5-2 阶段输出展示

下图展示了ChatGen-Evo的逐步输出和最终图像。可以观察到，ChatGen-Evo能够根据用户的自由风格输入有效地重写高质量的专业提示词。此外，ChatGen-Evo选择适合的模型以匹配用户所希望的风格或特定角色。最后，它生成恰当的参数配置，以确保生成图像的高质量。通过精心设计的逐步输出产生的这些高质量图像，展示了自动文本到图像（Automatic T2I）的价值。它免去了用户进行繁琐步骤的负担，直接从他们的自由风格输入自动化地生成所需的图像。

5-3 与商用模型的比较

我们将我们的方法与先进的商业模型DALL-E 3的图像质量进行了比较。虽然DALL-E能够生成高质量的图像，但其风格主要局限于单一类型（动漫风格）。这一局限源于它依赖单一模型，无法完全适应多样化和个性化的风格。这突显了我们方法的价值，尤其是在需要真实风格或其他个性化输出的场景中，我们的方法表现得更为出色。

LD-DPO：基于 DPO 的长度脱敏偏好优化算法

2024-11-05T10:00:00+08:00

论文题目：Length Desensitization in Direct Preference Optimization

论文地址：https://arxiv.org/abs/2409.06411

1 引言

大语言模型（Large Language Model, LLM）在自然语言处理（Natural Language Processing, NLP）领域已取得显著成就，不仅能够生成与人类相似的文本，还能理解复杂的上下文关系，并完成多样化的下游语言任务。为了确保模型行为符合人类的价值观及偏好，通过人类反馈进行的学习是至关重要的，它有助于提升模型的实用性、诚实性及安全性。直接偏好优化（Direct Preference Optimization, DPO）作为一种常用的偏好学习策略，与传统基于人类反馈的强化学习算法（Reinforcement Learning from Human Feedback，RLHF）不同，前者通过采用隐式奖励机制替代在线奖励模型（Reward Modeling, RM），从而简化训练过程并增强训练稳定性。

然而，经由一系列实证研究揭示，DPO方法在优化过程中倾向于过度强调文本的丰富性，导致模型输出过于冗长，进而影响了模型在部分下游任务（逻辑推理，封闭知识问答等）中的性能以及最终用户的体验。鉴于此，本文旨在探讨DPO优化目标中的潜在局限性，指出用于拟合隐式奖励的模型预测概率$\pi(y

x)$与输入序列长度之间存在着密切关联，即DPO算法存在无法避免的长度敏感性。基于上述发现，文中提出了一种名为长度脱敏直接偏好优化（Length Desensitized Direct Preference Optimization, LD-DPO）的偏好优化方法，以解决DPO算法存在的长度敏感性，鼓励模型学习长度偏好以外的真实人类偏好。

实验结果表明，在使用Llama2-13B、Llama3-8B及Qwen2-7B两类不同设置（Base版本和Instruct版本）的背景下，于MT-Bench与AlpacaEval 2等多个基准测试集中，相较于传统的DPO及其他基准方法，LD-DPO展现出了优越的表现。该方法不仅使得模型能够生成更为精炼且高质量的响应，相较于DPO方法，输出长度平均缩减了10%-40%，同时还在很大程度上提升了模型的逻辑推理能力。LD-DPO在多类任务上更好地实现了LLM与人类的偏好对齐。

文章的主要贡献如下：

文章首次定义了DPO的长度敏感性，并为这一现象提供了理论验证。
文章提出LD-DPO，一种长度脱敏的直接偏好优化算法，通过对预测概率的重新建模，缓解了DPO算法的长度敏感性。
文章通过实验验证LD-DPO算法能够使模型生成更简洁且高质量的回复，相比于DPO算法，响应长度减少了10%-40%。

2 DPO长度敏感性

本文通过对DPO的损失函数（如下公式）进行理论分析，揭示了DPO算法的长度敏感性。 $\mathcal{L}_{DPO}(\pi_\theta;\pi_{ref})= -\mathbb{E}_{(x,y_w,y_l) \sim \mathcal{D}}[\log\sigma(\beta \log \frac{\pi_\theta(y_w|x)}{\pi_{ref}(y_w|x)}-\beta \log \frac{\pi_\theta(y_l|x)}{\pi_{ref}(y_l|x)})].$ 具体来说，针对由人类标注的偏好数据（Chosen）与非偏好数据（Rejected）组成的数据组合$(x,y_w,y_l)$，将actor模型的预测概率分别记作$\mathcal{X}1=\pi\theta(y_w|x)$和$\mathcal{X}2=\pi\theta(y_l|x)$，且将reference模型的预测概率分别记作$\mathcal{K}1=\pi{ref}(y_w|x)$和$\mathcal{K}2=\pi{ref}(y_l|x)$,通过对DPO的两个预测变量分别求解梯度，得到二者梯度的相对数值关系，具体如下所示： $\left\lvert \frac{\partial \mathcal{L}_{DPO}(\mathcal{X}_1;\mathcal{X}_2)}{\partial \mathcal{X}_1}/\frac{\partial \mathcal{L}_{DPO}(\mathcal{X}_1;\mathcal{X}_2)}{\partial \mathcal{X}_2} \right\rvert = \frac{\mathcal{X}_2}{\mathcal{X}_1} = \frac{\pi_{\theta}(y_l|x)}{\pi_{\theta}(y_w|x)},$ 即，二者的梯度数值之比取决于actor模型的预测概率，而该预测概率可以看作是逐个token预测概率的连乘，即： $\pi_\theta(y|x)=\prod_{i=1}^{len(y)}p(y_i|x,y_{\leq i}).$ 因此，由于$p(y_i|x,y_{\leq i}) \in [0,1]$，使得$\pi_\theta(y|x)$的数值大小高度依赖数据所包含的token个数，从而导致DPO的优化过程具有显著的长度敏感性，可以总结为：

当数据对中Chosen更长，而Rejected更短时，相较于非偏好方向，模型在偏好方向拥有更大的梯度值。
当数据对中Chosen更短，而Rejected更长时，相较于非偏好方向，模型在偏好方向拥有更小的梯度值。

另外，文中还对两个优化方向的实际数值与其预测概率的关系进行分析，如下图所示，沿偏好方向的梯度数值关于$\pi_{\theta}(y_w|x)$单调递减，关于$\pi_{\theta}(y_l|x)$单调递增；沿非偏好方向的梯度数值关于$\pi_{\theta}(y_w|x)$与$\pi_{\theta}(y_l|x)$均单调递减，同样可以反映出DPO算法的优化过程具有显著的长度敏感性。

3 LD-DPO

针对DPO的长度敏感特性，本文设计了基于DPO的长度脱敏优化算法——LD-DPO，通过对预测概率的重新建模来减少数据长度对优化方向梯度的影响，从而实现脱敏。具体来说，论文作者定义偏好数据对的公共长度为$l_p=min{len(y_w),len(y_l)}$，预测概率$\pi(y|x)$可以表示为： $\pi(y|x)=\prod_{i=1}^{l_p}p(y_i|x,y_{\leq i})\prod_{i=l_p+1}^{l}p(y_i|x,y_{\leq i}),$ 当数据过长时，上式中的$\prod_{i=l_p+1}^{l}p(y_i|x,y_{\leq i})$部分导致$\pi(y|x)$迅速衰减，从而使得DPO算法具有长度敏感性。依据上述分析，文章对该部分进行重新建模，将长度带来的偏好从人类真实偏好中解耦，即：

\[\prod_{i=l_{p}+1}^{l}\underbrace{p^{\alpha}(y_i|x,y_{\leq i})}_{\text{human-like}}\underbrace{p^{1-\alpha}(y_i|x,y_{\leq i})}_{\text{verbosity}}.\]

进一步将冗长偏好部分从预测概率中消除并通过简化，得到LD-DPO的最终预测概率计算式： $\hat{\pi}(y|x)=\prod_{i=1}^{l}p^{\alpha}(y_i|x,y_{\leq i})\prod_{i=1}^{l_p}p^{1-\alpha}(y_i|x,y_{\leq i}).$ 如下图所示，本文对实际偏好训练过程中的$\pi_{\theta}(y_l|x)/\pi_{\theta}(y_w|x)$进行统计分析，可以发现DPO算法中该数值与数据长度存在显著关联，在LD-DPO算法中，随着超参数$\alpha$的减小，这一关联正在逐渐减弱，当$\alpha=0$时意味着优化过程只考虑偏好数据对中的公共长度部分，此时数据长度已经不再作为变量。

4 主要实验

4-1 实验设置

本文选择三类模型系列Llama2-13B、Llama3-8B、Qwen2-7B中的两种设置（Base、Instruct）进行实验；偏好优化阶段选取UltraFeedback数据集；评测集主要选取MT-Bench、AlpacaEval 2（其余评测集指标见文章附录）；对比的基线方法为近期相关的偏好优化工作：DPO、R-DPO、SimPO、WPO及SamPO。

4-2 实验结果

根据下表，可以得到结论：在六种不同设置下，LD-DPO在MT-Bench及AlpacaEval 2上的性能表现均超越其他基线方法，并且相较于标准的DPO算法，LD-DPO算法的平均回复长度下降10%～40%，说明模型通过LD-DPO算法优化，倾向于输出简洁的高质量回复，更好地实现与人类真实偏好的对齐。

4-3 不同模型的长度敏感性分析

如下图所示，文章对不同能力模型的训练过程进一步分析，发现在DPO训练过程中，长度敏感性与模型能力呈负相关。进一步，文章定义长度敏感系数$\gamma=1-\alpha_s$，其中$\alpha_s$为LD-DPO算法的最优超参，提供了一个偏好优化过程的评估维度。

4-4 消融实验

文章中进行了长度解耦目标的消融实验，如下图所示，分别针对偏好数据（Chosen）和非偏好数据（Rejected）的预测概率进行长度解耦，得出结论：不论是Chosen还是Rejected，都应进行预测概率的重新建模，否则DPO算法的长度敏感性均会导致输出长度的过优化。

4-5 超参分析实验

文章在Llama3-8B-Instruct模型上进行了超参分析实验，如下图所示，随着超参数$\alpha$数值减小，产出模型在AlpacaEval 2和MT-Bench上的平均回复长度持续衰减后保持稳定，其在AlpacaEval 2上的LC-Winrate（Length Control Winrate）以及在MT-Bench上的平均得分先增后减，并在$\alpha=0.5$时达到性能最优。当$\alpha$取值过大时，偏好优化过程受长度敏感性的影响，导致回复冗长且质量较低；当$\alpha$取值过小时，会损失部分人类真实偏好信息，导致优化性能不佳，应当根据模型基础能力及偏好学习中的长度敏感性确定合适的超参数（文章提供了实验所用模型的推荐参数选择）。

5 总结

本文针对DPO算法会导致模型生成冗长响应这一业界公认现象，第一次提出DPO算法具有长度敏感性，并基于DPO的优化损失函数进行理论与实验分析。在此基础上，文章提出LD-DPO算法，通过对模型预测概率的重新建模来缓解数据长度对其造成的影响，从而实现对DPO算法的长度脱敏。实验部分，文章使用Llama2-13B、Llama3-8B、Qwen2-7B的两种不同设置（Base、Instruct），在包括MT-Bench、AlpacaEval 2在内的多个主流评测集上进行验证，证明LD-DPO算法优于当前其他偏好优化算法，且相较于DPO算法可以有效降低产出模型的回复长度。最后，文章比较了不同能力模型的长度敏感性差异，为后续的偏好优化工作提供新视角。

参考

[1] Direct Preference Optimization: Your Language Model is Secretly a Reward Model

[2] Provably Robust DPO: Aligning Language Models with Noisy Feedback

[3] SimPO: Simple Preference Optimization with a Reference-Free Rewarda

[4] WPO: Enhancing RLHF with Weighted Preference Optimization

[5] Eliminating Biased Length Reliance of Direct Preference Optimization via Down-Sampled KL Divergence

知识链 = 知识图谱 + 大模型 + 推理 − 幻觉 (ACL 2024)

2024-08-15T10:00:00+08:00

最近由华东师大和香港大学联合提出了一种面向大语言模型推理的幻觉缓解方法Chain-of-Knowledge被ACL2024接收为长文主会。

PDF: https://arxiv.org/pdf/2306.06427

最近这两年，诸如GPT-4、LLaMA3等一系列超百亿规模的大语言模型相继提出，这些大模型以其大规模参数、大规模语料和大规模算力为基础，展现出了极为强大的语义理解和推理生成能力。

为了更好地引导大语言模型完成复杂任务的推理，一些面向大模型提示工程被相继提出，包括Chain-of-Thougt（CoT）、Self-Consistency、Program-of-Thought（PoT）、ReAct等。在这些提示工程的引导下，大模型可以遵循一定的模式完成问题的理解、规划、推理和解答。

不过即便如此，大语言模型在推理过程中依然会存在幻觉，这通常表现在对问题的规划和推理步骤存在事实性错误或逻辑错误。为此，如何能够识别并纠正这些错误对缓解大模型幻觉问题具有重大价值。

例如如上图所示，传统的推理方法是构造若干Input-Output Pair，从而大模型可以遵循这样的模式进行生成；CoT则在此基础上增加了推理路径，实验和理论发现CoT可以很好地提高大模型的推理能力。不过在实际使用中，依然会存在一些错误，这通常是因为大模型对目标问题存在没有掌握的知识，使得其在某个具体的推理步骤上犯错。

为了提高大模型的推理能力，缓解幻觉问题，本文从三个方面进行了改进。

提示工程：Chain-of-Knowledge Prompting

既然CoT存在一定的不足，那么就先从最简单的提示工程出发。回到刚才的图，我们发现大模型在回答问题时，虽然CoT可以在形式上约束大模型要给出推理步骤，但是由于这种推理步骤是以自然语言形态表达，大模型很有可能会生成出错误的中间结果，而自然语言文本模态的中间步骤很难判断其正确与否。

为此，作者尝试增加一项约束，即让大模型给出明确的推理证据三元组（Evidence Triple）。类似于知识图谱中的三元组，每个三元组由Subject、Relation和Object组成，描述一个推理过程则可以用若干个三元组组成，如以下例子：

假设问题：“乔丹为什么被认为是篮球史上最伟大的球员之一？” 传统的CoT方法可能会生成自然语言的推理步骤，但可能会遗漏关键证据或包含错误信息。使用CoK方法，模型会生成如下证据三元组：

（迈克尔·乔丹，获得，6次NBA总冠军）
（迈克尔·乔丹，获得，5次常规赛MVP）
（迈克尔·乔丹，影响了，篮球的全球推广）

通过这种结构化的表达，我们可以发现可以较好地提高推理能力。因为，大模型产生幻觉通常会因为长篇大论的文本解释从而出错，而显式地给出依据则会间接约束大模型不能用模糊的解释来蒙混过关。

幻觉度量

不过，虽然通过CoK提示工程的引导，还是没有办法100%的避免幻觉问题。为此，我们需要找到这些可能错误错误的推理步骤，并尝试纠正他们。

一般地，不论是常识推理还是符号推理，虽然可以通过最终大模型预测的答案来判断其推理过程中间是否可能出错，但是想具体定位到错误的步骤是比较困难的。为此，我们借助CoK提示的结构，尝试将其与外部知识库进行对齐。

给定一个Prompt和大模型给出的CoK推理路径（包括文本模态的推理路径，和结构化的推理路径）。作者提出两个度量方式：

基于忠实性的幻觉度量：忠实性是指大模型生成的结果与其输入的事实一致性，通常应用在文本摘要、机器翻译等场景。对于推理中，则表示当前推理步骤是否与上下文存在关联。先前一些工程采用类似自然语言推断（NLI）的形式来度量忠实性，作者则采用预训练的SimCSE来作为衡量指标。
基于事实性的幻觉度量：大模型出现错误的另一个原因是某个步骤产生了事实错误，换句话说，其给出的某个推理三元组可能是错误的。为此，作者采用TransR等知识表示学习方法来估计每个证据三元组的正确与否，对于错误的三元组，其对应的得分会低于某个阈值，从而可以推断其是错误的。

Rethinking策略

如果对于一个Prompt，大模型生成的推理步骤经过两个幻觉度量之后被认为存在错误，那么就需要对其进行纠正。作者借鉴了目前的RAG思想，尝试通过对外部知识进行检索增强的形式来提高其在某一个错误的推理步骤上的准确性。

但不同于RAG的是，Rethinking算法则是先基于忠实性和事实性度量指标找到错误的推理三元组，其次对这部分三元组检索外部知识库并实现知识增强，最后基于增强的知识以及原先错误的信息提示大模型进行自我反思，并重新规划和思考当前的问题。整个过程不断迭代直到通过幻觉度量。

整个框架的结构如下图所示：

（1）提示工程提示工程中，直接采用CoT编写的提示作为文本模态推理路径。同时也采用Zero-Shot CoT的方法构造一些推理路径。为了得到这些exemplar的结构化证据三元组，作者采用人工标注的方法实现，为了确保证据链的准确性，在标注过程中会参考现有的知识图谱，以保证推理过程是准确无误的。

（2）幻觉度量幻觉度量的得分范围为0-1。0分表示完全错误，1分表示完全正确。这里针对不同的数据集会在验证集上挑选合适的阈值。

（3）再思考算法大模型会接收到幻觉度量的反馈结果，包括具体到每个推理步骤的正确与否信息。对于错误的证据三元组，会对其检索外部知识库里寻找最有可能正确的三元组，并以提示的形式在下一轮大模型回答时作为增强。这里需要强调的是，只针对错误的推理步骤进行知识检索，而不会将正确答案泄漏给大模型。以下为一个直观的例子：

设想模型被问到：“爱因斯坦发明了电灯吗？” 初始回答可能是：

证据三元组：（爱因斯坦，发明了，电灯）

解释： 爱因斯坦发明了电灯，所以答案是“是的”。

经F²验证，发现第一条证据与事实不符。于是，从知识库中检索到正确的证据：

（托马斯·爱迪生，发明了，电灯）

将正确的证据注入提示后，模型重新生成回答：

新的证据三元组：
1. （爱因斯坦，是，物理学家）
2. （托马斯·爱迪生，发明了，电灯）
解释： 电灯是由托马斯·爱迪生发明的，而爱因斯坦是著名的物理学家，所以答案是“不是”。

新的回答通过了F²验证，成功纠正了模型在常识推理中的错误

实验

作者在包括常识与事实推理、算术推理和符号推理等任务上进行了实验。挑选了包括text-davinci-002、gpt3.5-turbo和gpt-4作为大模型基座。实验总体结果如下：

实验结果呈现出CoK可以较好地在绝大多数任务上超越基线和SOTA。同时在Self-Consistency的增强下可以提高超过3%的准确率。

在BoolQ和CSQA上进行实验来验证再思考算法的收敛性，可发现大多数情况下大模型可以在第3轮回答正确。

通过观察一些Case，可以发现在CoK的提示下，大模型可以生成出结构化的推理路径，并能够在再思考算法的增强下不断地提高准确性。

未来展望

应用拓展： CoK方法有望应用于法律推理、医学诊断等需要复杂推理的场景，提升模型在专业领域的应用价值。
实时知识更新： 外部知识库可以被扩展为实时的搜索引擎，为模型提供最新的知识支持，进一步提高推理的准确性和时效性。

总结

该研究开创性地将结构化的知识证据引入大语言模型的推理过程中，提供了一种有效缓解幻觉问题的新途径。通过明确的证据三元组和针对幻觉的度量与纠正机制，模型的推理过程变得更加透明和可靠。这一方法不仅适用于当前的大模型，也为未来更复杂的推理任务提供了宝贵的参考。

SEA：基于大模型的自动评审框架

2024-07-30T10:00:00+08:00

论文题目：Automated Peer Reviewing in Paper SEA: Standardization, Evaluation, and Analysis

主页地址: https://ecnu-sea.github.io/

论文地址：https://arxiv.org/abs/2407.12857

Github地址：https://github.com/ecnu-sea/sea

1 引言

当前，学术论文数量的激增对传统评审机制造成了严重冲击，导致出版物质量参差不齐，不仅加大了同行评审的压力，也对科研环境产生了负面影响。现有的方法通过Prompt工程诱导大语言模型（LLM）进行评审，但这些模型往往倾向于讨好人类，输出的内容较为圆滑；另一类方法使用同行评审数据进行微调，但由于微调时仅使用一个评审标签，生成的意见往往是片面和不完整的。（如下图所示）

因此，本研究的核心是：如何让大型语言模型生成高质量且全面的评审内容，从而帮助作者提升论文质量？

2 自动化论文评审框架：SEA

本文提出一个新颖的自动化论文评审框架SEA，包括三个模块：标准化，评估和分析。如上图所示。

2-1 SEA-S（标准化模块）：

为了使大型语言模型（LLMs）具备审稿能力，高质量的SFT（监督微调）数据集至关重要。然而，现有的同行评审数据集的评审标签存在以下两个问题：

每篇文章对应多条评审，不同的评审基于其领域或知识提供片面的意见。
不同领域以及不同年份的评审格式各异，直接进行SFT会造成不一致性。

为了解决这些问题，本文提出将一篇文章的所有评审整合为一个评审。这种整合后的评审不仅内容丰富，还统一了格式。具体来说，本文尝试使用不同的闭源和开源模型基于特定指令进行整合，发现只有GPT-4能够达到理想效果。然而，GPT-4的成本高且缺乏扩展性。因此，作者随机抽取20%的评审数据，用GPT-4进行整合，并将整合后的评审作为标签，原始的多条评审作为输入，构建SFT数据集来微调开源模型Mistral-7B。通过这种方法，将GPT-4的整合能力蒸馏到Mistral-7B中，形成数据标准化模型SEA-S。最后，作者利用SEA-S对同行评审数据集的评审标签进行整合，生成高质量的评审标签。

2-2 SEA-E（评估模块）：

本文采用Nougat对原论文PDF进行解析。Nougat是一款专门的学术文档PDF解析器，能够将公式转换为LaTeX代码。随后，将SEA-S的输出与解析后的PDF结合，构建了一个高质量的同行评审指令微调数据集，并用其对Mistral-7B进行微调，最终得到一个能够生成全面且高质量审稿意见的评审模型SEA-E。

2-3 SEA-A（分析模块）：

为了分析SEA-E生成的意见与原始文章的一致性，本文训练了一个回归模型SEA-A。该模型基于原始文章和SEA-E生成的评审内容，预测这些内容与文章的一致性得分。本文利用训练集中的论文的Reviewer confidence作为权重，来计算平均的Rating分数作为ground truth：

随后，SEA-A的输入为经过表征模型得到的文章表征和评审表征。

SEA-A的最终输出作为mismatch score，分数越接近0，生成的评审内容与原文更一致。基于此，本文引入了一个自我修正机制，当SEA-E生成的意见与原始文章不一致时，SEA-A会提供反馈，指导SEA-E重新生成更一致的审稿意见。

3 主要实验

3-1 实验设定

本文爬取了OpenReview上NeurIPS-2023和ICLR-2024数据，其中90%的数据作为训练数据，剩下的10%作为测试集。此外测试集还包括REVIEWER2、PeerRead、NLPeer的数据。

Baseline模型包括原始的Mistral-7B，随机挑选review进行SFT得到的Mistral-7B-R，GPT-3.5整合数据进行SFT得到的Mistral-7B-3.5。本文方法的模型包括SEA-E和SEA-EA，其中SEA-EA是将自我修复机制与SEA-E相结合的增强模型。评估指标采用BLEU，ROUGE和BERTScore。

3-2 主要实验结果

可以看到SEA在所有数据集上都远远超出别的baseline模型，无论是in-domain还是cross-domain。此外，SEA-EA也在所有的结果上超过了SEA-E，凸显出自我纠正机制在生成与原始文章更一致的评审的有效性。M-7B-R表现不佳可能是因为只用一条评审作为SFT的数据，导致生成的内容不够丰富；M-7B生成的内容虽然长度长，但是未能与人类评审对齐，质量不佳。M-7B-3.5表现不如SEA-E是因为数据标准化质量不够。

3-3 标准化结果分析

内容分析: 由于整合后的评审内容没有ground truth，无法直接使用主试验的评估指标进行评估。为了解决这个问题，本文设计了一种巧妙的方法来评估不同模型的评审整合能力。具体来说，本文将SEA-S整合的评审内容作为参考（references），而其他模型整合的评审内容作为候选（candidates）。接着，计算候选与参考之间ROUGE值的召回率（recall）和精准率（precision）。通过这两个指标，可以推断出两个评论中重叠和独立语义信息的百分比。从信息量的角度来看，这有助于评估哪个模型整合的评审内容更为丰富，从而间接说明其整合能力更强。结果如下：

格式分析：相较于Mistral-7B和GPT-3.5，SEA-S整合的内容更为丰富，这进一步验证了SEA-S在标准化评审并提供更丰富信息方面的优越性。此外，研究还发现，SEA-S整合的内容甚至略优于GPT-4，因为GPT-4在整合过程中，有时会因未能完全遵循指令而生成低质量的评审内容。

3-4 SEA-A中的不匹配度分数

本小节分析了不同模型生成的评审内容与原始文章之间的一致性。将不同模型在测试集上生成的评审内容输入SEA-A，计算每个模型在不同数据集上的mismatch score。结果显示，SEA-EA在所有数据集上保持最低的mismatch score，其次是SEA-E，这证明了SEA能够生成与原始文章更一致的评审意见。Mistral-7B由于没有经过SFT，未能学习到生成评审与原始文章一致的内容，因此表现最差。

3-5 定量分数分析

本文还对生成评审中的评分部分进行了分析，包括Soundness、Presentation、Contribution和Rating。基于原数据中confidence的加权均分作为ground truth，并采用均方误差（MSE）作为度量标准。括号中的百分比表示生成内容能够准确生成有效分数的比例。结果显示：

SEA确保了输出格式的有效性。
MSE度量表明，SEA在所有情况下都优于基线模型。
SEA-EA在大多数情况下表现优于SEA-E，进一步验证了自我修正机制能够使生成结果与人类反馈在定量评估结果上高度一致。

3-6 定性决策分析

本小节分析了生成的Decision和Reason部分，即类似于Meta-review的内容。结果如下表所示：

SEA-EA的准确率和BERTScore最高，后者表明生成内容与meta-review更加贴近。
NeurIPS-23数据集由于数据本身的问题（95%都是Accept），没有太大的参考价值。
ICLR-24数据集中，SEA-EA的准确率超过SEA-E多达4%，进一步表明自我纠正策略的有效性。
Mistral-7B的Recall高达97.65%，但Precision较低，这表明它倾向于迎合人类偏好，接受大部分论文。
SEA在Precision和F1上表现更好，这表明本文的方法可以更有效地识别不同质量的论文。

总体而言，SEA生成的评审内容更接近实际的审稿决策，并且不偏向于接受决策。

SEA生成的实例展示

InstructGraph：以图为中心的大模型指令微调与偏好对齐 (ACL 2024)

2024-07-15T10:00:00+08:00

论文：InstructGraph: Boosting Large Language Models via Graph-centric Instruction Tuning and Preference Alignment PDF：https://arxiv.org/pdf/2402.08785 Github：https://github.com/wjn1996/InstructGraph Graph指令数据：https://huggingface.co/datasets/wjn1996/InstructGraph

当大语言模型遇到图，会发生什么样的化学反应呢？最近由华东师范大学（ECNU）和加州大学圣地亚哥分校（UC San Diego）联合提出了针对提升大模型在图推理和图生成能力的InstructGraph框架。该工作被ACL 2024接收为Findings长文。

1、LLM与Graph

众所周知，大语言模型（Large Language Models，LLMs）是通过自回归式的Causal Language Modeling实现预训练，自然语言文本遵循着token-by-token的序列形式实现文本生成和推理。然而，图（Graph）则不是序列模式的数据，因此，如何让一个以序列为感知的大语言模型很好地理解一个图数据，是一大挑战。

最近一些工作尝试将图神经网络等模型集成在大模型基座上，使得模型能够按照原先的图学习模式感知图，并借助大模型的生成能力实现推理。然而这类方法存在两个不足：

需要改变大模型的结构，使得模型很难自适应到任意的图，同时这类方法也无法有效地将图与文本很好的进行兼容；
只能够实现由图到文（Graph2Text）的转换，而无法实现图文之间的相互转换，例如Text2Graph。

为了让大语言模型更好更有效地理解图或生成图，该工作提出InstructGraph框架，并考虑从三个方面来实现这一目的。

Prompt Engineering：在输入模板层面上，如何将图与文实现比较好的对齐；
Instruction-tuning：在监督微调时，如何让大模型能够很好地完成图推理与生成任务；
Preference Optimization：在偏好对齐时，如何让那个大模型能够更准确地实现图的理解和生成，缓解幻觉问题。

2、提示工程：结构上对齐

文本是序列化的数据，图是结构化的数据，如何在输入层面上在不介入外部模型的条件下很自然地实现统一对齐呢？该工作想到了使用代码（Code）作为中间表示。

Code是一种天然的包含结构化信息的序列数据，现如今大语言模型之所以能够具备很强的推理性能，也得易于代码数据的引入。因此，如果将图用代码的形式来表达，那么就巧妙地实现了图文的统一结合，而对于大语言模型来说，处理图和处理代码相似，无需刻意地在输入感知上对图进行专门的表示学习。

为此提出Code-like Format Verbalizer，对于任意一个图，都可以转换为一个代码的结构模式。

基于这个Code-like Format形式，在做图到文（Graph2Text）时，大模型可以像理解代码一样理解图，然后通过文本生成完成回答；在做文到图（Text2Graph）时，大模型可以像写代码一样生成一个图。这一过程充分利用了大语言模型的代码理解和生成的能力。

3、图指令微调

对于GPT-4、GPT-4o等超大规模的模型，在提示工程的引导下大模型已然可以完成的很不错。但是对于较为小规模的模型，效果依然不行，那么就需要对小模型进行监督微调来赋予其图推理和生成的能力。本文将图指令微调划分为两大范式：

图推理：给定一个Query和一个Graph，回答问题；
图生成：给定一个Query，生成一个Graph。

为了达到这个目的，该工作收集了来自29个不同的针对图推理和生成的任务，并进行了数据预处理和指令构建，最终构建了大约1.6M语料。数据来自Wikipedia、Wikidata、DBPeidia、FIFA、Freebase、OGB、PubMed、Amazon、CiteSeerX、MoveLens、InstructUIE、InstructIE、ConceptNet、NLGraph、ArXiv、LastFM等。对这些图任务进行了更为细致的划分，划分为4个Group，如下所示：

Graph Structure Modeling

图结构建模任务旨在设计相应的指令，让LLM能够理解Graph结构相关的信息，包括图连通性、环、最短路径等信息。先前工作NLGraph提出了8种与Graph结构相关的benchmark。这里挑选了前7个任务的训练集作为训练数据。另外还增加了两个NLGraph中没有提及的任务：

Graph Degree Prediction：给定一个Graph，计算目标节点的度数，有向图则包括入度和出度。
Graph Diameter：给定一个Graph，计算其直径。
Graph Language Modeling

图语言建模旨在设计相应的指令，让大模型根据Graph来完成语言建模。这里包含若干类别的任务：
Caption Generation：基于Wikipedia和Wikidata，针对Wikidata给定的一个知识图谱，生成出Wikipedia中的文本描述；
Question Answering：输入一个Graph，给定一个问题Query，回答相应的问题；
Nodel Classification：输入一个Graph，对其中一个节点进行分类；
Link Prediction：输入一个Graph，对其中两个节点的边类型进行预测；
Relevance Inspection：输入一个Graph和一个文本描述，判断图文之间的相关性；
Collaboration Filtering：输入一个协同图（二分图），预测两侧节点之间的关系；
Graph Generation Modeling

图生成建模旨在让大模型根据指令生成一个Graph。生成的过程等价于生成Code。图生成包含两个类别的任务，分别是根据文本生成一个图，类似于信息抽取和知识图谱构建；另一个任务则是生成一个结构图。

Graph Thought Modeling

除了针对Graph进行理解和推理以外，对于普通的文本生成和推理任务也可以间接利用Graph。例如数学计算推理时，原始的Chain-of-Thought（CoT）是通过text-based reasoning chain的形式进行推理的，而我们可以敦促模型先生成一个计算图，然后再基于这个计算图生成答案。这一过程也类似于大模型Agent中的Planning环节。

所有任务数据列举如下所示：

4、图偏好对齐

先前的很多面向Graph+LLM的工作，均忽略了Graph相关的偏好优化问题。我们发现LLM在针对Graph进行instruction-tuning阶段，同样存在一些偏好问题。我们认为除了LLM本身存在的harmless、helpless等问题外，针对Graph也依然存在如下问题：

输入的graph可能存在错误、冗余，或于大模型本身存在冲突的信息。

例如输入的graph中，存在冲突的关系，例如a -> b [relation=”r”], b -> a [relation=”r”] 输入的graph（尤其是知识图谱等），存在与真实知识冲突的，例如输入的graph 中国 -> 日本 [relation=”接壤”]
大模型生成的内容与输入的graph存在不一致（内部幻觉）；

例如在KBQA时，大模型可能回答的答案可能不在子图中出现过。如果子图中没有，应该修正回答为“正确答案是xxx，不过如果只关注给定的图，则不存在答案”
大模型生成的内容与真实知识存在不一致（外部幻觉）；

大模型生成的内容中有错误事实信息；大模型生成graph时，出现胡编乱造 “给你三个节点，生成含有十条边的图”：这个问题很显然无法回答，需要让LLM优化。

为了避免过多的人工介入，构建偏好数据主要通过负采样的形式实现。负采样数据来源于两种途径：

启发式构建：修改graph结构，从而获得错误的graph，其与对应的文本不一致；
ChatGPT改写：设计instruction，让模型编造一个与graph信息不一致的文本；

ps：需要获得错误的文本区间

提出两种non-reward的图对齐训练方法：Graph-based DPO（GDPO），即利用DPO的优化算法，根据上述两个graph存在的特性，构建pair数据。

五、实验

实验中，挑选LLaMA2-7B作为基座进行模型微调和对齐。整体实验如下图所示，InstructGraph的总体性能超越GPT-4。超越了GPT-4约13%，超越GPT-3.5约38%。

针对信息抽取任务的图生成任务，进行了较为细粒度的评估。生成一个图通常包含两个角度，一个是判断实体/节点的准确性、另一个是实体/节点之间关系的准确性，结果如下图所示：

针对偏好对齐训练后的模型，实验结果如下所示：可发现，经过偏好对齐调优后的模型性能可以进一步得到提升，提升效果接近10%。此外，InstructGraph在通用的NLP任务上效果也能够保持与LLaMA2相似的结果。

黑箱优化：语言模型即服务

2022-09-09T18:28:44+08:00

[论文导读] Black-Box Tuning for Language-Model-as-a-Service

最近在参与一个算法调优竞赛，学习了不少关于小样本学习、Prompt Learning以及模型优化方面的知识。在文献调研过程中阅读了一篇提出了一种大规模语言模型落地的算法（不计算模型梯度）的文章：Black-Box Tuning for Language-Model-as-a-Service（ICML 2022），文章来自FudanNLP，本篇博客记录一下其中的要点以及我个人对问题的理解。

Background

预训练语言模型（简称PTM）越来越大了，让它们能落地被实际的业务应用越发困难，而且，对于一些大型的商用模型（比如Open AI的GPT-3），它们并不开源，使用者也很难与模型本身交互。回顾一下，我们平时在使用小模型的时候往往是这么做的：

下载某个开源预训练模型的检查点/自己训练一个预训练模型
收集特定任务的标注数据
Fine-tune预训练语言模型
上线推理

但是，随着模型变大，预训练和微调的成本都快速上升，再加上商用模型的限制，使用小模型的策略来玩大模型并不现实，比如GPT系列的模型，具体可参考：GPT-3 Demo。为了解决这些问题，作者提出了黑箱优化这个概念，用作者自己的话说就是：LMaaS是要把大模型当作发电厂，那自然不能给每家每户都派一个调电（调参）师傅过去，最好是每家每户能够自己把电器（任务）管理好，发电厂（大模型服务方）只需要确保供应电力（算力），这才是规模化的玩法。

In-Context Learning

GPT-3在他们的论文里给出的玩法就是in-context learning. 如下图所示，不需要进行反向传播，仅需要把少量标注样本放在输入文本的上下文中即可诱导GPT-3输出答案。

Prompt Learning

再往后，这种通过额外文本诱导模型提供正确答案（生成某些词，或是给出正确的分类结果等）发展成为如今大火的Prompt learning，将Downstream Tasks转化为(M)LM任务来直接用PTM解决，模型规模越大，其对语言建模的能力往往就越强，从(M)LM迁移到Downstream Tasks就越容易，那我们就可以用一个大规模通用PTM来解决各种下游任务了。

Language-Model-as-a-Service

概念补充：Parameter-Efficient tuning，即只微调少量参数，如Prompt Tuning，但是用户在服务端仍然需要调参。

个人认为，理解了下面这张图，就把黑箱优化这个新提出的概念理解了，在此处可将图右上角的“黑盒模型”视为一个不知道具体细节的函数f(x)

Derivative-Free Optimizer：简称DFO，顾名思义就是一个不依赖模型给我梯度的优化器，实验中使用的是CMA（CMA Evolution Strategy）实现，全称是Covariance Matrix Adaptation Evolution Strategy，在PyPI中对应的是cma包。
本征向量 $z$：DFO优化的目标
随机矩阵 $A$：此处产生均匀分布（前人工作使用了正态分布），为DFO生成的向量增加随机/多样性
初始Prompt-Embedding $p_{0}$：从RoBERTa的词表中随机抽取一些单词，将其Embedding与DFO生成的向量进行“直和”，也就是每个位置对应相加。我个人认为这步的目的是让DFO生成的本征向量能尽可能靠近一个“靠谱”的词向量空间。

Reference:

https://zhuanlan.zhihu.com/p/455915295

[2022] 配置一台用于开发的MacBook

2022-08-23T17:16:28+08:00

在2022年配置一台用于开发的MacBook

0 Macbook配置与基本信息

14-inch MacBook Pro - Space Grey

32GB unified memory
Backlit Magic Keyboard with Touch ID - US English
1TB SSD storage
14-inch Liquid Retina XDR display
Apple M1 Max with 10-core CPU, 24-core GPU, 16-core Neural Engine
Three Thunderbolt 4 ports, HDMI port, SDXC card slot, MagSafe 3 port

1 系统偏好设置

1.1 打开电池百分比

现在的macOS默认不显示当前电池百分比，需要在系统偏好设置中手动打开

方法：系统偏好 - 程序坞和菜单 - 电池 - 显示电池百分比

1.2 显示蓝牙图标

不知道为什么苹果现在默认隐藏了蓝牙图标，需要先点开状态调上的控制中心才能找到蓝牙按钮，直接按住图标将其拖拽到上方状态栏即可。

1.3 文件路径

访达并不是那么好用，为了更直接的了解当前文件所在位置，个人建议显示文件的路径

方法：打开终端（Terminal）使用以下命令

# show path bar
defaults write com.apple.finder ShowPathbar -bool true

1.4 访达窗口下方状态栏

为了更方便的用鼠标拖动的方式放大/缩小图标，以及查看当前位置的文件个数和状态，可以打开访达窗口下方的状态栏。

方法：打开终端（Terminal）使用以下命令

# show status bar
defaults write com.apple.finder ShowStatusBar -bool true

1.5 触控板

触控板可以选择“单指轻触”来代替“按下”，并且自定义触控板速度

位置：系统偏好 - 触控板

1.6 Screenshot

macOS的截屏很方便，使用默认快捷键command+shift+4即可，会得到一张高清png图，如果希望缩小截图所占空间，可以令系统默认使用jpeg格式。

 defaults write com.apple.screencapture type jpg

1.7 外来软件权限

许多在软件官网下载安装包会因为苹果的安全限制无法打开，可以进入：系统偏好设置 - 安全性与隐私 - 通用，允许任意来源软件的安装。

顺便可以解锁让Apple Watch解锁Mac的功能（记得先解锁Apple Watch）

Remark：如果找不到“任意来源”，可以使用命令行命令

sudo spctl --master-disable

*此处需要输入PIN

2 终端与命令行

2.1 HOMEBREW

Homebrew是一款经典的开源软件包管理系统，它可被用来简化macOS系统上的软件安装过程。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

随后执行以下命令（会默认替换username），将Homebrew添加到环境变量

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/username/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

使用Homebrew安装以下软件包

brew install \
  wget \
  exa \
  git \
  nvm \
  pnpm \
  vips

2.2 iTerm2 & Oh My Zsh

2.2.1 iTerm2

macOS自带的终端（Terminal）在灵活度和颜值上都稍有欠缺，在此推荐使用 iTerm2，可以提供全屏编辑/窗口拆分/窗口透明等功能。

ZSH_THEME=”powerlevel10k/powerlevel10k”

https://github.com/romkatv/powerlevel10k

2.2.2 Oh My Zsh

Oh My Zsh是一款社区驱动的命令行（终端）工具，可以方便地配置主题，并提供了插件机制（如命令的自动补全、提示等），使用以下命令安装即可

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/too

随后，每当Oh My Zsh的配置改变时，都需要执行：

source ~/.zshrc

我选择的主题是：ZSH_THEME=”powerlevel10k/powerlevel10k”，在~/.zshrc文件中修改对应参数即可。也建议尝试omz的插件，比如 zsh-autosuggestions 等。

地址：https://github.com/romkatv/powe

3 软件推荐

接下来就是软件推荐清单了，仅仅是推荐一些个人常用的软件。除了日常应用外，我还选择了一些可能对CS/SE/DS等相关专业学生大裨益的软件。我将他们分成三个类别，并且附上了官网链接。

Remark：如果你和我一样使用的是M1系列芯片（包括M1 Pro 和 M1 Max），在官网下载时请选择apple silicon mac版本的软件

比较Intel与Apple Silicon：https://support.apple.com/en-us/HT211814

3.1 日常使用

腾讯柠檬清理：据说是企鹅为数不多的良心产品，用来清理垃圾文件。
CleanMyMac X：功能更全面的系统垃圾清理软件，缺点是需要购买License。
Snipaste：占用低但功能丰富的截图软件，目前macOS已经有了测试版，免费版即可覆盖大部分人的日常需求。
欧路词典：用了若干年的词典软件，个人是否好用取决于是否构建好适合自己的词典库。
Outlook：用于管理邮件，在App Store下载
The Unarchiver：非常好用的的macOS端解压软件，在App Store下载
MonitorControl：外接显示器亮度调整（GitHub开源）
Zoom/Cisco Webex/腾讯会议，各取所需

3.2 笔记与文献管理

Notion：全能型笔记软件，本人为重度用户，利用Notion构建了如电子图书馆，知识库等，有教育优惠。可以使用微信小程序Notion助手方便地通过分享链接保存知乎/微信公众号文章。此外，虽然我还有一年半的印象笔记订阅，但因其愈发过分的广告，我已在迁移出所有内容后将其弃用。
Typora：轻量级Markdown编辑器
Zotero/Mendeley Desktop：用于文献管理，安装插件后可以和Notion搭配使用
Mathpix：用于OCR数学公式，将其转为markdown语法
Goodnotes/Notability：老牌的笔记软件，在App Store下载
Calibre：用于电子书管理
语雀：用于构建/查看知识库、协作编辑，支持多种编辑器（其实网页版的飞书文档也不错）

3.3 开发用途

Filezilla2：FTP传输客户端,用于向服务器（及跳板）传文件
VS Code：无需多言
Jetbrains全家桶（如果是学生身份可以无限白嫖）
Sublime Text：跨平台文本编辑器
Navicat：图形化数据库管理工具，用于连接本地和远程数据库
GitHub Desktop：通过图形界面更方便的管理GitHub仓库
Docker：用于容器管理

一些关于 MacBook 的基本配置和软件推荐暂且就先介绍到这里，希望对读到这里的你有所帮助。

Reference

https://www.robinwieruch.de/mac-setup-web-development/
https://zhuanlan.zhihu.com/p/48207191

ViLT：图像-文本多模态Transformer

2022-08-11T18:49:23+08:00

[论文导读] ViLT: Vision-and-Language Transformer Without Convolution or Region Supervision

前言与背景

背景

ViLT是ICML 2021的一篇Oral Presentation，它提出了一个极其简单的多模态训练方法，大大减少了视觉-文本多模态任务中处理图像特征抽取部分的计算量，将主要的计算量都放在了模态融合上，显著提高了模型的推理的速度，把方法的建模做了相当程度的简化，算是多模态领域这两年来里程碑式的工作了。

主要贡献

ViLT把目标检测（Object Detection），也就是文章Title中提及的Region Supervision从多模态任务里面去掉了。天下苦目标检测久矣，回忆一下DETR就是因为把目标检测框架做的简单，不仅可以End2End（端到端）训练，而且支持后处理。而ViLT直接把目标检测这个高开销任务干掉了，让模型明显简化和推理加速。

从上图可以概览一下前面的工作，文本的处理都很简单，通过word embedding生成向量，扔到Transformer里就可以了。但是视觉这边就不一样了，对于最流行的区域特征，先给一个图像，通过一个Backbone网络，然后RoI，相当于就是做了一次目标检测（抽取Bounding box），所以图像处理的结果就跟文本的单词一样，都是离散形式存在的（也就是一个序列），最后再把文本和图像的序列扔给Transformer进行处理。把图像化为和文本序列一样的离散化表示是一种理论上可行且实现方便的方法，这也就是为什么之前的工作都是把和文本一起训练的通过OD来建模。但是，整个模型的运行时间分配并不合理，用BERT类模型处理文本只占用约15ms，但是视觉OD部分占了810ms。过去这几年（ViLT出现之前）一直有各种各样的工作把视觉这部分的时间压缩，但并没有根本性解决这个问题的方案出现。

而ViLT直接把这件事情反过来了，视觉部分只占据0.4ms，也就是说处理图像部分的时间开销反而只有文本的1/35了，获得了上千倍的运行时间的减少，这也是本文最大的卖点。但实际上，之前被诟病的高开销目标检测也并没有这么不堪，因为可以复用一些处理好的、静态的数据（抽取好的特征），而ViLT虽然推理很快，但是其训练依然是很昂贵的，需要64张32g V100训练三天，它甚至比之前的方法训练时间都要久，而且从上图也可以看出其性能和基于RoI的模型比并没有显著提升。因此，个人认为ViLT最大的贡献是开了“Without Convolution or Region Supervision”这个坑，而非是模型的性能。

接下来对paper本身进行分析

文章解读

Title

ViLT: Vision-and-Language Transformer Without Convolution or Region Supervision

解释一下这里的Conv和Region Supervision的具体含义

卷积：指的就是预训练好的一个模型抽出的backbone，提供特征图。
区域特征：简而言之就是目标检测的框框。

可以看出，作者最希望体现的卖点，就是既不用卷积带来监督信号，也不用区域特征带来监督信号，以此降低计算复杂度。

Abstract

VLP（视觉文本预训练）在过去几年发展的很好，在各种downstream任务都有很好的效果，但是这些模型在图像处理部分花费的精力太多了。常理而言，视觉部分越复杂，开销越大，结果越好，因此之前的工作太过依赖于feature extraction，也就是看为一个目标检测，模型又有Backbone网络在工作，又有Region Supervision在工作。这篇文章针对这个点开始研究，指出了一下两个问题：

效率不行，抽特征花了太多的时间，花费的时间已经超过了模态融合，对下游任务不友好。
如果只用一个预训练好的模型去抽取特征，模型的表示能力肯定有问题，比如用一个目标检测器，因为目标检测的数据集规模都不大，不能涵盖问题的边边角角，因此如果只是抽特征，大概率就不是最优解。而且深度学习时代，总得想办法做End2end的学习。

因此，ViLT提出了极简化的方案，图像预处理做的和文本预处理一样，都通过linear embedding就结束了，正是因为这种设计，ViLT的速度快了很多，但是性能依旧保持竞争力。

Introduction

模态学习近几年很火，进步也很快，因为也采用了PT-FT的方式。不论是nlp还是视觉，大家现在都这么干，当把它拓展到多模态的时候，效果也不错。作者指出在这个条件下，预训练阶段的学习比较重要，它不仅能够为模型提供一个好的初始化，甚至还可以帮助模型Zero-Shot做下游任务，催生了多模态的视觉文本联合预训练模型。

在文章的导言部分，作者罗列了2019-2021年间出现的若干引用过百的文章（显然，背后还有上千篇跟进性质的工作），可见这个东西过去几年发展的速度多快，19年Vilbert、VisualBert、VLBert三篇文章名字很像。因此多模态虽然听起来还是挺新的，但实际上竞争很激烈，需要拼手速。

作者认为，一般来说上述模型都是图像文本对来训练的，他们的目标函数都是imgae-text matching为主导的，也就是计算匹配loss和nlp专用的掩码学习，作者在footnote中指出了，虽然还有其他的目标形式，但是imgae-text matching和mlm基本是所有模型都要使用的。同样的，ViLT也是用了这两个任务。下游任务涉及到自然语言和视觉这两个模态，不过要注意图像和文本的数量关系并不是一一对应的，可能是一对多，也可能是多对一。从宏观上看过以后，我们看看ViLT的具体内容：

首先，如何去处理文本？

这个问题的解决方案比较统一，17年开始学界就是用Transformer处理文本了，而且也早早一统江湖，文本可发挥的地方不大。

重要的是，是如何处理视觉部分

视觉部分就有很多可以发挥的地方了，你的图像的像素，必须被转化为某一种形式，比如离散化，能够跟language tokens去匹配起来，然后才能和文本一起喂给Transformer去玩Self-Attention。你可能会问为什么不能用Pixel？ViT已经指出了这个问题，就是长度太长了，Transformer接受不了，因此ViT把图像分割为16*16的patches，用patch构建的特征喂给Transformer。因此，就是这类问题的核心就可以抽象为像素 → 语义特征的处理方法如何优化了。

作者指出了，大部分这种VLP都依赖一个目标检测器，原因归纳如下

想要一个离散化的特征，目标检测的框就是天然的离散特征，给你图，返回我框，而且这些框有明确的语义信息，直接用RoI抽取特征即可。思路打开，可以把每个这样的Bounding Box理解为一个词语。
下游任务，因为对于Vision-Language的任务而言，要么是VQA，要么是Captioning，他们和物体的联系太紧密了，对于Visual Reassign/Retrieval来说也是，其实你只要正确地识别出了物体，就有了很大的概率来匹配到相应的文字

目前的VLP都是用了预训练好的目标检测器（Visual Genome数据集，1600个类别和400个属性），就是看中了覆盖类别数量多。如果是coco的80类，很有可能就超出匹配的空间了，总而言之类别越多越好。此外，各个工作也都需要在同数据集比较，因此都选择了这个VG训练的目标检测器，但是它非常昂贵。

作者认为之前大部分工作还是集中在提升视觉编码器上，学术界关注效率没有关注性能这么火，尤其是多模态，都不把它当回事，因为在训练的时候可以抽取好目标检测的特征，放在硬盘上，需要的时候从里面拿，因此可以发现抽特征可以在线下完成，真的训练没想象中这么贵。但是！真实世界中，你的数据每时每秒在新生成，你每个时刻都要去抽取特征，这个时间就不能忽略了，这就是前面工作最大的局限性。

对先前工作的归纳

这篇文章比较神奇的地方就是：它的背景知识介绍比自己的方法长得多，作者把抽取图像的技术路线写了一整页，重新定义了vision-language model，并按照以下策略进行分类。

图像和文本的表达是否平衡：使用参数量和计算量来衡量
模态之间如何交互与融合

先对Abbreviation进行一下简单的解释

VE：Visual Embedding
TE：Textual Embedding
MI：模态融合

对于这四张子图而言而言

文本轻量，视觉很贵，融合轻量（点积 or 浅层网络），其代表为Visual Semantic Embedding (VSE)
二者开销基本等价，但融合轻量（点积），其代表为CLIP
最主流的方法，基本80%的工作都是这个形式，文本处理便宜，目标检测非常昂贵，但是性能还不错，其代表为Visual-BERT和UNITER
作者提出方法，认为在多模态任务中，两个模态的融合比较重要，和特征关系最好不要这么大，希望二者的特征抽取都能便宜一点

ViLT的模型结构

模型的输入细节：：

Word：L*H
图像（Patch Embedding）：N*H

灰色指代模态，0就是文本，1就是图像，这是因为concatenate后，模型并不知道谁是谁，不利于学习。因此你要告诉模型哪块是文本，哪块是图像，模型的输入和输出等长度。

其中的✳分别代表文本和图片的[CLS] Token

注意：图像中的灰色-绿色-浅绿/灰色-紫色-浅紫，也就是文本/图像的Model-type Embedding，Token Pos Embedding和文本/图像本身的Embeddeding看起来是拼接起来的，实际上是加法加在一起的。

训练的策略与细节

Image Text Matching：人为设计的任务，故意把和文本匹配的图片随机替换掉，实际上做二分类，让模型判断一张图是否被替换为了另一张图片。
MLM：NLP经典任务，都懂的。
Word Patch Alignment：文本和图像的相似度如何？OT是把几何和概率联系起来的一个工具。可以理解为在计算文本和图像概率分布的distance

看到这里可能有个问题：为啥不给图像也来个MLM？当时ViT已经有了，但是MAE还没出来，不过MAE现在（22年）已经很火了，就前面的模型架构图来看，把图片中的紫色部分遮住，似乎就是个BERT，把蓝色部分遮住，似乎就是个ViT，因此在图片的Caption中也说了是受到了ViT的启发。

Whole Word Masking：作者举了个例子，这个giraffe，被劈成小的词根（token）以后，你mask了中间一部分后，由gi和raff开头结尾的单词并不多，很容易就能猜出来是giraffe，根本就不学了。这就导致了你做多模态的时候我压根不借助图像信息了（short cut），一部分loss就失去了意义，因此还不如全部mask掉，让模型一定要借助图像信息。

Image Augmentation：之前的多模态任务里没办法用数据增强的，因为特征都已经抽取好了，只要一增强，特征就要全部重抽。作者这里既然已经end2end了，直接就上了修改版的random augment，用了ra的policy，但是去掉了color gitter和cutout，让文本能够和图片对应起来。

ViLT所使用的数据集

MS-COCO：每个图对应5个Caption，标题较长（平均超过十个词）
VG：10w图，对应500w文字描述，但是标题比较短
GCC：一对一
SBU：一对一

一般将他们称为4-million，很多人沿用了这个设定，但实际上每个数据集有自己的特性，比如一对多和多对一关系。因此在衡量数据集大小的时候，我们一般是用图片的数量来衡量数据集的大小，而非是有多少个pair。注意：GCC和SBU现在下不完整了，有很多url失效了。

实验效果

分类任务

时间：ViLT最大的卖点，之前都是900ms，即使Grid feature也有100ms，但是ViLT直接降低到了15ms

结果：依然是基于目标检测（区域特征）的模型效果最好，但ViLT的速度和精确度结合比较好（成功Tradeoff）

Retrieval

上面是Zero-Shot的性能，下面是经过Fine-Tuning的性能，总而言之，ViLT的性能还差一点点（这样才有坑可填），但性能并不是它的卖点，所以也不用太过在意。

消融实验

作者就训练步数对模型性能的提升和前面提到的训练技巧进行了消融。

问题1：训练时间

很多自监督的工作，都说自己训练越长越好，比如MoCo，SimCLR，MAE（1600epochs），作者尝试了下这个东西的steps对性能是否有影响。得出的结论是有提升，但是提升很少，消融应该就是在25k做的，但是刷分肯定挑了更好的模型。

问题2：前面的技巧

证明了ViLT所使用的图像数据增强非常有效，而且注意，作者在这里让图像也简单的做了下完形填空，但是效果不怎么样（当时MAE还没出来）。

拓展方向

Scalability：Transformer都是越大越好的，数据越多越好，来个ViLT-H
图像的遮蔽语言建模：今天看来，已经被MAE做掉了，而且有超级多的跟进工作
更先进的数据增强：消融就能发现，数据增强很管用，而且能提高Data Efficiency

总结

本文的写作有些非主流，背景知识写出了文献综述的味道，而且是自己方法的两倍长度。不过个人觉得本文对之前工作做的Taxonomy很好，重新定义了vision-language model，来彰显自己方案的可靠性。从文章真正的贡献而言：

模型既没有贵的Embedding，又能保住性能，简单且有效（也让后面人有坑可以填）
证明了不再需要Conv或者Region，任务一样可以做好

不过需要注意，ViLT是用PyTorch-Lightening写的代码，和原生PyTorch有区别，而且需要64个V100训练三天，似乎99%的从业者都不能承担。

总而言之，ViLT算是一个多模态领域开创性的工作，成功地平衡了训练/推理时间开销和下游任务的性能，因此也出现了若干跟进性质的工作，在之后的文章导读中应该还会继续涉及这个话题。

快速为 Hexo-Icarus 配置 MathJax（2022）

2022-07-17T21:00:03+08:00

如何让自己的博客能可靠地渲染数学公式？这是个问题。

前言

前几天在将hugo博客迁移到Hexo-Icarus后，发现了MathJax无法正常工作的问题。在搜索引擎搜索的话，会得到一些类似的答案，尤其是csdn上的答案，不仅不完全正确，而且因博主们持续不断地互相抄袭，这些答案早就不适合2022年的hexo-icarus了，真正可靠的答案很少，而且都被淹没在了这些垃圾信息中。

## 解决方案

大多数人刚配置好Hexo-Icarus后会出现LaTeX Error，典型的情况如下图所示

还有一些个别情况，会出现公式直接被吞无法显示的情况，一般是有些LaTeX符号在Hexo生成页面时，被识别成Markdown语法而被渲染成HTML标签导致的，这也不用急，先尝试排查一下npm modules看一下自己装了哪些包，然后卸载掉安装好Icarus主题后再安装的公式package，Icarus自带行间公式的渲染。

如果发现自己有hexo-math，还需要卸载这个package

$ npm uninstall hexo-math

使用以下命令，换装hexo-filter-mathjax，在Hexo端渲染MathJax

$ npm install hexo-filter-mathjax
$ hexo clean

在编辑博客md文件时，在header区域加上 mathjax: true，如下所示

title: "快速为 Hexo-Icarus 配置 MathJax（2022）"
date: 2022-07-17 21:00:03
mathjax: true
categories:
- Blog
tags:
- Blog
keywords:
- Blog

然后重新使用 hexo g 命令生成博客页面，再使用 hexo s 进行预览，会发现问题解决了。

效果

行内公式

CodeBERT的输入形式为 $[CLS], w_1, w_2, …w_n, [SEP], c_1, c_2, …, c_m, [EOS]$，第一段为自然语言文本，第二段为代码，训练的数据可分为两种，即bimodal data，即NL-PL Pairs和unimodal data，也就是纯代码。

行间公式

行间公式使用{raw}...{endraw}进行包裹，如下

$$
\begin{equation}M_{i j}= \begin{cases}0 & \text { if } q_{i} \in\{[C L S],[S E P]\} \text { or } q_{i}, k_{j} \in W \cup C \text { or }\left\langle q_{i}, k_{j}\right\rangle \in E \cup E^{\prime} \\ -\infty & \text { otherwise }\end{cases}\end{equation}
$$

\[\begin{equation}M_{i j}= \begin{cases}0 & \text { if } q_{i} \in\{[C L S],[S E P]\} \text { or } q_{i}, k_{j} \in W \cup C \text { or }\left\langle q_{i}, k_{j}\right\rangle \in E \cup E^{\prime} \\ -\infty & \text { otherwise }\end{cases}\end{equation}\]

以上就是在为Icarus配置MathJax时的一些经验分享，有时候直接去这些主题仓库的issue中寻找答案，会比用搜索引擎的效率高很多，希望能有所帮助。

Code预训练语言模型学习指南（原理/分析/代码）Part2

2022-07-09T20:00:03+08:00

Code预训练语言模型学习指南（原理/分析/代码）Part2

这个主题的上一篇文章 Code预训练语言模型学习指南（原理/分析/代码）Part1 讲解了几个典型的Code预训练语言模型（CodePTMs），这篇文章顺延这个话题，继续讨论21年及以后出现的CodePTMs，并且补充一些代码。

PLBART

NAACL 2021 Unified Pre-training for Program Understanding and Generation

顾名思义，就是应用于编程语言的BART，参考了ACL 2020的文章：BART: Denoising Sequence-to-Sequence Pre-training for Natural Language Generation, Translation, and Comprehension

先简单说下BART，它吸收了BERT模型的双向编码器和GPT中的单向left-to-right解码器这二者的优点，因此比BERT更适合文本生成的场景（BERT因Pre-training阶段和生成式下游任务差异比较大，因此被认为不适合做NLG相关任务），而它相比GPT，也多了双向上下文语境信息（GPT是单向建模）。除此之外，相比BERT的Token Masking，BART对Encoder端采用了更加复杂的Noise。

基于对BART的知识，理解PLBART并不算困难，其使用了和BART-base相同的架构，唯一结构上的不同的是它在Encoder和Decoder的顶部添加了一个额外的LayerNorm。在Noise策略方面，PLBART使用了token masking, token deletion和token infilling这三种策略，与BART相比少了Sentence Permutation和Document Rotation这两个任务，这些任务的细节都可以参考BART原文。

在微调下游任务方面，作者将PLBART的下游任务分为两块

首先是Sequence Generation，又可细分为三个任务，可参考下图

其次是Sequence Classification：将序列尾部的special token喂给线性分类器用于预测，与BERT等模型的分类区别不大。

实验与比较方面，作者先指定了baseline模型，并将其分成了两种

Training from Scratch，作者用下游任务的数据集从零开始训练了LSTM+Attention以及一个Transformer Pre-trained Models，作者挑选了RoBERTa、CodeBERT、GraphCodeBERT、GPT-2、CodeGPT(-adapted) 具体的实验部分做了Code Summarization、Code Generation、Code Translation这三个生成式任务，效果自然是好的，在Classification方面做了两个任务：clone detection和vulnerability detection，在后者上PLBART不如基于AST的模型。

CodeT5

EMNLP 2021 CodeT5: Identifier-aware Unified Pre-trained Encoder-Decoder Models for Code Understanding and Generation

文中对CodeT5的描述是：a unified pre-trained encoder-decoder Transformer model that better leverages the code semantics conveyed from the developer-assigned identifiers，即一个能更好地利用代码语法信息（形式是identifier，即标识符）的统一预训练Transformer模型。在开始之前，和PLBART一样，先简单说下Google T5模型。T5的名字来源是Text-To-Text Transfer Transformer，顾名思义T5把所有的NLP问题统一归纳为了Text2Text任务，用来做NMT、QA、文本摘要和文本分类任务。

对比下T5原文，可以发现二者的核心思想还是非常类似的，作者将CodeT5归纳为a pre-trained encoder-decoder model that considers the token type information in code，细心的玩家可能发现了，前面提到的CodeBERT为首的BERT类模型和CodeGPT为首的GPT类模型，仅含有Encoder或Decoder，而非完整利用一个Transformer架构来处理代码。因此CodeT5最大的卖点即第一个unified encoder-decoder CodePTM，可以理解为完全使用了Transformer的两个部分。

此外，除了使用T5的架构外，作者使用了以下两个方案来更好地利用代码结构特性：

使用了代码的标识符信息，提出了Identifier-aware Pre-training，是一个与T5中Masked Span类似的目标，简而言之就是随机mask掉任意长度的Span，然后让decoder去预测。利用了代码地Comments（自然语言注释）信息，作者称之为Bimodel Dual Generation，让自然语言和源代码的表征可以对齐，帮助缓和Pre-training和Fine-Tuning阶段的差距。

文章发表时在CodeXGLUE Benchmark的若干任务上取得了SOTA效果。

UniXcoder

ACL 2022 UniXcoder: Unified Cross-Modal Pre-training for Code Representation

这是当今（2022.7）的SOTA模型，参考了NIPS2019: Unified Language Model Pre-training for Natural Language Understanding and Generation

文章选择了五个任务，分为以下三类

代码理解任务：Clone Detection和Code Search 代码生成任务：Code Summary和Code Generation 自回归任务：Code Completion 本文很重要的一个卖点就是更全面地利用了AST提供的代码结构信息。文章开头讲过，AST一般会被表示为一个Tree结构，不能直接作为Transformer类模型的输入，回忆一下前面提到的GraphCodeBERT，作者在以损失相当一部分信息的情况下让模型学习AST的数据流。为了能更加有效地利用AST，因此UniXcoder地作者构建了一个one-to-one的mapping function，将AST转为一个序列结构（flattened token sequence），然后和Code Comments一同编码，对这个mapping function的有效性的证明在文章的附录中。

模型结构方面，UniXcoder的一个卖点就是一个统一的，可以同时兼容Encoder-Only，Decoder-Only和Encoder-Decoder三种模式的CodePTM，相当于给模型添加了“开关”，来决定采用什么模式处理任务，用白话讲，就是通过使用三种不同类型的自注意力Mask策略来控制模型的行为。

既然同时能拥有三种模式，那么自然会有更多预训练任务，如下所示：

Masked Language Modeling（MLM），算是基本操作了。 Unidirectional Language Modeling（ULM），用于训练decoder-only模式，帮助完成自回归任务，对应的是右上三角masking。 Denoising Objective DeNoiSing (DNS)，可参考BART和T5，用于训练encoder-decoder模式，帮助完成生成任务，参考架构图中的encoder-decoder部分。除了上面这些任务以外，作者还提出了Code Fragment Representation Learning

其中包含了Multi-modal Contrastive Learning (MCL) 和 Cross-Modal Generation (CMG)这两个任务。前者采用了一个对比学习损失，后者是使用了一个统一的自然语言描述（comment），文中使用了fulcrum，即支点这个词，让模型学习到的代码表征在不同语言之间的对齐。

还需注意的一点就是，UniXcoder在预训练和微调这两个阶段中的输入形式有所不同，由于引入了Flattened AST，AST展开后的序列中被引入了大量额外的tokens（70% longer）会导致额外的开销。因此，在微调阶段UniXcoder仅使用AST的叶子节点，为了缓解这个gap，在预训练阶段作者设置了0.5的概率随机丢弃输入序列中的非叶子节点。

除了Clone Detection、Code Search、Code Summarization和Code Completion等任务上表现较好外，UniXcoder还提供了一个新任务：zero-shot code-to-code search，即在zero-shot的情境下，通过一个源代码的query在candidates集合中寻找语义相同的源代码，该任务使用的数据集是CodeNet，2021年的一篇数据集文章，用来衡量训练所得的code fragment embeddings的效果。

总结

上述对CodePTMs相关的内容大致上是六月中下旬赶一个文章时调研文献后总结的笔记，然后补充了点链接和细节，实验部分写的比较简略，是因为如果每个模型的实验都要全讲的话篇幅就太长了，而且这些任务都大差不差，每个模型都讲一遍冗余会比较多，之后可能会在其他文章补充。此外，有一些影响力比较小或者Task-specific的工作可能没完全覆盖到。总而言之，不论是CodeBERT开的新坑还是今天的SOTA模型UniXcoder，MSRA在这个领域还是完全dominant的存在。对于CodeBERT和GraphCodeBERT为首的大模型，复现预训练阶段的成本很高，不适合平民玩家，而且今年五月的IJCAI 22 Survey Track连CodePTMs的Survey工作都已经出了（Deep Learning Meets Software Engineering: A Survey on Pre-Trained Models of Source Code），可能短时间内出革命性的新模型的可能性不大，而且Code领域使用的这些方法终究还是跟着NLP走的，需要NLP提出新技术后Code领域才有跟进的可能。个人感觉接下来在这个相对较小但很卷的领域的研究热点可能会慢慢向可解释性和模型分析（Analysis of Models & Interpretability）方面转移，最近还研读了一些22年新出的Probing CodePTMs的文章，之后再补充。

希望本文对想熟悉代码表征预训练模型这块的朋友有所帮助。

Code预训练语言模型学习指南（原理/分析/代码）Part1

2022-07-06T20:00:03+08:00

Code预训练语言模型学习指南（原理/分析/代码）Part1

Introduction

自从2020年CodeBERT开了代码表征预训练模型（本文称之为CodePTM）这个新坑后，在短短两年的时间内出现了若干个程序设计语言（Programming Language，称之为PL，与Natural Language，也就是NL对应）语言模型。它们的共同特点是大部分用于处理PL（或Source Code）时所采用的技术是从NLP中的Transformer-based模型迁移而来，但这些CodePTMs又各有特点，从训练的角度出发即不同的预训练/微调策略，从数据的角度出发，比如是否使用了代码的结构信息，即抽象语法树（Abstract Syntax Tree，本文将其简称为AST）及其变体。而从架构出发，这些Code预训练模型大致可以被分为以下这三类：

encoder-only：CuBERT、CodeBERT、GraphCodeBERT等
decoder-only：CodeGPT、GPT-C等
encoder-decoder：PLBART、CodeT5等

本文对各个CodePTM建模编程语言的思想进行回顾，并简要分析了一下它们的特色。对文中提到的所有CodePTMs的描述主要从背景、预训练策略、微调策略以及下游任务这几个角度出发进行分析，考虑到这些模型之间都存在一些共性以及文章篇幅原因，文中略去了一些通用的处理手段和细节，因此对各部分的分析讲解详略不一，不过都保留了建模编程语言最核心的思想。阅读前需要对Transformer有一定的了解，考虑到单篇博客的长度，这些模型分在两篇博客中讲完。

CuBERT

ICML 2020 Learning and Evaluating Contextual Embedding of Source Code

CuBERT，即Code Understanding BERT，和后面提到的CodeBERT可被归为同一个时期的工作，虽是首个提出Code预训练模型的工作，但和CodeBERT相比，其影响力较小（我在写这篇文章的时候CuBERT引用还没过百），具体原因个人认为是它仅对Python语言进行建模（CodeBERT同时对6种编程语言建模），且它的下游任务和CodeBERT相比不太丰富，主要是以代码理解任务为主。

作者通过GitHub采集了7.4M Python语言编写的程序用于CuBERT的预训练，将基于Transformer类模型处理自然语言的手段迁移到了编程语言上，使用的模型架构和训练方式直接照搬了BERT-Large（24层16个注意力头），然后使用了一个处理过的ETH Py150数据集进行微调。

与此同时，作者还训练了一组Word2Vec embeddings、Bi-LSTM模型和Transformer模型用于比较。

就任务而言，作者构建了一个Benchmark，其中包含了：

五个分类任务（具体细节和描述可参考原文附录）
1. Variable-Misuse Classification
2. Wrong Binary Operator
3. Swapped Operand
4. Function-Docstring Mismatch
5. Exception Type
一个定位+修复任务（Variable-Misuse Localization and Repair），也是本文唯一一个非分类任务

就这几个下游任务而言，可以看到CuBERT主要还是在做代码理解领域的判别式任务，与后续出现的CodeXGLUE Benchmark比其在任务的数量和类型上都有局限性。而且，由于它仅采用了Python语言，和后面出现的各种CodePTMs比局限性比较大，因此仅做简单的科普。

CodeBERT

Findings of EMNLP 2020 CodeBERT: A Pre-Trained Model for Programming and Natural Languages

相比前面提到同期工作的CuBERT，CodeBERT的影响力比它大很多。一方面是因为它是多语言（multi-programming-lingual）模型，纳入了6个编程语言，另一方面是它和MSRA自己的CodeXGLUE Benchmark配套后在各个下游任务上被广泛使用。

除了预训练阶段的任务有变化外，CodeBERT的其他方面与自然语言中的BERT模型训练基本无异（其本质上的一个RoBERTa），CodeBERT使用了bimodal data（即PL-NL Pairs）进行了预训练，预训练数据的来源为CodeSearchNet数据集，其中有Python, Java, JavaScript, PHP, Ruby和Go这六种编程语言的2.1M bimodal data和6.4M unimodal codes（也就是没有对应comments的纯代码），这些数据的来源都是GitHub中的开源仓库，并且后续的很多工作也在预训练阶段用了CodeSearchNet数据集。

Masked Language Modeling (MLM)，算是Transformer类模型的预训练中最老生常谈的任务了，作者将其应用于基于bimodal data的训练

Replaced Token Detection (RTD)，迁移自ELECTRA，既可以利用bimodal data进行训练，还可以进一步利用unimodal data（比如是没有对应自然语言文本的code），具体细节可以参考ELECTRA原文。

实验部分做了Natural Language Code Search，个人认为文中没有添加更多下游任务是受到EMNLP的篇幅限制，使用CodeBERT可以在多个下游任务，如Clone detection（克隆检测）、Defect detection（缺陷检测）、Code summarization等上得到出色的结果，具体可参考CodeXGLUE，如下图所示

从CodeBERT开始，后续的CodePTMs就全部继承了对多个PL的支持，不过CodeBERT完全使用了建模自然语言的手段来为Code（或是说NL-PL Pairs）做预训练，忽视了代码的一个很大的特性，那就是结构信息，具体而言就是在编译器进行语法分析阶段生成的抽象语法树（Abstract Syntax Tree，本文称之为AST），紧跟着CodeBERT的GraphCodeBERT立刻填上了这个坑。

GraphCodeBERT

ICLR2021 GRAPHCODEBERT: PRE-TRAINING CODE REPRESENTATIONS WITH DATA FLOW

看名字就知道这是CodeBERT的后续工作，主要想法就是为CodeBERT添加代码的语法信息，使CodePTM可以显式学习代码的结构信息。

GraphCodeBERT基于数据流学习代码的表征，如下图所示

数据流的获得分为以下几个步骤

通过语法分析工具获得AST，原文中使用的工具是tree-sitter
从AST中提出变量，构成一个由变量组成的序列
从AST中抽取变量之间的依赖关系，文中称之为“value comes from”，构造数据流图

GraphCodeBERT在模型预训练阶段额外提出了两个在当时较为新颖的训练任务

Edge Prediction，即数据流图边预测，通过预测数据流图的边学习代码的结构信息
Node Alignment，即变量对齐，具体而言是学习数据流图中的某个node来自输入代码中的哪个code token 将它们和从CodeBERT（或是BERT or RoBERTa）继承下来的MLM任务一起优化。考虑到AST是一种图结构，为了让Transformer能适应其与一般序列结构的差异，作者修改了其注意力机制，主要是通过调整Attention Mask缩小感受野。

作者将其称为Graph-Guided Masked Attention，其中E代表的是数据流图的边，E’代表的是数据流图的节点和代码的对应关系边。

就下游任务而言，GraphCodeBERT文中主要完成了Natural Language Code Search、Clone Detection、Code Translation和Code Refinement这几个任务，它同样适用CodeXGLUE Benchmark中的其他任务，比如Code Summarization等。

GraphCodeBERT相较于前作CodeBERT解决了CodePTM只学习自然语义，而不学代码结构/语法的问题。但细心的读者或许能发现，学习数据流相较于学习AST本身有相当的信息损失，这也为之后的UniXcoder挖了一个小坑。

GPT-C

FSE/ESEC 2020 IntelliCode Compose: Code Generation using Transformer

GPT-C是为了代码补全（Code Completion）这个任务而设计的，作者认为之前的的代码补全工作有两点不同

根据上文的token来预测下个token，没有将代码的全文环境纳入考虑
多语言效果不佳

作者提出的GPT-C是GPT-2模型的变体，在一个大规模、无监督、多语言的数据集上从零开始训练。基于GPT-C，作者构建了一个代码补全Framework，称之为IntelliCode Compose，并对多种编程语言进行建模。作者将Sequence decoding的过程视为对树的搜索，搜到出现目标token为止。

虽说是多语言，但是使用的是Python, C#, JavaScript 和 TypeScript，和CodeXGLUE不同且少了两个语言。

就多语言模型的训练而言，作者提出了四个训练的策略

Language-agnostic baseline，即忽略掉编程语言的不同构建一个baseline多语言模型。
Language-type embedding，即加入一个向量来表示每种编程语言，和token embedding等相加。
Language specific control codes，每个输入的训练样本前拼接一个”lang ∗ remaining token sequence”字符串，∗即为编程语言
add a programming language classification task during model pretraining，即在预训练阶段加入一个分类编程语言的任务

关于IntelliCode Compose：作者将Sequence decoding的过程视为对树的搜索，搜到出现目标token为止

在文末，作者考虑到了模型的推理开销问题，还上了一个知识蒸馏，并且还讨论了一下模型基于K8S和VS Code的部署问题。

Code-GPT

Code-GPT是在CodeXGLUE中被提出的，没有单独成文，不要和GPT-C搞混了。作者实现它的目的是为了code completion 和 text-to-code generation任务。它就是一个由Code训练，与GPT-2完全同架构的12层Transformer Decoder模型，不过MSRA的研究者实现了两个版本

Pretrained from scratch：随机初始化，从零训练
CodeGPT-adapted：先使用一个GPT-2作为起始点，再持续使用Code进行训练，作者将这个方法称为“domain-adaptive”

更详细的内容可以参考CodeXGLUE原文的4.2节，作者在Huggingface提供了CodeGPT-small-java 和 CodeGPT-small-java-adaptedGPT2 这两个checkpoints，正常地使用transformers库加载就能使用了。

以上是5个代码表征领域的预训练模型的简介与简要分析，还有若干模型会在下一篇博客中继续讨论。

A Structural Analysis of CodePTMs

2022-06-12T20:00:03+08:00

[论文导读] What Do They Capture? - A Structural Analysis of Pre-Trained Language Models for Source Code

简述

这篇发表在ICSE 2022的文章来自华中科大，主要研究代码表征预训练模型（Code PTM）的可解释性。通读后发现其中的相当一部分参考了ICLR 2021的一篇对蛋白质Transformer（如TapeBert、ProtBert以及ProtXLNet等，挖个坑之后补）进行注意力机制分析的文章：

BERTOLOGY MEETS BIOLOGY: INTERPRETING ATTENTION IN PROTEIN LANGUAGE MODELS

其中的可视化代码，以及Attention Analysis部分，几乎是照搬了蛋白质文章的代码和公式（设置threshold来过滤低注意力值，并计算各个类的注意力分布）

本文大量内容是参考了前人在NLP和生信领域的工作，将它们直接迁移到了Code上。但不失为一种入门Code PTM可解释性这个小领域的渠道。

摘要与要点

本文进行了透彻的结构性分析，以期为CPTM提供可解释性，分为以下三个方面

attention analysis: Attention aligns strongly with the syntax structure of code
probing on the word embedding: Pre-training language models of code can preserve the syntax structure of code in the intermediate representations of each Transformer layer
syntax tree induction: The pre-trained models of code have the ability of inducing syntax trees of code.

这些发现可能代表着将code的语法结构融入预训练会帮助得到更好的代码表征

导言

本文将当前的代码表征研究方案分为了两类

监督学习模型：任务特定模型，也就是一个编码器网络 (e.g. LSTM, CNN, and Transformer) 为程序生成一个表征向量。
无监督/自监督学习模型：utilize word embedding techniques to represent source code，学习全局词向量，如基于AST的Code2Vec

We try to answer the following question: Can the existing pre-trained language models learn the syntactical structure of source code written in programming languages?

核心问题：现在的CPTM能否学习到源码中的句法结构，重申了三点contribution

Analyze the self-attention weights and align the weights with the syntax structure，即给定一个代码片段，如果二者有neighborhood关系，那么分配给他们的注意力会比较高，研究揭示了注意力可以捕获源代码的高维结构属性，比如motif structure
Design a structural probing approach to investigate whether the syntax structure is embedded in the linear-transformed contextual word embedding of pre-trained code models. 证明了代码的句法结构隐式地嵌入在了模型所学习到的向量中
Investigate whether the pretrained language models for source code provide the ability of inducing the syntax tree without training 说明了预训练模型的确能够在一定程度上学习到源代码的句法结构

作者还提到，本工作和其他以设计更好的网络以获得更好的源代码表示的工作是互补关系。

研究背景

Transformers的概述

主要是对Transformer的一般架构和计算方式做了简介，包括投影、注意力分数计算、Scaled Dot-Product Attention以及通过positional encodings为输入添加位置信息，没有提出新的概念，对这部分不了解的朋友可以参考下HarvardNLP的The Annotated Transformer这篇文章

Pre-Training Language Model

在代码表征领域，最先开这个坑的就是MSRA提出CodeBERT，随后出现了GraphCodeBERT、CodeT5以及PLBART等诸多预训练模型，最近比较新的是ICLR提出的UniXcoder（以后再讲，挖个坑）

值得一提的是这部分是对BERT模型的简介，提及的输入和训练任务都直接照搬了BERT的原文，但代码表征预训练模型的输入和训练任务与BERT有很大不同，以CodeBERT为例，其输入为代码片段和自然语言拼接而成，训练任务为ELECTRA。而GraphCodeBERT基于CodeBERT，在预训练阶段融入了Data-flow信息（通过AST提供）

\[s=[\mathrm{CLS}], \underbrace{w_{1}, w_{2}, \ldots, w_{n}}_{c_{1}},[\mathrm{SEP}], \underbrace{u_{1}, u_{2}, \ldots, u_{m}}_{c_{2}},[\mathrm{EOS}]\]

研究动机

早期的NLP工作指出了Transformer的自注意力机制能够帮助捕获一定的自然语言句法信息

上图为经过CodeBERT模型编码的一个代码片段的注意力可视化，（a）图展示了相应的注意力，（b）图展示了Transformer第五层的各注意力头的注意力分数平均值（c）图是这层第12个头的注意力权重，其中标注了一些红色的点为相应ast中有motif structure

本文作者对motif structure的定义是：AST树中包含非叶子节点和叶子节点的结构，可见示例图中（a）图中用深色标注的AST局部结构

示例图中的（b）图展示了自注意力分布的热力图，作者从其中挑选了一些“长方形”，将其归为一个group，结合AST的信息可以发现此热力图所反馈的信息可以和AST相对应，比如tokens在AST的同一个分支。最后（c）图挑选了一个Transformer层中的一个Head做了case study，根据我的经验应该是使用BertViz完成的绘图。

这里有一个重要的概念：motif structure，也就是作者为AST定义了一个特殊的语法结构，它包含了非叶子结点及其子节点，如上图的 (a) 中的if_statement部分。

CodePTMs的结构性分析

这部分在文章的第四章，使用了三个不同的结构分析方法，以解释CodeBERT和GraphCodeBERT两个模型，下图为三个方法的示例

注意力分析

每个Transformer层中都能获得一套输入的代码的注意力，设计了一个indicator函数𝑓 (𝑤𝑖, 𝑤 𝑗 )，判断两个输入token是否有syntactic relation（句法关联），作者定义了syntactic relation，即 𝑤𝑖 和 𝑤𝑗 在AST中有相同父节点。

\[\begin{equation}p_{\alpha}(f)=\frac{\sum_{c \in C} \sum_{i=1}^{|c|} \sum_{j=1}^{|c|} \mathcal{1}_{\alpha_{i, j}(c)>\theta} \cdot f\left(w_{i}, w_{j}\right)}{\sum_{c \in C} \sum_{i=1}^{|c|} \sum_{j=1}^{|c|} 1_{\alpha_{i, j}(c)>\theta}}\end{equation}\]

公式中的theta为一个阈值，用于过滤掉注意力权重较低（低置信）的token pairs，上面这个公式中相应的注意力仅仅取决于权重的绝对值。因为这些head注意在前一个或是后一个code token，它并不会考虑到code token的内容，因此不会和整个代码片段的句法结构匹配。

（这块的分析简直和BERTOLOGY MEETS BIOLOGY一模一样）

所以进一步调研了注意力的变化性（attention variability），用来衡量对于不同的输入，注意力怎么变化，公式如下

\[\begin{equation}\text { Variability }_{\alpha}=\frac{\sum_{c \in C} \sum_{i=1}^{|c|} \sum_{j=1}^{|i|}\left|\alpha_{i, j}(c)-\bar{\alpha}_{i, j}\right|}{2 \cdot \sum_{c \in C} \sum_{i=1}^{|c|} \sum_{j=1}^{|i|} \alpha_{i, j}(c)}\end{equation}\]

（我觉得这部分完全参考了 Analyzing the Structure of Attention in a Transformer Language Model）

使用单个token pair的注意力分数减去所有注意力分数的均值，只选取了前10个token来保证每个position有足够多的数据，这些位置信息在整个序列中（看起来）是一致的，作者认为变化性的较高则为content-dependent head，较低变化性则为content-independent head

Structural Probing on Word Embedding

这部分使用了Structural Probing的分析方法来检查预训练模型是否把句法结构嵌入在上下文中的word embedding中（白话讲就是训练出来的word/code embedding中是否含有句法信息）。该方法的核心概念是（AST的）树状结构在被嵌入一个新的空间后，两个词向量之间的欧氏距离和两个词在语法树之间的边数量对应。

上图的简介图（a）和（c）演示了对代码的Word Embedding的Structural probing

此处学习了一个mapping function，使用代码序列作为输入，模型的每个层生成词向量，然后计算二者在高维空间中的distance。作者认为，如果Vf和Vi的欧式平方距离接近2，那么语法树的结构被较好地保留

\[\begin{equation}d_{B}\left(\mathbf{h}*{i}, \mathbf{h}*{j}\right)^{2}=\left(B\left(\mathbf{h}*{i}-\mathbf{h}*{j}\right)\right)^{T}\left(B\left(\mathbf{h}*{i}-\mathbf{h}*{j}\right)\right)\end{equation}\]

参数训练的loss function，两个distance，第一个表示AST中code token的距离，第二个表示词向量的距离，第一个sigma为所有训练序列的平均distance，第二个sigma为代码序列中所有可能的二元组组合，训练目标就是通过误差反向传播更新映射函数B

\[\begin{equation}\min *{B} \sum*{c \in C} \frac{1}{|c|^{2}} \sum_{i, j}\left|d_{T^{c}}\left(w_{i}^{c}, w_{j}^{c}\right)-d_{B}\left(\mathbf{h}*{i}^{c}, \mathbf{h}*{j}^{c}\right)^{2}\right|\end{equation}\]

Syntax Tree Induction

这一部分研究预训练模型在不训练的情况下引导句法结构的能力

两个code tokens之间的“距离”接近（如注意力分布类似或是表示类似），那么它们应该在语法树中较为接近，比如有公共父节点。此处的假设是，如果源于预训练模型的语法树与gold standard的语法树很相似，我们可以合理的推导出预训练模型保留了句法结构信息这个结论

这里有一个概念，文章没有讲清楚，那就是Gold Standard指代的是什么

我个人的理解：预训练模型得到的token embedding的距离关系和实际AST里两个token之间的距离关系是一致的

通过保证token embedding的距离关系来验证没有通过树结构就学到语法了

实验设计和结果

作者在这里以三个Research Question的形式展示了实验的效果

RQ1: Attention Analysis

这张图展示了CodeBERT和GraphCodeBERT的注意力是如何与AST对应的，其中的色块是AST中连接了motif structure高置信度的注意力权重的proportion，柱状图展示了每个层的最大值

RQ2: Probing on Word Embedding

probing中的python语言的斯皮尔曼系数

RQ3: Syntax Tree Induction

上图为一个针对CodeBERT模型的Case study，比较了是否注入了bias，从图中可以看到CodeBERT能捕获多个motif structure，说明了syntax tree induction的有效性

本节小结：

代码的语法树可以由代码表征预训练模型induce得到
从注意力信息中抽取语法树比从CodePTM的上下文表示中抽取更有效

Limitations and Future Work

进一步的研究

预训练的另外几个方面

Control-flow graphs (CFGs)
Data-flow graphs (DFGs)

更多预训练模型

本文只研究了CodeBERT and GraphCodeBERT的表征，言下之意：这两个模型都是Encoder-only的模型，其他架构的模型如PLBART，CodeT5也可以整一发，还有一些经典模型，比如把LSTM和CNN + 注意力模型应用在代码的处理上也可以使用类似的分析方法。

Structural Analysis

本文的Structural probing相对简单，用一个更深的网络也许可以获得更好的映射

树结构

所涉及的Right-skewness bias是用于NLP的，或许可以使用AST结构来补充

回顾一下，本文从三个角度对代码表征预训练模型进行了分析，把一些NLP中的可解释性分析方法迁移到了Code领域，并且融合了生信领域的一些工作。不过本文并没有基于这些发现改进模型（比如给Code的各种下游任务提点）

后记

补充一下注意力权重的可视化策略，之前提到过这篇文章的注意力可视化可能用了BertViz，我个人也觉得BertViz非常的好用，Github给的demo可以支持交互效果，而且如果报告/文章版面够大的话，还可以这么玩（选择neuron view）

华东师大本科毕业设计模版（Class of 2022）

2022-03-28T10:20:37+08:00

华东师范大学本科毕业论文（设计）的TeX模版已经好几年没人更新了，为了能保持排版规范和一致性，我对老LaTeX模版中的一些细节进行了修正，并对应word模版修改了层次结构，再添加了一些新功能。

话不多说，先上项目地址：QiushiSun-ECNU-Undergraduate-Thesis-Template-2022

1. 基于老模版的修改

本模板为了迎合2018级（2022届）华东师范大学本科生毕业（论文）设计的模板需要，基于 YijunYuan/ECNU-Undergraduate-LaTeX 和 Koyamin/ECNUThesis-Undergraduate 进行了修改，让同学们可以最大限度地节约排版时间。

修改细节

包括

修改了页眉的文章title说明
修改了封面、中英文摘要的字体
支持插入（更漂亮的）代码块
新增了插入图片的Bicaption以及表格的Bicaption，提供中英文文字说明
重新设置了TOC(Table Of Contents) 的深度
调整 itemize 环境中的条目之间的间距
使用了gb7714-2015引用规范

更新

2022/3/30：添加了生僻字支持，字体地址：https://github.com/micmro/Stylify-Me/blob/master/.fonts/SimSun.ttf （若出现了生僻字输出错误再安装该字体）
2022/4/8：修正了section/subsection/subsubsection后出现多余”.”的问题，并添加了此部分示例
2022/4/17：在目录前添加了诚信承诺书，在使用时把Integrity.pdf替换为签名好的pdf文件（命名为Integrity.pdf）即可。
2022/4/17：修改了四级标题为*.*.*.*形式，与word模板保持一致。
2022/4/20：修改了表格Caption的位置，与word模板保持一致。
2022/4/22：调整了页边距，上：2.5cm，下：2.0 cm，左：3.0cm，右：2.5 cm以与word模板保持一致，修正了引用会议论文时缺失地址导致出现[S:n]占位的情况。

说明

Attention is all You need!

本模版只能使用 XeLaTeX 进行编译，使用其它 TeX 引擎将会导致不可避免地编译失败或是输出异常。
一般情况下，不需要修改.cls文件

使用环境

使用 XeLaTeX2020 和 XeLaTeX2021 编译器均能编译成功，本地配置环境有困难但网络环境稳定的同学建议使用Overleaf。

2. 如何在iPad端轻松加愉快地使用

善用PWA功能（它本质上还是个浏览器），首先在Safari浏览器中打开Overleaf，选中项目

点击分享按钮，再点击“添加至桌面”

就可以愉快的玩耍了

配置LaTeX Beamer的小技巧

2022-03-22T12:11:36+08:00

分享一些在配置LaTeX Beamer时发现的小技巧

最近为了答辩，魔改了一个有些年份但是自己很喜欢的Beamer模版，因此分享一些在配置中不容易发现的小技巧。

1. 控制封面页的Subtitle

如题所示，LaTeX Beamer往往只支持两级标题，但是如果确有需要，可以在subtitle命令内部设置另一个大小字体的文本并且换行达成。可以使用以下命令

\subtitle{\tiny{Knowledge Distillation based on Programming Languages Pre-Trained models and Its Application}\\[0.8em] \scriptsize{中期进度汇报}}

效果预览

2. 优雅地在BibTeX中引用网页

一般技术博客或网页不会像Research Gate这样的Paper Repositories一样为你生成Bibtex，因此很多时候需要自己动手。

@misc{T-NLG,
    author = "Corby Rosset",
    title = "Turing-NLG: A 17-billion-parameter language model by Microsoft",
    howpublished = "Website",
    year = {2020},
    month = {3},
    note = {\url{https://www.microsoft.com/en-us/research/blog/turing-nlg-a-17-billion-parameter-language-model-by-microsoft/}}
}

How do you get nicely formatted URLs in the bibliography?

3. 如何让caption换行再居中

有时候为了美观，在遇到Caption太长需要换行的时候可能会考虑让未填充完一整行的内容居中，但因为Beamer中不常见太长的Caption，因此以Article来举例（二者的使用方法是一样的）

上图为默认的换行方式，可以仿照下面的命令来调整居中，但是因为centering和换行符的优先级问题，因此换行符需要protect

\bicaption{\centering 教师模型在POJ-104数据集和Big Clone Bench数据集微调克隆检测任务的过程}{Performance on the POJ-104 \& Big Clone Bench Dataset, by Fine-Tuning Teacher Nets on \protect\\ \centering Clone Detection Task}

4. Beamer 分栏环境下使用脚注

在Beamer中使用columns环境进行分栏的话，需要特别注意footnote的位置，为了搞清楚这个footnote到底是属于某个column还是整个page，需要显示标注，以下是一个错误示例（在column中单单使用了\footnote命令）

使用以下命令显式声明footnote所对应的内容在整张slide的底部出现

\caption{\scriptsize CNN vs RNN vs Self-Attention vs Fully Connected\footnotemark}

\end{columns}  %分栏环境结束
\footnotetext[1]{$N$代表序列长度，$D$为维度，$K$为卷积核大小}
\end{frame}

5. 调整Beamer插图Caption的大小

有时候想要调整一下Caption的大小，但由于大部分页面都会统一Caption比字符小2号，因此一个个修改似乎是治标不治本，而且在caption命令的内部调整偶尔会导致奇怪的错误。查阅手册后发现Beamer和Article一样支持全局修改。

因此，直接使用下面这个全局命令调整吧

\captionsetup{font={scriptsize}}

看下将默认大小调整为scriptsize的效果。

(Xe)LaTeX小技巧

2022-03-19T10:20:37+08:00

分享一些在配置毕业论文模版时发现的(Xe)LaTeX小技巧

最近在配置2022年的毕业论文 LaTeX 模版，在GitHub上找了多个老模版，都无法满足今年的文章格式要求（参考了教务老师提供的Word模版），因此分享一些在配置模版中不容易发现的小技巧。

1. 控制目录的深度

如题所示，LaTeX中的TOC(Table Of Contents) 深度可以依据你的需求来控制深度，默认为Chapter + section + subsection，如下

可以使用命令

\setcounter{tocdepth}{1}

来缩减目录的深度

这个条目中的参数对应的目录深度如下

Param	Depth
-1	part
0	chapter
1	section
2	subsection
3	subsubsection
4	paragraph
5	subparagraph

2. 调整Itemize项之间的间距

$\LaTeX$ 默认的itemize条目项间距很大，插入下列itemize代码

\begin{itemize}
    \item Microsoft CodeXGLUE任务数据集，其包含了xx条从GitHub的开源仓库中所采集的函数
    \item 华东师范大学数据科学与工程学院水杉码园数据集，其包含了约100,000个由数据学院学生在Online Judge平台上提交的代码片段。
\end{itemize}

Itemize的效果如下所示

使用以下命令来修改itemize的间距

\usepackage{enumitem}
\setenumerate[1]{itemsep=0pt,partopsep=0pt,parsep=\parskip,topsep=5pt}
\setitemize[1]{itemsep=0pt,partopsep=0pt,parsep=\parskip,topsep=5pt}
\setdescription{itemsep=0pt,partopsep=0pt,parsep=\parskip,topsep=5pt}

查看缩减行间距后的效果

3. 为图片添加双语说明

当前的毕业论文模版要求每张插图都需要双语Caption（虽然我不懂这是为什么…），但既然要求如此，那就需要在一般的Caption上做一些修正

需要先导入一个额外的包

\usepackage{bicaption} %caption的扩展package
\captionsetup[figure][bi-second]{name=Figure}%将英文图的开头设定为字符“Figure”

随后插图

\begin{figure}[H]
    \centering
    \includegraphics[scale=yourscale]{source/pic.png}
    \bicaption{卷积神经网络（忽略补全），循环神经网络和自注意力机制的比较}{Comparing CNN (padding tokens are omitted), RNN, and self-attention architectures}
\end{figure}

通过下图查看Bicaption的效果

如果有其他的新发现就会继续更新！

The Value of Research & Novelty in Science

2022-02-06T09:12:37+08:00

学习笔记：判断研究工作的价值，以及研究新意度（Novelty）的五大误解

本篇博客是基于李沐老师的视频：

总结的学习笔记

研究工作的价值

核心思想：用有新意的方法有效地解决一个研究问题

问题
1. 工程问题
  1. 如算法很占内存，代码是否能优化，实现方式是否能优化
  2. 如模型精度不高，那是否能多采样点数据
2. 研究问题
有效（相对地有效性）
1. 相对之前的工作，你一般无法彻底解决一个问题，相对之前的工作我是否能做提升
新意（Novelty）：对你的研究社区中的其他研究者而言，你用的方法别人没想到

研究工作的价值

新意度 x 有效性 x 问题大小 = 价值

每一项都可以分为三个级别：1，10，100

新意度	有效性	问题大小
1（说了你的方法，后面的文章结果都不用看了）	1（好那么一点点，多重复几次就差不多了）	1（对前面的工作在不好一个的点改进）
10（某一方面用了聪明的技术）	10（中等，可见的提升）	10（比如一个计算机视觉的子任务）
100（之前的工作没用过，打开了新世界的大门）	100（一个工作就能向前推5-10个点）	100（可以大到解决通用的人工智能）

如果一个工作能拿到两个10，那么值得一写，如果能拿到10，10，10就很不错，两个方向拉满就非常困难，三个方向都拉满即功成名就。

研究新意度（Novelty）的五大误解

文章链接：Novelty in Science，这篇文章是用来教育reviewer的。

作者背景：德国马普所智能系统研究院的创始人之一，研究方向是计算机视觉、计算机图形学等。

用来评价论文价值的公式对强理论性的工作并不适用，因为对一个理论问题来说，你很难判断他这个领域的大小，有效性也不是很好判断，因为一个定理总是正确的。所以理论研究者对一个文章的判断，作者经常用两个词：

深刻：你是不是揭示了一些本质的一些东西
优美：你的定理的本身和你证明，是不是有美感（与个人品味相关）

优美这个词的好处是他把技术性和复杂性从指标中剥夺出来了

参考：毕加索和伦勃朗，我们都能欣赏出美来，即使创作过程作品的复杂度有区别，创作的艰难度上有区别。

1. Novelty as Complexity：用复杂度衡量Novelty

The simplicity of an idea is often confused with a lack of novelty when exactly the opposite is often true. A common review critique is

The idea is very simple. It just changes one term in the loss and everything else is the same as prior work.

If nobody thought to change that one term, then it is ipso facto novel. The inventive insight is to realize that a small change could have a big effect and to formulate the new loss.

典型：只修改了损失函数

2. Novelty as Difficulty：用困难度衡量Novelty

Formulating a simple idea means stripping away the unnecessary to reveal the core of something. This is one of the most useful things that a scientist can do.

典型：Ian Goodfellow的GAN，着重解释对抗的思想，而不是为了效果堆砌复杂技术（比如把文中的MLP替换为CNN）

3. Novelty as Surprise：用惊讶来衡量Novelty

完全使用Surprise来衡量，那么会认为一个新的工作自然而然，人的思维就是这样的。

The idea is obvious because the authors just combined two well known ideas.

在你没有听到前，你大概率没想到过！

典型：MAE，就是简单的技术拼在一起，但是在这之前并没有人想到，所以它拥有Novelty。

4. Novelty as Technical Novelty：用技术新意来等价新意

典型：ImageNet，大家都是晚上抓图片然后人工标注，但是ImageNet大啊，大才能支撑深度学习中的各种算法。

此外，如果你把一个复杂的算法替换为简单的算法，而且能提供一些Insight，那当然也是有效的。

5. Novelty as Usefulness or value：用有效性等价新意

Lack of utility is indeed an issue but it is very hard to assess with a new idea. Reviewers should be careful here and aware that we all have limited imagination.

实用性的缺少不能代表新意度低，它的确是个问题，但是后面可能会被其他研究者玩出花来

总结：Novelty≠ Complexity, Difficulty, Surprise, Technical Novelty, Usefulness.

文章作者认为新意度，更多的是关于这个想法是不是优美的。