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（流马）会发生什么？
以下是具体构想。
- 直接砍掉翻译层。 LLM直接读取JSON-LD，直接输出JSON-LD。中间那几百行转换代码全部丢弃，系统架构瞬间变得干净利落。
- LLM自主“漫游”知识图谱。 当前LLM需要他人喂食才能查询“skill:rust-jwt-auth 所需的前置技能”。未来LLM可以在推理过程中自己规划：“我看到 task:how 引用了 skill:rust-jwt-auth，让我查一下它的 skill:requiresDirect……” 随即触发一次内部工具调用，返回相关子图，继续推理。LLM从被动的“信息接收者”进化为主动的“知识探索者”。
- Token消耗进一步降低。 目前出于安全考虑，必须将IRI翻译成自然语言：“技能：Rust JWT认证实现（IRI: skill:rust-jwt-auth）”。如果LLM能识别IRI，直接传递 skill:rust-jwt-auth 一个字符串即可。上下文里充满紧凑的IRI引用，不再有冗余的自然语言解释。
- Skill共享简化为“粘贴IRI即可”。 现在两个Skill间共享参数需要在@context中做映射，LLM完全不知情。若LLM理解JSON-LD，它能自动识别：“哦，skill:sourceDataURI 在A中叫 input_file，在B中叫 data_path，但语义相同。” 鸭子类型真正发挥作用——不再依赖Harness翻译，LLM自己完成语义匹配。
- 多Agent协作直接通过图通信。 目前Agent A完成任务后，Agent B需等待Harness将图变化翻译成文本才能知道状态。LLM若懂JSON-LD，Agent A写入 task:001 exec:status "completed" 后，Agent B在对话中直接接收三元组更新，立刻、自动、无歧义地调整自身计划。
四、给模型厂商的实操建议
在训练数据中加入JSON-LD听起来像个小需求，实现起来并不复杂：
- 在代码生成数据集中混入JSON-LD样本。 现有训练数据中很多包含“生成JSON”的任务。只需将其中一小部分替换为JSON-LD，让模型见识到
@context、@id、@type这些关键字。
- 在RDF/知识图谱数据上做指令微调。 Wikidata、DBpedia等拥有海量JSON-LD格式数据。用它们做指令微调任务，例如“请将这段自然语言描述转换成JSON-LD”、“根据此JSON-LD文档回答问题”。
- 在Agent相关数据中用JSON-LD定义工具。 目前多数Agent框架使用JSON Schema定义工具。JSON Schema完全可以嵌入JSON-LD。训练时让模型学会理解和生成带
@context的工具定义。
- 操作就这么简单。 不必专门为JSON-LD训练新模型。只需在现有训练管线中将JSON-LD的占比从“接近0%”提升到“能见到几次”，LLM对其适应能力就会飞跃式提升。
五、最后几句实话
模型厂商的优先级清单很长——多模态、更长上下文、更快推理、更低成本……“支持JSON-LD”可能排在一千名开外。但我坚信，JSON-LD是AI Agent走向真正智能的关键基础设施。它不是另一种数据格式，而是让数据变成图、让Agent乃至LLM间能互相理解、让记忆跨会话持久化的语义总线。
当前的LLM就像一位天才但只会英语的人。处理全球业务时能力很强，一旦遇到西班牙语、中文、阿拉伯语就必须通过翻译。JSON-LD就是AI世界的“通用语言”。
所以，诚恳呼吁模型厂商们：教教LLM说“JSON-LD”吧。
Gliding Horse（流马）平台在线等，挺急的。