Выбор между промптингом, RAG и файнтюнингом (и когда их сочетать)

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

Это не взаимозаменяемые вещи. Они решают разные проблемы. Если ошибиться, потратите три месяца и бюджет на файнтюнинг там, где ответом был лучший промпт. Или построите громоздкую RAG-инфраструктуру там, где файнтюнинг был бы проще. Или застрянете на промптах там, где модель принципиально не может сделать то, что нужно.

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

Что на самом деле делает каждый из них

Чёткое разграничение:

Промптинг меняет то, о чём просят модель. Вы даёте модели более качественные инструкции, примеры, требования к формату, контекст. Сама модель не меняется; меняется вход.

RAG меняет то, какие данные видит модель. Вы достаёте релевантную информацию в момент запроса и включаете её в промпт. У модели есть свежие, специфические, динамические данные — без обучения на них.

Файнтюнинг меняет то, что модель знает или как себя ведёт. Вы обучаете модель на примерах, меняя её веса. Сама модель обновляется.

Они решают разные проблемы:

• Инструкционный разрыв: модель могла бы выполнить задачу, если правильно её попросить. → Промптинг.
• Разрыв в знаниях: модели нужна информация, которой у неё нет. → RAG.
• Разрыв в способностях: модель не может стабильно выполнять задачу даже с хорошими промптами и контекстом. → Файнтюнинг.

Понять, какой именно разрыв у вас, — это половина успеха.

Диагностика разрыва

Когда ИИ не делает того, что вам нужно, спросите:

Мог бы умный человек, имея только промпт, выполнить эту задачу?

Если да → инструкционный разрыв. Должен помочь промпт получше.

Если нет, смог бы он выполнить её, если бы вы дали ему релевантные справочные материалы?

Если да → разрыв в знаниях. Может помочь RAG.

Если нет, смог бы он выполнить её после длительной практики и обратной связи?

Если да → разрыв в способностях. Файнтюнинг может помочь.

Если нет → возможно, задача LLM не решается. Пересмотрите проблему.

Большинство проблем «ИИ не работает» — это инструкционные разрывы; решает их более удачный промптинг. Следующие по частоте — разрывы в знаниях. Настоящие разрывы в способностях — самая малочисленная категория, но самая трудная.

Промптинг: недооценённый рычаг

Промптинг — самый дешёвый, самый быстрый и чаще всего правильный ответ. И всё же команды перескакивают через него к RAG или файнтюнингу.

Что можно сделать только промптингом:

• Поменять тон, формат, длину.
• Применить шаблоны рассуждения (chain-of-thought, самокритика).
• Закодировать ограничения (делай X, не делай Y).
• Закодировать политики и защитные правила.
• Адаптироваться под конкретные юзкейсы (разные промпты для разных фич).
• Повысить стабильность через few-shot-примеры.

Чего нельзя сделать только промптингом:

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

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

Усилия на промпт-инжиниринг

Неделя интенсивной итерации над промптом может дать драматическое улучшение. Типичная кривая:

• День 1: бейзлайн. Посредственные результаты.
• Дни 2–3: структурные изменения. Лучший формат, более чёткие инструкции. Большие улучшения.
• Дни 4–5: примеры и краевые случаи. Ловим типичные провалы.
• Дни 6–7: тон, ограничения, шлифовка. Последние 10% улучшения.

После недели вы вытащили из промптинга почти всё, что он может дать. Если всё ещё не довольны — разрыв, скорее всего, в знаниях или в способностях.

Как выглядят хорошие промпты

Для ориентира, сильный промпт обычно содержит:

• Чёткую роль и задачу.
• Конкретные требования к формату.
• 1–5 репрезентативных примеров (если нужны).
• Явные ограничения (что делать, чего не делать).
• Обработку краевых случаев.
• Схему вывода.

Обычно 5–10 абзацев. Не слишком короткий (недоопределённый), не слишком длинный (модель теряет фокус).

RAG: исправление знаний

RAG — правильный инструмент, когда:

• Модели нужна фактическая информация, которой у неё нет.
• Информация меняется (живые данные, недавние события, данные по конкретному аккаунту).
• Информация специфична для вашей предметной области или организации.
• Нужны цитаты / доказуемая опора на источник.

И неправильный, когда:

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

Реалистичная стоимость

RAG-система — это серьёзная инженерия:

