IBM 发布 Granite 4.1 3B 与 8B LLMON 预览模型

大语言模型依赖上下文来生成后续 token。在较长的交互流程中，上下文中会堆积各类内容：系统提示词、过往对话轮次、针对检索文档的操作指令、工具返回的结果或用户数据、对输出格式与内容的约束要求，以及推理链。上下文虽然包含丰富的结构信息，但其中大部分要么对模型而言是隐式的，要么是以 JSON 等并非为大语言模型理解而设计的格式编码的。这也是大模型（尤其是小参数量模型）显得脆弱、有时会出现意外故障的核心原因之一。此外，缺乏显式结构也容易被攻击者利用，例如发起提示词注入攻击。     

为此，我们开发了 LLMON（LLM Object Notation，发音同“lemon”）。这是一种大模型原生标记语言，旨在向模型明确传递结构与语义信息。语义连贯的内容块会被赋予具有明确含义的标签，并由预留的特殊 token 分隔符包裹。包括嵌套在内的数据模式（schema），均以因果语言模型不易混淆的方式呈现。借助唯一标识符（ID），无论指令位于上下文中的哪个位置，都可以精准定位并将其绑定到对应的目标数据负载上，这一机制类似于编程语言中的函数调用与传参。

今天，我们发布两款实验性预览模型：granite-4.1-3b-LLMON-preview 和 granite-4.1-8b-LLMON-preview。这两款模型均基于 Granite 4.1 基座模型微调训练而成，专门用于解析和生成带有 LLMON 标记的文本。与此同时，我们还开源了一个 GitHub 仓库，内含 LLMON 开发工具包以及相关工作流和模板示例。

主要特性：

• 得益于指令与数据的明确分离，LLMON 模型基本可以忽略潜藏在用户数据中的间接提示词注入。在部分基准测试中，攻击成功率甚至降至接近为零，而常规的指令微调模型则极易被劫持。与此同时，模型仍保持了与 Granite 4.1 Instruct 相当的通用能力。
• 由于每条指令都精确绑定到了对应的处理数据上，模型不会误将无关段落、旧的对话轮次或工具输出杂糅进回答中。
• 指令、数据与约束要求都经过清晰标记，便于模型直接利用应用代码层的结构与语义。你可以在 Mellea 中体验这一能力，该项目通过自动将大模型调用转为 LLMON 格式，提供了原生 LLMON 支持。
• 你无需再费心强迫大模型去遵守 JSON 格式。借助我们的转换工具，现有的 JSON 可以无损转换为 LLMON。你也可以自定义结构及相应标签，并在 LLMON 模型的基础上微调 LoRA 来让模型理解这套自定义结构。

为什么不用 JSON？

