LlamaIndex против LangChain: когда какой инструмент

MAATRIX

Если вы начинаете проект поверх LLM и уже прочитали десяток статей «что лучше», скорее всего запутались ещё сильнее — половина источников хвалит LlamaIndex за RAG, вторая половина советует LangChain «для всего». Проблема в том, что оба ответа были правдой года три назад и уже не полностью правдивы сейчас: оба фреймворка активно росли в сторону друг друга. Разберём, откуда взялась разница в позиционировании, что из неё осталось актуальным, и как выбирать инструмент под конкретную задачу, а не по репутации.

Откуда взялись LlamaIndex и LangChain: разное позиционирование на старте

Это принципиально важно понимать не как факт «на сегодня», а как историю, которая объясняет, почему у каждого фреймворка так устроены абстракции.

LlamaIndex (изначально GPT Index) с первых версий строился вокруг одной задачи: взять корпус документов — PDF, Notion, Confluence, базу данных, файловую систему — и сделать его доступным для запросов через LLM. Отсюда его центральные абстракции: Document, Node, Index, QueryEngine. Библиотека с самого начала предлагала специализированные загрузчики данных (LlamaHub), разные стратегии разбиения на чанки, несколько типов индексов (векторный, списочный, древовидный, keyword-based) и инструменты для оценки качества поиска. Это был фреймворк «для RAG» в узком и хорошем смысле — узкая специализация давала глубину: тонкая настройка retrieval, работа с метаданными узлов, комбинирование нескольких индексов в одном запросе.

LangChain стартовал почти одновременно, но с другой рамкой: не «как найти нужный кусок текста», а «как связать вызовы модели, инструментов и внешних систем в последовательность действий». Его исходные абстракции — Chain, Agent, Tool, Memory — заточены под произвольную логику: вызвать модель, передать результат в следующий шаг, дать модели доступ к калькулятору или поисковику, сохранить историю диалога. RAG в LangChain тоже был с ранних версий (RetrievalQA, VectorStoreRetriever), но как один из множества сценариев использования цепочек, а не как центральная тема проекта.

Если совсем грубо: LlamaIndex начинался с вопроса «как достать из документов правильный контекст», LangChain — с вопроса «как построить программу, где шаги решает модель». Это разное происхождение всё ещё видно в том, какие абстракции в каждом фреймворке проработаны глубже, даже если формально оба сегодня умеют почти всё.

LlamaIndex: сильные стороны в поиске и индексации

Там, где LlamaIndex по-прежнему исторически силён — работа с данными до момента, когда до модели вообще доходит запрос.

Практические плюсы, которые стоит учитывать:

• Готовые стратегии чанкинга — не только «нарезать по N символов», но и SentenceSplitter, SemanticSplitterNodeParser (разбиение по смысловым границам), иерархические парсеры для сохранения структуры документа.
• Разные типы индексов под разные задачи — векторный для семантического поиска, SummaryIndex для последовательного обхода всего корпуса, TreeIndex для иерархических запросов, KeywordTableIndex для точных совпадений терминов.
• Query engines с постобработкой — встроенные реранкеры, фильтрация по метаданным, объединение результатов из нескольких индексов (RouterQueryEngine, который сам решает, к какому индексу обратиться).
• Большая коллекция готовых коннекторов данных через LlamaHub — от S3 и Google Drive до Slack и баз данных, что экономит время на написание своих загрузчиков.

Минимальный пример, который показывает философию библиотеки — от документов к ответу за несколько строк:

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=5)

response = query_engine.query("Как настроить резервное копирование базы?")
print(response)

Если ваша задача — «есть 5000 внутренних документов, нужно быстро и точно искать по ним ответы» — специализированные инструменты LlamaIndex снимают немало ручной работы: не нужно самому писать логику маршрутизации между разными типами поиска или ручную склейку результатов реранкинга.

Подробный разбор самого процесса — от вопроса до ответа — есть в статье что происходит внутри RAG между вопросом и ответом, а практическую сборку пайплайна с нуля мы разбирали в RAG pipeline с нуля: практический пример.

LangChain: сильные стороны в построении цепочек и агентов

LangChain исторически даёт более общую модель — не «индекс плюс запрос», а произвольный граф шагов, где на каждом шаге может быть вызов модели, инструмента, условная логика или обращение к памяти диалога.

Где это ощущается сильнее всего на практике:

• Абстракция агента с инструментами — модель сама решает, какой инструмент вызвать (поиск в интернете, калькулятор, обращение к API, чтение файла) и в каком порядке, с возможностью нескольких итераций «подумать → вызвать инструмент → оценить результат → продолжить».
• LangGraph (надстройка над LangChain для графов состояний) — явное описание сложных сценариев с ветвлениями, циклами, параллельными шагами и человеком в цикле (human-in-the-loop), что для многошаговых агентных сценариев удобнее, чем линейная цепочка.
• Единый интерфейс над множеством провайдеров моделей и инструментов — переключение между разными LLM, векторными базами, поисковыми API без переписывания всей логики.
• Память диалога — из коробки есть несколько стратегий хранения истории разговора (буфер, суммаризация старых сообщений, комбинированные варианты), что важно для чат-подобных сценариев, а не разовых запросов.

Пример простого агента с инструментом — модель сама решает, когда его вызывать:

from langchain.agents import create_agent
from langchain_core.tools import tool

