Привет, Хабр! Я — Владимир Килязов, эксперт по машинному обучению в Cloud.ru. Последние несколько лет я активно помогаю бизнесу и технарям работать с LLM в своих задачах без космических бюджетов.
Помните времена, когда для обучения языковой модели новым трюкам, ее обязательно «доводили» на специальных датасетах? Теперь есть и другие варианты. Вместо классического дообучения можно использовать RAG и промт-инженерию, и это будет быстрее и дешевле. Получается, fine-tuning больше не нужен? Про это и порассуждаем тут в статье.

Как адаптировать под бизнес большие модели: три варианта
Начнем с начала. Сейчас есть три варианта оптимизации LLM:
● Fine-tuning (дообучение) — дополнительное обучение готовой языковой модели на узкоспециализированных данных. Она доучивается на новых примерах и изменяет вес. Например, можно скормить GPT-модели пачку медицинских текстов, чтобы она лучше понимала терминологию.
● Промпт-инженерия — в этом случае мы составляем правильные запросы к модели. Не изменяем ее, а оптимизируем ввод — продумываем подсказки, контекст, примеры, формат запроса так, чтобы направить модель и получить желаемый ответ. Метод не требует изменения параметров модели и новых данных — только экспериментов с формулировками.
● RAG (Retrieval Augmented Generation) — дословно «генерация с дополнением через поиск». Здесь важно понимать: модель сама никуда не подключается — это делает разработчик через внешний пайплайн. Схема работы простая: формируется запрос к источникам вроде документов, баз или интернета, извлечённые данные добавляются в подсказку, и LLM строит ответ уже с учетом этой информации. В классическом варианте веса модели остаются неизменными, а точность растет за счет доступа к внешним знаниям. В более продвинутых сценариях, например в Agentic RAG, сама модель может инициировать поиск как инструмент и использовать его в процессе генерации.
Почему fine-tuning теряет популярность
Когда LLM только появились, их обязательно дообучали. Но у этого подхода были минусы:
● Дорого и долго. Для классического fine-tuning приходится собирать и размечать датасет, подбирать гиперпараметры и использовать мощные графические процессоры для обучения. Такая адаптация модели под отраслевой корпус может растянуться на недели и потребовать значительных затрат на облачные вычисления — счет идет на тысячи долларов. Да, существуют более легкие методы, например LoRA или QLoRA. Они дообучают модель экономнее, меняя лишь часть параметров или сохраняя поправки в адаптерах. Это уменьшает нагрузку и позволяет работать с меньшими ресурсами. Иногда достаточно одной-двух GPU и пары часов. Однако даже с такими приемами fine-tuning остается сложным и ресурсоемким процессом, особенно если сравнивать его с RAG или другими подходами, где не требуется вмешательство в веса модели.
● Информация со временем устаревает. Модель обучается на данных, доступных на момент ее тренировки. Со временем часть сведений теряет актуальность, а модель продолжает опираться на старые знания. Чтобы обновить контент, ее приходится обучать заново или дообучать на новых данных, что, как уже говорилось выше, занимает много времени и стоит дорого. В результате без свежей информации страдает фактологичность ответов, LLM может выдавать формально связный текст, но с устаревшими или неточными данными.
● Каждое обновление = новое обучение. Если в модель не встроен механизм доступа к внешним данным, то добавление даже тысяч новых документов в базу ничего не изменит, она их просто не увидит. Чтобы включить свежую информацию, модель приходится обучать заново, фактически начиная процесс тренировки с нуля. В итоге любое крупное обновление превращается в полноценный цикл обучения: сбор датасета, подготовка инфраструктуры и недели работы на GPU. Именно поэтому классический fine-tuning плохо масштабируется и быстро устаревает по сравнению с подходами вроде RAG
● Catastrophic forgetting. Когда мы перенастраиваем модель на новом датасете, есть опасность, что она начнет хуже помнить то, что знала раньше. Новые знания как бы затирают часть старых. Например, доучив модель на текстах одной тематики, можно испортить ее ответы в других темах.
● Нужны ML-эксперты. Чтобы дообучать, нужно разбираться в глубоком обучении, архитектуре моделей, уметь готовить датасеты, оценивать результаты. А чтобы использовать промпт-инженерию или RAG, просто нужны классические навыки программирования и работы с данными, а не магия вне Хогвартса.
Подведу итог. Дообучение — вещь мощная, но тяжеловесная. Поэтому многие выбирают RAG и промпт-инжиниринг.