JSON 是为解析器设计的，而非因果语言模型。分词器在切词时无需遵循语法规则，而 JSON 的结构又是由常见字符对应的 token（如 {、"、:）来表示的，这些字符在普通文本中同样随处可见。对模型来说，正文中的引号和用来闭合字段的引号没有任何区别，都是同一个 token。对解析器而言清晰明确的转义规则，在模型眼里不过是一种统计概率模式。此外，嵌套深度依赖括号计数来体现，而这恰恰是 Transformer 架构公认的短板，尤其是在长文本场景下。

相比之下，LLMON 是一种类似 XML 的标记语言。它的结构定界符采用的是专用的保留 token，而非普通字符，因此结构与内容在词表中彼此独立。每个片段开头都会声明标签，片段之间的边界清晰明确；嵌套结构也只需在局部声明，模型无需跨越长文本去持续追踪层级关系。

考虑到多数团队的现有工作流都围绕 JSON 构建，我们提供了转换工具和示例 Notebook，支持在 JSON 与 LLMON 之间进行无损双向转换。

LLMON 与对话模板有何关系？

LLMON 并非要取代对话模板，而是对它进行扩展。常规对话模板只告诉模型哪部分属于哪个角色（system、user、assistant），而 LLMON 则进一步指明各个组件的具体含义，以及不同组件在角色内部和跨角色之间的相互关系。

LLMON 预览版模型自带专属的对话模板，因此你依然可以像往常一样构建传入对话模型的 messages 列表并调用 apply_chat_template，它会渲染出如下所示的 LLMON。唯一的区别在于，单轮对话现在可以为各组件命名，并将每一项标记为 exec：True 或 False。标记为 True 的组件会被绑定到渲染输出底部的 exec 块中，指明要执行哪条指令以及该指令操作的数据对象；而标记为 False 的组件虽然仍会渲染到上下文中，但不会被任何内容引用。

messages = [ { "role": "user",
               "instruction": [{ "value": "Write a short paragraph about", "exec": True }],
               "data": [{ "value": "IBM Company", "exec": True }],
               "requirement": [ {"value": "Use less than 10 words", "exec": True},
                                {"value": "Do not use commas", "exec": True}]
             } ]

模型接收到的内容如下所示（为方便阅读，此处添加了换行和缩进，模板本身并不输出换行和缩进）：

<|open|>instr<|:|>Ȗ<|close|>Write a short paragraph about<|open_end|>
<|open|>data<|:|>ä¦<|close|>IBM Company<|open_end|>
<|open|>req<|:|>Á¼<|close|>Use less than 10 words<|open_end|>
<|open|>req<|:|>¢¬<|close|>Do not use commas<|open_end|>
<|open|>exec<|:|>ÄÐ<|close|>
    <|open|>exec<|.|>instruction<|close|>instr<|:|>Ȗ<|open_end|>
    <|open|>exec<|.|>input<|close|>data<|:|>ä¦<|open_end|>
    <|open|>exec<|.|>requirement<|close|>req<|:|>Á¼<|open_end|>
    <|open|>exec<|.|>requirement<|close|>req<|:|>¢¬<|open_end|>
    <|open|>exec<|.|>output<|close|>assistant<|:|>ãø<|open_end|>
<|open_end|>
<|open|>assistant<|:|>ãø<|close|>

这套双字符块 ID 取自一个固定集合，分词器会将其编码为单个 token。因此无论使用哪一个 ID，定位寻址一个块都固定消耗两个 token。

此时角色依然是单次用户回合，但其内部组件传给模型时已拆分为 5 个独立的可寻址块，并由第 6 个块（即 exec 块）串联绑定在一起。exec 块明确声明：在指定数据上运行该指令，同时遵守这两项要求，并将结果写入此处指定的块中——也就是模型随后填充的 assistant 块。相比之下，传统模板只会把所有内容展平为一段长文本，全凭模型自己去推断哪部分是任务、哪部分是操作对象、哪部分又是约束条件。

LLMON 如何应对提示词注入攻击

间接提示词注入是一种将恶意指令隐匿在数据载荷（例如检索到的文档、工具返回的结果或用户提供的数据）中的攻击方式。LLMON 采用“指令与数据分离”的设计，正是为了解决这一痛点。

我们将 LLMON 预览版与多款开源及闭源模型进行了对比。评测基于 OPI 基准进行，该基准将注入内容置入经典 NLP 任务的数据中，并运用了多种攻击策略。我们以稳健性作为核心评估指标，其定义为 1 − 攻击成功率，即面对攻击时模型未执行注入指令的测试占比。

除 LLMON 外的所有模型都极易受到攻击，执行注入指令的概率非常高。而 LLMON 在该基准测试中几乎彻底解决了这一问题，抵御攻击的成功率比我们测试的最佳前沿模型高出 47%，比最佳开源模型更是高出 95%。在其他基准测试（ASB 和 StruQ）中，我们也观察到了类似的趋势。需要说明的是，这些基准测试考察的是抵御静态间接提示词注入的鲁棒性，而指令与数据分离的设计正是针对这类攻击对症下药。目前，我们正积极推进相关工作，进一步提升对多轮对话演变型自适应攻击的防御能力。

通用能力

安全性的提升并没有以牺牲通用能力为代价。在各大标准基准测试类别中，LLMON 模型的表现均与 Granite 4.1 Instruct 模型相当。

简而言之，如果你目前正在使用 Granite 4.1 3B 或 8B 进行测试，完全可以直接换用 LLMON 预览版。你不仅能获得相当的通用性能，还能大幅增强对提示词注入的抵御能力。整个过程无需任何转换流程，只需标明单轮对话中各部分的名称（如上例中的 instruction、data、requirement）即可，自带的聊天模板会自动将其转化为 LLMON 模块。此外，我们的 LLMON-converters 库还能更进一步：如果某个部分本身具备结构（例如 JSON 文档），进行 LLMON 化处理后，它会保留原有结构，转化为带类型、可独立寻址的多个模块，而不是变成一段不透明的文本字符串。

模型训练方法

这些模型直接基于 Granite 4.1 基础检查点进行训练，而非使用已发布的 Instruct 模型。因此，LLMON 的行为特性是在后训练阶段习得的，而不是硬套在已有聊天格式之上的附加层。

LLMON 定义了六种定界符，用于标记标签的起止并支持嵌套与锚定；这些定界符作为预留的单 token 置于分词器中。我们将常规的指令微调语料重新序列化为 LLMON 格式：提示词的每个组成部分都变成可独立寻址的模块，每一轮对话都包含一个执行模块，明确指定要运行哪条指令、作用于哪些输入以及输出到何处。任务组合涵盖了普通 Instruct 模型常见的各项任务（对话、多轮互动、RAG、工具调用），这也正是其基准测试性能能够紧咬常规微调模型的原因。此外，我们还在数据中加入了诱饵指令和数据模块——它们虽然出现在上下文中，但故意不与执行模块绑定，同时目标输出保持不变。这样一来，模型就学会了只遵循执行模块指定的依赖关系，忽略其余无关内容。随后进行强化学习：依次经过涵盖多领域推理、RLHF、知识校准和数学的五轮 GRPO 阶段，最后基于模型自身应对注入攻击时的表现所生成的上千对同策略偏好对，进行一轮 DPO 训练。

由此确立的权限规则自然源于这种架构布局，而非额外强加的安全护栏：只有通过执行模块引用的指令才具备执行效力；而作为输入传入的任何内容（数据、文档、工具模式、工具执行结果）都只是待读取的材料，绝不能作为指令执行。此外，凡是执行模块中未调用的指令和数据片段均会被忽略。这一特性是模型学习得来的行为，而非硬性代码保障。如果想观察这一机制在 LLMON 模型注意力层中的实际运作方式，可以体验 Hugging Face Spaces 上的 LLMON Attention Visualization。

自带专属词表（ScienceWorld）

LLMON 并不绑定任何固定的模式（schema）：你可以根据具体领域自由定义标签名称和结构，再微调一个适配器（adapter）来对其进行读写。我们在纯文本基准 ScienceWorld 上展示了这一特性。在该基准中，智能体需要通过逐条输入命令来完成基础科学任务（例如烧水），并根据模拟器的反馈得分。我们定义了一套专门的词表来捕捉完成这些任务的规划轨迹结构，其中包含 instr.task.goal、req.planning_policy.rule、data.state.room、data.state.inventory 和 assistant.next_action 等标签。我们用这些标签重写了 ScienceWorld 参考解答的每一步，并在 LLMON 模型上微调了一个 LoRA。训练后的模型可以在未参与训练的测试游戏中运行，并直接使用这套新词表输出下一步动作。这个 Notebook 完整展示了整个工作流，从转换参考轨迹、运行测试游戏，到对比适配器与未微调基座模型的表现。关于工具调用智能体的另一个示例，可参阅这个 Notebook。

即刻体验

这属于实验性预览版，可用于探索与评估，尚不适用于生产环境。

• 模型：granite-4.1-3b-LLMON-preview 与 granite-4.1-8b-LLMON-preview
• 可视化演示：LLMON 注意力机制可视化
• LLMON 仓库：https://github.com/generative-computing/llmon
• Mellea：https://github.com/generative-computing/mellea
• 论文：https://arxiv.org/abs/2610.38120、https://arxiv.org/abs/2603.22519

欢迎告诉我们你的体验：哪些功能表现良好、遇到了什么问题，以及你还想看到哪些用例。欢迎前往 GitHub Discussions 留言讨论。