@tool
def get_server_status(server_id: str) -> str:
    """Возвращает текущий статус сервера по его ID."""
    return f"Сервер {server_id}: онлайн, нагрузка 23%"

agent = create_agent(model="gpt-4o", tools=[get_server_status])
result = agent.invoke({"messages": [("user", "Проверь статус сервера srv-42")]})

Если ваша задача — «модель должна сама решать, вызывать ли инструмент А, потом Б, при определённом условии — В, и уметь остановиться, когда собрала достаточно информации» — сложность здесь не в поиске по документам, а в логике принятия решений и оркестрации шагов. Именно под это LangChain и его модель цепочек/графов исторически строились.

Практический пример поднятия такого агента на своём сервере смотрите в статье как поднять агента на LangChain на сервере.

Где границы стёрлись: как оба фреймворка расширились

Честно: описанное выше — это исторический контраст, а не актуальная жёсткая граница. Оба проекта за прошедшие годы явно двигались навстречу друг другу, и к 2026 году разрыв в возможностях заметно уже, чем в описаниях из старых статей 2023 года.

LlamaIndex добавил полноценные агентные возможности — FunctionAgent, ReActAgent, поддержку многошаговых рассуждений с вызовом инструментов, оркестрацию нескольких агентов через AgentWorkflow. Сегодня на LlamaIndex вполне реально построить агента с инструментами и условной логикой, а не только классический RAG-запрос.

LangChain, в свою очередь, ощутимо прокачал RAG-инструментарий: сейчас в экосистеме есть развитые загрузчики документов, интеграции с реранкерами, гибкие стратегии сплиттинга текста, MultiVectorRetriever для работы с разными представлениями одного документа (например, краткое резюме плюс полный текст) — многое из того, что раньше было заметным преимуществом LlamaIndex.

Практический вывод из этого простой и не очень приятный тем, кто ищет готовую формулу: историческое позиционирование объясняет, откуда растут абстракции каждого фреймворка, но не является жёстким фактом о текущих возможностях. Документация обоих проектов регулярно обновляется, добавляются новые модули, меняются рекомендуемые паттерны. Прежде чем делать выбор на основе статьи (в том числе этой), стоит свериться с актуальной документацией — если она резко разошлась с описанным здесь, доверяйте документации, а не тексту, который вы читаете сейчас.

Практические критерии выбора под задачу

Раз историческое позиционирование — не абсолютный факт, разумнее выбирать по структуре самой задачи, а не по названию фреймворка. Вот рабочие ориентиры:

Если задача не укладывается однозначно ни в одну строку — это нормально, современные приложения на LLM часто смешивают RAG и агентное поведение в одном пайплайне. В таком случае решение не «взять один фреймворк вместо другого», а взвесить, какая часть системы для вас сложнее технически: доводить до ума качество поиска (тогда сильные стороны LlamaIndex важнее) или доводить до ума логику принятия решений агентом (тогда важнее модель LangChain/LangGraph).

Отдельно стоит учитывать эксплуатационную сторону: оба фреймворка тянут за собой немало зависимостей, и на боевом сервере важно не просто «что удобнее писать», но и как это разворачивается, обновляется и потребляет ресурсы — выбор фреймворка не отменяет вопрос, где физически будут жить эмбеддинги, индексы и запущенный процесс с моделью.

Как совмещать оба (или мигрировать между ними)

На практике это не всегда выбор «или-или». Несколько рабочих схем, которые встречаются в реальных проектах:

LlamaIndex как retriever внутри LangChain-цепочки. LlamaIndex предоставляет обёртку, превращающую его query engine в LangChain-совместимый инструмент (tool) или retriever. Это позволяет использовать специализированный поиск LlamaIndex внутри более широкой агентной логики LangChain:

from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool

index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()

search_tool = QueryEngineTool.from_defaults(
    query_engine=query_engine,
    name="knowledge_base_search",
    description="Поиск по внутренней базе документов компании",
)
# search_tool дальше передаётся в агента LangChain как обычный инструмент

Раздельные сервисы. Если приложение большое, часто проще держать RAG-часть (индексация, поиск, реранкинг) отдельным сервисом на LlamaIndex за своим API, а оркестрацию агентного поведения — на LangChain/LangGraph, который дёргает этот сервис как обычный HTTP-инструмент. Это разделение ответственности упрощает и независимое масштабирование, и независимые апдейты каждой части.

Миграция в одну сторону. Если проект начинался как простой RAG на LlamaIndex, а потом обрастает агентным поведением с множеством инструментов и условной логикой — часто разумнее не пытаться выжать из LlamaIndex сложную оркестрацию, а вынести именно логику принятия решений в LangGraph, оставив LlamaIndex ответственным только за retrieval. И наоборот: если агент на LangChain изначально делал простые RAG-запросы, а качество поиска стало узким местом — есть смысл заменить самодельный retrieval на специализированные индексы LlamaIndex, не переписывая остальную агентную логику.

Здесь же стоит вспомнить более широкий вопрос: не всегда задача вообще требует RAG. Если ваш случай — это скорее адаптация модели под узкую предметную область, а не поиск по постоянно обновляемому корпусу, взгляните на сравнение в статье fine-tuning vs RAG: что выбрать — иногда правильный ответ вообще не про выбор между LlamaIndex и LangChain.

Частые вопросы