Ограничение длины ответа без потери смысла в LLM

Почему ответ разрастается

Модель редко выбирает краткость сама. Если в промпте нет жесткой рамки, она подстраховывается: добавляет вступление, повторяет вопрос своими словами, потом еще раз формулирует тот же вывод. Токены уходят не на смысл, а на "обвязку".

Объем обычно растет по одной и той же схеме. Модель начинает с общего абзаца вместо прямого ответа, дублирует тезис разными словами, дает лишние примеры, превращает все в список и вставляет оговорки "на всякий случай". Это особенно заметно в широких задачах: пересказ документа, сравнение вариантов, помощь оператору, генерация писем. Чем больше свободы, тем охотнее модель заполняет ее подробностями.

Проблема в том, что длинный текст редко делает ответ точнее. Пользователю обычно нужен ясный вывод, одна рекомендация или 2-3 шага. Когда ответ растягивается, главная мысль прячется в середине, и человек тратит время на поиск сути. В поддержке и во внутренних помощниках это видно сразу: сотруднику нужен ответ за секунды, а не мини-статья.

Лишний объем бьет и по бюджету. Вы платите за сгенерированные токены, а вместе с длиной ответа растет и задержка. Один ответ на 700 токенов вместо 200 кажется мелочью, но в чате с тысячами запросов в день разница быстро становится заметной. Если один и тот же запрос еще и проходит через несколько моделей, перерасход умножается.

Поэтому ограничение длины ответа - не попытка "обрезать" качество. Это способ убрать повторы, пустые примеры и страховочные абзацы, чтобы модель тратила токены на суть. Короткий ответ часто работает лучше: его проще читать, дешевле отдавать и легче контролировать.

Что оставить, чтобы смысл не пропал

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

Сначала выберите один формат для каждого сценария. Для классификации это может быть одна метка и короткая причина в одной строке. Для аналитики - 3 вывода и 1 риск. Для поддержки - готовый ответ клиенту без внутреннего рассуждения. Если вам нужен итог, просите итог сразу, а не "подумать вслух".

Хорошее правило простое: в короткой версии должны остаться решение, причина и следующее действие. Все остальное обычно можно убрать. История рассуждений, длинные оговорки и повтор вопроса в проде редко нужны, а токены съедают быстро.

Когда команда заранее решает, что именно должно остаться в сжатом ответе, промпт становится чище. У ответа появляется фиксированная форма, у модели - понятный предел по количеству пунктов, а лишние объяснения уже выглядят как ошибка, а не как "полезная детализация".

Ограничение по структуре почти всегда работает лучше, чем абстрактное "ответь короче". Лучше написать: "Дай 2 пункта, до 12 слов в каждом" или "Сделай 1 абзац до 4 строк". Так модель понимает рамки, а вам проще проверять результат автоматически.

В дорогих сценариях это особенно заметно. Если один запрос идет через несколько моделей или провайдеров, даже разница в 80-100 токенов на ответ быстро превращается в лишние расходы. Если вы работаете через единый шлюз вроде RU LLM, проще держать один и тот же контракт ответа для разных моделей и не переписывать интеграцию под каждый маршрут.

Небольшой пример. Если менеджеру нужен итог по звонку, не просите "подробно проанализировать диалог". Лучше так: "Верни JSON с полями verdict, reason, next_step. Reason - не больше 20 слов". Смысл сохраняется, пустые фразы уходят, а ответ легче встроить в следующий шаг цепочки.

Как настроить max tokens по шагам

Ставить лимит наугад почти всегда плохая идея. Если взять слишком мало, модель начнет резать мысль на полуслове. Если слишком много, вы получите лишний текст и лишние расходы.

Сначала найдите рабочий диапазон

Откройте логи и смотрите не на все ответы подряд, а только на удачные. Нужны случаи, где ответ получился полным, без воды и без обрыва в конце. Обычно уже по 30-50 запросам видно, сколько токенов реально нужно вашему сценарию.

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

Потом задайте лимит с запасом

Когда рабочий диапазон понятен, ставьте max tokens чуть выше длины удачных ответов, а не сильно выше "на всякий случай". Запас нужен, но небольшой. Иначе модель снова начнет разрастаться.

После этого проверьте крайние случаи: длинные документы, редкие форматы, ответы с JSON, таблицами, цитатами. Если именно они упираются в лимит, повышайте его только для этого сценария. Один общий max tokens для всех задач почти всегда дает лишние траты в одном месте и обрывы в другом.

Полезный сигнал в логах - доля ответов, которые регулярно доходят до предела. Если таких случаев много, проблема обычно не в модели, а в слишком тесном лимите или в промпте, который просит больше, чем вы готовы отдать в ответе.

Когда stop sequences дают лучший результат

Stop sequences хорошо работают там, где у ответа есть понятная граница. Модель уже решила задачу, но потом дописывает служебный хвост, второй вывод или еще один пример. В таких случаях stop sequences режут лишнее точнее, чем грубое снижение max tokens.

