Fine-tuning или RAG: что выбрать для своей задачи

MAATRIX

Когда модель отвечает не так, как нужно бизнесу — путает факты, не знает вашу базу знаний или пишет не в том стиле — первый инстинкт часто «дообучить её на своих данных». Но в половине случаев правильный ответ — не трогать веса модели вообще, а подключить ей внешнюю память. Разберёмся, чем RAG отличается от fine-tuning, когда каждый из них реально решает задачу, а когда вы просто потратите деньги и время впустую.

В чём разница на уровне архитектуры

RAG (Retrieval-Augmented Generation) не меняет модель. Вы берёте готовую LLM — открытую или через API — и перед тем как отдать ей вопрос пользователя, подмешиваете в промпт релевантные куски текста, найденные в вашей базе знаний. Модель отвечает, опираясь на этот контекст, но сама остаётся неизменной: те же веса, тот же чекпоинт, что и до интеграции.

Fine-tuning — это буквально дообучение: вы прогоняете модель через дополнительные шаги градиентного спуска на своём датасете, и её веса меняются. После этого модель — уже не та, что была скачана с Hugging Face: у неё другое распределение вероятностей на выходе, и это распределение теперь смещено в сторону ваших примеров.

Отсюда и все практические различия. RAG — это про то, *что модель знает в момент ответа*. Fine-tuning — про то, *как модель ведёт себя в принципе*, независимо от того, что ей подсунули в контекст.

Что даёт RAG

RAG решает проблему актуальности и прозрачности знаний:

• Обновление за минуты. Добавили документ в векторную базу — модель уже может на него ссылаться при следующем запросе. Не нужно ничего переобучать.
• Прозрачность источника. Можно показать пользователю, из какого документа взят ответ (fragment + ссылка), что критично для юридических, медицинских и финансовых кейсов.
• Меньше галлюцинаций на фактах. Модель отвечает, опираясь на реальный текст, а не на то, что «запомнила» при обучении — и запомнила могла неточно.
• Не трогает базовую модель. Можно менять LLM-провайдера (например, с одной открытой модели на другую) без пересборки базы знаний — она хранится отдельно.

Минимальный стек RAG на сервере обычно выглядит так: векторная база (Qdrant, Chroma, pgvector), эмбеддинг-модель для превращения текста в векторы, и сама LLM для генерации ответа. Псевдокод логики запроса:

query_vector = embed(user_question)
chunks = vector_db.search(query_vector, top_k=5)
context = "\n\n".join(c.text for c in chunks)

prompt = f"""Ответь на вопрос, используя только контекст ниже.
Если ответа нет в контексте — скажи, что не знаешь.

Контекст:
{context}

Вопрос: {user_question}"""

answer = llm.generate(prompt)

Разворачивать такую схему с нуля вручную необязательно — есть готовые связки вроде AnythingLLM или Flowise, где база знаний, эмбеддинги и LLM уже собраны в один интерфейс. Мы подробно писали, как поднять RAG по своим документам на сервере, включая сбор и подготовку исходных данных.

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

Что даёт fine-tuning

Fine-tuning решает другую проблему — поведение модели, а не её знания:

• Консистентный формат ответа. Если вам нужно, чтобы модель всегда отвечала в строгой JSON-схеме, определённым тоном или структурой (например, медицинские заключения по шаблону), дообучение на сотнях примеров такого формата закрепляет паттерн надёжнее, чем инструкция в промпте.
• Узкая специализация. Классификация тикетов поддержки по вашим внутренним категориям, извлечение сущностей из специфичных документов, генерация кода в стиле вашей кодовой базы — задачи, где нужно не «знание фактов», а конкретный навык.
• Более короткий промпт в проде. Если модель уже «понимает» задачу на уровне весов, не нужно на каждый запрос тащить длинную инструкцию с примерами (few-shot) — это экономит токены и снижает задержку.
• Поведение, которое не выразить текстом. Иногда легче показать 500 примеров правильного стиля, чем описать его словами в system-промпте.

