RAG, поиск и LongContext: почему сложные пайплайны не всегда нужны

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

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

Сегодня многие модели держат 1M токенов, а то и больше, а в это окно контекста чаще всего спокойно влезает вся документация. Но если не влезет — то обязательно ли сразу строить весь RAG самому? А как понять, когда есть альтернатива RAG, а когда нет?

В этой статье мы разберём, почему RAG стал выбором по умолчанию (и почему это было оправдано), посмотрим, как падает качество при Long Context, сравним подходы и узнаем, что, как и когда использовать.

В 2023 году RAG де-факто был единственным рабочим способом засунуть знания в LLM. Контекстное окно тогда составляло 4–8K токенов, что равнялось около 10–20 страницам текста. Попытка загрузить в модель документацию на 400 страниц заканчивалась плачевно — только часть документа была обработана. RAG стал панацеей — чанкинг, эмбеддинги, векторная база, реранкер, целая поисковая система.

Альтернативы, по типу Long Context, проигрывали в точности — LLM часто запоминали только начало и конец, а середину по остаточному принципу, что могло привести к галлюцинациям.

Но технологии не стоят на месте. Сегодня флагманские модели держат контекстное окно в 1 миллион токенов. GPT, Claude, GLM — все они официально в большей части случаев заявляют о поддержке 1M+ токенов. 400 страниц документации (~250K токенов) для них — не проблема.

И тут возникает закономерный вопрос: и зачем нужен RAG теперь?

Вот типичная ситуация. Какая-нибудь компания «ООО Рога и Копыта» хочет чат-бота по своей документации по уходу за домашним скотом. Приходит разработчик и говорит: «Нужен RAG-пайплайн! Чанкинг, эмбеддинги, векторная база, реранкер, всё по красоте». На это уходит 2–3 месяца разработки, затем ещё поддержка (обновлять эмбеддинги, следить, чтобы не депрейкнули модель, базу данных мониторить). А ведь эта самая документация вполне помещается в контекст одной модели!

Невольно задаёшься вопросами, всегда ли нужен RAG, где проходят границы профита между Long Context и RAG, и главное — как понять, выгодно потратить время и ресурсы на полноценную базу данных или хватит LLM?

Но почему RAG?

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

И RAG быстро прижился и стал неким «лингва франка» для работы с базой знаний. Он позволял быстро работать с корпусами любого размера, хоть мегабайты, хоть терабайты, векторная база всё обработает, пока позволяют ресурсы. А также RAG давал ссылки на источники. В энтерпрайзе и компаниях это весьма критично, чтобы понимать, что ИИ не выдумал ничего, и можно было, допустим, отсылаться в отчётах на определённый документ. Кроме того, всё это помогало экономить на токенах: вместо того чтобы заполнять контекст модели, RAG отдаёт чанки. Ну и инфраструктура — LangChain, векторные БД (Milvus, Qdrant и другие), всё это развивалось чаще всего с оглядкой на RAG. Готовые решения, гайды, туториалы, курсы — всё это построилось.

Ну и разработчики привыкли к RAG как к эталонному решению, и если нужно как-то сделать поиск по документации, возникает идея о нём.

Но не всегда RAG подходит, иногда модель может сама переварить документацию благодаря большому контекстному окну, и строить пайплайн уже не так и выгодно. Например, Long Context может спокойно заменить всё это. Или нет?

Разберем Long Context

Прежде чем голословно говорить, что RAG не нужен, давайте поймём, где, как и почему Long Context может провалиться, ибо 1M токенов не всегда решает все проблемы.

Выше я говорил, что LLM склонны фокусироваться на начале и конце сообщения. В 2023–2025 годах исследователи (Lost in the Middle: How Language Models Use Long Contexts и Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization) обнаружили, что LLM не читают контекст равномерно. Внимание модели следует U-образной кривой — информация в начале и конце контекста обрабатывается хорошо, а середина проваливается в «чёрную дыру».

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

