Какой LLM-моделью лучше делать ставку на компанию: дешевле начинать с простого варианта
Короткий ответ: никакой. Лучше начинать с самой дешевой модели, которая справляется с задачей. Надежность ваших данных, рабочих процессов и интеграций играет куда большую роль, чем выбранная модель.
Каждый день на этой неделе я делал то, что, подозреваю, делали и миллионы других людей: смотрел на подборщик LLM-моделей и пытался понять, какую именно мне вообще нужно хотеть.
OpenAI только что выпустила GPT-5.6 Sol, Terra и Luna. Sol — флагман. Terra предлагает большую часть интеллекта за меньшие деньги. Luna еще дешевле. Anthropic в конце июня выпустила Claude Sonnet 5, а месяцем ранее — Opus 4.8; где-то между ними появился и Fable 5. Тем временем Google, который еще несколько месяцев назад казался победителем в войне моделей, теперь получает уколы от Gergely Orosz, который утверждает, что Gemini выпал из высшего эшелона для разработки ПО и уже много месяцев не участвует в крупных релизах.
Может быть, Orosz прав. Может быть, через шесть недель он снова ошибется. Честно говоря, это утомляет.
Я постоянно использую ChatGPT и Claude и все равно почти никогда не имею принципиального понимания, какую модель выбрать. Обычно я кликаю на самую большую и дорогую опцию, потому что не понимаю, чем рискую, выбирая вариант поменьше. «Instant» звучит подозрительно несерьезно. «Thinking» звучит дорого, но мощно.
Быстрый опрос среди моих знакомых в LinkedIn показывает, что моя боль «КАКУЮ МОДЕЛЬ???» знакома не только мне. И, что важнее, я подозреваю, что предприятия тоже чувствуют то же самое.
A model doesn’t rot
Прежде чем увлекаться, стоит спросить, имеет ли вообще значение эта текучка моделей. В конце концов, модель не гниет. Модель, которую компания вывела в продакшн в марте, в июле работает так же хорошо, как и в момент выбора. «Устаревшее» обычно означает лишь, что теперь существует что-то лучшее, а не то, что развернутая модель вдруг перестала суммировать страховые претензии или классифицировать обращения в поддержку. Иными словами, если уже есть работающий вариант, мысль «а вдруг Opus 200.2 лучше!» — это проблема FOMO, а не производительности.
Большинство корпоративных задач вообще не живут на переднем крае. Извлечение, суммирование, классификация, сравнение документов и помощь клиентской поддержке часто отлично работают на меньших и более дешевых моделях. Собственная подача OpenAI для тройки GPT-5.6 заключается не только в том, что Sol лучше. Речь о том, что Terra и Luna дают разные сочетания интеллекта, задержки и стоимости. Luna, самый дешевый уровень, почти сравнялся с пиковым качеством предыдущего поколения при менее чем половине предполагаемой стоимости, по данным OpenAI.
Практический вопрос, конечно, в том, с чего начать. Предприятие не может протестировать каждую модель, каждый режим рассуждения и каждый ценовой уровень, прежде чем вообще что-то делать. Поэтому мой совет такой: начните с самой дешевой убедительной модели, которая, похоже, способна выполнить задачу. Дайте ей репрезентативный набор реальных примеров и до начала тестов определите, что считается «достаточно хорошо». Если она проходит — остановитесь. Если нет — поднимитесь на уровень выше или попробуйте модель, чьи сильные стороны лучше подходят под эту работу.
Это звучит почти вызывающе просто, но это переворачивает привычный способ, которым многие, включая меня, используют эти продукты. Мы начинаем с самой большой модели, потому что боимся, что что-то потеряем. Предприятиям же следует начинать ниже и требовать доказательств, прежде чем платить за большее количество интеллекта.
Разумеется, есть исключения. Для действительно сложной работы, такой как автономное кодирование, сложные исследования или высокорисковое рассуждение, старт с frontier-модели может сэкономить время. Но и тогда цель должна быть в том, чтобы установить верхнюю планку качества, а затем проверить, может ли более дешевая модель ее достичь. То есть нужно менять вопрос с «какая модель лучшая?» на «какая самая недорогая модель надежно проходит порог для этой работы?»
Для многих сценариев такое снижение цены важнее, чем несколько дополнительных баллов в бенчмарках. Как я писал еще в 2023 году, следование за AI hype никому не помогает. Если ваша стратегия выбора модели зависит от того, какой скриншот бенчмарка сейчас гуляет по X, стратегии у вас нет. По крайней мере жизнеспособной. Выберите модель и игнорируйте шум.
Разве что этот шум указывает на серьезный сигнал.
Sometimes better really is better
Улучшения на frontier-уровне не всегда бывают постепенными, поэтому иногда разумно подумать об апгрейде. Кодирование — самый очевидный пример. Есть большая разница между моделью, которая подсказывает следующие несколько строк кода, и моделью, которая может изучить репозиторий, спланировать изменение, использовать инструменты, запустить тесты, обнаружить собственные ошибки и продолжать работу длительное время. Это не просто более приятный autocomplete. Это может перестроить весь процесс разработки.
Именно поэтому предприятия не могут просто стандартизироваться на модели, которой 18 месяцев, и объявить победу. В некоторых областях, особенно в разработке ПО и другой agentic-работе, более сильные модели могут запускать эффект накопительной продуктивности. Модель, которая надежно завершает 80% ограниченной задачи вместо 50%, может оправдать совершенно другое распределение труда между людьми и машинами.
Но такой апгрейд не бесплатен.
Модели по-разному интерпретируют инструкции, вызывают инструменты, управляют контекстом, отказывают в запросах и ошибаются. Подсказки и scaffolding, настроенные под одну модель, могут деградировать при переносе на другую. Или стоимость может взлететь. Как на этой неделе обнаружил один из моих коллег в Oracle, выполнение тех же задач в GPT 5.6 оказалось на порядки дороже, чем в 5.5. Изменение API может быть пустяковым, но повторная валидация и ее последствия — нет.
В результате предприятия оказываются между двумя плохими вариантами. Можно заморозиться и, возможно, упустить значимые улучшения. А можно гнаться за каждым релизом и снова и снова тестировать production-системы на веру. Что делать?
Stop making model bets
Ответ — перестать делать ставки на LLM и начать делать ставки на job-to-be-done. Перестаньте спрашивать, какая модель быстрее. Вместо этого выясните, какую именно работу вы хотите улучшить. Как выглядит хороший результат? Сколько задержки и стоимости выдерживает этот workflow? Насколько сильно он может ошибаться, прежде чем понадобится вмешательство человека? Когда на эти вопросы есть ответы, выбор модели становится менее непрозрачным.
Сложная миграция кода может оправдать GPT-5.6 Sol или Claude Sonnet 5. Повторяющаяся задача классификации может отлично работать на Luna или другой более маленькой модели. Регулируемый процесс может требовать модель или вариант развертывания с особыми средствами контроля данных. Иногда правильная модель — это вообще не LLM, как, например, когда я пишу этот текст. Извините, вендоры AI! По крайней мере, вам не придется отвечать за мои ошибки.
Именно здесь evaluation становятся центром enterprise AI strategy. Как я уже говорил раньше, у большинства компаний проблема не столько в качестве AI, сколько в измерении AI. Поэтому private evaluation suite, построенный на реальной работе компании, — единственный leaderboard, который имеет значение. Новая модель заметно улучшает качество? Тогда используйте ее. Она снижает стоимость или задержку? Снова свободный проход к внедрению. Улучшение оправдывает расходы и труд на повторную валидацию? Если да, продолжайте.
Make model releases boring
Как бы важна ни была модель, помните: успех AI всегда возвращается к вашим данным, вашим workflow, вашим интеграциям и так далее. В этом и заключается скучная реальность за sexy AI. Retrieval, memory, governance, качество данных, observability и feedback loops не так захватывают, как запуск новой модели, но именно они в конечном счете делают AI по-настоящему работающим.
И снова: когда приходит время смотреть на что-то новое, принцип должен быть таким — по умолчанию брать самую дешевую модель, которая надежно проходит ваши evaluation. На более способные модели стоит поднимать только более сложные задачи, когда измерения показывают, что премия окупается. Совет: сделайте это невидимым для сотрудников, чтобы система сама маршрутизировала запрос к лучшей модели под конкретный prompt. Как выразился Jon Lewis из dbt Labs, «лучшая модель — это “Auto”, и я не хочу слышать ничего другого». Собственное migration guidance от OpenAI рекомендует тестировать модели на репрезентативных задачах, включая проверку более низкого уровня reasoning вместо автоматического выкручивания всего на максимум.
Что касается меня, я, вероятно, и дальше буду нажимать на самую блестящую опцию. У меня нет формального evaluation suite для колонок InfoWorld, а marginal cost — это уже оплаченная подписка. Предприятиям такой отговорки не дано.
Материал — перевод статьи с английского.