В 2023 году контекстное окно GPT-4 вмещало восемь тысяч токенов — хватало на короткую статью, но не на книгу. В 2026 году Gemini 2.5 Pro, Claude 3.7 Sonnet и GPT-4.1 переваривают по миллиону токенов за раз. Это примерно семьсот тысяч слов: вся трилогия «Властелин колец» плюс «Хоббит» помещаются в один промпт с запасом. Когда вся корпоративная база знаний теоретически влезает в окно модели, возникает резонный вопрос: а нужен ли вообще RAG?

Retrieval-Augmented Generation — подход, при котором модель сначала ищет релевантные документы в векторной базе, а потом генерирует ответ на их основе — стал стандартом для production-систем с 2024 года. Но рост контекстных окон породил альтернативу: просто скормить модели всё целиком и позволить механизму внимания самому найти нужное. Два подхода, два совершенно разных компромисса. Разбираем, где какой выигрывает, и почему вопрос «RAG или длинный контекст» — это ложная дихотомия, которая скрывает более интересные архитектурные решения.

Что такое инжекция контекста и почему она важна

Большие языковые модели обучены один раз и заморожены. Они знают мир до даты обучения и абсолютно ничего не знают о ваших внутренних документах, коде, переписках или событиях пяти минут назад. Если нужен ответ на основе приватных данных, приходится решать задачу контекстной инжекции: как передать модели правильную информацию в правильный момент.

Классический RAG делает это через промежуточный слой. Документы разбиваются на фрагменты, превращаются в векторы эмбеддингов, сохраняются в векторной базе. При запросе система ищет семантически близкие фрагменты и вставляет их в промпт. Длинный контекст избавляется от промежуточного слоя: документы идут напрямую в окно модели, а attention-механизм сам решает, на что смотреть. Проще архитектурно, но не очевидно лучше практически.

Три аргумента за длинный контекст

Схлопывание инфраструктуры. Production RAG — это сборка из множества компонентов: стратегия чанкинга, модель эмбеддингов, векторная база, реранкер, пайплайн синхронизации данных, мониторинг качества ретрива. Каждый компонент — точка отказа, каждый требует настройки и поддержки. Длинный контекст сводит архитектуру к двум шагам: получить данные и отправить их модели. Это не просто удобство — это снижение операционной сложности на порядок, особенно для команд без выделенных ML-инженеров. Меньше компонентов — меньше ночных дежурств, меньше неожиданных падений в продакшене, меньше времени на отладку.

Лотерея ретрива. Семантический поиск в векторной базе — вероятностный процесс. Он ищет математически близкие векторы, но «близость в векторном пространстве» не гарантирует релевантность для конкретного вопроса. Ответ может существовать в базе знаний, но ретривер его не найдёт — и модель никогда его не увидит. Это называют тихим отказом: система работает, но даёт неправильный или неполный ответ, и диагностировать причину сложно. С длинным контекстом такой проблемы нет: модель видит всё, и ответственность за поиск информации лежит на её механизме внимания, а не на отдельном ретривере. Конечно, модель тоже может промахнуться, но по крайней мере промах происходит в одном месте, а не в цепочке из пяти компонентов.

Проблема целостного анализа. RAG по определению возвращает изолированные фрагменты. Если ответ требует сопоставления двух документов целиком — например, выявить, какие требования безопасности из спецификации не попали в итоговый релиз — ретривер найдёт фрагменты про «безопасность» и «релиз», но не найдёт пробел между ними. Модель увидит отрывки из обоих документов, но не получит полной картины для сравнения. Длинный контекст решает это тривиально: оба документа загружаются целиком, и модель выполняет глобальное сравнение. Это особенно ценно в юридической и аудиторской работе, где пропущенная деталь может стоить миллионов.

Три аргумента за RAG

Повторное чтение текста. Длинный контекст создаёт массовую вычислительную неэффективность. Пятисотстраничный мануал — это примерно двести пятьдесят тысяч токенов. Если загружать его в промпт при каждом запросе, модель вынуждена обрабатывать весь мануал заново каждый раз. RAG платит эту стоимость один раз при индексации, а при запросе обрабатывает только небольшие релевантные фрагменты. Prompt caching частично решает проблему для статичных данных, но для часто обновляемых потоков — финансовые и временные издержки длинного контекста становятся ощутимыми. Представьте, что каждый вопрос сотрудника к внутренней базе знаний стоит в десять раз дороже только потому, что система перечитывает всю базу вместо нужного раздела.

Игла в стоге сена. Интуитивно кажется: если данные в контекстном окне, модель их использует. Исследования показывают иное. По мере роста контекста attention-механизм размывается: конкретный параграф, затерянный в середине двухтысячестраничного документа, часто игнорируется или заменяется галлюцинированными деталями из окружающего текста. Это известно как проблема «иглы в стоге сена» — наличие информации не равно её использованию. RAG решает это радикально: вместо стога сена модель получает только иглы — пять-десять релевантных фрагментов, в которых ответ гарантированно есть. Конечно, если ретривер промахнётся, модель вообще не увидит нужного, но когда ретривер попадает — качество ответа выше, потому что модель фокусируется на сигнале, а не шуме.

