Контекстное окно против RAG и дообучения: что выбрать

Три способа «научить» LLM работать с вашими данными и задачами - положить всё в контекстное окно, подключить RAG (retrieval-augmented generation) или дообучить модель. У каждого подхода своя цена, скорость обновления знаний и предел точности. Ниже - как они устроены, чем отличаются и как выбрать стратегию для чат-бота, ассистента поддержки или внутреннего copilot без лишних затрат.

Коротко: что это значит для бизнеса

• Три способа «научить» модель ваших данных — контекстное окно (весь текст в промпт), RAG (поиск + генерация), дообучение (веса модели) — у каждого своя цена и скорость обновления знаний.
• Контекстное окно проще всего запустить, но дорожает с длиной и не годится для больших баз — подходит для пилота и небольшого стабильного корпуса (5-50 документов).
• RAG — стандарт для масштабируемых баз знаний: индекс обновляется за минуты, ответы можно подкреплять цитатами источников, но нужна инфраструктура (векторная БД, пайплайн).
• Дообучение — самое дорогое и медленное решение, оправдано только при стабильном формате ответа и тысячах готовых примеров; для новых фактов оно не заменяет RAG.
• В продакшене подходы обычно комбинируют: дообучение задаёт стиль, RAG приносит факты, короткий контекст — системные правила и историю диалога.
• Хорошо подходит: бизнесу, который выбирает архитектуру для чат-бота или ассистента поддержки и хочет не переплатить за лишнюю инфраструктуру. Плохо подходит: как готовый рецепт «на все случаи» — выбор зависит от объёма данных, частоты обновления и бюджета.

Три подхода одной задачи

Задача одна: модель должна отвечать на вопросы о вашем продукте, документации, политиках или домене - а не только о том, что было в предобучение. Решения:

Часто выбирают не «или», а комбинацию: RAG для фактов, дообучение для стиля и формата, длинный контекст - для небольшого набора документов в одном запросе.

Контекстное окно: всё в промпт

Контекстное окно - объём текста (в токенах), который модель «видит» за один запрос: системный промпт, история диалога, прикреплённые файлы и инструкции.

Как это работает

Вы кладёте в промпт:

• system-инструкции («отвечай как юрист компании X»);
• релевантные документы целиком или крупными кусками;
• примеры в промпте («вот образец хорошего ответа»).

Современные модели (GPT-5.6, Claude Fable 5, Gemini 3.5 Flash) поддерживают 1-2M токенов контекста - это сотни страниц текста. Для многих сценариев этого достаточно без отдельной инфраструктуры.

Плюсы

• Минимальная инфраструктура - не нужен векторный индекс и пайплайн обновления эмбеддинги.
• Мгновенное обновление - поменяли текст в промпт, знания обновились сразу.
• Прозрачность - вы точно знаете, что модель «видит» в этом запросе.
• Примеры в промпте без обучения - примеры в промпте задают формат ответа.

Минусы

• Стоимость растёт с длиной - тарифы у провайдеров на длинный контекст часто x1.5-x2 к базовому.
• Потолок объёма - даже 2M токенов не вместят всю корпоративную базу знаний.
• Качество на «игле» - модель может «терять» детали в середине очень длинного контекста.
• Задержка - больше токенов на input - дольше первый ответ.

Когда выбирать контекст

• Небольшой и стабильный корпус: 5-50 документов, один продукт, один FAQ.
• Прототип или MVP - проверить гипотезу за день без RAG-стека.
• Задача с полным текстом в одном запросе: сравнение двух договоров, ревью кода всего PR.
• Нужен полный контроль над тем, что попало в prompt (аудит, compliance).

RAG: поиск + генерация

RAG - перед ответом система ищет релевантные фрагменты в вашей базе (векторный поиск, BM25, гибрид), подставляет их в промпт и модель генерирует ответ с опорой на найденное.

Как это работает

Типичный пайплайн:

1. Ingestion - документы режутся на фрагменты (300-1000 токенов), строятся эмбеддинги.
2. Index - векторная БД (Pinecone, Qdrant, pgvector, Chroma) + опционально keyword index.
3. Query - вопрос пользователя -> эмбеддинг -> top-k фрагменты.
4. Generation - фрагменты + вопрос -> LLM -> ответ (желательно с цитатами источников).

Обновление знаний: переиндексировать изменённые документы - без переобучения модели.

Плюсы

• Масштаб - миллионы страниц, если индекс и нарезка на фрагменты настроены правильно.
• Актуальность - новый документ в индексе через минуты, не недели.
• Снижение галлюцинаций - модель опирается на предоставленные фрагменты; цитаты повышают доверие.
• Экономия на input - в промпт попадают только релевантные куски, не вся база.

Минусы

