TOON:一种为大模型设计的JSON压缩型数据结构

TOON:一种为大模型设计的JSON压缩型数据结构

目录

TOON:一种为大模型设计的JSON压缩型数据结构

一、精准定义,什么是 TOON?

1、JSON 数据格式的局限性

2、TOON 的结构与优势

3、TOON 数据结构的主要特征

4、媒体类型与文件拓展名

二、举例:JSON 与 TOON 描述同一组数据分别是什么样

三、结语


        作者:watermelo37

        ZEEKLOG优质创作者、华为云云享专家、阿里云专家博主、腾讯云“创作之星”特邀作者、火山KOL、支付宝合作作者,全平台博客昵称watermelo37。

        一个假装是giser的coder,做不只专注于业务逻辑的前端工程师,Java、Docker、Python、LLM均有涉猎。



---------------------------------------------------------------------

温柔地对待温柔的人,包容的三观就是最大的温柔。

---------------------------------------------------------------------

TOON:一种为大模型设计的JSON压缩型数据结构

        TOON 入门到实战三部曲:

        基础入门:TOON:一种为大模型设计的JSON压缩型数据结构

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

        开发实战:面向大模型开发:在项目中使用 TOON 的实践与流式处理

        最近 AI 圈子里出现了一个新概念:TOON

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

        当下社区中关于 TOON 的文章质量良莠不齐,有些描述甚至是错误的。本文将结合官方描述与工程视角,对 TOON 做一次尽量简洁、准确的入门性介绍,帮助读者先弄清楚一个问题:

        TOON 到底是什么?它解决的是什么问题?

        截至目前,TOON 在 GitHub 上已经获得了 21.5k+ Star,一种比JSON更优秀的大模型友好数据格式真的诞生了?

一、精准定义,什么是 TOON?

1、JSON 数据格式的局限性

        JSON 在工程世界里几乎无可替代,但在与大模型交互时,它有一个非常现实的问题:结构冗余。尤其是同构对象数组,比如:

{ "hikes": [ { "id": 1, "name": "Blue Lake Trail", "distanceKm": 7.5 }, { "id": 2, "name": "Ridge Overlook", "distanceKm": 9.2 }, { "id": 3, "name": "Wildflower Loop", "distanceKm": 5.1 } ] } 

        每一行都在重复:"id" "name" "distanceKm"。

        在 LLM 输入中,这些重复的结构信息会消耗更多的上下文空间。JSON 的问题在于并非为语言模型的上下文机制设计,完善通用的结构给它带来了更多的信息冗余,但信息冗余是要花钱的。

2、TOON 的结构与优势

        TOON 的核心思想就是:在保持 JSON 语义不变的前提下,把重复结构前移并声明一次 + 提前告知数据条目总长度。

        它融合了三种表达风格:

  • YAML 的缩进结构:表达对象嵌套
  • 表格化声明:表达同构对象数组
  • 显式结构标注:减少歧义,方便模型解析

        其核心就在于 TOON 将键名重复的同构对象数组变成形如“key[n]{a,b,c}:”的声明,后续n行只表示值。

        举个例子,上面的JSON数据转化为 TOON 就是:

hikes[3]{id,name,distanceKm}: 1,Blue Lake Trail,7.5 2,Ridge Overlook,9.2 3,Wildflower Loop,5.1

        是不是简洁了很多?重复的键名、空格、括号都被去除了。

3、TOON 数据结构的主要特征

        官方仓库对于 TOON 的主要特征是这样描述的:

  • 令牌高效且准确:TOON 在混合结构基准测试中,在 4 个模型中,准确率达到 74%(而 JSON 仅为 70%),同时使用约 40% 的令牌。
  • JSON 数据模型:通过确定性、无损的往返编码与 JSON 相同的对象、数组和原语。
  • LLM 友好型护栏: 明确的[N]长度和{fields}头部为模型提供了清晰的模式,提高了解析可靠性。
  • 最小语法: 使用缩进代替大括号,减少引用,赋予类似 YAML 的可读性和 CSV 风格的紧凑性。
  • 表格数组: 均匀的对象数组合并成表,表中声明字段一次,逐行传输取值。
  • 多语言生态系统:TypeScript、Python、Go、Rust、.NET 及其他语言中的规范驱动实现。

