模型厂商，请教会AI说JSON-LD

前几篇讨论了JSON-LD作为数据总线的优势、借鉴CPU缓存架构构建记忆系统的方法，以及Oxigraph与Qdrant这对黄金搭档的协作模式。

评论区有人问：“既然JSON-LD这么好，为什么不直接让LLM生成JSON-LD呢？”

这个问题点出了核心痛点——当前LLM根本不熟悉JSON-LD。本文探讨：为何模型厂商应将JSON-LD纳入训练数据，以及如果LLM能像编写JSON一样自然生成JSON-LD，Gliding Horse（流马）平台会迎来怎样的变革。

一、现在的LLM，看JSON-LD如同看甲骨文

测试结果显示：让多个主流模型编写包含@context、@id、@type的JSON-LD文档，效果惨不忍睹：

• @context经常被写成@context（注意特殊引号）
• @id要么重复，要么缺失，要么生成无意义的字符串
• @type时而出现时而消失，类型名称常拼写错误

最极端的情况：模型直接输出一个普通JSON，并在上方加注释“这是JSON-LD”。

原因很简单：模型在训练时几乎没见过JSON-LD。训练数据以API文档（JSON）、配置文件（JSON）、网页数据（HTML）、代码（各种语言）、维基百科（Markdown/文本）为主。JSON-LD？那似乎是W3C语义网社区使用的格式，很少进入主流通用训练集。因此LLM对JSON-LD的理解仅停留在“某种以@开头的奇特JSON”层面。

二、因为这个“文盲”，系统被迫引入“翻译官”

在Gliding Horse（流马）平台中，JSON-LD是绝对核心。所有数据——Skill定义、任务元数据、对话记忆、设计文档——均以JSON-LD节点形式存储于Oxigraph图数据库中。但由于LLM不识别JSON-LD，不得不在LLM与图数据库之间增加一层“翻译引擎”。

流程如下：

LLM想读数据 → Rust引擎从Oxigraph取JSON-LD → 剥掉@context和@id 
→ 转成“技能：Python数据分析（IRI: skill:python-analysis）”纯文本 
→ 喂给LLM

LLM想写数据 → 输出普通JSON → Rust引擎解析 → 加上@context和@id 
→ 转成JSON-LD → 存入Oxigraph

这就像雇佣了一位只会英语的外国保姆，不得不在她与家人之间安排翻译。翻译劳累，用户心累。这套翻译层带来实际代价：

• 数百行Rust代码全用于“转换”这类低技术含量工作
• 每次转换均有信息损失——图中的语义关系在LLM眼中变为“相关技能：xxx”文本
• Token浪费在自然语言描述上，而非直接的IRI引用

三、若LLM原生支持JSON-LD，Gliding Horse（流马）将变成什么样？

畅想如下：

1. 翻译层直接移除 LLM直接读取JSON-LD，直接输出JSON-LD。中间数百行转换代码全部淘汰。系统架构瞬间清爽。

2. LLM自主“探索”知识图谱 当前LLM要查询“skill:rust-jwt-auth 需要哪些前置技能”，必须等待外部输入。未来LLM可在推理中自主规划：“看到 task:how 引用了 skill:rust-jwt-auth，让我查询它的 skill:requiresDirect……” 随即触发内部工具调用，获取相关子图，继续推理。LLM从被动的“信息接收者”转变为主动的“知识探索者”。

3. Token消耗再降低 现有做法将IRI翻译为自然语言：“技能：Rust JWT认证实现（IRI: skill:rust-jwt-auth）”。若LLM理解IRI，直接传递 skill:rust-jwt-auth 一个字符串即可。上下文中全是紧凑的IRI引用，无冗余自然语言解释。

4. Skill共享变为“复制粘贴IRI” 目前两个Skill间共享参数需在@context中映射，LLM完全不知。若LLM理解JSON-LD，它能自然理解：“哦，skill:sourceDataURI 在A中叫 input_file，在B中叫 data_path，但语义相同。” 鸭子类型真正发挥作用——无需Harness翻译，LLM自主完成语义匹配。

5. 多Agent协作直接使用图通信 当前Agent A完成任务后，Agent B需等待Harness将图变化翻译为文本告知。若LLM理解JSON-LD，Agent A写入 task:001 exec:status "completed" 后，Agent B直接在对话中接收该三元组更新，立即、自动、无歧义地调整自身计划。

四、给模型厂商的具体建议

在训练数据中增加JSON-LD看似小众需求，实则操作并不复杂：

1. 在代码生成数据集中混入JSON-LD 当前许多训练数据包含“生成JSON”任务。将其中一小部分替换为JSON-LD即可，让模型认识@context、@id、@type这些关键字。

2. 在RDF/知识图谱数据上做指令微调 Wikidata、DBpedia拥有海量JSON-LD格式数据。可进行指令微调，如“请将以下自然语言描述转换为JSON-LD格式”或“根据此JSON-LD文档回答问题”。

3. 在Agent相关数据中用JSON-LD定义工具 当前大多数Agent框架使用JSON Schema定义工具。实际上JSON Schema可以嵌入JSON-LD。训练模型时，让它学习理解和生成带@context的工具定义。

4. 操作就这么简单 无需专门为JSON-LD训练新模型。只需在现有训练管线中，将JSON-LD占比从“接近0%”提升至“偶尔可见”，LLM对其适应能力就会有质的飞跃。

五、最后说句掏心窝子的话

理解模型厂商的优先级列表很长——多模态、更长上下文、更快推理、更低成本……“支持JSON-LD”或许排在一千名开外。但真诚相信，JSON-LD是AI Agent走向真正智能的关键基础设施。它不是另一种数据格式，而是让数据变为图、让Agent乃至LLM模型间能相互理解、让记忆跨会话持久化的语义总线。

当前LLM如同一位聪明绝顶但只会英语的人。处理全球业务很强，但遇到西班牙语、中文、阿拉伯语仍需翻译。JSON-LD正是AI世界的“通用语”。

因此，诚恳呼吁模型厂商：教教LLM说“JSON-LD”吧。

Gliding Horse（流马）平台在线等，挺急的。