Самый мощный ИИ нужен не каждой задаче: как выбрать модель без гонки за названием
Вы просите нейросеть разобрать обращения покупателей. Для сообщения «Где мой заказ?» нужен один из трёх ярлыков: доставка, возврат или другое. Следом вы поручаете ей разобраться, почему в приложении иногда пропадают платежи. Обе задачи выглядят как текстовый запрос. Но цена ошибки, объём рассуждений и способ проверки у них разные.
Поэтому вопрос «какая модель лучше?» полезно заменить вопросом «какой результат мне нужен и как я пойму, что он получился?». Ниже — небольшой способ сравнения для своей работы. Это методическая памятка, а не результаты нашего теста моделей.
Повод: небольшие модели становятся отдельным рабочим инструментом
7 октября Anthropic представила Claude Haiku 5.5. Компания ориентирует её на короткие повторяющиеся задачи: сводки, классификацию, запросы к данным, работу помощником более крупной модели. Для сложных многошаговых задач программирования в том же анонсе она рекомендует Sonnet 5.5 и Opus 5.5.
Это позиционирование производителя, а не независимое доказательство, что Haiku подойдёт вашей компании. Оно показывает полезное различие: модель можно выбирать под этап работы, а не назначать одну самую дорогую на всё подряд.
Сначала опишите приемлемый результат
Возьмём вымышленный магазин. Ему нужно распределять сообщения по отделам. Пример правильного ответа — один ярлык из заранее заданного списка. Модель не должна придумывать статус заказа, обещать возврат или писать покупателю.
Такую задачу сравнительно легко проверять: известен допустимый формат, можно вручную разметить примеры и посмотреть, где ответы расходятся с ними. Но стоит добавить «самостоятельно решай, кому вернуть деньги» — и задача резко меняется. Даже идеальное попадание в ярлык не доказывает готовность принимать финансовые решения.
Запишите до сравнения четыре вещи: входные данные, нужный результат, недопустимые ошибки и действия, которые модель выполнять не должна. Это защищает от ситуации, когда красивый ответ принимают за правильно выполненную работу.
Соберите небольшой набор собственных примеров
Для первого отбора можно взять, например, 20–30 обезличенных сообщений: обычные обращения, сообщения с двумя вопросами, опечатки, недостаток информации. Это удобный старт, а не статистическое доказательство надёжности.
Добавьте случай «Я хочу вернуть товар, но сначала уточните, когда приедет другой заказ». Правильный ярлык здесь зависит от правила вашего магазина. Если этого правила нет, сравнение измеряет ещё и неоднозначность задания. Сначала решите, как обрабатывать такие случаи: несколько ярлыков, уточнение или передача человеку.
У технических задач проверка будет другой. Для исправления программы важен работающий результат и проверки поведения; объяснение агента «всё исправлено» само по себе не подтверждение. Anthropic в руководстве по оценке агентов отдельно разбирает задачи, попытки, критерии проверки и итоговое состояние среды.
Сравнивайте одинаковые условия
Дайте двум моделям одно задание, одни данные и одинаковые разрешённые инструменты. Сохраните ответы. Считайте не только очевидные ошибки, но и ответы в неправильном формате, лишние выдуманные детали и случаи, где человек вынужден всё пересматривать.
Для нестабильных или важных случаев повторите запуск: одна удачная попытка ещё не показывает, что задача решается надёжно. Маленький набор не охватит все будущие обращения, поэтому после внедрения нужен отдельный список новых ошибок. Добавляйте их в проверку перед сменой модели или инструкции.
«Дешевле» считайте до готового результата
Для API полезно учитывать весь расход на задачу: вход, ответ, дополнительные вызовы, повторные попытки и ручную проверку. Токен — единица, которой сервис измеряет обработанный текст; число токенов не равно числу слов. Конкретные тарифы и правила кэширования зависят от сервиса и модели.
Модель с низким тарифом может оказаться неудобной, если ответы часто нужно переделывать. И наоборот: мощная система не обязательно приносит пользу на простом шаге с чёткими правилами. Подписка на готовое приложение и оплата API — разные условия; сравнивать их одним числом за токен тоже нельзя.
Не обязательно выбирать единственного победителя
У магазина может получиться такая схема: обычные обращения обрабатывает подходящая лёгкая модель, неоднозначные случаи уходят человеку или на дополнительную проверку. Самостоятельно возвращать деньги этот процесс вообще не умеет. Это пример устройства работы, а не обещание экономии и не готовая рекомендация для любого бизнеса.
Начните с одной повторяющейся задачи. Если более лёгкая модель выдерживает ваши критерии, её имеет смысл рассматривать. Если ошибки слишком дороги или результат невозможно проверить, усложнение контроля может быть важнее смены названия в меню.