Технически чаще всего используется не полное дообучение всех весов (это дорого и требует много GPU-памяти), а LoRA (Low-Rank Adaptation) — дообучение небольших адаптеров поверх замороженной модели. Мы разбирали процесс подробно в статье «LoRA fine-tuning своей модели на VPS». Типичный вызов через популярный фреймворк выглядит так:

python -m axolotl.cli.train config.yml

где config.yml описывает базовую модель, датасет и параметры LoRA (rank, alpha, целевые слои). Дообученные адаптеры весят десятки-сотни мегабайт и подключаются к базовой модели во время инференса — полную копию модели хранить не нужно.

Минус: обучение требует размеченного датасета (хотя бы несколько сотен качественных примеров), GPU-мощностей на этапе обучения, и — самое неочевидное — после дообучения модель нужно заново тестировать на прежних задачах: fine-tuning иногда ухудшает то, что модель умела раньше (эффект catastrophic forgetting).

Таблица сравнения по критериям

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

Типичная ошибка: файнтюнить под свежие факты

Самая частая ошибка — попытка «зашить» в модель актуальные данные через дообучение: цены, статус заказов, новости компании, содержимое базы знаний, которая меняется каждую неделю. Это почти всегда неправильный инструмент:

• Каждое обновление фактов требует нового цикла обучения — это часы или дни, а не минуты.
• Модель не умеет достоверно сообщать *откуда* она это знает — источник теряется в весах.
• Модель может «запомнить» факт неточно (обучение — это статистическое сжатие, не база данных) и позже уверенно об этом соврать.
• Датасет для факто-ориентированного дообучения быстро устаревает, и вы попадаете в бесконечный цикл переобучения.

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

Можно ли сочетать оба подхода

Да, и на практике это частая связка. Типичная схема:

1. Fine-tuning закрепляет формат, тон и узкий навык модели — например, она всегда отвечает в вашей терминологии, в нужной структуре, с определённым уровнем детализации.
2. RAG поверх этой дообученной модели подтягивает актуальные факты из базы знаний в момент ответа.

Получается модель, которая одновременно «говорит на вашем языке» и «знает, что происходит сейчас». Это дороже в поддержке — нужна и инфраструктура для векторного поиска, и процесс периодического дообучения, — но для продуктов с высокими требованиями к качеству (например, ИИ-ассистент, который должен звучать как эксперт компании и при этом ссылаться на актуальные документы) это оправданно.

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

Как оценить, что выгоднее для вашей задачи

Прежде чем выбирать, задайте себе три вопроса:

• Как часто меняются данные, которые должна знать модель? Если чаще, чем раз в месяц — почти наверняка RAG. Дообучать модель каждую неделю нерентабельно.
• Проблема в знаниях или в поведении? Модель не знает факт — RAG. Модель знает факт, но отвечает не в том формате, тоне или структуре — fine-tuning.
• Готовы ли вы поддерживать GPU-инфраструктуру для обучения? RAG можно запустить на CPU-сервере с умеренным объёмом RAM для эмбеддингов и векторного поиска. Fine-tuning, даже через LoRA, требует GPU хотя бы на этапе обучения — постоянно держать его не обязательно, но на цикл дообучения он нужен.

По деньгам ориентир простой: RAG-стек (векторная база + эмбеддинги + инференс через CPU или бюджетный GPU) обычно обходится дешевле на старте, чем цикл fine-tuning с арендой GPU-мощностей под обучение — но точные цифры сильно зависят от объёма данных, размера модели и провайдера, поэтому здесь стоит посчитать под свою задачу, а не ориентироваться на чужие бенчмарки. Если нужен GPU именно под обучение, у нас есть отдельный разбор выбора GPU-сервера для обучения моделей.

Частые вопросы