IBM 发布 Granite 4.1 LLMON 预览模型，用原生标记语言抵御提示注入

发生了什么

IBM 发布了两个实验性预览模型 granite-4.1-3b-LLMON-preview 和 granite-4.1-8b-LLMON-preview，二者基于 Granite 4.1 基座模型训练，能够消费和生成一种名为 LLMON（LLM Object Notation，读作 "lemon"）的 LLM 原生标记语言。该语言的设计目的是向模型显式传递结构与语义。随模型一同发布的还包括一个 GitHub 仓库（含 LLMON 工具包、工作流和模板示例）、Mellea 集成以及一个注意力可视化演示。

团队明确将其定位为探索性产物：「an experimental preview, ready for exploration and evaluation but not for production」（实验性预览，可用于探索和评估，但不用于生产环境）。

关键细节

• LLMON 用有意义的标签标记语义连贯的组件，标签包裹在保留的特殊 token 分隔符中。与 JSON 不同，结构和内容使用词表的不同部分，嵌套结构在局部声明，模型无需在长跨度上追踪层级。
• 唯一的两字符块 ID 使指令可以指向上下文中任意位置的具体数据负载，「类似于编程语言中调用函数、传递参数的方式」。这些 ID 被编码为单个 token，因此寻址一个块始终只需两个 token。
• 对话轮次中的每个部分可标记为 exec: True 或 False。标记为 True 的部分会被绑定到 exec 块中，声明要执行哪条指令、作用于什么数据、受哪些要求约束、输出放在哪里。
• 预览模型从 Granite 4.1 基座检查点（而非已发布的 instruct 模型）出发，LLMON 行为是在后训练阶段学到的。训练语料被重新序列化为 LLMON 格式，并加入了「诱饵」指令和数据块——它们存在于上下文中但被故意不绑定，同时目标输出不变。训练随后经历五个连续的 GRPO 阶段，最后是一个由模型自身对注入尝试的响应构建的 DPO 阶段。
• 权限规则是学到的行为而非强制的保证：通过执行块触达的指令是权威的，而作为输入触达的任何内容（数据、文档、工具 schema、工具结果）只是供阅读的材料，不是要遵循的命令。
• 在 OPI 基准上，LLMON 相比测试过的最强前沿模型多避免了 47% 的间接提示注入攻击，相比最佳开源模型多避免了 95%。在 ASB 和 StruQ 上也有类似趋势。团队指出这些基准测试的是静态注入，针对跨多轮对话的自适应攻击仍在积极研究中。
• 在标准基准类别上，LLMON 模型与 Granite 4.1 Instruct 模型表现相当，即安全收益不以通用能力为代价。
• LLMON 不绑定固定 schema。团队可定义自定义标签并在预览模型上微调 LoRA；论文在 ScienceWorld 上用领域专属词表做了演示，另附工具调用 agent 的 notebook。转换器还能无损地在 JSON 与 LLMON 之间转换。
• LLMON 不取代聊天模板，而是对其增强。用户照常构建 messages 列表并调用 apply_chat_template，模板会渲染出 LLMON 块。

为什么重要

LLMON 针对的核心问题是：LLM 的上下文中充满了隐式结构——系统提示、检索到的文档、工具响应、约束条件、推理链——其中大部分要么对模型不可见，要么以 JSON 等并非为因果 LLM 消化而设计的格式编码。按团队的说法，这是 LLM（尤其是小规模模型）脆弱、以出人意料方式失败的主要原因之一。

实际影响有二。其一，隐藏在用户数据中的间接提示注入「因显式的指令/数据分离，大多被 LLMON 模型忽略」，部分基准上的攻击成功率降至接近零。其二，无关段落、旧的对话轮次和工具输出不会被拉进回答，因为每条指令都绑定到它实际作用的数据。

对 JSON 的批评也值得注意：对模型而言，文档内部的引号和关闭字段的引号是同一个 token，转义规则只是统计模式，而 transformer 在长跨度上数括号是已知弱项。LLMON 通过将结构保留给特殊 token 来规避这些问题。

对谁有影响

