LangChain или LlamaIndex: что выбрать для RAG и AI-агента

Раздел

AI-агенты для бизнеса

Сложность

средняя

Обновлено

2026-05-20

Короткий ответ

Если задача в основном про данные, документы, индексацию, retrieval и RAG, чаще начинайте с LlamaIndex или с простого собственного pipeline. Если задача про управляемый agent workflow, tools, состояния, ветвления и многошаговые действия, смотрите LangChain вместе с LangGraph. Если команда еще не доказала сценарий, не начинайте с большого фреймворка вообще.

Правильный вопрос не “что мощнее”, а “какая часть системы сложная именно у нас”: поиск по знаниям, orchestration агента, интеграции, права, наблюдаемость, evals или эксплуатация. Фреймворк должен закрывать реальную сложность, а не добавлять архитектуру ради архитектуры.

Для контекста полезны статьи RAG система, создание AI-агента и векторная база для RAG.

Разные центры тяжести

LangChain вырос как общий набор компонентов для LLM-приложений: модели, tools, retrieval, агенты, интеграции. Для управляемых агентов важную роль играет LangGraph: графы состояния, шаги, переходы, checkpointing и более явное управление процессом.

LlamaIndex сильнее воспринимается как data framework: загрузка документов, индексы, retrieval, query engines, agents поверх данных. Он часто удобен, когда основной продуктовый риск - найти правильный контекст и ответить по нему.

В официальной документации LangChain полезно отдельно читать overview и retrieval, потому что “используем LangChain” может означать разные слои. Для stateful agent workflow смотрите LangGraph. Для data-first подхода начните с концепций LlamaIndex.

Но граница не абсолютная. LangChain умеет RAG, LlamaIndex умеет agents. Поэтому выбирайте по рабочему сценарию, навыкам команды и тому, какую часть вы готовы сопровождать сами.

Когда выбирать LangChain и LangGraph

LangChain и LangGraph уместны, если у вас много действий и явная логика процесса. Например: агент принимает заявку, проверяет CRM, вызывает несколько tools, задает уточняющий вопрос, ждет человека, возвращается к задаче, пишет результат в систему.

Сценарии, где LangGraph особенно полезен:

• многошаговый workflow;
• несколько веток и состояний;
• long-running agent;
• human-in-the-loop;
• tool calling с ограничениями;
• повторяемые graph transitions;
• необходимость трассировать шаги.

Если процесс можно нарисовать как граф, где важно понимать, почему агент перешел из одного состояния в другое, LangGraph часто лучше хаотичного “агент сам решит”.

Риск - переусложнение. Для простого RAG по базе знаний полноценный graph может быть лишним. Сначала проверьте, что без него действительно трудно.

Когда выбирать LlamaIndex

LlamaIndex стоит рассматривать, если главная работа связана с данными: загрузить документы, сохранить структуру, построить индекс, настроить retrieval, показать источники, улучшать качество поиска.

Хорошие сценарии:

• корпоративная база знаний;
• поиск по документации;
• RAG по договорам и регламентам;
• ingestion из разных источников;
• работа с метаданными документов;
• сравнение retrieval-стратегий;
• ответы с источниками.

Если бизнес-задача звучит как “мы не можем надежно отвечать по своим документам”, начинайте с корпуса, индексации и eval-набора. В таком проекте orchestration агента может появиться позже.

Риск LlamaIndex тот же: можно слишком рано уйти в сложные индексы, когда проблема в документах, правах или отсутствии тестовых вопросов.

Когда не нужен ни один

Для пилота иногда лучше написать простой код: загрузить 20 документов, нарезать chunks, положить embeddings в выбранное хранилище, сделать поиск, вызвать модель, показать источники. Это дает понимание данных и ошибок без слоя абстракций.

Фреймворк не нужен на первом дне, если:

• один источник данных;
• один тип запроса;
• нет agent workflow;
• мало интеграций;
• команда еще не знает критерии качества;
• нужно быстро проверить спрос.

