🤖 AI

Think in English, Answer in Korean: Efficient Adaptation of Multilingual Tool-Using Agents

本文介绍了由 Cohere 和 LG CNS 开发的混合推理模型 LuckyStar 111B，该模型通过特定的微调和量化策略，高效地将经过后训练的多语言基座模型适配于韩英企业级智能体，在保持通用指令遵循质量的同时，显著增强了函数调用和 NL2SQL 等工具使用能力，并兼顾了内存限制。

原作者： Utsav Garg, Sungjin Hong, Jason Jung, Justin Lee, Shaan Desai, Joon Hee Kim, Anirudh Shrinivason, Edmond Wen, Susie Park

发布于 2026-07-01

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Utsav Garg, Sungjin Hong, Jason Jung, Justin Lee, Shaan Desai, Joon Hee Kim, Anirudh Shrinivason, Edmond Wen, Susie Park

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

想象你有一个才华横溢、精通多种语言的助手，名叫 LuckyStar。这个助手规模宏大（拥有 1110 亿个“脑细胞”或参数），为大型企业工作。面临的挑战是：公司需要这个助手既足够聪明，能解决复杂的数学问题、编写计算机代码并与数据库（如 SQL）进行对话，同时又需要它运行快速、成本低廉，并且能够流利地使用韩语和英语交流而不产生混淆。

以下是研究人员如何构建并微调 LuckyStar 的故事，通过简单易懂的方式进行了解释：

1. 起点：一个聪明的基座

他们并没有从零开始构建一个全新的大脑（这就像是从教婴儿识字开始），而是从一个非常聪明、已经经过训练的模型 Command A 开始。你可以把这想象成聘请了一位已经完美掌握如何遵循指令的资深员工。他们只需要教这位员工一些新的、特定的工作技能即可。

2. “开关”技巧：混合推理

最大的创新在于给了这个助手一个由简单的“前导词”（对话开始时的简短指令）控制的心理开关。

模式 A（短跑选手）： 如果你问一个简单的问题，比如“天气怎么样？”，开关会告诉模型要快速且简洁。
模式 B（侦探）： 如果你问一个难题、数学题或复杂的数据库查询，开关会告诉模型要“大声思考”，在给出答案之前进行多步推理。
为什么这很重要： 他们不需要两个不同的机器人。一个机器人就可以通过根据提示词改变其“心态”，完美地胜任两项工作。

3. 语言谜题：用英语思考，用韩语表达

在训练过程中，他们发现了一个奇怪的故障。当他们用韩语向模型提问时，模型往往会开始用韩语思考，但随后却不小心用英语完成了回答。这就像一个在法语环境下学习的学生，最后写出的论文却是西班牙语。

为了修复这个问题，他们使用了一个聪明的策略：

他们教导模型使用英语进行思考（进行复杂的推理），因为数学和逻辑方面的训练数据大多是英文。
但如果模型没有用用户的语言进行最终回答，他们会严格惩罚它。
结果： 模型学会了用英语进行内部的“侦探工作”，但始终按照用户要求的语言提交最终报告。

4. “工具”训练：学习使用数据库

为了让助手擅长执行“智能体”（Agentic）任务（即使用 SQL 数据库等工具），他们必须非常小心。

冷启动问题： 起初，模型在编写数据库查询方面表现得很糟糕。这就像试图在一个人从未握过方向盘的情况下教他驾驶赛车。
解决方案： 他们使用了“尝试并拒绝”的方法。他们生成了数千个可能的答案，检查哪些答案确实有效（是“可验证的”），并且只将正确的答案反馈给模型进行学习。这在开始高级训练之前建立了强大的基础。

5. “话痨”问题：学会闭嘴

在教会模型成为一名优秀的侦探后，它变得有点过于话痨了。即使你只需要一个“是”或“否”，它也会给出冗长、啰嗦的解释。