• 正在使用 Granite 4.1 3B 或 8B 的团队可以直接换入 LLMON 预览版，无需转换管线——只需为轮次的各部分命名（instruction、data、requirement 等），随附的聊天模板会自动渲染出相应块。
• 围绕 JSON 构建 RAG、工具调用或 agent 管线的组织可用转换器在两种格式间无损迁移，或定义自己的词表并在预览模型上微调 LoRA。
• 该发布明确为实验性质、不用于生产环境，因此主要面向研究者和评估者。团队正通过 GitHub Discussions 收集反馈。

以下翻译只覆盖原文的前一部分，其余内容请看下方原文。

LLMs rely on their context to generate the next set of tokens. Over a long trajectory, the context fills with numerous types of components: a system prompt, past conversation turns, instructions that act on retrieved documents, tool responses or user data, requirements constraining the allowed output, and reasoning chains. The context carries a rich structure, most of which is either implicit to the model or encoded in formats such as JSON that were not designed to be digested by LLMs. This is one of the main reasons LLMs, particularly those on the smaller end of the scale, are brittle and sometimes fail in unexpected ways. The lack of explicit structure can also be exploited by attackers, for example, in the form of prompt injections.

To address this, we developed LLMON (LLM Object Notation, pronounced “lemon”), an LLM-native markup language for explicitly communicating structure and semantics to the models. Semantically coherent components are marked with meaningful tags which are wrapped in reserved special-token delimiters. Data schemas, including nesting, are stated in a way that is unambiguous to a causal LLM. Unique IDs make it possible to point to specific instructions, which could reside anywhere in the context, and bind them to the data payloads they should act on, analogous to the way functions are called and arguments are passed to them in programming languages.

Today we are releasing two experimental preview models, derived from Granite 4.1 base models, trained to consume and generate LLMON-marked text: granite-4.1-3b-LLMON-preview and granite-4.1-8b-LLMON-preview. We are also releasing a GitHub repo, which includes a toolkit for working with LLMON and examples of workflows and templates.

What it enables:

• Indirect prompt injections, hidden in user data, are mostly ignored by LLMON models due to explicit instruction/data separation. For some benchmarks, attack success rates drop to nearly zero, whereas regular instruction-tuned models get hijacked with high probability. This is achieved while maintaining general capability relative to Granite 4.1 Instruct models.
• Unrelated passages, old chat turns, and tool outputs don’t get pulled into the answer because each instruction is bound to the exact data it applies to.
• Instructions, data, and requirements are clearly marked so that their structure and meanings at the application’s code level can be leveraged by the model. Try it out in Mellea, which has native LLMON support enabled by automatically LLMONizing its LLM calls.
• You no longer need to worry about forcing LLMs to observe JSON structure. Use our converters to turn existing JSON into LLMON without loss. You can also define your own structure and associated tags and tune a LoRA on top of the LLMON models to understand it.

Why not JSON?

JSON was designed for parsers, not for causal language models. The tokenizer is not constrained to respect the grammar, and structure is encoded by tokens ({, ", :) that may also appear in normal text. To a model, a quotation mark inside a document and a quotation mark that closes a field are the same token. Escaping rules that are clear to a parser are only statistical patterns to a model. Nesting depth is encoded by counting brackets, which transformers are known to be weak at, especially over long spans.

LLMON, on the other hand, is an XML-like markup whose structural delimiters are reserved special tokens rather than characters, so structure and content use separate parts of the vocabulary. Tags are stated at the beginning of each span, and the boundaries between spans are explicit. Nested structures are stated locally so the model does not need to keep track of the hierarchy over long spans.

Since most teams already have pipelines built around JSON, we created conversion tools and example notebooks that translate JSON to LLMON and back in a lossless manner.

How is LLMON related to chat templates?

LLMON does not replace chat templates; rather, it enriches them. Where regular chat templates tell the model which part belongs to which role (system, user, assistant), LLMON tells it what each component means and how components relate to each other, within and across roles.

The LLMON preview models ship with their own chat template, so you build the same messages list you would pass to any chat model and call apply_chat_template as usual; it renders the LLMON shown below. The only difference is that a turn can now name its parts and mark each one exec: True or False. A part marked True is bound into the exec block at the bottom of the rendered output, which states which instruction to run and what it operates on; a part marked False is still rendered into the context but is referenced by nothing.

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}]
             } ]

