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

Для меня вопрос «как выбрать LLM» начинается не с таблицы моделей, а с границы процесса. Что система должна делать, какие ошибки действительно дороги, сколько времени можно ждать ответ и какие данные вообще допустимо отправлять внешнему провайдеру?

Если эти условия не определены, сравнение быстро превращается в спор брендов. Я бы вместо этого собрал небольшой набор собственных сценариев и проверил модели на одинаковых правилах.

Сначала определите единицу полезного результата

Для одного процесса полезным результатом будет корректно классифицированное обращение. Для другого — заполненная структура договора, выбранный следующий шаг или безопасный tool call. Сравнивать модели по общему впечатлению от ответа здесь слишком грубо.

Я бы описал 20–50 реальных примеров и заранее зафиксировал, что считается успехом. Если ответ может быть разным по формулировке, оценивать нужно не совпадение текста, а правильность решения, обязательные поля и отсутствие критичной ошибки.

Так model evaluation становится частью бизнес-процесса. Microsoft рекомендует выбирать модель исходя из требований workload, а не из универсального лидерборда.

Проверяемые источники: Microsoft Learn — Choose the Right AI Model for Your Workload

Качество без latency может оказаться бесполезным

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

Я бы разделял offline и interactive сценарии. В первом можно позволить более долгий inference ради качества. Во втором нужен latency budget, после которого даже правильный ответ приходит слишком поздно.

Anthropic отдельно описывает способы уменьшать latency и подчёркивает компромисс между размером модели, числом токенов и временем ответа.

Проверяемые источники: Anthropic — Reducing latency

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже
Как выбрать LLM для бизнеса: качество, цена, задержка и данные · временная заглушка

Считать стоит стоимость завершённой операции

Цена за токен удобна для тарифа, но плохо отвечает на вопрос бизнеса. Более дешёвая модель может потребовать повторного вызова, дополнительной проверки или чаще отправлять результат человеку.

Поэтому я бы считал стоимость корректного outcome: inference, retries, tool calls, validation и ручное исключение. Иногда более дорогая модель выигрывает именно потому, что весь остальной процесс становится короче.

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

Проверяемые источники: Anthropic — Pricing

Данные и инструменты могут сузить выбор раньше качества

Не каждый workload можно отправлять в любой внешний API. У компании могут быть требования по региону обработки, retention, доступу к логам или договорным условиям. Это стоит проверять до большого сравнительного теста.

Второй фильтр — инструменты. Если процесс зависит от structured outputs, tool use, длинного контекста или мультимодальности, эти возможности становятся частью минимального контракта модели.

Я бы не пытался компенсировать отсутствующую базовую возможность сложным prompt. Проще исключить модель из этого сценария и сравнивать оставшиеся варианты.

Проверяемые источники: Microsoft Learn — Choose the Right AI Model for Your Workload · Anthropic — Choosing the right model

Одна модель не обязана выигрывать все классы задач

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

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

Это также уменьшает риск преждевременной привязки всей системы к одному варианту модели.

Проверяемые источники: Anthropic — Choosing the right model

Мой минимальный тест перед выбором модели

Я бы взял реальные примеры из процесса, включил несколько неприятных исключений и прогнал две-три подходящие модели с одинаковым контрактом. Для каждой сохранил бы quality outcome, latency, стоимость и причину ручной проверки.

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

Хороший выбор — не модель с максимальным числом побед в интернете. Это модель, которая укладывается в ограничения конкретного процесса и оставляет понятный путь проверки результата.

Проверяемые источники: Microsoft Learn — Choose the Right AI Model for Your Workload

Смена модели должна быть частью теста ещё до production

Я бы сделал небольшой portability check сразу после выбора: взять два-три критичных примера и прогнать их на ближайшей альтернативе. Не ради multi-model архитектуры, а чтобы понять, насколько наш contract специфичен.

Если альтернативе нужен другой prompt или отдельная схема tool use, это нормально. Важно записать различия и сохранить их рядом с eval-set. Тогда через полгода решение можно пересмотреть без повторного исследования с нуля.

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

Проверяемые источники: Microsoft Learn — Choose the Right AI Model for Your Workload · Anthropic — Choosing the right model

Вопросы, которые я бы уточнил до следующего шага

Нужно ли всегда выбирать самую сильную LLM?

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

Сколько примеров нужно для сравнения моделей?

Универсального числа нет. Для первого решения я бы предпочёл небольшой, но репрезентативный набор реальных кейсов с критичными исключениями, а затем расширял его по production-ошибкам.

Можно ли доверять публичным benchmark?

Они полезны для предварительного отбора, но не заменяют проверку на собственном workload. Бизнесу важна не средняя способность модели, а результат на конкретных операциях.

Если бы это был мой проект, я бы не пытался выбрать LLM «на год вперёд». Я бы зафиксировал текущий contract и eval-set, выбрал модель для него и оставил возможность повторить тест позже. В быстро меняющемся рынке способность спокойно пересмотреть выбор иногда важнее самого первого выбора.

Рядом с этой темой я бы держал для «как выбрать LLM»: Как посчитать эффект от AI-автоматизации до запуска · Как ограничить стоимость AI-системы · AI-агент для бизнеса: от copilot к ограниченной автономности.