Но не путайте простой старт с вечным самописом. Когда появляются права, обновления, evals, трассировка, несколько источников и долгоживущий продукт, фреймворк может сэкономить сопровождение.

Матрица выбора

Выбор фреймворка не отменяет архитектуру безопасности. Права, audit log, источники, отказ без данных и ручное подтверждение должны быть спроектированы отдельно.

Минимальная схема, которую стоит нарисовать до выбора:

RAG-first:
  source docs -> chunking -> index -> retriever -> answer with sources -> eval

Agent-first:
  user task -> state graph -> tool policy -> tool calls -> human approval -> write back

Условный LangGraph-flow для CRM-агента:

classify_request -> retrieve_customer -> draft_action
  -> if risky: human_review
  -> else: write_internal_note
  -> summarize_trace

Условный LlamaIndex-flow для RAG:

load_documents -> build_nodes_with_metadata -> create_index
  -> retrieve_allowed_sources -> synthesize_answer_with_citations
  -> run_retrieval_eval

Если ваша схема ближе к первому блоку Agent-first, выбирайте orchestration осознанно. Если ближе к RAG-first, сначала решите качество корпуса, metadata и eval.

Evals и наблюдаемость

Перед выбором стека соберите тестовый набор. Для RAG это вопросы, правильные источники, документы без ответа и проверки прав. Для агента - задачи, ожидаемые tool calls, запрещенные действия, признаки handoff и критерии успеха.

Сравнивайте не только качество финального ответа. Смотрите:

• правильность retrieval;
• корректность tool selection;
• число лишних шагов;
• latency;
• стоимость;
• читаемость trace;
• простоту отладки;
• объем кода вокруг фреймворка.

Если фреймворк помогает увидеть ошибку быстрее, это реальная ценность. Если он прячет ошибку за магией и требует читать исходники, ценность ниже.

Команда и сопровождение

Учитывайте не только разработку, но и сопровождение. Кто будет обновлять dependencies, читать changelog, разбирать breaking changes, писать evals, исправлять prompts и объяснять поведение агентного workflow владельцу бизнеса?

Для маленькой команды лучше меньше слоев. Для команды с несколькими AI-сценариями общий фреймворк может окупиться: единые patterns, tracing, evals, logging и повторяемая структура tools.

Не выбирайте стек только потому, что он популярен в демо. Выбирайте тот, который команда сможет поддерживать через полгода, когда появятся странные ошибки, устаревшие документы и новые требования по правам.

Чеклист выбора

• Описан основной сценарий: RAG, agent workflow или оба.
• Есть тестовый набор до выбора фреймворка.
• Понятно, где применяются права доступа.
• Измеряются retrieval, tool calls, latency и стоимость.
• Команда понимает, как смотреть trace.
• Есть план обновления зависимостей.
• Нельзя выполнить опасное действие без человека.
• Фреймворк сокращает код, а не маскирует хаос.
• Сценарий проверен на реальных данных.
• Есть критерий отказа от фреймворка, если он усложняет пилот.

FAQ

Можно ли использовать LangChain и LlamaIndex вместе?

Да, но начинайте так только при ясной причине. Например, LlamaIndex отвечает за retrieval, а LangGraph - за workflow. Без причины это добавит две зоны сложности.

Что лучше для RAG?

Если главная задача - документы и retrieval, чаще удобнее LlamaIndex или простой pipeline. Но LangChain тоже подходит, если команда уже использует его экосистему.

Что лучше для агента?

Для управляемого многошагового агента чаще смотрят LangGraph. Но agent без evals и прав остается рискованным независимо от фреймворка.

Нужно ли выбирать стек до сбора данных?

Нет. Сначала разберите корпус, задачи, права и критерии качества. После этого выбор станет менее идеологическим.

Что читать дальше?

Для контроля качества смотрите мониторинг и eval AI-агентов и оценку качества RAG.