Если же нужны масштабирование решений, гибкая балансировка ресурсов и интеграция с корпоративными стандартами, многие компании выбирают инфраструктурные облачные платформы, например, такие как Cloud.ru Evolution. С ними можно запускать и ML-эксперименты, и промышленные LLM-сервисы в единой безопасной среде, не тратя время на обслуживание серверов и ручное администрирование.
Если fine-tuning — это как отправить AI обратно учиться, то RAG и хитрые подсказки — это как дать AI записную книжку и доступ к поиску.
Почему RAG и промпт-инжиниринг «в тренде»
Перечислю основные причины:
● Свежие данные при генерации ответа. Главная боль классических LLM заключается в том, что они «застывают» в момент обучения. Если модель обучили год назад — она так и останется жить в прошлом. Все события, законы, изменения в продуктах или инфраструктуре, произошедшие после этого, для нее попросту не существуют. Чтобы обновить картину мира, приходится заново собирать данные и запускать дорогостоящий цикл обучения, что по времени и деньгам сопоставимо с запуском нового продукта. RAG меняет правила игры. В этой архитектуре сама модель остается статичной, а актуальность ответа обеспечивается за счет внешней базы знаний. Мы просто обновляем документы, к которым имеет доступ пайплайн поиска, и уже на этом основании LLM строит свой ответ. Получается нечто вроде «живой надстройки»: модель помнит общее устройство языка и умеет рассуждать, а свежие факты она черпает из актуальных источников. Представьте практический сценарий. В компании выходит новая версия внутреннего регламента или нормативного документа. В классической модели сотрудники еще месяц будут получать устаревшие ответы, пока не запустят цикл переобучения. В RAG-системе достаточно добавить документ в индекс и уже через минуту модель корректно учитывает новые правила в ответах. Для бизнеса это означает мгновенное внедрение изменений без гигантских затрат на обучение. Именно поэтому RAG и промпт-инжиниринг сегодня часто воспринимаются как «козырь» по сравнению с тяжеловесным fine-tuning. Это гибкость, скорость и фактическая актуальность информации, которая в реальных сценариях ценится гораздо выше, чем попытка переписать все веса модели под новые данные.
● Меньше галлюцинаций. Поскольку RAG заземляет ответы на конкретных данных, уменьшается риск выдумок. Модель опирается на факты из базы, что повышает достоверность ответов.
● Быстрее запустить. Настроить индекс для поиска по документам и интегрировать его с моделью на порядок проще, чем вести многонедельный fine-tuning с неочевидным результатом. То же самое с промпт-инженерией. Можно улучшить ответы модели за счет подбора удачных формулировок запросов. Итерации происходят в режиме диалога с моделью. Это особенно ценно в прототипировании решений на базе AI.
Не всегда есть смысл поднимать инфраструктуру под RAG или эксперименты с LLM на своем железе. Сегодня проще и быстрее использовать облачные сервисы. У нас, например, есть Evolution AI Factory среда, которая позволяет разворачивать Retrieval-Augmented Generation и работать с языковыми моделями буквально «из коробки». В вашем распоряжении вычислительные ресурсы, хранилища, средства интеграции с корпоративными данными и инструменты для быстрых ML-экспериментов. Это значит, что проверить гипотезу или собрать прототип можно за часы, не тратя недели на развертывание собственной инфраструктуры и найм специалистов под круглосуточное сопровождение.
● Минимальные затраты на изменение требований. Достаточно поправить промпт или добавить/обновить документы в базе знаний. Не нужно гонять заново обучение на всех данных.
● Прозрачность и отслеживаемость ответов. Бонус RAG — traceability, возможность проследить, откуда взялся ответ. Поскольку модель извлекает конкретные документы, всегда можно сослаться на источник факта. В корпоративных сценариях это облегчает верификацию и аудит — каждое утверждение можно привязать к определенному документу, хранящемуся у вас. Если модель ошиблась, легко выяснить, на каком материале она основывалась, и исправить либо данные, либо алгоритм поиска. Fine-tuned модель — черный ящик: она выдает ответ, но непонятно, какой именно абзац из тысяч обучающих документов к нему привел.
● Можно внедрить контекст пользователя в каждый запрос. Например, чат-бот поликлиники не просто знает общие факты о болезни, но и ищет в базе данные пациента (анамнез, результаты анализов) и тут же учитывает их при ответе. Fine-tuning так не умеет — он «зашит» раз и навсегда, и подстраивать его под каждого человека невозможно без отдельной модели на каждого (что утопично). Промпт-инженерия тоже может эмулировать персонализацию, если включать нужные детали в запрос, но эти детали надо откуда-то достать — и тут выручит связка с RAG.
● Сохранность данных и приватность. При классическом fine-tuning ваши данные встраиваются в веса модели. Это значит, что часть информации теоретически может «просочиться» наружу: модель способна воспроизводить куски обучающих текстов. Более того, передавая стороннему провайдеру модель, дообученную на чувствительных данных, вы рискуете нарушить требования по безопасности. RAG работает иначе. Данные остаются во внешнем хранилище под вашим контролем, а модель лишь делает к ним краткий запрос во время ответа. Веса при этом не меняются, и информация не «утекает» в саму модель. Для компаний это критично, так проще соблюдать требования по приватности и минимизировать риски утечек, даже если сама система развернута в облаке
Где RAG однозначно выгоднее классического обучения
1. Для новостного чат-бота или поискового движка по свежей документации RAG станет очевидным выбором. Любые изменения в базе знаний сразу учтутся в ответах без переобучения модели.
2. Там, где важны точность и проверяемость (нужны ссылки). В ситуациях, где цена ошибки высока, RAG предпочтительнее, потому что позволяет сослаться на источник каждого факта. Юридический помощник на базе RAG может выдавать ответы со ссылками на конкретные законы или параграфы договора. Пользователь видит: ответ опирается на официальный документ — доверие выше.
3. Там где, нужна персонализация под пользователя или контекст запроса. AI-ассистент службы поддержки может при ответе подгрузить сведения о аккаунте клиента и на этой основе сформировать более релевантный ответ.
4. Если ограничены ресурсы на разработку и поддержку. Fine-tuning — длительный проект, требующий много человеко-часов и денег. А после релиза — еще и постоянного обслуживания. Если вы стартап или небольшой отдел, у вас может не быть роскоши держать команду ML-инженеров для таких задач. RAG-подход и умные промпты в этом случае привлекательны: базовую модель можно взять готовую через API, а свою специфичную информацию подавать ей через векторную базу. Это дешевле вначале и проще в итеративной доработке. Особенно на старте проекта разумно попробовать RAG/промпт-инженерию, и только если их возможностей будет недостаточно, инвестировать в полноценное дообучение.
5. Компании в регулируемых отраслях (финансы, медицина, госсектор) особенно ценят контроль над данными. В отличие от fine-tuning, где обучающий корпус частично фиксируется в весах модели, при RAG информация остается во внешнем хранилище и подгружается только в момент запроса. Это снижает риски утечек и упрощает соответствие требованиям комплаенса. Кроме того, если необходимо удалить или скорректировать данные, достаточно обновить внешнюю базу и ответы будут учитывать изменения мгновенно, без повторного цикла обучения. Именно поэтому RAG удобен там, где критично соблюдение нормативов по безопасности и приватности.
Когда нужен fine-tuning
Итак, fine-tuning канул в лету? И да, и нет. Классическое дообучение теперь реже используется как первый инструмент. Но это не значит, что fine-tuning совсем исчез. Есть задачи, где без него пока никуда.
1. Модель должна генерировать текст в узком формате или стиле. Юридический AI, заполняющий документы как нотариус, или медицинская модель, оформляющая отчеты по заданному шаблону, — такие сценарии надежнее всего достигаются fine-tuning на тысячах примеров. RAG тут не поможет: он подтянет факты, но не научит модель писать «как юрист». промпт-инжиниринг может задать тон, но не даст стопроцентного соблюдения формата. На практике для таких задач часто применяют облегченные методы вроде LoRA или QLoRA. Они позволяют дообучить модель под конкретный стиль без полного переобучения всех весов, что экономит ресурсы и время.
2. Если нужно исправить слабые места в модели. Если исходная LLM регулярно ошибается в каких-то типовых задачах или путается в терминологии, целенаправленное дообучение на примерах правильных ответов поможет ей подтянуть уровень. Например, модель путает имена иностранных политиков — можно дообучить ее на датасете биографий, и она перестанет ошибаться. RAG здесь тоже вариант (искать информацию), но иногда эффективнее именно научить модель, особенно если запросы однотипные.
3. Если нужно работать в автономном режиме. Если приложение должно работать офлайн или с минимальными задержками, внешние запросы нежелательны. Представьте бортовой компьютер самолета с AI-моделью: доступа к облаку нет, все знания должны быть внутри. Или мобильное приложение, которое должно отвечать мгновенно — интеграция RAG может дать лишние миллисекунды/секунды на поиск. В этих сценариях выигрывает заранее дообученная модель, у которой все, что нужно, уже внутри. Она автономна и не зависит от соединения с базой знаний.
На мой взгляд, будущее за комбинацией методов. Никто не запрещает сначала дообучить модель на своих данных, а затем подключить к ней RAG для актуальных сведений. Такой гибрид способен и говорить на языке вашей предметной области, и не терять свежести знаний. Разумеется, стоить связка будет недешево, поэтому решение оправдано для действительно важных задач.
Коротко о главном
Fine-tuning как подход не умер полностью и не потерял актуальности, но его «золотое время» в чистом виде прошло. Прежде чем тратить ресурсы на дообучение огромной LLM, компании всё чаще выбирают более лёгкие пути: инженерию промптов, подключение внешних баз знаний или использование инструментов вроде LangChain. Во многих случаях этого достаточно, чтобы решить задачу без тяжёлых и дорогих циклов обучения.
С другой стороны, для сверхспециализированных или критически важных сценариев классический fine-tuning остается востребованным. Будущее, скорее всего, за комбинацией трех подходов:
когда нужно подмешивать свежие факты через RAG,
когда важна форма задавать стиль и тональность через промпт-инжиниринг,
а там, где без обучения не обойтись, то использовать точечный fine-tuning, чаще всего в формате экономичных техник вроде LoRA или QLoRA.
Такое сочетание позволяет одновременно держать актуальность знаний, управлять стилем и сохранять контроль над узкими задачами, не раздувая стоимость эксплуатации моделей до небес.
А вы что выбирате? RAG, fine-tuning или промпт-инжиниринг?
Kerts89
что выгоднее с точки зрения ресурсов GPU?
BaxLi
Вопрос немного не синхронен с вариантами того что происходит в каждом случае.
В силу своего опыта разработки самих моделей на уровне нейронных архитектур, отвечу что наибольшее потребление происходит при обучении.
РАГ при нарезке и векторизировании/ чанкинге потребляет существенно меньше ресурсов.
Ну и промпт я бы просто назвал незначимым, ибо он все равно существует во всех 3х случаях, но мне самому не нравится ответ.
Эт как сравнивать синее с сладким и мелким ... :)