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

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

С вами вновь Александр Константинов — технический эксперт из Cloud.ru. И на этот раз мы разберем, как избежать главных ошибок тонкой настройки: от принятия решения о ее необходимости до семи смертных грехов, которые губят большинство проектов.

А точно ли нужен Finetuning? 

Семь смертных грехов, которые погубят Finetuning (и рекомендации, как их искупить)

Обжорство, Лень, Жадность, Гордыня, Гнев, Похоть, Зависть

Хороший Finetuning — это марафон, а не спринт

А точно ли нужен Finetuning? 

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

Finetuning — спасательный круг

• Узкоспециализированные задачи. Вам нужен AI-юрист, который видит нюансы договоров вашей юрисдикции, или диагност, замечающий аномалии на снимках, не описанные в учебниках. Finetuning учит модель понимать контекст, а не искать по ключевым словам.

• Стиль и личность. Вам нужен не ассистент, а голос бренда: ироничный сотрудник технической поддержки или чопорный бухгалтер. Здесь нужно «перепрошить» манеру генерации.

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

• Актуализация знаний (но в связке с RAG). Если нужно, чтобы модель 2022 года оперировала концепциями 2025, Finetuning может помочь. Но это дорогой способ «освежить» знания, и он не отменяет RAG для оперативных данных.

Finetuning — ошибка

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

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

• Данных катастрофически мало. Для Finetuning нужны тысячи качественных примеров. Обучение на паре сотен примеров ведет к недобучению, и всё придется начинать сначала. Лучше использовать Few-Shot промптинг и вставлять примеры прямо в запрос.

Итого

Запомните правило: Finetuning — это про то, как модель думает. RAG и промптинг — про то, что она знает. Определились, что в какой категории ваш кейс? Если в первой, то добро пожаловать на адскую кухню ML-инженера.

Семь смертных грехов, которые погубят Finetuning (и рекомендации, как их искупить)

Обжорство

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

Представьте, что крупный ритейлер создавал AI-ассистента для колл-центра. Его кормили всем подряд: логами чатов, расшифровками звонков, письмами с жалобами. В результате на запрос «Где мой заказ?» модель выдавала цитаты из жалоб, фразы вроде «передам специалисту» или начинала рассуждать о возвратах.

Всё потому, что модель «накормили» хаосом данных: приветствия, прощания, вопросы без ответов, эмоциональные высказывания. 

Как искупить грех: 

• Жесткий контроль качества. Создайте эталон, например, вручную соберите 20–50 идеальных пар «вопрос-ответ». Все данные должны сверяться с ним по стилю. Поручите это эксперту (например, лучшему оператору поддержки) или сформулируйте сами.

• Глубокая очистка. Фильтруйте по длине (удаляйте слишком короткие/длинные реплики), убирайте текст с CapsLock, спецсимволами т.д.

• Смысловая дедубликация. Группируйте запросы по смыслу, а не по словам («не пришел заказ» = «где посылка»). После оставьте 1–2 самых качественных примера из каждого кластера, остальные удалите. Это уберет перекос в данных и предотвратит переобучение на популярных формулировках.

• Балансировка тем. Воспользуйтесь техникой классификации или кластеризации, чтобы автоматически разметить все собранные данные по темам (например: «доставка», «оплата», «возвраты», «гарантия»). Если 80% данных — о доставке, а о возвратах — 20%, модель будет слаба в возвратах. Искусственно уравняйте представленность тем, чтобы у нее не было пробелов в знаниях.

Лень 

Лень — ситуация, в которой вы запускаете обучение и уходите пить кофе, надеясь, что раз Training Loss (ошибка на обучающих данных) падает, то значит всё идет по плану. Это главная причина, почему модели, идеально отвечающие на учебные примеры, позорно проваливаются на реальных данных.

Здесь есть хороший пример из жизни. Представьте, что ученик готовится к экзамену, зазубривая ответы на конкретные билеты. Если на самом экзамене ему попадется ровно тот же билет, он с блеском его сдаст (это низкий Training Loss). Но если вопрос будет задан по-другому или на смежную тему, которой не было в изначальном списке, он провалится, потому что не понял предмет, а просто запомнил ответы.

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

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

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

