LLMON：一种面向大语言模型的原生标记语言

大语言模型（LLM）依赖其上下文来生成下一组词元。在一条很长的轨迹中，上下文会填入各种类型的组件：系统提示、过去的对话轮次、作用于检索文档的指令、工具响应或用户数据、约束允许输出的要求，以及推理链。上下文承载着丰富的结构，其中大部分要么是模型隐式理解的，要么以 JSON 等并非为 LLM 消化而设计的格式编码。这是 LLM（尤其是规模较小的一端）表现脆弱、有时以意外方式失败的主要原因之一。缺乏显式结构还可能被攻击者利用，例如用于提示注入（prompt injection）。

为了解决这个问题，我们开发了 LLMON（LLM Object Notation，读作 "lemon"），这是一种 LLM 原生标记语言，用于向模型显式传达结构与语义。语义连贯的组件会被有意义的标签标记，这些标签包裹在保留的特殊词元（special token）分隔符中。数据模式（包括嵌套关系）以一种对因果 LLM（causal LLM）而言无歧义的方式陈述。唯一 ID 使得指向特定指令成为可能——这些指令可以位于上下文中的任何位置——并将它们绑定到应当作用的数据载荷上，类似于编程语言中调用函数并向其传递参数的方式。

今天，我们发布两个实验性预览模型，它们派生自 Granite 4.1 基础模型，并被训练来消费和生成带 LLMON 标记的文本：granite-4.1-3b-LLMON-preview 和 granite-4.1-8b-LLMON-preview。我们还发布了一个 GitHub 仓库，其中包含用于处理 LLMON 的工具包，以及工作流和模板示例。

它带来了什么：

由于显式的指令／数据分离，隐藏在用户数据中的间接提示注入（indirect prompt injection）大多会被 LLMON 模型忽略。在某些基准测试中，攻击成功率降至接近零，而常规的指令微调模型被劫持的概率很高。与此同时，相对于 Granite 4.1 Instruct 模型，通用能力得以保持。

无关段落、旧聊天轮次和工具输出不会被拉入答案，因为每条指令都绑定到其所适用的确切数据。

指令、数据和需求都有清晰标记，因此应用代码层面的结构与含义可以被模型利用。你可以在 Mellea 中试用它，Mellea 通过自动将其 LLM 调用 LLMON 化，原生支持 LLMON。

你不再需要担心如何强迫 LLM 遵守 JSON 结构。使用我们的转换器，可以将现有 JSON 无损地转换为 LLMON。你也可以定义自己的结构和关联标签，并在 LLMON 模型之上微调一个 LoRA 来理解它。

为什么不用 JSON？#

JSON 是为解析器设计的，而不是为因果语言模型设计的。分词器并不受语法约束，结构由 {、"、: 等也可能出现在普通文本中的词元来编码。对模型来说，文档内部的引号和用于闭合字段的引号是同一个词元。对解析器而言清晰的转义规则，对模型而言只是统计模式。嵌套深度通过计数括号来编码，而 Transformer 已知在这方面较弱，尤其是在长跨度上。

相比之下，LLMON 是一种类 XML 标记，其结构分隔符是保留的特殊词元而非普通字符，因此结构和内容使用词汇表的不同部分。标签在每个跨度开头声明，跨度之间的边界是显式的。嵌套结构在局部声明，因此模型不需要在长跨度上跟踪层级关系。

由于大多数团队已经围绕 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 来自一个固定集合，该分词器会将其编码为单个词元，因此无论抽到哪个 ID，寻址一个块总是花费两个词元。

角色仍然是单个 user 轮次，但其组件以五个独立、可寻址的块到达模型，并由第六个块（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 定义了六个分隔符，用于标记标签的开始和结束，并允许嵌套和锚定；它们作为保留的单个词元安装到分词器中。我们将一个常规的指令微调语料库重新序列化为 LLMON：每个提示组件都变成自己的可寻址块，每个轮次都携带一个执行块，指明要运行哪条指令、它作用于哪些输入，以及输出到哪里。任务组合与普通 instruct 模型所见的一致（聊天、多轮、RAG、工具调用），这就是为什么基准性能保持接近常规微调模型。此外，我们用诱饵指令和数据块来增强数据：这些块存在于上下文中，但被故意保持未绑定，同时目标输出保持不变。这样模型就学会遵循执行块所规定的依赖关系，并忽略其余部分。接下来是强化学习：五个连续的 GRPO 阶段，涵盖多领域推理、RLHF、知识校准和数学，随后是一个最终的 DPO 阶段，使用一千个由模型自身对注入尝试的响应构建的 on-policy 偏好对。

由此产生的权限规则是这种布局的自然结果，而不是额外添加的护栏：通过执行块到达的指令具有权威性，而作为输入到达的任何内容（数据、文档、工具模式、工具结果）都是可供阅读的材料，而不是要遵循的命令。此外，执行块中没有被调用的指令和数据跨度会被忽略。这是一种习得行为，而不是强制保证。要了解这在 LLMON 模型的注意力层中如何体现，可以试试 Hugging Face Spaces 上的 LLMON Attention Visualization。

自带词汇表（ScienceWorld）#

LLMON 并不绑定固定模式：你可以选择适合自己领域的标签名和结构，并在适配器上微调以读写它们。我们在 ScienceWorld 上演示了这一点。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 Attention Visualization

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。