Повний стек агентського ШІ, рівень за рівнем: від фронтенду до можливості спостереження.
Десять рівнів за лаштунками агентського сервісу: фронтенд, прийом даних, розділення на частини, ембеддинги, векторний пошук, отримання інформації, формулювання запитів, ШІ з великими мережами, розгортання та оцінка.
Джерела: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence
Штучний інтелект вже давно вийшов за межі ситуації, коли хтось вводить запит та читає відповідь. Сучасні продукти ШІ — це повноцінні програмні системи. Вони приймають документи, перетворюють хаотичний неструктурований матеріал на корисні знання, генерують ембеддинги, отримують контекст, взаємодіють із великими мовними моделями, запускають інструменти, функціонують у хмарній інфраструктурі та стежать за власною продуктивністю. Це подвійно стосується агентних систем ШІ. Агент — це не просто LLM, що знаходиться всередині вікна чату. Продуктивний агентний додаток потребує цілої технологічної стеку навколо моделі, причому сама модель є лише одним з її елементів.
Діаграма референтної архітектури цього стеку є зручною картою, яка охоплює шлях від фронтенду через процеси отримання даних, пошуку та формулювання запитів до моделей, їх розгортання та моніторингу. У наступних розділах розглядається кожен елемент цього стеку, його призначення, причина існування та спосіб взаємодії інструментів між собою.
Шари в одному погляді
У певній послідовності працює цей стек: фронтенд, обробка документів, розділення на частини та попередня обробка, ембеддинги, векторна база даних, пошук інформації, розробка запитів, ШІ, інфраструктура та розгортання, а нарешті — моніторинг та оцінка.
Ця послідовність не є суворо визначеною ланцюговою процедурою. У справжніх агентних системах елементи постійно взаємодіють між собою. Агент може кілька разів отримувати інформацію, викликати зовнішні інструменти, використовувати різні моделі, оцінювати власні відповіді та запускати додаткові процеси перед тим, як отримати кінцевий результат. Краще розглядати цей стек як технологічну екосистему, що оточує інтелект, а не як просту ланцюгову структуру запит-відповідь.
Шар 1: фронтенд
Кожній системі ШІ потрібне місце, де люди можуть з нею взаємодіяти. Фронтенд забезпечує інтерфейс взаємодії – чи то чат-бот, корпоративний портал, панель аналітики, внутрішній інструмент чи робоче середовище з підтримкою ШІ. Типовими технологіями є React, Next.js, Streamlit та Azure App Service. React дозволяє створювати інтерактивні інтерфейси, а Next.js – більш повну фреймворк-систему для розробки веб-додатків у промислових умовах. Streamlit зручний для швидкого створення додатків на основі ШІ та даних без використання традиційних інструментів фронтенду. Azure App Service пропонує кероване хостинг для веб-додатків та API.
У корпоративній архітектурі з використанням агентів фронтенд – це не просто чат-вікно. Він може відображати прогрес агента, джерела отриманої інформації, статус робочого процесу, результати роботи інструментів, запити на схвалення, створені документи та взаємодію з людиною. Саме тут ШІ стає доступним для корпоративних користувачів.
Рівень 2: збір документів
Ефективна система потребує доступу до релевантної інформації, проте корпоративні знання рідко зберігаються у єдиному організованому форматі. Вони розкидані по PDF-файлах, документах Word, презентаціях, сканах, веб-сторінках, базах даних, електронних листах та іншому. Процес збору збирає та витягує контент з усіх цих джерел.
Інструменти, призначені для цього, — це Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain та двигуни OCR. OCR є важливим, коли інформація знаходиться всередині сканів чи зображень. Apache Tika витягує текст та метадані з дуже широкого спектру форматів. Microsoft Fabric сприяє розширеним корпоративним процесам обробки даних, а такі фреймворки, як LangChain, дозволяють під’єднувати компоненти збору даних до шляхів обробки інформації за допомогою ШІ.
Мета проста: перетворити розсіяну корпоративну інформацію на контент, який може обробляти машина. Без надійного шару імпорту навіть найскладніші моделі будуть мати труднощі з наданням змістовних відповідей про вашу організацію.
Шар 3: розділення на частини та попередня обробка
Вилучення тексту — це лише початок. Документ обсягом 200 сторінок не можна передавати повністю в кожен запит до моделі, тому великі документи потрібно розділяти на менші, змістовні одиниці. Цими частинами можуть бути абзаци, розділи, сторінки чи семантичні одиниці, а LangChain та подібні фреймворки пропонують кілька стратегій розділення на частини.
Хороше розділення тексту — це не просто розрізання на частини кожні кілька сотень символів, адже погане розділення руйнує контекст. Коли визначення відокремлюється від пояснення, яке надає йому значення, процес пошуку може повернути щось неповне. Частини, які занадто великі, роблять пошук неточним, а частини, які занадто малі, втрачають важливі зв’язки. Тож ця стратегія безпосередньо впливає на якість усього, що відбувається далі.
Попередня обробка включає очищення тексту, видалення зайвого контенту, нормалізацію форматів, вилучення метаданих, виявлення структури документа та доповнення частин тексту додатковою інформацією. Наскільки ефективним буде подальший пошук, часто визначається саме на цьому етапі.
Рівень 4: ембеддинги
Після розділення документів на частини системі потрібен спосіб для опису їхнього значення. Модель ембеддингів перетворює текст на числовий вектор, і схожі концепції опиняються близько одна до одної у просторі ембеддингів.
Порівняйте запит на скидання пароля співробітника з запитом про те, як змінити дані входу на роботу. Формулювання відрізняються, але мета схожа, і хороша модель ембеддингів це розпізнає. Серед постачальників, які використовуються для цього шару, — OpenAI, Cohere та сервіси ШІ на базі Azure. Отримані вектори лежать в основі семантичного пошуку та відтворення інформації, що робить це одним із найважливіших зсувів у цій структурі: людська мова стає математичним представленням, а це представлення забезпечує семантичну схожість.
Шар 5: база даних векторів
Ембеддинги мають зберігатися там, де підтримується швидкий пошук за схожістю, і саме це є завданням бази даних векторів. У діаграмі перелічені Milvus, FAISS, Azure AI Search, Azure Cosmos DB та Azure Database for PostgreSQL. Вони сильно відрізняються за функціоналом та моделлю розгортання, але всі вони спрямовані на ефективне відтворення інформації за допомогою семантичної схожості.
Коли користувач ставить запитання, сам запит перетворюється на ембеддинг, і система шукає найближчі вектори. Потім знайдені фрагменти передаються на наступні шари. Це є основою більшості систем генерації з підтримкою пошуку інформації.
Шар 6: шар пошуку
База даних векторів зберігає інформацію, але саме шар пошуку вирішує, що саме буде показано моделі. Цю різницю легко не помітити. Пошук може ґрунтуватися на семантичній схожості, пошуку за ключовими словами, фільтрації метаданих, гібридному пошуку, переранжуванні та інших методах; інструменти на кшталт Azure AI Search, LangChain та LlamaIndex використовуються для цього.
Зріла система поєднує різні стратегії. Семантичний пошук знаходить матеріали, концептуально пов’язані з запитом, тоді як пошук за ключовими словами гарантує, що точні ідентифікатори, назви продуктів, номери полісів чи технічні терміни не залишаться непоміченими. Це гібридний підхід до пошуку, а корпоративні системи RAG все частіше додають фільтри метаданих, механізми переранжування, графи знань та інші елементи.
Метою не є отримання якомога більшої кількості інформації, а отримання саме правильної інформації.
Рівень 7: інженерія запитів
Після пошуку система має сформувати належну інструкцію для мовної моделі. Промпт для експлуатації — це значно більше, ніж просто запит користувача; він може включати інструкції системи, отриманий контекст, історію розмов, бізнес-правила, вимоги до формату вихідних даних, обмеження щодо безпеки, приклади, визначення інструментів та метадані. LangChain, Promptify та DSPy — це приклади інструментів, які допомагають структурувати та налаштовувати промпти.
Інженерія запитів також виходить за межі ручного створення винахідливих формулювань. Увага зосереджується на інженерії контексту, яка ставить ширше питання: що має отримати модель, у якій структурі та на якому етапі робочого процесу? Це має ще більше значення для агентів, які можуть динамічно формувати контекст на основі попередніх дій, отриманого матеріалу, результатів роботи інструментів та проміжних результатів.
Рівень 8: велика мовна модель
У центрі знаходиться велика мовна модель, де відбувається розуміння мови, міркування, генерація тексту та виконання інструкцій. Серед згаданих платформ та моделей — Azure, OpenAI, LLaMA та Mistral AI. Модель отримує запит разом із ретельно підготовленим контекстом та інструкціями.
Є один принцип, який варто повторити: LLM — це не вся програма. Це лише один компонент у значно більшій системі, а продакшн-застосунок потребує функцій пошуку інформації, оркестрації, забезпечення безпеки, оцінки, моніторингу, інфраструктури та бізнес-логіки, які працюють навколо нього. Це стає особливо помітним під час переходу від прототипу до комерційного продакшну.
Від додатків на основі LLM до агентів
Корисно розрізняти звичайні додатки на основі LLM та додатки з використанням агентів. У базовому додатку виконуються кроки: користувач, запит, LLM, відповідь. У додатку типу RAG — користувач, пошук інформації, контекст, LLM, відповідь. Система з агентами є набагато більш динамічною: користувач, агент, планування, пошук інформації, інструменти, LLM, оцінка, подальші дії, кінцева відповідь. Агент сам вирішує, що робити далі, а не просто дотримується фіксованої послідовності дій.
Припустимо, хтось запитує, чому вчора зламався процес виробництва та що з цим робити. Агент може отримати історію виконання, переглянути журнали, здійснити запити до баз даних, проаналізувати повідомлення про помилки, ознайомитися з правилами експлуатації, визначити ймовірну причину та, можливо, запропонувати або застосувати схвалене рішення. Це принципово відрізняється від створення простого абзацу тексту.
Рівень 9: інфраструктура та розгортання
Добре опрацьований прототип не робить продукт готовим до використання в середовищі виробництва. Для запуску потрібна масштабована інфраструктура, мережеві рішення, засоби безпеки, автоматизація розгортання, керування ресурсами та стійкість системи. Архітектура включає Azure Container Apps, Azure Kubernetes Service, Docker та Kubernetes.
Docker упаковує додатки у портативні контейнери. Kubernetes координує роботу контейнеризованих завдань у розподілених середовищах. Azure Kubernetes Service — це керована версія Kubernetes, а Azure Container Apps спрощує розгортання контейнерів, не вимагаючи керування всім середовищем Kubernetes.
Цей рівень має велике значення, коли система мусить справлятися з великим трафіком користувачів, багатьма одночасними завданнями агентів, навантаженням від інференції моделей, фоновою обробкою, потоками обробки документів, довготривалими завданнями, інтеграцією з зовнішніми інструментами та вимогами до корпоративної безпеки. Модель може бути чудовою, але саме інфраструктура визначає, чи може ця чудовість бути надана надійно в масштабах.
Рівень 10: спостережуваність та оцінка
Спостережуваність є однією з найбільш занедбаних складових інженерії ШІ. Традиційні додатки можна відстежувати за використанням CPU, оперативною пам’яттю, затримками, помилками та частотою запитів. Додатки ШІ потребують більшого. Командам необхідно бачити, що отримав модель, що було знайдено, які інструменти використовувалися, які рішення були прийняті, тривалість кожного кроку, кількість токенів та чи допомогла кінцева відповідь.
Тут на допомогу приходять Azure AI Foundry, OpenTelemetry та Grafana. OpenTelemetry збирає телеметричні дані з розподілених додатків, а Grafana візуалізує метрики роботи та рівня додатку.
Оцінка є ще одним виміром. Системи в промисловому використанні можуть потребувати оцінок за релевантністю, обґрунтованістю, наявністю галюцинацій, якістю пошуку, затримками, витратами, безпекою та задоволеністю користувачів. Агенти підвищують стандарти, оскільки їхні дії також потребують оцінки разом із кінцевою відповіддю:
- Чи обрав він правильний інструмент?
- Чи отримало воно правильну інформацію?
- Чи здійснювало воно зайві виклики інструментів?
- Чи дотримувалося воно правильної схеми роботи?
- Чи зупинилося воно після завершення завдання?
- Чи передало воно ситуацію належним чином, коли знадобився людський оператор?
Ці запитання роблять спостережуваність та оцінку невід’ємною частиною роботи з ШІ в промислових умовах.
Чому важлива вся структура
Поширеним хибним уявленням є те, що створення ШІ-додатку означає вибір потужного LLM та додавання інтерфейсу користувача. Це може підійти для демонстрації, але рідко відображає те, що потрібно для корпоративної платформи ШІ.
Уявімо собі співробітника, який запитує асистента щодо політики організації щодо вирішення певної проблеми клієнта. Система має зрозуміти запит, знайти відповідні документи з політикою, виокремити релевантні розділи, надати їх моделі, сформулювати обґрунтовану відповідь, можливо, навести джерело, дотримуватися правил безпеки, стежити за взаємодією та оцінити, чи була відповідь корисною. Кожен рівень відіграє свою роль: фронтенд забезпечує взаємодію, процес отримання даних — знання, попередня обробка робить їх придатними для використання, ембеддинги фіксують значення, векторні бази даних зберігають пошукові представлення, механізми пошуку знаходять контекст, інструкції структурують інформацію, ШІ генерує відповідь, інфраструктура забезпечує масштабованість та надійність, а можливість спостереження забезпечує прозорість та відповідальність. У цьому сенсі сучасний ШІ є повнофункціональним.
Вибір інструментів
Технології, описані в моделі архітектури, — це не список товарів, які потрібно повністю прийняти. Кожна з них є одним із варіантів для свого шару. Компанія може спочатку обрати React та Next.js, Azure AI Content Understanding для обробки документів, LangChain для координації процесів, хостовану модель ембеддингу, Azure AI Search для пошуку інформації, модель, яка працює на платформі Azure, та Azure Container Apps для її запуску. Інша компанія може обрати зовсім інший набір технологій.
Найважливіший урок полягає у тому, що архітектура передує інструментам. Бізнес-вимоги формують архітектуру, архітектура визначає функціональні можливості, необхідні кожному шару, і лише після цього слід обирати конкретні технології.
Більше, ніж просто LLM
Повний погляд на архітектуру також пояснює, чому проекти з використанням агентів швидко ускладнюються. Агенту може знадобитися корпоративні знання через RAG, структуровані дані з баз даних, зовнішня інформація через API, операційні можливості за допомогою інструментів та виконання робочих процесів через системи оркестрації. Йому також потрібні механізми контролю: автентифікація та авторизація, заходи захисту приватності даних, захист від вставки команд, права доступу до інструментів, кроки людського схвалення, журнали аудиту та системи оцінки.
Отже, штучний інтелект у форматі агентів існує на перетині кількох галузей: інженерії програмного забезпечення, інженерії даних, інженерії ШІ, інженерії хмарних технологій, безпеки та можливостей моніторингу. Створення агентів промислового рівня є інженерною задачею, а не просто вправою у написанні команд.
Як еволюціонувала архітектура додатків
Індустрія пройшла кілька етапів розвитку. Ранні застосунки ШІ були орієнтовані на моделі. Потім технологія RAG поєднала моделі з зовнішніми джерелами знань. Системи з додатковими інструментами дозволили моделям взаємодіяти з зовнішніми ресурсами. Зараз агентні системи ШІ поєднують моделі, механізми пошуку інформації, інструменти, пам’ять, планування, оркестрацію та оцінку. Розвиток відбувається від простих LLM до RAG, потім до використання інструментів, далі до агентів та багатоагентних систем, і у міру подальшого розвитку інфраструктура, яка їх підтримує, стає все важливішою.
З чого почати
Не кожному додатку потрібен весь набір технологій. Для простого інструменту для ставлення запитань та відповідей може вистачити базового LLM. Якщо додатку потрібні приватні дані або інформація, яка часто змінюється, слід додати RAG. Коли ключовим елементом проблеми є зв’язки між ентитетами, варто розглянути пошук на основі графів. Якщо система має планувати завдання, обирати інструменти, виконувати кілька кроків та приймати рішення в реальному часі, то агентський ШІ стане кращим вибором.
Метою не повинна бути найскладніша архітектура — це має бути найпростіша, яка надійно вирішує проблему.
Що далі
Ця галузь все ще розвивається. Графи знань, векторні бази даних, фреймворки агентів, двигуни робочих процесів, багатомодальні моделі, інструменти оцінки та хмарні платформи, ймовірно, будуть все більше поєднуватися між собою. Додатки будуть приймати не лише текст, а й зображення, аудіо, відео, структуровані дані, корпоративні системи та реальні робочі процеси. Спостереження та оцінка системи будуть мати таке ж важливе значення, як і вибір її моделі. Майбутнє полягає не стільки у самісіньких більш розумних моделях, скільки у надійних системах, побудованих навколо них.
Висновок
Агентський ШІ — це не одна технологія, а цілий комплекс. Від фронтенду, через який взаємодіють користувачі, до процесів обробки даних, створення ембеддингів та використання векторних баз даних, механізмів пошуку та формулювання запитів, аж до ШІ на основі великих мовних моделей, їх розгортання та моніторингу — кожен етап формує рівень інтелекту, який в кінцевому підсумку демонструє система. ШІ на основі великих мовних моделей є лише однією частиною. Система агентського типу промислового рівня потребує правильних даних, стратегії пошуку, механізмів координації, інфраструктури та систем оцінки. Ступінь здатності моделей має менше значення, ніж якістю проектування систем, які їх оточують.
Пов’язана література
- Веб-стек для стартапів у епоху AI-агентів: Next.js, MUI та Firebase — Які інструменти залишаються ефективними, коли агенти пишуть більшу частину коду: Next.js, MUI, Firebase, Vercel, PostHog та мінімальна налаштування агента, з поясненням причин вибору кожного з них.
- Що знаходить агент для порівняння моделей: зміни стилю переважають над незначними корективами — Аудитор з чорною скринькою порівняв базову модель із фінансовим LoRA: 82% випробувань виявили зміни у довжині та структурі, тоді як заплановані зміни в логіці прийняття рішень залишилися непоміченими.