RAG или Long Context: когда действительно нужен сложный пайплайн, а когда хватит большого окна LLM

В 2023 году архитектура RAG (Retrieval-Augmented Generation) воспринималась как единственное жизнеспособное решение для подключения собственной базы знаний к большим языковым моделям. Контекстные окна тогда были ограничены скромными 4–8K токенов — это примерно 10–20 страниц текста. Если требовалось заставить нейросеть проанализировать технический регламент или руководство на 400 страниц, без извлечения фрагментов через векторную базу обойтись было невозможно. RAG моментально стал стандартом отрасли, породив масштабную экосистему из векторных хранилищ, реранкеров и фреймворков.

Однако к настоящему моменту ситуация кардинально изменилась. Современные флагманские языковые модели — от семейств GPT и Claude до передовых открытых решений — штатно поддерживают контекстные окна объемом в 1 миллион токенов и более. В такое окно легко помещается объемистый корпус документов целиком. В связи с этим в среде разработчиков и инженеров все чаще возникает вопрос: разумно ли инвестировать месяцы работы и значительный бюджет в развертывание и обслуживание сложной инфраструктуры RAG, если можно просто передать весь массив информации напрямую в промпт?

В этом материале я детально разберу, почему RAG стал выбором по умолчанию, в каких сценариях огромный контекст проигрывает из-за архитектурных особенностей нейросетей, как проявляется деградация внимания (Context Rot), какие существуют шесть градаций сложности поисковых систем и как финансовый расчет помогает выбрать оптимальный подход.

Почему RAG стал стандартом по умолчанию?

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

• Масштабируемость корпуса: векторная база данных способна индексировать гигабайты и терабайты текстовой информации, оперативно отдавая только релевантные куски.
• Точные ссылки на источники: для корпоративного сегмента критически важно знать, из какого конкретного абзаца или файла модель взяла факт, что минимизирует риск галлюцинаций в отчетах.
• Экономия токенов на отдельный запрос: вместо передачи сотен тысяч токенов при каждом обращении модель получает лишь 5–10 компактных фрагментов (чанков).
• Развитая инфраструктура: появление инструментов вроде LangChain, Qdrant, Milvus и Pinecone упростило сборку типовых решений.

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

Анатомия и слабые места Long Context

Казалось бы, решение очевидно: отбросить RAG и загружать все файлы прямо в контекст. Но на практике гигантское контекстное окно на 1M токенов не гарантирует безупречной работы. Исследования последних лет раскрывают важные технические нюансы работы трансформеров.

Еще в базовых работах по анализу длинного контекста (включая известное исследование Lost in the Middle) ученые зафиксировали: языковые модели обрабатывают входной текст неравномерно. Распределение внимания напоминает U-образную кривую. Модель прекрасно считывает и запоминает факты, расположенные в самом начале и в самом конце сообщения, тогда как середина контекста оказывается в зоны пониженного внимания.

Математические исследования подтверждают: это U-образное искривление внимание — не дефект обучения, а прямое следствие архитектуры трансформеров. Сочетание причинного маскирования (causal masking), остаточных связей (residual connections) и механизмов позиционного кодирования (например, RoPE) приводит к тому, что с увеличением расстояния между токенами связь между ними естественным образом затухает. Если ключевая деталь затерялась в середине 500-страничного массива данных среди шума, шанс промаха модели существенно возрастает.

Бенчмарк RULER: реальный контекст существенно меньше заявленного

Стандартный тест «иголка в стоге сена» (NIAH) проверяет лишь точечное умение модели найти один изолированный факт в длинном тексте. Чтобы оценить реальные возможности моделей при сложной работе, исследователи из NVIDIA разработали бенчмарк RULER. Он проверяет способность модели извлекать множество фактов одновременно, отслеживать логические цепочки (A → B → C) и агрегировать данные по всему тексту.

Тестирование 17 современных нейросетей с заявленным контекстом от 4K до 128K токенов показало показательную картину. В то время как с простым тестом NIAH справились почти все, на бенчмарке RULER эффективную работу с 32K токенов продемонстрировала лишь половина участников. При приближении к пределу заявленного окна точность большинства моделей резко падает.

Эксперименты NVIDIA показали: реальная «рабочая зона» современной LLM составляет порядка 50–65% от паспортного значения. Для модели с заявленным окном в 1 миллион токенов надежно обрабатываемый объем равен примерно 500–650K токенов. При этом с ростом объема контекста модели начинают чаще полагаться на свои заученные параметрические знания или механически копировать фрагменты текста вместо проведения логических рассуждений.

Эффект «утомления» контекста (Context Rot)

Второй серьезной проблемой при эксплуатации Long Context в реальных диалоговых системах является так называемое «контекстное утомление» (Context Rot). Оно проявляется во время длительных сессий общения.

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

Исследования Chroma Research и бенчмарк LongMemEval подтверждают: при накоплении порядка 100K+ токенов истории диалога точность ответов на простые вопросы снижается. В многошаговых диалогах RAG демонстрирует преимущество по стабильности: поскольку каждый запрос изолирован и подтягивает только свежие релевантные чанки, качество ответов остается устойчивым на уровне 85–90% как на первом, так и на пятидесятом шаге.