Как искупить грех лени:

• Главное правило — всегда выделяйте Validation set. С самого начала. Без этого вы летите вслепую.

• Смотрите не только на Loss. Помимо общей ошибки (Loss), нужно отслеживать качественные метрики (Task-specific metrics) на валидационной выборке. Эти метрики показывают реальное качество, например:

  • F1-score: идеален для задач классификации (спам/не спам, тематика и т.д.). Учитывает и точность, и полноту ответов.

  • BLEU или ROUGE: стандартные метрики для оценки качества сгенерированного текста (например, его перевода). Показывают, насколько совпадают слова и смыслы между текстом модели и эталонным ответом.

• Внедрите Early Stopping. Early Stopping — это алгоритм, который постоянно следит за метриками на валидационной выборке. Он не даст модели провести тысячи эпох, чтобы зазубрить учебник. Суть в том, что он помогает остановить ее в тот момент, когда она достигла пика понимания и вот-вот начнет забывать общие принципы и переобучаться. С ним уйти пить кофе просто не получится.

• Держите под рукой слепой тест (Test Set). По аналогии с обучением, это выпускной экзамен. Это еще один набор данных, который модель не видит ни во время обучения, ни во время валидации и настройки гиперпараметров. Вы используете его только один раз в самом конце для финальной оценки качества. Это честная проверка того, как модель справится с абсолютно новыми для нее данными.

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

Жадность

Жадность — это погоня за быстрым результатом и установка завышенной скорости обучения модели (LR). Слишком высокий LR можно сравнить с попыткой въехать на парковку на второй космической скорости. В результате модель не успевает «осмыслить» данные, проскакивает точки оптимума, функция потерь начинает дико колебаться или улетает в бесконечность (это называется «дивергенция»). В итоге веса модели становятся бесполезными.

Реальный кейс: стартап торопился запустить чат-бота. Чтобы ускорить обучение, они выставили LR = 1e-3 вместо рекомендованных 1e-5. В результате функция потерь скакала и улетела в бесконечность, а веса модели стали бесполезными.

Всё потому, что был задан слишком большой шаг градиентного спуска. Модель «перепрыгивала» точку оптимума.

Как искупить грех:

• Начинайте с низких значений. 2e-5 или 3e-5 — безопасная отправная точка для Finetuning. Разогнаться вы всегда успеете.

• Используйте планировщики (schedulers). Не держите LR постоянным. Например, позвольте модели сделать крупные шаги в начале и «приземлиться» в конце: 

  • линейное затухание (Linear Decay) плавно уменьшает LR от стартового значения до почти нуля к концу обучения;

  • косинусное затухание (Cosine Annealing) уменьшает LR по кривой, похожей на косинусоиду, что позволяет модели в конце обучения сделать несколько более крупных «исследующих» шагов для лучшего «приземления» в точке минимума.

• Визуализируйте и анализируйте процесс. Смотрите на график потерь (Loss curve). Он должен быть плавным и не снижаться резко. Если он напоминает кардиограмму пациента в критическом состоянии — ваш LR слишком высок, нужно понижать.

• Поэтапный подход. Начните с маленького LR, дождитесь сходимости, и только потом можете очень осторожно его увеличивать в следующих экспериментах.

Гордыня

Гордыня — это отказ от создания своего датасета из-за веры в «магию» чужого. Например, уверенность, что качественный датасет с Hugging Face (типа legal_qa) идеально подойдет для ваших задач. Такая слепая вера ни к чему хорошему не приведет, а только убьет модель.

Приведем пример из практики. Одна команда взяла англоязычный датасет по контрактам, чтобы создать AI-юриста для договоров аренды в РФ.

Но в результате модель уверенно ссылалась на американское право, неправильно трактовала договоры и пропускала риски, которые актуальны для России. 

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

Как искупить этот грех:

• Проводите аудит. Перед использованием просмотрите 100–200 примеров. Соответствуют ли они вашим требованиям? Актуальны ли они для вашего рынка, сегмента аудитории? 

• Тестируйте перед обучением. Прогоните свои реальные данные (например, компания из примера могла бы прогнать хотя бы 10 договоров) через модель, дообученную на чужом датасете. Сразу станет ясно, подходит он или нет.

