Як ШІ змінює математику для стартапів

Аманда Сільвер з Microsoft протягом 24 років допомагає розробникам, а останні кілька років це означало створення інструментів для штучного інтелекту. Після тривалої роботи в GitHub Copilot, Сільвер зараз є віце-президентом підрозділу CoreAI Microsoft, де вона працює над інструментами для розгортання програм та агентних систем у підприємствах.

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

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

Отже, ваша робота зосереджена на продуктах Microsoft для зовнішніх розробників — часто це стартапи, які інакше не зосереджені на штучному інтелекті. Як, на вашу думку, ШІ вплине на ці компанії?

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

Як це виглядає на практиці?

Ми, безумовно, бачимо, як багатокрокові агенти стають дуже широким використанням у всіх різних видах завдань кодування, чи не так? Наприклад, одна з речей, яку розробники повинні робити для підтримки кодової бази, це бути в курсі останніх версій бібліотек, від яких вона залежить. У вас може бути залежність від старішої версії середовища виконання .NET або Java SDK. І ми можемо використовувати ці агентні системи для аналізу всієї вашої кодової бази та оновлення її набагато легше, можливо, зі скороченням часу на 70% або 80%. І для цього дійсно має бути розгорнутий багатокроковий агент.

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

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

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

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

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

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

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

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