【Спостереження Yunqi】Конференція Yunqi — це не відповідь, а карта того, на що робить ставку AI-індустрія

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

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

Обидва погляди надто поверхневі.

Звісно, виставки мають маркетинговий характер, але сам маркетинг також є інформацією. Коли виробник спрямовує бюджет, продакт-менеджерів, інженерні команди, відділ продажів і виставкові ресурси в певний напрямок, це щонайменше свідчить про два речі: що він хоче, аби ринок повірив, і на яку проблему він намагається перетворити розробку на продукт.

Тож тепер я радше розглядаю великі технологічні конференції як високощільний майданчик промислової вибірки. Вони не дають відповідей, але дають вибірки, сигнали, контрприклади та карту «на що галузь робить ставку заради майбутнього».

1. Спочатку розкладемо «галас» виставки на різні рівні доказовості

Цього разу я свідомо почав розділяти технологічний напрямок на п’ять рівнів:

Наратив → Продукт → Виробництво → Бізнес → Дохід
(Narrative → Product → Production → Business → Revenue)

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

На рівень нижче — продуктовий рівень (Product) — те, що вже можна показати, викликати через API чи поставити замовнику. На стендах — готові інтерфейси, API, робочі консолі, платформи governance. Це означає, що певний напрям уже перейшов від концепції до зрілого продукту. Між «можна продемонструвати» і «може стабільно працювати місяцями» все ще пролягає велика прірва.

Ще нижче — рівень виробництва (Production) — тут продукт справді інтегрується в процеси замовника, працює безперервно й натикається на цілком реальні речі: права доступу, дані, аудит, відновлення після збоїв, витрати, координацію між підрозділами. Лише в цей момент можна говорити про справжнє промислове впровадження.

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

Найнижчий і водночас найконкретніший — це рівень доходу (Revenue): чи готовий клієнт платити довгостроково, за який результат він готовий платити, за яких умов відбувається поновлення підписки.

Ця рамка потрібна, щоб не змішувати різні типи доказів. Виставковий стенд доводить, що напрямок варто показувати; форум показує, яке сприйняття вендор хоче закріпити в головах; реальні кейси клієнтів підвищують достовірність на виробничому та бізнес-рівнях; а стійкий дохід підтверджує вже рівень доходу.

Тому сам по собі галас навколо якогось напрямку на конференції — ще не привід вкладати в нього вже зараз.

2. Найпомітніша зміна цього разу: над моделями виростає дедалі більше шарів

Останніми роками розмови про AI зводилися переважно до моделей: розмір параметрів, бенчмарки (Benchmark), здатність до міркування, ціна, розмір контекстного вікна, якість зображень, можливості коду.

Цього разу на місці я чітко відчув, що фокус зміщується.

Моделі все ще важливі, але системний шар навколо них помітно потовстішав. Для аналогії: ще кілька років тому всі змагалися в потужності двигуна, нині ж потужності вистачає, і конкуренція переміщується на рівень автомобіля загалом — шасі, трансмісія, гальма, панель приладів, подушки безпеки, управління витратою пального. Фундамент даних, доступ до моделей, управління токенами, середовище виконання агентів, ізольовані пісочниці, контекст, пам’ять, навички, робота в браузері, керування робочим столом, верифікація, спостережуваність, дозволи, аудит, контроль витрат — дедалі більше можливостей виокремлюються в самостійні продукти.

Причина цілком пряма: між здатністю моделі відповідати на запитання та її здатністю потрапити у виробничий процес і надійно виконати роботу стоїть ціла інженерна система.

Якщо провести день на виставці, можна побачити п’ять-шість продуктів із абсолютно різними назвами, які, проте, сходяться до однієї й тієї самої архітектури. QwenWork демонструє, як агент викликає різноманітні інструменти в ізольованому середовищі для виконання завдань. Qoder розповідає про контекст, специфікації вимог, тестові фреймворки, верифікацію, пам’ять і мультимодельну маршрутизацію. TinyFish, партнер-виробник в екосистемі Alibaba Cloud, займається тим, щоб агенти могли виконувати завдання у справжньому вебсередовищі. WonderClip розкладає відеовиробництво на сценарій, розкадрування, матеріали, генерацію, рецензування, версії та серійне виробництво. Агентний пошук в Alibaba Cloud OpenSearch своєю чергою розширює пошук у бік планування, міркування, пам’яті, дій та оцінювання.

На перший погляд вони належать до абсолютно різних царин, проте їхня базова структура збігається:

Контекст → Планування → Навичка → Виконання → Верифікація → Пам’ять → Бізнес-результат
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

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

3. Контекст (Context) перетворюється з «вхідного матеріалу» на довгостроковий актив

Під час виступу Qoder (IDE-агент від ByteDance) на одній із конференцій прозвучала думка, приблизно така: обчислювальна потужність моделей перетвориться на масовий товар, а справжнім активом стане контекст.

