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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверяемый промпт может включать:

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

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

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

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

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

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

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

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

RAG-система требует полноценной инженерной работы:

• Сборка: загрузка данных, права доступа, разбиение на фрагменты, индексирование, поиск, оценка и эксплуатация; оценивайте сроки по своим источникам и критериям приёмки.
• Эксплуатация: постоянная — поддерживать индекс актуальным, следить за качеством, чинить проблемы.
• Инфраструктура: парсинг и OCR, хранение, эмбеддинги, поиск, переранжирование, генерация, резервное копирование и телеметрия; рассчитывайте стоимость по датированным предложениям и измеренным объёмам.
• Стоимость одного запроса: могут добавиться эмбеддинг запроса, поиск, переранжирование и токены контекста, но точный контекст иногда позволяет использовать более дешёвую модель. Измеряйте полный путь запроса.

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

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

Универсального процента «качества первой недели» не существует. Сравните лексический, векторный и гибридный поиск на размеченном наборе, измерьте полноту поиска и качество итоговых ответов по отдельным категориям, затем меняйте по одному этапу. Запускайте систему для пользователей только после прохождения проверок ошибок и прав доступа, относящихся к вашему бизнесу.

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

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

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

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

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

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

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

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

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

Prompt tuning / prefix tuning: обучает непрерывные параметры промпта или префикса. Польза меньшей обучаемой поверхности зависит от оборудования, поддержки поставщика, качества на задаче и интеграции с сервером.

Instruction tuning: контролируемое дообучение на парах «инструкция — ответ». Оно распространено при создании моделей и может быть полезным экспериментом прикладной команды, если это позволяют лицензия, данные, инфраструктура и тесты.

RLHF / DPO / KTO: разные семейства оптимизации по предпочтениям; они не взаимозаменяемы и не используют одинаковые данные. Сверяйтесь с первичной публикацией и документацией выбранной реализации, затем проверяйте качество предпочтений, вознаграждения и регрессии безопасности.

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

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

Стоимость и длительность дообучения зависят от базовой модели, длины последовательностей, объёма токенов, числа эпох, оборудования, распределённого обучения, сбоев и оценки. Начинайте расчёт с небольшого инструментированного запуска:

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

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

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

Сценарии, в которых эксперимент с дообучением может быть оправдан:

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

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

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

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

Адаптация поведения. Настройка безопасности может улучшить измеряемое поведение при отказах, но также способна привести к лишним отказам, пропустить опасные запросы или ухудшить другие способности. Она должна оставаться одним из уровней защиты наряду с детерминированной авторизацией, применением правил, мониторингом и контролем человека.

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

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

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

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

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

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

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

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

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

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

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

Вариант по умолчанию для приложений, насыщенных знаниями.

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

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

Комбинация 2: Дообученная модель + RAG

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

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

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

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

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

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

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

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

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

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

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

Схема принятия решения

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

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

Если да: создайте и оцените базовый вариант с промптом. Запускайте его только после прохождения критериев качества и безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

Компоненты:

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

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

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

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

Компоненты:

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

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

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

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

Компоненты:

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

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

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

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

Компоненты:

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

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

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

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

Ошибка 1: Сразу хвататься за дообучение. Сначала проверьте базовые варианты с промптами и поиском. Многие предполагаемые проблемы дообучения на деле связаны с инструкцией или отсутствующим контекстом, а базовый вариант даёт данные для решения.

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

Ошибка 3: Дообучение без оценки. Без отложенного базового варианта и результатов по отдельным категориям нельзя связать изменение с улучшением, а регрессии останутся незаметными.

Ошибка 4: Устаревшие дообученные модели. Базовые модели, серверы, данные и требования продукта меняются. Перед повторным обучением или дальнейшим использованием адаптера заново запустите неизменённый базовый вариант и приёмочные тесты.

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

Ошибка 6: Нет правила остановки работы над промптом. Без отложенного набора можно бесконечно подгонять инструкцию под примеры. Остановитесь или пересмотрите подход, когда заранее выбранные показатели перестают улучшаться.

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

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

Рабочая таблица для сравнения — заполните её измеренными или полученными от поставщиков данными при одинаковом пороге качества:

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

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

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

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

1. Создайте простейший подходящий базовый вариант. Часто это промптинг или ограниченный вывод, но поиск либо обращение к авторитетному инструменту может быть проще, если факты уже хранятся в рабочей системе.
2. Добавьте поиск, если проверка выявила проблему с доказательствами или актуальностью, затем оцените полный путь загрузки, прав доступа, поиска и генерации.
3. Проведите эксперимент с дообучением, если доказан разрыв в поведении или качестве выполнения задачи и имеются репрезентативные данные с проверенными правами, а также поддерживаемая среда инференса.
4. Объединяйте методы только тогда, когда каждый компонент даёт измеримое дополнительное улучшение, оправдывающее расширение эксплуатационной поверхности.

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