Від Prompt Engineering до Intelligent Automation. Що ми упускаємо?

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Матеріал буде корисним для широкої аудиторії: від початківців до досвідчених IT-фахівців. А також для менеджерів, рекрутерів, HR, освітян та всіх небайдужих до теми ШІ й впровадження інноваційних автоматизованих рішень у бізнес.

Prompt Engineering. Level 1

LLM-бум привніс у життя новий важливий скіл, який має опанувати кожен, хто хоче ефективно використовувати інструменти генеративного ШІ — Prompt Engineering. Сама собою напрошується аналогія з минулого — «Оператор ПК». Все просто: опанували основи Prompt Engineering і радісно витискаємо максимум із зоопарку сервісів та технологій, підсилених сучасними LLM... Відчуваємо певний буст від використання ШІ в повсякденній роботі й розуміємо, що в цьому є хороший потенціал. А далі? Що вивчати і в якому напрямку розвиватися? І які є напрямки?

Коли йдеться про застосування ШІ в бізнесі, можна виділити три ключові напрямки:

• LLM: генерація контенту, розумні асистенти, автоматизація.
• Computer Vision: роботи, контроль якості, безпека, охорона праці.
• Data Science: прогнозування попиту, рекомендаційні системи, склад, логістика.

Початківці зі знанням Prompt Engineering у більшості випадків під «ШІ» мають на увазі напрямок, пов’язаний з LLM. Зосередимось на тому, що пов’язано саме з цим.

Prompt Engineering + No-Code / Low-Code

Більшість тренерів та курсів про це не говорять, але, на мій погляд, подальший шлях розвитку цілком очевидний — вчитися тотальній автоматизації з використанням ШІ, опанувавши одну з так званих No-Code / Low-Code платформ. Наприклад, загальнодоступні сервіси — Zapier, Make, Latenode тощо. Це дозволяє добитися чудових результатів, витративши декілька днів на опанування зв’язки Prompt Engineering та No-Code / Low-Code.

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

При цьому вони щодня чують про «Агентів», які чи то частково, чи то повністю — витіснять їх у близькому майбутньому... І новоспечені «Ноу-Кодери / Промпт-Інженери», а іноді й бородаті гуру, ставлять однакове питання: «Що далі?».

Давайте подивимось у майбутнє, апроксимуючи попередні тренди.

Ретроспективний погляд

Озираючись у минуле, спадає на думку три типи прикладного програмного забезпечення, які сформували сучасний ІТ-ландшафт таким, яким ми його знаємо. А саме:

1. Десктопний софт. Від ранніх WordPerfect та Lotus 1-2-3 до сучасних Chrome та Steam.
2. Вебсервіси. Від Yahoo до Netflix та Microsoft 365.
3. Мобільні додатки. Від J2ME та Symbian до сучасних додатків для Android / iOS.

Днями Сатья Наделла, CEO Microsoft, окреслив майбутній тренд:

«The application layer is collapsing into agents»

Іншими словами:

Щойно з’явиться зручний для клієнтів (особливо малого бізнесу), а також швидкий і дешевий для розробників-одинаків спосіб дистрибуції «Агентів», — економіка зробить свою справу, а ІТ-ландшафт вчергове зміниться.

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

Навряд чи хтось у здоровому глузді заперечуватиме, що за декілька років майже весь e-commerce стане роботизованим на базі ШІ. І що цей тренд радісно підхоплять інші напрямки бізнесу, особливо медіа, сфера обслуговування та й загалом велика кількість представників реального сектору...

А отже, постає питання: Хто всі ті люди, які створять для нас із вами сотні тисяч інтерактивних рішень на базі ШІ, та що їм для цього потрібно освоїти?

RPA — Robotic Process Automation

Самій концепції RPA вже добрий десяток років. Існує чудова теоретична база у вигляді курсів від провідних вендорів та університетів, а також ціла низка зрілих платформ: Power Automate, UiPath, Blue Prism тощо. Але, попри це, ми все ще перебуваємо в початковій фазі глобального тренду під умовною назвою «Тотальна роботизація». Чому?

Давайте поміркуємо разом:

ІНФОРМАЦІЙНІ технології стали ОПЕРАЦІЙНИМИ.

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

Нас чекала революція. І вона прийшла.

Intelligent Automation. RPA++

