Умной модели недостаточно: что ICML 2026 напомнил мне о настоящих ИИ‑системах

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

Почему конференционные идеи упираются в реальный мир

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

Один из пленарных докладов был посвящён визуально‑языковым моделям — vision‑language models, VLM — роботам и моделям мира. Роботов уже научили довольно хорошо воспринимать команды и выполнять отдельные действия. Но между красивой демонстрацией и устойчивой работой в физическом мире остаётся огромный разрыв. Ошибка на одном шаге меняет состояние среды, следующая команда строится уже на неверной картине, и через несколько итераций вся последовательность разваливается.

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

Другой пленарный доклад был посвящён вопросу: что останется человеку по мере развития и распространения искусственного интеллекта. Одной из важных для меня мыслей стало то, что мы часто ошибочно представляем развитие ИИ как одну лестницу: от узкого интеллекта к общему искусственному интеллекту, затем к похожему на человека и, наконец, к сверхинтеллекту.

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

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

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

ИИ не отменил эту закономерность. Наоборот, сделал её заметнее.

Я вижу это и в работе Statanly Technologies, где мы соединяем исследования с внедрением прикладных ИИ‑систем: от промышленного компьютерного зрения и видеоаналитики до RAG, речевых интерфейсов и прогнозных моделей. Сценарии могут быть совершенно разными, но архитектурный вопрос почти всегда один: что должно произойти после того, как модель выдала результат?

Модель видит дефект. Что происходит дальше

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

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

Но довольно быстро стало понятно: сама по себе точность модели ещё ничего не гарантирует.

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

Пока на эти вопросы нет ответов, модель остаётся дорогим наблюдателем. Бизнес‑ценность появляется только тогда, когда результат распознавания становится частью производственного процесса. Сигнал должен превратиться в событие, а событие — в понятное действие.

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

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

Иногда модель работает, а проект — нет

В другом проекте мы устанавливали камеры на горно‑обогатительном предприятии. По конвейеру двигалась руда, которая затем попадала в дробилку. Нужно было измерять распределение размеров кусков до и после дробления, замечать инородные объекты и собирать аналитику о качестве процесса.

Первоначальная идея выглядела логично: анализировать входную фракцию и в зависимости от неё регулировать режим работы оборудования.

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

Оператору результаты не были особенно нужны. Регулировка оборудования оказалась гораздо менее автоматизированной, чем предполагалось. А вскоре участок должен был уйти на ремонт с разборкой конвейеров и дробилки — вместе со всей тщательно откалиброванной системой наблюдения.

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

Если модель выдаёт информацию, на которую никто не обязан реагировать, это ещё не автоматизация. И тем более не ИИ‑трансформация, о которой сейчас любят говорить.

Был и совсем небольшой, но показательный проект на птицефабрике. Цыплята быстро двигались по конвейеру, а заказчик хотел считать их с помощью камеры. Качество видео было ограниченным: каждый объект появлялся всего в нескольких кадрах, иногда несколько цыплят двигались вплотную друг к другу, а при остановке конвейера продолжали перемещаться на месте. Алгоритм мог многократно посчитать одного и того же цыплёнка или пропустить слипшихся.

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

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

ИИ конкурирует не с отсутствием решения, а с решениями другой природы: реле, датчиком, SQL‑запросом, регламентом, формой в интерфейсе или обычным алгоритмом. И побеждает далеко не всегда.

Самое сложное — договориться, что считать правильным

В генеративном ИИ эта проблема проявляется немного иначе.

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

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

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

Самым сложным стал вопрос не о качестве модели, а о том, что считать правильным ответом. Кто является владельцем знания? Какая версия позиции считается актуальной? Как она утверждается? Как изменения версионируются? Что делать, если пользовательский вопрос допускает несколько интерпретаций?

Это уже не столько задача машинного обучения, сколько управление знаниями и требованиями.

Ограничения не мешают ИИ — они делают его полезным

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

Юристам нужно было находить похожие дела по содержанию и одновременно учитывать структурированные параметры: категорию спора, регион, адвоката, даты и другие признаки.

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

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

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

Сегодня такой подход называют scaffolding, guardrails или workflow — каркасом, ограничителями и фиксированным маршрутом работы системы. По сути, мы построили конечный автомат с тщательно выверенной схемой взаимодействия. Тогда мы называли это просто хорошей инженерной практикой.

Именно ограничения сделали систему полезной. Пользователь получал естественный интерфейс на человеческом языке, но внутри запрос проходил по контролируемому маршруту. Модель не могла произвольно менять порядок действий или подменять достоверный поиск красивой генерацией.

Лучшим подтверждением успеха стала не демонстрация и не презентация результатов пилота. Примерно через год заказчик вернулся с бюджетом на развитие решения.

Теперь на основе того же архитектурного подхода строится более широкая ИИ‑платформа: сервисы для работы с юридическими архивами, помощники для внутренних подразделений, инструменты для HR и финансовой аналитики. Естественный язык используется как интерфейс, но критические операции выполняются через строго определённые хранимые процедуры, разрешённые SQL‑запросы и контролируемые источники данных.

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

От детектора касок к платформе событий

Ещё нагляднее этот переход виден в проектах промышленной безопасности. Со временем из нескольких таких проектов в Statanly выросла платформа событийной видеоаналитики.

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

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

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

Со стороны всё это можно описать как набор детекторов. Но набор детекторов ещё не платформа.

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

Сегодня источником события может быть модель компьютерного зрения. Завтра — аудиоаналитика, датчик, временной ряд или мультимодальная модель. Конкретные нейросети будут заменяться. Архитектура событий и действий останется.

Именно она позволяет системе масштабироваться.

Пять вопросов перед запуском ИИ‑проекта

Перед тем как выбирать модель или заказывать пилот, полезно ответить на пять вопросов.

Какое решение должно измениться? Не «что модель должна распознать», а какое производственное, управленческое или клиентское действие станет другим.

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

Как проверяется результат? Нужно определить допустимую ошибку, источники подтверждения и случаи, когда решение передаётся человеку.

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

Нужен ли здесь ИИ? Иногда датчик, SQL‑запрос, правило или изменение процесса решают задачу точнее, дешевле и надёжнее.

ИИ возвращается к системной инженерии

После ICML у меня не осталось ощущения, что главная проблема ближайших лет — недостаточно умные модели. Они продолжат улучшаться, и довольно быстро.

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

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

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

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

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

Сначала стоит спросить другое. Какое решение должно измениться благодаря системе? Кто отвечает за это решение? Как проверяется результат? Что произойдёт, если модель ошибётся? Можно ли восстановить её действия? И есть ли у организации процесс, способный использовать полученный сигнал?

Модель производит результат. Система определяет, можно ли ему доверять, превращает его в событие, выбирает допустимое действие и фиксирует ответственность.

И, возможно, главный переход, который происходит сейчас в прикладном искусственном интеллекте, — это не переход от одной версии модели к другой. Это переход от экспериментов с моделями к нормальной системной инженерии вокруг них.