Простыми словами
Fine-tuning - это дообучение уже готовой языковой модели на ваших примерах. Модель не создают с нуля, а аккуратно подстраивают под конкретную задачу: нужный стиль ответа, формат JSON, классификацию обращений, извлечение данных из документов или внутреннюю терминологию компании.
Проще представить так: базовая модель уже умеет говорить, рассуждать и писать. Fine-tuning показывает ей много примеров того, как именно вы хотите получать результат. После этого модель чаще повторяет нужный шаблон без длинных объяснений в промпте.
Но fine-tuning не стоит воспринимать как волшебную загрузку знаний в голову модели. Если вам нужны актуальные цены, регламенты, инструкции, карточки клиентов или документы компании, чаще нужен RAG, а не дообучение.
Когда fine-tuning полезен
Fine-tuning хорошо работает там, где задача повторяется много раз и у вас уже есть хорошие примеры правильных ответов.
Например, поддержка каждый день получает сотни обращений, и их надо стабильно раскладывать по категориям: доставка, возврат, оплата, гарантия, жалоба. Можно написать промпт, но модель все равно иногда будет называть категории по-разному. Дообучение помогает сделать поведение ровнее.
Другой пример - единый стиль ответов. Если компания хочет, чтобы ассистент отвечал коротко, спокойно, без канцелярита и в одном tone of voice, fine-tuning может быть полезен. Особенно если простые инструкции уже стали слишком длинными и все равно не дают стабильности.
Еще один хороший сценарий - извлечение данных. Например, из письма или документа нужно доставать сумму, дату, номер договора, название компании и признак риска. Здесь fine-tuning может помочь модели лучше понимать ваши типовые документы.
Когда fine-tuning не нужен
Fine-tuning часто пытаются сделать слишком рано. Это ошибка.
Если модель отвечает плохо, сначала надо понять почему. Может быть, промпт расплывчатый. Может быть, в RAG попадает не тот документ. Может быть, схема JSON плохо описана. Может быть, нет validation в backend. Может быть, модель вообще не видит нужные данные.
В таких случаях fine-tuning не решит проблему. Он просто научит модель увереннее повторять ошибки.
Дообучение обычно не нужно, если вы еще не пробовали хороший системный промпт, few-shot примеры, RAG, structured output и evals. Fine-tuning имеет смысл только тогда, когда более простые способы уже проверены и понятно, что именно надо улучшить.
Fine-tuning или RAG
Самое частое заблуждение: “мы дообучим модель на наших документах, и она будет знать базу компании”. На практике для этого почти всегда лучше подходит RAG.
RAG достает нужные фрагменты документов прямо во время ответа. Документ обновился - индекс обновили, и модель отвечает по новым данным. Можно показать источник, проверить права доступа и удалить устаревшую информацию.
Fine-tuning больше подходит не для хранения фактов, а для поведения. Он помогает модели отвечать в нужном стиле, соблюдать формат, классифицировать, извлекать поля и понимать повторяемые паттерны.
Коротко: знания и документы - чаще RAG. Поведение и формат - иногда fine-tuning.
Fine-tuning или хороший промпт
Промпт дешевле, быстрее и проще откатывается. Поэтому почти всегда начинать надо с него.
Хороший промпт может задать роль, правила, формат, примеры и ограничения. Для многих задач этого достаточно. Если модель иногда ошибается в стиле или формате, можно добавить несколько примеров прямо в запрос.
Fine-tuning нужен, когда промпт разрастается, становится дорогим, сложным и все равно не дает стабильности. Тогда часть поведения можно перенести из промпта в модель.
Это похоже на разницу между инструкцией сотруднику и обучением сотрудника на множестве реальных кейсов. Инструкция быстрее, обучение глубже, но требует времени и качественных материалов.
Какие данные нужны
Качество fine-tuning почти полностью зависит от качества примеров. Нельзя просто выгрузить сырые чаты поддержки и надеяться на хороший результат.
Нужны пары “вход - правильный выход”. Если это классификация, у каждого обращения должна быть правильная категория. Если это стиль ответа, нужен хороший эталонный ответ. Если это извлечение данных, должны быть проверенные поля.
Плохие примеры опасны. Модель запомнит канцелярит, ошибки, лишние фразы, устаревшие правила, персональные данные и хаотичные категории. Поэтому dataset надо чистить: удалять мусор, дубли, секреты, персональные данные без необходимости и противоречивые ответы.
Лучше иметь меньше примеров, но хороших. Пятьсот аккуратных кейсов часто полезнее, чем двадцать тысяч сырых логов.
Как проверять результат
Fine-tuning нельзя оценивать по ощущениям. Нужны evals.
Сначала фиксируют baseline: как справляется обычная модель с хорошим промптом. Потом обучают новую версию и прогоняют ее на тех же тестовых примерах. Сравнивают точность, формат, стоимость, скорость, количество ошибок, необходимость ручной проверки и поведение на сложных кейсах.
Важно проверять модель не на тех же примерах, на которых она училась. Иначе можно получить красивый результат, который развалится на новых данных. Это называется overfitting: модель запомнила тренировочные ответы, но не научилась нормально обобщать.
Если fine-tuned модель лучше только на знакомых примерах, пользы мало. Она должна быть лучше на новых похожих задачах.
Какие риски есть
Fine-tuning добавляет в проект новую сложность. Появляется версия модели, версия dataset, процесс обучения, сравнение качества, релиз и откат.
Главные риски простые: обучить на плохих данных, переобучить модель, случайно использовать персональные данные, ухудшить старые сценарии или решить не ту проблему. Бывает и так, что после дообучения модель лучше держит стиль, но хуже следует строгому JSON. Поэтому без evals и rollback лучше не запускать такую версию в production.
Отдельно важна безопасность. Если в dataset попали секреты, токены, личные данные клиентов или закрытые документы, это уже не техническая мелочь, а серьезный риск.
Как принимать решение
Перед fine-tuning стоит задать себе несколько вопросов.
Есть ли у нас понятная повторяемая задача? Есть ли хорошие примеры правильного результата? Есть ли baseline для сравнения? Есть ли evals? Понятно ли, почему промпта, RAG или structured output уже недостаточно? Есть ли план отката?
Если на эти вопросы сложно ответить, fine-tuning лучше отложить.
Если ответы есть, дообучение может дать хороший эффект: сократить промпт, стабилизировать формат, улучшить классификацию, снизить количество ручных правок и сделать поведение модели ближе к вашему продукту.
Короткий вывод
Fine-tuning нужен не для того, чтобы “залить знания в модель”. Для знаний чаще используют RAG.
Fine-tuning нужен, когда вы хотите стабильно повторять нужное поведение: стиль, формат, классификацию, извлечение данных или работу с типовыми доменными примерами.
Начинать лучше с промпта, RAG, structured output и evals. Дообучать модель стоит тогда, когда есть чистые данные, понятная метрика, baseline и реальная причина усложнять систему.
Частые вопросы
Fine-tuning добавляет модели новые знания?
Не совсем. Он может помочь модели лучше вести себя в вашем домене, но для актуальных документов, цен, регламентов и клиентских данных обычно лучше подходит RAG.
Что лучше: RAG или fine-tuning?
Если нужны факты и документы - чаще RAG. Если нужно стабильное поведение, стиль, классификация или формат - можно рассматривать fine-tuning.
Сколько примеров нужно?
Зависит от задачи. Иногда помогают сотни хороших примеров, иногда нужны тысячи. Важнее не количество, а чистота и единообразие данных.
Можно ли начать без evals?
Для эксперимента можно, для production - нет. Без evals вы не поймете, стало ли лучше и не сломались ли старые сценарии.
Fine-tuning заменяет guardrails?
Нет. Даже дообученная модель может ошибаться. Validation, guardrails, human review и логи все равно нужны.