• Используйте как основу. Чужой датасет можно использовать для «общего понимания», но финальное дообучение делайте только на своем, выверенном датасете.

• Цените время. Пара недель на создание датасета на 5 000 качественных примеров даст больший эффект, чем месяц борьбы с чужим датасетом на 100 000 примеров.

Гнев

Гнев — это слепая ярость ML-инженера от попыток решить задачу неподходящим инструментом. Вы пробовали когда-нибудь забить гвоздь микроскопом или построить небоскреб с помощью детского молотка? Переводя на язык Finetuning, это всё равно что использовать гигантскую модель для простой задачи или наоборот — слабую модель для сложной.

Реальный кейс из практики: команда разработчиков решила сделать чат-бота для часто задаваемых вопросов (FAQ) на сайте. Объем базы — 50 вопросов-ответов. На волне хайпа руководство настояло на использовании самой мощной из доступных им моделей (Llama 2 70B).

Результат был дорогостоящим и неэффективным:

• инференс был медленным и дорогим. Обслуживание такой модели требовало мощной и дорогой GPU-инфраструктуры;

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

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

Проблема кроется в несоответствии масштаба задачи и сложности модели. Для простого поиска по базе FAQ существуют гораздо более эффективные и дешевые методы (например, RAG).

Как искупить грех гнева:

• Соизмеряйте задачу и модель. Например, для чат-ботов поддержки и классификации текста часто хватает моделей размера 7B–13B параметров (Mistral 7B, Llama 3 8B). Для сложных задач (анализ кода, сложные выводы) уже могут потребоваться модели от 34B и выше.

• Проведите реалистичный расчет стоимости владения (TCO). Оцените не только стоимость обучения, но и стоимость инференса. Спросите себя: «Сможем ли мы содержать модель-гигант в продакшене? Хватит ли у нас GPU-мощностей?» Часто стоимость инференса на протяжении года кратно превышает разовую стоимость обучения.

• Рассмотрите иерархический подход. Не пытайтесь заставить одну модель делать всё. Часто эффективнее создать конвейер:

  1. классификатор (маленькая модель ~7B) определяет намерение пользователя ( «вопрос о доставке», «проблема с возвратом», «общий вопрос»);

  2. маршрутизатор направляет запрос в нужный сервис. Например, если вопрос из FAQ, то отправляет запрос в RAG-систему, которая быстро найдет точный ответ в базе знаний. Или если у пользователя проблемы с возвратом, то запускает скрипт для создания заявки в CRM.

• Начните эксперименты с качественной, но небольшой модели (например, с Llama 3 8B). Велика вероятность, что ее возможностей вам хватит с головой, а апгрейднуть вы всегда успеете.

Похоть 

В чем суть греха? В безудержном желании использовать самые модные, сложные и экзотические методы там, где можно обойтись простыми и надежными решениями. Это не качественный Finetuning, а погоня за хайпом. И желание сделать «круто», а не «эффективно».

Представьте, что команда разрабатывала ассистента для подбора товаров в интернет-магазине. Задача была четкой: по характеристикам товара (цвет, размер, цена) и истории просмотров пользователя генерировать краткое описание и рекомендацию.

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

• кастомной архитектуры нейросети с несколькими головами внимания;

• ансамбля из нескольких моделей (одна для анализа истории, другая для генерации текста);

• самодельного алгоритма ранжирования поверх выхода моделей.

Представили результат? Команда потратила три месяца на разработку и отладку этой «Франкенштейн-системы». Она работала нестабильно, ее было невозможно адекватно тестировать, а качество рекомендаций оказалось ниже, чем у простой fine-tuned Llama 3 8B, которую джун мог подготовить за две недели.

Не нужно создавать сложности ради сложностей. Страсть к эксперименту затмила конечную бизнес-цель — получение работающего и надежного решения.

Как искупить грех:

• Принцип бритвы Оккама: не усложняйте без необходимости. Всегда начинайте с самого простого работоспособного решения (например, качественный датасет + Finetuning стандартной модели с помощью LoRA). Усложняйте архитектуру только тогда, когда уперлись в потолок качества и можете доказать, что новая сложность даст прирост.

