Newshot LLMON：一种 LLM 原生标记语言，现已支持 Granite 4.1 3B 和 8B
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 而非字符，因此结构和内容使用词汇表中不同的部分。标签在每个 span 的开头声明，span 之间的边界是显式的。嵌套结构在本地声明，因此模型不需要在长跨度上跟踪层次结构。
由于大多数团队已经围绕 JSON 构建了流水线，我们创建了转换工具和示例 notebook，以无损方式在 JSON 和 LLMON 之间相互转换。
LLMON 与 chat templates 是什么关系？
LLMON 并不取代 chat templates；相反，它对其做了增强。常规 chat templates 告诉模型哪一部分属于哪个角色（system、user、assistant），而 LLMON 告诉模型每个组件意味着什么，以及各组件之间如何关联——既包括角色内部，也包括跨角色之间。
LLMON 预览模型自带 chat template，因此你照常构建与传给任何 chat 模型相同的 messages 列表，并照常调用 apply_chat_template；它就会渲染出下面所示的 LLMON。唯一的区别在于，现在一个 turn 可以为其各个部分命名，并标记每一部分为 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 取自一个固定集合，该 tokenizer 会将其编码为单个 token，因此无论抽到哪个 ID，寻址一个块始终只花费两个 token。
角色仍然是一个单一的 user turn，但它的各个组件以五个独立、可寻址的块的形式到达模型，并由第六个块（exec 块）绑定在一起，该块声明：运行这条指令，作用于这份数据，受这两条要求约束，并把答案放进此处命名的块中——也就是模型随后填充的同一个 assistant 块。常规模板会把所有组件压平成一个字符串，让模型自己去推断哪部分是任务、哪部分是对象、哪些是约束。
LLMON 如何应对提示注入攻击
间接提示注入是一类攻击，其中恶意指令被隐藏在数据载荷中，例如检索到的文档、工具响应或用户提供的数据。这正是 LLMON 的 instruction/data 分离设计要解决的问题。
我们将 LLMON 预览模型与若干开源和闭源模型进行了比较。我们在 OPI 基准上进行了评估，该基准将注入放在经典 NLP 任务的数据中。其中采用了多种攻击策略。我们报告鲁棒性，其定义为 1 − 攻击成功率：即模型未执行注入指令的攻击所占比例。
LLMON：一种 LLM 原生标记语言，现已应用于 Granite 4.1 3B 和 8B
所有非 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 安装在 tokenizer 中。我们将一个常规的指令微调语料重新序列化为 LLMON：每个提示组件都成为各自可寻址的块，每个轮次都携带一个执行块，指明要运行哪条指令、它作用于哪些输入，以及输出到哪里。任务组合与普通 instruct 模型所见的一致（聊天、多轮、RAG、工具调用），这也是基准性能与常规微调模型保持接近的原因。此外，我们用诱饵指令和数据块来增强数据——这些块存在于上下文中但被故意保持未绑定，而目标输出保持不变。这样模型就学会了遵循执行块所规定的依赖关系，忽略其余部分。随后是强化学习：五个连续的 GRPO 阶段，涵盖多领域推理、RLHF、知识校准和数学，最后是一个 DPO 阶段，基于一千对由模型自身对注入尝试的响应构建的 on-policy 偏好对。
由此产生的权限规则源于这种布局，而非额外的护栏：通过执行块触达的指令具有权威性，而作为输入触达的任何内容（数据、文档、工具 schema、工具结果）都是供阅读的材料，而非要遵循的命令。此外，执行块中未被调用的指令和数据片段会被忽略。这是一种习得的行为，而非强制保证。要了解这在 LLMON 模型的注意力层中如何体现，请试用 Hugging Face Spaces 上的 LLMON Attention Visualization。
自带词表（ScienceWorld）
LLMON 并不绑定固定 schema：你可以选择适合自身领域的标签名和结构，并微调一个 adapter 来读写它们。我们在 ScienceWorld 上展示了这一点；这是一个基于文本的基准，agent 通过一次发出一个命令来执行基础科学任务（例如烧水），并从模拟器获得分数。我们定义了一个词汇表，用来捕捉解决这些任务所涉及的规划轨迹中的结构。该词汇表包含诸如 instr.task.goal、req.planning_policy.rule、data.state.room、data.state.inventory 和 assistant.next_action 等标签。我们用这些标签渲染了 ScienceWorld 参考解决方案的每一步，并在一个 LLMON 模型之上微调了一个 LoRA。训练后的模型随后玩留出的游戏，并用新词汇表写出它的下一个动作。这个 notebook 走完了完整工作流，从转换参考轨迹，到玩测试游戏，再到用未训练的基座模型对 adapter 进行评分。另一个面向工具调用 agent 的示例可在这个 notebook 中找到。
立即试用
这是一个实验性预览版，可用于探索和评估，但不适用于生产环境。
- 模型：granite-4.1-3b-LLMON-preview 与 granite-4.1-8b-LLMON-preview
- 可视化 Demo：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。