Бурхливий розвиток AI спричинив появу та активний розвиток IA (Intelligent Automation) — як одного з ключових драйверів змін у впровадженні ІТ-рішень для бізнесу.

Я б назвав це явище «демократизацією технологій», адже саме цим воно є:

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

Intelligent Automation базується на трьох ключових компонентах:

Якщо з BPM (Business Process Management) плюс-мінус усе зрозуміло, то стосовно інших двох виникають запитання:

• Чи вірно стверджувати, що No-Code / Low-Code скіли є попередньою, підготовчою сходинкою до RPA?

Так, цілком. Людина, яка опанувала умовний Zapier, з легкістю сприйме концепцію RPA, адаптувавшись до нових для себе платформ за лічені години, навіть не дні. Вона таким чином закриє очевидні прогалини та вийде на якісно новий рівень. Таким чином маємо прямий і зрозумілий шлях: No-Code / Low-Code > RPA.

• Чи не виникає при цьому відчуття, що інший компонент Intelligent Automation, а саме «Artificial Intelligence», виглядає дещо неповним і існує якась прогалина на шляху від Prompt Engineering до Intelligent Automation?

Переконаний, що так. Адже вся елегантність, гнучкість та сила складних інтерактивних мультифункціональних діалогових агентів на базі ШІ з когнітивним прийняттям рішень навряд чи покривається самими лише принципами Prompt Engineering та RPA.

У структурі IA спеціалізації бракує важливого елемента:

Я зрозумів це на власному досвіді, готуючи матеріали для чергового уроку в рамках базового курсу з ШІ, який я на вихідних викладаю ветеранам, пацієнтам місцевого госпіталю. Хлопці засвоїли Prompt Engineering, No-Code та просунулися в напрямку RPA... Але ми зіткнулися з труднощами в переході від «простих» (1-Prompt / RAG) ботів до більш складних «Агентів». З’явилося відчуття, що RPA в поєднанні з Prompt Engineering примушує «танцювати з бубном» у спробах пояснити та реалізовувати мультифункціонального агента з когнітивним прийняттям рішень.

Наприклад, створюємо агента для роботи з клієнтами в сервісі доставки піци. Тривіальний раутинг потоку виконання на базі потреби користувача в консультації вимагає циклу «FOR EACH» для кожного повідомлення, з подальшим API-викликом моделі ШІ та промптом виду «поверни 1, якщо користувач потребує консультації, 2 — якщо хоче дізнатись статус замовлення, 3 — ...». А потім — окремих IF-ELSE IF-ELSE або SWITCH / CASE для кожної відповіді.

Це незручно, ненаглядно і некруто.

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

Історично зростання продуктивності в Software Engineering було пов’язане з підвищенням рівня абстракції: від машинного коду та асемблера — до змінних, функцій та ООП; від реального hardware — до віртуальних машин із JIT.

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

Нам потрібен вихід, і я його знайшов.

Dialogue Engineering

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

У своїй голові я формулюю це таким чином:

Dialogue Engineering — це фреймворк та підхід до проєктування, розробки, впровадження та оптимізації інтерактивних діалогових рішень або «ШІ Агентів», які здатні вести осмислені та ефективні розмови з людьми й приймати рішення на базі когнітивної логіки.

На відміну від простого написання «промптів» (що є частиною Prompt Engineering), Dialogue Engineering охоплює набагато ширший спектр завдань, що стосуються побудови повноцінного розмовного досвіду та досягнення мети із застосуванням гнучких підходів.

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

Робочий цикл діалогових рішень

Якщо узагальнити, то переважна більшість інтеграцій LLM в об’єктну модель RPA зводиться до простого циклу. Я називаю це IPTA (Input-Process-Think-Act). Подібний підхід прокладає міст між класичним RPA та наступним поколінням платформ. Розглянемо детальніше:

• Input. Це подія, яка ініціює інтеграцію. Наприклад — звернення користувача або інший тригер (оплата рахунку, зміна статусу замовлення, підвищення температури, вхід у приміщення, настання конкретного моменту часу для запуску за графіком тощо). Це дає можливість створювати як класичних пасивних, так і проактивних Агентів, які самі ініціюють взаємодію з користувачем.
• Process. Це складання докупи всіх відомих факторів, генерація метапромпта: Базовий промпт, рольова модель, профіль поведінки, цілі й завдання, функції, контекст події, пам’ять (дані з минулих циклів), дані користувача, обмеження тощо.
• Think. Виявлення суті запиту та визначення найкращої реакції. Тут відбувається виявлення потреби, наміру, теми, сутності запиту та робиться вибір реакції — відповідь на питання або запит додаткових даних чи використання інструментів. Це точка прийняття рішення про подальші дії (напрямок контрольного потоку — у термінах RPA).
• Act. Дія — когнітивний перехід до іншого функціонального модуля, на базі виявленої потреби чи наміру користувача, або повідомлення у відповідь, звернення за MCP-протоколом, Webhook чи використання інструмента (однієї з доступних інтеграцій).

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