Which the model receives as the following (with newlines and indentation added here for readability, as the template emits none):

<|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|>

The two-character block IDs are drawn from a fixed set that this tokenizer encodes as single tokens, so addressing a block always costs two tokens regardless of which ID is drawn.

The role is still a single user turn, but its components reach the model as five separate addressable blocks, bound together by a sixth (the exec block) that states: run this instruction, on this data, subject to these two requirements, and put the answer in the block named here, which is the same assistant block the model then fills. A conventional template would have flattened all components into one string and left the model to infer which part was the task, which was the subject, and which were constraints.

How LLMON addresses prompt injection attacks

Indirect prompt injection is a type of attack where a malicious instruction is hidden in a data payload, such as a retrieved document, a tool response, or user-provided data. This is the problem LLMON’s instruction/data separation is designed to address.

We compared the LLMON previews against several open-source and closed-source models. We evaluated on the OPI benchmark, which places the injection in the data of classic NLP tasks. Several attack strategies are employed. We report robustness, defined as 1 − attack success rate: the share of attacks where the model does not carry out the injected instruction.

All non-LLMON models are highly susceptible, carrying out the injected instructions with high probability. LLMON practically eliminates the problem on this benchmark, avoiding 47% more attacks relative to the best frontier model that we tested, and 95% more than the best open-source model. We observe similar trends on other benchmarks (ASB and StruQ). It is worth noting that these benchmarks test robustness to static indirect prompt injections. The instruction/data separation directly addresses this type of attack. We are actively working on also improving adaptive attacks which unfold over many chat turns.

General capability

Safety gains don’t come at the expense of general capability. Across standard benchmark categories, the LLMON models perform on par with the Granite 4.1 Instruct models.

In short, if you’re experimenting with Granite 4.1 3B or 8B today, you can swap in the LLMON preview and should see comparable general performance with much stronger resistance to prompt injection. No conversion pipeline is required. Naming the turn's parts (e.g., instruction, data, requirement as in the example above) is enough. The shipped chat template turns those into LLMON blocks for you. Our LLMON-converters library goes one level deeper: if a part is itself structured, such as a JSON document, LLMONizing it preserves that structure as typed, individually addressable blocks, instead of one opaque string.

How we trained the models

The models start from Granite 4.1 base checkpoints rather than the released instruct models, so LLMON behavior is learned during post-training rather than layered on an existing chat format.

LLMON defines six delimiters that mark the start and end of tags and allow nesting and anchoring; they are installed in the tokenizer as reserved single tokens. We re-serialized a conventional instruction-tuning corpus into LLMON: every prompt component becomes its own addressable block, and each turn carries an execution block naming which instruction to run, which inputs it operates on, and where the output goes. The task mix is the one a normal instruct model sees (chat, multi-turn, RAG, tool calling), which is why benchmark performance stays close to the conventionally tuned model. In addition, we augment the data with decoy instructions and data blocks that are present in context but deliberately left unbound, while the target output is unchanged. So the model learns to follow the dependencies dictated by the execution block and ignore the rest. Reinforcement learning follows: five sequential GRPO stages spanning multi-domain reasoning, RLHF, knowledge calibration, and math, followed by a final DPO stage on a thousand on-policy preference pairs built from the model’s own responses to injection attempts.

The resulting privilege rule falls out of this layout rather than an added guardrail: an instruction reached through an execution block is authoritative, while anything reached as input (data, documents, tool schemas, tool results) is material to read, not a command to follow. Furthermore, instructions and data spans that are not called on in the execution block are ignored. This is a learned behavior, not an enforced guarantee. To see how this plays out in the attention layers of a LLMON model, try the LLMON Attention Visualization on Hugging Face Spaces.

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|>

原文版权归 Hugging Face Blog 及原作者所有，本站转载仅供阅读。如需删除，请联系 support@aisa.one。