Вопрос «какая модель лучше» задают чаще всего и отвечают на него хуже всего — обычно ссылкой на рейтинг.
Рейтинг отвечает на другой вопрос: какая модель сильнее в среднем по чужим задачам. Ваш вопрос иной — какая справится с вашей задачей, на ваших текстах, в рамках ваших ограничений и по приемлемой цене. Ответы совпадают не всегда, и проверить это стоит день работы.
Ниже — признаки, по которым выбирают, в порядке важности. Названий конкретных моделей я почти не привожу: они меняются быстрее, чем устаревает эта статья, а критерии остаются.
Признак 0: где могут обрабатываться данные
Стоит перед всеми остальными, потому что отсекает варианты целиком, а не сдвигает предпочтения.
Если в запросах будут персональные данные, коммерческая тайна или внутренние документы, вопрос «куда уходит текст» решается до всех прочих. Часть организаций этим ограничением закрывает облачные модели полностью — «152-ФЗ и нейросети».
Ответ определяет, выбираете вы из облачных сервисов или из моделей, которые можно развернуть у себя, — «Открытые модели для русского языка».
Признак 1: качество на вашей задаче
Не «качество вообще», а на вашем классе задач и ваших текстах.
Модель, отлично пишущая тексты, может хуже извлекать поля из документов. Модель, сильная на английском, может уступать на русском. Модель, понимающая общие темы, может не различать вашу профессиональную терминологию.
Проверяется только измерением на своём наборе — «Тестирование модели на своей задаче».
Признак 2: стоимость обращения
Считается не по цене за тысячу токенов, а по стоимости одной операции вашего процесса: сколько текста уходит в запросе, сколько возвращается, сколько обращений на задачу.
Разница между моделями в цене за токен может быть десятикратной, а разница в стоимости операции — иной, потому что более сильная модель иногда решает задачу за один заход там, где слабая требует трёх. Разбор — «Длина контекста и стоимость».
Признак 3: скорость ответа
Для переписки почти безразлична, для голосового сценария определяющая, для пакетной обработки ночью не важна вовсе.
Смотреть надо на два числа: время до первого символа и скорость выдачи. Первое важно там, где ответ показывается человеку сразу.
Признак 4: длина контекста
Сколько текста модель принимает за раз. Определяет, поместится ли ваш документ целиком или его придётся резать.
Оговорка, которую редко делают: заявленная длина контекста и длина, на которой модель работает хорошо, — разные величины. Качество ответов на очень длинных входах обычно падает, и проверять это надо на своих данных.
Признак 5: поддержка нужных возможностей
Строгий формат ответа, вызов инструментов, работа с изображениями. Если конвейеру нужен предсказуемый формат — «Структурированный вывод модели», — модель должна это поддерживать, иначе надёжность падает независимо от её «ума».
Признак 6: доступность и устойчивость
Не в смысле аптайма, а в смысле: сможете ли вы пользоваться этой моделью через год. Ограничения по регионам, требования к оплате, изменения условий — «Если зарубежная модель недоступна».
Практическое следствие: слой доступа к моделям стоит закладывать сразу — «Шлюз моделей».
Признак 7: договорные условия
Что происходит с вашими запросами: используются ли для обучения, сколько хранятся, есть ли договор с юрлицом, кто отвечает за сбои. Для облачных сервисов это часть выбора наравне с качеством.
Как выбрать за день
Порядок, который экономит недели.
Шаг 1. Отсеките по ограничениям. Обработка данных, доступность, необходимые возможности. Обычно после этого остаётся два-четыре кандидата, а не двадцать.
Шаг 2. Соберите набор задач. 50–100 реальных случаев с известным правильным результатом. Реальных, а не придуманных: придуманные формулируются удобно и решаются всеми.
Шаг 3. Прогоните кандидатов на одинаковом промпте. Одинаковом — иначе вы сравниваете промпты, а не модели.
Шаг 4. Посмотрите на провалы отдельно. Не только на среднюю долю верных ответов. Часто одна модель лучше в среднем, но систематически проваливает важный класс случаев — и это решает выбор.
Шаг 5. Посчитайте стоимость операции на реальных объёмах, а не за тысячу токенов.
Шаг 6. Проверьте под нагрузкой, если поток заметный — «Нагрузочное тестирование».
Частая ошибка: брать самую сильную
Крупные модели дороже и медленнее. Для узкой задачи — классификация обращений, извлечение полей, приведение текста к формату — часто достаточно небольшой модели, и разница в стоимости оказывается кратной.
Разумная стратегия: начать с сильной модели, чтобы понять достижимый потолок, затем проверить, справится ли модель попроще. Первое даёт ориентир качества, второе — экономию. Разбор — «Малые модели для бизнес-задач».
В конвейере из нескольких шагов разные шаги вполне могут работать на разных моделях: тяжёлая на сложном шаге, лёгкая на простых.
Разбор: почему выбрали не лучшую по рейтингу
Задача. Разбор входящих документов: определить тип, извлечь реквизиты. Поток около 2 000 документов в месяц. Документы содержат персональные данные.
Что отсеклось сразу. Требование заказчика — обработка внутри контура. Облачные сервисы отпали целиком, независимо от качества. Осталось три открытые модели, которые можно развернуть.
Что показала проверка на своём наборе. Собрали 80 реальных документов с проверенными значениями полей.
Самая крупная из кандидатов дала лучший результат по доле верно извлечённых полей. Средняя показала результат немного хуже. Небольшая — заметно хуже на сложных документах, но практически одинаково на типовых.
Что решило выбор. Посмотрели на распределение: типовые документы составляли около 80% потока, и на них все три модели работали одинаково.
Взяли схему из двух моделей: небольшая обрабатывает всё, а документы, где сработала проверка или флаг неуверенности, переобрабатываются крупной. Средняя не понадобилась.
Результат. Качество на уровне крупной модели, потребление видеопамяти и стоимость эксплуатации — ближе к небольшой. Требования к оборудованию снизились настолько, что хватило одной видеокарты вместо двух — «Расчёт видеопамяти».
Что стоит забрать. Вопрос «какая модель лучше» оказался неправильно поставленным. Правильный — «какая комбинация закрывает поток дешевле при том же качестве».
Чего не стоит делать
Выбирать по рейтингу без проверки. Рейтинг — повод включить модель в список кандидатов, а не основание для решения.
Сравнивать на разных промптах. Тогда вы сравниваете формулировки, а не модели.
Проверять на придуманных примерах. Они решаются всеми и ничего не показывают.
Игнорировать стоимость операции. Цена за токен без учёта длины запроса и числа обращений ни о чём не говорит.
Привязываться намертво. Модель придётся менять — из-за цены, доступности или появления лучшей. Закладывайте возможность миграции с самого начала.
Частые вопросы
Какую модель выбрать для бизнес-задачи?
Ту, что лучше работает на вашей задаче в рамках ваших ограничений, — и это определяется измерением, а не рейтингом. Порядок такой: сначала отсечь варианты по требованиям к обработке данных и доступности, затем прогнать оставшихся кандидатов на наборе из реальных случаев с одинаковым промптом.
Нужно ли брать самую сильную модель?
Обычно нет. Для узких задач — классификации, извлечения полей, приведения текста к формату — часто достаточно небольшой модели при кратной разнице в стоимости. Разумная стратегия: сильной моделью выяснить достижимый потолок качества, затем проверить, справится ли модель проще.
Можно ли доверять сравнениям моделей?
Как источнику списка кандидатов — да. Как основанию для выбора — нет: они измеряют среднее по чужим задачам, а ваш вопрос про ваши тексты и вашу терминологию. Проверка на своём наборе занимает день и регулярно даёт результат, отличный от рейтинга.
Что важнее — качество или стоимость?
Зависит от того, что происходит при ошибке. Там, где ошибка обратима и дёшева, выигрывает более дешёвая модель с проверками. Там, где ошибка дорога, экономия на модели обычно не оправдывается. Считать нужно стоимость операции целиком, включая разбор ошибок человеком.
Можно ли использовать разные модели на разных шагах?
Не только можно, но и разумно: тяжёлая модель на сложном шаге, лёгкая на простых. Это одна из самых действенных мер по сокращению расходов, и она требует, чтобы доступ к моделям был устроен через общий слой, а не прибит к коду.
Что делать, если модель перестанет быть доступной?
Заранее исходить из того, что это возможно: не привязывать код к конкретному поставщику, держать проверенную запасную модель и иметь набор тестов, на котором замена проверяется за часы. Без такой подготовки смена модели превращается в отдельный проект.
Что дальше
Российские облачные модели — «YandexGPT или GigaChat». Если данные не должны покидать контур — «Открытые модели для русского» и «Облако или свой сервер». Как проверять выбор — «Тестирование модели на своей задаче».
Подбор модели и проверка на вашей задаче — часть работы по разработке и внедрению ИИ.