LangGraph та FastAPI: як створити чат-бота у форматі мікросервісу

В останні роки екосистема інструментів для розробки застосунків зі штучним інтелектом стрімко розвивається. Одним із найпомітніших прикладів є LangChain – фреймворк, який зробив роботу з великими мовними моделями (LLM) більш структурованою та доступною. Проте, як це часто буває з популярними технологіями, з часом проявилися й певні обмеження. На зміну прийшов новий підхід LangGraph, який пропонує свіжий погляд на створення складних інтерактивних систем.

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

Що таке LangChain

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

Ключові можливості LangChain:

• Підключення до API моделей і векторних баз даних.
• Організація конвеєрів обробки.
• Керування пам’яттю (memory) для збереження контексту діалогу.
• Підтримка інструментів пошуку та вилучення даних.

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

Ланцюги дозволяють будувати лінійні сценарії взаємодії з моделлю. Але саме ця лінійність є їхнім головним недоліком.

Проблематика LangChain у чат-ботах

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

Основні проблеми:

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

LangGraph

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

Переваги LangGraph:

• Гнучкі сценарії: легке моделювання складних розгалужень, циклів та умовних переходів.
• Керування станом: вбудовані механізми збереження прогресу та відновлення виконання.
• Human-In-The-Loop: можливість вбудувати етапи, де рішення приймає людина.
• Очікування та асинхронність: виконання можна призупинити та відновити пізніше.

Платформа підтримує не тільки графову, але й функціональну парадигму розробки: можна задіяти керування станом (state‑менеджмент), human‑in‑the‑loop, механізм “подорожі в часі” (time travel), стримінг відповідей і збереження Durable execution навіть без явного опису графа – все це завдяки легкому та гнучкому функціональному API, який добре інтегрується в різні застосунки.

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

Human-In-The-Loop

Однією з ключових можливостей LangGraph є підтримка Human-In-The-Loop (HITL). У контексті чат-бота це означає, що на певному етапі бот може передати контроль людині, дочекатися відповіді або підтвердження, і тільки потім продовжити виконання графа.

Приклади використання:

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

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

Стани та сесії в LangGraph

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

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

Це дозволяє:

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

Архітектура мікросервісу чат-бота

Клієнт (веб або мобільний застосунок, або будь-який бекенд) надсилає звичайний POST-запит до шлюзу FastAPI з повідомленням користувача та ідентифікаторами сесії/користувача. На межі ми перевіряємо вхідні дані і відразу готуємо відповідну модель: або повертаємо готовий текст, якщо гілка виконання коротка, або миттєво видаємо підтвердження з message_id, щоб клієнт міг пізніше отримати остаточний результат (‘GET /messages/{id}’).

Ядром сервісу є скомпільований LangGraph. Кожен виклик отримує збережений знімок стану з постійного сховища за ключем сесії, виконує кілька “кроків” графа і знову робить чекпойнт. Якщо сценарій простий і вкладається в час очікування запиту, ми формуємо відповідь відразу і повертаємо її синхронно. Якщо задіяно багато кроків або “довготривалих” інструментів, FastAPI після базової перевірки і запису завдання негайно відповідає клієнту, а продовження логіки триває у фоновому режимі. У цьому випадку відмінно працює вбудований механізм фонових завдань FastAPI: операція продовжує виконуватися вже після того, як клієнт отримав HTTP-відповідь, що запобігає блокування інтерфейсу і знімає навантаження по тайм-аутах. Для простих сервісів цього достатньо, не вдаючись до черг і воркерів; при зростанні навантаження можна замінити вбудований фон на зовнішній раннер, не змінюючи контрактів.

Стан – це ключ до передбачуваності та стійкості. LangGraph зберігає знімок (checkpointer) після кожного значущого кроку і завдяки “durable execution” може відновитися саме з того місця, де зупинився – через перезапуск контейнера, збій зовнішнього сервісу чи навмисну паузу HITL. Це усуває необхідність у самописних “машинах станів” і робить довгі діалоги відтворюваними: ми не програємо гілку заново і не втрачаємо контекст, а просто продовжуємо. Для простого варіанту достатньо одинарного постійного сховища для чекпойнтів (SQL/NoSQL – за вимогами), при цьому сам принцип “збереглося → продовжив” вбудований в бібліотеку.

При внутрішньому виконанні важливо збалансувати синхронні та асинхронні операції. FastAPI підтримує обидва варіанти, але блокуючі операції (наприклад, зовнішні HTTP-запити, I/O) краще або переносити у фон відразу після швидкої відповіді клієнту, або викликати в неблокуючому режимі, щоб не навантажувати воркерів під час очікування. Це забезпечує стабільність служби: клієнт не повинен чекати, поки попередній запит закінчить повільну обробку, наприклад, ланцюга промптів.

Результатом є стабільний конвеєр: клієнт надсилає запит у звичайний HTTPS-маршрут, сервіс перевіряє його і або відразу повертає готову відповідь, або надсилає підтвердження і продовжує кроки графа у фоновому режимі; кожен важливий крок фіксується в постійному сховищі, тому будь-який збій або пауза буде оброблятися коректно; участь людини запускається через HTTP без підтримки постійних з’єднань. Такий дизайн не вимагає незвичайних шаблонів інфраструктури і легко розробляється для більшості проєктів і завдань.

Підсумок

LangGraph у поєднанні з FastAPI забезпечує надійну та гнучку основу для створення production-ready чат-ботів. LangGraph виводить організацію логіки взаємодії на новий рівень, дозволяючи проєктувати діалоги у формі графів, а не лінійних ланцюгів, та забезпечуючи вбудований контроль стану і можливість відновлення виконання через механізм durable execution. Це дозволяє створювати діалогові системи з розгалуженнями, циклами, Human‑In‑The‑Loop і стійкістю до збоїв, на відміну від LangChain, де подібні сценарії важче підтримувати.

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

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

Микола Андрющенко, ML-інженер