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

Команда получает задачу: «Сделайте наш ИИ лучше под наш конкретный сценарий использования». Есть несколько способов это сделать. Можно писать более качественные промпты. Можно построить RAG-систему, чтобы подавать модели релевантные данные. Можно дообучить модель на примерах своей предметной области.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жёсткие требования к формату. Выводы должны стабильно соответствовать конкретной схеме или стилю. Промптинг даст 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 поверх релевантной судебной практики и прецедентов.
• Без файнтюнинга; рассуждающие модели тянут на себе тяжёлую работу.

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

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

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

Компоненты:

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

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

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

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

Компоненты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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