ONTO: A Token-Efficient Columnar Notation for LLM Input Optimization
本文提出了 ONTO（对象令牌优化表示法），这是一种专为大语言模型输入优化的列式序列化格式，通过“一次声明字段、多行数据排列”的设计消除了 JSON 中重复键名的开销，在保持人类可读性和层级结构支持的同时，实现了 46% 至 51% 的令牌减少量及 5% 至 10% 的推理延迟降低。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
这篇论文介绍了一种名为 Onto 的新工具，它的核心目的非常明确：帮大语言模型（LLM）“省饭量”，同时让它吃得一样香。
为了让你轻松理解，我们可以把大语言模型想象成一个超级聪明的厨师，而我们要喂给它的数据就是食材。
1. 现在的痛点：用“快递盒”装“散装菜”
目前，当我们把数据（比如 1000 个传感器的读数）喂给 AI 时，最常用的格式是 JSON。
- 比喻：想象你要给厨师送 1000 个苹果。JSON 的做法是：把每一个苹果都单独装进一个精美的盒子里，盒子上还要贴上标签写着“苹果”、“苹果”、“苹果”……甚至每个苹果还要用塑料膜包一层，再放一个叉子。
- 问题：对于人类来说，这样很清晰，知道哪个是哪个。但对于 AI 厨师来说，它不仅要处理 1000 个苹果，还要处理 1000 个盒子、1000 张标签和 1000 个叉子。
- 后果：AI 的“胃口”（上下文窗口）是有限的，而且按“吃下去的总重量”（Token 数量）收费。结果就是，AI 花了 80% 的力气去消化那些重复的“盒子”和“标签”，只有 20% 的力气在真正思考苹果的味道（数据内容）。
2. 解决方案：Onto 的“自助餐台”模式
作者提出了 Onto，这是一种专门为 AI 设计的“列式”数据格式。
- 比喻：Onto 的做法是，在厨房门口挂一块大黑板（声明一次字段名），上面写着：“这里有苹果、香蕉、橙子”。然后，把 1000 个苹果排成一排，1000 个香蕉排成一排，中间用简单的竖线
|隔开。 - 核心逻辑：“一次声明，多次使用”。
- 不再给每个苹果贴标签，因为黑板上已经写好了。
- 不再用盒子装，直接排好队。
- 如果需要表示“苹果放在篮子里”（嵌套结构），只需要稍微缩进一点（像排队时稍微站前一点），而不是再套一层盒子。
3. 效果如何？
论文通过实验发现，Onto 就像给数据做了“瘦身操”：
- 省空间：相比 JSON，Onto 能减少 46% 到 51% 的 Token 数量。
- 简单说：以前 AI 要吃 100 斤的“盒子 + 苹果”，现在只需要吃 50 斤的“苹果”。
- 省时间：因为数据量少了，AI 处理速度变快了，延迟降低了 5% 到 10%。
- 不伤脑：最重要的是，虽然格式变了，但 AI 理解数据的能力完全没有下降。它依然能准确回答“哪个苹果最重？”或者“有多少个苹果坏了？”这类问题。
4. 为什么以前没人这么做？
这就好比以前我们送快递，必须保证每个包裹都独立包装，因为快递可能要转手给不同的人（文档交换）。
但大语言模型不一样，它是一次性消费：数据发过去，它处理完就完了，不需要再转手给别人。所以，那些为了“转手”而设计的精美包装（重复的标签、复杂的括号），对 AI 来说纯属浪费。
5. 总结：Onto 是什么？
- 它不是：用来替代 JSON 做网站接口，也不是用来存数据库的。
- 它是：专门为喂给 AI 吃而设计的“特制饲料”。
- 它的优势：
- 列式排列：像 Excel 表格一样，把同类数据排在一起，去掉重复的表头。
- 人类可读：虽然精简了，但人眼依然能看懂（不像二进制代码那样乱）。
- 支持层级：即使是复杂的嵌套数据（比如“设备里的温度”和“设备里的位置”），也能用简单的缩进表示，不需要复杂的括号。
一句话总结：
Onto 就是给大语言模型准备的一顿去掉了所有多余包装盒的“裸装”大餐。它让 AI 能用更少的钱（Token 成本）、更快的速度，吃到同样多的干货，而且吃得一样明白。这对于那些需要处理海量数据的企业来说，是一个既省钱又高效的“黑科技”。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。