RAG vs Fine-tuning: когда что выбирать — опыт 30+ проектов

Представьте: клиент хочет «умного бота для базы знаний». Первый вопрос, который я задаю: «Данные часто меняются?»

От ответа зависит архитектура. И бюджет. И сроки. И головная боль ^[1] на следующие полгода.

За 30+ проектов я использовал оба подхода. RAG — в 80% случаев. Fine-tuning — в 15%. Комбинацию — в 5%. Расскажу, почему такое распределение и как выбирать.

Суть различия за 30 секунд

RAG (Retrieval-Augmented Generation):

• Модель остаётся базовой

• При запросе ищем релевантные документы в базе

• Подставляем найденное в контекст

• Модель генерирует ответ на основе найденного

Fine-tuning:

• Дообучаем модель на своих данных

• Знания «запекаются» в веса нейросети

• Модель отвечает «из памяти»

• Данные нужны только на этапе обучения ^[2]

Когда RAG — правильный выбор

Прежде чем разбирать сценарии — вот минимальный, но рабочий RAG-пайплайн на Python. Всего 20 строк, чтобы понять суть:

from openai import OpenAI
from qdrant_client import QdrantClient

client = OpenAI()
qdrant = QdrantClient("localhost", port=6333)

def rag_query(question: str, collection: str = "docs") -> str:
    # 1. Получаем embedding вопроса
    embedding = client.embeddings.create(
        model="text-embedding-3-small",
        input=question
    ).data[0].embedding

    # 2. Ищем релевантные документы
    results = qdrant.search(
        collection_name=collection,
        query_vector=embedding,
        limit=5
    )

    # 3. Формируем контекст
    context = "nn".join([r.payload["text"] for r in results])

    # 4. Генерируем ответ с контекстом
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": f"Отвечай на основе контекста:n{context}"},
            {"role": "user", "content": question}
        ]
    )
    return response.choices[0].message.content

# Использование
answer = rag_query("Какой SLA у тарифа Бизнес?")
 [3]

Это ядро любого RAG-решения. Дальше обвязка: чанкинг документов, индексация, re-ranking — но суть всегда одна: поиск + генерация.

1. Данные часто меняются

Документация, прайсы, регламенты, новости — всё, что обновляется регулярно.

Реальный сценарий: база знаний техподдержки. Новые продукты, новые баги, новые решения — каждую неделю.

• С RAG: добавил документ в базу — сразу доступен

• С Fine-tuning: переобучать модель при каждом изменении (дорого и долго)

2. Нужна прозрачность ответов

RAG позволяет показать источник: «Ответ основан на документе X, раздел Y, страница Z».

Когда это критично:

• Юридические документы — клиент хочет видеть пункт договора

• Финансовая отчётность — нужна ссылка на источник цифр

• Медицинские рекомендации — ответственность за информацию

• Внутренние регламенты — «а где это написано?»

Fine-tuning не даёт прозрачности. Модель отвечает «из головы» — непонятно, откуда взялась информация.

3. Большой объём данных

Fine-tuning эффективен на 1000-100000 примеров. RAG работает с миллионами документов.

Реальный сценарий: база данных на 600 000 записей о промышленном оборудовании. Fine-tuning просто не справится — слишком много данных для «запекания» в модель.

4. Ограниченный бюджет

5. Нужен контроль над данными

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

Fine-tuning: данные «размазаны» по весам модели. Удалить конкретную информацию невозможно. Это важно для GDPR и персональных данных.

Когда Fine-tuning — правильный выбор

1. Специфический стиль или формат

Модель должна писать как конкретный автор. Или генерировать код в определённом стиле. Или отвечать с определённой интонацией.

Реальный сценарий: бот пишет ответы клиентам в стиле компании — с определёнными фразами, структурой, tone of voice.

RAG даст контент (что сказать). Fine-tuning даст голос (как сказать).

2. Доменная терминология

Если в вашей области 500+ специфичных терминов, которые базовая модель не знает или путает.

Примеры:

• Медицинская диагностика с узкой специализацией

• Юридические термины конкретной юрисдикции

