Нікундж Баджай, співзасновник і генеральний директор TrueFoundry – Серія інтерв’ю

Ви працювали над дослідженнями машинного навчання, виробництвом штучного інтелекту в Facebook (META ) та великомасштабними системами рекомендацій до заснування TrueFoundry — які досвіди найпряміше спонукали вас до створення корпоративної інфраструктури штучного інтелекту, і яку біль ви відчували, що не була вирішена на той момент?

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

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

Наша команда завжди працювала на перетині створення моделей машинного навчання та інфраструктури машинного навчання, тому ми мали унікальну точку зору, яку могли принести подібні вертикальні стеки до підприємств і адаптувати їх для конкретних вимог. У нас також була гіпотеза наприкінці 2021 року, що машинне навчання наближалося до точки інфлекції, і коли це відбулося, більше компаній будуть потребувати вертикально інтегрованого стека для розгортання та масштабування цих систем ефективно. Це врешті-решт привело нас до заснування TrueFoundry, і наша гіпотеза була правильною. Впровадження штучного інтелекту прискорилося після запуску ChatGPT у кінці 2022 року.

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

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

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

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

TrueFailover був запущений під час хвилі високопрофільних збоїв хмарних та штучно-інтелектуальних сервісів. Які недавні події зробили зрозумілим, що надійність штучного інтелекту перейшла від “бажаного” до основної архітектурної вимоги?

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

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

Багато збоїв штучного інтелекту все ще подаються як технічні помилки. Де ви бачите справжні економічні та людські витрати, які починають з’являтися, коли системи штучного інтелекту виходять з ладу?

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

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

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

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

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

Ви сказали, що багато команд проектують можливості, а не безперервність. Чому, на вашу думку, стійкість історично була занижена в проектуванні систем штучного інтелекту?

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

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

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

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

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

Без фокусу на конкретних продуктах, як організації повинні переосмислити архітектуру штучного інтелекту, щоб припустити відмову, а не розглядати аварії як рідкісні крайні випадки?

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

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

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

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

Оглядаючись вперед, що означає “готовність до виробництва” штучного інтелекту в світі, де штучний інтелект очікується бути безперервно доступним, а не лише періодично корисним?

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

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

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

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

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