AI Radar — 每天的 AI 热点、模型与教程

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 取自一个固定集合，该 tokenizer 会将其编码为单个 token，因此无论抽取哪个 ID，寻址一个块始终只花费两个 token。

角色仍然是单个用户轮次，但其各个组成部分以五个独立可寻址的块到达模型，并由第六个块（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：每个提示组件都成为其自身可寻址的块，每一轮都携带一个执行块，指明要运行哪条指令、它作用于哪些输入以及输出去向何处。任务组合与普通指令模型所见的一致（聊天、多轮、RAG、工具调用），这也是基准测试性能与常规微调模型保持接近的原因。此外，我们在数据中加入了诱饵指令和数据块，它们存在于上下文中但被故意保持未绑定，而目标输出保持不变。因此，模型学会遵循执行块所规定的依赖关系，并忽略其余部分。随后是强化学习：五个连续的 GRPO 阶段，涵盖多领域推理、RLHF、知识校准和数学，最后是一个 DPO 阶段，基于一千对同策略偏好对，这些偏好对由模型自身对注入尝试的响应构建而成。

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

自带词表（ScienceWorld）

LLMON 并不绑定于固定 schema：你可以选择适合自己领域的标签名和结构，并微调一个适配器来读写它们。我们在 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。

IBM 发布 LLMON 标记语言及 Granite 4.1 预览模型