Частый случай - шаблонный ответ с маркером конца. Например, вы просите краткий итог, а затем внутренний технический блок для логов. Пользователю нужен только итог. Если поставить стоп-строку перед служебной частью, модель остановится раньше и не потащит лишнее в интерфейс.

Они особенно удобны, когда:

• ответ должен закончиться после блока "Итог" или другой финальной секции;
• после основного текста модель часто пишет повторный вывод;
• в шаблоне есть внутренние секции вроде "DEBUG", "META" или служебного тега конца.

Хорошая стоп-строка - это редкий и понятный маркер конца, а не обычное слово. Подходят вещи вроде "\n<END>\n", "\n[/answer]" или отдельный технический тег, который вы сами добавили в шаблон. Плохой выбор - слова вроде "Итог", "Пример" или "Ответ": они часто встречаются в обычном тексте и могут оборвать мысль в середине.

Стоп-строку нельзя проверять на одном удачном промпте. Ее нужно гонять на реальных шаблонах: коротких, длинных, с таблицами, с кодом, с цитатами. Если вы маршрутизируете запросы через разные модели, например через RU LLM, один и тот же маркер лучше прогнать на нескольких провайдерах. Формально стоп-строка одна и та же, но конец ответа модели оформляют по-разному.

Небольшой пример. Бот поддержки отвечает так: решение проблемы, затем "Служебная заметка для CRM:". Пользовательскую часть вы хотите показать, а заметку сохранить только во внутреннем канале. Стоп-строка "\nСлужебная заметка для CRM:" решает это чище, чем попытка ужать весь ответ лимитом токенов.

Если после внедрения смысл иногда обрывается, проблема обычно не в самой идее stop sequences. Чаще всего маркер слишком общий. В таком случае меняют стоп-строку на более редкую, а не режут ответ еще сильнее.

Как сделать короткий fallback для дорогих запросов

Короткий fallback нужен не для красоты, а для контроля бюджета и задержки. Если запрос ушел в дорогую модель, а пользователю нужен ответ за пару секунд, лучше вернуть сжатую версию, чем ждать длинный текст за лишние деньги.

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

Сам fallback стоит делать очень коротким - 2-3 предложения. В первом дайте прямой ответ. Во втором добавьте самое важное ограничение или следующий шаг. В третьем, если нужно, скажите, что детали можно раскрыть отдельно. Такой формат держит смысл и не раздражает пользователя.

Один шаблон на все случаи работает плохо. Для поиска по базе нужен один fallback, для аналитики другой, для генерации письма третий. Если задача сводится к выбору варианта, дайте рекомендацию и одну причину. Если задача про объяснение, дайте вывод и предложите уточнить, что именно раскрыть: пример, расчет или пошаговый план.

Если у вас OpenAI-совместимый шлюз, короткий режим удобно включать на уровне маршрутизации. В RU LLM это можно делать без смены SDK, кода и промптов: команда сохраняет тот же интерфейс, а правило "дорого или долго - ответь короче" задает один раз.

Каждый переход в короткий режим стоит логировать. Записывайте причину, модель, оценку токенов, фактическую цену и то, попросил ли пользователь полную версию потом. Через неделю таких логов уже видно, где fallback экономит деньги, а где слишком часто режет полезный ответ.

Хороший fallback не прячет информацию. Он просто откладывает детали до явного запроса пользователя.

Пример из практики

У команды поддержки был частый запрос: сравнить условия нескольких тарифов и быстро подсказать оператору, что предлагать клиенту. Проблема появилась сразу. Если дать модели все документы и попросить "сравни тарифы", она начинала писать длинное объяснение с оговорками, примерами и повторами. Оператор тратил время на чтение, а стоимость LLM росла.

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

Потом приложение само выбирало формат. Если различий мало, оператор получал компактную таблицу на 4-5 строк. Если условий много, система просила модель выдать только итог:

• какой тариф дешевле при текущем объеме;
• где жестче ограничения;
• что стоит уточнить у клиента перед продажей.

На втором шаге команда поставила жесткий предел по max tokens и добавила stop sequences для фраз, после которых ответ обычно расползался в лишние пояснения. Например, генерация останавливалась до блока с общими советами и повтором условий. Ответ не стал хуже. Наоборот, оператор видел только то, что нужно для разговора.

Был и запасной режим. Если черновик все равно рос или запрос шел в дорогую модель, приложение включало короткий fallback. Вместо полного сравнения оператор получал 2 предложения: лучший тариф для текущих вводных и одно предупреждение о спорном месте, например о лимите или комиссии. Этого хватало, чтобы не держать клиента на линии лишние 40 секунд.

После настройки команда сравнила метрики за две недели. Средняя длина ответа упала примерно с 420 до 150 токенов. Цена одного ответа снизилась почти на треть. По внутренней проверке точность почти не изменилась: операторы так же редко исправляли итог вручную. Изменилось другое - они быстрее находили суть и реже просили систему "сказать короче".

