В прошлом году я попытался «убить» RAG в продукте, который мне был важен.
У нас был retrieval-пайплайн, который в целом работал, но раздражал. В нём случались всплески задержек, были пограничные случаи, которые мы не могли воспроизвести, и копился бэклог правок: лучшее разбиение на фрагменты, более точные фильтры, более качественный реранкинг, более хорошие оценки (evals).
Потом стало проще покупать большой контекст и проще его оправдывать. Искушение было очевидным: если мы просто будем вставлять больше текста в промпт, то сможем выкинуть пайплайн, убрать онколл и выкатить всё в прод.
Сначала это работало. Демонстрации проходили без проблем. Ассистент звучал умно. Команда смогла сосредоточиться на фичах, а не на «инфраструктурной обвязке».
А потом всё развалилось в форме, которая бьёт больнее всего: не краш, а публичное разочарование. «Он отвечал уверенно, но ошибался». «Он сослался на документ, который поменяли на прошлой неделе». «Он дал правильный ответ не тому человеку». Ничто из этого не было неожиданностью. Это была предсказуемая цена за то, что мы относились к контексту как к свалке, а не как к спроектированной системе.
Именно поэтому я не верю в тезис «RAG мёртв».
Извлечение (retrieval) никуда не делось. На короткое время исчезло другое — социальное доказательство. Про RAG стало не так весело говорить, пока все наслаждались периодом очарования длинным контекстом. В 2026 году RAG возвращается, потому что возвращаются реальные требования: актуальность знаний, права доступа, стоимость, задержки и возможность аудита.
Современный RAG выглядит иначе. Это уже меньше «демо векторной базы», и больше инженерия поиска: гибридный поиск, реранкинг, формирование контекста и оценка качества, которая измеряет сбои извлечения, а не только качество ответов.
Почему действительно казалось, что «RAG мёртв»
Этот тезис обычно вырастает из реального опыта. Большие окна контекста позволяют командам выпускать продукт, не строя поиск. Модели стали лучше пересказывать и «сшивать» информацию. Кэширование промптов сделало подход «вставим целиком руководство» менее болезненным для многих внутренних ассистентов.
Если ваш корпус небольшой и стабильный, это действительно может быть правильным решением. Многим продуктам не нужен поиск в первый же день. Проблемы начинаются тогда, когда вы сохраняете ту же архитектуру, а корпус разрастается и цена ошибки растёт.
RAG обычно «возвращается», как только для вас становится важен хотя бы один из пунктов ниже:
Актуальность (freshness): вчера что-то изменилось, и ответ должен это учитывать.
Права доступа (permissions): не каждый пользователь имеет доступ к каждому документу.
Надёжность/проверяемость (reliability): вам нужно понимать, на что именно опирался ответ.
Задержки и стоимость (latency & cost): вы не можете позволить себе отправлять гигантский контекст на каждом шаге диалога.
Когда появляются эти требования, «просто вставить побольше» превращается не в упрощение, а в долг по надёжности.
Большой контекст не устранил извлечение — он изменил то, где поиск начинает окупаться
Большой контекст — это серьёзное изменение. На практике он полезным образом меняет архитектуру системы в двух аспектах:
Он позволяет отложить внедрение поиска для небольших корпусов.
Он делает несовершенный поиск менее катастрофичным, потому что можно включить больше фрагментов-свидетельств.
Но базовое ограничение никуда не девается: модели не используют длинный контекст одинаково эффективно по всей его длине.
Работа «Lost in the Middle» описывает практический сценарий отказа: качество может снижаться, если релевантная информация находится в середине длинного входа, а модели часто лучше справляются, когда подтверждающие данные расположены ближе к началу или к концу.(1) Если ваша «стратегия привязки к источникам» сводится к тому, чтобы вывалить в промпт побольше текста, вы рассчитываете на то, что нужный фрагмент будет использован корректно, в правильном порядке и под нагрузкой. Это не инженерия, а надежда с ограничением по токенам.
Моя первая позиция проста:
Если вам нужны надёжные ответы, контекст нужно воспринимать как тщательно отобранный артефакт, а не как мусорную корзину.
Поиск — это способ такой отбор обеспечить.
Что означает «современный RAG» в продакшене
В 2023 году распространённой ментальной моделью было «векторный поиск плюс top-k фрагментов».
В 2026 году устойчивые системы больше похожи на многоэтапный поисковый пайплайн. Конкретные компоненты могут различаться, но точки управления остаются схожими:
Переписывание запроса для поиска. Добавление ограничений, которые пользователь ��одразумевал (тенант, продукт, временной диапазон).
Широкий отбор с использованием гибридного поиска. Комбинация семантического поиска и лексического сопоставления, чтобы не пропустить идентификаторы и точные совпадения.
Реранкинг и фильтрация. Продвижение лучших фрагментов, отсечение шума, обеспечение разнообразия.
Сбор доказательств, а не объёма. Удаление дубликатов, сжатие и форматирование контекста так, чтобы им было удобно пользоваться.
Генерация с правилами привязки к источникам. Должно быть понятно, что взято из подтверждающих данных, а что является выводом модели.
Оценка retrieval-слоя. Необходимо отслеживать, были ли нужные фрагменты-свидетельства вообще доступны модели.
Вот простой способ описать этот сдвиг:
Наивная привычка в RAG | Что происходит в реальном использовании | Современный ход в RAG |
Только семантический top-k | Пропускаются идентификаторы, коды ошибок и имена собственные | Гибридный поиск (семантический плюс лексический) |
Передавать всё подряд | Больше токенов, больше путаницы, больше уверенной ерунды | Сокращать контекст, структурировать его и обосновывать, что именно попало внутрь |
Без реранкинга | Слабые фрагменты «топят» хорошие | Реранжировать и жёстко фильтровать |
Измерять только ответ | Нельзя понять, где именно система сломалась | Измерять сбои извлечения и фактическую привязанность к источникам |
Моё второе мнение — то самое, которое раздражает людей, мечтающих о единственной библиотеке, способной «решить RAG»:
Современный RAG — это не компонент. Это пайплайн, а пайплайны требуют измерений.
Гибридный поиск — это скучное улучшение, которое реально окупается
Эмбеддинги отлично ловят смысл. Но они не гарантируют точность в деталях. Поэтому подход «только векторный поиск» обычно начинает деградировать, как только корпус становится «настоящим»: тикеты, идентификаторы, коды ошибок, названия политик, номера версий, строки SKU и точные формулировки.
В материале Anthropic «Contextual Retrieval» эта проблема разложена по полочкам, и там же яв��о названо базовое решение: объединить эмбеддинги с лексическим поиском вроде BM25, а сверху добавить реранкинг.(2) Они сообщают о заметном снижении доли сбоев извлечения при сочетании контекстуализированных эмбеддингов и контекстуализированного BM25, и о дополнительных улучшениях при добавлении реранкинга.(2)
Не обязательно копировать их стек один в один, чтобы вынести главный вывод. Важно направление:
семантический поиск ловит смысл
лексический поиск ловит точные совпадения
реранкинг не пускает шум в промпт
Моё третье мнение звучит довольно жёстко:
Если в вашем поисковом слое нет лексической компоненты и реранкера, скорее всего вы поставляете демо, а не систему.
Большинство жалоб «RAG не работает» на самом деле про продукт
Когда команды говорят «RAG не работает», я обычно нахожу одну из таких первопричин:
вопрос задан слишком расплывчато, поэтому поиск возвращает ерунду
разбиение на фрагменты разрезало нужный кусок пополам
не хватает метаданных, поэтому нельзя отфильтровать по тенанту, продукту или времени
корпус на самом деле не является источником истины
никто не может с опорой на факты ответить, помог ли поиск
Векторный поиск — лишь одна часть. Сложные проблемы находятся выше по цепочке.
Если загрузка данных работает нестабильно, то «самого свежего» документа в системе может просто не быть. Если контроль доступа сделан на честном слове, то либо данные утекут, либо вы закрутите гайки так, что доступ будет чрезмерно ограничен. Если интерфейс не п��могает пользователям формулировать вопросы точнее, поиск выглядит непоследовательным, и его начинают винить. Если ваш корпус — это кладбище почти одинаковых версий, даже хороший поисковый слой будет казаться случайным.
Именно здесь тезис «RAG мёртв» часто прячет более неудобную мысль:
Ваш контент и дизайн продукта важнее, чем модель эмбеддингов.
RAG для чат-ассистентов и агентов, которые используют инструменты
Для чат-ассистента извлечение обычно нужно для привязки к источникам. Вы хотите, чтобы ассистент ссылался на правильный материал и останавливался, когда у него нет подтверждений.
Для агента, который использует инструменты, поиск становится частью управляющей логики. Поиск — это не «загрузить контекст в начало промпта». Это инструмент, который агент может вызывать, потенциально много раз, между действиями. Из-за этого меняются сценарии отказа.
Агент может:
найти политику и затем решить, что не может продолжить без недостающего параметра
найти документацию и затем задать уточняющий вопрос вместо того, чтобы угадывать
выполнить поиск ещё раз после неудачного вызова инструмента, потому что ему нужен другой аргумент
Вот почему агенты делают формирование контекста и оценку качества более важными, а не менее. Агенты могут «перегрузить» себя доказательствами, а затем уверенно действовать, опираясь на неверный фрагмент.
Если вам нужен практический сигнал того, что поиск никуда не денется, смотрите на поведение продуктов, а не на презентации стартапов. Anthropic описывает режим, в котором Projects могут переключаться на retrieval-augmented подход (с извлечением), когда знания проекта приближаются к пределу окна контекста, и утверждает, что это позволяет существенно увеличить объем доступных знаний, сохраняя разумное время ответа.(3)
Это не исследовательская история. Это продуктовая история. Поиск существует в продуктах, потому что он окупается.
Когда не стоит строить поиск
Возвращение RAG не означает, что он нужен каждому продукту.
Не стройте поиск, если:
ваш корпус небольшой и стабильный, и вы можете дешево включать его в контекст
ваш «источник истины» не определён, поэтому «привязка к источникам» — это фантазия
у вас нет способа оценить, помог ли поиск
Поиск — это инфраструктура. Инфраструктура имеет смысл только тогда, когда у вас есть реальное ограничение при масштабировании и способ измерить, что это ограничение действительно существует.
Подведем итоги
RAG возвращается в 2026 году, потому что большой контекст не решил требований, которые заставляют продукты быть честными: актуальность данных, права доступа, стоимость, задержки и возможность аудита.
Большой контекст изменил момент, когда поиск начинает окупаться, и упростил некоторые системы. Но он не убрал потребность в инженерии поиска. Модели всё ещё не умеют одинаково хорошо работать с длинным вводом по всей его длине.(1)
Если вы воспринимаете поиск как пайплайн, осознанно формируете контекст и измеряете сбои извлечения и привязанность ответа к видетельствам, RAG перестаёт быть мемом и превращается в устойчивое конкурентное преимущество.
Ссылки
Если хочется углубиться дальше и разбирать такие системы руками, на курсе NLP. Advanced фокус именно на архитектуре LLM и трансформеров: как устроены пайплайны, где ломается качество и как это измерять. Будет много практики на Python/PyTorch и разбор решений, которые можно адаптировать под реальные продуктовые ограничения.
Для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:
26 февраля, 20:00. «Продвинутые техники RAG и введение в GraphRAG». Записаться
11 марта, 20:00. «Концепция AI-агентов и мультиагентных систем». Записаться
18 марта, 20:00. «Современные Методы работы с LLM: от промпт-инжиниринга до агентов и RAG». Записаться
Больше курсов по AI и нейросетям смотрите в каталоге.
