Змінний хмарний прогноз

Шаблон, який я бачив раніше

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

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

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

Хмарна корекція

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

Але те, для чого вони будували, не залишилося нерухомим. Хмара не змінилася, але робочі нагрузки змінилися. Коли процеси стали зрілими та передбачуваними, організації познайомилися з витратами на повернення своїх власних даних. Платежі за виїзд, витрати на зберігання, заряди за передачу: витрати, які були легкими для ігнорування, коли гнучкість була вартісною, і важкими для ігнорування, коли робочі нагрузки стабілізувалися. У 2024 році, після років оплати за виїзд даних, AWS, Azure та Google Cloud скасували ці платежі для клієнтів, які міграють з їхніх платформ, як повідомляє DataCenterDynamics.

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

Ці накопичені відповіді стали корекцією, яку промисловість неправильно назвала. Ця корекція отримала назву “репатріація хмари” і неправильно описується більшість часу. Насправді це зрілість робочих нагрузок: зрілі компанії вчаться відповідати кожній робочій нагрузці інфраструктурній моделі, яка їй підходить. Дані підтверджують вибіркове читання, а не цілковите. IDC виявила, що близько 80% організацій очікують деякої репатріації протягом наступних 12 місяців, навіть якщо менше 10% репатріювали цілі робочі нагрузки, згідно з повідомленнями на CIO.com.

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

Той самий корекційний кривий, інша технологія

Цей цикл закінчено і позначено тепер. Той самий вигляд починає формуватися знову з штучним інтелектом. Кожен вендор, кожна конференція, кожний продажний дзвінок зараз про штучний інтелект. Насичення ідентичне тому, що я спостерігав з хмарою. Витрати під шумом реальні: Gartner прогнозує світові витрати на генерацію штучного інтелекту в розмірі 644 мільярдів доларів у 2025 році, на 76,4% більше ніж у минулому році.

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

Просунутися занадто далеко без стратегії, і розгляд не є можливо. Корекція прийде. Вона завжди прийде. Ви просунетеся занадто далеко без стратегії, і врешті-решт економіка та оперативна реальність призведуть до розглядання.

Вже є назва для корективного шаблону, і це не моя назва. Репатріація штучного інтелекту, акт переміщення конкретних завдань з ймовірнісних систем штучного інтелекту назад у детерміновані робочі потоки, коли ці завдання стають стабільними та повторюваними, не є концепцією, яку я винайшов. Це шаблон, який я спостерігаю, як розгортається. Я не одинок у спостереженні за цим: Gartner прогнозує, що понад 40% агентських проектів штучного інтелекту будуть скасовані до кінця 2027 року, посилаючись на зростаючі витрати, невиразну бізнес-цінність та недостатні засоби контролю ризику.

Як виглядає корекція штучного інтелекту

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

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

З визначеннями, встановленими, питання часу відповідає собі. Ймовірнісні робочі потоки часто є правильним інструментом на початку, коли процеси ще не повністю зрозумілі. Вони стають проблематичними, коли компанії продовжують використовувати їх, коли процеси вже зрозумілі.

Конкретний робочий потік робить той ранній проти пізнього розріз помітним. Частина цього робочого потоку справді потребує штучний інтелект. Визначення правильного облікового запису з виклику транскрипції, наприклад, потребує висновків, яких детермінована система не може зробити. Інші частини, прикріплення файлу до запису чи публікація сповіщення, є детермінованими завданнями. Фіксоване правило, прямий виклик API, є тим самим вихідним кожен раз. Я винен у цьому сам: я зараз будую внутрішню автоматизацію, яка поєднує виклики транскрипції, маршрутизує інформацію до нашої CRM, призначає дії та 推ить оновлення до Slack.

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

Граючи це досить далеко, ця ноша перетворюється на чистий марнотрат. Подумайте про компанію, яка використовує штучний інтелект для аналізу 50 000 підтримуючих квитків. Штучний інтелект визначає п’ять найпоширеніших шляхів вирішення. Спочатку штучний інтелект обробляє маршрутизацію ймовірнісно: читає кожен квиток та робить судове рішення. З часом компанія підтверджує ці моделі. Шляхи вирішення тепер відомі. Перетворення їх на детерміновані гілки робочого потоку не усуває штучний інтелект з процесу, але воно усуває зайву практику оплати штучному інтелекту за повторне відкриття відповідей, які тепер відомі.

Це ймовірнісний податок: доданий витрат, затримка та ноша управління, пов’язана з використанням штучного інтелекту як часу виконання для роботи, яка вже не потребує ймовірнісного міркування.

Як виглядають зрілі операційні моделі

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

Цей розріз створює чітке правило операції. Ймовірнісні системи цінні там, де існує справжня двозначність. Люди двозначні. Неструктуровані дані двозначні. Процеси, які ще не повністю зрозумілі, двозначні. Висновок є правильним інструментом для всього цього. Інша половина правила так само важлива: детерміновані системи є там, де масштаб, вартість, швидкість та управління мають значення. Ймовірнісний шар відкриває та інтерпретує. Детермінований шар виконує.

На землі дві сигнали кажуть вам, до якої сторони належить дана робоча нагрузка:

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

На практиці ця межа проводиться як поріг впевненості. Конкретний поріг впевненості, зобов’язання до рішення, коли модель понад 90% впевнена, або відмови від неї нижче цього рівня, часто є тим місцем, де ця межа проводиться на практиці.

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