Две главные идеи, которые AI-индустрия почему-то забросила

История технологий — не всегда история прогресса

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

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

Первая забытая идея: объекты должны жить

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

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

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

Мы не отменили ООП, но ослабили одно из его глубочайших свойств. Со временем мы придумали ORM, сессионные хранилища, event sourcing, шины сообщений, распределённые кеши, workflow-движки — горы связующего кода. Все эти технологии решают реальные проблемы масштаба и распределённости. Но вместе они показывают: сохраняемость перестала быть естественным свойством вычислительного объекта и превратилась в инженерную задачу вокруг него.

Для enterprise AI это критично. Системе, действующей от лица компании, нужен не просто доступ к документам и API. Ей нужны долгоживущие сущности, чья идентичность, состояния, связи, разрешения и допустимые переходы остаются согласованными во времени. Клиент должен быть одним и тем же от взаимодействия к взаимодействию. Процесс обязан переживать сбои. Контракт должен нести свои ограничения.

Сегодняшние системы называют это «памятью». Но память — не объектная модель. Память может восстановить фрагменты прошлого. Объектная модель определяет, что существует и как может меняться. Например, Anthropic представила способность Claude помнить диалоги недельной или месячной давности как важное достижение. Для чат-бота это так. Но с точки зрения enterprise-ПО эта веха звучит странно скромно. Клиент, контракт, страховое требование или девятимесячный процесс продаж не должны быть согласованными месяц — они должны быть согласованными всё время своего существования.

Вторая забытая идея: обучение на последствиях

Другая вытесненная идея — обучение с подкреплением (reinforcement learning). AlphaGo от DeepMind сочетал глубокие нейросети с RL и победил одного из сильнейших игроков в го. AlphaZero пошёл дальше: научился играть в шахматы, сёги и го через самоигру, без копирования партий человека. MuZero научился планировать, не зная заранее правил среды.

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

Но появился трансформер. Статья 2017 года «Attention Is All You Need» представила архитектуру, которая легко параллелится и отлично обрабатывает последовательности. Она стала основой генеративного AI и преобразила NLP. И это не было ошибкой — трансформеры стали одним из важнейших достижений в вычислительной технике. Проблема в том, что сместился центр тяжести индустрии.

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

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

Почему эти две потери усиливают друг друга

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

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

Уберите первое — компанию трудно представить. Уберите второе — компанию невозможно непрерывно оптимизировать. Это объясняет, почему так много enterprise AI до сих пор похожи на умный интерфейс, сидящий поверх отсутствующей среды исполнения. Система может красиво говорить об организации, но не может полноценно обитать в ней устойчиво, с сохранением состояния и ориентацией на результат.

Это же объясняет, почему внедрения остаются штучными. Людям приходится восстанавливать контекст, соединять системы, определять разрешения, описывать бизнес-объекты, измерять результаты и заново выстраивать цикл для каждого кейса. Модель даёт интеллект, но архитектура, нужная, чтобы превратить интеллект в накапливаемый организационный потенциал, собирается вручную. Результат — индустрия, блестящая в демонстрациях и странно бедная в накоплении.

Архитектура, которая нужна сейчас

Следующая enterprise AI-архитектура должна будет восстановить обе идеи одновременно. Ей понадобятся объекты, чья идентичность, состояние, связи, разрешения и поведение сохраняются естественным образом — даже когда выполнение перемещается между машинами и масштабируется от десяти до десяти миллионов взаимодействий.

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

Только соединив долговременную объектную модель и постоянное обучение на последствиях, enterprise AI сможет перестать быть дорогим генератором текста и стать настоящей операционной системой для бизнеса.