Как проверить, что LLM соблюдает лимит длины ответа
В API LLM параметр максимального числа выходных токенов ограничивает генерацию, но не задаёт точное число слов или символов. Если продукту нужен ответ не длиннее 500 слов, одной настройки `max_output_tokens` недостаточно: токенизация зависит от текста и модели, а ответ может закончиться раньше лимита или оборваться из-за него. Проверка лимита длины ответа должна учитывать и измерение результата, и причину завершения генерации.
Это важно для интерфейсов с жёсткими ограничениями, JSON-ответов, карточек товаров и систем, где длинный вывод увеличивает стоимость или ломает последующую обработку. Ниже — практический способ превратить расплывчатое «пиши кратко» в проверяемое требование.
Почему токены не равны словам и символам
Токен — единица, на которую конкретный токенизатор разбивает текст. Это может быть слово целиком, его часть, знак препинания или пробел. Поэтому одинаковый объём текста в символах может давать разное количество токенов; соотношение меняется с языком, содержимым и используемой моделью.
Документация OpenAI описывает ограничение выходных токенов как верхнюю границу генерации, а не гарантию получить ровно заданное число. Инструмент `tiktoken` позволяет считать токены для поддерживаемых токенизаторов OpenAI, но это не универсальный счётчик для любых моделей. В Transformers у Hugging Face токенизация также связана с конкретным токенизатором модели.
Отсюда два разных требования:
- Техническое: не сгенерировать больше N токенов.
- Продуктовое: уложиться в N слов или символов, сохранить структуру и не оборвать смысл.
Если интерфейс показывает ограничение в 300 символов, проверять только токены бессмысленно: отображаемый текст следует измерять в символах после получения ответа. Если важно ограничить нагрузку на API, отдельно проверяют число выходных токенов и причину завершения.
Как задать проверяемый критерий длины ответа
Начните не с формулировки для модели, а с правила, которое можно проверить программно. Например: «Ответ содержит не более 500 слов, состоит из двух абзацев и не заканчивается незавершённым предложением». Здесь длина, формат и целостность — отдельные условия.
Зафиксируйте четыре параметра:
Единица измерения. Токены, слова, символы с пробелами или без них.
Область подсчёта. Весь ответ, текстовое поле JSON или только видимая пользователю часть.
3. Граница. Не более N либо диапазон от N до M.
4. Дополнительные требования. Например, валидный JSON, обязательные поля, отсутствие оборванного предложения.
Определите также, что делать с Markdown, кодом и служебными полями. Иначе один тест будет считать разметку, а другой — только текст. Для русскоязычного продукта полезно явно решить, считать ли числа, аббревиатуры и слова с дефисом отдельными единицами: стандартного определения «слова» для всех задач нет.
Как измерять текст: токены, слова и символы
Символы обычно считать проще всего. В Python длина строки `len(text)` считает кодовые точки Unicode, но это не всегда совпадает с воспринимаемыми пользователем графемами: некоторые эмодзи и составные символы могут состоять из нескольких кодовых точек. Если интерфейс ограничивает видимую длину, проверьте на реальных примерах, как именно считает символы сам интерфейс.
Для грубой оценки слов можно использовать разбиение по пробелам, но оно плохо обрабатывает пунктуацию и некоторые языковые случаи. Надёжнее определить правило подсчёта через регулярное выражение или библиотеку, а затем закрепить его тестами. Важно не менять это правило незаметно после запуска.
Для токенов используйте токенизатор, соответствующий модели. Например, в Python с `tiktoken`:
python
import tiktoken
encoding = tiktoken.encoding_for_model(«gpt-4o»)
text = «Проверяем длину ответа на русском языке.»
token_count = len(encoding.encode(text))
print(token_count)
Этот код применим только там, где выбранная модель поддерживается библиотекой и её отображением токенизатора. Для другой модели берите официальный или рекомендованный её разработчиком способ подсчёта. Документация Anthropic, например, описывает отдельный API для оценки числа токенов входного сообщения Claude; не следует подставлять его результат вместо точного счёта выходного текста, если документация прямо этого не обещает.
Как отличить короткий ответ от усечённого
Меньшее число токенов само по себе не доказывает, что ограничение сработало правильно. Модель могла завершить ответ раньше, потому что считает задачу законченной. И наоборот, ответ может упереться в лимит и оборваться посреди структуры или предложения.
Сохраняйте вместе с текстом метаданные ответа: использованные токены, статус завершения и доступные API сведения о причине остановки. Названия полей зависят от API и версии; сверяйтесь с документацией конкретного endpoint. В Responses API OpenAI, например, объект ответа содержит сведения о статусе и деталях завершения. Не интерпретируйте отсутствие явного признака усечения как доказательство смысловой полноты.
Для JSON проверяйте оба уровня: парсинг и схему. Валидный JSON может всё равно не соответствовать требуемой длине, а оборванный JSON обычно указывает на проблему завершения, но может быть вызван и иными ошибками. Разделяйте эти результаты в логах, чтобы понимать, чинить ли лимит, форматирование или инструкцию.
Воспроизводимый тест на заданном наборе запросов
Проверять длину на одном удачном примере недостаточно. Подготовьте небольшой набор запросов, который отражает реальные сценарии: короткие и длинные исходные данные, русский текст с числами и аббревиатурами, код или списки, если они встречаются в продукте.
Для каждого запроса выполните одинаковое число запусков при фиксированных настройках модели. Если API поддерживает параметр случайности, сохраните его значение. Запишите:
- версию или идентификатор модели и дату проверки;
- параметры лимита и генерации;
- длину результата в нужных единицах;
- причину завершения и статус ответа;
- валидность формата и выполнение требований к содержанию.
Сравнивайте не только среднее значение, но и максимум, долю превышений лимита и долю ответов, оборванных на границе. Для строгого ограничения важнее худший результат, чем средняя длина: среднее в 450 слов не спасёт интерфейс, если отдельные ответы достигают 700.
Пример простой проверки после получения текста:
python
def check_response(text, max_chars):
return {
«chars»: len(text),
«within_limit»: len(text) <= max_chars,
}
result = check_response(«Короткий проверочный ответ.», 500)
assert result[«within_limit»]
Это тестирует только символы, не токены, смысл или полноту. В реальном конвейере добавьте отдельные проверки и сохраните причину завершения API. Не смешивайте всё в один булев результат: иначе нельзя понять, что именно нарушено.
Что делать, если модель регулярно превышает лимит
Сначала проверьте, что именно превышается. Если выходных токенов больше заданной границы, вероятны неправильная настройка, несовпадение параметров с используемым endpoint или ошибка измерения. Если токены в норме, а слов или символов слишком много, нужна отдельная продуктовая проверка и, возможно, более низкий технический предел.
Инструкцию «ответь максимум в 100 слов» можно оставить как подсказку модели, но не считать механизмом контроля. Для надёжного ограничения используйте несколько слоёв:
- задайте разумный предел генерации в API;
- сформулируйте целевую длину и структуру в запросе;
- измерьте фактический текст после генерации;
- при превышении выполните контролируемое сокращение или запросите новую версию;
- повторно проверьте формат и смысл после обработки.
Автоматическое обрезание строки по символам может удалить обязательную оговорку или сломать JSON. Безопаснее отклонить результат и повторить запрос с более строгим требованием либо сократить его отдельной операцией, которая затем проходит те же проверки. Повторный вызов увеличивает задержку и расход, поэтому его частоту тоже стоит измерять.
Как выбрать предел с учётом стоимости и контекста
Входной и выходной контекст — разные части бюджета. Ограничивая только ответ, вы не гарантируете, что весь запрос помещается в контекст модели: история диалога, инструкции и переданные документы тоже занимают место. Документация провайдеров описывает эти ограничения по-разному, поэтому перед запуском сверяйте параметры конкретной модели и API.
Для оценки стоимости ориентируйтесь на фактическое использование токенов, указанное в ответе API, а не только на настроенный максимум. Максимальный лимит задаёт возможный потолок генерации, но не означает, что каждый запрос его исчерпает. Сравните на своём наборе запросов медиану, верхние значения и частоту повторов после превышения длины.
При выборе параметров задайте вопрос: что дороже — иногда получить длинный ответ, повторно вызвать модель или потерять часть содержания из-за жёсткого усечения? Для краткой подписи может подойти строгий постфильтр; для ответа с рекомендациями безопаснее сохранить смысл и попросить модель сократить текст, чем обрезать последние символы.
Чек-лист перед внедрением
Перед выпуском ограничения проверьте несколько вещей:
- Счётчик соответствует именно той модели и единице измерения, которые нужны продукту.
- Длина измеряется на том тексте, который действительно увидит пользователь.
- В логах сохраняются статус завершения и доступные сведения о причине остановки.
- Тестовый набор включает реальные длинные и нестандартные запросы.
- Отдельно проверяются формат, обязательные поля и смысловая целостность.
- Повторная генерация или сокращение имеют ограничение по числу попыток и контролируются по стоимости.
- После обновления модели, токенизатора или API тесты запускаются заново.
Лимит токенов полезен как технический предохранитель, но соответствие словесному или символьному требованию доказывает только измерение самого результата. Зафиксируйте правило подсчёта, прогоните репрезентативные запросы и проверьте причины завершения — тогда ограничение станет тестируемым свойством системы, а не надеждой на формулировку в промпте.
