Token-Oriented Object Notation: экономия на спичках, или все-таки нет? На днях в одном из чатов про LLM увидел новый формат представления данных для промпта. Суть в следующем: давайте выкинем из JSON все ненужные отступы, кавычки и скобки, оставив только самую важную информацию. Меньше токенов потратим, и быстрее ответ пользователю дадим. В теории - идея крутая, надо брать. Но так ли хорошо это будет работать на деле - не вполне понятно, все-таки LLM на этом формате не учились, и могут быть проблемы с интерпретацией данных. А если не понятно - надо тестировать на каких-то данных, про что собственно и расскажу, так что велкам читать. В качестве подопытной LLM взял minimax/minimax-m2, благо на опенроутере она сейчас бесплатная. Нагенерировал с ChatGPT синтетический датасет, в котором есть длинный промпт с описанием предметной области, и набор вопросов, на которые нужно ответить. Не столь важно, насколько адекватным примеры внутри этого датасета, главное - чтобы исходный датасет имел одни и те же данные как в формате JSON-нотации, так и в виде TOON-нотации. Составлено 15 заданий, "правильным" ответом для каждого из них является JSON с ответом, который должен в точности повторять указанный в задании. Генерировать в ответе TOON формат напрямую было бы слишком неразумно, т к модель его явно на обучении не видела в тех же количествах, и пришлось бы ей долго объяснять, что это такое и как оно составляется, что помешало бы чистоте эксперимента. В итоге, на каждый из 15 вопросов, ждем корректно отформатированный JSON, если видим хотя бы 1 ошибку - ответ не проходит. Для формата JSON, конвертация выполнялась с настройками json.dumps(dataset, ensure_ascii=False, separators=(",", ":"), sort_keys=False, indent="\t") В результате, получили следующие метрики качества: Запуск 1: JSON 10/15 (66.7%), TOON 9/15 (60.0%) - JSON пока побеждает Запуск 2: JSON 13/15 (86.7%), TOON 15/15 (100.0%) - тут TOON вырвался вперед Запуск 3: JSON : 12/15 (80.0%), TOON : 12/15 (80.0%) - score одинаковый (но спойлер - оба ошиблись в разных вопросах) Похоже, LLM достаточно неплохо понимает такой странный формат, и часто делает из него правильные выводы. При этом, на таком синтетическом датасете токенов не то чтобы получилось сэкономить. Чтобы датасет хорошо лег на TOON-формат, данные в нем должны быть достаточно однородными. В моем примере это было не так - поэтому промпт в формате TOON оказался 980 токенов длиной, что конечно короче чем 1534 у промпта с данными в формате JSON, но все равно многовато. Конечно, эксперимент дико грязный, и для получения нормальных результатов нужно было бы: - внимательно вычитать датасет на предмет корректности заданий; - докинуть вопросов, на которые в системном промпте нет ответа, и указание что в таком случае делать; - не использовать openrouter, т к не совсем понятно, какой провайдер у free моделей под капотом, и на каком железе они запущены; - выбрать побольше моделей, с разной архитектурой и разного размера. Но при всем при этом, на формат однозначно стоит взглянуть более пристально, особенно если вы экономите входные токены. Ссылки для дальнейшего изучения: - репозиторий автора, который предложил формат, там есть подробное описание + бенчмарки - библиотека для конвертации python object -> TOON и обратно - код для воспроизведения результатов @korneychukov