Контекстное окно vs RAG vs fine-tuning: что выбрать

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

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

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

Подход	Суть	Где меняются знания
Контекстное окно	Весь нужный текст в prompt	В каждом запросе
RAG	Поиск релевантных фрагментов + генерация	В индексе / базе знаний
Fine-tuning	Дообучение весов модели	В весах модели

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

Контекстное окно: всё в prompt

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

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

Вы кладёте в prompt:

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

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

Плюсы

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

Минусы

• Стоимость растёт с длиной - long-context тарифы у провайдеров часто x1.5-x2 к базовому.
• Потолок объёма - даже 2M токенов не вместят всю базу знаний enterprise.
• Качество на «игле» - модель может «терять» детали в середине очень длинного контекста (lost-in-the-middle).
• Latency - больше токенов на input - дольше первый ответ.

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

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

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

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

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

Типичный pipeline:

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

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

Плюсы

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

Минусы

• Сложность - chunking, embeddings, reranking, evaluation, мониторинг drift.
• Качество retrieval = качество ответа - плохой поиск даёт плохие ответы при «идеальной» модели.
• Latency - два шага (search + generate) плюс rerank.
• Дубликаты и противоречия - разные версии документа в индексе путают систему.

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

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

Fine-tuning: знания в весах

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

Варианты:

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

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

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

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

Плюсы

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

Минусы

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

Когда выбирать fine-tuning

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

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

Критерий	Контекст	RAG	Fine-tuning
Объём знаний	До лимита окна	Практически неограничен	Ограничен training set
Актуальность	Мгновенно (новый prompt)	Быстро (reindex)	Медленно (retrain)
Стоимость старта	Низкая	Средняя	Высокая
Стоимость запроса	Растёт с длиной context	Search + короткий context	Низкий prompt
Галлюцинации	Средний риск	Ниже при хорошем retrieval	Средний, «уверенные» ошибки
Цитирование источников	Ручное в prompt	Естественно	Сложно
Инфраструктура	API модели	Vector DB, pipeline	GPU, MLOps
Compliance / audit	Полный контроль prompt	Логи retrieval	Чёрный ящик весов

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

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

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

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

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

Добавьте fine-tuning, если:

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

Типичный production-стек 2026:

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

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

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

Итог

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

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

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

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

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

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

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

Что дешевле: RAG или fine-tuning?

RAG дешевле на входе: vector DB, embeddings API, без GPU-кластера. Fine-tuning дороже на старте (данные, обучение, деплой), но может снизить cost per request, если убирает длинные инструкции и few-shot из каждого prompt при большом трафике. Сравнивайте TCO за 6-12 месяцев: инфра RAG + embedding refresh vs стоимость retrain и inference fine-tuned модели.

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

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

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

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