Дообучение модели изнутри: где уходят деньги и время

Первая неделя такого проекта выглядит не так, как её представляют. Никто ничего не обучает. Мы сидим с предметным экспертом заказчика и по одному разбираем реальные обращения клиентов: вот здесь ответ хороший, вот здесь формально верный, но живой человек так не пишет, а вот здесь вообще надо было отказаться и перевести на менеджера. К пятнице у нас есть полторы сотни разобранных случаев и ни одной обученной модели. Это нормальный ход. В первой части мы разбирались, когда дообучение вообще уместно; здесь — как оно устроено, если решение принято.

Экзамен раньше учебника

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

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

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

Насколько сильно переоценивает — измерено в неожиданном месте. В 2025 году исследователи METR провели контролируемый эксперимент: опытные разработчики решали задачи в знакомых им репозиториях, с ИИ-инструментами и без. С инструментами они потратили на 19% больше времени, при этом были уверены, что ускорились примерно на 20%. Выборка узкая, и это не приговор инструментам. Но разрыв между ощущением и замером — сорок процентных пунктов — стоит запомнить любому, кто собирается оценивать качество модели по впечатлению.

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

Довольно часто единственный по-настоящему полезный результат такого проекта — сам проверочный набор. Потому что он показывает, что дообучение не нужно.

Данные лежат не там, где вы думаете

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

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

Сколько примеров нужно на самом деле — вопрос, на который честный ответ звучит как уклончивый. Порядок: сотни для узкой задачи вроде классификации обращений или разбора входящего письма на поля, единицы тысяч для чего-то более широкого. Старое правило «минимум десять тысяч» давно неверно. Точного числа не назовёт никто, потому что оно зависит от того, насколько грязные у вас данные, а это выясняется на второй неделе.

И контринтуитивное: больше не значит лучше. Шум в обучающей выборке закрепляется прочнее, чем шум в промпте, и потом его не переспоришь никакой инструкцией. Три редакции одного регламента в выборке — и модель добросовестно усвоит, что правильных ответов несколько.

Разметка, или чей это труд

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

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

Куда уходит смета

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

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

Железо и рубли без мистики

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

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

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

Что ломается

Список не полный, но эти семь встречаются в каждом втором проекте.

• Формат обучения не совпал с боевым. Учили на чистом тексте, в проде приходит распознанный скан. Или обучали с одним системным промптом, а в работе другой. Метрики отличные, эффекта ноль. Самая тихая из всех поломок.
• Тестовые данные протекли в обучающие. Один клиент встречается в двадцати строках, разбили случайно по строкам — его строки попали и туда, и туда. На тесте почти идеально, в проде посредственно, и никто не понимает почему. Делить надо по сущности: по клиенту, документу, сделке. А если задача дрейфует во времени — по времени: учим на прошлом, проверяем на будущем.
• Дисбаланс. Девяносто пять процентов заявок обычные, пять — срочные. Модель научилась всегда отвечать «обычная» и имеет формальную точность 95% при нулевой пользе: она пропускает ровно то, ради чего всё затевалось.
• Слишком много проходов по данным. Модель начинает воспроизводить обучающие примеры почти дословно, вместе с именами конкретных клиентов из выборки. Отдельно неприятно, если в выборке были персональные данные: из весов их потом не удалить по запросу, только переобучив заново.
• Забывание. Выиграли узкую задачу, проиграли общую адекватность. Лечится профилактически: в обучающую смесь подмешивают общие данные, а после каждого прогона гоняют отдельный «канареечный» набор посторонних вопросов — чтобы поймать деградацию раньше, чем её поймает клиент.
• Не заложено поведение при незнании. Бот отвечает всегда. В опте и рознице самая дорогая ошибка — уверенно названная неверная цена или срок. Умение сказать «не знаю» и передать человеку — это функциональное требование, а не мелочь на потом.
• Ослабление защитных механизмов. Показано (Qi и соавторы, ICLR 2024), что дообучение измеримо ослабляет встроенные ограничения модели — даже когда обучали на совершенно безобидных данных. После дообучения безопасность проверяется отдельно, это не паранойя.

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

Для тех, кто будет делать сам. Сегодняшний стандарт — лёгкое дообучение (LoRA или её экономная по памяти версия) поверх открытых весов; инструментарий сложился вокруг библиотек Hugging Face. Проходов по данным обычно один–три: больше — почти гарантированное зазубривание. В обучающую смесь штатно подмешивают 10–20% общих данных как профилактику забывания, а не как аварийную меру. Красный флаг после прогона — заметное падение на общих замерах при росте на целевом: это значит, что вы выиграли задачу и проиграли модель. Ещё одна привычка, экономящая нервы: один адаптер на задачу вместо одной модели «на всё» — дешевле обучать, проще проверять, откатывается по отдельности.

Российская специфика

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

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

И про 152-ФЗ, коротко и без запугивания. Закон требует не «чтобы сервер стоял у нас», а трёх вещей: законное основание обработки, хранение данных россиян на территории страны и реально работающие меры защиты. Локальное размещение закрывает только вторую. Персональные данные, попавшие в обучающую выборку, вшиваются в веса и по запросу не удаляются — при поиске по документам запись просто убирается из индекса, и это ещё один аргумент в пользу второй ступени. Про закрытый контур мы писали отдельно в материале о локальной нейросети.

Что остаётся у вас на руках

Нормальный итог проекта — не «работающий бот», а комплект, который можно передать кому угодно: файл-адаптер и понятная инструкция, как его подключить и откатить; проверочный набор с эталонами; обучающая выборка в разобранном виде; описанный порядок обновления. Если после проекта у вас нет хотя бы первых трёх пунктов, вы арендовали результат, а не купили.

Дальше модель живёт

Базовая модель обновится. Форма счёта сменится, потому что так решила бухгалтерия. Ассортимент вырастет вдвое, появится новая категория, и в ней своя манера общения. Ничего из этого не касается вашего кода — а качество упадёт.

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

Можно ли самому

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

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

С чего начать

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

• Больше 80% попаданий — дообучение вам не нужно, доводите промпт и поиск.
• Меньше 40% — проблема не в модели, а в данных или в постановке задачи. Обучение эту проблему не вылечит, а закрепит.
• Между — вот здесь есть о чём разговаривать. И только если наберётся достаточно примеров.

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