Fine-tuning vs RAG vs Prompt Engineering: как выбрать подход адаптации LLM

Когда команда впервые внедряет LLM в продукт, перед ней встаёт развилка: каким способом адаптировать модель под конкретную задачу. Три основных подхода — prompt engineering, RAG и fine-tuning — часто противопоставляются как конкурирующие, хотя на практике решают разные задачи и регулярно используются параллельно. Выбор неправильного подхода стоит компании десятков тысяч долларов на обучение модели, которую можно было заменить десятью строками инструкций в промпте.

В этой статье — сравнение трёх подходов по конкретным параметрам, разбор сценариев применения каждого, обзор стоимости и сложности, и decision framework для выбора правильного варианта под конкретную задачу.

Три способа адаптации LLM

LLM «из коробки» — универсальная модель, обученная на общем корпусе текстов. Чтобы заставить её решать конкретную бизнес-задачу, существуют три подхода с разной глубиной вмешательства:

• Prompt engineering. Изменение того, как мы формулируем запрос к модели. Не меняем модель, не добавляем данных — только улучшаем инструкции.
• RAG (Retrieval-Augmented Generation). Подключение внешних источников знаний. В момент запроса релевантная информация извлекается и передаётся модели как контекст.
• Fine-tuning. Дообучение модели на собственных данных. Изменяет веса модели, создавая её специализированную версию.

Подходы упорядочены по возрастанию сложности и стоимости. Профессиональный подход начинается с самого простого (prompt engineering), и только при недостаточном результате переходит к более сложным.

Prompt Engineering: что это

Prompt engineering — искусство формулировки инструкций для LLM так, чтобы получать качественные результаты. Включает структурирование запроса, добавление примеров (few-shot learning), указание формата ответа, использование системных промптов для задания роли модели.

Базовые техники:

• Zero-shot prompting. Прямой вопрос без примеров. «Классифицируй отзыв как позитивный или негативный: …»
• Few-shot prompting. Несколько примеров перед основным запросом. «Вот примеры: … Теперь классифицируй: …»
• Chain-of-thought. Просьба к модели рассуждать пошагово. «Подумай по шагам перед ответом.»
• System prompt. Установка контекста: «Ты опытный юрист по корпоративному праву…»
• Format specification. Указание формата вывода: JSON, markdown, конкретные поля.
• Constraints. Ограничения: «Ответ не более 100 слов», «Не используй технические термины».

Современные модели чувствительны к качеству промпта. Хорошо составленный промпт может улучшить точность ответов на 20–50% без изменения модели.

RAG: что это

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

RAG решает две проблемы prompt engineering: ограниченный контекст (нельзя поместить всю корпоративную базу в каждый промпт) и устаревшие знания модели (информация обновляется в базе, не в модели).

Базовые компоненты: embedding-модель, векторная база данных, retrieval-логика, генеративная LLM. Подробнее RAG разобран в отдельной статье; здесь — для сравнения с другими подходами.

Fine-tuning: что это

Fine-tuning — продолжение обучения готовой модели на специфическом датасете. Веса модели обновляются, и она становится «специалистом» в конкретной области или формате ответов.

Типы fine-tuning:

• Full fine-tuning. Обновление всех параметров модели. Самый мощный, но самый дорогой.
• LoRA (Low-Rank Adaptation). Обновление только небольшой части параметров через дополнительные «адаптерные» слои. На порядки дешевле, чем full fine-tuning.
• QLoRA. LoRA в комбинации с квантизацией. Позволяет fine-tune’ить большие модели на consumer-уровне GPU.
• Instruction tuning. Дообучение на парах «инструкция — ответ» для улучшения следования формату.
• RLHF (Reinforcement Learning from Human Feedback). Обучение на основе оценок людей. Сложнее всего в реализации.

Для большинства практических задач достаточно LoRA — она даёт результаты, сопоставимые с full fine-tuning, при на порядки меньшей стоимости.

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

Когда применять Prompt Engineering

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

Сценарии применения:

• Классификация. Сортировка отзывов, тикетов, документов по категориям через few-shot promting.
• Извлечение данных. Парсинг неструктурированного текста (резюме, чеки, переписки) в JSON или таблицы.
• Стилистическая адаптация. Переписывание текста в другом тоне (формальный, дружелюбный, технический).
• Перевод и локализация. С учётом контекста и терминологии.
• Резюмирование. Сжатие длинных текстов в краткие выводы.
• Простые чат-боты. Когда система отвечает на основе общих знаний модели.
• Творческие задачи. Генерация идей, написание черновиков, brainstorming.

Если задача решается grade A через prompt engineering, не нужно тратить ресурсы на RAG или fine-tuning. Самая распространённая ошибка — попытка сразу прыгнуть к fine-tuning’у задач, которые решаются хорошим промптом.