4、媒体类型与文件拓展名

        TOON 文件在 HTTP 和内容类型感知的上下文中使用 .toon 扩展名和临时媒体类型 text/toon。TOON 文档始终采用 UTF-8 编码;可以指定 charset=utf-8 参数,但省略时默认为 UTF-8。

二、举例:JSON 与 TOON 描述同一组数据分别是什么样

        TOON 看起来像添加了长度的 csv ?先别急,我们可以通过一个官方的对比案例理解一下 TOON 结构的真实魅力。

        原始 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

        在不影响人类可读性的基础上,TOON 去除了所有的普通对象中的大括号、空格甚至双引号,将所有的同构对象数组和普通数组都简化成类似CSV的结构,并将数组的总长度、键名都提前声明,便于大模型获取核心信息。

        这一点除了节省 token 外,官方认为还带来了识别和搜索效率的提升,这一点小瓜将在下一次更新《探究TOON的价值边界:比JSON更优的大模型友好数据格式?》中展开介绍。

三、结语

        到这里为止,我们可以给 TOON 一个非常清晰的定义:TOON 是一种为大模型输入设计的、对 JSON 进行结构压缩的表示方式。它吸纳了 yaml、 csv 的表示特点,对 JSON 数据的表达结构进行了重构,在特定场景下能节约 token 的使用量。

        它通过消除同构对象数组中的结构重复显式声明数组规模与字段模式来降低结构性 token 的消耗。但问题也随之而来,是不是所有 JSON 都适合 TOON?TOON 是否真的更利于模型理解?这些问题,将在下一篇《探究TOON的价值边界:比JSON更优的大模型友好数据格式?》展开。

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

        其他热门文章,请关注:

        极致的灵活度满足工程美学:用Vue Flow绘制一个完美流程图

        你真的会使用Vue3的onMounted钩子函数吗?Vue3中onMounted的用法详解

        Web Worker:让前端飞起来的隐形引擎

        测评:这B班上的值不值?在不同城市过上同等生活水平到底需要多少钱?

        通过array.filter()实现数组的数据筛选、数据清洗和链式调用

        DeepSeek:全栈开发者视角下的AI革命者

        TreeSize:免费的磁盘清理与管理神器,解决C盘爆满的燃眉之急

        通过Array.sort() 实现多字段排序、排序稳定性、随机排序洗牌算法、优化排序性能

        高效工作流:用Mermaid绘制你的专属流程图;如何在Vue3中导入mermaid绘制流程图

        通过MongoDB Atlas 实现语义搜索与 RAG——迈向AI的搜索机制

      【前端实战】如何让用户回到上次阅读的位置?

        前端实战:基于Vue3与免费满血版DeepSeek实现无限滚动+懒加载+瀑布流模块及优化策略

        深入理解 JavaScript 中的 Array.find() 方法:原理、性能优势与实用案例详解

        el-table实现动态数据的实时排序,一篇文章讲清楚elementui的表格排序功能

        JavaScript双问号操作符(??)详解,解决使用 || 时因类型转换带来的问题

        内存泄漏——海量数据背后隐藏的项目生产环境崩溃风险!如何避免内存泄漏

        MutationObserver详解+案例——深入理解 JavaScript 中的 MutationObserver

        JavaScript中通过array.map()实现数据转换、创建派生数组、异步数据流处理、DOM操作等

Read more

Spring Cloud 熔断降级详解:用 “保险丝“ 类比,Sentinel 实战教程

Spring Cloud 熔断降级详解:用 “保险丝“ 类比,Sentinel 实战教程

