LangGraph vs LangChain українською: що коли

«LangGraph vs LangChain» — питання, на якому плутаються майже всі, хто тільки заходить у тему агентів. І не дивно: назви схожі, команда одна, документація переплетена. Але це не конкуренти і не дві версії одного й того ж. LangChain — широкий тулкіт. LangGraph — вузький шар оркестрації станів поверх нього. Розберемо різницю чесно, без маркетингу, і скажемо, що коли брати.

Коротка відповідь у двох реченнях

LangChain — це набір будівельних блоків: обгортки над моделями, лоадери документів, ретривери, парсери, інтеграції, ланцюжки (chains). Він відповідає на питання «як зібрати LLM-застосунок зі стандартних деталей». LangGraph — це окрема бібліотека від тієї ж команди, яка відповідає на питання «як керувати агентом, що має цикли, стан і паузи». Перше — про деталі, друге — про оркестрацію складної поведінки.

Якщо ви вже читали вступ до LangGraph українською → — там я розбирав, що таке StateGraph і коли граф кращий за голий SDK. Тут не повторюватимусь: фокус саме на парі LangChain vs LangGraph і на тому, де проходить межа між ними.

Що таке LangChain насправді

LangChain зʼявився як відповідь на біль раннього 2023-го: кожен писав одне й те саме руками — промпт-шаблони, виклик моделі, парсинг відповіді, підтягування контексту з документів. LangChain зібрав ці патерни в одну екосистему. Сьогодні це насамперед:

• Інтеграції. Сотні готових конекторів — моделі (OpenAI, Anthropic, локальні), векторні бази, лоадери для PDF, сайтів, Notion, баз даних. Це найсильніша частина: не писати обгортки самому.
• Chains (ланцюжки). Лінійні послідовності кроків: промпт → модель → парсер. Через LCEL (LangChain Expression Language) вони складаються в один пайплайн оператором |.
• Ретривери та RAG. Готові цеглинки для пошуку по документах і підстановки контексту в промпт. Класичний RAG на LangChain збирається за вечір.
• Парсери та схеми. Витягування структурованого виходу (JSON, Pydantic-моделі) з відповіді LLM без ручної регулярки.

Ключова теза: LangChain чудовий для лінійних і слабко розгалужених сценаріїв. Ланцюжок — це труба: дані заходять з одного кінця, виходять з іншого. Поки логіка тече в один бік, LangChain економить вам тижні.

Де LangChain починає тріщати

Проблеми вилазять, щойно агенту треба повертатися назад. Класичний ланцюжок не вміє елегантно робити цикл «спробуй → перевір → переробляй». В оригінальному LangChain для цього був AgentExecutor — чорна скринька, яка крутила власний цикл міркувань усередині. На простих кейсах він працював, але щойно треба було втрутитися в логіку переходів, додати паузу на людину чи зберегти стан — починалися милиці.

Саме тому команда LangChain і випустила LangGraph окремо. Це було чесне визнання: ланцюжкова модель не тягне складну агентну поведінку. Потрібен був явний граф, де переходи видно, а стан керований. Так зʼявився чіткий поділ: LangChain лишився тулкітом деталей, LangGraph став шаром оркестрації.

Що таке LangGraph і чим він інший

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

• Цикли. Ребро може вести вузол сам у себе — агент повторює спробу, поки не пройде валідацію.
• Persistence. Checkpointer пише стан у Postgres чи Redis. Процес переживає рестарт сервера і продовжує з місця зупинки.
• Human-in-the-loop. Граф паузиться на вузлі, чекає підтвердження людини, потім іде далі з того ж стану.

Найважливіше, що багатьох дивує: LangGraph не вимагає LangChain. Усередині вузла ви можете кликати голий OpenAI чи Anthropic SDK — і ніколи не торкатися ланцюжків. Можна й навпаки: брати інтеграції LangChain (лоадери, ретривери) усередині вузлів LangGraph-графа. Вони композуються, але не залежать одне від одного жорстко.

Різниця в коді: chain проти StateGraph

Найкоротший спосіб відчути різницю — побачити те саме завдання у двох стилях. Спершу простий LangChain-ланцюжок: промпт → модель → парсер. Це труба в один бік.

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

prompt = ChatPromptTemplate.from_template(
    "Поясни коротко: {question}"
)
model = ChatOpenAI(model="gpt-4o-mini")

# LCEL: кроки складаються оператором |
chain = prompt | model | StrOutputParser()

answer = chain.invoke({"question": "Що таке LangGraph?"})

