【Yunqi: наблюдения】 Yunqi — это не ответ, а карта того, на что ставит ИИ-индустрия

Главное, что я вынес с Yunqi в этот раз, — не очередной список новых моделей и компаний, а изменившийся способ смотреть на выставки.

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

Оба взгляда — слишком поверхностны.

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

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

1. Сначала разложим «шум» выставки по уровням доказательности

В этот раз я сознательно стал раскладывать каждое технологическое направление на пять уровней:

Нарратив → Продукт → Продакшен → Бизнес → Выручка
(Narrative → Product → Production → Business → Revenue)

На самом верху расположен нарративный уровень (Narrative) — то, что вендоры хотят, чтобы рынок принял за чистую монету. Например: агенты (Agent) станут новой точкой входа в рабочие процессы, компаниям необходима AI-нативная (AI-native) архитектура, контекст (Context) превратится в ключевой актив, а мультиагентные системы возьмут на себя всё более сложные задачи. Эти утверждения важны — они показывают, куда движутся внимание и капитал организаций, — но всё же остаются лишь гипотезами и ставками.

Уровнем ниже — продуктовый слой (Product): то, что уже можно показать, к чему можно обратиться через API, что можно поставить в рабочий контур или платформу управления. Это сигнал о том, что направление вышло из стадии концепта и оформилось в продукт. Однако между «можно продемонстрировать» и «стабильно работает на длинной дистанции» по-прежнему зияет огромная пропасть.

Ещё ниже — производственный уровень (Production): продукт реально встроен в клиентские процессы, работает непрерывно и начинает сталкиваться с суровой действительностью — правами доступа, данными, аудитом, восстановлением, затратами, кросс-функциональным взаимодействием. Только тогда его можно считать вышедшим в продакшен.

Ниже располагается уровень «Бизнес» (Business) — и здесь нужно задать следующий вопрос: что изменилось после запуска? Сократились ли сроки выполнения заказов, выросла ли конверсия, снизились ли расходы на персонал, увеличился ли объём тестирования рекламных креативов — или же стала возможной та бизнес-процедура, которую раньше выполнить не удавалось?

Самый нижний — и самый приземлённый — уровень называется «Выручка» (Revenue): готов ли клиент платить в долгосрочной перспективе, за какой именно результат он готов платить и при каких условиях происходит продление подписки.

Ценность этой модели в том, что она не позволяет смешивать разные типы доказательств в одну кучу. Стенд на выставке подтверждает, что направление стоит показать; форум — что вендор хочет закрепить определённое восприятие; реальные кейсы клиентов повышают доверие к производственному и бизнес-уровням; а устойчивая выручка подтверждает уровень Revenue.

Поэтому сам по себе тот факт, что какое-то направление активно обсуждается на конференции, ещё не означает «пора инвестировать».

II. Самое заметное изменение: над моделями нарастает всё больше слоёв

В последние годы разговоры об ИИ крутились вокруг самой модели: размер параметров, результаты на бенчмарках (Benchmark), способности к рассуждению, цена, размер контекстного окна, качество изображений, возможности в работе с кодом.

В этот раз прямо на площадке я отчётливо почувствовал, что фокус смещается.

Модели по-прежнему важны, но системный слой вокруг них стал ощутимо толще. Фундамент данных, подключение моделей, управление токенами, среда выполнения агентов (Agent Runtime), песочницы (Sandbox), контекст (Context), память (Memory), навыки (Skill), управление браузером (Browser Use), управление компьютером (Computer Use), верификация (Verification), наблюдаемость (Observability), права доступа, аудит, контроль затрат — всё больше этих возможностей выделяется в отдельные продукты.

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

За день на выставке встречаешь пять-шесть продуктов с совершенно разными названиями, но все они сходятся к одной и той же архитектуре. QwenWork (агентская платформа Alibaba) демонстрирует, как агент в изолированной среде вызывает разные инструменты и выполняет задачи. Qoder (агентская IDE от ByteDance) говорит о контексте, спецификациях требований (Spec), тестовой обвязке (Harness), верификации (Verification), памяти и мультимодельной маршрутизации. Независимый вендор TinyFish показывает, как агент выходит в реальный веб и выполняет задачи уже там. WonderClip разбивает видеопроизводство на сценарий, раскадровку, материалы, генерацию, ревью, версионирование и пакетный выпуск. Agentic Search в Alibaba Cloud OpenSearch расширяет поиск за счёт планирования (Planning), рассуждений (Reasoning), памяти (Memory), действий (Action) и оценки (Evaluation).

На первый взгляд — совершенно разные области, но в основе лежит одна и та же архитектура:

Контекст → Планирование → Навыки → Исполнение → Верификация → Память → Бизнес-результат
（Context → Planning → Skill → Execution → Verification → Memory → Business Outcome）

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

