IBM发布原生标记语言LLMON，化解提示词注入风险

在长上下文推理过程中，大语言模型的输入往往混杂着系统提示词、历史对话、外部检索文档、工具返回结果以及各类输出约束。这种高度复杂的上下文结构通常以隐式方式存在，或者被编码为 JSON 等非 LLM 原生的数据格式。由于缺乏明确的结构区分，模型不仅容易产生混淆，还极易受到间接提示词注入（Prompt Injection）攻击。

针对这一痛点，IBM 相关研究团队推出了专为大语言模型设计的标记语言 LLMON（LLM Object Notation，发音同 lemon），旨在向模型显式传递语义与上下文结构。同时，团队发布了基于 Granite 4.1 基础模型微调的两个实验性预览模型：granite-4.1-3b-LLMON-preview 与 granite-4.1-8b-LLMON-preview，并开源了配套的 GitHub 代码库。

为什么放弃 JSON？

JSON 最初是为代码解析器设计的，并不适合自回归因果语言模型。分词器（Tokenizer）无法原生遵循 JSON 语法，括号、引号、冒号等关键结构标记在正文中同样频繁出现。对大语言模型而言，文档正文内的引号与用于闭合字段的引号在 Token 层面完全相同；转义规则对解析器清晰明确，对模型而言却只是统计概率。

此外，JSON 的嵌套层级依赖括号匹配，而 Transformer 架构在长距离跨度下处理括号计数的能力较弱。

LLMON 采用了类似 XML 的标记设计，但其核心结构定界符均为分词器专用的预留特殊 Token，使结构与内容在词表层面彻底分离。各个数据块的边界清晰独立，嵌套结构在局部完成声明，模型无需跨长文本维护复杂的层次关系。为兼容现有生态，开源仓库中提供了转换工具，支持将现有 JSON 数据无损转换为 LLMON。

扩展 Chat Template：指令与数据绑定

LLMON 并非替代现有的对话模板（Chat Template），而是在其基础上进行语义增强。传统的模板仅区分角色（如 system、user、assistant），LLMON 则明确界定了各部分的语义角色以及跨组件的关联关系。

在调用时，开发者只需在常规 messages 列表中指定每个片段的类型（如指令、数据、约束条件），并标记 exec 状态：

messages = [ { "role": "user",
               "instruction": [{ "value": "写一段简短介绍", "exec": True }],
               "data": [{ "value": "IBM Company", "exec": True }],
               "requirement": [ {"value": "少于10个词", "exec": True},
                                {"value": "不要使用逗号", "exec": True}]
             } ]

模板会将输入渲染为包含唯一 ID 的独立可寻址数据块，并在末尾附加执行块（exec block）。执行块类似编程语言中的函数调用，显式指明“在指定数据上运行该指令，并受对应约束限制，结果输出到特定区域”。未被执行块引用的内容即使存在于上下文中，也会被模型主动忽略。

有效防御间接提示词注入

间接提示词注入通常将恶意指令藏匿于抓取网页、工具输出或用户数据中。在 LLMON 体系下，通过执行块调用的内容具备最高执行权限，而作为输入传入的数据、文档或工具结果仅被视为“可读素材”，不再具备指令属性。

在针对间接提示词注入的 OPI 基准测试中，非 LLMON 架构的模型普遍容易受到劫持。相较于测试中的顶尖前沿模型，LLMON 模型的攻击规避率高出 47%；与测试的最佳开源模型相比，攻击规避率提升达 95%，在静态注入测试下防御成功率接近 100%。

通用能力无损与自定义词表

安全性的提升并未牺牲基础任务能力。基准测试表明，搭载 LLMON 的模型在各项常规评估中的表现与 Granite 4.1 Instruct 保持一致。

在训练过程中，团队直接基于 Granite 4.1 基础模型进行后训练。通过在指令微调数据中引入干扰项（未绑定的多余指令与数据块），结合五阶段 GRPO 强化学习与直接偏好优化（DPO），让模型在注意力层学会选择性聚焦与忽略。开发者可通过官方提供的 LLMON 注意力可视化演示 直观观察这一机制。

此外，LLMON 支持领域定制。开发者可以根据具体业务场景（如具身规划、工具调用 Agent）定义专属标签结构，并通过微调 LoRA 适配器，让模型快速适应特定格式的输入与输出生成。