Чем LangChain отличается от LlamaIndex — и почему я потратил неделю, прежде чем понял, что задаю не тот вопрос?
Когда собираешь первое RAG-приложение, рано или поздно натыкаешься на этот выбор. Оба фреймворка упоминаются через запятую, оба на Python, оба работают с LLM. Я честно пытался найти нормальное сравнение — и нашёл кучу статей, которые перечисляют фичи колонками. Но ни одна не объяснила главного: это вообще конкуренты или нет?
Спойлер: не совсем. И вот почему это важно, если выбираешь инструмент под конкретную задачу.
Откуда они выросли — и это многое объясняет
LangChain появился как способ соединять всё подряд. Идея простая: есть LLM, есть куча внешних инструментов — поиск, базы данных, API, память, агенты. LangChain — это клей, который держит всё вместе. Он с самого начала строился вокруг цепочек действий и агентов, которые принимают решения по ходу работы.
LlamaIndex вырос из другой боли. Его создавали люди, которым нужно было нормально подключить к LLM свои собственные данные — документы, базы знаний, внутренние вики. Поэтому в центре там не "цепочки действий", а индексирование, chunking, поиск по данным и то, как правильно подать контекст модели.
Я долго не понимал эту разницу, потому что оба умеют примерно одно и то же. Но когда начинаешь разбираться, видишь: LangChain думает про workflow, LlamaIndex думает про данные. Разные углы зрения на одну задачу.
Где LangChain выигрывает
Я собирал на нём небольшого агента — он должен был принимать запрос, решать, нужен ли поиск в интернете или достаточно ответить из памяти, и отдавать результат. Для такого сценария LangChain — очевидный выбор.
Инструментарий для агентов там заметно богаче. Готовые обёртки под десятки сервисов: Google Search, Wikipedia, WolframAlpha, SQL-базы, REST API. Логика "подумай, выбери инструмент, выполни, проверь" прописана нативно. LangChain Expression Language (LCEL) позволяет описывать сложные цепочки относительно читаемо — хотя первые пару часов я смотрел на пайпы (|) и думал, что что-то делаю не так.
Отдельная история — LangSmith, их платформа трассировки. Реально помогает понять, где именно в цепочке всё пошло не так. Я запускал один воркфлоу и увидел в трейсах, что модель на третьем шаге получала обрезанный контекст. Без этого я бы ещё долго гадал.
Если задача звучит как "мне нужен агент, который умеет делать несколько разных вещей и сам решает, что делать дальше" — смотри на LangChain.
Где LlamaIndex выигрывает
Тут у меня была другая история. Нужно было сделать поиск по большой коллекции PDF — технические документы, руководства, около 400 файлов. Попробовал сначала LangChain. Работает, но ощущение, что сам собираешь велосипед из запчастей.
В LlamaIndex всё вокруг данных продумано на уровень глубже. Chunking с учётом структуры документа, разные типы индексов (векторный, список, дерево, граф знаний), управление тем, как именно контекст попадает в промпт — это там first-class citizens, а не надстройки.
На практике больше всего понравились query engines. Штука, которая позволяет задавать вопросы к индексу с разными стратегиями. Например, sub-question query engine разбивает сложный вопрос на части, отвечает на каждую отдельно, потом собирает итог. Я проверил на реальных документах — качество ответов заметно лучше, чем при простом top-k поиске.
С разнородными источниками LlamaIndex тоже справляется лучше. Подключить одновременно PDF, Notion, базу данных и веб-страницы и сделать из этого единый поиск — там это решается куда менее болезненно.
Если задача звучит как "у меня есть данные, и мне нужно, чтобы LLM с ними нормально работал" — смотри на LlamaIndex.
Почему их часто используют вместе
Это удивило меня больше всего. Я несколько раз встречал проекты, где LlamaIndex используется как движок для работы с данными, а LangChain — как оркестратор поверх. LlamaIndex строит индекс и отвечает на запросы к данным, LangChain управляет агентом, который решает, когда к этому индексу обращаться, а когда делать что-то другое.
Это не костыль — вполне логичная архитектура. Каждый делает то, что умеет лучше.
Есть даже официальная интеграция: можно обернуть LlamaIndex query engine как инструмент для LangChain-агента. Я пробовал — работает, хотя настройка занимает время и документация местами расходится с реальностью. Классика.
Как я теперь принимаю решение
Когда приходит новая задача, я задаю себе два вопроса. Это больше про "что делать" или про "с какими данными работать"? Мне нужен агент, который сам принимает решения, или качественный поиск по конкретному корпусу?
Если первое — LangChain. Если второе — LlamaIndex. Если оба — смотрю, что будет ядром системы, и от этого выбираю основу.
Ещё один момент, который стоит учитывать: LangChain развивается быстро и иногда хаотично. Я несколько раз натыкался на deprecated-методы в коде, которому было три месяца. LlamaIndex в этом смысле чуть стабильнее, хотя тоже не без сюрпризов.
Вопрос "что лучше" — неправильный вопрос. Правильный: что лучше подходит под конкретную задачу. Звучит как банальность, но реально помогает — когда перестаёшь искать универсальный ответ и начинаешь смотреть на то, что именно строишь.