III. Контекст превращается из «входных данных» в долгосрочный актив

На одном из слайдов с презентации Qoder (coding assistant от Alibaba) сказано прямо:

Model power is a commodity. Context is the asset.

В этом высказывании, разумеется, присутствует маркетинговый посыл, но за ним стоит реальная проблема: чем мощнее становятся модели и чем ниже стоимость доступа к ним, тем сильнее долгосрочная работоспособность интеллектуального агента (Agent) определяется тем, что именно он «знает».

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

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

Поэтому Qoder развивает Wiki репозитория (Repo Wiki), память (Memory) и карточки знаний (Knowledge Cards), QwenWork делает упор на корпоративный контекст (Enterprise Context), а OpenSearch акцентирует долгосрочную память, память задач и сжатие контекста. Все они пытаются решить одну и ту же задачу: позволить агенту не постигать окружающий мир каждый раз с чистого листа.

Это также означает, что долгосрочная ценность библиотек промптов (Prompt Library), которые многие команды так любят накапливать, вероятно, ниже, чем принято считать. Промпт (Prompt) — это скорее способ вызова отдельной задачи; реальный накопительный эффект дают бизнес-контекст, история решений, результаты валидации, причины сбоев и переиспользуемые навыки.

IV. Единица конкуренции ИИ-продуктов смещается от «отдельной функции» к «целостному рабочему процессу»

WonderClip произвёл на меня особенно яркое впечатление.

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

Но архитектура продукта, которую команда продемонстрировала на сцене, уже движется в сторону более целостной производственной системы:

Загрузить сценарий → Разобрать по элементам → Подготовить материалы → Сгенерировать пакетно

Плюс Storyboard, Canvas, пользовательские навыки, общие активы, командная работа, управление версиями. Продукт вернул «генерацию» в середину рабочего процесса.

Для тех, кто делает ИИ-приложения, здесь прямой инсайт.

Если ядро продукта по-прежнему сводится к схеме «загрузи что-то, ИИ обработает, скачай результат», то при следующем же апгрейде модели его ценность легко схлопнется. Более устойчивый путь — занять ту цельную работу, которую пользователь изначально хотел довести до конца.

Возьмём, к примеру, контент для e-commerce. По отдельности замена товара на фото, смена фона, перевод, озвучка — всё это довольно поверхностные операции. Поднявшись на уровень выше, объектами продукта должны постепенно становиться бренд (Brand), конкретная товарная позиция (SKU), кампания (Campaign), рынок (Market), креативная стратегия (Creative Strategy), варианты креатива (Variants), каналы дистрибуции (Distribution) и эффективность размещения (Performance). Генерация здесь лишь исполнитель; настоящая ценность рождается внутри всего рабочего процесса креативных операций — Creative Operations Workflow.

Пять. Агенты (Agent) переходят от «отвечать на вопросы» к «выполнять задачи»

Сегодня на выступлении, посвящённом агентному поиску Alibaba Cloud OpenSearch, мне попалась одна очень показательная схема эволюции.

Ранний поиск решал задачу «от запроса (Query) — к списку результатов (Results)». Генеративный ИИ сдвинул парадигму к схеме «от вопроса (Question) — к ответу (Answer)». Агентный поиск делает следующий шаг: теперь конечная цель — уже не результат, а действие: «от задачи (Goal) — к действию (Action)».

Иными словами, сам поиск переопределяет своё место в системе.

В будущем исследовательский агент (Research Agent), по всей видимости, сможет автоматически декомпозировать задачу, формировать план запросов, обращаться к нескольким поисковым источникам, уточнять выдачу, перекрёстно верифицировать данные, выстраивать промежуточные выводы — и затем передавать эстафету другим инструментам. Поисковый API постепенно превращается в инфраструктуру, через которую агент получает внешний контекст.

Это неизбежно меняет и то, как мы наблюдаем за SEO и GEO. Если раньше в центре внимания были показы (Impressions), клики (Clicks) и позиции в выдаче (Ranking), то теперь к этому набору добавляются видимость в ИИ (AI Visibility), цитирования (Citation), упоминания (Mention), переходы из ИИ-источников (AI Referral) — и, что принципиально, конвертируется ли этот трафик в регистрации (Signup), оплаты (Paid) и удержание (Retention).

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

6. Настоящие проблемы корпоративного ИИ выходят на организационный уровень

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

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

У кого есть реальная мотивация этим пользоваться?

Допустим, сотрудник применил ИИ и сжал задачу, на которую уходило 8 часов, до 5. Что произойдёт с высвободившимися 3 часами? Если ответ — «ему просто дадут больше работы», — мотивация сотрудника продвигать ИИ самостоятельно, скорее всего, окажется слабой.

