Современные языковые модели принимают сотни тысяч токенов за один запрос — это десятки и сотни страниц текста. Отсюда соблазн: забыть про векторные базы и поиск, просто вкладывать все документы в промпт. Приём работает — на маленьких и стабильных наборах. На реальной базе компании, которая живёт и обновляется, экономика разворачивается в пользу поиска с дополнением (RAG).
Эта страница сводит выбор в таблицы «когда что» и критериев: стоимость, скорость, свежесть данных, прослеживаемость и безопасность. RAG здесь — подход «сначала найти, потом ответить»; его место относительно дообучения модели — в смежном гиде «RAG или fine-tuning», а фундамент — в термине «контекстное окно LLM».
Кратко: когда что выбирать
Прямой ответ — в таблице: слева ситуация, справа разумное решение по состоянию на сентябрь 2026 года. Если узнали свою компанию в одной из строк — дальше достаточно проверить решение по чек-листу в конце страницы, а не перечитывать весь интернет.
| Ситуация | Подход | Почему |
|---|---|---|
| Десятки–сотни страниц, набор меняется редко | длинный контекст | проще системы: нечего индексировать и поддерживать |
| База растёт: тысячи страниц, новые документы еженедельно | RAG | в запрос попадают релевантные фрагменты, а не вся база |
| Ответ обязан ссылаться на пункт документа | RAG | поиск выдаёт источник цитаты; «весь промпт» — не ссылка |
| Чувствительные данные, лишнее показывать нельзя | RAG | в модель уходит только найденный фрагмент под этим запросом |
| Разовые аналитические задачи, стоимость не критична | длинный контекст | качество полноты выше: модель видит документ целиком |
| Массовый поток однотипных запросов (поддержка, поиск) | RAG | короткий контекст = дешевле каждый ответ и быстрее |
Критерии сравнения
Развёрнутая матрица по критериям, которые заказчики проверяют перед решением: стоимость, сроки, риски, поддержка, комплаенс и режим данных. Каждая строка матрицы ниже раскрыта отдельным разбором — с пояснениями, откуда берутся цифры и на что смотреть в вашей ситуации.
| Критерий | Длинный контекст | RAG |
|---|---|---|
| Стоимость запроса | растёт линейно с размером базы: платите за все страницы каждый раз | платите за несколько найденных фрагментов |
| Стоимость системы | нет отдельной инфраструктуры | пилот от 480 000 ₽, промышленный контур — от 690 000 ₽ |
| Скорость ответа | медленнее на больших промптах: тысячи токенов обрабатываются дольше | быстрее: короткий контекст + миллисекунды поиска |
| Свежесть данных | пересборка промпта при каждом изменении набора | переиндексация изменившихся документов — автоматически |
| Прослеживаемость | ссылку на источник модель формулирует сама — с ошибками | поиск возвращает конкретный фрагмент и источник |
| Качество на объёме | модель «тонет» в лишнем тексте: внимание размывается | в контексте только релевантное — точность выше |
| Безопасность данных | вся база уходит в каждый запрос и логи | уходит фрагмент под конкретный запрос; доступы разграничиваются |
Матрица выше — навигация: каждая строка раскрыта разбором ниже, а итоговая формула зависит от объёма базы и числа запросов.
Разбор критериев
Экономика токенов
Главный аргумент против «просто вложить всё» — счёт. При длинном контексте вы платите за обработку всей базы в каждом запросе, даже если ответ лежит на одной странице; при RAG — только за найденные фрагменты и короткий ответ. На десятке запросов в день разницы нет, на тысячах — отличие становится строкой бюджета. Что само собой входит в стоимость RAG-системы, разбирает ответ на вопрос «сколько стоит свой RAG по документам».
Качество: внимание размывается
Второй аргумент менее очевиден: длинный промпт не гарантирует лучшего ответа. Модели хуже находят детали в середине большого контекста, а конкурирующие пункты разных документов приводят к усреднённым или противоречивым формулировкам. Поисковая выдача из пяти релевантных фрагментов часто даёт более точный ответ, чем тот же фрагмент, погружённый в четыреста страниц: внимание модели распределяется по меньшему объёму.
Свежесть и сопровождение
База компании живёт: регламенты переиздаются, прайсы меняются, договоры подписываются. В схеме с длинным контекстом каждое изменение требует пересборки промпта — и рано или поздно кто-то забудет это сделать, а модель продолжит отвечать по устаревшей версии без предупреждения. В RAG переиндексация нового документа — штатная операция, и свежесть становится свойством системы, а не дисциплиной сотрудников.
Прослеживаемость и ссылки
Для юридических, финансовых и регуляторных сценариев ответ без источника бесполезен. RAG возвращает фрагмент и ссылку на документ силами поиска — это проверяемо и аудитопригодно. Длинный контекст заставляет модель саму угадывать, из какого места огромного промпта взят ответ; угадывает она с ошибками. Если цитата — требование, выбор подхода закрыт.
Гибрид: RAG плюс длинный контекст
Подходы не исключают друг друга. Рабочая схема 2026 года: поиск отбирает пять–десять релевантных фрагментов, а достаточно большое контекстное окно позволяет отдать их целиком, вместе с оглавлениями и структурой разделов — без агрессивной нарезки на чанки. Как готовить документы к такому режиму, разбирает гайд «как подготовить данные для RAG»; гибридные схемы поиска — «гибридный поиск и переранжирование».
Когда длинный контекст всё же выигрывает
Честно про обратную сторону: анализ одного договора на двадцать страниц, разовый аудит регламента, работа с одним большим отчётом — здесь вложить документ целиком проще и качественнее, чем строить индекс ради трёх запросов. Правило: если набор документов умещается в контекст, меняется редко и запросов немного — системе поиска не место, достаточно аккуратного промпта.
Вердикты по трём сценариям
Сценарий 1. Закрытый набор документов до ~300 страниц
Длинный контекст: без векторной базы и её сопровождения, разработка сокращается до промпта и проверки. Прототип такого ассистента — от 90 000 ₽. Заранее заложите пересборку промпта при изменении документов — это единственное ручное действие схемы.
Сценарий 2. Живая база знаний с обновлениями
RAG: пилот — от 480 000 ₽, промышленный контур с переиндексацией, правами доступа и цитированием — от 690 000 ₽. Каждый ответ ссылается на источник, свежесть поддерживается автоматически, стоимость запроса не растёт вместе с базой. Полный корпоративный портал поиска — 0,9–1,2 млн ₽.
Сценарий 3. Массовые клиентские запросы
RAG безальтернативно: тысячи однотипных обращений в сутки при длинном контексте разоряют на токенах и отвечают медленно. Поиск отбирает фрагменты за миллисекунды, ответ модели короткий и цитируемый. Сравнение с классическим полнотекстовым поиском — в гиде «векторная БД против полнотекстового поиска».
Типичные ошибки выбора
Типичные ошибки выбора между этими подходами стоят либо лишних денег, либо потерянного доверия к системе.
- Считать RAG «сложным» на маленьком наборе — и наоборот, строить индекс ради трёх документов.
- Класть в длинный контекст базу целиком «чтобы ничего не потерять» — и платить за это каждый запрос.
- Нарезать документы на чанки без структуры: заголовки и оглавления теряются, качество падает.
- Отказываться от цитат там, где ответ проверяют юристы или аудиторы.
- Не закладывать переиндексацию: база обновляется, а система отвечает по прошлогодней версии.
Итог
Длинный контекст — для малых стабильных наборов и разовой аналитики; RAG — для живых баз, массовых запросов и сценариев, где нужна ссылка на источник. Решение стоит перепроверить на своих цифрах: разбор задачи бесплатный, ответ — за 1 рабочий день.
Чек-лист решения
Семь пунктов, которые стоит закрыть до выбора: они одинаково полезны обоим вариантам и закрывают большинство ошибок из списка выше. Пройдите список с командой — обычно это один рабочий час, который экономит недели переделок.
- Посчитайте объём базы в страницах и оцените частоту изменений документов.
- Оцените число запросов в сутки и умножьте на стоимость полного контекста.
- Выпишите сценарии, где ответ обязан сопровождаться цитатой и источником.
- Определите классы данных: что можно в облачную модель, что только в контур.
- Решите, нужен ли гибрид: поиск по базе плюс большие фрагменты в окне.
- Заложите регламент переиндексации или пересборки промпта при изменениях.
- Соберите тестовый набор вопросов с эталонными ответами до выбора подхода.
Смежные материалы
Место RAG относительно дообучения — «RAG или fine-tuning»; выбор хранилища — «векторная БД против полнотекстового поиска»; нижний уровень — «что такое RAG» и «контекстное окно LLM». Реализация — pgvector для RAG.
Полный каталог разборов «или — или» — в разделе Сравнения; форматы работ, сроки и цены «от» — в каталоге услуг.