Звісно, у цьому відчувається позиція вендора, але за нею стоїть цілком реальна проблема. Що потужнішою та доступнішою стає модель, то більше довгострокова здатність агента ефективно працювати залежить від того, що саме він «знає» про вашу організацію.

Якщо говорити прямо: модель можна замінити будь-якої миті, а ваші внутрішні активи — нікуди не подінуться. Архітектурні обмеження, історичні рішення, бізнес-правила, допущені помилки та підводні камені, характер клієнтів. Що більше цього накопичено, то краще працює AI.

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

Ця інформація не з’явиться автоматично від самої заміни моделі на потужнішу.

Тому Qoder створює Wiki для кодових репозиторіїв (Repo Wiki), Memory та Knowledge Cards, QwenWork наголошує на корпоративному контексті (Enterprise Context), а OpenSearch робить акцент на довгостроковій пам’яті, пам’яті завдань і стисненні контексту. Усі вони намагаються розв’язати одну й ту саму проблему: звільнити агента від необхідності щоразу починати розуміння світу з нуля.

Це також означає, що бібліотеки промптів, які раніше так полюбляли накопичувати багато команд, у добу агентів, імовірно, не матимуть такої довгострокової цінності, як уявлялося. Промпт — радше спосіб виклику конкретного завдання; справді «працює на складний відсоток» інше: бізнес-контекст, історія рішень, результати валідації, причини збоїв і багаторазово придатні навички.

IV. Конкурентна одиниця AI-продуктів зміщується від «однієї функції» до «цілісної роботи»

Це особливо відчутно на прикладі WonderClip.

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

Але показана наживо продуктова архітектура вже рухається в бік більш завершеної виробничої системи:

Upload the script → Review the breakdown → Prepare the assets → Generate in bulk

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

Це дає прямий урок для розробки AI-застосунків.

Якщо ядро продукту все ще зводиться до схеми «завантажив → AI опрацював → забрав результат», то наступне оновлення моделі легко стискає його цінність. Стабільніший шлях — зайняти цілу роботу, яку користувач мав виконати сам.

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

5. Агенти рухаються від «відповідати на запитання» до «виконувати завдання»

На виступі Alibaba Cloud OpenSearch про агентний пошук мою увагу привернула одна дуже показова діаграма еволюції.

Перше покоління пошуку: ви вводите ключове слово, отримуєте десять посилань і самостійно шукаєте відповідь.
Друге покоління пошуку (генеративне): ви ставите питання й одразу отримуєте відповідь.
Третє покоління пошуку (агентне): ви формулюєте мету — агент сам знаходить дані, ухвалює рішення, викликає потрібні інструменти й на завершення надає вам готовий результат.

Різницю між трьома поколіннями легко пояснити на прикладі: ви хочете порівняти корпоративні рішення трьох хмарних провайдерів. Перше покоління покаже посилання на їхні сайти, друге — коротке резюме, а третє одразу видасть підготовлену рекомендацію для закупівлі.

Сам пошук також переосмислює свою роль. Він більше не кінцева точка, а інфраструктура, через яку агент отримує зовнішню інформацію. Дослідницький агент автоматично декомпонує запит, звертається до кількох пошукових джерел, перехресно перевіряє дані, формує проміжні висновки, а потім підключає інші інструменти для подальших кроків.

Пошук не зник — він став частиною більшого замкненого робочого циклу.

6. Справжні виклики корпоративного ШІ переходять на організаційний рівень

На конференції багато уваги приділяли технічним питанням корпоративного ШІ: даним, доступам, безпеці, governance, інтеграції моделей, хмарній архітектурі та платформам агентів.

Усе це має значення. Але після кількох кейсів мене дедалі більше хвилює інше питання:

Хто має реальну мотивацію цим користуватися?

Уявіть, що працівник за допомогою ШІ стиснув свою 8-годинну роботу до 5 годин. Що станеться з тими трьома годинами, що звільнилися? Якщо відповідь — лише «дати йому ще більше роботи», його власна мотивація просувати ШІ, найімовірніше, буде невеликою.

Інший приклад: якщо KPI команди ШІ — це кількість запущених агентів і число викликів, у неї є стимул нарощувати функціонал; бізнес-команда несе витрати на перебудову процесів; ІТ-команда та служба безпеки несуть ризик помилок; а приріст доходу неможливо чітко приписати до конкретного джерела. У такій організаційній структурі, навіть коли технологія доступна, впровадження може гальмуватися.

Корпоративний ШІ не можна оцінювати лише за архітектурою — справжня стеля визначається дизайном мотивацій.

Технічні проблеми розв’язуються грошима; організаційні — грошима розв’язуються далеко не завжди. Щодо кожного проєкту треба чітко відповісти на шість запитань: роль, KPI, вигода, витрати, ризик, право рішення. Хто отримує вигоду, хто несе ризик, хто має право рішення, хто відповідає за результат.