Когда применять RAG

Подходит для задач, требующих специфической, актуальной, проверяемой информации.

Сценарии применения:

• Корпоративные ассистенты. Ответы на вопросы по внутренней документации компании.
• Поддержка клиентов. Бот, отвечающий на вопросы о конкретном продукте на основе его документации.
• Базы знаний. Семантический поиск + генерация ответов по корпоративной wiki.
• Юридические системы. Анализ контрактов, поиск по законодательству, прецедентам.
• Финансовая аналитика. Работа с актуальными отчётами, рыночными данными.
• Технические ассистенты. Ответы по документации продукта, API, библиотек.
• Медицинские помощники. Доступ к актуальным клиническим протоколам и исследованиям.
• Любая задача с фактами, специфическими для бизнеса. Цены, наличие, правила, политики компании.

RAG — оптимальный подход для подавляющего большинства корпоративных AI-приложений. Сочетает гибкость (легко обновлять данные) с надёжностью (можно проверить источник ответа).

Когда применять Fine-tuning

Подходит для задач, требующих изменения поведения, стиля или специфических навыков модели, которые не достигаются через промпт.

Сценарии применения:

• Специфический формат вывода. Когда нужен очень жёсткий формат, который сложно обеспечить промптом.
• Узко-доменный язык. Медицинская терминология, юридический жаргон, специализированные коды.
• Имитация стиля. Например, AI-ассистент, пишущий в стиле конкретного бренда или автора.
• Безопасность и compliance. Когда нужно гарантированно избегать определённых тем или формулировок.
• Снижение стоимости. Дообученная small-модель может выполнять задачу, требовавшую frontier-модели, за меньшие деньги.
• Очень высокая нагрузка. Когда стоимость API-вызовов frontier-модели становится экономически нецелесообразной.
• Privacy-критические задачи. Self-hosted fine-tuned модель полностью под контролем компании.
• Уникальные навыки. Способности, которым модель не научилась в pre-training.

Fine-tuning не помогает заучить факты — для этого работает RAG. Fine-tuning меняет поведение, стиль, формат. Использовать его для «впихивания» базы данных в модель — антипаттерн.

Гибридные подходы

Подходы не взаимоисключают друг друга, и продвинутые системы используют их комбинированно.

RAG + Prompt Engineering

Самая распространённая комбинация. Качественные промпты улучшают то, как модель использует найденный контекст. Few-shot примеры показывают модели, как должен выглядеть хороший ответ при определённом контексте.

Fine-tuning + RAG

Сильная связка для специализированных доменов. Fine-tuning адаптирует модель под язык и формат отрасли, RAG поставляет актуальные факты. Используется в медицинских, юридических, финансовых системах.

Fine-tuning + Prompt Engineering

Дообученная модель плюс хорошо составленные промпты. Подходит для специфических задач с предсказуемым форматом, где данные обновляются редко.

Все три

Сложные production-системы используют все три подхода. Fine-tuned модель с домено-специфическими навыками, RAG для актуальных данных, prompt engineering для качества ответов.

Стоимость каждого подхода

Точные цифры зависят от размера модели, объёма данных, используемых сервисов. Для prompt engineering и базового RAG расходы понятны заранее. Fine-tuning и RLHF — более рискованные инвестиции с непредсказуемым ROI.

Сложность реализации

Prompt Engineering

Требования: понимание задачи, умение писать инструкции, итеративное тестирование. Не нужны ML-навыки, инфраструктура, данные.

Кто может: маркетолог, продакт-менеджер, разработчик. Часто prompt engineering выполняется без участия ML-команды.

RAG

Требования: понимание архитектуры, навык работы с векторными БД, embedding-моделями, оркестраторами (LangChain, LlamaIndex). Подготовка данных, чанкинг, тестирование.

Кто может: backend-разработчик с базовым пониманием AI. ML-команда не обязательна для базового RAG.

Fine-tuning

Требования: подготовка качественного датасета (часто самая сложная часть), знание ML-фреймворков (PyTorch, Transformers), доступ к GPU, понимание гиперпараметров, навыки оценки качества обучения.

Кто может: ML-инженер. Без специалиста fine-tuning часто заканчивается потраченными ресурсами без результата.

Decision framework: как выбрать подход

Алгоритм выбора, который подходит в большинстве ситуаций:

1. Попробовать prompt engineering. Сформулировать запрос с примерами, протестировать на представительной выборке задач. Если результат удовлетворителен — остановиться.
2. Если нужны специфические данные — RAG. Подключить базу знаний, оптимизировать retrieval, протестировать.
3. Если нужно изменить поведение или формат — fine-tuning. Подготовить датасет, провести LoRA-fine-tuning, протестировать.
4. Если ни один подход не работает достаточно хорошо — комбинация. Fine-tuned модель + RAG + продуманные промпты.

