Как выбрать и проверить LLM под рабочие задачи бизнеса: пошаговый разбор

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

1. Опишите задачу через вход и выход. Одна повторяющаяся операция, сформулированная одной фразой: «на входе письмо клиента с вопросом по цене, на выходе ответ из четырёх блоков: приветствие, цена, срок, следующий шаг». Результат: сотрудник, который делает эту работу руками, пересказывает формулировку своими словами. Не совпало — переписывайте задачу, а не тестируйте модели.
2. Зафиксируйте условия приёмки до первого запуска: чек-лист на 5–10 пунктов с ответом «да» или «нет» — структура, длина, обязательные пункты, отсутствие выдуманных цифр и цен, рабочий тон. Отдельным пунктом — сколько ручной доработки допустимо, в минутах на единицу результата. Результат: по чек-листу два разных сотрудника придут к одному выводу.
3. Соберите 20–50 обезличенных кейсов из своей практики: реальные письма, заявки, брифы, выгрузки. Удалите имена, контакты, суммы клиентов, всё, что позволяет опознать человека или компанию. Результат: папка однотипно оформленных входов, которые можно прогнать через любую модель без юридических рисков.
4. Отберите 3–4 модели-кандидата по публичным бенчмаркам. Это единственная роль рейтингов: помочь составить список, а не ответить, что нужно вам. Смотрите не на общее место, а на категорию, ближайшую к вашей задаче. Результат: короткий список с одной строкой обоснования на каждую модель.
5. Проверьте требования, которых в бенчмарке нет: доступность и способы оплаты из России, наличие API, лимиты запросов, длина контекста, регион хранения данных, что придётся оформлять по 152-ФЗ. Результат: таблица «модель — доступна или нет — стоимость запроса — ограничения». Модель, не прошедшая по доступности или по данным, дальше не тестируется.
6. Прогоните один и тот же набор кейсов через всех кандидатов на одинаковых промптах и настройках. Иначе вы сравниваете свои правки по ходу дела, а не модели. Результат: полная матрица результатов, а не воспоминание «мне понравилось».
7. Оценивайте по бинарной шкале: по каждому пункту чек-листа — «прошло» или «не прошло». Итоговый балл модели — доля прошедших кейсов. Результат: у каждой модели есть число, которое можно сравнить с числом конкурента.
8. Считайте не только цену токенов, но и время проверки: стоимость прогона плюс минуты правок, умноженные на стоимость часа сотрудника, который их делает. Результат: рублёвая цифра на одну единицу результата у каждой модели. По ней и сравнивайте.
9. Добавьте «сложную двадцатку»: длинные письма, сленг, опечатки, цифры из прайса, смешанные языки, вопросы не по теме. Результат: видно, где модель ломается стабильно и лечится ли это промптом или такой случай надо оставлять человеку.
10. Проверьте устойчивость: прогоните 5–10 кейсов по три раза подряд. Модель, которая на одном и том же входе выдаёт разное качество, в поток не ставится. Результат: посчитано, сколько кейсов дали отличающийся результат между запусками.
11. Выберите основную и запасную модель и зафиксируйте версию: название модели, версия, дата теста, балл по чек-листу. Результат: документ, по которому через месяц понятно, что именно вы тестировали.
12. Встройте модель в процесс с человеком на приёмке и замерьте до и после. Первое время каждый результат проверяется, позже приёмку можно ослабить, но не отменять. Результат: часы на задачу до внедрения и после, посчитанные в одном и том же месте одним и тем же способом.
13. Перепроверяйте по расписанию: раз в месяц или при смене версии. Тот же набор кейсов, тот же чек-лист, та же таблица. Результат: таблица тестов с датами, по которой видно, когда качество просело.

Публичные рейтинги не отвечают на главный вопрос: подходит ли модель вашей задаче. В статье на Habr «Как выбрать и проверить LLM для рабочих задач: Claude, GPT, Gemini и другие модели» руководитель проектов по автоматизации бизнеса Игорь Зуриев описывает такой же порядок работы: бенчмарки отбирают кандидатов, а решение принимается на своей задаче и своих условиях приёмки. Он также приводит личный опыт с Fable 5.1, Stitch и Sonnet 5. Названия в рейтинге сами по себе ничего не решают — решает результат на конкретном входе и время, которое уходит на правки после него.

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

Как считать выгоду. Сравнивайте не модели между собой, а два состояния одного процесса: как было руками и как стало с моделью и человеком на приёмке. Если сотрудник тратил 40 минут на документ, а теперь тратит 12 минут на проверку и правки, экономия выражается в часах, которые считаются в деньгах по его ставке. Модель, дешевле по токенам, но требующая вдвое больше правок, окажется дороже. Третий счёт — конверсия: быстрый ответ на заявку часто важнее копеечной разницы в цене прогона, но этот эффект нужно мерить отдельно, а не приписывать его модели.