Команда 高德 (Amap, навігаційний сервіс Alibaba) за допомогою Qoder Knowledge Engine перетворила галузеві знання з мільйона рядків коду на активи, що їх можна витягати за запитом, — і частка задач, які проходять з першої спроби, зросла з 37,3% до 61,5%. За цим результатом стоїть не лише впроваджений інструмент, а й те, що команда перетворила «накопичення галузевих знань» з опції на жорсткий показник. Якщо просто кинути інструмент у команду і ніхто не відповідає за «якість накопичення знань», ефект, найімовірніше, буде вдвічі слабшим.

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

Сім. Найчастіше оманливі саме ті метрики, що видаються найочевиднішими

Під час виступу Qoder прозвучала теза: частка AI-згенерованого коду — це марна метрика.

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

Коли AI знижує вартість написання коду, вузьке місце зміщується до вимог, контексту, архітектури, рев’ю, тестування, інтеграції, розгортання та приймання.

Те саме працює і в бізнес-сценаріях. Дивіться не на «скільки зображень згенерував AI», а на те, чи скоротився цикл підготовки матеріалів для маркетингової акції з двох тижнів до трьох днів. Дивіться не на «скільки разів викликали AI», а на те, чи зросла середня кількість звернень, яку опрацьовує оператор контакт-центру, і чи зменшилися скарги клієнтів. Частка згенерованого коду, кількість токенів, кількість агентів, кількість викликів, обсяг згенерованих зображень — усе це може бути лише локальною метрикою ефективності. Справді важливий — наскрізний результат: чи скоротився цикл постачання, чи зменшилися людино-години, чи зросла частка прийнятих із першої спроби, чи знизилася собівартість прийнятого завдання, чи змінилися кінцеві бізнес-показники.

Ця конференція стала мені нагадуванням: не варто бути зачарованим тим, «скільки зробив AI», — варто дивитися, що саме змінилося в системі загалом.

Вісім. Конференція підказує — але право вирішувати залишається за вами

Найлегше, що може статися на конференції, — це коли зовнішній світ починає визначати ваші пріоритети замість вас.

Чим більше про якусь тему говорять зі сцени — тим сильніше відчуття, що її варто дослідити. Чим більше великий гравець у неї інвестує — тим більше здається, що треба наздоганяти. Чим прогресивнішим виглядає продукт — тим більше хочеться його в себе запровадити.

Цього разу я волію звести весь цей інформаційний шум до простішого питання:

Як саме це змінить моє Рішення?

Якщо почуте лише викликає «як цікаво» — це просто вхідні дані.

Якщо ж воно змушує переглянути вибір між Build, Buy та Ignore, зміщує межі продукту, зупиняє чергову низькоцінну ініціативу, переконструює робочий процес або перевизначає метрику експерименту — лише тоді воно справді стає частиною рішення.

Apsara Conference — не відповідь.

Радше це карта галузевих ставок. Карта, з якої видно, куди рухаються інші, де починається заторик, яка інфраструктура формується, які проблеми масштабуються у готові продукти.

Який шлях обрати врешті — усе одно визначають ваші цілі, обмеження, ресурси й докази.

Саме це я хочу виносити з технічних конференцій: бачити більше ставок, але залишати право на остаточне рішення за собою.

Якщо ви зараз оцінюєте, з чого починати впровадження корпоративного ШІ, які напрямки варті інвестицій, а які — лише роздуті хайпом бульбашки, — ласкаво просимо поспілкуватися. Ми спеціалізуємося на консалтингу з корпоративної ШІ-трансформації — від технологічного вибору й організаційного дизайну до побудови системи метрик. Допомагаємо перетворити «галас із конференцій» на «вашу власну обґрунтовану позицію». Контакт для співпраці: [email protected].

Додаткове читання: «Семикрокова рамка ШІ-трансформації» — системний розбір повного шляху впровадження ШІ в компанії.

Про цю серію

«Спостереження Юньці» — це серія IAIUSE про індустріальний ландшафт, що стартує від конференції Yunqi 2026 (щорічна конференція Alibaba Cloud). Крізь призму дослідника ми розбираємо реальні зміни, які відбуваються в ШІ-індустрії — не женемося за хайпом, а дивимося, куди роблять ставки та наскільки переконливі докази.

Серія охоплює системний шар над моделями, впровадження агентів, Context-активи, організаційний дизайн ШІ в компаніях, зміну одиниці конкуренції ШІ-продуктів та інші теми — загалом близько 10 матеріалів.

Маю майже 8 років досвіду консалтингу й бізнес-аналітики у великих корпораціях, працював у IBM, брав участь у проєктах для телекомунікацій, фінансів, страхування й виробництва. Згодом продовжував працювати на першій лінії операторських продуктів, інтернет-продуктів і розробки ШІ-застосунків — аналіз вимог, продуктовий дизайн, крос-командне впровадження. Судження цієї серії ґрунтуються на моїх польових спостереженнях і міжгалузевій верифікації, відображають чітку авторську позицію та не репрезентують жодного вендора.