探究TOON的价值边界：比JSON更优的大模型友好数据格式？

    最近 AI 圈子里出现了一个新概念：**TOON**。

    官方对它的描述是这样的：一种简洁、易读的 JSON 数据模型编码，最大限度地减少令牌数量，使模型易于理解结构。它旨在作为现有 JSON 的可随插、无损表示，用于 LLM 输入 。它**结合了 YAML 基于缩进的嵌套对象结构与 CSV 风格的表格布局**，用于统一数组。TOON 的优势在于对象数组统一（每行多个字段，项目结构相同），实现类似 CSV 的紧凑性，同时增加了显式结构，帮助大型语言模型可靠解析和验证数据。

    **截至目前**，**TOON 在github上已经揽下21.5k+ star**。一种比JSON更优秀的大模型友好数据格式真的诞生了？

    在上一篇博文[TOON：一种为大模型设计的JSON压缩型数据结构](https://opengms-watermelo.blog.csdn.net/article/details/156652916)中，我们已经对 TOON 的结构和设计目标有了一个相对准确的认识。但任何一种数据格式的价值，都不取决于“它能做什么”，而取决于它在什么情况下值得被使用。这一篇将聚焦一个更现实的问题：TOON 的收益边界到底在哪里？

    TOON 的优势建立在一个非常强的前提之上：同构性。官方在何时不该使用 TOON 上是这样描述的（表格结构指同构对象数组，即数组中每个对象的键名都一样，可以用表格表示）：

    官方给出了这样的一组效率排名（每1000个代币的准确率）：

    该排名不包括 CSV，因为它只支持 209 题中的 109 题（仅为扁平表格数据）。虽然 CSV 对于简单的表格数据非常高效，但它无法表示其他格式处理的嵌套结构。

    此外，还有一组各模型检索精度的排名，官方将以下数据作为大模型检索的依据：

    生成了五类一共209个问题：

    最后得到的测试结果是这样的：

    官方提供的效率、检索准确度排名相对缥缈，但是 token 差异是我们确实能看得见摸得着的，我们利用 OpenAI 提供的 tokenizer 工具来统计一下 token 差异。

    网址：[https://platform.openai.com/tokenizer](https://platform.openai.com/tokenizer)

    测试数据：

// JSON
{
  "context": {
    "task": "Our favorite hikes together",
    "location": "Boulder",
    "season": "spring_2025"
  },
  "friends": ["ana", "luis", "sam"],
  "hikes": [
    {
      "id": 1,
      "name": "Blue Lake Trail",
      "distanceKm": 7.5,
      "elevationGain": 320,
      "companion": "ana",
      "wasSunny": true
    },
    {
      "id": 2,
      "name": "Ridge Overlook",
      "distanceKm": 9.2,
      "elevationGain": 540,
      "companion": "luis",
      "wasSunny": false
    },
    {
      "id": 3,
      "name": "Wildflower Loop",
      "distanceKm": 5.1,
      "elevationGain": 180,
      "companion": "sam",
      "wasSunny": true
    }
  ]
}

// TOON
context:
  task: Our favorite hikes together
  location: Boulder
  season: spring_2025
friends[3]: ana,luis,sam
hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}:
  1,Blue Lake Trail,7.5,320,ana,true
  2,Ridge Overlook,9.2,540,luis,false
  3,Wildflower Loop,5.1,180,sam,true

    其中 JSON 数据的 token 计数为 223：

    TOON 数据的 token 计数为 104：

    基于这个对比，我们可以发现 JSON 中有大量的大括号、重复的键名消耗了额外的 token，但是在空格、换行上，TOON 比起 JSON 不一定能带来实际的提升。此外，关于 **characters / tokens的比值，JSON 数据是 2.98，TOON 数据则是 2.75 。即优化 n% 的字符，也没办法减少 n% 的 token 消耗，说明 TOON 数据中每个 token 包含的字符数更少。**

    但总体说来，TOON 在表格结构中确实能大幅减少 JSON 数据中的冗余内容，一定程度上减少 token 的浪费。

    根据上述的介绍和探索，结合小瓜自己的理解来看。这里需要非常克制地给出结论，从设计目标看，TOON 确实减少了结构重复，明确了语义边界，有助于模型做模式识别，在适用情况下，确实节省了不少的 token ，但这并不意味着模型“天生更懂 TOON”，TOON 数据格式在效率和准确度上的提升仍需要更多的积淀和发展。

    TOON 在数据格式变更上做出了一次尝试，这个角度并不是唯一解法。事实上，在很多真实场景中，**减少输入数据本身，比更换数据格式收益更大。**TOON 优化后 characters / tokens 的比值变小了也能佐证这一点。

    TOON github仓库：[https://github.com/toon-format/toon](https://github.com/toon-format/toon)

    TOON 并不是一个噱头，也不是 JSON 的替代品。它更像是一种为大模型输入定制的结构受限的数据表达 DSL。在特定场景下，使用 TOON 可能有奇效，它应该被视为一个工具选项，理解它的边界比盲目使用它或者拒绝它更重要。

    只有锻炼思维才能可持续地解决问题，只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助，麻烦您点个赞支持一下，还可以收藏起来以备不时之需，有疑问和错误欢迎在评论区指出~

    其他热门文章，请关注：