Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Большинство способов сократить ответ LLM во время генерации не находят лишний текст, а лишь раньше останавливают модель. Mahmoud Alyosify, Mirna Imbabi и Eman Elkhamisi проверили это в препринте, который не прошёл рецензирование и содержит замеры самих авторов: контроллер убирал 25–35% токенов, но результат всегда совпадал с началом исходного ответа. Для продукта это разделяет две задачи: снизить стоимость генерации можно ранней остановкой, а убрать повторы без потери содержания гораздо сложнее.
Почему контроллер длины не выбирает лишнее
Авторы предлагают простой критерий для любых методов сокращения. Результат нужно сравнивать не с полным ответом, а с тем же ответом, обрезанным до точно такой же длины. Если метод сохраняет не больше содержания, чем эта обрезка, он не управляет многословием — он только выбирает место остановки.
Проверенный процессор менял оценки вариантов следующего токена в зависимости от энтропии — неопределённости модели при выборе продолжения. После заданной позиции он повышал вероятность токена завершения, когда неопределённость становилась достаточно высокой.
На рабочей конфигурации процессор не менял оценки обычных токенов. Поэтому при жадной генерации он мог либо выбрать тот же следующий токен, что исходная модель, либо закончить ответ. Полученный текст неизбежно оставался префиксом, то есть началом неизменённого ответа.
Формальные метрики это не выявили. Они считали длинный общий фрагмент признаком сохранённого качества, хотя процессор мог оборвать новую мысль посреди предложения и не удалить ни одного повтора. Сравнение с обрезкой той же длины сразу показывало, что содержательного выигрыша нет.
Проверка ещё 23 семейств методов без дообучения дала тот же общий результат. Подсказки о краткости создавали другой, более короткий ответ; вмешательство в выбор токенов уводило генерацию по новой траектории; отбор и удаление фрагментов не находили достаточно повторов либо работали не лучше обрезки. Модель могла использовать готовую оценку полезности, но плохо определяла избыточность собственных предложений.
ELIDE скрывает фрагмент, но не прекращает его генерацию
ELIDE отделяет текст, который видит модель, от текста, который получает пользователь. На границе предложения система сначала ищет похожий уже показанный фрагмент, затем модель логического вывода проверяет, следует ли новое предложение из предыдущего текста. Если следует, предложение скрывают.
Скрытый фрагмент остаётся в контексте модели и в её кэше состояний. Модель продолжает генерацию так, словно читатель увидел весь ответ, поэтому ELIDE не меняет последующие токены. Метод экономит место в интерфейсе и токены при дальнейшей обработке ответа, но не вычисления исходной генерации.
Первая версия обошла обрезку той же длины по автоматическим метрикам, однако ручная проверка обнаружила вред в 59% удалений. Система скрывала повторяющиеся атрибуты разных пунктов списка, прямой ответ как повтор вопроса, припевы и служебные элементы структурированного текста. Автоматические модели считали содержание восстановимым, хотя для читателя ответ становился хуже.
Повышение порога уверенности до 0,99 не исправило ошибку: вредными оставались 59–61% прошедших отбор фрагментов. Два одинаковых предложения действительно следуют друг из друга, но это не означает, что одно можно удалить, если они относятся к разным объектам. Проблема оказалась не в уверенности модели, а в том, какой предыдущий текст разрешено использовать как основание.
В ELIDE v2 поиск ограничили текущим пунктом списка или смысловым блоком, запретили удалять ответ как повтор вопроса и добавили защиту для диалогов, стихов и структурированных форматов. На свежих проверках вредным оставалось примерно одно удаление из десяти, а объём скрытого текста составил 0,96%. Метод стал аккуратнее, но практическая экономия оказалась небольшой.
Основные опыты охватывали Mistral-7B-Instruct-v0.2, Llama-3.1-8B-Instruct и Qwen2.5-3B-Instruct с жадной генерацией на NVIDIA A40. ELIDE проверяли на публичных наборах запросов и двух свежих выборках, затем переносили на OLMo-2 и Granite-3.1. Ручную оценку удалений проводили внутри исследования, поэтому результаты прежде всего задают способ проверки, а не готовую гарантию безопасности.
Что меняется в планах продуктовой команды
Контроллер завершения имеет смысл, если продукт допускает обычную обрезку: например, ответ всё равно ограничен карточкой, сообщением или бюджетом. Тогда его нужно оценивать как стратегию остановки и отдельно проверять, не обрывает ли он инструкции, код и перечисления. Называть такой механизм удалением многословия не стоит.
Если нужен короткий самостоятельный ответ, сначала проще явно просить модель писать кратко. В опытах такая инструкция сокращала ответы на 36–50%, но модель заново выбирала содержание, а не удаляла повторы из уже сформированного текста. Поэтому качество следует проверять на задачах продукта, а не через сходство с длинным вариантом.
ELIDE подходит только там, где ценны показанные или повторно передаваемые токены, а не стоимость первоначального вывода модели. Его стоит рассматривать как отдельный фильтр представления с журналом каждого удаления, ограничением контекста внутри смыслового блока и ручной проверкой на реальных форматах продукта.
Главное изменение для испытаний — обязательная базовая линия с обрезкой до той же длины. Если метод её не превосходит, он не выбирает содержание. Если превосходит, этого всё равно недостаточно: история ELIDE показывает, что автоматические оценки могут одобрить удаление, которое меняет смысл или ломает форму ответа.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