Частые ошибки

Самая частая ошибка - ставить один и тот же лимит для всех запросов. Для классификации, извлечения полей и коротких подсказок это иногда срабатывает. Для сложного ответа с пояснением, сравнением или JSON такой подход почти всегда дает обрыв. Ограничение длины работает лучше, когда у разных сценариев свои max tokens.

Один лимит ломает разные сценарии

Слишком маленький max tokens выглядит обманчиво безопасно. Модель успевает начать уверенно, но теряет концовку: вывод, оговорку, последний пункт списка или закрывающую скобку. Пользователь видит текст, который вроде бы полезен, но уже не может нормально им воспользоваться. Это хуже, чем явная ошибка, потому что такой ответ легко принять за готовый.

Если вы снижаете стоимость LLM, режьте длину не вслепую, а под формат ответа. Короткая сводка, ответ в одну фразу и структурированный JSON требуют разного запаса токенов. Иначе один маршрут будет дорогим без причины, а другой начнет регулярно ломаться.

Стоп-строки тоже часто выбирают неудачно. Если взять stop sequences вроде "Итог:" или двойного переноса строки, можно случайно оборвать полезный текст. Модель сама любит такие куски и в середине ответа. Надежнее использовать технические разделители, которые редко встречаются в обычной речи, и проверять их на серии реальных запросов.

Fallback не должен звучать как отказ

Многие делают fallback слишком сухим: "Не могу ответить" или "Запрос слишком сложный". Пользователь читает это как сбой. Короткий fallback должен все же приносить пользу: дать один вывод, предложить следующий шаг или попросить сузить вопрос. Тогда дешевый режим не раздражает и не выглядит как заглушка.

Еще одна ошибка - не смотреть на незавершенные ответы в логах. Именно там видно, где max tokens мал, где stop sequences срабатывают раньше времени и где fallback включается слишком часто. Один такой разбор обычно быстро показывает, что именно ломает ответ и где уходят лишние деньги.

Быстрая проверка перед запуском

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

Хороший короткий ответ не прячет вывод в конце. Пользователь должен понять суть по первым строкам, даже если дальше не читает. Если модель сначала пишет длинную подводку, а потом дает цифры и условия, настройка еще сырая.

Перед запуском хватит короткой проверки:

• прогоните 10-15 реальных запросов в целевом интерфейсе;
• проверьте первые две строки отдельно - в них должны быть решение, цифра, статус или короткий совет;
• сравните короткую и полную версии на фактах, чтобы после сжатия не исчезли суммы, сроки, лимиты и исключения;
• прочитайте fallback без истории диалога и проверьте, понятен ли он сам по себе.

Простой тест быстро ловит ошибки. Допустим, полный ответ модели говорит: "Лимит 300 000 рублей, срок 30 дней, досрочное погашение без комиссии". После сжатия нельзя оставлять только "Лимит 300 000 рублей". Пользователь потеряет срок и условие, а это уже не сокращение, а искажение.

Если один пункт не проходит, не спешите поднимать max tokens. Часто помогает другой порядок ответа: сначала итог, потом детали, потом пояснение. А для дорогих сценариев лучше сразу держать короткий fallback из одной фразы, чем платить за длинный текст, который никто не дочитает.

Что сделать после первого запуска

Через несколько дней после релиза уже видно, где лимиты выбраны удачно, а где модель тратит лишние токены. Не смотрите только на средние цифры по всем запросам. Возьмите 20-30 самых дорогих обращений и разберите их вручную: где ответ можно было обрезать раньше, где stop sequences сработали поздно, а где короткий fallback сэкономил бы бюджет без потери смысла.

Обычно после такого разбора одна общая настройка распадается на несколько. Модели ведут себя по-разному, и задачи тоже. Для поиска по базе знаний можно держать один max tokens, для суммаризации документов другой, для генерации писем третий. Спокойнее жить с 3-4 профилями, чем искать один универсальный лимит для всего.

Полезно собрать простую панель с метриками. Без нее команда спорит по ощущениям, а не по фактам. Достаточно видеть среднюю и 95-й перцентиль цены на запрос, среднюю длину ответа в токенах, долю ответов, которые уперлись в max tokens, и частоту fallback по каждому сценарию.

Если видно, что fallback включается слишком часто, не поднимайте лимит везде сразу. Иногда лучше переписать промпт на более короткий формат ответа. Иногда достаточно сменить модель для одного типа задач. Так экономия обычно выходит заметнее, чем при простом росте max tokens.

Если команде нужен единый OpenAI-совместимый контур в РФ, такой разбор удобно проводить через RU LLM: можно прогнать одни и те же запросы по нескольким моделям и сравнить длину ответа, задержку и цену без смены клиентского кода. А для сценариев с требованиями 152-ФЗ стоит отдельно проверить, где лежат логи, как маскируются PII и есть ли аудит-трейлы по каждому запросу. Если оставить это на потом, потом же придется переделывать уже работающий маршрут.