Чому «прикрутити» ШІ до продукту недостатньо? Розмова з Леонідом Абасовим, провідним інженером Prometheus Group

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

Проблема в тому, що ШІ не можна просто «прикрутити» до продукту як ще один сервіс, пояснює Леонід Абасов, Principal Software Engineer у Prometheus Group. Раніше він працював над інженерними проєктами, пов’язаними з Microsoft і NASA, займався масштабуванням інфраструктури Namecheap, а також розробляє open-source інструменти для побудови pipeline-архітектур.

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

ㅤ Новини компаній ㅤ

Чому просто «прикрутити модель» не вийде

— Сьогодні багато компаній намагаються просто додати ШІ до продукту. Чому підхід «прикрутити модель» майже не працює?

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

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

— Якщо ШІ має бути частиною архітектури, де саме він повинен знаходитися в системі?

— Найчастіше в data pipeline. Саме там формується якість даних, від якої залежить результат моделі.

— Ви працюєте з рішеннями для підприємств у Prometheus Group. Які вимоги виникають, коли ШІ інтегрується у промислові системи?

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

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

— Які архітектурні помилки ви найчастіше бачите у ШІ-проєктах?

— Найпоширеніша помилка – це фокус на моделі, а не на системі.

Про власний досвід, який допомагає у контексті ШІ

— До Prometheus Group ви працювали в Namecheap. Як досвід роботи з інфраструктурою для мільйонів користувачів впливає на підхід до ШІ?

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

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

— Ви також працювали над проєктами, пов’язаними з Microsoft і NASA. Чим відрізняється архітектура таких систем?

— Там дуже високі вимоги до стабільності та передбачуваності. Експериментувати можна лише в чітко контрольованих межах.

— Ви створили open-source бібліотеку PipelineLauncher. Для чого вона була розроблена?

— Усе почалося з практичної задачі – спростити побудову pipeline-архітектур у .NET-проєктах. Так з’явився інструмент PipelineLauncher. Багато систем, особливо тих, що працюють із великими обсягами даних, насправді складаються з ланцюжка етапів обробки: підготовка даних, трансформація, аналіз і формування результату.

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

Про зміни та майбутнє сфери

— Як змінюється роль програмістів у світі, де з’явилися ШІ-асистенти для написання коду?

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

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

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

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

— І наостанок: яку одну архітектурну помилку ви б порадили уникати компаніям, які будують ШІ-системи?

— Не починати з моделі. Починати потрібно з архітектури даних.

Штучний інтелект поступово стає частиною архітектури сучасних програмних систем. Але, як показує практика, успіх таких проєктів залежить не від того, яку модель використовує компанія, а від того, наскільки продумано побудована вся система – від збору даних до контролю результатів. Саме цей інженерний підхід, за словами Леоніда Абасова (Leonid Abasov), і визначає майбутнє ШІ у реальних продуктах.

ㅤ Новини компаній ㅤ