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

Обещание на той стороне этой стены - агент, который делает долгую работу сам, всю ночь если надо, и оставляет человеку валидацию последних 10%. Сбывается это обещание или нет - упирается в проблему, которую разговоры об оркестрации обычно пропускают. Когда компания Chroma протестировала 18 ведущих моделей, каждая теряла точность по мере роста входных данных. Это свойство того, как работает внимание, а не дыра, которую закрывает более сильная модель. Агент, которому скормили больше данных, не становится устойчивее. Он становится шатче.

Это слой под гонкой оркестрации. Маршрутизация, durable execution и наблюдаемость - всё это предполагает, что каждый агент уже достаточно компетентен, чтобы координироваться. Глубинный вопрос в другом: как долго агент может работать, пока человеку не придётся вмешаться? И ответ упирается в то, где относительно модели живут знания вашей компании. Оба стандартных фикса оставляют человека в цикле.

Почему обучение модели вашим данным не даёт автономии

У enterprise-команд есть два способа поместить знания внутрь модели. Первый - fine-tuning, который запекает знания в веса. Он страдает от катастрофического забывания - проблемы, известной с 1980-х и до сих пор не решённой: когда модель учится новому, она теряет то, что уже знала. Команды обходят это изоляцией каждой задачи в своей fine-tuned-модели или адаптере - и получают зоопарк моделей, который растёт стоимостью и головной болью governance. А fine-tuned-модель это снимок: он устаревает в день, когда меняется политика, и начинается дорогой, медленный цикл переобучения.

Второй способ - in-context learning, который пропускает переобучение и помещает политики в промпт на каждом запуске. Здесь кусает гниение контекста. Retrieval сужает то, что попадает в промпт, но промах retrieval выглядит так же уверенно, как точный ответ, а стоимость и задержка растут с каждым добавленным токеном.

Две проблемы рифмуются. С fine-tuning модель может уверенно работать по политике прошлого квартала. С in-context learning она может уверенно работать по детали, которую потеряла в середине длинного промпта. Вывод в обоих случаях выглядит одинаково убедительно, и вы не можете сказать, какие части неправильны, не проверив их все. Поэтому человек никогда не уходит.

Третий путь: генерация модели под задачу на лету

Третий подход переходит из research в ранние продукты. Вместо переобучения одной модели или забивания её промпта, генератор строит маленькую специализированную модель прямо на лету, из ваших политик, прямо в момент инференса. Генератор - это hypernetwork: сеть, чей выход - веса другой сети.

Идею назвали в 2016 году. Применение для генерации специализированных языковых моделей из текста или документов - свежее и активное. Sakana AI анонсировала Text-to-LoRA на ICML 2025: адаптер модели генерируется с одного прохода по описанию на естественном языке. А система SHINE 2026 года называет hypernetwork-адаптацию «многообещающим новым фронтом» - именно потому, что она обходит и стоимость переобучения fine-tuning, и ограничения контекста промптов.

Сравнение трёх подходов

  • Fine-tuning: знания в весах. Дорого обновлять. Забывает старое. Зоопарк моделей.
  • In-context / RAG: знания в промпте. Дешево обновлять. Контекст гниёт, промахи retrieval незаметны.
  • Hypernetwork: знания в сгенерированных весах. Дешево обновить перегенерацией. Узкая модель без лишнего контекста.

Суть генерации адаптеров, а не их хранения и обучения, - в том, чтобы свернуть зоопарк per-task LoRA в одну сеть, которая производит их на лету, включая задачи, которых она не видела. Элегантная часть - как это замыкает проблему: per-task адаптер, который команды собирают вручную, чтобы обойти катастрофическое забывание, - это тот же объект, который hypernetwork производит автоматически. Зоопарк моделей перестаёт быть головной болью и становится сгенерированным выводом.

Аргумент за маленькие модели под капотом сформулировали исследователи Nvidia в 2025 году: для узких повторяющихся задач small models достаточно способны и в 10-30 раз дешевле frontier-обобщителей. Nace.AI, компания из Пало-Альто, собравшая 21,5 млн долларов seed-раунда в мае 2026 года, - самый понятный коммерческий пример. Её технология - генератор под названием MetaModel - производит адаптации параметров для модели на лету из политик компании. Система нацелена на регулируемую работу: аудит, комплаенс, оценку рисков. Компания говорит, что агенты обрабатывают основную массу рабочего процесса, а эксперты валидируют результат - сплит, который Nace маркетирует как 90/10.