Другой пример: если KPI команды ИИ — это количество запущенных агентов и число вызовов, у неё есть стимул бесконечно наращивать функциональность; бизнес-команда несёт издержки перестройки процессов; ИТ и безопасность принимают на себя риск ошибок; а итоговый рост выручки невозможно чётко атрибутировать. В такой организационной структуре, даже если технология работает, внедрение может идти очень медленно.

Корпоративный ИИ нельзя оценивать только по архитектуре (Architecture). Настоящий потолок — это дизайн мотивации (Incentive Design).

Технические проблемы можно решить деньгами, организационные — далеко не всегда. У любого проекта как минимум нужно прояснить: роли (Role), ключевые показатели (KPI), выгоды (Benefit), затраты (Cost), риски (Risk) и полномочия по принятию решений (Decision Right). Кто получает выгоду, тот несёт риски, имеет право решать и отвечает за результат.

Большинство так называемых «проблем внедрения ИИ» в итоге оказываются проблемами организационного дизайна.

7. Самые обманчивые метрики — те, что выглядят нагляднее всего

В презентации Qoder есть один слайд, который на меня произвёл сильное впечатление:

Generation rate is a vanity metric.

На нём сравнивается доля сгенерированного ИИ кода на разных этапах, при этом подчёркивается, что цикл поставки ПО (Delivery Cycle) не сократился в той же пропорции. Конкретные цифры здесь взяты из кейса вендора и не могут служить отраслевым бенчмарком (Benchmark), но заложенная в них логика вполне рабочая.

Когда ИИ удешевляет написание кода (Coding), узкое место смещается к требованиям (Requirement), контексту (Context), архитектуре (Architecture), ревью (Review), тестированию (Test), интеграции (Integration), развёртыванию (Deployment) и приёмке (Validation).

Поэтому скорость генерации кода, число токенов, количество агентов, число вызовов и объём сгенерированных изображений могут становиться локальными метриками эффективности. По-настоящему важны сквозные результаты: сократился ли срок поставки (Lead Time), снизились ли трудозатраты в человеко-минутах (Human Minutes), вырос ли показатель First-pass Acceptance Rate, уменьшилась ли стоимость одной принятой задачи (Cost per Accepted Task), изменились ли итоговые бизнес-показатели.

Конференция напомнила мне простую вещь: цифра «сколько сделал ИИ» легко ослепляет — куда важнее смотреть на «что изменилось во всей системе благодаря этому».

Восемь. Конференция подкидывает ставки — но право решать остаётся за вами

Самое частое последствие посещения конференций — внешний мир начинает расставлять приоритеты за вас.

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

На этот раз я бы предпочёл свести всю эту информацию к одному более простому вопросу:

Какое именно моё решение эта информация способна изменить?

Если она лишь вызывает у меня мысль «как интересно» — это просто входной сигнал.

Если же она заставляет меня заново взвесить «строить самому (Build)», «купить готовое (Buy)» или «проигнорировать (Ignore)», сдвинуть границы продукта, свернуть низкоценную разработку, переработать рабочий процесс или переопределить метрику эксперимента — только тогда она действительно попадает в принятие решений.

Конференция Yunqi (云栖大会, ежегодный технологический форум Alibaba) сама по себе ответом не является.

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

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

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

Если вы сейчас оцениваете, с какого рубежа заходить в корпоративный ИИ, в какие направления стоит вкладываться, а что является пузырём, раздутым нарративом, — давайте обсудим. Мы занимаемся консалтингом по корпоративной ИИ-трансформации: от выбора технологий и оргдизайна до системы метрик — помогая превратить «конференционный шум» в «вашу собственную оценку». Контактный email: [email protected].

Рекомендуем к прочтению: «Семишаговая модель ИИ-трансформации» (《AI 转型七步框架》), в которой системно разобран полный путь внедрения ИИ в компании.

О серии

«Yunqi Observation» — серия отраслевых репортажей IAIUSE, которая стартует с конференции Yunqi 2026 и с исследовательской позиции разбирает реальные сдвиги в индустрии ИИ: без погони за хайпом — только ставки и сила доказательств.

Серия охватывает системный слой над моделями, внедрение агентов, Context-активы, оргдизайн корпоративного ИИ, смену конкурентной единицы в ИИ-продуктах и смежные темы — всего около 10 материалов.

У меня почти 8 лет опыта в консалтинге и бизнес-аналитике для крупного enterprise: я работал в IBM и участвовал в проектах для телекоммуникационной, финансовой, страховой и производственной отраслей. Затем продолжил работать «в поле» — продуктовая разработка у оператора связи, интернет-продукты, ИИ-приложения, — занимаясь анализом требований, продуктовым дизайном и кросс-командным внедрением. Выводы серии основаны на моих полевых наблюдениях и кросс-валидации по отрасли, отражают выраженную авторскую позицию и не представляют точку зрения какого-либо вендора.