欢迎文末添加好友交流,共同进步! “ 俺はモンキー・D・ルフィ。海贼王になる男だ!” * 📋 目录 * 什么是熔断降级 * 定义 * 为什么需要熔断降级? * 保险丝类比:形象理解熔断机制 * 生活中的保险丝 * 熔断器工作原理对比 * 熔断器三种状态 * Sentinel 核心概念 * 什么是 Sentinel? * 核心概念对比 * Sentinel vs Hystrix 对比 * Sentinel 实战教程 * 环境准备 * 1. 添加依赖 * 2. 配置文件 * 基础示例:注解方式 * 3. 主启动类 * 4. 创建订单服务 * 5. 控制器 * 高级配置:规则定义 * 6. 流控规则配置 * OpenFeign 集成 * 7. Feign客户端集成Sentinel * 8. Feign降级处理 * 规则持久化(

By Ne0inhk
【MYSQL】MYSQL学习的一大重点:MYSQL表的操作

【MYSQL】MYSQL学习的一大重点:MYSQL表的操作

🎬 个人主页:艾莉丝努力练剑 ❄专栏传送门:《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》 《Linux操作系统编程详解》《笔试/面试常见算法:从基础到进阶》《Python干货分享》 ⭐️为天地立心,为生民立命,为往圣继绝学,为万世开太平 🎬 艾莉丝的简介: 文章目录 * 0 ~> 概要 * 1 ~> 创建表 * 2 ~> 创建表的案例详解 * 3 ~> 查看表结构 * 4 ~> 修改表 * 4.1 什么时候需要修改表 * 4.2 修改方式 * 4.3 案例 * 4.3.1 在users表添加二条记录 * 4.

By Ne0inhk
Spring Boot 后端分层开发实战:从 MVC 到三层架构详解

Spring Boot 后端分层开发实战:从 MVC 到三层架构详解

应用分层 通过上面的练习,我们学习了 Spring MVC 简单功能的开发,但是我们也发现了一些问题。目前我们程序的代码有点 “杂乱”,然而当前只是 “一点点功能” 的开发。如果我们把整个项目功能完成呢?代码会更加的 “杂乱无章”(文件乱,代码内容乱)。 也基于此,咱们接下来学习应用分层。类似公司的组织架构:公司初创阶段,一个人身兼数职,既做财务,又做人事,还有行政。随着公司的逐渐壮大,会把岗位进行细分,划分为财务部门,人事部门,行政部门等。各个部门内部还会再进行细分。 项目开发也是类似,最开始功能简单时,我们前后端放在一起开发,随着项目功能的复杂,我们分为前端和后端不同的团队,甚至更细粒度的团队。后端开发也会根据功能再进行细分。MVC 就是其中的一种拆分方式。但是随着后端人员不再涉及前端,后端开发又有了新的分层方式。 4.1 介绍 阿里开发手册中,关于工程结构部分,定义了常见工程的应用分层结构: 那么什么是应用分层呢?应用分层是一种软件开发设计思想,

By Ne0inhk
一卡通核心交易平台的国产数据库实践解析:架构、迁移与高可用落地

一卡通核心交易平台的国产数据库实践解析:架构、迁移与高可用落地

文章目录 * 摘要 * 1. 业务与技术挑战拆解 * 2. 总体架构(从数据库边界看) * 3. 数据模型:以“不可变流水”为中心 * 3.1 流水表(交易事实表)建议 * 3.2 账户与余额:把“强一致”收敛到最小 * 4. 高可用与容灾:把“不可用窗口”工程化 * 4.1 同城高可用:主备切换与防脑裂 * 4.2 异地灾备:以“可恢复”为目标设计链路 * 5. 性能与稳定性:把瓶颈消灭在“写路径” * 5.1 连接治理:让资源可控 * 5.2 SQL治理:少做无谓计算

By Ne0inhk