• Внутренняя терминология крупной компании

3. Структурированный вывод

Когда нужен строго определённый формат JSON/XML с доменной логикой ^[4].

Реальный сценарий: парсинг счетов-фактур → структурированные данные для 1С. Нужно извлечь 20+ полей в точном формате.

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

4. Скорость критична

RAG добавляет latency: поиск по базе + ранжирование + формирование контекста.

Измерения на базе из 100K документов, GPU A100, batch size 1. На менее мощном железе или при большем объёме данных цифры будут выше.

Для real-time приложений (голосовые ассистенты, игры) разница в 100-200ms может быть критичной.

5. Offline-режим

Fine-tuned модель работает автономно. RAG требует доступ к векторной базе.

Реальный сценарий: мобильное приложение с локальной LLM для использования без интернета.

Комбинированный подход

В 5% проектов использую оба:

Реальный сценарий: юридический ассистент.

• Fine-tuning: юридический стиль, терминология, структура документов

• RAG: актуальные законы, судебная практика, внутренние регламенты

Модель «знает» как говорить юридическим языком (fine-tuning), но берёт актуальную информацию из базы (RAG).

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

Что пошло не так

1. RAG для задач стиля

Клиент хотел бота, который «пишет как наш CEO». Сделали RAG на примерах его писем.

Результат: бот выдавал правильную информацию, но стиль был нейтральным. RAG не изменяет стиль модели — он добавляет контент.

Решение: переделали на fine-tuning для стиля + RAG для актуальных данных.

2. Fine-tuning для меняющихся данных

Клиент настоял: «Дообучим модель на нашей документации, будет умнее».

Через месяц документация устарела. Модель отвечала по старым ценам и регламентам.

Решение: переделали на RAG. Теперь обновление — минуты, не переобучение.

3. Недооценка RAG latency

При 10 одновременных запросах векторный поиск стал узким местом. Ответы тормозили.

Решение: добавили кэширование частых запросов + масштабировали векторную базу.

4. Переоценка Fine-tuning accuracy

Клиент думал: дообучим — будет 100% точность.

На редких случаях модель всё равно галлюцинировала. Fine-tuning не гарантирует безошибочность.

Решение: добавили верификацию критичных ответов через RAG.

Стоимость в 2026

Скрытые расходы RAG:

• Поддержка векторной базы

• Обновление embeddings при изменении документов

• Масштабирование при росте нагрузки

Скрытые расходы Fine-tuning:

• Переобучение при изменении данных

• Версионирование моделей

• Тестирование после каждого обновления

Когда это работает

RAG работает когда:

• Данные обновляются чаще, чем раз в месяц

• Нужна прозрачность и ссылки на источники

• Бюджет ограничен, нужен быстрый старт

• Объём данных большой (10K+ документов)

Fine-tuning работает когда:

• Данные стабильны (обновления раз в квартал или реже)

• Нужен специфический стиль или формат

• Latency критична

• Есть бюджет на обучение и поддержку

Гибрид работает когда:

• Нужен и стиль, и актуальные данные

• Сложная предметная область

• Готовы инвестировать в сложную архитектуру

Выводы

RAG — выбор по умолчанию:

• Быстрый старт

• Прозрачность

• Актуальность данных

• Контроль над информацией

Fine-tuning — когда есть причина:

• Специфичный стиль

• Сложная терминология

• Структурированный вывод

• Минимальная latency

Гибрид — для сложных кейсов:

• Стиль + актуальные данные

• Терминология + обновляемая база

Главное правило: начинайте с RAG, переходите к fine-tuning только при необходимости. В 80% случаев RAG достаточно.

Какой подход используете вы? RAG, fine-tuning или гибрид? Делитесь опытом ^[5] в комментариях.

Ссылки

• RAG Paper (Lewis et al.) ^[6] — оригинальная статья по RAG

• OpenAI Fine-tuning Guide ^[7] — руководство по дообучению

• Qdrant ^[8] — векторная база данных

• LangChain RAG Tutorial ^[9] — туториал по RAG-пайплайну