Бесконечный масштаб данных. Миллион токенов звучит впечатляюще, но в масштабе корпоративного дата-лейка это капля в море. Корпоративные хранилища измеряются терабайтами и петабайтами, и никакое контекстное окно их не вместит. Если нужен доступ ко всему массиву данных — от истории транзакций до архивов переписок — без слоя ретрива не обойтись. Векторная база остаётся единственным жизнеспособным складом, а RAG — единственным способом отфильтровать из него то, что поместится в окно модели. Даже при контексте в десять миллионов токенов enterprise не сможет загрузить всё целиком.

Когда какой подход выигрывает

Выбор зависит не от модной архитектуры, а от свойств данных и задачи. Длинный контекст оптимален, когда набор данных ограничен и требуется глобальное рассуждение: анализ конкретного юридического контракта, суммаризация книги, сравнение двух версий документа. Здесь упрощение инфраструктуры и целостность анализа перевешивают вычислительные затраты.

RAG остаётся незаменимым при навигации по неограниченным корпоративным базам знаний, где данные измеряются терабайтами и постоянно обновляются. Техническая поддержка, медицинские архивы, юридические базы прецедентов, финансовые транзакции — всё это требует фильтрации перед подачей в модель, и здесь векторная база — не избыточность, а необходимость.

Гибридные схемы становятся всё популярнее. Сначала RAG отбирает релевантные документы из огромного массива, затем длинный контекст позволяет модели проанализировать их целиком. Такой подход сохраняет масштабируемость ретрива и добавляет глубину анализа, которую даёт полный контекст. Но он требует более сложной оркестрации и не всегда оправдан для простых задач.

Есть и третий путь, который обсуждают всё чаще: агентные системы с памятью. Вместо того чтобы полагаться на статичный RAG-пайплайн или гигантский контекст, агент сам решает, какую информацию извлечь, когда обновить индекс и какие источники проверить. Такие системы комбинируют гибкость человеческого исследователя с масштабом машинного поиска, хотя и добавляют сложности в виде планирования, самоконтроля и управления ошибками. Пока агентные архитектуры остаются экспериментальными, но крупные игроки вроде Anthropic и OpenAI активно инвестируют в этот направление, предвидя, что следующее поколение AI-систем будет меньше зависеть от жёстко заданных пайплайнов.

Наконец, стоит упомянуть экономику. Длинный контекст дороже на запрос, но дешевле в инфраструктуре. RAG дешевле на запрос, но требует постоянной поддержки: обновление индексов, мониторинг дрейфа эмбеддингов, дообучение реранкеров. Для стартапа с ограниченными ресурсами длинный контекст может оказаться предпочтительнее просто потому, что не требует команды для поддержки векторной базы. Для крупного enterprise с терабайтами данных и выделенной ML-платформой — RAG остаётся экономически выгоднее. Переломный момент наступает, когда стоимость инфраструктуры RAG превышает переплату за длинный контекст — и этот порог сдвигается каждый год в пользу более дешёвых моделей с большими окнами.

Часто задаваемые вопросы

Можно ли полностью отказаться от векторной базы в 2026 году?

Нет, если речь идёт о корпоративных масштабах. Для небольших ограниченных наборов данных — до нескольких сотен тысяч токенов — длинный контекст действительно заменяет RAG. Но при терабайтах данных без слоя ретрива не обойтись.

Почему модель не находит информацию в длинном контексте, если она там есть?

Attention-механизм имеет ограниченную ёмкость фокуса. В очень длинных последовательностях информация в середине обрабатывается хуже, чем в начале или конце. Это не баг конкретной модели, а фундаментальное свойство трансформерной архитектуры, которое частично компенсируется улучшенными позиционными кодировками, но не устраняется полностью.

Стоит ли мигрировать существующий RAG на длинный контекст?

Если ваш набор данных ограничен и задачи требуют глобального анализа — миграция может существенно упростить архитектуру. Если данные масштабируются за пределы контекстного окна или требуют частых обновлений — RAG остаётся правильным выбором. Начните с пилота на ограниченном подмножестве данных и измерьте качество ответов и стоимость инференса.

Итог

RAG и длинный контекст — не конкуренты, а инструменты для разных условий. Длинный контекст выигрывает в простоте и целостности анализа на ограниченных данных. RAG выигрывает в масштабируемости, эффективности и точности при навигации по огромным корпоративным хранилищам. В 2026 году технологический ландшафт позволяет выбирать подход под задачу, а не подгонять задачу под доступную технологию. Ключевой вопрос при проектировании системы: ваши данные измеряются страницами или петабайтами?