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

IBM 团队在 Hugging Face 发布了 LLMON（LLM Object Notation），一种专为大语言模型设计的原生标记语言，并同步推出了基于 Granite 4.1 的 3B 和 8B 实验性预览模型。LLMON 旨在解决传统 JSON 格式在 LLM 上下文中的结构性缺陷，通过显式标记指令、数据和约束，提升模型对复杂上下文的解析能力。该方案显著降低了提示注入攻击的成功率，同时保持了模型的一般能力，为构建更稳健的 AI 应用提供了新的技术路径。

LLMON 解决上下文结构模糊问题

大语言模型在长轨迹生成中，上下文往往混杂了系统提示、历史对话、检索文档、工具响应及输出约束等多种组件。传统上，这些结构要么隐含在模型内部，要么使用 JSON 等并非为 LLM 设计的格式编码。这种缺乏显式结构的情况导致模型（尤其是小模型）变得脆弱，容易在意外情况下失败，甚至被攻击者利用进行提示注入。LLMON 作为一种 LLM 原生标记语言，通过有意义的标签和保留的特殊令牌分隔符，显式地向模型传达结构和语义。它允许通过唯一 ID 指向特定指令，并将其与数据负载绑定，类似于编程语言中的函数调用和参数传递，从而明确了组件之间的关系。

为何 JSON 不适合因果语言模型

JSON 是为解析器设计的，而非因果语言模型。在 JSON 中，结构由 `{`、`:` 等字符编码，这些字符在普通文本中也可能出现，导致模型难以区分结构符号和内容符号。例如，文档中的引号和关闭字段的引号对模型来说是相同的 token。此外，JSON 的嵌套深度依赖于括号计数，而 Transformer 架构在处理长跨度层级结构时表现较弱。LLMON 采用类似 XML 的标记，其结构分隔符是保留的特殊令牌，而非普通字符，使得结构和内容在词汇表中分离。标签在每个跨度开始时声明，边界明确，且嵌套结构在局部声明，无需模型在长跨度中追踪层级，从而降低了认知负担。

增强安全性与指令绑定机制

LLMON 的核心优势之一在于其安全性。由于指令和数据被显式分离，隐藏在用户数据中的间接提示注入攻击大多会被 LLMON 模型忽略。在部分基准测试中，攻击成功率降至接近零，而常规指令微调模型则容易被劫持。同时，LLMON 模型在保持 Granite 4.1 Instruct 模型一般能力的基础上，实现了这一安全提升。此外，通过明确标记指令、数据和需求，应用代码层的结构和语义可以被模型有效利用。无关的段落、旧的聊天轮次或工具输出不会因缺乏绑定而被错误地拉入答案，因为每条指令都精确绑定到其适用的数据上。

与聊天模板的集成方式

LLMON 并不取代聊天模板，而是对其进行丰富。常规聊天模板告诉模型哪部分属于哪个角色（如 system、user、assistant），而 LLMON 进一步告诉模型每个组件的含义以及组件之间的关系。LLMON 预览模型自带聊天模板，开发者可以像调用任何聊天模型一样构建消息列表并调用 `apply_chat_template`。主要区别在于，一个轮次现在可以命名其部分，并标记每个部分为 `exec: True` 或 `False`。标记为 `True` 的部分会被绑定到渲染输出底部的 `exec` 块中，指明要执行的指令及其操作对象；标记为 `False` 的部分仍渲染到上下文中，但不被任何指令引用。这种机制使得结构更加清晰，便于模型理解。

小编总结

对于国内从事 AI 应用开发的从业者而言，LLMON 提供了一种超越简单 Prompt 工程的结构化思维。虽然目前仅发布了实验性预览模型，但其核心思想——即通过显式结构标记来增强模型对复杂上下文的鲁棒性——值得借鉴。特别是在处理多轮对话、工具调用和 RAG 场景时，传统的 JSON 格式确实存在解析歧义和安全漏洞。建议开发者关注其 GitHub 仓库中的转换工具和 LoRA 微调方法，尝试在现有 JSON 管道中引入 LLMON 结构，以评估其在特定业务场景下的安全性和准确性提升。需要注意的是，目前该方案主要基于 IBM Granite 模型，其他模型是否适用需进一步验证。