• Сборка: 4–12 недель для серьёзной (ingestion, чанкинг, эмбеддинги, retrieval, reranking, evals).
• Эксплуатация: постоянная — поддерживать индекс актуальным, мониторить качество, чинить проблемы.
• Инфраструктура: векторная БД, расходы на эмбеддинги, расходы на reranking. Обычно €200–2000/мес для систем умеренного масштаба.
• Стоимость одного запроса: выше, чем при чистом промптинге (дополнительные эмбеддинги + retrieval + больший контекст). Обычно в 2–5 раз дороже классического API-вызова.

Для правильных задач это окупается. Но это значительная инвестиция по сравнению с промптингом.

Качество RAG — это путь

Работающая RAG-система к концу первой недели обычно даёт 60–70% качества. Доведение до продакшен-уровня (85%+) занимает ещё 1–2 месяца работы: улучшение чанкинга, добавление reranking, починка провалов, построение эвалов.

Планируйте это. Не выкатывайте в проде на первой неделе; получите злых пользователей.

Файнтюнинг: когда промптинга и RAG недостаточно

Файнтюнинг — правильный инструмент, когда:

• У вас явный разрыв в способностях — модель не может стабильно выполнять задачу даже при хороших промптах и контексте.
• У вас есть хорошая партия качественных обучающих примеров — минимум несколько сотен для очень узкой LoRA, типичнее 1000+ для устойчивого общего поведения. Точные пороги по технике см. в статье про файнтюнинг.
• Нужно стабильное, узкое поведение (конкретный стиль, конкретный формат вывода, конкретная предметная область).
• Важна стоимость инференса / задержка (зафайнтюненная меньшая модель может быть дешевле, чем универсальная большая).

И неправильный, когда:

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

Виды файнтюнинга

Полный файнтюнинг: обновляются все веса модели. Самый мощный, самый дорогой. Требует значительных compute-ресурсов. Обычно прерогатива лабораторий, выпускающих базовые модели.

LoRA (Low-Rank Adaptation): обучается только небольшое подмножество весов. Гораздо дешевле. Часто даёт результаты, конкурентоспособные с полным файнтюнингом для узких задач.

QLoRA: квантованная LoRA. Ещё дешевле. Качество на масштабе ниже, но для многих задач разумно.

Prompt tuning / prefix tuning: ещё меньше; обучаются только «мягкие» промпты. Самое дешёвое. Ограниченные возможности.

Instruction tuning: обучение модели следовать инструкциям. Обычно делается на уровне базовой модели; конечным пользователям редко полезно.

RLHF / DPO / KTO: обучение модели на данных предпочтений (ответ A против B). Мощно для поведенческих изменений; сложно сделать хорошо.

В 2026 году большинство команд, занимающихся файнтюнингом, применяют LoRA поверх сильной базовой модели. Это правильный баланс цены и возможностей для большинства юзкейсов.

Реалистичная стоимость

Стоимость файнтюнинга зависит от подхода и масштаба, но для типичной LoRA на open-модели среднего размера с 5K–10K примеров:

• Подготовка данных: 1–4 недели. Часто основной объём работы. Курирование, очистка, форматирование примеров.
• Тренировка: от часов до дней, в зависимости от размера датасета и инфраструктуры. €100–2000 в compute.
• Эвалы: 1–2 недели. Построение эвал-наборов, сравнение зафайнтюненной модели с базовой.
• Итерации: 1–3 цикла, пока что-то не станет готово к продакшену.
• Развёртывание: если используете managed API (OpenAI fine-tuning, Anthropic, Vertex) — просто. Если хостите сами — больше работы.
• Поддержка: переобучение при обновлении данных, при обновлении базовой модели, при смене юзкейса.

Итого: 6–12 недель работы, €1K–€20K в compute (в зависимости от масштаба), постоянная поддержка.

Значительная инвестиция. Убедитесь, что оно того стоит.

Когда файнтюнинг блистает

Конкретные сценарии, где файнтюнинг явно выигрывает:

Жёсткие требования к формату. Выводы должны стабильно соответствовать конкретной схеме или стилю. Промптинг даст 95%; файнтюнинг — 99%.

Узкоспециализированные предметные области. Медицинская терминология, юридические формулировки, код на внутреннем DSL. Файнтюнинг учит модель вашему конкретному диалекту.

Личность / голос. Стабильный голос на тысячах взаимодействий. Промпты могут «съезжать»; файнтюнинг впекает это намертво.

Оптимизация задержки/стоимости. Зафайнтюненная 7B-модель, заточенная под вашу задачу, может быть дешевле и быстрее, чем универсальная 70B. На большом объёме это окупается.

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

Когда файнтюнинг не оправдывает ожиданий

Типичные способы разочароваться в файнтюнинге:

Недостаточно данных. Файнтюнинг на 100 примерах обычно мало что даёт. Очень узкая LoRA иногда работает на нескольких сотнях; для устойчивого общего поведения планируйте 1000+ качественных примеров.

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

Катастрофическое забывание. Тяжёлый файнтюнинг на узкие задачи может ухудшить общие способности. Модель становится лучше в вашей задаче, но хуже во всём остальном.

Устаревшие знания. Зафайнтюненная модель — это снимок. Новая информация требует переобучения. Для динамичных предметных областей это вечная статья расходов.

Базовая модель улучшается быстрее, чем файнтюн. Базовая модель стала достаточно хорошей, и файнтюн уже не лучше. Теперь вы поддерживаете файнтюн устаревшей базы.

Проблемы оценки. Без серьёзных эвалов вы не знаете, помог ли файнтюнинг, навредил или не повлиял. Многие «успешные» файнтюны — это плацебо-победы.

Шаблоны комбинирования

В продакшене лучшие системы сочетают все три подхода.

Комбинация 1: Промптинг + RAG (самая частая)

Дефолт для приложений, насыщенных знаниями.

• Тщательно спроектированные промпты кодируют инструкции, формат, ограничения.
• RAG обеспечивает свежую, специфическую информацию.
• Без файнтюнинга; опираемся на сильную базовую модель.

Это самый распространённый продакшен-паттерн в 2026 году. Работает для большинства юзкейсов.

Комбинация 2: Зафайнтюненная модель + RAG

Когда нужны и поведенческая специализация, и динамические знания.

• Файнтюн под голос, формат, предметную область.
• RAG для свежей информации.
• Промпты оркестрируют.

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

Комбинация 3: Специализированные файнтюны под конкретные задачи

Разные файнтюны под разные части системы.

• Файнтюн под классификацию для маршрутизации.
• Файнтюн под суммаризацию для дайджестов.
• Файнтюн под генерацию ответов клиентам.
• Каждый меньше, быстрее, специализированнее.

Используется, когда важны масштаб и оптимизация стоимости. Каждый файнтюн хорошо делает свою узкую работу; оркестрация их вызывает.

Комбинация 4: Зафайнтюненный роутер + универсальные модели

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

Файнтюн маленький, быстрый, узкий. Дорогая универсальная работа выполняется универсальными моделями, которые остаются актуальными.

Это сочетает экономичность (файнтюн небольшой) с возможностями (универсальные модели на тяжёлой работе).

Фреймворк принятия решения

Практическая последовательность:

Вопрос 1: Решается ли задача с текущей моделью и хорошим промптом?

Если да: пишите промпт. Итерируйте неделю. Выкатывайте.

Если нет — к Вопросу 2.

Вопрос 2: Связана ли задача со знаниями, которых у модели нет?

Если да: стройте RAG. Тратьте месяцы. Доводите до продакшен-уровня. Сочетайте с сильным промптингом.

Если нет — к Вопросу 3.

Вопрос 3: Касается ли задача стабильного формата, узкой предметной области или конкретного поведения?

Если да И у вас хотя бы несколько сотен (в идеале 1000+) качественных примеров — файнтюньте. Сочетайте с промптингом и, возможно, с RAG.

Если примеров нет — вкладывайтесь в их сбор ИЛИ продолжайте дожимать промптинг/RAG, прежде чем браться за файнтюнинг.

Вопрос 4: Сделали ли вы эвал-работу, чтобы понять, какой подход реально помогает?

Этот вопрос применим на каждом шаге. Без эвалов вы гадаете.

Продакшен-примеры

Несколько реальных комбинаций:

Пример 1: ИИ-поддержка клиентов

Постановка: ИИ-поддержка SaaS-компании на первой линии.

Компоненты:

• Сильные промпты под тон, формат, политики эскалации.
• RAG поверх свежих документов, политик, истории тикетов.
• Лёгкий файнтюн под фирменный голос компании и шаблоны эскалации (1500 примеров, отобранных из прошлых тикетов).

Итог: Автономно закрывает 65% тикетов. Файнтюн отвечает за стабильный голос; RAG поддерживает точность; промпты обрабатывают политики.

Пример 2: Проверка юридических документов

Постановка: Legal-tech продукт проверяет контракты на риски.

Компоненты:

• Подробные промпты, кодирующие, что искать (юридические категории, рубрика серьёзности).
• RAG поверх релевантной судебной практики и прецедентов.
• Без файнтюнинга; reasoning-модели тянут на себе тяжёлую работу.