Главное правило — начинать с самого простого. Около 80% задач решаются хорошим prompt engineering. Из оставшихся 20% большинство закрывается RAG. Fine-tuning остаётся для самых специфических случаев.

Типичные ошибки выбора

• Fine-tuning «потому что модно». Команды бросаются в дорогое обучение без проверки, решается ли задача проще.
• Fine-tuning вместо RAG для фактов. Попытка «впихнуть» базу данных в модель через обучение — не работает, провоцирует галлюцинации.
• RAG для задач, не требующих специфических данных. Если модель уже знает ответ из общих данных, RAG только усложняет систему.
• Игнорирование prompt engineering после внедрения RAG. Качество промптов остаётся важным даже при наличии RAG.
• Fine-tuning маленького датасета. Для качественного fine-tuning’a нужны от тысяч до десятков тысяч примеров. На 50 примерах модель просто переобучается.
• Слепая вера в специализированную модель. Дообученная модель может показывать худшие результаты на общих задачах, чем оригинал.
• Отсутствие метрик. Без бенчмарка из задач с эталонными ответами невозможно объективно сравнивать подходы.
• Переход к RAG/fine-tuning без оптимизации промпта. Часто базовый промпт работает плохо, и команда винит модель, а не свою формулировку.
• Игнорирование стоимости. Fine-tuning может стоить тысячи долларов и сэкономить копейки на запросе — экономика не сходится.
• Использование fine-tuning для безопасности. Дообучение модели «не отвечать на чувствительные темы» обходится через jailbreak. Безопасность строится на уровне системы, а не модели.

Эволюция подходов в 2025–2026

Граница между подходами размывается. Прогресс в технологиях смещает баланс:

• Огромные контекстные окна. Когда в промпт помещается миллион токенов, граница между «prompt engineering» и «RAG» становится условной. Зачем искать релевантные документы, если можно положить всю базу в контекст?
• Дешёвые модели. Falling cost of API-токенов делает дорогой fine-tuning менее оправданным.
• Reasoning-модели. Модели типа OpenAI o-серии, Claude Extended Thinking меняют качество ответов без необходимости fine-tuning’a.
• Agent-фреймворки. Сложные задачи решаются через композицию агентов с tools, что заменяет fine-tuning’и под специфические сценарии.
• Synthetic data generation. Использование LLM для генерации обучающих датасетов для fine-tuning’a других LLM.

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

Что выбрать для чат-бота поддержки?

В большинстве случаев RAG + хорошие промпты. Бот должен отвечать на основе документации продукта (RAG), в дружелюбном тоне с определённым форматом (prompt engineering). Fine-tuning редко оправдан для этой задачи.

Можно ли использовать fine-tuning для актуальной информации?

Технически — да, но непрактично. Каждое обновление данных требует переобучения. RAG обновляется мгновенно при изменении базы. Для актуальных фактов RAG почти всегда лучше.

Сколько примеров нужно для fine-tuning?

Минимум — 50–100 высококачественных примеров для LoRA. Оптимально — 1 000–10 000. Для специализированных задач — десятки тысяч. Качество датасета важнее количества: 100 идеальных примеров лучше, чем 1000 посредственных.

Что дешевле — frontier-модель с RAG или fine-tuned маленькая модель?

Зависит от объёма запросов. Малый объём (тысячи в месяц) — frontier-модель проще и дешевле. Большой объём (миллионы в месяц) — fine-tuned small модель может окупиться. Точка перелома обычно при 50 000–200 000 запросов в месяц.

Можно ли обойтись только prompt engineering?

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

Как оценить, какой подход работает лучше?

Через бенчмарк: собрать набор задач с эталонными ответами (50–500 примеров), прогнать через каждый подход, измерить качество автоматически (BLEU, ROUGE, embedding similarity) и руками (human evaluation). Без бенчмарка любые сравнения субъективны.

Заключение

Prompt engineering, RAG и fine-tuning — не альтернативы, а инструменты разной мощности. Опытные AI-команды последовательно поднимаются по этой лестнице: начинают с самого простого, добавляют сложность только когда результат недостаточен. Команды, прыгающие сразу к fine-tuning’у, чаще теряют время и деньги, чем команды, дисциплинированно отрабатывающие prompt engineering. Главное в выборе — не «что модно», а «что решает конкретную задачу с минимальными затратами». Этот принцип в 2026 году важнее, чем когда-либо: ландшафт меняется быстро, и подход, оптимальный год назад, сегодня может оказаться overkill.