• Сложность - нарезка на фрагменты, эмбеддинги, переранжирование, evaluation, мониторинг drift.
• Качество извлечения = качество ответа - плохой поиск даёт плохие ответы при «идеальной» модели.
• Задержка - два шага плюс переранжирование.
• Дубликаты и противоречия - разные версии документа в индексе путают систему.

Когда выбирать RAG

• Большая или часто меняющаяся база: документация, wiki, тикеты, Confluence, PDF-архив.
• Нужны ссылки на источник в ответе (support, legal, medical с оговорками).
• Много пользователей и запросов - дешевле подтягивать 5 фрагментов, чем 500 страниц в контекст.
• Данные нельзя вшивать в веса модели (конфиденциальность, изоляция tenant).

Дообучение: знания в весах

Дообучение - дообучение базовой модели на ваших данных: пары instruction/response, диалоги, доменные тексты. Веса сдвигаются так, что модель лучше знает стиль, терминологию и типовые задачи без длинного промпта.

Варианты:

• Full дообучение - все параметры (дорого, редко нужно).
• LoRA / QLoRA - адаптеры поверх frozen base (стандарт для custom моделей).
• DPO / RLHF - выравнивание под предпочтения (тон, безопасность, формат).

Как это работает

1. Собираете dataset: Q&A, диалоги поддержки, примеры кода, JSON-ответы.
2. Обучаете адаптер или полную модель на GPU (часы - дни).
3. Деплоите fine-tuned эндпоинт или merged weights.
4. При inference - короткий системный промпт, модель уже «знает» паттерны.

Дообучение не заменяет актуальные факты: цены, версии API, новости продукта модель не «запомнит» надёжно - для этого нужен RAG или свежий контекст.

Плюсы

• Стиль и формат - единая тональность, JSON schema, шаблоны ответов.
• Меньше tokens в промпт - не нужны длинные инструкции и десятки примеров в промпте.
• Задержка и cost на запрос - короче промпт при той же задаче.
• Специализированная терминология - медицина, юриспруденция, внутренний жаргон.

Минусы

• Дорого и долго - данные, GPU, итерации, проверка качества; нужна ML-компетенция.
• Устаревание - новый продукт = новый цикл обучения или гибрид с RAG.
• Риск overfitting - модель «зазубрила» обучающая выборка и плохо обобщается.
• Хуже для редких фактов - дообучение слабее RAG для «найди параграф 4.2 в policy v3».

Когда выбирать дообучение

• Стабильная задача с повторяющимся форматом: классификация, extraction, summarization по шаблону.
• Нужен короткий промпт и низкая задержка на миллионах запросов.
• Большой объём качественных размеченных диалогов (тысячи+ примеров).
• На своей инфраструктуре или изолированно от интернета - одна локальная модель без внешнего API на каждый фрагмент.

Сравнение по ключевым критериям

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

Начните с контекста, если:

• документов мало и они помещаются в 100-200K токенов;
• нужен пилот за один спринт;
• каждый запрос уникален и требует «всего файла» (diff, контракт).

Добавьте RAG, если:

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

Добавьте дообучение, если:

• формат ответа жёсткий и одинаковый на 95% запросов;
• RAG уже работает, но промпт раздувается от инструкций и примеров;
• есть dataset и бюджет на итерации проверки качества.

Типичный продакшен-стек 2026:

Fine-tuned модель (стиль + routing)
    + RAG (факты из базы знаний)
    + Умеренный context (system prompt, последние N сообщений, 1-2 полных doc при необходимости)

Частые ошибки

• «Зальём всё в 1M контекст» - дорого, медленно, а качество извлечения при том же бюджете часто выше у RAG.
• Fine-tune вместо RAG для FAQ - модель «запомнит» устаревшие цены; RAG или context проще.
• RAG без проверки качества - без метрик (recall@k, верность фактам, проверка человеком) система деградирует незаметно.
• Слишком мелкая нарезка на фрагменты - теряется смысл абзаца; слишком крупный - шум в промпт.
• Игнорировать переранжирование - top-5 из векторного поиска без cross-encoder часто хуже гибрида BM25 + переранжирование.

Когда не стоит спешить с RAG или дообучением

• Данных и вопросов мало. Десяток документов и редкие обращения пользователей - длинного контекста в промпте достаточно; RAG-инфраструктура и дообучение окупятся нескоро.
• Нет владельца процесса. RAG нужно следить за актуальностью индекса, дообучение - за качеством датасета; без выделенного человека, который отвечает за это, качество ответов деградирует незаметно.
• Продукт и данные ещё нестабильны. Пока цены, процессы и формулировки часто меняются, дообучение особенно рискованно - каждое изменение требует нового цикла обучения; на этом этапе выгоднее короткий контекст и правки промпта.
• Нет времени на оценку качества. Recall, точность ответов и проверка на реальных вопросах требуют итераций; если результат нужен «за неделю без доработок», начните с самого простого варианта - контекстного окна, а RAG и дообучение добавляйте по мере роста нагрузки.

