LangChain или LlamaIndex: нужен ли фреймворк для LLM
Практика4 минРедакция Innovialabs
Коротко
Для чат-бота, извлечения данных или простого RAG часто хватает SDK провайдера и своего кода; LlamaIndex окупается в RAG с большим количеством документов, LangChain — при множестве интеграций и агентных сценариях, но оба добавляют абстракции, которые нужно изучать и поддерживать.
Короткий ответ
Фреймворк для работы с LLM не обязателен. Вызов модели — это HTTP-запрос, а официальные SDK уже умеют работать с сообщениями, стримингом, вызовом инструментов и структурированным выводом.
Фреймворк имеет смысл, когда иначе вы будете заново писать то, что в нём уже есть:
- LlamaIndex — если ядро продукта это поиск по вашим документам (RAG): загрузка множества форматов, нарезка, индексация, стратегии поиска.
- LangChain — если нужно много готовых интеграций (модели, векторные базы, инструменты) и многошаговые агентные сценарии; для агентов с состоянием у него есть отдельная библиотека LangGraph.
- Прямой SDK — если логика сводится к нескольким промптам, паре инструментов и одному источнику данных.
Сравнение
| Критерий | Прямой SDK | LangChain | LlamaIndex |
|---|---|---|---|
| Фокус | Прямые вызовы модели | Цепочки, агенты, интеграции | Загрузка данных, индексация, поиск |
| Порог входа | Низкий: один API | Выше: много понятий и слоёв | Средний: понятия индексов и ретриверов |
| Скорость прототипа | Средняя | Высокая, если подходит готовый компонент | Высокая для вопросов по документам |
| Контроль и прозрачность | Полные | Ниже: промпты и логика скрыты в компонентах | Средние |
| Отладка | Обычный код и логи | Нужна трассировка, чтобы понять, что произошло | Нужна трассировка шагов поиска |
| Смена провайдера модели | Тонкий адаптер пишете сами | Встроено | Встроено |
| Стоимость поддержки | Только ваш код | Следить за изменениями API во многих пакетах | Тоже следить за изменениями API |
Оба фреймворка быстро развиваются, их API и структура пакетов заметно менялись со временем. Учитывайте это в стоимости поддержки.
Когда хватает прямых вызовов SDK
- Чат-бот поддержки с системным промптом и несколькими инструментами.
- Извлечение полей из документов в JSON через структурированный вывод.
- Классификация, суммаризация, перевод.
- Простой RAG: один источник, векторная база, один шаг поиска.
Без фреймворка вы видите каждый промпт и каждый запрос, отладка обычная, а обновление SDK редко что-то ломает. Код базового RAG укладывается в несколько небольших функций: получить эмбеддинг запроса, найти фрагменты в векторной базе, собрать промпт, вызвать модель.
Когда фреймворк помогает
LlamaIndex окупается, если у вас:
- много типов документов (PDF, Word, веб-страницы, базы данных) и нужны готовые загрузчики;
- продвинутый поиск: гибридный поиск, переранжирование, иерархические фрагменты, фильтры по метаданным;
- нужно быстро пробовать разные стратегии индексации.
LangChain окупается, если у вас:
- много интеграций, и провайдеры или векторные базы могут меняться;
- агенты с инструментами, ветвлениями и состоянием, которые иначе пришлось бы строить с нуля;
- команда готова использовать его экосистему, включая инструменты трассировки и оценки.
Когда фреймворк мешает
- Скрытые промпты. Компонент отправляет модели текст, который вы не писали, и вы узнаёте об этом, только когда падает качество.
- Абстракция ради абстракции. Три слоя классов вокруг одного HTTP-запроса.
- Хрупкие обновления. Обновление фреймворка ломает код, который нормально работал.
- Сложная отладка. Ошибку глубоко в цепочке труднее найти, чем в своей функции.
- Тяжёлые зависимости. Много пакетов и транзитивных зависимостей ради небольшой функции.
Критерии выбора
Задайте себе вопросы:
- Сколько источников и форматов данных? Много — присмотритесь к LlamaIndex.
- Насколько сложная логика? Многошаговые агенты с состоянием — LangChain/LangGraph. Линейное «промпт → ответ» — SDK.
- Кто будет поддерживать? Если команда не знает фреймворк, стоимость обучения реальна.
- Насколько важен контроль над промптами и задержками? Чем важнее, тем больше причин держаться ближе к SDK.
- Сколько проживёт продукт? Быстрый прототип можно собрать на чём угодно, долгоживущему продукту нужны предсказуемые обновления.
Практичный компромисс: ядро писать на SDK, а из фреймворка брать отдельные компоненты — например, загрузчики документов или сплиттеры текста, не выстраивая вокруг него всю архитектуру.