跳到正文
RadarAI· Hugging Face 社区博客（混合发现）·· 3 小时前AI 评分64

IBM 发布 LLMON 标记语言及 granite-4.1-3b/8b-LLMON-preview 预览模型

AI 导读

IBM 发布 LLMON（LLM Object Notation）标记语言，以及基于 Granite 4.1 的 granite-4.1-3b-LLMON-preview 和 granite-4.1-8b-LLMON-preview 两个实验预览模型，用保留的特殊 token 显式标记指令、数据和约束，并通过执行块把指令绑定到对应数据。

正文 · AI 翻译

Hugging Face 社区博客·2026-11-13 03:07· 1 小时前AI 评分62

LLMON：一种 LLM 原生标记语言，现已应用于 Granite 4.1 3B 和 8B

AI 导读

IBM 发布 LLMON（LLM Object Notation）标记语言及基于 Granite 4.1 的两个实验预览模型 granite-4.1-3b-LLMON-preview 和 granite-4.1-8b-LLMON-preview，用保留的特殊 token 显式标记指令、数据和约束并绑定执行关系。

正文 · 原文

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

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

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

它带来了什么：

  • 隐藏在用户数据中的间接提示注入，由于显式的指令/数据分离，大多被 LLMON 模型忽略。在某些基准测试中，攻击成功率降至接近零，而常规指令微调模型被劫持的概率很高。这是在保持相对于 Granite 4.1 Instruct 模型通用能力的同时实现的。
  • 无关段落、旧对话轮次和工具输出不会被拉入答案，因为每条指令都绑定到它所适用的确切数据。
  • 指令、数据和要求被清晰标记，以便模型能够利用其在应用代码层面的结构和含义。可在 Mellea 中试用，它通过自动将其 LLM 调用 LLMON 化来启用原生 LLMON 支持。
  • 你不再需要担心强迫 LLM 遵守 JSON 结构。使用我们的转换器可将现有 JSON 无损转换为 LLMON。你也可以定义自己的结构和关联标签，并在 LLMON 模型之上微调 LoRA 以理解它。

为什么不用 JSON？

JSON 是为解析器设计的，而不是为因果语言模型设计的。分词器并不受语法约束，结构由 token（{、"、:）编码，而这些 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。

角色仍然是单个用户轮次，但其组件以五个独立可寻址块的形式到达模型，并由第六个块（exec 块）绑定在一起，该块声明：运行此指令，作用于此数据，受这两项要求约束，并将答案放入此处命名的块中，也就是模型随后填充的同一个 assistant 块。常规模板会将所有组件展平为一个字符串，让模型自行推断哪部分是任务、哪部分是主题、哪些是约束。

LLMON 如何应对提示注入攻击

间接提示注入是一种攻击类型，恶意指令被隐藏在数据载荷中，例如检索到的文档、工具响应或用户提供的数据。这正是 LLMON 的指令/数据分离设计所要解决的问题。

我们将 LLMON 预览版与若干开源和闭源模型进行了比较。我们在 OPI 基准上进行了评估，该基准将注入置于经典 NLP 任务的数据中。采用了多种攻击策略。我们报告鲁棒性，定义为 1 − 攻击成功率：即模型未执行注入指令的攻击所占比例。

OPI

所有非 LLMON 模型都高度易感，会以高概率执行注入的指令。LLMON 在该基准上几乎消除了这一问题，相比我们测试过的最佳前沿模型多避免了 47% 的攻击，相比最佳开源模型多避免了 95%。我们在其他基准（ASB 和 StruQ）上也观察到类似趋势。值得注意的是，这些基准测试的是对静态间接提示注入的鲁棒性。指令/数据分离直接针对这类攻击。我们也在积极改进针对跨多轮对话展开的自适应攻击的防御能力。

通用能力

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

Granite-4.1 vs LLMON

简而言之，如果你目前正在试用 Granite 4.1 3B 或 8B，可以直接换用 LLMON 预览版，应当能看到相当的通用性能，同时对提示注入的抵抗力强得多。无需任何转换流水线。只需为对话轮次的各部分命名（例如上例中的 instruction、data、requirement）即可。随附的聊天模板会为你将其转换为 LLMON 块。我们的 LLMON-converters 库则更进一步：如果某个部分本身是结构化的，例如一个 JSON 文档，LLMON 化会将其保留为带类型的、可单独寻址的块，而不是一个不透明的字符串。

我们如何训练这些模型

这些模型从 Granite 4.1 基础检查点出发，而非已发布的 instruct 模型，因此 LLMON 行为是在后训练期间习得的，而不是叠加在现有聊天格式之上。

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

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

Attention Demo

自带词表（ScienceWorld）

LLMON 并不绑定于固定模式：你可以选择适合自己领域的标签名和结构，并微调适配器来读写它们。我们在 ScienceWorld 上演示了这一点，这是一个基于文本的基准测试，智能体通过每次发出一个命令来执行基础科学任务（例如烧水），并从模拟器获得评分。我们定义了一套词汇表，用于捕捉解决这些任务所涉及的规划轨迹中的结构。该词汇表包含诸如 instr.task.goal、req.planning_policy.rule、data.state.room、data.state.inventory 和 assistant.next_action 等标签。我们用这些标签渲染了 ScienceWorld 参考解决方案的每一步，并在 LLMON 模型之上微调了一个 LoRA。训练后的模型随后进行留出游戏，并用新的词汇表写出其下一步动作。本 notebook 完整演示了整个工作流程，从转换参考轨迹到进行测试游戏，以及将适配器与未训练的基座模型进行评分对比。另一个面向工具调用智能体的示例可在本 notebook中找到。

立即试用

这是一个实验性预览版，可用于探索和评估，但不适用于生产环境。

告诉我们你的发现：哪些有效、哪些出了问题，以及你希望看到哪些用例。请发布在 GitHub Discussions 中。

来源：Hugging Face 社区博客 · huggingface.co

来源：RadarAI · aihot.news

Hugging Face开源生态安全对齐模型发布#模型发布#安全/对齐#开源/仓库#Hugging Face