Работа 2026 года Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias доказывает математически: U-образная кривая — это следствие архитектуры трансформера, а не артефакт обучения.

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

И в нынешнем 2026, если релевантная информация разбросана по контексту, и между ней много шума, и нужно достать несколько фактов, точность падает.

RULER Benchmark: эффективный размер контекста меньше заявленного

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

Исследователи протестировали 17 моделей с заявленным контекстом от 4K до 128K токенов. На простом NIAH-тесте почти все показывают близкую к идеальной точность. Но на RULER картина меняется радикально.

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

Ещё один тревожный паттерн: с ростом контекста модели начинают больше полагаться на параметрические знания (то, что запомнили при обучении) и копировать из контекста вместо того, чтобы рассуждать.

Исследователи из NVIDIA формулируют это так: заявленный контекст — это потолок, а не рабочая зона. Эффективный контекст — обычно 50–65% от заявленного. Для современных моделей с 1M токенов реальная рабочая зона может быть 500–650K. Уже в разы лучше, чем в 2023 году, но всё ещё есть куда расти.

Если подвести итог архитектуры трансформера и U-образной кривой, то даже моделью с 10M контекста информация в середине будет обрабатываться хуже, чем в начале и конце. И если ваш корпус документов — это сотни страниц, где ответ может быть где угодно, Long Context не является надёжным решением.

Именно здесь RAG показывает своё преимущество: вместо того чтобы надеяться, что модель найдёт нужное в 500K токенов, вы явно подаёте ей 5–10 релевантных чанков.

Контекстное утомление (Context Rot)

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

Явление получило название context fatigue, или context rot — контекстное утомление/гниение. И оно напрямую связано с тем, о чём мы говорили выше: чем больше токенов накапливается в окне, тем туже и хуже модель справляется с задачей извлечения конкретного факта, особенно если этот факт находится не в начале и не в конце, и ещё хуже, если фактов несколько.

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

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

LongMemEval показал ту же картину: в диалогах на ~113K токенов все модели показывают значительно худшие результаты на полных промптах по сравнению с фокусированными. Добавление нерелевантной истории заставляет модель выполнять две задачи одновременно — retrieval и reasoning — и обе деградируют.

И тут даже RAG не спасает, увы. Правильные чанки на первом вопросе, на втором, на третьем, но к пятнадцатому — контекст забит предыдущими ответами, уточнениями, исправлениями и тупиковыми ветками. Модель, увы и ах, уже не может отличить, что важно сейчас, от того, что было важно десять ходов назад.

ACM Digital Library опубликовал бенчмарк, где сравнивали три архитектуры на реальной технической документации (300 страниц):

Long Context работает прекрасно для средних текстов. Первые 10–15 вопросов — точность 85%+. Но потом начинается мракобесие: модель перегружена, внимание размывается, точность падает до 65–70%. И это при том, что стоимость в 85 раз выше, чем у RAG.

RAG в том же исследовании показывает стабильные 85–90% на всём протяжении сессии. Каждый запрос независим — чанки не накапливаются в контексте, история не забивает рабочую память.

Исследование WiCER на 17 доменах RepLiQA (6,800 вопросов) подтверждает: full-context KV cache выигрывает на курированных знаниях (4.38 vs 4.08 из 5), но деградирует ниже RAG при масштабировании из-за «attention dilution».

Проблема context rot решается управлением контекстом. Anthropic в своих рекомендациях по context engineering предлагает несколько стратегий:

Компактизация — когда разговор приближается к лимиту, суммировать его содержимое и начинать новое окно с этим саммари. Claude Code именно так и работает — сохраняет архитектурные решения, нерешённые баги и детали реализации, отбрасывая избыточные выводы инструментов.

Очистка результатов инструментов: если инструмент был вызван глубоко в истории, сырой результат можно отбросить — он уже не релевантен.

Субагенты: специализированные агенты обрабатывают узкие задачи в чистых контекстных окнах. Каждый субагент может использовать десятки тысяч токенов, но возвращает только сжатое резюме (обычно 1000–2000 токенов).

