这几天好像这个叫 TOON 的东西比较火，我们这篇文章来看看他到底是什么，又有什么作用。TOON 全称 Token-Oriented Object Notation，它主要解决的问题就是当你把JSON 输入给LLM 的时候，token 消耗太高了。
一个长 JSON 数组扔进模型token 计数直接起飞。因为引号、大括号、重复的键名，到处都是这些没什么实际意义的字符，而TOON 就是从这个痛点出发，它不是要干掉 JSON，而是说：既然主要是语言模型，那些装饰性的字符完全可以省掉。
Token数对比
常规 JSON 长这样：
[
{ "id": 1, "name": "Deep", "role": "admin" },
{ "id": 2, "name": "Hub", "role": "user" }
]
TOON 版本：
users[2]{id,name,role}:
1,Deep,admin
2,Hub,user
第一眼看上去像半成品草稿。但逻辑其实很清晰——字段名只写一次，声明有多少行，然后直接按表格形式写数据，我们直接可以说这个算是CSV的一个进化版。
有一个不严谨的测试JSON 格式的 token 数基本是 TOON 的两倍。差距就这么大。
TOON
JSON 的问题是结构不变的情况下还在重复。而TOON的想法是既然结构本来就很明显了，没必要每条记录都写一遍。
另外就是该有得支功能还是都有，比如说嵌套，使用类似 YAML 的缩进结构来处理嵌套对象：
user:
id: 123
email: ada111@666.com
metadata:
active: true
score: 4.5
简单得嵌套跟YAML 基本一样，如果把嵌套和列表放在一起就是这样：
比如说这个json
{
items: [
{
users: [
{ id: 1, name: 'Deep' },
{ id: 2, name: 'Hub' }
],
status: 'active'
}
]
}
转换完以后是这样的
items[1]:
- users[2]{id,name}:
1,Deep
2,Hub
status: active
这完全就是YAML 和CSV的缝合怪，不过倒是把JSON冗余的标点去掉了。
不过根据官网的评测token的确是减少了很多
局限性
对于YAML来说深层嵌套的数据结构一直是个问题，而TOON也一样，如果层次太多会比较乱。而且同一个列表里如果对象结构不一致，也不太好处理。但是如果只是为了优化 LLM prompt，TOON还真的确实挺实用。
总结
适合用 TOON 的情况：
- 往模型里塞大量重复结构的数据
- token 成本是主要考虑因素
- 数据结构相对规整
继续用 JSON 的情况：
- 写 API 接口
- 需要长期存储
- 数据结构复杂或者不规则
所以TOON并不是什么颠覆性的东西。更像是有人把 JSON 里那些多余的部分清理掉，然后说：跟模型交互的时候，可以试试这个。
github地址：
https://avoid.overfit.cn/post/95264c51c6544c139b198c31fe4127ab
