Что такое LangChain и LangGraph?
LangChain и LangGraph - открытые фреймворки на Python (и с поддержкой JavaScript) для сборки приложений на больших языковых моделях: от простого RAG до ИИ-агентов с инструментами, памятью и ветвлением сценариев. LangChain даёт строительные блоки (модели, промпты, цепочки, ретриверы), LangGraph - граф состояний для сложных агентных потоков, где нужен контроль, циклы и человеческое подтверждение. Ниже - чем они отличаются, когда какой взять и на что смотреть бизнесу.
- LangChain - библиотека компонентов: LLM, промпты, цепочки, эмбеддинги, векторный поиск, инструменты
- LangGraph - оркестрация через граф узлов: состояние, ветки, циклы, retry, human-in-the-loop
- Цепочка (chain) - фиксированный пайплайн «вход → шаги → ответ»
- Агент - модель сама решает, какой инструмент вызвать и когда остановиться
- Не замена модели - фреймворк не делает GPT/Claude «умнее»; он помогает связать API, данные и логику
- Практика - простой RAG и FAQ часто хватает LangChain; сложные маршруты поддержки и мультиагентность - зона LangGraph
Что такое LangChain простыми словами
Один вызов API модели - это «спросили → ответили». Реальный продукт обычно шире: подтянуть документы из базы знаний, вызвать CRM, проверить заказ, сохранить историю, посчитать токены и не дать модели галлюцинировать «из головы».
LangChain - это набор абстракций поверх провайдеров (OpenAI, Anthropic, Gemini, локальные LLM и др.), чтобы не писать один и тот же glue-код руками:
| Компонент | Зачем нужен |
|---|---|
| Chat model / LLM | Единый интерфейс к разным API |
| Prompt templates | Промпты с переменными и ролями (system/user) |
| Retrievers | Поиск релевантных фрагментов для RAG |
| Tools / functions | Вызов внешних API, БД, калькуляторов |
| Memory | История диалога и краткосрочный контекст |
| Output parsers | Превращение ответа модели в JSON/структуру |
Типичный сценарий на LangChain: пользователь спрашивает → ретривер находит куски документации → промпт склеивает вопрос + контекст → модель отвечает со ссылкой на источники. Это классический RAG, и для многих бизнес-кейсов его достаточно.
Что такое LangGraph и чем он дополняет LangChain
LangGraph - библиотека от той же экосистемы LangChain для построения агентных приложений как графа: узлы (nodes) выполняют шаги, рёбра (edges) задают переходы, есть общее состояние (state), которое обновляется по ходу.
Зачем граф, если есть цепочки:
- Ветвление - если уверенность низкая → эскалация человеку; если клиент просит возврат → другой сценарий.
- Циклы - агент вызывает инструмент, читает результат, думает ещё раз, снова вызывает инструмент.
- Контроль - явные точки остановки, retry, лимиты шагов; меньше «чёрного ящика».
- Мультиагентность - несколько ролей (исследователь, редактор, модератор) передают результат друг другу.
- Human-in-the-loop - перед отправкой письма клиенту или списанием денег система ждёт подтверждения оператора.
Упрощённо: LangChain = детали конструктора, LangGraph = схема сборки сложного механизма. Их часто используют вместе: узлы графа внутри вызывают модели, ретриверы и инструменты из экосистемы LangChain.
LangChain vs LangGraph: когда что выбирать
| Задача | Обычно достаточно | Лучше смотреть в сторону |
|---|---|---|
| FAQ / RAG по базе знаний | LangChain (+ векторная БД) | LangGraph, если много веток и эскалаций |
| Один фиксированный пайплайн (summarize → translate) | LangChain | - |
| Агент с tools и циклами «подумал → вызвал → проверил» | LangChain Agent или LangGraph | LangGraph при росте сложности |
| Поддержка с маршрутизацией тикетов | Можно стартовать на цепочках | LangGraph для статусов и human-approve |
| Несколько агентов и долгие задачи | Сложно на чистых chains | LangGraph |
Правило на практике: начните с самого простого пайплайна. Если логика уже похожа на блок-схему с условиями и циклами - переходите на граф, а не наращивайте «цепочку из if-ов в одном файле».
Как выглядит типичный стек
Минимальный рабочий набор для бизнеса:
- Модель - GPT / Claude / Gemini или локальная через Ollama;
- LangChain - промпты, ретривер, tools;
- Векторное хранилище - для эмбеддингов и поиска по знаниям;
- LangGraph (по необходимости) - оркестрация агента и веток;
- Наблюдаемость - логи шагов, latency, стоимость токенов, трассировка ошибок;
- Интеграции - CRM, helpdesk, Telegram-бот, внутренняя БД.
Важно: фреймворк не заменяет чистые данные и продукт. Плохая база знаний + сильный LangGraph всё равно даст слабые ответы. Оценка стоимости RAG-системы и ИИ-агента под ключ почти всегда упирается в данные, интеграции и контроль качества, а не только в выбор библиотеки.
Плюсы и минусы для проекта
Плюсы:
- быстрый старт прототипа на Python;
- готовые интеграции с популярными LLM и векторными БД;
- единый стиль кода для промптов, tools и RAG;
- LangGraph даёт явную схему агента - проще объяснять заказчику и отлаживать;
- экосистема развита, много примеров и документации.
Минусы и риски:
- abstraction tax: новичок может «утонуть» в слоях, хотя хватило бы 50 строк прямого API;
- API экосистемы меняется - пинить версии и следить за breaking changes;
- агенты с циклами легко разгоняют расход токенов без лимитов;
- без тестов и evals продукт деградирует незаметно;
- не каждый бизнес-сценарий нуждается в агенте - часто лучше детерминированный скрипт + LLM на одном шаге.
Когда бизнесу это нужно - и когда рано
Имеет смысл, если вы:
- строите RAG, ассистента или агента поверх своих данных и API;
- команда уже пишет на Python/JS и хочет стандартный каркас, а не ad-hoc скрипты;
- нужны ветки, подтверждение человека и долгие многошаговые сценарии (LangGraph);
- планируете сопровождать продукт месяцами - явная архитектура окупается.
Можно отложить, если:
- задача решается одним-двумя вызовами API с хорошим промптом;
- нет стабильной базы знаний и интеграций - фреймворк не спасёт пустые данные;
- команда ещё не освоила базовый вызов LLM и эмбеддинги;
- нужен только no-code чатбот без кастомной логики.
Итог
LangChain - способ собирать LLM-приложения из готовых блоков: модели, промпты, RAG, инструменты. LangGraph - способ оркестрировать сложную логику агентов как граф состояний с ветками, циклами и контрольными точками. Для FAQ и поиска по документам часто хватает LangChain; для агентов поддержки, мультишаговых процессов и human-in-the-loop разумнее сразу проектировать поток на LangGraph. Выбор библиотеки вторичен относительно качества данных, метрик и бюджета на токены - но правильный каркас экономит месяцы хаоса в коде.
Часто задаваемые вопросы
LangChain и LangGraph - это разные продукты или одно целое?
Это связанная экосистема: LangChain даёт компоненты, LangGraph - оркестрацию сложных потоков. Их можно использовать по отдельности, но на практике узлы графа часто вызывают модели и tools из LangChain. Думайте не «или-или», а «блоки + схема», когда сценарий усложняется.
Нужен ли LangGraph для обычного RAG?
Не обязательно. Классический RAG (вопрос → поиск → ответ) спокойно делается на LangChain или даже на прямых вызовах API + векторной БД. LangGraph имеет смысл, если поверх RAG появляются ветки, переспрашивание, несколько агентов, проверка фактов в цикле или обязательное подтверждение человека.
Чем агент на LangGraph отличается от «просто вызвать ChatGPT»?
Один вызов ChatGPT - это ответ модели в рамках одного контекстного окна. Агент на LangGraph может многократно вызывать инструменты, обновлять состояние, ветвиться по условиям и останавливаться на проверке оператором. Это ближе к workflow-движку с LLM внутри, чем к обычному чату.
На каком языке лучше писать - Python или JavaScript?
Для бэкенда, data-pipeline и большинства примеров экосистемы чаще берут Python. JavaScript/TypeScript удобен, если агент живёт рядом с Node-стеком сайта. Функционально подходы похожи; выбирайте язык команды и того сервиса, куда встраиваете LLM.
Сколько стоит внедрение на LangChain / LangGraph?
Сам фреймворк open source - платите за API моделей, инфраструктуру (векторная БД, хостинг) и разработку/сопровождение. Прототип RAG может уложиться в дни и небольшой бюджет на токены; продакшен-агент с CRM, мониторингом и evals - уже проект на недели и заметный бюджет на агента. Главный скрытый расход - бесконтрольные циклы агента и раздутый контекст.