修复方法： 他们使用了**偏好对齐（Preference Alignment）**技术。他们向模型展示了“好的、简洁的回答”与“坏的、冗长的回答”的示例，并告诉它：“我们更喜欢短的回答。”这使得模型在保持乐于助人的同时，不会显得烦人。

6. 硬件黑科技：把鲸鱼装进浴缸

这个模型非常庞大（1110 亿参数）。通常情况下，你需要一台巨大的、昂贵的超级计算机来运行它。

窍门： 他们使用了 4-bit 量化（4-bit quantization）。想象一下，你将一张高分辨率照片进行压缩，使其文件大小减半，但你仍然能完美识别出图片内容。
结果： 这使得这个庞大的 1110 亿参数模型可以在单张标准显卡（H100 GPU）上运行，且几乎不损失质量。这使得企业实际使用它变得更加便宜且容易。

结果总结

最终的模型 LuckyStar 111B 是一个实用的、双语（韩语/英语）的智能体，它能够：

比原始基座模型更好地解决数学和逻辑问题。
能够有效地与数据库对话并使用工具。
即使在用另一种语言思考时，也能正确使用用户的语言。
可以在单台服务器上运行，从而节省成本。

论文的结论是，对于企业级应用，你不一定需要从头开始构建一个完美的全新模型。相反，你可以拿一个聪明的现有模型，给它一个用于不同任务的“开关”，教它谨慎地使用工具，并对其进行压缩以实现高效运行。

技术摘要：高效适配多语言工具使用智能体 (LuckyStar 111B)

1. 问题陈述

在多语言环境下运行的企业级助手面临着一系列复杂的约束：它们必须基于私有数据进行推理，执行工具调用（如 SQL 或检索），并遵循严格的内存和推理预算。在韩-英双语场景中存在一个特定的挑战：智能体必须解析韩语请求，在以英语为主的 Schema 或文档上进行推理，执行工具，并返回带有数值依据的韩语答案。

现有方法通常需要从头训练模型，或为不同的工作负载（例如推理型与简洁交互型）维护独立的模型，这既昂贵又低效。此外，将后训练的多语言模型适配到可验证的智能体工作流时，往往会导致诸如语言漂移（韩语提示词导致英语回答）以及在经过推理优化后变得冗长的失败模式。目标是在内存受限的部署环境（例如单 GPU 推理）下，高效地适配大规模、经过后训练的多语言模型，以处理混合推理和工具使用。

2. 方法论

作者介绍了 LuckyStar 111B，这是一个基于 Cohere 全量后训练的 Command A 模型适配而成的 111B 参数双语模型。该团队并未采用从头预训练的方式，而是采用了三阶段适配流水线，在保留通用指令遵循质量的同时，增加了推理和工具使用能力。

2.1 混合适配流水线

核心设计选择是通过前导词（Preamble）条件的混合推理。该模型使用相同的权重支持两种运行模式：

推理模式（Reasoning Mode）： 由特定的前导词触发，诱发针对数学、工具使用和自然语言转 SQL (NL2SQL) 的逐步行为。
非推理模式（Non-Reasoning Mode）： 由不同的前导词触发，诱发针对标准用户交互的简洁响应。

训练流水线由以下部分组成：

混合监督微调 (SFT)： 数据集包含约 80% 的推理示例（数学、代码、工具使用）和约 20% 的非推理示例，以保留简洁的行为。对于推理任务，模型被训练在生成最终答案之前先生成中间步骤。
基于可验证奖励的强化学习 (RLVR)： 此阶段针对多步任务的正确性进行优化。
- 数据策展： 对于 NL2SQL，团队从 Spider、BIRD 和 SynSQL 中策划了 10 万个可验证的“提示词-查询”对，并筛选出输出在 1–500 个 token 之间的可执行查询。
- 冷启动解决方案： 由于基座模型在策划的 NL2SQL 集上的准确率低于 1%，团队利用最佳 N 采样拒绝采样（Best-of-N rejection sampling），结合强大的内部模型和开源模型，生成高质量的初始轨迹，用于 SFT 引导。
- 奖励函数： 根据基于规则的验证器或 LLM 评判器（Command A）的正确性分配二元奖励。
离线偏好对齐 (DPO)： 为了抵消 RLVR 引入的冗长问题，团队使用了低学习率的应用直接偏好优化 (DPO)。此阶段使用偏好对进行处理，其中直接答案被视为“选中”，而冗长的输出被视为“拒绝”，从而在不降低推理能力的情况下精炼聊天机器人行为。

