Токенами считают тариф, но для инженера важнее другое: ими же оплачиваются внимание модели, память запроса и каждая лишняя ошибка.
Каждый LLM-вызов состоит из:
- системных инструкций;
- developer/application-инструкций;
- пользовательского входа;
- подмешанного контекста;
- истории диалога, если она есть;
- описания инструментов;
- схемы ответа;
- самого ответа модели.
Всё это занимает токены. Всё это стоит денег. Всё это влияет на качество.
Новичок думает: «У модели большое контекстное окно, можно засунуть всё».
Инженер видит в каждом лишнем токене задержку, стоимость и шум.
Контекстное окно — не память
Большое окно контекста не означает, что модель одинаково хорошо использует весь текст. Длинный контекст может:
- увеличить задержку;
- размыть важные инструкции;
- повысить стоимость;
- создать конфликт между документами;
- сделать отладку почти невозможной;
- ухудшить качество ответа из-за нерелевантного шума.
Контекст надо проектировать так же, как SQL-запрос. Вы не делаете SELECT * FROM everything на каждый HTTP request. Тогда почему вы отправляете модели весь Confluence?
Вероятностный ответ
LLM не «знает» ответ в человеческом смысле. Она генерирует наиболее вероятное продолжение с учётом обученных паттернов и текущего контекста. Для многих задач этого достаточно. Опасность начинается, когда модель принимают за базу данных.
Параметры генерации
Несколько ручек управляют тем, как модель выбирает следующий токен. Инженеру достаточно понимать три:
temperature— степень случайности выбора. Низкая (0–0.3) — модель почти всегда берёт самый вероятный токен: подходит для классификации, извлечения, всего, где нужна стабильность. Высокая (0.8–1.0) — распределение «расплющивается», ответы разнообразнее: уместно для генерации вариантов текста. Важно:temperature=0уменьшает разброс, но не гарантирует идентичных ответов — это не seed.top_p— альтернативный способ ограничить выбор (доля вероятностной массы). Правило простое: настраивайте либоtemperature, либоtop_p, не оба сразу.max_output_tokens— жёсткий потолок длины ответа. Это не пожелание модели, а обрезка: ответ, упёршийся в лимит, обрывается посреди мысли (или посреди JSON — глава 9 разбирает, как это ловить). Ставьте с запасом относительно ожидаемой длины, но ставьте всегда: это последний рубеж защиты от «болтливого» и дорогого ответа.
Две оговорки из практики. Первая: у некоторых провайдеров новейшие модели вообще не принимают параметры сэмплирования — поведение управляется только промптом; проверяйте документацию конкретной модели, а не переносите привычки. Вторая: не используйте temperature как инструмент качества. «Поднимем температуру, вдруг станет лучше» — это не инженерия; параметры выбираются под тип задачи один раз и меняются только по результатам evals.
Отсюда следуют правила:
- факты берём из источников истины;
- модель используем для интерпретации, трансформации, объяснения и выбора в неопределённости;
- критичные решения проверяем;
- формат фиксируем схемой;
- качество измеряем на наборах примеров;
- стоимость считаем заранее.
Чеклист главы
- Вы знаете, из каких частей состоит контекст каждого вашего вызова и сколько токенов занимает каждая часть.
- В prompt не попадает ничего «на всякий случай»: каждая часть контекста отвечает на вопрос «зачем она здесь».
- История диалога и подмешанные документы имеют явный лимит, а не растут бесконечно.
- Никакой факт, критичный для продукта, не берётся из «памяти» модели.
- Одинаковый вход не обязан давать одинаковый выход — и ваши тесты это учитывают.
Практикум
Задача 3.1 — токеновый рентген запроса. ⭑
Возьмите любой свой LLM-вызов (или соберите типовой: system prompt + описание задачи + документ на 2–3 страницы + вопрос). С помощью токенайзера провайдера посчитайте, сколько токенов занимает каждая часть контекста, и постройте разбивку в процентах.
Критерии приёмки:
- Есть таблица: часть контекста → токены → % → стоимость при цене вашей модели.
- Найдена хотя бы одна часть, которую можно сократить на 30%+ без потери качества (лишние инструкции, дублирование, неиспользуемые примеры).
- Посчитано, сколько денег экономит это сокращение на 100 000 запросов в месяц.
Подсказки:
- У OpenAI есть
tiktoken, у Anthropic — endpoint подсчёта токенов. Числа будут разными — это нормально, токенайзеры разные. - Чаще всего раздуты system prompt («будь профессиональным, вежливым, точным…») и история диалога.
Задача 3.2 — эксперимент с недетерминизмом. ⭑
Отправьте один и тот же запрос на классификацию 20 раз с temperature=0 и 20 раз с temperature=1. Запрос возьмите пограничный — сообщение, которое можно отнести к двум категориям.
Критерии приёмки:
- Есть распределение ответов для обеих температур.
- Написан вывод из трёх предложений: что это означает для тестов, ретраев и evals вашей системы.
- Сформулировано правило: в каких ваших use case недетерминизм допустим, а в каких его надо гасить схемой и проверками.
Подсказки:
temperature=0уменьшает разброс, но не гарантирует идентичность ответов. Если ваши тесты сравнивают строки посимвольно — они будут мигать.