Как выбрать модель под задачу: качество, скорость, цена

Выбор модели часто делается один раз и по репутации: «возьмём самую сильную, потом разберёмся». Потом не разбираются. Через полгода в продукте десять функций, все на одной модели, и никто не знает, какой из них она действительно нужна.

Модель — это компромисс между тремя вещами, и получить максимум по всем сразу не выйдет. Задача — понять, что важно именно этой функции.

Три оси

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

Задержка. Сколько ждёт человек. У неё две части, и их стоит мерить отдельно:

• время до первого токена — важно, если ответ показывается потоком;
• полное время ответа — важно, если результат нужен целиком: заполнить форму, принять решение в коде.

Стоимость. Цена одного вызова, умноженная на то, сколько раз функция вызывается. Функция, которую дёргают на каждое нажатие клавиши, и функция, которую запускают раз в неделю, — разные задачи даже при одинаковом промпте.

Расставь приоритеты по функциям

Для каждой функции ответь, что из трёх для неё главное:

• подсказки при наборе, автодополнение, сортировка — главное скорость. Ответ через три секунды здесь хуже, чем отсутствие ответа;
• разбор договора, сложный анализ, генерация кода — главное качество. Человек готов подождать, а ошибка стоит дорого;
• фоновая обработка больших объёмов — классификация, извлечение полей, разметка — главное стоимость и пропускная способность. Никто не ждёт, но вызовов много.

После этого становится видно, что одна модель на всё — почти всегда неправильный выбор хотя бы для части функций.

Начни с младшего уровня

Разумный порядок проверки — снизу вверх. Возьми самую лёгкую модель, которая в принципе может справиться, прогони на ней свой проверочный набор — двадцать–пятьдесят реальных примеров с критериями хорошего ответа. Не хватает — поднимись на уровень выше. Остановись там, где результат устраивает.

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

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

Маршрутизация вместо одной модели

Не обязательно выбирать одну модель на функцию. Рабочие схемы:

• по сложности — простые запросы идут на лёгкую модель, сложные на старшую. Сложность можно определить правилом (длина, тип документа) или той же лёгкой моделью;
• с эскалацией — сначала отвечает лёгкая модель, ответ проверяется; если проверка не прошла, запрос уходит к старшей;
• по этапам — лёгкая модель отбирает и готовит данные, старшая пишет итоговый ответ.

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

Измеряй в продакшне

Проверочный набор отвечает на вопрос «годится ли», продакшн — «как работает на самом деле». Записывай для каждого вызова модель, время до первого токена, полное время, число токенов и итог: принял ли человек результат, повторил ли, исправил ли. Через пару недель станет видно, где модель с запасом и где на пределе.

Не привязывайся намертво

Модели обновляются, появляются новые уровни, старые снимают с поддержки. Чтобы смена модели была правкой конфигурации, а не переписыванием:

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

Итог

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

SUBXCAT может сравнить модели на твоих задачах и настроить маршрутизацию так, чтобы смена модели занимала минуты.