2.2 多语言推理策略

早期实验显示，尽管提示词是韩语，但韩语提示词往往会导致推理过程和最终答案向英语漂移。

翻译尝试： 将英语推理过程翻译成韩语带来的改进微乎其微，这可能是由于自然度下降和学习信号减弱导致的。
混合语言策略： 团队采取了一种策略，即模型使用英语进行推理，但生成用户语言（韩语）的最终答案。
语言一致性惩罚： 在 RLVR 期间，如果最终答案的语言与提示词语言不匹配，则应用惩罚项（ $r_{penalty} = 0.5$ ），而中间推理过程保持为英语。这显著降低了语言不匹配率，从 SFT 阶段的 12.2% 降至 RLVR 阶段的 0.8%。

2.3 高效部署

为了解决内存限制问题，模型从 FP8 量化为 4-bit 权重。这减少了约 50% 的内存占用，使得 111B 参数的模型能够在单张 80GB H100 GPU 上运行。

3. 关键结果

适配后的 LuckyStar 111B 模型在保持通用多语言质量的同时，在工具使用和推理方面表现出显著提升。

推理与工具使用：
- 数学推理： 在 AIME 2024（69.3 对比 Command A 的 10.0）和 MATH 500（93.6 对比 76.2）上的 Pass@1 准确率有所提高。
- 函数调用： 在 BFCL v3 上得到提升（73.7 对比 13.3）。
- 企业级 NL2SQL： 在内部 150 个问题的基准测试中，从 7.3 提升至 38.0。
- LG 智能体评估： 在需要检索和 SQL 的 60 个业务/金融问题基准测试中，从 2.67 提升至 4.85。
- 4-bit 量化模型在这些基准测试中保持了与 FP8 模型相当的性能。
通用多语言质量：
- 模型保留了强大的指令遵循能力。在韩语基准测试（KMMLU、ARC-C、IFEval、MT-Bench）中，其得分达到或超过了其他强力的专有模型（如 GPT-4o、Claude 3.7 Sonnet）以及基座 Command A 模型。
- 英语性能保持稳健，MMLU (82.7) 和 ARC-C (93.8) 的得分与基座模型持平或更高。

4. 重要性与主张

本文声称提供了一个实用的方案，用于将经过后训练的多语言模型适配到内存受限部署下的可验证智能体工作流中。

混合推理： 使用前导词条件允许单个模型在简洁模式和推理模式之间切换，避免了为不同企业工作负载准备独立模型的需求。
失败模式分析： 作者识别并解决了扩展智能体系统中的三个关键失败模式：
1. NL2SQL 冷启动： 通过拒绝采样 SFT 引导 RL 解决。
2. 语言漂移： 通过 RLVR 期间的语言一致性奖励解决。
3. 冗长问题： 通过离线偏好对齐 (DPO) 解决。
部署可行性： 该工作证明，通过 4-bit 量化，111B 参数的模型可以有效地部署在单张 H100 GPU 上，且几乎没有损失基准测试质量，使先进的智能体能力在硬件有限的企业环境中变得触手可及。
关注点分离： 结果表明，将内部推理语言（英语）与面向用户的响应语言（韩语）分离，是多语言智能体的一种实用（尽管并不完美）的策略，尽管原生语言推理仍是未来的研究目标。

作者强调，虽然公开基准测试提供了可比性，但内部企业评估对于捕捉实现现实世界部署所需的特定工作流、Schema 约束和数值准确性要求至关重要。