Как выбрать AI-модель под рабочую задачу, а не по общему рейтингу

Сформулируйте решение, которое модель должна улучшить

Фраза «нужна модель для работы» слишком широка. Зафиксируйте единицу результата: извлечённая таблица, черновик ответа, классификация обращения, патч кода или аналитическая записка. Опишите, кто проверяет выход и что произойдёт при ошибке. Для извлечения реквизита критична точность поля; для мозгового штурма важнее разнообразие; для массового triage — стабильная задержка и предсказуемая цена.

Запишите обязательные ограничения как gate, а не как пожелания. Например: ни один документ определённого класса не покидает согласованный контур; ответ без цитируемого источника помечается UNKNOWN; p95 должен укладываться в пользовательский сценарий; JSON проходит schema validation. Модель, нарушившая gate, не компенсирует это красивым средним баллом.

Только после этого выбирайте кандидатов. Включите текущую базовую систему, иначе улучшение не с чем сравнить. Если процесс сейчас выполняет человек с шаблоном или детерминированный parser, это честный baseline. Большая модель должна доказать пользу относительно него, а не относительно пустого экрана.

Соберите eval-набор до чтения рейтингов

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

Для точных задач используйте ground truth и программные проверки. Для открытого текста создайте рубрику: полнота, фактическая поддержка, соблюдение формата, ненужные допущения и объём ручной правки. Два проверяющих должны понимать шкалу одинаково. Модель-судья может ускорить triage, но контрольный поднабор нужен человеку, иначе ошибки оценщика становятся невидимыми.

Фиксируйте всю конфигурацию: provider, model ID или commit, дату, системные инструкции, sampling, retrieval, инструменты и лимиты. Сравнение «модель A против модели B» бессмысленно, если одной дали другой prompt или больше документов. Повторяемость важнее красивой таблицы, потому что через месяц тест придётся запускать снова.

Матрица выбора по типам задач

Матрица не назначает конкретный бренд. Она показывает, какой критерий должен стать gate и где разумно начинать поиск. «Высокий» означает вес в решении, а не обещание, что дорогая или большая модель автоматически победит. Приватность всегда проверяется отдельно по фактической конфигурации.

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

Как измерять качество без самообмана

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

Разбивайте результаты по сегментам: длина, язык, тип документа, наличие таблиц, свежесть источника, сложность запроса. Общий score может расти, пока качество на самом важном сегменте падает. Сохраняйте примеры ошибок и превращайте их в regression set; это защищает от повторного появления уже понятной проблемы.

Публичные benchmarks полезны для короткого списка кандидатов и понимания методик. HELM специально показывает несколько аспектов, а long-context leaderboard отделяет паспортный размер входа от фактического результата. Но даже прозрачный benchmark не знает вашу терминологию, цену ошибки и формат приемки.

Скорость: смотрите распределение, а не удачный запрос

Измеряйте end-to-end время от пользовательского действия до готового проверяемого результата. Отдельно сохраняйте time to first token, полное время, число tool calls и retries. Медиана показывает типичный опыт, p95 — длинный хвост, который чаще ломает интерфейс и SLA. Один прогон из playground почти ничего не говорит о нагрузке.

На задержку влияют размер prompt, объём генерируемого текста, reasoning, retrieval, сеть и очереди поставщика. Сокращение лишнего контекста иногда полезнее смены модели. Streaming улучшает ощущение скорости, но не сокращает момент, когда весь структурированный результат можно валидировать и использовать.

Полная стоимость — это счёт за процесс

Соберите калькуляцию из фактически измеренных единиц: входные, выходные и cached tokens; embedding и storage; поиск и reranking; tool calls; повторные попытки; проваленные ответы; инфраструктура; наблюдаемость; человеческая проверка. Для self-hosted добавьте ускорители, резерв мощности, инженерное сопровождение и обновления. Не переносите цифры из чужого кейса.

Тарифы фиксируйте отдельным датированным снимком со ссылкой на официальную страницу. Некоторые продукты тарифицируют input и output по-разному, выделяют cache, batch или provisioned throughput. Сравнивайте стоимость одной принятой единицы результата, а не миллион абстрактных токенов: дешёвая генерация с частыми повторами может оказаться дороже.

Приватность: задайте поставщику восемь вопросов

• Какой именно продукт и endpoint получает данные: consumer chat, business workspace, API или third-party gateway?

• Используются ли input и output для обучения по умолчанию и при каких явных opt-in действиях?

• Что хранится, где, сколько времени и можно ли настроить либо отключить retention?

• Есть ли abuse monitoring, автоматическая или человеческая проверка и исключения для неё?

• В какой географии обрабатываются данные и что меняется у global deployment?

• Какие uploaded files, vector stores, histories, caches и backups живут дольше одного запроса?

• Кто внутри организации и у поставщика имеет доступ, как работают SSO, роли и audit log?

• Какие connectors и subprocessors получают данные за пределами основного model endpoint?

Фраза «данные не идут в обучение» отвечает только на один пункт. Anthropic, Google и OpenAI публикуют разные режимы хранения и commercial commitments. Читать нужно документ выбранного продукта в день решения. Если договор, data processing terms и настройки не закрывают ваш класс данных, техническое качество модели не имеет значения.

Hosted и self-hosted: у каждого варианта свой долг

Hosted API переносит значительную часть эксплуатации поставщику, но оставляет зависимость от условий, версий, квот и регионов. Self-hosted даёт больше контроля над размещением, однако требует проверить лицензию модели и данных, обновлять runtime, защищать endpoint, ограничивать логи и рассчитывать мощность. Open weights не означают отсутствие условий использования.

Изучите model card: intended use, ограничения, языки, данные, evaluation и license. Затем проверьте собственные случаи. Если карточка молчит о важном сегменте, это не доказательство плохого качества, но явная неопределённость. Она должна попасть в решение и план теста, а не исчезнуть за популярностью репозитория.

Практический следующий шаг: одностраничный протокол выбора

Создайте таблицу с кандидатами и четырьмя разделами: качество, скорость, стоимость, данные. Вверху перечислите hard gates. Рядом приложите hash eval-набора, конфигурацию запуска, датированный тариф и ссылки на privacy terms. Для каждого проигрыша сохраните пример, а не только балл. Выберите минимальную систему, прошедшую все обязательные условия.

Назначьте дату пересмотра и события вне графика: новая версия модели, изменение цены или terms, другой retrieval, новый тип документа, заметный drift ошибок. Повторный запуск той же процедуры важнее верности первоначальному выбору. Модель — заменяемый компонент процесса, а не ставка на бренд.

До решения проведите blind review части ответов: проверяющий не должен знать название кандидата. Это снижает влияние бренда, цены и ожиданий на субъективную рубрику. После раскрытия сопоставьте оценки с latency, стоимостью и инцидентами. Если два кандидата статистически неразличимы на малом наборе, не объявляйте победителя — расширьте наиболее важный сегмент.

Заранее опишите fallback: меньшая модель, предыдущая версия, детерминированный parser или ручная очередь. Проверьте rate limit, timeout, malformed output и недоступность поставщика. Кандидат, который превосходен в лаборатории, но не имеет безопасного восстановления, не готов к критичному процессу. Эксплуатационная устойчивость входит в качество системы.

Что читать дальше

• разобрать природу уверенных ошибок

• классифицировать рабочие документы до теста

• проверить экономию времени на собственном процессе

• сравнить SaaS и open source по полной стоимости владения