То бишь, «retrieval pipeline» может быть идеальным, стратегия чанкинга выверенной, но если вы строите разговорный интерфейс поверх документов — управление этим самым разговором и есть слабое место.

Когда вы решаете между Long Context и RAG, вы решаете не то, сколько токенов, а то, как будет действовать система в длительных чатах.

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

RAG проще, чем кажется

И наконец перейдём к сути статьи — большинство людей переусложняют RAG-стек. Они сразу бегут к эмбеддингам, векторным базам и реранкерам, тогда как пользователю часто нужно просто найти документ с ответом. Начинать стоит сверху (с простого), и переходить к сложному только тогда, когда данные покажут, что это необходимо.

И давайте разберём, какие могут быть шесть уровней.

Только BM25

Просто поиск по ключевым словам, ровно тот же алгоритм, что использовался в поисковиках задолго до нейросетей. BM25 ранжирует документы по частоте терминов с учётом длины документа и насыщенности.

Работает, когда документация структурирована и пользователи ищут по конкретным терминам (названия функций, коды ошибок, артикулы). Если человек вводит конкретный термин, BM25 найдёт это быстрее и точнее любого эмбеддинга, ибо точное совпадение строки — это то, что BM25 делает идеально.

LLM трансформирует запрос

Здесь добавляется один вызов модели. Пользователь пишет «как починить то, что сломалось после обновления», LLM превращает это в «инструкция по откату обновления» — и дальше идёт обычный BM25-поиск. Это хорошо подходит, если запросы нечёткие, пользователи формулируют вопросы на естественном языке, а документация структурирована.

Гибридный поиск (BM25 + эмбеддинги)

И здесь впервые появляются эмбеддинги. BM25 отбирает кандидатов по ключевым словам, а эмбеддинги ловят семантически близкие документы. Результаты объединяются через взвешенный скор (обычно 0.3 BM25 + 0.7 косинусное сходство или наоборот). Работает, если данные постоянно обновляются и нужен баланс точности и полноты. Довольно удобный и популярный рецепт, даёт хорошее качество без переусложнения.

Эмбеддинги без векторной БД

Вместо того чтобы хранить все векторы в базе, документы эмбеддятся в момент запроса. Это звучит странно, но имеет смысл, если у вас 50 документов и они меняются каждый день, хранить их эмбеддинги имеет мало смысла, они устаревают быстро. Подходит, если данные меняются часто и ежедневно, критична свежесть, малое количество документов (K = 20–50). Плата за свежесть — это латентность: 200–500 мс на запрос уходит на генерацию эмбеддингов.

Горячие и холодные уровни

Интересное решение, основанное на Парето-распределении — 20% документов дают 80% запросов. Популярные документы хранятся в векторной БД (быстро, но занимает место), редкие — эмбеддятся на лету (медленно, но не требует хранения).

Работает, если у вас есть чёткое разделение популярное и редкое, и вы готовы поддерживать два уровня сложности ради экономии.

Классический RAG

Все документы проэмбеддированы заранее, лежат в векторной БД, реранкер переранжирует топ-K кандидатов. Это и есть тот самый ресурсоёмкий пайплайн. Подходит, если у вас данные стабильны, латентность критична, корпус большой, документация большая. Классический сценарий — огромная документация, которая меняется раз в квартал, и тысячи запросов в день.

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

Так когда Long Context выгоднее RAG?

А когда Long Context всё-таки лучше, чем RAG? Мы разобрали, где Long Context проваливается технически. Но технические ограничения — это только половина картины, а вторая-то половина — деньги, и здесь всё становится ещё интереснее, потому что экономика может полностью перевернуть техническое решение. Бывает так, что Long Context объективно хуже по качеству, но настолько дешевле в разработке и поддержке, что выбор очевиден. А бывает наоборот: RAG кажется дорогим на старте, но окупается за месяц на объёме.

