RAG vs Fine-tuning vs длинный контекст: как выбрать подход для корпоративного AI

Если вы хоть раз слышали фразу «давайте закинем наши ADR в ChatGPT и он всё сам поймёт» — вы знаете, с чего начинается боль. У заказчика сотня документов, три базы знаний и горячее желание «чтобы модель отвечала по нашим данным». А дальше начинается самое интересное: один подрядчик предлагает RAG, второй — fine-tuning, третий говорит «да купите модель с окном на миллион токенов и не парьтесь». И все три звучат убедительно.

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

Три подхода: суть каждого

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

RAG (Retrieval-Augmented Generation)

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

Схема работы: документы (ТЗ, ADR, переписка) → разбиение на чанки → векторизация через embedding-модель → векторная база данных. Когда приходит запрос, он векторизуется той же моделью, по вектору ищутся ближайшие чанки, они добавляются в контекст LLM — и модель генерирует ответ, опираясь на найденное.

Ключевая фишка RAG: данные живут отдельно от модели. Добавили новый документ — он сразу доступен, без переобучения. Удалили устаревшее — модель про него «забыла». Если вы проектируете RAG-пайплайн для базы знаний аналитика — это ровно ваш случай.

Fine-tuning (дообучение модели)

Fine-tuning — процесс дообучения предобученной LLM на собственном наборе данных. В отличие от RAG, знания «впечатываются» в веса модели и становятся её неотъемлемой частью.

Для fine-tuning нужен датасет — размеченные пары «вопрос → правильный ответ» или «инструкция → ожидаемый результат». Модель прогоняется через эти примеры на GPU, её веса корректируются, и на выходе получается кастомная версия, которая «знает» ваш домен. Не по ссылкам на документы, а на уровне параметров.

Оборотная сторона: обучение стоит денег (GPU-часы), данные для обучения надо готовить, а при добавлении новых документов нужно либо переобучать, либо городить гибридную схему. Плюс отладить fine-tuned модель сложнее, чем RAG-пайплайн — нет чёткой цепочки «запрос → поиск → генерация», непонятно, откуда модель взяла конкретный факт.

Длинный контекст (large context window)

Длинный контекст — подход, при котором все необходимые документы загружаются в промпт напрямую, без внешнего поиска и без дообучения. Работает за счёт моделей с контекстным окном от 128K до 1M токенов (Gemini 2.5, Claude, GPT-4.1).

Идея соблазнительная: не нужно настраивать ни чанкер, ни векторную БД, ни embedding-модель. Просто закинул все документы в промпт — и модель отвечает. На практике цена растёт линейно с объёмом: каждый запрос тащит полный контекст, даже если 90% документов к вопросу отношения не имеют. На одном-двух запросах это незаметно, на сотне в день — бюджет улетает в космос.

Примечательно, что модели с окном на 1M токенов реально держат качество не на всём окне. Исследования (Lost in the Middle, 2024) показывают: информация из начала и середины длинного промпта извлекается моделью хуже, чем из начала и конца. Так что «просто закину всё» — работает, но не всегда.

Дерево решений: какой подход выбрать

Вот схема, которую удобно держать под рукой при обсуждении архитектуры AI-функции. Три вопроса — и вы знаете, куда смотреть.

flowchart TD
  START["Нужно адаптировать LLM под корпоративные данные"] --> Q1{"Данные часто обновляются?"}
  Q1 -->|"Да, каждую неделю"| RAG["RAG: поиск по внешней базе знаний"]
  Q1 -->|"Нет, стабильный корпус"| Q2{"Объём умещается в контекстное окно?"}
  Q2 -->|"Да, менее 128K токенов"| LC["Длинный контекст: всё в одном промпте"]
  Q2 -->|"Нет, сотни тысяч токенов"| Q3{"Есть размеченные пары вопрос-ответ?"}
  Q3 -->|"Да"| FT["Fine-tuning: дообучение модели"]
  Q3 -->|"Нет"| HYBRID["Гибрид: RAG + длинный контекст"]
  
  style START fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Q1 fill:#f0a500,stroke:#c88400,color:#fff
  style Q2 fill:#f0a500,stroke:#c88400,color:#fff
  style Q3 fill:#f0a500,stroke:#c88400,color:#fff
  style RAG fill:#50c878,stroke:#3a9a5c,color:#fff
  style LC fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style FT fill:#7b68ee,stroke:#5a4db2,color:#fff
  style HYBRID fill:#50c878,stroke:#3a9a5c,color:#fff

