🤖 machine learning

FusionFactory: Fusing LLM Capabilities with Multi-LLM Log Data

本文介绍了 FusionFactory，这是一个系统性框架及配套的 LLMFusionBench 基准测试，它利用多 LLM 日志数据，在查询、思维和模型层面融合互补能力，在满足实际服务约束的同时，在多样化任务中持续优于单一模型。

原作者： Tao Feng, Haozhen Zhang, Zijie Lei, Pengrui Han, Mostofa Patwary, Mohammad Shoeybi, Bryan Catanzaro, Jiaxuan You

发布于 2026-07-02

📖 1 分钟阅读☕ 轻松阅读

原作者： Tao Feng, Haozhen Zhang, Zijie Lei, Pengrui Han, Mostofa Patwary, Mohammad Shoeybi, Bryan Catanzaro, Jiaxuan You

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你拥有一个海量的对话库，里面记录了人们与许多不同 AI 助手之间的交流。有些 AI 擅长数学，有些是编程高手，还有些则是百科全书式的知识渊博。通常情况下，当你提出问题时，你只能选择其中一个 AI 来回答。但如果，你可以观察所有这些过去的对话，并将每一个 AI 最出色的部分结合在一起，变成一个超级智能的系统呢？

这正是这篇名为 FusionFactory 的论文所探讨的内容。作者构建了一个巨大的工具包，旨在研究如何利用这些 AI 的“日志数据”（即它们说了什么以及表现如何的记录），来找到将这些不同的 AI 大脑进行混合搭配的最佳方式。

以下是他们发现的简单拆解：

1. 问题所在：选择太多，问题只有一个

把 AI 世界想象成一家拥有 20 位不同厨师的餐厅。

厨师 A 做披萨最棒。
厨师 B 做汤最棒。
厨师 C 是甜点大师。

如果你点餐，你通常只能选一位厨师来负责你的整顿晚餐。但作者注意到，在现实世界中，公司经常会让所有厨师去做同一道菜，并记录下谁做得如何。于是他们问道：“我们能否利用这些记录，创造出一个‘超级厨师’，既能做出完美的披萨，又能做出完美的汤和甜点？”

2. 解决方案：FusionFactory（三种混合方式）

作者创建了一个名为 FusionFactory 的框架，它尝试了三种不同的组合方式，取决于你在何时进行混合。

第一层：“聪明服务员”（查询级融合 / Query-Level Fusion）

运作方式： 在你下单之前，一位聪明的服务员会先看你的需求。如果你要问数学题，服务员会立即把问题交给数学厨师；如果你要讲笑话，他们会交给喜剧厨师。
类比： 这就像一名交通警察，将车辆引导至最快的车道。
结果： 这是最便宜、最快的方法。它并不改变厨师，只是选择了最合适的那一个。因为它不会浪费时间让错误的厨师去尝试，所以非常节省成本。

第二层：“食谱书”（思维级融合 / Thought-Level Fusion）

运作方式： 这个方法不再仅仅是挑选一位厨师，而是去观察过去厨师们使用的最佳食谱。如果有 10 位厨师解决了某个难题，系统会阅读他们的步骤，总结出“解决这类问题的完美思考方式”，然后将这个总结交给正在为你服务的厨师。
类比： 想象你在烹饪，在开始之前，有人递给你一张便签，上面写着：“这是顶尖厨师解决这个特定问题的秘诀。”然后你根据这个窍门开始烹饪。
结果： 这成为了最终的赢家。它带来了性能的最大提升。这就像是在不重新训练厨师的情况下，给了他们一份关于最佳思考模式的“小抄”。

第三层：“学徒厨师”（模型级融合 / Model-Level Fusion）

运作方式： 这是重体力活。系统会提取 20 位厨师中最优秀的答案，并强迫一位特定的厨师通过学习来记住这些教训。这就像是一场漫长且昂贵的训练营。
类比： 你带了一位初级厨师，让他背诵所有大师的拿手好菜，直到他自己也成为大师。
结果： 这是效果最差的。由于试图同时学习太多不同的风格，这位“初级厨师”（模型）感到困惑，其表现甚至比直接挑选合适的厨师或给他们一份小抄还要差。

3. 重大发现：“并非万能药”

论文在 14 种不同类型的任务（如数学、编程、阅读和常识）上测试了 20 种不同的 AI 模型。

