RAG умер? Да здравствует RAG!
Вы запустили RAG-систему. Она работала отлично на тестовых данных. А потом в продакшене пользователь задал вопрос по документу на 200 страниц. И все посыпалось. Контекст переполнен, релевантность документов падает, ответы становятся бредовыми. Знакомая история? К 2026 году эта проблема достигла эпических масштабов.
Проблема не в RAG как идее. Проблема в том, что мы запихиваем в LLM все подряд, надеясь, что векторный поиск и огромное контекстное окно спасут ситуацию. Они не спасают. Точнее, спасают до первого серьезного запроса. Современные LLM вроде Claude-4 или GPT-5-Omni на 19.04.2026 хоть и имеют контекстные окна в 200k+ токенов, но стоимость и качество ответа при переполнении падают катастрофически.
RAG не сломался. Он просто вышел за пределы своих проектных возможностей. Пора переходить от простого "поиск-и-вставка" к интеллектуальному управлению контекстом.
Контекстный движок: что это и зачем он нужен
Забудьте на минуту про векторы и эмбеддинги. Представьте систему, которая управляет контекстом как операционная система управляет памятью. Она не просто находит документы. Она решает, что важно прямо сейчас, что можно сжать, что нужно сохранить для следующего шага диалога, а что выкинуть навсегда.
Это контекстный движок. Его задача - не поиск, а управление вниманием LLM. И вот из чего он состоит.
1Управление памятью: не просто векторный поиск
Векторная база - это тупая память. Она находит похожие куски текста, но не понимает связей между ними. В сложном диалоге о проекте вам нужны не похожие предложения, а конкретные требования, обсужденные на прошлой неделе, и текущий статус задач.
Здесь стоит посмотреть на подходы вроде Anchor Engine V5, который заменяет векторный поиск на оптимизированный граф памяти. Граф хранит не только семантику, но и временные связи, причинно-следственные цепочки. Это уже ближе к реальной работе с информацией.
Но память - это еще и аппаратная проблема. Когда все твердят о "стене памяти" ИИ, имеет смысл вспомнить про технологии вроде RRAM, которые ломают привычные ограничения. А в 2026 году аналоговая память RRAM уже не футуристика, а реальность для edge-устройств. Ваш движок должен проектироваться с учетом этих сдвигов.
2Компрессия контекста: как ужать 100k токенов до 4k без потери смысла
Самый простой и самый опасный способ. Берете длинный текст, отдаете его LLM с промптом "сократи, сохрани главное". Получаете выжимку, которая потеряла все нюансы. Потом удивляетесь, почему модель ошибается в деталях.
Правильная компрессия - это иерархическая.
- Уровень 1: Извлечение сущностей и фактов. Вытащить даты, имена, цифры, ключевые утверждения. Это можно делать малыми, дешевыми моделями.
- Уровень 2: Семантическое сжатие. Группировка схожих идей, удаление повторов, построение краткого конспекта. Тут уже нужна модель поумнее.
- Уровень 3: Динамическое сжатие под задачу. Если пользователь спрашивает про финансовые показатели, сжимаем все, что связано с финансами, оставляя детали. Остальное - в архив.
Инструменты? Посмотрите на библиотеки, вышедшие в начале 2026 года: LongContextCompressor от Cohere, или открытый аналог MemSum. Они умеют не просто резать текст, а строить деревья релевантности.
3Переранжирование документов: почему relevance - это не все
Векторный поиск выдает топ-10 чанков по косинусной близости. Вы их все пихаете в промпт. А что, если самый релевантный чанк - это определение термина, а вам для ответа нужен пятый по релевантности, где как раз описан пример использования? Модель запутается.
Переранжирование (re-ranking) должно учитывать не только семантическую близость, но и:
- Тип информации: определение, пример, контраргумент, статистика.
- Свежесть: для новостей или изменяющихся данных это критично.
- Источник: доверенный ли это мануал или комментарий с форума.
- Связность с предыдущим контекстом: поддерживает ли этот чанк текущую линию диалога или переводит в новое русло.
На практике это значит запустить второй, более тяжелый ранжировщик (например, BGE-reranker-v3 или его аналоги 2026 года) только на топ-20 результатов от векторов. Да, это дороже. Но в разы дешевле, чем платить за обработку десятков лишних токенов в GPT-5.
4Управление токенами: бюджет, приоритеты, квоты
У вас есть лимит, скажем, 16 000 токенов на контекст. Как их распределить?
- 500 токенов - на системный промпт.
- 1000 - на историю диалога.
- 2000 - на инструкции для агента.
- Остальные 12500 - на релевантные документы.
Но документов на 25000 токенов. Что делают все? Обрезают до 12500 с начала. Кошмар.
Управление токенами - это планировщик. Он знает "бюджет" и распределяет его по приоритетам. Самый важный документ получает 30% бюджета, следующий - 20%, и так далее. Менее важное сжимается агрессивнее. А что-то откладывается в "кэш быстрого доступа", если модель вдруг спросит.
Это похоже на управление оперативной памятью в реальной ОС. И здесь крайне полезны идеи из руководства по борьбе с деградацией контекста. Там эта проблема разобрана на живых примерах.
Собираем движок: архитектура, которая не развалится
Вот как выглядит упрощенная схема работы контекстного движка для одного запроса:
| Этап | Что происходит | Инструменты (актуально на 2026) |
|---|---|---|
| 1. Первичный поиск | Векторная БД ищет все потенциально релевантное. Широкий охват. | Qdrant 2.0, Pinecone с новыми скалярно-векторными гибридами, локально - LanceDB. |
| 2. Фильтрация и переранжирование | Тяжелая модель-ранкер отбирает топ-5 по качеству и полезности для задачи. | Cohere Rerank 2026, BGE-reranker-v4, Jina Reranker. |
| 3. Планирование бюджета токенов | Распределяет лимит контекста между выбранными документами и историей. | Кастомная логика на Python. Библиотек пока нет - приходится паять самим. |
| 4. Многоуровневое сжатие | Каждый документ сжимается до выделенного ему бюджета с учетом его важности. | LongContextCompressor, MemSum, или вызов малой LLM (например, Phi-4-mini). |
| 5. Формирование финального контекста | Сжатые чанки, история диалога, системный промпт собираются в единое целое с четкой структурой. | Шаблонизатор промптов (Langchain уже устарел, на смену пришли PromptFlow и Haystack 2.0). |
Звучит сложно? Так оно и есть. Но альтернатива - это неработающий RAG на производстве. Для вдохновения посмотрите, как собирают RAG-агента для объяснения настолок или как реализуют полностью локальную Agentic RAG систему. Там много практических решений.
Ошибки, которые убьют ваш контекстный движок
Собрали систему, а она дает сбой. Вот самые частые косяки.
Ошибка 1: Слепая экономия на переранжировании. "Зачем нам второй ранкер, если векторы и так хорошие?" Затем, что векторы не понимают контекста запроса. Вы сэкономите 100 миллисекунд на ранжировании и потеряете 10 секунд на обработку мусора LLM, которая еще и ошибется.
Ошибка 2: Статичное сжатие. Один раз сжали документ и положили в кэш. Но в следующем запросе нужны другие детали. Сжатие должно быть динамическим и пересчитываться (или хотя бы адаптироваться) под каждый запрос.
Ошибка 3: Игнорирование многоходовости. В диалоге контекст - это не только документы, но и предыдущие ответы модели, уточнения пользователя. Если ваш движок не умеет работать с графом диалога и обратным обходом, он будет каждый раз начинать с нуля. Пользователи возненавидят вашего агента.
Ошибка 4: Забыть про мультимодальность. В 2026 году запрос "найди на схемах блок, про который я вчера говорил" - обычное дело. Если ваш движок заточен только под текст, вы проиграли. Изучите подходы мультимодального RAG, даже если пока работаете с текстом. Архитектура должна быть расширяемой.
Самая главная ошибка - пытаться скопировать архитектуру из блога 2023 года. Мир LLM меняется каждый квартал. То, что было передовым в 2024, сегодня - анахронизм.
Что дальше? Контекст без границ
К 2027 году, я уверен, управление контекстом станет отдельной специализацией в ML-инженерии. Появятся стандартные протоколы обмена "контекстными сессиями" между разными агентами. Движки научатся предсказывать, какая информация понадобится модели через три шага, и заранее подгружать ее в сжатом виде.
Аппаратура тоже не стоит на месте. Когда 1.58-битные движки на Rust станут массовыми, сама экономика токенов изменится. Обработка станет дешевле, но требования к качеству контекста - выше.
Поэтому мой совет простой. Не стройте очередной RAG из коробки. Стройте контекстный движок. С самого начала закладывайте в него управление памятью, планировщик токенов, слои сжатия. Пусть первая версия будет примитивной. Но архитектура должна позволять расти. Иначе через полгода вы будете не улучшать систему, а тушить пожар в продакшене, где RAG действительно "сломался".
P.S. И да, иногда лучше вообще обойтись без тяжелого RAG. Для простых задач смотрите в сторону легких решений без тяжёлых библиотек. Правильный инструмент для правильной задачи - это тоже часть управления контекстом. Только контекстом вашего проекта.