Логика дерева проста и беспощадна:

Данные обновляются часто? Если да — RAG, потому что fine-tuning не успеет за изменениями, а длинный контекст на каждом запросе пересчитывать дорого.
Объём умещается в контекстное окно модели? Если да и данные стабильны — длинный контекст даст самый простой пайплайн. Никаких дополнительных сервисов.
Есть размеченные пары вопрос-ответ? Если нет — fine-tuning недоступен (не на чём обучать). Остаётся гибрид: RAG для поиска + длинный контекст модели для связывания найденных чанков в осмысленный ответ.

Обратите внимание: ни одна ветка не ведёт к варианту «ничего не делать». Потому что базовая LLM без доступа к корпоративным данным — это как аналитик без доступа к Confluence: общие слова скажет, а по делу — галлюцинации. Вредные, кстати, галлюцинации: звучат правдоподобно. Сотрудник поверит, примет решение, а через месяц обнаружится, что модель выдумала несуществующий API и сослалась на ADR, которого нет.

Матрица сравнения: по каким критериям выбирать

Критерий	RAG	Fine-tuning	Длинный контекст
Актуальность данных	Всегда свежие, индексация за минуты	Устаревает до следующего обучения	Зависит от того, что положили в промпт
Стоимость внедрения	Средняя: векторная БД, embedding-модель, чанкер	Высокая: GPU-часы, подготовка датасета	Низкая: только API-ключ
Стоимость запроса	Низкая: ищутся 3–5 чанков, а не всё	Средняя: модель тяжелее, чем базовая	Высокая: каждый запрос тащит полный контекст
Объяснимость ответа	Высокая: есть ссылки на источники	Низкая: модель «знает», но не скажет откуда	Средняя: всё лежит в промпте, но без ссылок на конкретный фрагмент
Качество на доменных задачах	Среднее: зависит от качества retrieval	Высокое: модель обучена именно под домен	Среднее: модель «видит» документы, но без специализации
Скорость ответа	Средняя: поиск + генерация	Высокая: только генерация	Низкая: обработка гигантского промпта
Порог входа	Средний: нужна инфраструктура	Высокий: нужны ML-компетенции	Низкий: просто API-запрос
Обновление данных	Бесплатное, мгновенное	Требует переобучения	Бесплатное, но растёт цена запроса

Эта матрица не говорит «RAG всегда лучше» или «fine-tuning — серебряная пуля». Она говорит: смотрите на свой контекст. У вас команда из трёх аналитиков с сотней документов? Длинный контекст закроет потребности за день. У вас финтех с тысячью регламентов, которые обновляются еженедельно? RAG — без вариантов. У вас продуктовая команда, которая хочет, чтобы модель отвечала в стиле конкретного PM-а? Fine-tuning.

Стоимость и инфраструктура

Давайте посчитаем на реалистичных цифрах, без маркетинговых обещаний. Возьмём условную команду аналитиков из 10 человек, 500 документов (ADR, ТЗ, спецификации), средний размер документа — 5 000 токенов, общий объём — 2.5M токенов.

**Длинный контекст (Gemini 2.5, окно 1M токенов, ~ $1.25/1M input-токенов).** При 50 запросах в день с полным контекстом в 100K токенов на запрос: 50 × 100K = 5M входных токенов в день → ~$ 6.25/день → ~ $150/месяц. Выглядит терпимо, пока не начинаете масштабироваться: 500 запросов в день — уже$ 1 500/месяц. И это только входные токены, генерация оплачивается отдельно.