“小抄”（思维级）是 MVP： 对于大多数任务，给 AI 一个思考方式的总结（“食谱书”）比其他任何方法都有效。它既灵活又强大。
“聪明服务员”是预算之王： 如果你担心成本，只需让一个智能路由选择正确的 AI 即可。它的表现几乎等同于表现最好的单个 AI，但成本却只是其一小部分。
“训练营”（模型级）很棘手： 试图将所有知识合并到一个单一的 AI 模型中往往会失败。当“教训”来自 20 种不同的个性时，很难教会一个大脑变得全能。

4. 为什么这很重要

作者认为，我们不需要发明新的、复杂的 AI 模型就能获得更好的结果。我们已经拥有了一个金矿：不同 AI 过去对话的日志。

如果你有钱但追求速度： 使用**“聪明服务员”**（查询级）。
如果你想要绝对最好的答案： 使用**“食谱书”**（思维级）。
如果你想建立一个单一且永久的 AI： 请务必小心，因为**“训练营”**（模型级）目前可能并不值得投入精力。

简而言之，这篇论文告诉我们：不要只挑选一个 AI。去观察他们思考的记录，并利用这些记录来引导你当前的 AI。这就像是在你的 AI 回答之前，给它一本智慧之书去阅读，而不是强迫它去死记硬背整座图书馆。

技术摘要：FusionFactory：融合大语言模型能力与多 LLM 日志数据

问题陈述

大语言模型（LLM）的快速多样化导致了一个格局：不同的模型在不同任务上表现卓越（例如，代码生成 vs. 事实检索）。因此，从业者越来越多地在工作流中使用多个 LLM，从而产生了有价值的多 LLM 日志数据。这些数据由结构化的服务记录组成，包含来自多个模型的对齐查询-响应对，以及元数据，如模型身份、响应模式（直接响应 vs. 推理增强型）、推理成本和质量反馈。

尽管存在此类数据，但现有的集成多个 LLM 的方法通常仅孤立地处理流水线中的单个阶段：

查询级（Query-level）： 路由方法为特定查询选择最佳模型，但无法在选择之外进行能力融合。
思维级（Thought-level）： 提示策略聚合推理过程，但往往缺乏与其他融合阶段的系统性评估。
模型级（Model-level）： 蒸馏和模型合并将知识转移到单个模型中，但通常忽略了基于 API 服务中的特定约束或日志数据的细微差别。

目前存在一个关键差距，即如何理解如何利用相同的结构化多 LLM 日志数据，在不同的干预点（路由、提示和训练）上满足多样化的用户需求，特别是在模型权重不可访问（基于 API 的服务）的情景下。

方法论

作者提出了 FusionFactory，这是一个用于融合 LLM 能力的系统化框架，并由 LLMFusionBench 支持，后者是一个旨在跨三个不同阶段评估融合策略的大规模基准测试。

1. LLMFusionBench 构建

为了实现跨阶段比较，作者构建了一个基准测试，包含：

范围： 涵盖 6 个领域（数学、代码、常识推理、世界知识、阅读理解、流行知识）的 14 个任务。
数据： 来自 20 个开源 LLM（参数量从 8B 到 671B 不等）的响应，总计 1.03 亿个 token。
结构： 与标准数据集不同，每个条目是一个结构化日志元组 $(q, t, m, s, r, c, y, j)$ ，捕捉查询、任务、模型身份、响应模式、生成的响应、推理成本、特定任务的性能以及 LLM 评委评分。
双模式： 对于每个查询，模型都会生成直接响应和推理增强型（思维链）响应，以捕捉多样化的推理模式。

2. FusionFactory 框架

FusionFactory 在三个层面运行，对应于 LLM 流水线中的早期、中期和后期融合阶段：

A. 查询级融合（早期融合）

目标： 在生成之前，为特定查询选择最优的 LL 模型和响应模式。
机制： 路由器学习一个策略 $f_\phi$ ，将 $(query, task) $映射到动作$ a = (model, mode)$。
目标： 最大化平衡性能 ( $P$ )、成本 ( $C$ ) 和 LLM 评委质量 ( $J$ ) 的奖励函数：
$Reward = \alpha \cdot P - \beta \cdot C + \gamma \cdot J$
实现： 使用各种路由算法（KNN, SVM, MLP, BERT, GraphRouter）在不同的奖励权重场景（性能优先、平衡、成本优先、LLM 评委）下进行评估。

