Почему MD/JSON/XML не подходят

Структурированные форматы уже существуют. Так почему нужен новый язык?

Самое частое возражение

Когда кто-то впервые сталкивается с идеей языка рассуждений ИИ, первое, что он говорит:

“Структурированные форматы уже существуют, разве нет?”

Они правы. Существуют. Много.

Есть Markdown. Есть JSON. Есть XML. YAML, TOML, Protocol Buffers, MessagePack, CSV…

Мир переполнен форматами данных. Так почему ИИ по-прежнему думает на естественном языке?

Чтобы ответить на этот вопрос, мы должны точно определить, что каждый формат делает хорошо и чего он не может.

Markdown: текущая память ИИ-агентов

По состоянию на 2026 год, формат, наиболее широко используемый ИИ-агентами, – Markdown.

Claude Code запоминает в файлах .md. Агенты на основе GPT тоже оставляют заметки в Markdown. CLAUDE.md, memory.md, notes.md. Долговременная память ИИ прямо сейчас стоит на Markdown.

Почему Markdown? Причина проста. LLM хорошо читают и пишут Markdown. Markdown обильно представлен в обучающих данных, и его структура достаточно проста для лёгкой генерации и разбора.

Но Markdown – формат документов, предназначенный для чтения людьми.

# Статус проекта
## Стратегия кэширования
- Принята SIMD-битовая маска (решение 1/28)
- GPU-ускорение на рассмотрении
## Нерешённое
- Метод генерации запросов не определён

Как машина это интерпретирует?

Есть заголовок раздела “Стратегия кэширования”. Под ним пункт “Принята SIMD-битовая маска”. Есть дата “(1/28)” в скобках.

Машина не может понять это структурно. Она может определить по ##, что “Стратегия кэширования” – заголовок раздела, но семантическая связь “это подтема архитектуры” в Markdown не существует. Человек знает, что “1/28” – дата, но машина должна угадывать. 28 января или одна двадцать восьмая?

В конечном счёте, чтобы “понять” Markdown, LLM должен выполнить интерпретацию естественного языка. Markdown – это естественный язык с наложенными отступами – а не структурированные данные.

JSON: структура без смысла

JSON идёт на шаг дальше Markdown.

{
  "entity": "Ли Сунсин",
  "birth": "1545",
  "death": "1598",
  "occupation": "naval_commander"
}

Есть структура. Пары ключ-значение явные. Машина может разобрать. К полям есть доступ.

Но есть проблема.

JSON не знает, что означает ключ “entity”.

Человек, создавший этот JSON, знает, что “entity” означает “объект”. В JSON другого человека та же концепция может быть “name”, “subject” или “item”.

{"name": "Ли Сунсин"}
{"subject": "Ли Сунсин"}
{"item": "Ли Сунсин"}
{"entity": "Ли Сунсин"}

Четыре JSON выражают одно и то же, но машина не может узнать, что это одно и то же.

JSON лишён разделяемой семантики. Есть структура, но нет договорённости о том, что эта структура означает.

Каждый проект создаёт свою схему. Каждый API использует свои имена полей. Чтобы связать схему A со схемой B, нужен ещё один слой трансформации.

Это Вавилонская башня. Структура есть, но никто не понимает структуру друг друга.

XML: налог многословности

XML попытался решить проблему JSON.

Пространства имён, определения схем (XSD), определения типов документов (DTD). Он предоставляет метаструктуры, определяющие смысл структур.

<entity xmlns="http://example.org/schema">
  <name>Ли Сунсин</name>
  <birth>
    <year>1545</year>
    <calendar>lunar</calendar>
  </birth>
  <death>
    <year>1598</year>
    <cause>killed_in_action</cause>
  </death>
</entity>

Смысл можно определить. Структуру можно принудить через схемы. Он строже JSON.

Но у XML есть фатальная проблема.

Он многословен.

В приведённом XML фактическая информация – “Ли Сунсин, 1545, 1598, killed_in_action.” Всё остальное – теги. Открывающие и закрывающие теги превосходят числом информацию.

Почему это проблема для ИИ?

Контекстное окно LLM конечно. Если для передачи той же информации требуется в 3 раза больше токенов, объём информации, помещающейся в контекст, сокращается до одной трети.

XML многословен, чтобы люди могли легко его читать. Язык рассуждений ИИ не должен иметь таких потерь. Для LLM тег <name> – это расточительство.

И XML – проект начала 2000-х. Он был создан в эпоху, когда LLM не существовали, для людей и традиционного ПО. Он никогда не проектировался как язык рассуждений ИИ.

Общее ограничение

Markdown, JSON, XML. У каждого из четырёх форматов есть свои сильные стороны, но они разделяют общие ограничения.

Они текстовые. Все они сериализуются в строки. Машина должна их разобрать для обработки. Разбор – это затраты.

Идеальный язык рассуждений – бинарный поток. Последовательность 16-битных слов. Разбор не нужен. Интерпретируем в момент чтения.

Они были спроектированы до эпохи LLM. Markdown – 2004 год. JSON – 2001 год. XML – 1998 год. Они были спроектированы в эпоху, когда концепции LLM не существовало, для людей или традиционного ПО.

Язык рассуждений ИИ должен быть спроектирован в эпоху LLM, для LLM. Принцип проектирования “1 слово = 1 токен” предполагает существование LLM.

Их единая семантическая система отсутствует или неполна. У Markdown вообще нет семантической системы. У JSON есть структура, но нет смысла. XML может определять схемы, но они не унифицированы.

Семантически выровненный индекс – это глобально единый идентификатор смысла. Где бы он ни использовался, один и тот же SIDX означает одно и то же. Никакой конвертации не нужно. Консенсус встроен.

Резюме

Новый формат нужен не потому, что существующие форматы плохи. А потому, что существующие форматы были созданы в другую эпоху, для другой цели.

Markdown создан для документов, которые читают люди. JSON создан для обмена данными в веб-API. XML создан для универсальной сериализации документов и данных.

Формат для записи и накопления рассуждений ИИ. Такого ещё не существует.

Когда цель другая, инструмент должен быть другим.