Чем LangChain отличается от LlamaIndex — и почему это вообще должно тебя волновать?
Если ты хоть раз пробовал собрать что-то с LLM, скорее всего уже видел этот спор в комментариях. Одни говорят «только LangChain, там всё есть». Другие — «LlamaIndex, потому что LangChain — это абстракция поверх абстракции поверх туториала». Третьи пишут «выкинул оба, написал сам за вечер». Я прошёл все три стадии. Расскажу, что из этого получилось.
LangChain: когда инструмент умнее тебя — это проблема
Начал с LangChain. Логика была простая: популярный, звёзды на GitHub, документация большая. Поставил, открыл туториал, запустил первую цепочку. Работает. Красиво.
А потом попробовал сделать что-то чуть сложнее — простой RAG-пайплайн с фильтрацией по метаданным. И провалился в кроличью нору. В LangChain три разных способа строить цепочки: старый через LLMChain, новый через LCEL (LangChain Expression Language), и какой-то промежуточный из статей 2023 года, который уже deprecated, но гуглится первым.
Час ушёл только на то, чтобы понять, какой из трёх подходов актуальный. Потом ещё час — почему ConversationalRetrievalChain ведёт себя не так, как в примере. API поменялся между версиями, Stack Overflow про это не знает.
Вот в чём штука с LangChain: он пытается охватить всё. Агенты, RAG, memory, callbacks, streaming, инструменты, мультимодальность. Для каждой задачи — обёртка. Но чем больше обёрток, тем труднее понять, что происходит внутри. Когда что-то ломается, ты отлаживаешь не свой код, а чужую абстракцию. Это отдельный вид боли.
При этом LangChain реально хорош для прототипа, который нужно показать завтра. Быстро склеить LLM + поиск + память — справляется. Просто не жди, что этот прототип легко превратится в production.
LlamaIndex: специализация как достоинство и как ограничение
LlamaIndex я попробовал, когда задача сузилась: нужен был чат по корпусу документов с нормальной индексацией и нормальным поиском. Не агенты, не цепочки — просто «документы → запрос → ответ».
Здесь он выигрывает честно. Заточен под именно это. Концепции понятнее: Document, Index, QueryEngine, Retriever — всё называется так, как оно есть. Структуру я понял за час, а не за день.
Что понравилось — можно нормально контролировать retrieval. Настроить chunking, выбрать стратегию поиска, добавить reranker — всё это делается без ощущения, что лезешь в кишки фреймворка. Почти.
Проблема пришла, когда захотел выйти за рамки простого RAG. Понадобилась небольшая агентная логика — чтобы система сама решала, когда искать по документам, а когда отвечать из контекста. LlamaIndex это поддерживает, но агенты там похожи на фичу, которую добавили потому что надо, а не потому что это их конёк. Документация по агентам заметно хуже, чем по индексированию.
Дело в том, что с 2024 года LlamaIndex заметно потяжелел. Переименовались, переписали API, добавили LlamaCloud — платную часть. Бесплатный open-source никуда не делся, но чувствуется, что основное развитие идёт туда, где деньги.
«Написал сам»: когда это честный выбор, а не снобизм
После двух итераций с фреймворками я сел и написал маленький RAG-пайплайн с нуля. Не потому что крутой — просто устал чинить то, что не я сломал.
Оказалось не страшно. Загрузить документы, разбить на чанки, сделать эмбеддинги через OpenAI или локальную модель, положить в Qdrant, при запросе найти похожие чанки, сформировать промпт, отправить в LLM, вернуть ответ. Всё. Около 200 строк кода. Каждую я знаю. Когда что-то ломается — знаю где смотреть. Добавить новую логику — просто дописываю функцию, не ищу, какой класс надо отнаследовать.
Но честно: это работает, пока задача понятная и стабильная. Как только появляется «а давай ещё добавим X» — начинаешь изобретать то, что в LlamaIndex уже есть. Я потратил день на нормальный streaming ответов, потом ещё полдня на обработку ошибок при rate limiting. Фреймворк бы это дал из коробки.
Как я сейчас выбираю между тремя вариантами
Универсального ответа нет, но логика у меня примерно такая.
Задача — «покажи прототип через три дня», архитектуры ещё нет — беру LangChain. Не потому что он лучший, а потому что там можно быстро собрать что угодно из готовых кусков. Технический долг будет, но это потом.
Задача конкретная — «чат по документам», «поиск по базе знаний», «вопрос-ответ по PDF» — беру LlamaIndex. Он для этого сделан, и это чувствуется. Меньше магии, больше предсказуемости.
Задача небольшая и понятная до конца — пишу сам. Обычно это что-то вроде одного специализированного агента с тремя инструментами или простой RAG-пайплайн с нестандартной логикой ранжирования. Когда точно знаешь, что нужно, фреймворк только мешает.
Что изменилось в 2026
Оба фреймворка за последние полтора года сильно поменялись — и не всегда в сторону простоты. LangChain всерьёз занялся агентами и LangGraph, граф-ориентированным подходом к многошаговым задачам. Это интересно, но добавляет ещё один слой концепций поверх уже существующих. LlamaIndex ушёл в сторону enterprise и облачных сервисов.
На практике изменилось и другое. Сами LLM стали умнее, и это неочевидно влияет на выбор инструментов: многие задачи, для которых раньше нужна была сложная цепочка с промежуточными шагами, сейчас решаются одним хорошим промптом. Часть функциональности фреймворков просто перестала быть нужной.
Так что вопрос «LangChain или LlamaIndex» в 2026 году иногда правильнее заменить на другой: а нужен ли фреймворк вообще.
Я не пришёл к одному ответу — и думаю, это нормально. Инструмент выбирается под задачу, а не наоборот. Главное, что вынес для себя: прежде чем тянуть фреймворк, стоит потратить час и честно понять, сколько из его возможностей ты реально используешь. Если ответ «процентов двадцать» — может, и не надо.
