/ заметки · 16 мая 2026 г. · принципы · design · llms

Принцип экономии токенов

Почему главная книга никогда не должна попадать в контекстное окно и что эта ограниченность заставляет проектировать вместо этого.

Самое полезное единичное ограничение, которое я перенял, строя автоматизацию вокруг LLM, такое: главная книга никогда не попадает в контекстное окно.

Под «главной книгой» я имею в виду любой большой структурированный транзакционный массив данных, который вы обычно отдали бы SQL-движку, сводной таблице или сверочному скрипту. Сотни тысяч строк. Длинные истории. Вещи, у которых уже есть естественный слой запросов.

Соблазн, когда вы только начинаете, скопировать кусок в промпт и попросить модель посчитать. Две колонки цифр, диапазон дат, «найди расхождения». Модель попробует. Иногда даже получится. Но вы платите реальную цену, которая поначалу невидима: каждый токен, потраченный на отрисовку сырых данных, это токен, не потраченный на рассуждение. Счёт не финансовый, он когнитивный. У модели меньше места думать, потому что она занята чтением.

Принцип, которому я теперь следую: данные живут там, где живут. Контекстное окно несёт вопрос, схему и результат одного целевого запроса. И всё. Модель аналитик, а не база данных.

На практике это выглядит так:

• Оборотная ведомость не вклеивается в промпт. Промпт говорит: «вот схема и имя файла; запроси нужный срез».
• Сверку не просят сделать у модели напрямую. Модель пишет скрипт, скрипт исполняется против файла, результат возвращается небольшой таблицей.
• Длинный PDF не суммаризируется одним заходом. Модели сообщается структура глав, спрашивается, какие разделы важны, и подаются только они.

Это вынуждает определённую дисциплину системы вокруг модели. Нужен слой инструментов, которые модель может вызвать, маленький набор типизированных действий, способ доставить результаты обратно в контекст, не раздувая его. MCP играет здесь роль. Так же хорошо работают и просто хорошо названные файлы на диске, которые модель может прочитать по запросу.

Несколько следствий, которые я научился уважать.

Retrieval это не то же, что ingestion. Ingest корпуса значит вывалить его в контекст. Retrieval значит спросить: «какая часть этого корпуса релевантна вопросу, который у меня сейчас», и вернуть только её. Первое плохо масштабируется. Второе это то, что люди реально делают, когда читают.

Схемы дёшевы, данные дороги. Описать форму массива в пятидесяти токенах стоит почти ничего и позволяет модели рассуждать о запросах к нему. Описать каждую строку стоит всего и позволяет модели рассуждать почти ни о чём.

Окно это рабочая память, а не жёсткий диск. Относитесь к нему так, как человек относится к рабочему столу: маленькая поверхность для артефактов текущего решения, удерживаемая в порядке, потому что беспорядок это то, что заставляет забывать.

Почему это важно, помимо стоимости и скорости: модель ведёт себя иначе, когда не похоронена под данными. Она задаёт лучшие вопросы. Она признаётся, когда не знает. Она перестаёт галлюцинировать цифры из колонок, которые прочла лишь наполовину. Это не свойства модели, это свойства разговора. Вы проектируете разговор, решая, что попадает в окно, а что нет.

Если workflow, кажется, требует всей главной книги в контексте, это знак, что workflow делает анализ, который LLM делать не должен. Перенесите анализ в систему. Оставьте модель для частей, которые только модель и может делать: рамка, суждение, язык.

← все заметки