Чисто, читабельно, нуль зайвого. Але тут немає циклу, гілки чи паузи — дані просто проходять наскрізь. Тепер те саме завдання, але з умовою «якщо відповідь слабка — спробуй ще раз», на LangGraph:

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class State(TypedDict):
    question: str
    answer: str
    tries: int

def call_model(state: State) -> dict:
    reply = model.invoke(state["question"]).content
    return {"answer": reply, "tries": state["tries"] + 1}

def is_good(state: State) -> str:
    # умовне ребро: цикл назад або вихід
    if "не знаю" in state["answer"] and state["tries"] < 3:
        return "retry"
    return "done"

graph = StateGraph(State)
graph.add_node("call_model", call_model)
graph.add_edge(START, "call_model")
graph.add_conditional_edges(
    "call_model", is_good, {"retry": "call_model", "done": END}
)

app = graph.compile()
result = app.invoke({"question": "Що таке LangGraph?", "tries": 0})

Бачите різницю? Ланцюжок — це вираз, який тече зліва направо. Граф — це машина станів: retry веде вузол сам у себе, done веде в END. Якщо ваша логіка вкладається в один прохід — перший варіант коротший і чесніший. Якщо зʼявляються повтори, гілки чи паузи — другий не перетворюється на стіну if-ів.

LangChain vs LangGraph: таблиця

Зверніть увагу: рядки в колонках не суперечать одне одному. Це не «або-або», а «де чий інструмент». RAG живе в LangChain. Оркестрація агента, що той RAG викликає, — у LangGraph.

Коли їх варто поєднати

Найчастіший реальний сценарій — не вибір, а композиція. LangGraph керує процесом на верхньому рівні, а всередині окремих вузлів ви викликаєте цеглинки LangChain. Типова звʼязка для support-агента з базою знань:

• Вузол «класифікувати запит» — простий LangChain-ланцюжок зі структурованим виходом.
• Вузол «знайти контекст» — ретривер LangChain поверх векторної бази (це і є RAG-частина).
• Вузол «відповісти» — виклик моделі з підтягнутим контекстом.
• Умовні ребра, цикл «уточнити, якщо контексту мало», пауза на менеджера для складних кейсів — усе це оркеструє LangGraph.

Тобто межа проста: LangChain — це «з чого зробити вузол», LangGraph — це «як зʼєднати вузли в процес зі станом». Коли задача доростає до кількох агентів, що передають роботу одне одному, ця композиція стає обовʼязковою — деталі розклав у статті про multi-agent системи →

Чесно: більшості простих застосунків LangGraph не треба

Скажу прямо, бо це економить клієнтам гроші. Якщо ваш продукт — це чат над документами, бот, що відповідає на FAQ, або генератор текстів за шаблоном, вам достатньо LangChain (а часто й голого SDK). Граф тут — церемонія заради церемонії: ви платите складністю за можливості, якими не користуєтесь.

LangGraph починає окуповуватись, коли у процесі зʼявляється хоча б одне з трьох: цикл, що повертається назад; пауза на рішення людини; стан, який треба пережити рестарт. Поки нічого з цього немає — ланцюжок чесніший. Фреймворк має зʼявлятися від болю, а не «на виріст».

Поширені помилки вибору

1. Думати, що LangGraph замінює LangChain. Ні. Він над ним (або поруч). Інтеграції та ретривери ви все одно частіше берете з LangChain.
2. Тягнути LangGraph у простий RAG. Пошук по документах — лінійний потік. Граф тут нічого не дає, лише додає рухомих частин.
3. Боятися брати LangGraph без LangChain. Можна писати вузли на голому SDK. Якщо вам не потрібні чужі абстракції — не беріть їх, граф від цього не постраждає.
4. Лишатися на старому AgentExecutor для складних агентів. Якщо у вас цикли й гілки на ланцюжках — це той самий біль, від якого сама команда LangChain пішла в граф. Не повторюйте цей шлях.

Як обрати: короткий тест

Обери LangChain, якщо у тебе RAG, лінійний пайплайн або потрібні готові інтеграції та лоадери, а логіка тече в один бік без повернень. У 70% продуктових кейсів цього вистачає.

Обери LangGraph, якщо зʼявилися цикли, гілки, паузи на людину, persistence стану або кілька агентів, що передають роботу. Тоді граф окупиться вже на першому серйозному дебагу.

Поєднай обидва, якщо агент керує складним процесом (LangGraph), але всередині вузлів спирається на RAG та інтеграції (LangChain). Це найтиповіший продакшн-варіант.

Саме таку архітектуру — граф для оркестрації плюс правильні цеглинки всередині вузлів — я проєктую й будую в рамках розробки multi-agent систем → від вибору стека до деплою й моніторингу.

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

Написати @tribeofdanel →