Gemini 4 Argon: модель выбирают под процесс, а не под ответ

Google показала Gemini 4 Argon - новую frontier-модель с акцентом на программирование, сложные многошаговые задачи, корпоративные процессы и cybersecurity. Доступ пока ограничен группой проверенных специалистов по кибербезопасности: по заявлению компании, сначала модель проверяют на потенциально опасные сценарии. Отдельно подчёркнут сильно увеличенный контекст и ставка на длинные автономные задачи.

Конкретных цифр по размеру контекста и дат общедоступного релиза в анонсе нет, и додумывать их я не буду. Интереснее другое: формулировка повода. Про модель говорят не словами «отвечает точнее», а словами «выполняет длинные задачи». Это смена единицы работы, и она меняет то, как собственнику и техническому директору стоит выбирать модель.

Что меняется, когда единицей работы становится процесс

Пока ИИ отвечал на вопрос, вся оценка сводилась к качеству ответа. Ответ видно целиком, он короткий, его легко перечитать и забраковать. Человек оставался исполнителем: модель подсказала, человек сделал.

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

Отсюда простая мысль, которую я повторяю клиентам: вопрос «какая модель умнее» постепенно отходит на второй план. На первый выходят два других - что именно мы даём модели выполнять и как мы это контролируем. Первый вопрос про границы полномочий, второй про наблюдаемость. Про то, с чего вообще начинать разговор об агентных системах, у меня есть отдельный разбор: агентный ИИ и первые вопросы для руководителя.

Длинный контекст даёт возможность и выставляет счёт

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

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

Счёт тоже реальный, и он из трёх частей.

• Порядок в данных. Если в окно поедет корпоративный хаос, модель получит хаос с большей детализацией. Противоречивые версии регламента, устаревшие справочники и три источника правды по одной цифре никуда не денутся от того, что их стало можно загрузить разом.
• Права доступа. Чем больше кладём в контекст, тем выше шанс, что туда попадёт то, что этому пользователю видеть не положено. Модель не проверяет права, она работает с тем, что ей дали. Контроль доступа остаётся задачей слоя, который собирает контекст, и это обычный зрелый доступ к данным, а не магия внутри модели.
• Деньги и время. Длинный контекст стоит токенов и секунд на каждом шаге. В процессе из тридцати шагов это умножается на тридцать.

Про то, почему большое окно само по себе не отменяет нормальный поиск и подготовку данных, я писал подробно: длинный контекст и практические пределы.

Автономность требует контрольных точек и журнала

Длинная автономная задача - это система, которая какое-то время действует без человека. У такой системы должны быть две вещи, которые в демо обычно не показывают.

Первая - контрольные точки. Заранее определённые места, где процесс останавливается и ждёт человека. Разумный принцип: автономия заканчивается там, где начинается необратимое действие. Прочитать, сопоставить, подготовить черновик, собрать расчёт - пусть делает сама. Отправить клиенту, списать деньги, изменить запись в учётной системе, выкатить изменение в прод - здесь нужна подпись человека. Границу стоит провести явно и записать, а не оставлять на усмотрение промпта.

Вторая - журнал действий. Здесь нужен не лог ответов модели, а запись того, что она делала: какие инструменты вызывала, с какими аргументами, что получила, что изменила. Когда такой записи нет, разбор инцидента превращается в гадание, а вопрос «почему система это сделала» остаётся без ответа. По сути это та же дисциплина, что и в обычных системах, где история событий становится источником правды: журнал событий как источник правды.

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

Ограниченный доступ как сигнал, а не как маркетинг

Самая содержательная деталь анонса - то, что модель сначала отдали ограниченной группе специалистов по кибербезопасности, чтобы проверить опасные сценарии. Это можно прочитать как пиар, но я читаю иначе.

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

Для вас отсюда следует практический вывод. Если вендор модели считает нужным проверять свою систему на злоупотребление до выката, то и вам стоит проверять свой агентный процесс до того, как подключить его к боевым системам. Та же логика: сначала изолированная среда и попытки сломать, потом доступ к реальным данным и реальным действиям.

Вопросы, которые стоит задать до пилота

Это те вопросы, которые я задаю на первой встрече, когда в компании собираются поставить агентный процесс. Они не про модель, они про то, что вокруг неё.

1. Какой именно процесс мы отдаём и где он заканчивается? Один процесс с понятным входом и понятным выходом. Формулировка «поможет с документооборотом» для пилота не годится.
2. Какие действия необратимы и кто их подписывает? Список необратимых действий стоит составить руками до старта. Он обычно короче, чем кажется, и именно он задаёт границу автономии.
3. Что попадает в контекст и по каким правам? Какие источники, кто имеет право видеть эти данные, что делаем с персональными данными и коммерческой тайной. Ответ «подключим всё, что есть» означает, что права доступа никто не продумал.
4. Где лежит журнал действий и кто его читает? Журнал, который никто не читает, существует только для отчёта. Нужен человек и повод смотреть в него регулярно.
5. Как выглядит остановка? Кнопка, роль, процедура. Если остановить процесс можно только через разработчика в рабочее время, у вас нет остановки.
6. По какой метрике мы считаем пилот удавшимся? Доля задач, доведённых до конца без вмешательства, частота вмешательств, стоимость одного прохода, время от запуска до результата. Цифры стоит зафиксировать до старта, иначе итог будет оцениваться впечатлением.
7. Что мы делаем, когда поставщик меняет модель под нами? Версионирование, фиксация поведения, набор тестовых прогонов, которые надо повторять. Это часть обычной оценки поставщика: как оценивать ИИ-поставщика при закупке.

Честные оговорки

• Про Argon известно мало. Цифр по контексту, бенчмарков и дат широкого доступа в анонсе нет. Всё, что я написал выше, - разбор направления, в котором движутся поставщики, а не оценка конкретной модели. Оценивать её можно будет, когда появится доступ и воспроизводимые замеры.
• Смена модели не чинит процесс. Если процесс плохо описан, данные противоречивы, а права доступа не разобраны, более сильная модель сделает то же самое быстрее и увереннее. Порядок в данных и регламенте дешевле делать до пилота, чем после.
• Автономность нужна не везде. Во многих задачах разумный предел - черновик, который проверяет человек. Это уже даёт экономию и не требует выстраивать контур контроля под необратимые действия. Полная автономия имеет смысл там, где объём операций делает ручную проверку узким местом.
• Контур контроля стоит денег. Журнал, контрольные точки, тестовые прогоны, песочница - это работа, которую надо заложить в бюджет пилота. Пилот, где этих статей нет, выглядит дешевле ровно до первого инцидента. Про разрыв между демо и платформой я писал отдельно: агентные системы из демо в платформу.

Если коротко

• Анонс Gemini 4 Argon интересен формулировкой: акцент на длинные автономные задачи и работу с инструментами, а не на качество отдельного ответа.
• Когда единицей работы становится процесс, выбор модели перестаёт быть выбором по уму и становится выбором по тому, что ей можно поручить и как это проверять.
• Большой контекст даёт загрузить корпоративную фактуру, но требует порядка в данных, разобранных прав доступа и бюджета на токены.
• Автономность нужно обвязывать контрольными точками на необратимых действиях, журналом действий и живым владельцем процесса.
• Ограниченный ранний доступ и проверка на опасные сценарии - сигнал, который стоит повторить у себя: сначала песочница и попытки сломать, потом боевые системы.

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