Итог

Контекстное окно - быстрый старт и полный контроль для небольших объёмов. RAG - стандарт для масштабируемых баз знаний с актуальными фактами и цитатами. Дообучение - инвестиция в стабильное поведение и формат, а не в энциклопедию фактов.

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

Стоимость разработки RAG-системы или ИИ-агента с нужной архитектурой - на странице прайса.

Если нужна помощь с разработкой, внедрением ИИ или сопровождением сайта под вашу задачу - напишите мне.

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

Можно ли заменить RAG очень длинным контекстным окном?

Теоретически - для небольших корпусов. Практически - редко выгодно: стоимость и задержка растут линейно с длиной промпта, а модели хуже используют информацию из середины длинного контекста. RAG подтягивает только релевантное и масштабируется на большие архивы. Исключение - задачи «прочитай весь файл целиком»: ревью кода, сравнение двух версий договора, анализ одного PDF на 200 страниц.

Нужен ли дообучение для корпоративного чат-бота?

Не обязательно на старте. Большинство internal copilot и ботов поддержки достаточно закрывают RAG + хороший системный промпт. Дообучение имеет смысл, когда накопились тысячи эталонных диалогов, нужен единый формат (JSON, тикеты, поля CRM) или критична экономия токенов на каждом запросе. Сначала измерьте базовую линию с RAG - дообучение без метрик часто не окупается.

Что дешевле: RAG или дообучение?

RAG дешевле на входе: векторная БД, эмбеддинги API, без GPU-кластера. Дообучение дороже на старте (данные, обучение, деплой), но может снизить стоимость на request, если убирает длинные инструкции и примеры из каждого промпта при большом трафике. Сравнивайте TCO за 6-12 месяцев: инфра RAG + эмбеддинг refresh vs стоимость retrain и inference fine-tuned модели.

Как часто нужно обновлять знания при каждом подходе?

Контекст - при каждом запросе (актуальный prompt) или при деплое новой версии шаблона. RAG - по мере изменения документов: incremental reindex от минут до часов; полный rebuild - по расписанию или при смене модели эмбеддингов. Дообучение - при смене поведения или домена: от недель до месяцев между релизами; факты (цены, релизы) всё равно подтягивают через RAG или инструмент calls.

Можно ли комбинировать все три подхода?

Да, и так делают лучшие продакшен-системы. Fine-tuned модель задаёт стиль и routing («нужен ли поиск по базе»). RAG приносит актуальные фрагменты. В context кладут system rules, историю чата и иногда один полный документ для задачи «прочитай целиком». Главное - чётко разделить роли: факты из RAG, поведение из дообучения, ограничения и примеры - из промпта, без дублирования одного и того же текста во всех слоях.

Термины в статье

LLM — Large Language Model — большая языковая модель

контекстное окно — context window — сколько текста модель может держать в одном запросе

дообучение — fine-tuning — дополнительное обучение модели под вашу задачу

промпт — prompt — текст-инструкция или запрос к модели

системный промпт — system prompt — скрытые инструкции, которые задают поведение модели

эмбеддинги — embeddings — числовые векторы, отражающие смысл текста

пайплайн — pipeline — цепочка автоматических шагов обработки

MVP — Minimum Viable Product — минимально жизнеспособный продукт

top-k — keep only the k most likely next tokens when sampling — при генерации оставляют только k самых вероятных токенов

переранжирование — reranking — переранжирование кандидатов (reranking)

Confluence — Atlassian wiki for team documentation — вики Atlassian для командной документации

QLoRA — Quantized Low-Rank Adaptation — квантованная низкоранговая адаптация модели

LoRA — Low-Rank Adaptation — низкоранговая адаптация модели

inference — running a trained model to get predictions — запуск обученной модели для получения ответа

эндпоинт — endpoint — точка API / конкретный URL API (endpoint)

RLHF — Reinforcement Learning from Human Feedback — обучение с подкреплением по обратной связи человека

паттерны — reusable solution patterns for common design problems — повторно используемые приёмы для типовых задач проектирования

на своей инфраструктуре — on-premise — на своей инфраструктуре (on-premise)

GPU — Graphics Processing Unit — графический процессор

галлюцинации — model hallucinations — уверенные, но неверные ответы модели

ML — Machine Learning — машинное обучение

проверки качества — evals — проверки качества ответов модели (evals)

RAG — Retrieval-Augmented Generation — генерация с дополненным поиском

fine-tune — train a model further on domain data — дообучить модель на данных предметной области

cross-encoder — rerank model that scores query and document together — реранкер: оценивает запрос и документ вместе

TCO — Total Cost of Ownership — совокупная стоимость владения