Почему дешёвый прогон не означает дешёвый проект

LoRA и QLoRA сделали адаптацию больших языковых моделей заметно доступнее. Вместо изменения всех весов LoRA обучает небольшие низкоранговые матрицы, а базовая модель остаётся замороженной. QLoRA дополнительно загружает базовые веса в 4-битном виде и обучает адаптеры через квантованную модель. В исходной работе QLoRA авторы показали дообучение модели на 65 млрд параметров на одной GPU с 48 ГБ памяти.

Для малого бизнеса это важный технический сдвиг: эксперимент с моделью класса 7–9 млрд параметров уже не обязательно требует собственного кластера. Но из этого легко сделать неверный финансовый вывод — считать стоимостью проекта только часы GPU.

Обучающий прогон может быть дешёвым. Рабочая система всё равно требует:

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

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

Когда дообучение решает правильную задачу

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

Типичные задачи:

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

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

Практический порядок проверки такой:

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

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

Из чего складывается полный бюджет

1. Постановка задачи и базовая линия

До начала обучения нужно определить, что считается успехом. Для классификации это могут быть precision и recall по каждому важному классу. Для генерации документа — доля ответов, прошедших схему, бизнес-правила и проверку специалиста. Для поддержки — время до утверждённого ответа и число опасных ошибок.

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

2. Данные

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

Набор следует разделить как минимум на обучение, настройку и финальную проверку. Близкие варианты одного документа нельзя раскидывать по разным частям: иначе метрика будет завышена из-за утечки.

3. Эксперименты и вычисления

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

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

4. Оценка и приёмка

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

В бизнес-процессе полезна метрика «доля операций, принятых без исправлений», а не только близость ответа к эталонному тексту. Она напрямую связана с трудозатратами.

5. Развёртывание и сопровождение

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

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

Модельный расчёт для небольшой компании

Рассмотрим пилот классификации и подготовки черновиков на локальной instruct-модели около 8 млрд параметров. Это не рыночная смета, а способ увидеть структуру затрат.

Допущения:

  • 2 000 отобранных примеров;
  • 48 часов профильных специалистов на правила, очистку и разметку по 2 500 ₽;
  • 32 часа ML-инженера на конвейер, эксперименты и развёртывание по 3 500 ₽;
  • 24 часа независимой проверки результатов по 2 500 ₽;
  • 20 часов аренды GPU по условным 250 ₽;
  • 12 часов инженерного сопровождения в первый месяц по 3 500 ₽.

Получается:

  • данные и правила — 120 000 ₽;
  • инженерная работа — 112 000 ₽;
  • независимая оценка — 60 000 ₽;
  • GPU — 5 000 ₽;
  • первый месяц наблюдения — 42 000 ₽;
  • всего — 339 000 ₽.

В этой модели вычисления занимают около 1,5% бюджета. Если аренда GPU подорожает вдвое, общий бюджет вырастет всего на 5 000 ₽. А если команда недооценит очистку данных на двадцать часов, проект станет дороже на 50 000 ₽. Главный финансовый риск находится не там, где светятся видеокарты.

Как посчитать окупаемость без самообмана

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

`месячная ценность = объём операций × сэкономленные минуты × стоимость часа / 60 − ежемесячное сопровождение`.

Продолжим модельный пример. Пусть система обрабатывает 3 000 случаев в месяц, после дообучения экономит в среднем 1,5 минуты проверки на каждом принятом результате, а полная стоимость часа сотрудника равна 1 200 ₽. Валовая экономия составит 90 000 ₽ в месяц. При сопровождении 25 000 ₽ чистый эффект — 65 000 ₽, а простой срок возврата пилотных 339 000 ₽ — около 5,2 месяца.

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

До запуска зафиксируйте:

  • время операции до пилота;
  • долю результатов без исправлений;
  • цену ложного принятия и ложного отказа;
  • объём исключений для человека;
  • регулярные расходы на мониторинг и переобучение.

Архитектура, которая сохраняет экономику

Минимальный производственный контур выглядит так:

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

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

Риски, которые нельзя вынести за скобки

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

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

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

Конкретный следующий шаг

До закупки GPU выберите одну повторяемую операцию и соберите 150–300 реальных примеров. Уберите дубли, выделите закрытый тест и измерьте базовую модель с промптом и RAG. Затем разметьте остаточные ошибки на три группы: знания, поведение и интеграция.

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

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