Почему Hypernetwork поднимает потолок автономии

Модель, которая узка, актуальна и мала, имеет меньшую поверхность для ошибок. Меньше ошибок в известном домене означает меньше выводов, которые агенту нужно эскалировать человеку. Это и есть реальная основа для любого утверждения о высокой автономии. 90/10 - не заранее установленный регулятор, а результат того, насколько мало система отдаёт обратно.

Два дизайнерских решения определяют, заслуживает ли эта автономия доверия или это просто скорость. Первое - grounding: привязка каждого вывода к источнику, чтобы проверяющий мог верифицировать, а не переделывать. Исследовательские модели вроде HalluGuard маркируют каждое утверждение как подтверждённое или нет и цитируют фрагмент, на который опирались. Nace поставляет агентов с моделями grounding и трейсами рассуждений по той же причине. 10%-ная проверка имеет смысл только если человек за секунды может подтвердить источник.

Второе - петля обратной связи. Когда ваши эксперты валидируют вывод, чья модель улучшается - и где она живёт? Это определяет, кому принадлежит накапливающийся актив. Nace, например, использует внешнюю сеть сертифицированных экспертов для одних проектов и штат заказчика для прямых enterprise-внедрений - результирующая модель остаётся в облаке клиента. Каждый выбор направляет обучение и владение в разное место.

«Агент, работающий на гиперсети, - самая убедительная попытка заставить маленькую модель знать конкретный бизнес, не забывая его и не переобъясняя всё на каждом запуске. Но это и наименее доказанный подход»

- Ujas Patel, VentureBeat

Где третий путь буксует

Подход всё ещё ранний. Калибровка - ключевой шарнир: ценность rests на том, что модель знает, когда она не уверена. И это действительно нерешённый вопрос: недавние работы по генерации адаптеров показали, что они не улучшают калибровку автоматически по сравнению с обычным fine-tuning, улучшения появляются только при специфических ограничениях.

Качество сгенерированной модели сильно зависит от данных политик, из которых она строится, что налагает премиум на курацию данных. Масштаб - открытый research-фронтир: hyperсети, показанные в опубликованных работах, пока малы. Именно здесь работа Nace становится интересной: в интервью компания сказала, что масштабировала свой генератор далеко за опубликованные размеры и вывела scaling law для роста производительности. Если это подтвердится peer review, ответ на один из центральных открытых вопросов поля станет известен.

Так или иначе, работа всё равно кончается у человека. Когда Deloitte Australia сдала правительственный отчёт примерно на 440 тысяч долларов, в нём обнаружились вымышленные цитаты и придуманная цитата суда - хотя отчёт прошёл senior review. Проверяющие смотрели выводы (они были верны), но не источники (они были не верны). Исследования показывают, что паттерн общий: эксперты реже исправляли одинаково ошибочную рекомендацию, если знали, что её сгенерировал AI.

Статья 14 EU AI Act теперь прямо называет это automation bias. Урок не про конкретного вендора: высокая доля автономии концентрирует человеческое внимание в тонком позднем срезе работы, а ценность этой проверки целиком зависит от того, может ли человек быстро проверить источник - что возвращает нас к grounding.

Что строить - и о чём спрашивать перед покупкой

Честный вывод: ваши агенты упираются обычно не в оркестрацию или размер модели, а в то, знает ли модель ваш бизнес достаточно хорошо, чтобы её можно было оставить одну. Правильный фикс зависит от задачи. Чтобы автоматизировать длинный повторяющийся высокообъёмный процесс end-to-end - запустить внутренний аудит на ночь и проверить финальный срез своими экспертами - hypernetwork-модель, скорее всего, сделает это дёшево и проработает достаточно долго, чтобы иметь смысл. Для короткой задачи на несколько шагов, которая и не должна работать без присмотра, разрыв между этим подходом и хорошо запромпченной frontier-моделью схлопывается почти до нуля.

Когда вендор продаёт автономных или специализированных агентов, четыре вопроса разрезают шумиху.

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

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