RAG (OpenAI text-embedding-3-small + GPT-4.1, PGVector на существующем PostgreSQL). Индексация 2.5M токенов через embedding-модель (~ $0.02/1M токенов) — одноразово$ 0.05. Запрос: векторизация запроса (~10 токенов) + поиск в PGVector (бесплатно на своей инфраструктуре) + генерация ответа с 5 чанками по 500 токенов каждый. При 50 запросах в день: 50 × (10 токенов embedding + 2 500 токенов контекста в LLM) → около $0.15/день на embedding +$ 10/день на LLM → ~$300/месяц. Дешевле длинного контекста при масштабировании.

**Fine-tuning (GPT-4o-mini, ~ $3/1M токенов обучения).** Подготовка датасета из 500 документов, превращение их в 1 000 пар «вопрос-ответ» (силами LLM или вручную) — это самая дорогая часть, по человеко-часам. Собственно обучение на 1 000 примерах по ~2K токенов каждый: ~2M токенов ×$ 3/1M = $6 за обучение. Запросы к fine-tuned модели: ~$ 0.30/1M токенов (дороже базовой в ~2 раза). При 50 запросах в день: ~$15/месяц на инференс. Выгодно на дистанции? Да. Но только если данные не меняются.

Важный нюанс: с единым API-слоем вроде LiteLLM вы можете комбинировать эти подходы без переписывания кода. Один эндпоинт, а под капотом — RAG для актуальных документов и fine-tuned модель для узкопрофильных задач. Переключение между стратегиями — изменение конфига, а не рефакторинг половины бэкенда.

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

В реальных проектах чистых стратегий почти не бывает. Чаще встречаются гибриды. Три типичных сценария:

Fine-tuning + RAG. Модель дообучена на стиль и терминологию компании, а фактические данные берёт через RAG. Так работают корпоративные AI-ассистенты уровня Enterprise: модель «говорит» как ваш сотрудник, но отвечает по актуальным документам. Дорого внедрять, но качество на выходе высокое.
RAG + длинный контекст. Retrieval находит 10–20 релевантных чанков, они все загружаются в контекст модели вместе с запросом. Плюс: меньше риск пропустить важное из-за плохого чанкинга (модель видит больше контекста). Минус: дороже, чем чистый RAG. Компромисс между качеством и стоимостью.
Fine-tuning + длинный контекст. Редкий, но существующий кейс: модель дообучена на внутреннем кодстайле/спецификациях, а для редких edge-кейсов ей скармливают пару документов в промпт. Специфично, обычно overengineered.

Стоит отметить: если вы на старте проекта и не знаете, что выбрать — начните с RAG. Это единственный подход, из которого легко мигрировать: накопили размеченные данные для fine-tuning — добавили дообученную модель вместо базовой (или параллельно). Поняли, что документов мало и контекст всё умещает — переключились на длинный контекст. Инфраструктура RAG (векторная БД, чанкер, embedding-модель) — это фундамент, на который ложится всё остальное.

Заключение

RAG, fine-tuning и длинный контекст — это не конкуренты, а три инструмента в ящике архитектора. Молоток, отвёртка и шуруповёрт. Можно забить шуруп молотком — получится, но криво. Можно отвёрткой закручивать сотню шурупов в день — руки отвалятся.

Для 80% корпоративных сценариев 2026 года оптимальный старт — RAG. Данные живут отдельно, источник ответа прозрачен, инфраструктура переиспользуется. Fine-tuning подключайте, когда накопили датасет и точно знаете, что модель должна отвечать в конкретном стиле на конкретные вопросы. Длинный контекст — для прототипов и случаев, когда объём документов стабильно помещается в окно модели.

И да: если вам говорят «мы просто закинем все документы в промпт и всё заработает» — попросите посчитать стоимость 500 запросов в день на production-трафике. Обычно после этого начинается предметный разговор про RAG.