Про все це — далі.

Концепція у першому наближенні

Для ілюстрації підходу візьмемо простий приклад — Агент, який керує доставкою піци. Масове впровадження таких рішень починає відбуватися прямо зараз. Отже, це дуже близьке майбутнє і зрозумілий для всіх use case.

Маємо набір функцій:

• Консультувати.
• Приймати замовлення.
• Відміняти замовлення.
• Змінювати замовлення.
• Перевіряти статус.
• Опрацьовувати скарги.

Усе це — функціональні модулі. Разом з обов’язковим базовим модулем — «Лобі» (точка входу, початковий модуль).

Модуль — це верхньорівнева логічна одиниця, обгортка для «циклу». Аналог «класу» в мовах програмування або «контейнера» — у термінах RPA.

Модуль має такі властивості:

Назва / Функція. Наприклад: «Лобі», «Консультація», «Статус замовлення».

Базовий промпт. Для «лобі» він один, а для прийому замовлення — інший.

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

Профілі поведінки. В рамках одного й того самого промпта з його цілепокладанням виникає необхідність у корекції поведінки Агента залежно від певної специфіки — контексту, зовнішніх обставин, типу користувача (наприклад, неповнолітній). Ці профілі декларуються в базовому промпті основного модуля («Лобі») та можуть активуватися в інших модулях залежно від ситуації.

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

Контекст. Це лог попередніх циклів у рамках поточного діалогу.

Пам’ять. Дані користувача та історія минулих взаємодій. Це суттєво покращує UX, спрощуючи обробку запитів типу «хочу те, що замовляв у минулу п’ятницю», «врахуй мої вподобання», «порекомендуй щось новеньке»).

Інструменти. Тут усе, наче, зрозуміло: бази даних, месенджери, календарі, CRM, пошта, MCP сервери, вебхуки тощо. Кожен модуль має власний перелік інструментів, доступний в рамках нього.

Когнітивна логіка переходів між модулями

Далі — цікавіше. Раз машина здатна виявляти в тексті потреби, наміри, теми, поняття, факти — це потрібно використовувати. Замість кнопок типу «зробити замовлення» та «дізнатись статус» можна застосовувати когнітивні методи та здійснювати переходи між модулями на основі цього. Просто й елегантно. Наприклад:

Перша фраза користувача «Привіт, а у вас смачна піца!» не дає нам явного наміру або потреби, але дозволяє встановити сутність «позитивна оцінка». Це дає змогу далі продовжити діалог (повторити цикл «Лобі») або перенаправити потік виконання на певний модуль лояльності, в якому можна зібрати детальний фідбек, запропонувати реферальну програму або надати знижку.

Фраза «Не можу визначитись» виявляє потребу в рекомендації або консультації, з переходом на відповідний модуль.

Фраза «Давайте як минулого разу» виявляє намір користувача зробити замовлення, причому вказує на його деталі.

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

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

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

The Outcome

Dialogue Engineering — це підхід, спрямований на спрощення та прискорення розробки Агентів на базі ШІ. Він як вписується в класичний RPA (у вигляді циклу), так і дозволяє реалізувати нове покоління рішень — простіших, зручніших, швидших, дешевших.

Я навмисне дав лише поверхневий перший погляд, без заглиблення у «смачніші» фічі, такі як робота з кількома користувачами одночасно (група замовників у месенджері, або інтерактивна взаємодія із замовником, кур’єром та менеджером — різними каналами), реакція на зовнішні події, делегування контрольного потоку, обробка невизначеностей, взаємодія з іншими Агентами тощо.

Я завершую роботу над відповідним курсом. Роблю це для цієї та майбутніх груп у госпіталі. Якщо бажаєте дізнатись більше про Dialogue Engineering — слідкуйте за новинами на сайті проєкту xWarriors Academy.