Чтобы бороться с эффектом Context Rot в системах с длинным контекстом, применяют специальную инженерию контекста (Context Engineering):

• Компактизация (Compaction): при приближении к лимиту диалог автоматически суммаризируется, а устаревшие логи вызовов отбрасываются (по такому принципу работает, например, Claude Code).
• Очистка вызовов инструментов: результаты работы внешних API и поиска, полученные несколько ходов назад, удаляются из рабочей памяти.
• Использование субагентов: узкие подзадачи делегируются отдельным агентам с изолированными чистыми контекстами, которые возвращают лишь итоговый сжатый результат.

Градация сложности: 6 уровней архитектуры RAG

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

1. Поиск BM25 (только ключевые слова): классический полнотекстовый поиск. Идеален для четко структурированной технической документации, артикулов, кодов ошибок и названий функций, где пользователь вводит точные термины. Работает мгновенно и не требует нейросетевых эмбеддингов.
2. Трансформация запроса через LLM + BM25: нейросеть принимает нечеткий пользовательский вопрос на естественном языке, перефразирует его в точные поисковые ключевые слова и отправляет в алгоритм BM25.
3. Гибридный поиск (BM25 + эмбеддинги): комбинация ключевых слов и семантического векторного поиска. BM25 обеспечивает точные совпадения редких терминов, а векторы находят смысловые аналогии. Результаты объединяются взвешенным ранжированием.
4. Генерация эмбеддингов на лету (без векторной БД): если корпус содержит всего 20–50 постоянно обновляемых документов, хранить векторы в базе нет смысла. Эмбеддинги создаются в момент запроса. Это гарантирует абсолютную свежесть данных ценой небольшой задержки (200–500 мс).
5. Двухуровневая архитектура (горячие и холодные данные): по правилу Парето около 20% документов генерируют 80% всех запросов. Часто запрашиваемые материалы индексируются в векторной БД для быстрого доступа, а редкие документы обрабатываются на лету.
6. Классический полнофункциональный RAG: предварительная индексация всего корпуса в векторном хранилище, двухэтапный поиск и использование модели-реранкера (Reranker) для финальной отбраковки кандидатов. Это оптимальный выбор для стабильных и гигантских массивов знаний.

Экономика решений: когда Long Context реально выгоднее RAG?

Техническая сторона вопроса — лишь половина дела. Окончательное решение всегда упирается в финансово-экономический расчет. Давайте разберем его на наглядном примере.

Предположим, у нас есть база знаний объемом 70 000 токенов (около 100–120 страниц текста). Возьмем модель среднего ценового сегмента (условно $2.50 за 1M входных токенов и $15.00 за 1M выходных токенов). Сравним два подхода при ответе на один вопрос (длина ответа — 500 токенов):

• Long Context: на каждый запрос передается вся документация (70 000 токенов). Стоимость одного запроса составляет около $0.068.
• Chunk-RAG: в промпт передается только системное указание и 5–7 найденных чанков (всего порядка 3 400 токенов). Стоимость одного запроса — всего $0.008.

На первый взгляд, RAG выгоднее в 8.5 раз. На 1 000 запросов разница составит $68 против $8. Однако ключевое значение имеет суммарная интенсивность использования системы. Если вы создаете внутренний помощник для небольшого отдела на 10 человек, генерирующий около 10 запросов в день (300 запросов в месяц), разница в расходах на API составит порядка $18–20 в месяц. Инжиниринг, настройка и поддержка RAG-пайплайна отнимут десятки часов работы программиста, что никогда не окупится экономией двадцати долларов на токенах.

Как контекстное кэширование меняет математику расходов

Ситуация становится еще интереснее при использовании механизма кэширования промптов (Prompt Caching), который поддерживают большинство современных провайдеров API. Если системная инструкция и массив документации остаются неизменными на входе, повторные запросы к кэшированному контексту обходятся в разы дешевле (скидка может достигать 75–90%).

При правильной структуре промпта (когда статичный массив документов размещен в самом начале, а динамический вопрос пользователя — в конце) стоимость запроса в режиме Long Context падает с $0.068 до $0.01–0.02. В этом случае разница с RAG сокращается до символических величин, а простота архитектуры без сторонних баз данных становится определяющим преимуществом.

Точку окупаемости RAG можно рассчитать по простой формуле:

Точка окупаемости (кол-во запросов) = Затраты на разработку и поддержку / Экономия на одном запросе

Если разработка пайплайна RAG обошлась в $5,000, а экономия с каждого запроса составляет $0.05, система начнет приносить чистую финансовую выгоду только после 100,000 обработанных запросов. Для публичного сервиса с высоким трафиком RAG окупится за пару недель. Для служебного внутреннего чат-бота он может не окупиться никогда.

Практическая матрица выбора архитектуры

Для удобства я свожу основные критерии выбора архитектуры в итоговую табличную матрицу:

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

Источник: habr.com