Метод6 мин чтения
Модель нельзя выбирать по таблице бенчмарков
Это разбор для тех, кто выбирает ИИ-модели под разработку, агентные задачи и внутренние процессы команды. Главное здесь - не угадать лидера недели, а собрать проверку, которая покажет реальную цену, качество и границы модели до того, как она попадёт в рабочий контур.
Бенчмарк показывает сигнал, но не результат в вашей работе
Gemini 4 Argon выглядит сильно в опубликованных проверках работы с информацией, финансовыми и юридическими агентными задачами. В VAULT модель получила 68,9%, а в юридическом тесте Harvey - 19,6%. Но в программировании картина неровная: 55% в Frontier Suite и 57,4% в Terminal Bench 4.0. Это не повод объявлять модель слабой. Это повод не переносить один хороший результат на все виды работы.
Пока Gemini 4 Argon не открыта для общего доступа. Её тестирует ограниченная группа доверенных специалистов по кибербезопасности, а расширение доступа обещано постепенно. Значит, сравнивать её с моделями, которые команда уже может прогнать на своих задачах, преждевременно.
Бенчмарк отвечает на вопрос «что модель смогла», а рабочий тест - «можно ли ей доверить процесс».
Выгода простая: команда не тратит недели на внедрение модели, которая красиво выглядит в отчёте, но срывается на вашем репозитории, документах или цепочке действий агента. Меньше ложных ожиданий, переделок и расходов на эксперименты ради экспериментов.
Рабочая валидация должна быть отдельным этапом выбора. Возьмите 5-10 задач, которые уже встречаются в работе: поиск ошибки, реализация небольшой функции, разбор документа, подготовка плана, работа в интерфейсе. Для каждой заранее зафиксируйте ожидаемый результат и условия доступа к данным. Не заменяйте этот набор абстрактными вопросами из интернета.
Цена модели складывается из настроек и поведения агента
Sonnet 5.5 заявлена как модель на 30% быстрее и на 30% дешевле Sonnet 5. При этом в одном бенчмарке она потратила больше токенов, а стоимость задачи составила 7,60 доллара. Это почти уровень более мощных альтернатив, на 27% дороже Opus 5.5 и более чем в 2 раза дороже GPT-6 Astra в том же сравнении.
Причина не в том, что заявления о снижении цены обязательно неверны. Сравнение зависит от типа задач и режима запуска. Тест с максимальными настройками вывода оказался дорогим. Снижение настройки до «очень высокой» сокращало расход примерно на 2/3.
Вот на чём часто обжигаются: смотрят цену за токен, выбирают «экономную» модель, а потом агент начинает дольше рассуждать, делает лишние ходы и съедает бюджет. Или наоборот, слишком сильно ограничивают вывод, получают плохой результат и добавляют ручную проверку. Формально дешёвый запуск становится дорогим процессом.
Вывод
стоимость нельзя оценивать по прайсу или рекламному проценту. Нужен замер на одинаковых задачах, с одинаковыми инструментами и настройками.
Разделение ролей приносит больше пользы, чем поиск одной идеальной модели
Sonnet 5.5 показывает сильные результаты в реализации и поиске ошибок. В Terminal Bench 4.0 у неё 70,6%, выше результата Opus 5.5 в этом тесте. Но в неоднозначных продуктовых задачах, где надо понять цель, выбрать направление и собрать план, Sonnet 5.5 может уступать Opus 5.5 по стратегичности.
Из этого следует практичный принцип: не заставляйте одну модель быть одновременно аналитиком, архитектором, исполнителем и ревьюером. Для планирования можно назначить одну модель, для реализации - другую, а для проверки - отдельный прогон. Это снижает вероятность, что одна неверная трактовка задачи пройдёт весь путь без контроля.
Такой контур особенно полезен в небольшой команде: решение становится проверяемым, а не завязанным на уверенность одного человека или одного агента. Но он не нужен для каждой мелочи. Простую правку, краткий поиск или черновик быстрее выполнить одним запуском. Делить роли стоит там, где ошибка дорого стоит или задачу трудно откатить.
Интерфейс и доступ к данным меняют ценность модели
Сильная базовая модель не спасает продукт, если пользователь не может дать ей нужные данные и инструменты. В отзывах о Dots повторяется претензия именно к ограничениям интерфейса и доступа. Одновременно Muse быстро набрал 3 млн еженедельно активных и 1 млн ежедневно активных пользователей за чуть больше чем 3 недели, хотя пользователи отмечали ошибки модели.
Это важный сигнал для внутренних инструментов. Команда может долго сравнивать качество ответов, но проиграть на самом скучном участке: агент не видит нужный контекст, не умеет передать результат в следующий шаг или заставляет человека вручную копировать данные между окнами.
DoorDash показывает другой аспект. Компания развивает собственного агента для заказов по SMS и сохраняет путь для внешних персональных агентов. В заказах продуктов через агентов средняя стоимость корзины, по заявлению компании, выше на 50%. Но стратегия не сводится к одному каналу: платформе важно сохранить отношения с пользователем, а пользователю - не оказаться запертым в одном посреднике.
Для команды это означает следующее: при выборе ИИ-инструмента проверяйте не только качество ответа, но и путь данных. Какие источники агент видит? Что он может сделать после ответа? Где остаётся журнал действий? Кто подтверждает рискованное действие? Если нужен единый интерфейс для процессов и контроля доступа, его можно собрать в ATLAS PANEL.
Безопасность начинается с границ задачи, а не с обещаний поставщика
Государственный портал America.gov пока работает как поиск ответов по 29 000 официальных сайтов. В будущем он должен принимать чувствительные данные и заполнять формы в разных ведомствах. При тестировании бот отказывался принимать фрагменты, похожие на адреса или пароли, пока их не удалят. Это полезная защита, но она не снимает вопроса о том, какие данные вообще стоит отправлять агенту.
То же касается корпоративных процессов. Не передавайте модели весь доступ «на всякий случай». Разделяйте поиск, подготовку черновика, отправку и оплату. Агент может предлагать действие, но необратимые шаги должны требовать понятного подтверждения человека. Внешние аудиты и добровольные механизмы контроля полезны, однако сами по себе не заменяют ваши правила доступа.
Первый шаг на сегодня
- Выберите 5 реальных задач, на которых команда сравнит модели.
- Для каждой задачи запишите качество результата, число попыток, токены и время человека на проверку.
- Разделите задачи на планирование, выполнение и проверку, не назначая одну модель на всё.
- Ограничьте доступ агента минимальным набором данных и действий для первого пилота.