Fine-tuning vs RAG vs few-shot: как адаптировать LLM под задачу
Когда команда внедряет языковую модель в свой продукт, она почти всегда сталкивается с одной задачей: базовая модель не знает специфики бизнеса. Не знает корпоративных терминов, не знает внутренних процессов, не знает данных компании, не следует нужному стилю общения. Возникает вопрос: как «научить» модель работать с этой спецификой.
В индустрии сложились три принципиально разных подхода к этой задаче: few-shot prompting (привести примеры в контексте), RAG (предоставить релевантные данные на ходу), fine-tuning (обучить модель на специфическом наборе данных). Каждый подход решает определённый класс проблем, имеет свои ограничения, требует разных ресурсов. Неправильный выбор приводит к перерасходу бюджета, неоптимальным результатам или невозможности достичь нужного качества. Разбираем устройство каждого подхода и критерии выбора.
Few-shot prompting: примеры в контексте
Few-shot prompting — простейший способ адаптировать модель к конкретной задаче. Разработчик включает в промпт несколько примеров желаемого поведения (input → output), и модель использует эти примеры как «обучающую выборку на лету», генерируя ответ в том же стиле.
Подход основан на способности крупных языковых моделей к in-context learning — пониманию паттернов из примеров без формального дообучения. Дав модели 3–5 примеров классификации текстов в определённые категории, можно получить корректную классификацию новых текстов даже на специфическом домене.
| Вариант prompting | Описание |
|---|---|
| Zero-shot | Инструкция без примеров, только описание задачи |
| One-shot | Один пример input → output перед основным запросом |
| Few-shot | Несколько (обычно 3–10) примеров перед запросом |
| Chain-of-thought | Примеры с пошаговым рассуждением для сложных задач |
Сильные стороны few-shot: мгновенное применение без обучения и инфраструктуры; нулевые упфронт-затраты; полная гибкость (изменили примеры — изменилось поведение); работает с любой моделью, поддерживающей достаточный контекст. Это самый низкобарьерный подход для быстрых экспериментов.
Слабые стороны: ограничен размером контекстного окна; повышает стоимость каждого запроса (примеры занимают токены); качество ограничено возможностями базовой модели понять задачу из нескольких примеров; не масштабируется на задачи, требующие сотен или тысяч примеров для нюансов.
RAG: внешний источник знаний
RAG (Retrieval Augmented Generation) — подход, при котором модель получает доступ к внешним данным через retrieval-механизм. При каждом запросе из базы знаний извлекаются релевантные документы, передаются в контекст модели, она формирует ответ на основе этих данных.
RAG идеально подходит для задач, где знания меняются или их слишком много для пометки в модель. Корпоративная база знаний с тысячами документов, регулярно обновляющиеся правила и инструкции, специфические данные пользователя — всё это лучше обслуживать через RAG, чем через fine-tuning.
Архитектура RAG включает: индексирование документов (превращение в эмбеддинги и сохранение в векторной базе); retrieval (поиск похожих эмбеддингов по запросу); генерация (передача найденных документов в модель вместе с вопросом). Все три шага можно оптимизировать независимо.
Сильные стороны RAG: модель опирается на актуальные данные (можно обновлять без переобучения); снижает hallucinations через grounding в источниках; даёт прозрачность через цитирование (можно показать источники ответа); работает с любой базовой моделью без её модификации.
Слабые стороны: качество ответов критически зависит от качества retrieval; добавляет latency и сложность архитектуры; не учит модель новым навыкам, только подсовывает данные; плохо подходит для задач, требующих особого стиля или формата ответов.
Fine-tuning: обучение на специфике
Fine-tuning — формальное дообучение модели на специфическом датасете. Базовая модель берёт «как есть», на ней запускается дополнительный цикл обучения на корпоративных или специальных данных, веса модели обновляются под целевую задачу.
Существует несколько разновидностей fine-tuning’а с разной стоимостью и эффектом. Full fine-tuning — обновление всех параметров модели; самый мощный, но дорогой и требующий значительных GPU-ресурсов. LoRA (Low-Rank Adaptation) — обучение небольших адаптеров поверх замороженной базовой модели; намного дешевле, не теряет много качества. QLoRA — комбинация LoRA с квантованием для ещё большей экономии ресурсов.
| Метод fine-tuning | Параметры для обучения | Стоимость | Качество |
|---|---|---|---|
| Full fine-tuning | Все веса модели | Очень высокая | Максимальное |
| LoRA | Малые adapter-веса | Низкая | Близкое к full |
| QLoRA | LoRA + квантование | Очень низкая | Близкое к LoRA |
| Prefix tuning | Только prefix-токены | Минимальная | Среднее |
| RLHF | Веса модели через preference learning | Очень высокая | Лучшее по alignment |
Сильные стороны fine-tuning: модель действительно «учится» новому, не только использует данные на ходу; быстрые ответы (нет retrieval-overhead); компактные промпты (нет необходимости передавать примеры или контекст); подходит для специфичного стиля и формата ответов.
Слабые стороны: требует значительных данных для эффективного обучения (от сотен до тысяч примеров); фиксированные знания на момент обучения (не обновляются автоматически); риск catastrophic forgetting — потери общих способностей модели; высокая стоимость full fine-tuning’а; сложность инфраструктуры (нужны MLOps-пайплайны для обучения и деплоя).
Сравнение подходов по типам задач
Каждый подход оптимален для определённых типов задач. Понимание этого соответствия — главное в принятии решения.
Адаптация к стилю и тону. Если нужно, чтобы модель отвечала в специфическом формате (краткие точные ответы, юмористический стиль, корпоративный тон), fine-tuning обычно даёт лучшие результаты. Few-shot работает для простых случаев, но не справляется со сложным стилем. RAG здесь не подходит — он добавляет данные, не меняет стиль.
Работа со специфическими знаниями. Если у компании есть база документации, регламентов, корпоративная wiki — RAG почти всегда правильный выбор. Fine-tuning на этих данных требует огромных датасетов и переобучения при каждом обновлении документации. Few-shot не подходит при объёмах больше нескольких примеров.
Узкоспециализированные задачи. Юридический анализ, медицинская терминология, специфические форматы кода — fine-tuning часто даёт качество, недостижимое для general-purpose модели через prompting или RAG. Особенно эффективен continuous fine-tuning на накапливающихся реальных задачах.
Структурированный вывод. Если нужно, чтобы модель надёжно выдавала JSON определённой схемы, fine-tuning делает это надёжно. Few-shot и RAG могут давать сбои в structured output, fine-tuned модель обучается выдавать правильный формат.
| Тип задачи | Лучший подход |
|---|---|
| Q&A по корпоративной базе знаний | RAG |
| Корпоративный стиль общения | Fine-tuning |
| Классификация текстов на свои категории | Fine-tuning или few-shot |
| Кодинг в специфическом фреймворке | Fine-tuning или RAG с примерами |
| Извлечение структурированных данных | Fine-tuning |
| Свежие новости и события | RAG (актуальность критична) |
| Перевод на специфический домен | Fine-tuning |
| Быстрые эксперименты с задачей | Few-shot |
Гибридные подходы
В реальных продакшен-системах редко используется только один подход. Гибридные архитектуры комбинируют преимущества разных методов.
Fine-tuning + RAG. Модель fine-tunes под общий стиль и формат ответов, RAG подсовывает актуальные данные. Подход работает отлично для домен-специфичных ассистентов: модель «обучена» отвечать как корпоративный консультант, RAG предоставляет конкретные данные клиента.
Few-shot + RAG. В контекст модели добавляются как примеры желаемых ответов (few-shot), так и retrieved-документы (RAG). Простой и гибкий подход без fine-tuning, дающий хорошее качество для большинства задач.
Fine-tuning адаптеров через RAG-данные. На основе данных, которые модель видит через RAG, периодически проводится fine-tuning. Это эволюция: то, что часто извлекается через retrieval, постепенно «вшивается» в модель.
Гибридные системы обычно превосходят чистые подходы по качеству, но усложняют архитектуру. Решение об их применении принимается, когда чистые подходы упираются в потолок качества для конкретной задачи.
Когда fine-tuning переоценён
В индустрии распространён миф «fine-tuning решит все проблемы». На практике часто оказывается, что более простые подходы дают сопоставимое качество за меньшие ресурсы.
Эмпирическое правило: попытаться сначала добиться нужного качества через few-shot и RAG, и только если это не работает — переходить к fine-tuning. Часто оказывается, что хорошо настроенный prompt с правильной структурой и подкреплённый RAG-данными работает не хуже, чем dedicated fine-tuned модель — при меньших затратах и большей гибкости.
Fine-tuning особенно сомнителен в следующих случаях. Данных мало (менее 200–500 качественных примеров) — модель не научится толком, может даже деградировать. Задача слишком общая (например, «улучшить ответы» без конкретной метрики) — без чёткого критерия успеха невозможно оценить, помог ли fine-tuning. Базовая модель уже хорошо справляется — улучшение через fine-tuning будет минимальным.
Подготовка данных для fine-tuning
Если решение о fine-tuning принято, главное условие успеха — качество датасета. Несколько ключевых принципов.
- Объём: 500–5000 высококачественных примеров обычно достаточно для LoRA fine-tuning; для full fine-tuning’а может потребоваться больше
- Разнообразие: примеры должны покрывать разные сценарии и edge cases, не быть однообразными
- Качество: каждый пример должен быть проверен — лучше 500 идеальных, чем 5000 средних
- Формат: единая структура примеров (input → output), консистентность стиля
- Валидация: отдельный набор для оценки, не пересекающийся с обучающим
Распространённая ошибка — попытка fine-tuning’а на «грязных» данных в надежде, что модель «сама разберётся». Не разберётся. Garbage in, garbage out — это правило для машинного обучения работает безотказно.
Continuous fine-tuning и обратная связь
Один из мощных подходов — continuous fine-tuning: регулярное дообучение модели на новых данных, накапливаемых в процессе работы продукта. Это создаёт цикл улучшения: модель работает, пользователи дают обратную связь (явно через ratings или неявно через поведение), хорошие ответы добавляются в датасет, модель периодически дообучается.
RLHF (Reinforcement Learning from Human Feedback) — формализованная версия этого подхода. Сравнения «какой ответ лучше» от людей используются для обучения reward-модели, которая дальше направляет fine-tuning основной модели. Это основной метод alignment’а современных коммерческих моделей.
Continuous fine-tuning требует серьёзной инфраструктуры: системы сбора feedback, очистки данных, оценки качества, периодических циклов обучения, A/B-тестирования новых версий. Окупается на продуктах с большой пользовательской базой и важностью качества ответов.
Стоимость и сложность инфраструктуры
Три подхода радикально различаются по требованиям к инфраструктуре.
Few-shot — минимальная инфраструктура. Достаточно API ключа к модели и кода с правильным prompt’ом. Можно прототипировать за часы. Никаких отдельных систем хранения, обучения, деплоя моделей.
RAG — средняя сложность. Нужны: векторная база, инфраструктура для индексирования документов, retrieval-сервис, мониторинг качества retrieval. Установка занимает дни-недели, но это разовая работа. После запуска RAG относительно стабилен и предсказуем.
Fine-tuning — высокая сложность. Нужны: пайплайн подготовки данных, GPU-инфраструктура для обучения (или managed-сервис), система оценки моделей, версионирование, deployment-пайплайн. Особенно сложен continuous fine-tuning, требующий MLOps-зрелости. Команда меньше 5 человек обычно не справляется с этим стеком на production-уровне.
| Подход | Время до запуска | Инфраструктура | Стоимость операций |
|---|---|---|---|
| Few-shot | Часы | Минимальная | Зависит от объёма промпта |
| RAG | Недели | Vector DB + retrieval | Средняя |
| Fine-tuning | Месяцы | MLOps-стек | Высокая (обучение + хостинг) |
Эволюция выбора с ростом продукта
Большинство команд проходит типичный путь эволюции в подходах к адаптации моделей.
Этап 1: MVP и эксперименты. Few-shot с базовой моделью. Цель — проверить, что задача в принципе решается LLM. Минимум инфраструктуры, быстрая итерация.
Этап 2: первые пользователи. Добавляется RAG для предоставления актуальных данных. Качество растёт, появляются специфические возможности для конкретных доменов.
Этап 3: масштабирование. Анализ ошибок и узких мест. В местах, где RAG и few-shot не справляются — точечный fine-tuning. Гибридная архитектура.
Этап 4: зрелый продукт. Continuous fine-tuning на feedback’е пользователей. Несколько специализированных fine-tuned моделей под разные задачи продукта. Сложная гибридная архитектура с маршрутизацией запросов.
Перепрыгивание этапов обычно не работает: команда, начавшая с fine-tuning без опыта работы с моделью, часто инвестирует в неправильное направление. Поступательный подход даёт лучшее понимание реальных потребностей продукта.
Часто задаваемые вопросы
С какого подхода начинать новому проекту с LLM?
С few-shot prompting. Это самый быстрый способ проверить, решается ли задача в принципе. Если zero-shot или few-shot уже даёт приемлемое качество, остальные подходы могут быть не нужны. Если нет — анализировать, в чём именно проблема: нехватка данных (нужен RAG) или нехватка специфичности (возможно, fine-tuning).
Можно ли использовать RAG для всех задач вместо fine-tuning?
Для большинства задач, связанных со знаниями — да, RAG предпочтительнее. Но для задач, требующих специфического стиля, формата ответа или сложных алгоритмов мышления, RAG не помогает. Также RAG не подходит для очень коротких быстрых ответов, где retrieval добавляет неприемлемую задержку.
Сколько данных нужно для эффективного fine-tuning?
Зависит от подхода и сложности задачи. LoRA fine-tuning может давать заметные результаты от 200–500 примеров. Full fine-tuning требует от 1000–5000 примеров для значимого эффекта. RLHF — десятки тысяч сравнений. Качество датасета важнее количества: 500 идеально подобранных примеров часто работают лучше, чем 5000 средних.
Стоит ли fine-tunить базовую модель или специализированные модели?
Для большинства задач лучше fine-tunить открытые модели среднего размера. Они даются для тюнинга, локально деплоятся, доступны для широкой кастомизации. Fine-tuning через API крупных коммерческих моделей возможен и быстр, но менее гибок и более дорог. Выбор зависит от инфраструктуры компании и требований к данным.
Как оценивать, что подход работает?
Через evaluation metrics на отдельном test-наборе. Для классификации — accuracy, F1. Для генерации — LLM-as-judge или human evaluation на тестовых сценариях. Главное правило — иметь baseline и измерять улучшение от каждого изменения. Без формальной оценки легко обмануть себя в иллюзии прогресса.
Что делать, если ничего не помогает достичь нужного качества?
Несколько направлений. Проверить, реалистична ли задача для текущего поколения моделей (некоторые задачи всё ещё за их пределами). Попробовать более мощную базовую модель. Декомпозировать сложную задачу на простые подзадачи, каждую решать отдельно. Привлечь human-in-the-loop для пограничных случаев. Иногда LLM — не лучший инструмент, и стоит рассмотреть альтернативные технологии.
Заключение
Few-shot, RAG, fine-tuning — это не конкурирующие альтернативы, а инструменты с разным назначением. Выбор зависит от характера задачи, доступных данных, ресурсов команды, требований к latency и стоимости. Команды, которые понимают эти различия и применяют правильный инструмент к правильной задаче, получают значительное преимущество перед теми, кто пробует «одно решение для всего».
Современная практика чаще всего гибридная. Few-shot для быстрых экспериментов и простых задач. RAG как основа продуктов, работающих со специфическими знаниями. Fine-tuning для критичных мест, где нужно качество, не достижимое другими способами. Каждый компонент закрывает свою нишу, вместе они формируют надёжную инфраструктуру AI-продукта.
Главное правило — не торопиться с самым сложным подходом. Начинать с простого, добавлять сложность по мере необходимости. Большинство команд, начавших с fine-tuning, в итоге понимают, что их задача решалась через RAG за меньшие деньги и с большей гибкостью. Поступательный подход экономит ресурсы и даёт лучшее понимание того, что именно нужно конкретному продукту.