Почему Markdown делает LLM умнее, а не просто дешевле
Почему Markdown делает LLM умнее, а не просто дешевле
Большинство людей открывают для себя рабочие процессы Markdown-для-ИИ через экономию средств. Они обнаруживают, что конвертация веб-страницы из сырого HTML в Markdown сокращает расход токенов на 80–90%, подсчитывают выгоду и немедленно переключаются.
Такая постановка верна, но неполна. Сокращение токенов — это побочный эффект. Реальная причина, по которой Markdown лучше работает с LLM, носит структурный характер: Markdown — это формат, в котором структура документа и смысловое значение являются одним и тем же. HTML — нет. Это различие важнее, чем количество символов.
Как LLM на самом деле читают контент
Прежде чем объяснять, почему Markdown выигрывает, полезно понять, что языковая модель делает при обработке текста.
LLM не «читают» так, как читают люди. Они преобразуют ввод в токены — фрагменты примерно по 3–4 символа каждый — и обрабатывают их через слои внимания, которые обучаются связям между ними. У модели нет визуального рендерера. Она не может предположить, что что-то является заголовком, потому что оно выглядит крупным и жирным в браузере. Она может работать только с получаемой последовательностью токенов.
Это означает, что качество сигнала входного текста — насколько чётко структура закодирована в самих токенах — напрямую определяет, насколько хорошо модель понимает контент.
Проблема: HTML разделяет структуру и смысл
HTML был разработан для браузеров, а не для языковых моделей. Браузер рендерит <div class="article-headline"> как крупный жирный заголовок. Модель видит следующее:
<div class="article-headline">Why Markdown Makes LLMs Smarter</div>
Что токенизируется примерно как:
< div class = " article - headline " > Why Markdown Makes LL Ms Sm arter </ div >
Структурный сигнал — «это главный заголовок» — скрыт внутри строки с именем класса. Модель должна научиться в процессе обучения, что article-headline подразумевает важность. Обычно это работает, но модель работает против формата, а не вместе с ним.
Теперь рассмотрим глубокое вложение, которое является стандартом для реальных веб-страниц:
<div class="container">
<div class="content-wrapper">
<article class="post">
<div class="post-body">
<h2 class="section-title">Key Findings</h2>
<p>The results showed...</p>
</div>
</article>
</div>
</div>
К тому моменту, когда модель добирается до Key Findings, она уже обработала четыре уровня структурного шума. Сам тег <h2> является единственным значимым сигналом, и он конкурирует с именем класса (section-title), которое может или не может его усиливать.
Почему Markdown объединяет структуру и семантику
Markdown решает эту проблему, делая структуру и смысл идентичными. Нет разделения между «как это выглядит» и «что это значит».
## Key Findings
The results showed...
Префикс ## и есть семантический сигнал. Он однозначно означает «заголовок второго уровня». Никаких имён классов, никаких обёрточных div, никаких конкурирующих сигналов. Модель получает ровно ту информацию, которая ей нужна, закодированную непосредственно в последовательности токенов.
Эта закономерность сохраняется для всех элементов Markdown:
| Тип контента | Сигнал HTML | Сигнал Markdown |
|---|---|---|
| Главный заголовок | <h1> или <div class="title"> или <span id="headline"> | # |
| Подзаголовок | <h2> — <h6> или стилизованные div | ## — ###### |
| Выделенный текст | <strong>, <b>, <span class="bold"> | **текст** |
| Код | <code>, <pre>, <div class="highlight"> | `код` или огороженные блоки |
| Список | <ul>/<li> или <div class="list-item"> | - элемент |
| Ссылка | <a href="..."> с окружающей разметкой | [текст](url) |
В HTML обычно существует 3–5 способов кодировать каждый смысловой элемент, и их фактическое использование варьируется от сайта к сайту. В Markdown способ только один. Это единообразие — не просто аккуратность, это причина, по которой модели обрабатывают Markdown надёжнее.
Как это выглядит на практике
Вот раздел из реальной технологической статьи, обработанный двумя способами и отправленный в Claude с одним и тем же промптом: «Изложите три основных вывода.»
Ввод A: Извлечение из сырого HTML (4 200 токенов)
<div class="article-body">
<div class="content-section" data-section="conclusions">
<h3 class="section-heading" id="section-3">Conclusions</h3>
<div class="paragraph-wrapper">
<p class="body-text">First, the researchers found that response latency...</p>
</div>
...
</div>
</div>
Результат: Модель правильно определила 2 из 3 выводов. Третий был смешан с методологическим примечанием в соседнем теге <aside>, который модель не распознала как второстепенный контент.
Ввод B: Конвертированный Markdown (890 токенов)
## Conclusions
First, the researchers found that response latency...
Результат: Все 3 вывода определены правильно. Содержимое <aside> было корректно исключено конвертером как вспомогательное, поэтому оно так и не попало к модели.
Количество токенов снизилось на 79%. Точность улучшилась с 67% до 100% в этом примере. Оба изменения произошли из одного источника: более чистого структурного кодирования.
Цифры по токенам (и почему они следствие, а не причина)
Поскольку стоимость важна, вот данные по обработке технической статьи в 1 500 слов:
| Формат ввода | Количество токенов | Стоимость (Claude Sonnet) | Соотношение сигнал/шум | |---|---|---|---| | Сырой HTML | 16 820 | $0,050 | ~6% | | Очищенный простой текст | 3 450 | $0,010 | ~35% | | Чистый Markdown | 1 890 | $0,006 | ~92% |
Разница в стоимости реальна — на 88% дешевле, чем сырой HTML. Но обратите внимание, что очищенный простой текст (просто удаление HTML-тегов) тоже значительно сокращает количество токенов, однако соотношение сигнал/шум остаётся на уровне 35%. Простой текст теряет всю структурную информацию: нет заголовков, нет выделения, нет иерархии списков. Вы платите меньше, но у модели меньше материала для работы.
Markdown достигает оптимума: максимум структурной информации при минимальных затратах токенов. Вот почему это правильный формат для ввода в LLM, а не просто более дешёвый вариант.
Три сценария, где качество формата меняет результаты
1. Резюмирование
При создании краткого изложения длинной статьи модель должна определить, какие разделы являются основным контентом, а какие — вспомогательным. Иерархия заголовков Markdown (#, ##, ###) делает это явным. Простой текст и плохо структурированный HTML вынуждают модель выводить это из самого контента, что увеличивает вероятность включения врезок из боковой панели, биографий авторов или анонсов связанных статей в итоговое резюме.
2. Ответы на вопросы по веб-контенту
Когда вы вставляете веб-страницу и задаёте конкретный вопрос, модель сначала должна найти нужный раздел. В чистом Markdown-документе токены заголовков действуют как оглавление, по которому может навигировать модель. В сыром HTML для нахождения нужного раздела требуется разбор обёрточных div и атрибутов классов, прежде чем добраться до контента, — что сжимает контекстное окно и увеличивает вероятность того, что модель обратит внимание не на ту область.
3. Извлечение кода
Технические страницы часто содержат примеры кода, перемежающиеся с прозаическими пояснениями. Огороженные блоки кода Markdown (```) создают чёткую границу. Модель точно знает, где начинается и заканчивается код. В HTML код может быть обёрнут в <pre>, <code>, <div class="highlight"> или пользовательский компонент вообще без стандартного тега — все разные паттерны токенов для одного и того же смыслового контента.
Практический вывод
Если вы передаёте веб-контент любому LLM — для исследований, резюмирования, ответов на вопросы или извлечения данных — формат, который вы используете, имеет такое же значение, как и промпт, который вы пишете. Чистый Markdown — это не просто удобство. Это входной формат, который LLM неявно были обучены понимать лучше всего, потому что значительная часть их обучающего корпуса (GitHub, Wikipedia, сайты документации, Stack Overflow) уже написана в Markdown или форматах, близких к Markdown.
Экономия средств — это бонус. Улучшение качества — это суть.
Конвертируйте любую веб-страницу в чистый Markdown, готовый для LLM, одним кликом. Попробуйте Web2MD — бесплатно для Chrome.