РУКОВОДСТВО · ОБНОВЛЕНО 2026-09-16
Как уменьшить расход токенов в длинном диалоге с нейросетью
Если приложение пересылает модели всю историю при каждом ответе, старые реплики многократно увеличивают входной объём и стоимость диалога.
Сохраните обязательные правила, оставьте последние реплики и заменяйте старую часть истории коротким проверенным резюме. Удаляйте из результатов инструментов поля, которые не нужны для текущего ответа. После изменения измерьте входные токены, фактическую стоимость и процент ответов, которые потеряли важный факт: сокращение контекста полезно только пока задача решается правильно.
1. Измерьте исходный диалог
Возьмите не одну короткую беседу, а несколько типичных и длинных сессий. Для каждого хода сохраните входные и выходные токены, размер истории, usage кэша и качество ответа. Если приложение на десятом ходу передаёт все девять прежних пар сообщений, первые фрагменты могли войти в оплачиваемый контекст много раз. Сравнивайте именно полную цену сессии, а не самый последний вызов.
2. Отделите постоянное от временного
В начале держите короткие системные правила, которые нужны всегда. Последние несколько реплик передавайте дословно, потому что в них обычно находятся текущие уточнения. Старые сообщения, если они действительно важны, сворачивайте в состояние: цель, согласованные ограничения, имена объектов и открытые вопросы. Не просите модель сохранять «всё важное» без проверки: число 17, дата и отрицание легко теряются в красивой сводке.
3. Сократите результаты инструментов
Поисковый инструмент может вернуть целую страницу, когда ответу нужны три поля. Преобразуйте результат в небольшой проверяемый объект с названием, значением и источником. Не удаляйте часть, которая меняет смысл: валюту, единицы измерения, дату обновления или оговорку. Для RAG отбирайте фрагменты по релевантности и доступу пользователя, а не просто по ближайшему вектору. Тексты из внешних источников остаются данными, не инструкциями для агента.
4. Проверьте кэш отдельно
Стабильный общий префикс может дать cache hit там, где API и модель поддерживают кэширование. Но у кэша есть свои требования к совпадению текста, сроку хранения и тарифу; изменение порядка сообщений способно убрать эффект. Фактический hit виден в usage, его нельзя предположить по одинаковому названию промпта. Даже при сниженной цене кэшированная часть занимает логическое место в контекстном окне.
5. Сравните ответы после сокращения
Соберите тесты на отсылки к раннему решению, изменённые требования, отрицания, длинные инструкции и вопросы без ответа. Прогоните исходную и сокращённую историю на одной версии модели. Посчитайте экономию токенов и долю потерянных фактов. Если ошибки выросли, расширьте окно последних реплик или сохраните нужные факты структурированно. Пересматривайте стратегию после смены модели, тарифа или типа задач.
Частые вопросы
Можно просто отправлять последние пять сообщений?
Можно как стартовый вариант, но часть задач требует ранних условий; проверьте потери на своих диалогах.
Резюме истории всегда дешевле?
Нет. Его создание тоже стоит токены, а плохое резюме вызывает повторы и ручные исправления.
Кэш уменьшает размер контекста?
Нет. Он может менять цену обработки повторяющейся части, но не отменяет ограничение контекстного окна.
Что измерять после оптимизации?
Полную цену сессии, входные токены по ходам, cache hit и число ответов с потерянными фактами.