• Считайте стоимость владения (TCO). Каждая добавленная вами сложность — это будущие затраты на поддержку, обновление, отладку и онбординг новых сотрудников. Будет ли отдача от этой сложности адекватна? Если нет, отрезайте лишнее.

• Сильно связные, слабо связанные — ключевой принцип сложных систем. Строите сложную систему? Разбейте ее на максимально независимые модули. Пусть каждый решает свою задачу (например, один модуль ищет товары, другой — генерирует текст). Это позволит тестировать и улучшать их по отдельности, а не ломать голову над монолитом.

• Решение должно быть скучным. В enterprise-разработке «скучное» и предсказуемое решение — лучшее решение. Использование стандартных, проверенных методов (как те же LoRA или библиотека Transformers) снижает риски и ускоряет разработку.

Не нужно поддаваться искушению сделать «самое крутое ML-решение». Стремитесь сделать эффективное и надежное решение бизнес-проблемы. Чаще всего это путь простоты и здравого смысла.

Зависть

Не нужно сравнивать результаты своей небольшой, дообученной на специфичных данных модели с возможностями GPT-4 или Claude 3. Это гарантированный путь к выгоранию и ощущению, что ваш проект провалился, хотя на самом деле он мог быть очень успешным.

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

Но вместо радости команда проверила тот же набор отзывов через GPT-4, и он показал 97%. Вместо празднования своей победы, они начали срочно искать, что же сделали не так, пытаясь догнать недостижимый эталон.

В чем суть греха? В непонимании цели кастомизации. Ваша цель — не победить в общем зачете гигантов с их триллионами параметров. Ваша цель — решить конкретную бизнес-задачу лучше, чем это делалось раньше, и дешевле, чем использовать готовые решения.

Как искупить грех зависти:

• Сравнивайте себя с собой, а не с гигантами индустрии. Ваш главный бенчмарк — это качество базовой модели до Finetuning на вашем тестовом наборе. Улучшили ее показатели на 15%? Это оглушительный успех!

  Например, если раньше ваша система ошибалась в 20% случаев, а теперь только в 6% — это огромное достижение, неважно, что где-то есть модель, которая ошибается в 3% случаев.

• Считайте экономику, а не только проценты. Как сравнить стоимость? Посчитайте два сценария:

  • стоимость аренды сервера для вашей модели (допустим, 500 ₽ в час) ÷ количество обработанных запросов в час;

  • стоимость 1 000 запросов по прайсу OpenAI (допустим, 300 ₽) ÷ 1000.

  Что же выгоднее? Часто своя модель, даже с чуть худшим качеством, но с предсказуемой ежемесячной стоимостью, оказывается в 10-100 раз выгоднее, чем плата за каждый запрос к GPT-4.

• Заранее определите, что для вас «успех». Какие метрики взять? Это зависит от задачи, например:

  • для классификации (спам/не спам, позитивный/негативный отзыв) можно смотреть на точность (Accuracy) или F1-score (учитывает и точность, и полноту ответа);

  • для генерации текста (ответы на вопросы, описания товаров) — ROUGE или BLEU. Они показывают, насколько текст модели похож на эталонный.

• Цените свои уникальные преимущества. Ваша собственная модель — это не просто цифры в отчете. Она просто ваша, и это супер, потому что находится за firewall-ом, не делится данными с третьими сторонами и в ней нет рисков, связанных с API-лимитами.

Хороший Finetuning — это марафон, а не спринт

Главный итог нашей статьи: разработка AI-агента под себя — не магия и не алхимия. Успех Finetuning определяется не хайповыми моделями, а дисциплиной данных, трезвой оценкой задач и выбором простых работающих решений. Ваша цель — не обогнать GPT-4, а создать модель, которая решает вашу проблему лучше вчерашнего дня и дешевле типовых решений. 

Если вы только начинаете путь в кастомизации AI, чтобы не наступать на все грабли сразу, можно начать с AI-сервисов от нас. Например, аккуратно дообучить модель через Evolution ML Finetuning или добавить ей актуальных знаний с помощью Evolution Managed RAG.

Расскажите, какой из «грехов» оказался самым болезненным именно в вашей практике? Делитесь в комментариях — обсудим, как искупить его с минимальными потерями.