这几天好像这个叫 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://github.com/toon-format/toon
点个在看你最好看!