Кладбище энкодеров: почему старый стек RAG работал через пень-колоду
Ещё год назад любой уважающий себя RAG-пайплайн выглядел как зоопарк: отдельный энкодер для эмбеддингов (BGE, E5, Instructor), отдельный реранкер (cross-encoder), отдельный векторный индекс (Faiss/Qdrant), а потом ещё и LLM-генератор. И всё это нужно было хоть как-то согласовать по версиям, API и задержкам. Знакомая боль? Я тоже через это проходил. Стек превращался в монстра Франкенштейна — каждый компонент тянул свою версию CUDA, свой батч-сайз и своё количество оперативной памяти. А latency от входа до выхода измерялась секундами, даже на мощных картах.
Главная проблема старого стека — каскад компромиссов. Энкодеры обучены на общих данных, реранкеры — на других, LLM — на третьих. Каждый этап теряет смысл, и финальный ответ часто не соответствует контексту. При этом вы платите за три отдельных инференса вместо одного.
К концу 2024 года стало очевидно: современные LLM (Qwen3, Llama 4 Scout, Gemma 3) уже настолько хорошо понимают семантику и ранжирование, что отдельные энкодеры избыточны. Зачем хранить базу эмбеддингов на 768 размерностей, если вы можете просто засунуть все чанки в промпт LLM и попросить выбрать релевантные? Ровно это и произошло — отказ от энкодеров в пользу LLM как универсального процессора.
Рождение единого движка: SGLang как могильщик старого стека
Но одно дело заменить три модели одной, другое — уметь это делать быстро. Тут на сцену выходит SGLang — фреймворк, который буквально перепрыгивает vLLM, TensorRT-LLM и прочих ветеранов по скорости за счёт радикс-деревьев и эффективного управления KV-кэшем. Если коротко: SGLang умеет кэшировать промежуточные состояния для любого префикса, и если вы обрабатываете сотни чанков с одинаковым системным промптом, то повторное вычисление внимания не требуется — просто берётся готовый KV-кэш из дерева.
В новом стеке RAG 2025 вся логика ретривала и реранкинга выполняется внутри одного LLM-сервера SGLang. Вы больше не гоняете данные между разными микросервисами, не дублируете память и не синхронизируете кэши. Одна модель, один API, один пайплайн.
Как это работает на практике (и почему это не просто замена энкодера)
Идея проста до безобразия: LLM сама решает, какие куски текста относятся к запросу. Вы передаёте ей запрос и набор кандидатов, а модель возвращает ранжированный список или сразу генерирует ответ, опираясь на наиболее релевантные чанки. Никаких векторных индексов, никаких энкодеров — только понимание естественного языка.
1 Prompt-based retrieval: отказ от графов и индексов
Вместо того чтобы строить эмбеддинги для каждого документа, вы просто кладёте документы в контекст (их может быть несколько десятков, если позволяет окно модели — у Qwen3-128K это не проблема). Затем просите LLM выбрать из списка те, что относятся к вопросу, или сразу ответить, используя эти тексты. SGLang обрабатывает такую задачу в разы быстрее, чем классическая цепочка энкодер → поиск → реранкер, потому что KV-кэш для статической части (документов) кешируется и используется повторно для всех последующих запросов к той же базе.
2 Generative reranking: LLM как судья
Даже если вы по старинке используете внешний ретривер (например, гибридный поиск с BM25 и энкодером), реранкинг теперь берёт на себя LLM. Промпт вида «Отсортируй эти отрывки по релевантности к запросу» работает точнее и контекстуальнее любого Bi-Encoder или Cross-Encoder. А SGLang позволяет выполнять такой реранкинг потоково — без необходимости ждать полной генерации всех оценок.
Подробности про замену энкодеров и реранкеров мы уже расписали в отдельной статье: RAG-стек 2026: как заменить энкодеры и реранкеры на LLM. Там и промпты, и бенчмарки, и грабли.
Что входит в современный стек RAG 2025: чеклист
Если вы решили перейти на новый стек, вот минимальный набор компонентов (спойлер: их всего два):
- Одна LLM — лучше всего Qwen3-32B-Instruct, Llama 4 Scout (17B MoE) или Gemma 3-27B. Все они показывают отличные результаты на реранкинге и генерации. Выбирайте ту, у кого окно контекста не меньше 32K токенов — чтобы вместить достаточно чанков.
- SGLang — единый сервер для инференса. Он поддерживает все современные архитектуры, кэширование на уровне radix tree, адаптивное квантование (FP8/INT4) и speculative decoding. Других серверов в 2025 году вы уже не захотите.
Опционально — лёгкий энкодер для первичной фильтрации (например, BGE-M3), если количество документов превышает миллионы и вы физически не можете скормить их все LLM. Но даже в этом случае реранкинг остаётся за LLM — энкодер только грубо отсекает 90% мусора.
Типичные ошибки при переходе на LLM-ретривал
Ошибка №1: использовать слабую модель. Если взять Llama 3.1 8B, она будет плохо ранжировать — качество упадёт ниже, чем у простого энкодера. Нужна модель от 20B параметров. Это не роскошь, а необходимость. Проверьте наш обзор локальных LLM 2025 — там есть таблица с оценками реранкинга.
- Игнорирование KV-кэша. Если вы не используете SGLang с radix cache, вы будете пересчитывать внимание для каждого запроса, что убивает всю выгоду. vLLM с PagedAttention не даёт такого прироста — проверено в битве SGLang против vLLM.
- Слепота к длине контекста. Даже LLM с окном 128K токенов теряют точность на середине последовательности. Используйте sliding window или Chunk → Rerank → Generate, но не скармливайте все документы оптом.
- Отказ от tool calling. RAG 2025 — это агент, который сам решает, когда и как обращаться к документам. Обязательно включите function calling в LLM. Список лучших моделей с этой способностью — в обзоре LLM с tool calling.
Что дальше: 2026 год — эпоха агентного RAG
Уже сейчас заметен тренд: RAG-пайплайн всё чаще строится не как линейная цепь, а как агент с петлёй обратной связи. LLM управляет всем: выбирает, какие документы загрузить, повторяет запрос, уточняет критерии. SGLang поддерживает грамматики и guided generation, что позволяет агентам возвращать структурированные действия (JSON, инструменты). Загляните в SyGra Studio — визуальный конструктор агентов, который как раз заточен под новый стек.
Энкодеры умрут окончательно. Уже сегодня нет смысла держать отдельный Bi-Encoder для ретривала, когда LLM за 30 миллиардов параметров делает это точнее и дешевле (в пересчёте на total cost of ownership). А SGLang станет стандартом де-факто для инференса — как когда-то стал Kubernetes для оркестрации.
Советую не тянуть: переводите свои RAG-системы на SGLang и Qwen3 уже сейчас. Пока конкуренты мучаются с Faiss и cross-encoder, вы будете получать ответы в 3 раза быстрее и без головной боли о совместимости энкодеров.
