Почему в 2023 году RAG был безальтернативен, а сегодня это не так
В 2023 году контекстное окно популярных моделей держалось в диапазоне 4-8K токенов. Это примерно 3-6 тысяч слов, меньше средней технической статьи. Положить в такой контекст документацию на 400 страниц было физически невозможно, поэтому Retrieval-Augmented Generation (RAG) оставался единственным рабочим способом дать модели доступ к базе знаний: документ резали на чанки, считали эмбеддинги, складывали их в векторную базу и подставляли в промпт только те фрагменты, которые поиск счёл релевантными.
К 2026 году картина другая. Флагманские модели держат 1M+ токенов, а документация на 400 страниц занимает около 250K токенов, то есть помещается целиком и с большим запасом. Корпус уходит в контекст полностью, и пайплайн с чанкингом, эмбеддингами, векторной базой и реранкером можно не строить вообще.
Прямой ответ на главный вопрос: Long Context подходит, если корпус помещается в эффективное контекстное окно модели, данные меняются редко и запросов немного. RAG нужен, когда корпус больше эффективного окна, база знаний обновляется каждый день, ассистент ведёт длинные диалоги или передавать весь корпус в каждом запросе дороже, чем держать поисковый индекс. Дальше разберём, где проходит эта граница.
Что такое Long Context на практике и где он ломается
Long Context означает, что вы не ищете фрагменты заранее, а отдаёте модели весь корпус и вопрос, а поиск по нему модель выполняет сама механизмом внимания. Схема выглядит проще: нет индекса, нет чанкинга, нет эмбеддингов, нет отдельного сервиса поиска. Обновление данных сводится к замене файла в промпте.
Проблемы начинаются там, где число токенов в спецификации расходится с реальным качеством ответов.
U-образная кривая внимания: почему середина контекста страдает
Модели извлекают информацию из начала и конца контекста заметно лучше, чем из середины. Зависимость называют U-образной кривой внимания: качество высокое на первых и последних фрагментах и проседает в середине. Если нужный факт лежит на 200-й странице из 400, шанс, что модель уверенно им воспользуется, ниже, чем для факта из оглавления или из последнего абзаца.
Практический вывод простой: ключевые факты, инструкции и определения ставьте в начало промпта, а самые важные уточнения продублируйте в конце. Расширение окна до 2M и 10M токенов эту кривизну само по себе не убирает, середина остаётся зоной риска.
Context rot: почему Long Context деградирует после 15-20 вопросов
Context rot описывает падение точности по мере накопления истории диалога. С каждым новым вопросом в контексте оказываются предыдущие ответы, уточнения и случайные детали. Через 15-20 вопросов модель начинает путать, о чём говорила в начале, и теряет нить. RAG в этой ситуации устойчивее: он каждый раз заново подтягивает только релевантные чанки, а не всю историю вместе с корпусом.
У этого ограничения есть цена. Больше контекста означает больше входных токенов, а значит, выше стоимость и задержка. Кэширование контекста LLM помогает: провайдеры умеют переиспользовать неизменный префикс промпта и брать за него меньше денег. Но кэш ускоряет и удешевляет повторную передачу корпуса, а context rot не лечит, потому что растёт сама история диалога.
Для ассистентов, которые ищут нормы и регламенты, эффект особенно болезнен: ответ должен опираться на первоисточник, а не на пересказ пятидесяти предыдущих сообщений. Практический чек-лист по метаданным, обновлению документов и аудиту собран в разборе про AI-помощника, который ищет ведомственные регламенты через RAG.
Шесть уровней сложности RAG-стека: от BM25 до классического RAG
RAG не монолит, а спектр решений, где сложность нарастает ступенями:
- BM25, лексический поиск без эмбеддингов.
- BM25 плюс LLM, которая переформулирует запрос.
- Векторный поиск по эмбеддингам.
- Гибрид: BM25 и векторный поиск вместе.
- Гибрид с реранкером.
- Классический RAG: чанкинг, эмбеддинги, векторная база и реранкер.
Каждый шаг вверх даёт качество и забирает ресурсы: растёт задержка, стоимость и объём инфраструктуры, которую нужно поддерживать.
BM25 и лексический поиск: минимальный RAG без эмбеддингов
BM25 ранжирует документы по частоте слов из запроса с поправкой на длину текста. Он не требует ни эмбеддингов, ни векторной базы, ни GPU, а индекс собирается за минуты и влезает в обычный поисковый движок. Для точных терминов, артикулов, кодов ошибок и названий функций это до сих пор один из самых надёжных вариантов: запрос «модель X200» найдёт страницу про X200, а не абзац про родственные модели.
Ограничение известно: BM25 не понимает синонимы и перефразировки. Запрос «как сбросить пароль» не найдёт раздел «восстановление доступа». Если база небольшая, а формулировки пользователей предсказуемы, этого достаточно, и городить векторный поиск незачем. Какие лёгкие методы закрывают документные задачи, разобрано в материале про то, чем заменить RAG в enterprise-документах.
Векторный поиск, гибрид и реранкер: где начинается настоящая сложность
Векторный поиск ищет по смыслу: текст и запрос превращаются в эмбеддинги, близость считается по косинусной мере. Так закрываются перефразировки, но появляется векторная база, модель эмбеддингов и вопрос их совместимости: при смене модели старые векторы придётся пересчитать для всего корпуса.
Гибрид соединяет лексику и смысл, складывая оценки BM25 и векторного поиска. Реранкер в RAG пересортировывает верхушку выдачи отдельной моделью, которая смотрит на пару «запрос и фрагмент» целиком, а не по отдельности. Это заметно повышает точность на верхних позициях и добавляет ещё одну модель в пайплайн со своим временем отклика.
Классический RAG собирает всё вместе: парсинг документов, чанкинг, эмбеддинги, векторную базу, поиск, реранкер и генерацию с цитированием. На выходе получается отдельный проект с инфраструктурой, мониторингом и регламентом обновления индекса. Ломается такая система тоже ступенчато: наивный RAG уверенно выдаёт неверный ответ, когда портится парсинг таблиц, не расширяется запрос или нужная страница проваливается ниже отсечки. Такие сценарии отказа и способы их закрыть разобраны в статье про четыре этапа RAG-пайплайна, где рождаются галлюцинации.
Запросы, которым нужен не один поиск, а цепочка шагов, решают планировщиком: он разбивает вопрос на подзадачи и итеративно уточняет выдачу. Пример такой схемы с метриками recall и оценкой стоимости описан в разборе многошагового семантического поиска в Amazon Bedrock.
Экономика выбора: когда RAG окупается, а когда нет
Точка окупаемости RAG держится на трёх факторах: объём корпуса, частота обновления, количество запросов.
Объём корпуса. Считать нужно по эффективному контексту, а не по заявленному: на практике он составляет 50-65% от номинала. Модель с окном 1M токенов надёжно удерживает примерно 500-650K. Если корпус меньше этой границы, Long Context справляется. Если больше, часть документов всё равно не попадёт в надёжную зону внимания, и резать корпус придётся в любом случае.
Частота обновления. Статичная документация живёт в промпте до следующего релиза. База, которая меняется ежедневно, заставляет пересылать весь корпус постоянно. RAG обновляет только изменённые чанки, а инкрементальная переиндексация дешевле полной перезагрузки.
Количество запросов. Арифметика простая. Документация на 250K токенов и 10 запросов в день дают 2,5M входных токенов ежедневно, и с кэшированием это стоит копейки. Те же 250K при 10 000 запросов в день превращаются в 2,5 млрд токенов, и здесь RAG с одним поиском на запрос почти всегда выигрывает по деньгам.
Если корпус слишком велик даже для Long Context, а аналитика по нему нужна, применяют сжатие знаний вместо полноценного пайплайна: метод, который сжимает базу знаний в разы для аналитических запросов.
Универсального числа вроде «RAG окупается с 5000 запросов в день» нет: слишком много зависит от цены за токен у конкретного провайдера, условий кэширования и стоимости поддержки индекса. Логика оценки всегда одна: сравните цену передачи корпуса в каждом запросе с ценой построения и поддержки поиска на своём объёме.
Практическая таблица: когда достаточно Long Context, а когда нужен RAG
| Условие | Что выбрать | Почему |
|---|---|---|
| Корпус укладывается в 50-65% эффективного окна | Long Context с кэшированием | Индекс не нужен, обновление сводится к замене файла в промпте |
| Корпус больше эффективного окна | RAG | Часть документов не попадёт в надёжную зону внимания |
| Данные обновляются ежедневно | RAG | Переиндексация изменённых чанков дешевле пересылки всего корпуса |
| Диалоги длиннее 15-20 вопросов | RAG | Context rot снижает точность по мере роста истории |
| Ответ зависит от факта в середине документа | RAG или перенос фактов в начало и конец промпта | U-образная кривая внимания хуже обрабатывает середину |
| Тысячи запросов в день | RAG | Стоимость входных токенов растёт линейно и быстро обгоняет поддержку индекса |
| Маленький статичный корпус, бюджет ограничен | Long Context | Классический RAG-проект не окупится |
| Нужны точные термины, коды и артикулы | BM25 или гибрид | Лексический поиск надёжнее на точных совпадениях |
Итог: как выбрать без лишней сложности
Начните с Long Context, если корпус укладывается в эффективное окно, данные меняются редко и диалоги короткие. Включите кэширование контекста, чтобы не платить за один и тот же префикс в каждом запросе, и разместите ключевые факты в начале промпта.
Переходите на RAG, когда упрётесь в одну из трёх стен: корпус перестал помещаться в эффективное окно, база обновляется быстрее, чем вы успеваете её пересылать, или диалог стабильно уходит за 15-20 вопросов. Берите BM25, если запросы содержат точные термины и коды, и добавляйте векторный поиск только там, где пользователи перефразируют формулировки. Классический RAG со всем стеком собирайте тогда, когда первые два уровня уже не вытягивают качество.
Ландшафт продолжает двигаться: растёт эффективное окно, дешевеет кэширование, появляются методы сжатия знаний. Точка окупаемости RAG сдвигается, поэтому решение, принятое полгода назад, стоит пересчитать заново по тем же трём факторам: объём корпуса, частота обновлений, число запросов.