B. 思维级融合（中期融合）

目标： 通过注入可重用的推理模式来增强生成，而不修改模型权重。
机制：
1. 模板提取： LLM 摘要器从历史查询的前 $k$ 个响应（按性能或评委评分排序）中提取抽象的“思维模板”。
2. 检索： 对于新查询，通过嵌入相似度检索相似的历史查询。
3. 提示： 相应的思维模板被用作 few-shot 示例，以引导目标 LLM。
策略： 使用基于性能、基于 LLM 评委以及混合选择策略来选取前 $k$ 个响应进行评估。

C. 模型级融合（后期融合）

目标： 通过监督微调（SFT）将互补的能力整合到单个基座模型中。
机制： 来自多 LLM 日志的高质量响应（由性能或评委评分筛选）作为基座模型的训练数据。
策略： 将 Top- $K$ SFT（使用选定的多 LLM 响应）与 Top- $K$ 仅标签 SFT（仅使用标准答案/Ground Truth）进行对比，以分离出多 LLM 知识带来的收益。

关键结果

实验在完整的 LLMFusionBench 测试集上进行，将三个融合层级与最佳个体 LLM 及零样本基线进行了比较。

思维级融合实现最佳性能：
- 思维级融合（特别是使用全规模模型的混合策略）实现了最高的平均性能 (0.615)，超过了最佳个体 LLM (0.600) 以及其他融合基线如 LLM-Blender (0.603) 和适配后的 FuseLLM (0.557)。
- 在推理密集型任务（数学和代码）中，增益最为显著，这表明检索多样化的推理轨迹具有重要价值。
- 即使在控制了近乎重复的检索情况下，性能提升依然稳健，这表明其收益来自于可重用的推理模式而非简单的模型数据重叠。
查询级融合提供最佳成本效率：
- 查询级融合（通过 GraphRouter）提供了性能与成本之间的理想权衡。
- 在成本感知路由下，它实现了与最佳单模型相当的性能，但推理成本降低了约 10 倍（归一化单位下为 0.0184 vs. 0.1850）。
- 这证实了其在对降低 token 使用量至关重要的 API 化服务场景中的实用性。
模型级融合显示出有限的泛化能力：
- 模型级融合（SFT）收益有限，并且在某些领域（代码和世界知识）的表现甚至差于零样本基线。
- 作者将其归因于对日志数据中特定响应风格的过拟合，以及将异构任务行为抽象为单一参数集的难度。
- 值得注意的是，多 LLM SFT 的表现优于仅标签 SFT，这证实了多 LLM 日志包含了超越标准答案的价值知识，但整合过程引入了泛化挑战。
领域差异：
- 融合在世界知识和数学领域仅带来边际改进，这两个领域高度依赖严格的事实准确性和逻辑一致性，这表明目前的融合启发式方法在这些领域适用性较低。
- 以推理为主的任务（数学、代码）从思维级融合中获益最多，而知识密集型任务的结果则褒贬不一。

意义与主张

论文声称 FusionFactory 和 LLMFusionBench 提供了一个统一的、具备阶段感知能力的 LLM 融合视角，而这在以前是缺失的。

超越 API 兼容性： 虽然以往的工作侧重于仅限 API 的路由，但本研究证明了相同的结构化多 LLM 日志数据可以系统地在路由、提示和训练阶段进行评估。
决策框架： “融合阶段矩阵”揭示了并不存在单一的最优融合策略；选择取决于部署约束（如成本 vs. 准确度）和任务需求（如推理 vs. 召回）。
- 使用 查询级 用于成本敏感、高吞吐量的场景。
- 使用 思维级 用于在不进行模型重训的情况下最大化推理能力。
- 仅在严格需要单个可部署模型且离线训练可行时使用 模型级，同时承认其泛化限制。
实践基础： 该工作验证了多 LLM 日志作为融合多样化 LLM 能力的可扩展监督源的实用性，为未来必须在异构、真实世界服务环境中运行的系统提供了蓝图。

作者总结道，虽然思维级融合目前提供了最强的性能提升，但通过其框架进行的系统性比较，对于理解多 LLM 系统中灵活性、成本与泛化能力之间的权衡至关重要。