Давайте посчитаем на конкретном примере. Возьмём модель уровня GPT-5.4 с ценами $2.50 за миллион входных токенов и $15 за миллион выходных. Это средний сегмент, не топ и не бюджет. Кстати, приобрести доступ к этой и другим ИИ из России вы можете через наш сервис BotHub, сможете получить для тестирования 300 тысяч бесплатных CAPS, перейдя по реферальной ссылке.

Сценарий примерно такой: у вас документация на 70 тысяч токенов (примерно 100–120 страниц). Пользователь задаёт вопрос, вы даёте ответ.

При Long Context вы отправляете всю документацию в контекст — 70 тысяч входных токенов. При Chunk-RAG вы отправляете только 3.4 тысячи токенов (5–7 релевантных чанков плюс системный промпт). Выход одинаковый — около 500 токенов на ответ.

Разница в цене за запрос — 8.5 раз. На тысяче запросов это $68 против $8. Вроде бы очевидно, что RAG выигрывает, да?

Но стоит лишь посмотреть на 30-дневную проекцию при 10 запросах в день…

… то видно, что за месяц разница — $20, не так уж и много. Если вы строите внутренний бот для отдела из десяти человек, эти $20 не окупят даже часа вашей зарплаты. Если вы строите публичный продукт на миллион запросов в месяц, разница уже $60,000 — здесь RAG обязателен.

А можно еще и оформить более дешевую модель, например gpt-5.6-luna, которая в BotHub, которая позволит сэкономить, если вам не нужно сверх-качество.

Контекстное кэширование ломает математику

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

Многие говорят, мол, для корпусов до 200 тысяч токенов полный контекст с кэшированием может быть дешевле, чем построение RAG-пайплайна. Логика тут есть, ибо если документация статична, вы платите за кэширование один раз, а потом каждый запрос стоит копейки.

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

Если вы всё сделали правильно, экономика Long Context с кэшированием становится совсем другой. Вместо $0.068 за запрос вы платите условные $0.01–0.02. Разница с RAG сокращается до 1.5–2 раз, а с учётом стоимости разработки и поддержки RAG может оказаться, что Long Context выигрывает.

В итоге давайте приведём всё сказанное к формуле окупаемости: Точка окупаемости RAG = стоимость разработки и поддержки ÷ разница в цене запроса.

Если вы потратили 200 часов на разработку RAG-пайплайна (условно $10,000), а каждый запрос экономит $0.06 по сравнению с Long Context, то RAG окупится после 166,000 запросов. При 10,000 запросов в месяц это 16 месяцев, при 100,000 запросов в месяц — меньше двух месяцев…

Внутренний бот для ста сотрудников — это 5–10 тысяч запросов в месяц. Даже если каждый запрос через Long Context стоит в 8 раз дороже, чем через RAG, экономия в $50–100 в месяц не окупит 200 часов разработки за разумное время. В итоге-то проще загрузить документацию в контекст, включить кэширование и забыть.

Но как только вы выходите на внешних пользователей или строите продукт, математика меняется радикально. При 100 тысячах запросов в месяц RAG окупается за пару месяцев, а дальше начинает приносить чистую экономию.

Как выбрать?

Выбор архитектуры зависит от трёх параметров: объём корпуса, частота обновления, количество запросов.

Из этой таблицы можно сделать вывод, что чем дешевле токены, тем дольше вам выгодно не строить RAG. Если цена за миллион токенов продолжит падать (а она падает), точка окупаемости RAG будет сдвигаться всё дальше. То, что окупалось за месяц год назад, сегодня может окупаться за полгода. А то, что не окупалось никогда, теперь может стать выгодным.

И стоит понимать, что это не универсальное решение. Может быть, у вас есть требования к безопасности, которые делают RAG обязательным независимо от экономики. Может быть, у вас есть команда, которая уже умеет строить RAG, и разработка займёт не 200 часов, а 20. Может быть, у вас есть регуляторные требования к ссылкам на источники, которые Long Context не может обеспечить.

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