Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Глубину обработки языковой модели можно подбирать под реальные запросы конкретного продукта, а не проводить каждый токен через все слои. В препринте Jerry Kaplan, который не прошёл рецензирование и в котором все числа получены самим автором, настройка порога под трафик повысила долю досрочных выходов более чем на 10 процентных пунктов на большинстве проверенных корпусов. Для внедрения этого недостаточно сравнить ответы с полной моделью: такая проверка пропустила ошибки в решаемых задачах.
Как трафик задаёт порог досрочного выхода
При обычном выводе каждый токен проходит через все слои модели. Механизм досрочного выхода добавляет к промежуточному слою небольшой обучаемый модуль считывания: он предлагает следующий токен, а проверка уверенности решает, выдать его сразу или продолжить обработку в оставшихся слоях.
Базовую модель при этом не меняют. Модуль обучают на ответах, которые сама модель уже выдаёт на обычном трафике продукта. Это позволяет приспособить досрочный выход к узкому набору запросов без дополнительной разметки ответов людьми.
Тип запросов определяет достижимую экономию. На модели с 1,5 млрд параметров при выходе с половинной глубины удалось досрочно выдать 96% токенов для арифметических текстовых задач, но только 8% для объяснений на китайском языке. В обоих случаях сохранялся одинаковый уровень совпадения токенов с полной моделью.
Из рассмотренных способов использовать знания о трафике полезным оказался только индивидуальный порог уверенности. Его калибровка для конкретного внедрения повышала долю досрочных выходов вплоть до 59 процентных пунктов на трёх моделях. Один общий порог для разных продуктов оставляет часть возможной экономии неиспользованной.
Работа рассчитана прежде всего на небольшие модели на персональных устройствах. В таком режиме генерацию ограничивает скорость чтения весов из памяти, поэтому пропуск оставшихся слоёв должен сокращать объём передаваемых данных, а не только число вычислительных операций.
Почему совпадение токенов не гарантирует правильный ответ
Стандартная метрика для досрочного выхода проверяет, насколько часто промежуточный модуль выбирает тот же токен, что и полная модель. Она измеряет сходство двух режимов генерации, но не проверяет, решила ли модель исходную задачу.
Разрыв проявился на арифметических текстовых задачах, где ответ можно сопоставить с правильным результатом. Полные модели в каждом случае правильно решили по 60 вопросов. При досрочном выходе правильными остались от 10 до 28 ответов — причём использовалась конфигурация с наивысшим совпадением токенов.
Следовательно, высокий процент совпадений нельзя принимать за гарантию прежнего качества. Для задач с проверяемым результатом порог нужно выбирать по правильности полного ответа. Если продукт генерирует код, расчёты или структурированные значения, проверка отдельных токенов может одобрить режим, который уже ломает итог.
Для ответов без однозначного эталона работа не предлагает готовой замены этой метрике. Практический вывод уже: сравнение с исходной моделью следует отделять от проверки того, выполняет ли ответ задачу продукта.
Работа меняет план испытаний, а не выбор модели
Результат не требует заранее выбирать модель с переменной глубиной. Он предлагает надстройку над замороженной моделью: обучить промежуточный модуль на её собственных ответах, затем подобрать порог под типичный трафик конкретного внедрения.
Такой эксперимент имеет смысл начинать с разделения потока запросов по продуктовым сценариям. Единый порог для помощника поддержки, генератора кода и многоязычного интерфейса противоречит главному результату работы: доступная доля досрочных выходов заметно меняется вместе с запросами.
Следующий шаг — оценивать две величины раздельно. Первая показывает, как часто модель пропускает оставшиеся слои. Вторая проверяет результат на уровне всей задачи: правильный расчёт, исполняемый код или соблюдение требуемой структуры. Порог подходит для эксплуатации только там, где выигрыш по первой величине не разрушает вторую.
Проверка охватывает упомянутые модели и несколько корпусов, включая арифметические задачи и объяснения на китайском языке, но, поскольку материал подготовлен по абстракту, из него нельзя восстановить устройство модуля считывания, процедуру калибровки и состав остальных корпусов. Поэтому работа задаёт схему пилота, но её результаты нельзя напрямую переносить в прогноз задержки или качества конкретного продукта.
Для небольших локальных моделей со стабильным и повторяющимся трафиком такой пилот может изменить план оптимизации: сначала калибровать глубину под реальные запросы, а затем решать, нужна ли замена модели или оборудования. Для облачных API и систем с постоянно меняющимся потоком работа не даёт оснований переносить приведённые доли экономии без собственных испытаний.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