Итог: Чистый промптинг + RAG работает хорошо, потому что у модели уже есть юридическое обучение. Файнтюнинг помог бы лишь немного; инвестиция не оправдалась.

Пример 3: Автодополнение кода на кастомном DSL

Постановка: Специализированный инструмент работы с данными со своим DSL.

Компоненты:

• Промпты с примерами.
• Без RAG (DSL достаточно мал, чтобы влезть в контекст).
• LoRA-файнтюн на 10K примерах DSL.

Итог: Файнтюнинг был необходим. Без него модель не могла стабильно генерировать валидный DSL. Промптов и контекста было недостаточно.

Пример 4: Внутренний корпоративный ассистент

Постановка: Универсальный ассистент для сотрудников компании.

Компоненты:

• Сильные системные промпты (голос, поведение, отказы).
• RAG поверх корпоративной вики, Slack, документации.
• Без файнтюнинга; «голос» компании заложен в промптах.

Итог: RAG + промпты покрывают большинство юзкейсов. Компания недостаточно своеобразна, чтобы голосу требовался файнтюнинг.

Типичные ошибки

Несколько шаблонов неправильного распределения усилий:

Ошибка 1: Сразу хвататься за файнтюнинг. Команды слышат «нам надо зафайнтюнить свою модель» и стартуют отсюда. В 90% случаев промптинг + RAG был бы быстрее, дешевле и не хуже.

Ошибка 2: Пропускать RAG, когда он и есть ответ. Команды строят громоздкие промпты, чтобы «напомнить» модели корпоративную информацию, которую очевидно следовало получать в момент запроса. Проще получить.

Ошибка 3: Файнтюнинг без эвалов. «Мы зафайнтюнили, и стало лучше.» Никаких метрик. Часто файнтюн не сделал ничего или даже навредил. Без эвалов вы не знаете.

Ошибка 4: Устаревшие файнтюны. Файнтюн полугодовой давности, времён, когда лучшим был GPT-4. Сегодняшние frontier-модели без файнтюна превосходят зафайнтюненную старую. Файнтюны нужно переоценивать по мере движения области.

Ошибка 5: Пытаться зафайнтюнить факты. Команды пробуют дообучить модель «знать про нашу компанию». Работает плохо — модель что-то запоминает, что-то галлюцинирует. RAG обрабатывает факты; файнтюнинг — поведение.

Ошибка 6: Слишком короткие итерации над промптами. Два дня итераций над промптом — это только старт. Две недели дают реальный ответ.

Ошибка 7: Перекладывать в RAG то, что мог бы сделать промптинг. Корпоративный документ на 50K токенов, вложенный в промпт, иногда проще, чем RAG. Особенно для малых корпусов.

Сравнение по стоимости и усилиям

Грубое сравнение для типичного проекта среднего размера:

| Подход | Усилия | Стоимость (разовая) | Стоимость (за запрос) | Поддержка | |----------|--------|----------------|------------------|-------------| | Промптинг | 1–2 недели | минимальная | базовая стоимость API | низкая | | RAG | 6–12 недель | развёртывание инфраструктуры (~€1K–5K) | 2–5× базы | умеренная (ingestion, эвалы) | | Файнтюнинг (LoRA) | 6–12 недель | тренировочный compute (~€500–5K) | базовая (часто дешевле при меньшей модели) | высокая (данные, переобучение, эвалы) | | Промптинг + RAG | 8–14 недель | инфраструктура | 2–5× базы | умеренная | | Все три | 12–20 недель | суммарно | по-разному | высокая |

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

Ключевая мысль

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

Честный порядок применения:

1. Промптинг (1–2 недели итераций). Самый дешёвый, самый быстрый, чаще всего достаточный.
2. RAG, если есть явный разрыв в знаниях. Серьёзная инвестиция, но с понятными границами.
3. Файнтюнинг, если есть явный разрыв в способностях, который промптинг + RAG не закрывают. Самый дорогой; в последнюю очередь.
4. Комбинации — для зрелых продакшен-систем.

Команды, у которых получается, честно отвечают, какой именно у них разрыв, и дисциплинированы в эвалах. Без эвалов нельзя понять, какой подход помог. С ними путь обычно ясен.

Большинство проектов «нам надо зафайнтюнить свою модель» при ближайшем рассмотрении должны звучать как «нам надо писать промпты получше и добавить RAG». Берегите файнтюнинг для случаев, которым он действительно нужен.

Результат: лучшие системы, быстрее, дешевле. О чём и должно быть выкатывание ИИ в продакшен.