LoRA или полный fine-tune для русской предметной области

Почему этот выбор часто решает результат

Выбор между LoRA и полным fine-tune влияет не столько на скорость запуска, сколько на то, сможет ли модель нормально работать в проде. Команды часто смешивают две разные задачи. Первая - научить модель понимать термины, сокращения и рабочие формулировки. Вторая - заставить ее стабильно отвечать в нужном формате, нужным тоном и без срывов в стиль базовой модели.

Это разные вещи. Модель может уверенно объяснять, что такое ПДн, скоринг или андеррайтинг, и при этом ломать JSON, путать поля местами или внезапно переходить с делового русского на нейтральный чат. Для внутреннего поиска это терпимо. Для клиентского сценария или автоматической обработки ответов - уже нет.

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

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

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

Что меняет LoRA, а что меняет полный fine-tune

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

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

Если упростить, разница выглядит так:

• LoRA быстрее учится и дешевле в запуске.
• LoRA требует меньше VRAM и чаще помещается на доступных GPU.
• Полный fine-tune дольше считается и чаще просит более серьезный кластер.
• Чекпойнт LoRA маленький, а полный fine-tune хранит полную копию модели.

В цикле экспериментов это чувствуется сразу. LoRA удобно прогонять несколько раз в день: поправили датасет, переобучили, проверили. Полный fine-tune обычно планируют как отдельный этап, потому что даже одна ошибка в разметке обходится заметно дороже.

С переносом на другую базовую модель оба подхода неудобны, но по-разному. Адаптер LoRA обычно жестко привязан к конкретной базе и даже к ее версии. Если команда сегодня тестирует Qwen 3, а завтра решает перейти на Llama 4, старый адаптер почти наверняка не пригодится. Полный fine-tune тоже не переносится на новую базу, но это хотя бы ожидаемо: вы берете тот же датасет и обучаете новую модель заново.

Во время работы LoRA означает пару "база + адаптер", за совместимостью которой нужно следить. Иногда адаптер заранее сливают с базой, но тогда часть удобства при обновлениях теряется. Полный fine-tune проще как единый артефакт: загрузили одну модель и обслуживаете ее как отдельную версию. Зато каждая новая версия тяжелее, дольше выкатывается и дороже хранится.

Если вы тестируете несколько моделей через единый OpenAI-совместимый шлюз, как RU LLM, разница проявляется еще быстрее. LoRA удобна для быстрых проверок на одной базе. Полный fine-tune имеет смысл тогда, когда нужно глубоко изменить поведение модели, а не слегка его подправить.

Когда адаптеров хватает

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

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

Полный fine-tune часто не нужен, если выход простой и короткий. Один класс, несколько полей в JSON, две строки справки, стандартная формулировка отказа или подтверждения - для таких задач LoRA обычно достаточно.

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

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

LoRA особенно уместна там, где предметные термины важнее авторского стиля. Если вам нужен точный разбор полей "ИНН", "КПП", "номер счета" и "дата списания", решает словарь предметной области и дисциплина формата. Фирменный тон тут почти ничего не меняет.

Хороший признак для LoRA простой: задачу можно описать одной фразой, а шаблон ответа стабилен. Например, "прочитай текст и верни 4 поля" или "выбери один класс и добавь короткую причину". В таких сценариях полный fine-tune часто дает мало пользы за лишние деньги и время.

Где LoRA не вытягивает формат и стиль

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

Строгий формат ломается первым

Если модель должна вернуть строгий JSON с десятком связанных полей, LoRA нередко держится только на простых примерах. На коротких запросах все выглядит прилично. На реальных кейсах она начинает путать зависимости между полями: ставит правильный статус, но неверное объяснение, забывает обязательный флаг, меняет тип значения или добавляет лишний текст вне схемы.

Типичный пример - внутренний помощник банка. Он знает факты по продукту, но в ответе должен одновременно выдать decision, reason, risk_flags, legal_basis, next_step и срок действия решения. LoRA часто учит названия полей, но хуже держит их согласованность. Полный fine-tune обычно лучше закрепляет сам шаблон ответа, а не только лексику вокруг него.

Длинный ответ тянет модель назад к базе

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

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

В русских предметных текстах это видно особенно хорошо. Модель знает, что нужно сослаться на 152-ФЗ, на согласие субъекта персональных данных или на условия договора, но пишет неточно: путает падеж, смягчает обязательную формулировку, меняет "обязан" на "может", смешивает канцелярский и разговорный регистр. Факт формально верный, а юридический или редакционный смысл уже съехал.

Частый сбой выглядит так: ответ по сути правильный, но вместо принятого шаблона модель уходит в общий стиль базы. Она добавляет вступление, вставляет лишние оговорки, меняет порядок блоков, пишет "человечнее", чем требует процесс. Для обычного чата это терпимо. Для API, комплаенса, внутреннего контроля и публикации от имени бренда - уже нет.

Если ошибка в форме ломает интеграцию или согласование, одних адаптеров часто мало. Тогда полный fine-tune нужен не ради новых знаний, а ради дисциплины ответа.

Как выбрать подход по шагам

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

Удобно пройти по простой схеме.

1. Сначала зафиксируйте, что именно должно измениться. Запишите это прямо: модель должна лучше знать термины, всегда отвечать в JSON, писать сухо и без лишних фраз, ссылаться на внутренние правила, не путать роли клиента и сотрудника.
2. Соберите небольшой, но чистый эталон. Для первого прогона часто хватает 100-300 примеров, если они ровные по качеству. Лучше 120 хороших ответов, чем 2000 сырых.
3. Прогоните базовую модель без обучения. Используйте те же промпты, которые пойдут в тест. Сохраните не только общий балл, но и типы ошибок: путает термины, ломает структуру, пишет слишком разговорно, пропускает обязательные поля.
4. Обучите LoRA на том же наборе и сравните строго на тех же примерах. Не меняйте сразу промпт, температуру и формат оценки, иначе вы сравните все сразу и ничего не поймете.
5. Переходите к полному fine-tune только после явного провала LoRA по нужным метрикам. Если адаптер уже дает нужный уровень, полный fine-tune часто добавит затрат и рисков, а пользы будет мало.

Для честного сравнения держите среду одинаковой. Если команда тестирует модели через единый OpenAI-совместимый endpoint, как в RU LLM, можно не трогать код и промпты и менять только саму модель или способ дообучения. Так проще понять, что дало эффект: данные, адаптер или полный цикл обучения.

Хороший признак зрелого решения простой: вы можете показать 10-20 типовых запросов, где разница видна сразу и без долгих объяснений.

Как подготовить данные для честного сравнения

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

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

Минимум стоит развести примеры на четыре группы:

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

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

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

Такая разметка быстро отрезвляет. LoRA нередко держит факты на приемлемом уровне, но хуже соблюдает жесткий шаблон ответа. Полный fine-tune иногда дает ровнее стиль и формат, и это видно только тогда, когда вы не смешиваете все промахи в одну оценку.

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

Не вычищайте сложные русские случаи ради удобства. Оставляйте примеры со склонениями, аббревиатурами, сокращениями и разными форматами записи: "01.02.2024", "1 февраля 2024", "ЦБ РФ", "г. Москва", "5 млн руб.". В проде именно на таких мелочах модель чаще всего спотыкается.

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

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

Пример для внутреннего помощника банка

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

На таком кейсе разница между LoRA и полным fine-tune видна быстро. Если базовая модель уже неплохо пишет по-русски, LoRA часто хватает, чтобы подтянуть предметные слова и связать их с нужными правилами банка. После короткого цикла дообучения модель начинает увереннее различать "Семейную ипотеку", рыночную программу и рефинансирование, понимать разницу между первоначальным взносом и подтверждением дохода, правильно называть анкеты, согласия и внутренние формы.

На коротких ответах это работает хорошо. Сотрудник спрашивает: "Какие документы нужны ИП для заявки на ипотеку?" Модель с LoRA уже не путает паспорт, выписку по счету, налоговую отчетность и внутреннюю анкету. Она реже выдумывает названия документов и лучше держит лимиты, если вы дали ей свежие примеры.

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

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

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

Полный fine-tune обычно лучше держит такие вещи. Он не только запоминает термины, но и глубже перестраивает привычку модели отвечать. В результате она стабильнее сохраняет форму карточки, реже пропускает оговорки, лучше выдерживает один и тот же тон в длинных ответах и в диалоге из нескольких сообщений.

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

Ошибки, которые ломают выводы

Сравнение LoRA и полного fine-tune часто портит не само обучение, а способ проверки. Команда видит хороший средний балл и решает, что модель готова. Потом ассистент банка один раз выдает неверный JSON в сценарии проверки клиента, и весь "хороший средний результат" уже ничего не значит.

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

Частая проблема сидит в данных. Если вы складываете в один датасет FAQ, деловые письма и JSON-ответы без явной разметки, модель получает противоречивый сигнал. Она не понимает, когда говорить кратко, когда писать вежливое письмо, а когда вернуть строгую структуру без лишнего текста. После этого легко сделать ложный вывод, что LoRA не тянет или что полный fine-tune вдруг "исправил стиль". На деле вы сравнили не методы, а беспорядок в примерах.

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

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

На практике стоит проверять четыре вещи:

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

Последний пункт часто недооценивают. Первый прогон может быть дешевым, а дальше начинаются новые версии датасета, повторное обучение, регрессии, поддержка шаблонов и пересчет метрик. Если полный fine-tune дает 3% прироста, но потом требует постоянной пересборки пайплайна, это уже не "чуть дороже". Это другой режим работы команды.

Нормальный вывод появляется только тогда, когда вы держите постоянными модель, тесты и критерии отказа. Иначе спор про LoRA и полный fine-tune превращается в спор про шум.

Быстрая проверка перед запуском

Перед релизом мало смотреть на среднюю оценку по красивой выборке. Гораздо полезнее увидеть, как модель ведет себя на неприятных запросах подряд. Если после десятка удачных ответов она начинает ломать формат, путать сокращения или менять тон, в проде это всплывет сразу.

Нормальный быстрый тест занимает пару часов. Возьмите 50-100 сложных примеров из реальных сценариев и прогоните одну и ту же пачку через базовую модель, LoRA-версию и полный fine-tune. Не смешивайте запросы "для галочки" с тяжелыми кейсами. Нужны длинные инструкции, шумный контекст, редкие русские термины, внутренние аббревиатуры и случаи, где ответ должен держать строгую структуру.

Проверьте хотя бы пять вещей:

• держит ли модель формат на всей серии, а не на первых 10 запросах;
• не плывет ли ответ после длинного контекста на 8-15 тысяч токенов;
• не распадаются ли русские термины, артикулы, коды продуктов и сокращения вроде "ПДн", "ДБО" или "ФЛ";
• сохраняет ли модель одинаковый тон и порядок блоков на похожих запросах;
• понимает ли команда, как откатить версию за один шаг и по каким метрикам считать ухудшение.

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

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

Откат должен быть скучным и быстрым. Кто переключает версию, где лежит прошлый артефакт, какой набор тестов запускается повторно и какой порог ошибки считается стоп-сигналом. Если на эти вопросы нет короткого ответа, выпускать модель рано.

Что делать дальше

Закрывать вопрос лучше не мнениями, а одним и тем же набором тестов. Если вы одновременно меняете базовую модель, датасет и способ обучения, выводы почти всегда будут шумными.

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

Дальше можно идти по простой схеме.

1. Возьмите базовую модель, которая уже неплохо понимает русский и вашу задачу без обучения.
2. Соберите короткий, но строгий eval: 100-300 примеров с реальными сценариями, где видны смысл, формат и стиль.
3. Прогоните LoRA на одном датасете и сравните не только качество по смыслу, но и дисциплину ответа: держит ли модель шаблон, порядок полей и длину.
4. Если LoRA закрывает требования, не усложняйте проект полным fine-tune.
5. Если она регулярно срывает стиль, шаблон или обязательные поля, переход к полному fine-tune уже выглядит не как теория, а как следующий шаг, подтвержденный данными.

Для команд в РФ есть еще практический момент: удобно сравнивать несколько моделей в одном и том же контуре, не переписывая интеграцию. В RU LLM для этого можно оставить те же SDK, код и промпты, поменяв только base_url на единый OpenAI-совместимый endpoint, а логи и бэкапы при этом остаются внутри РФ. Это упрощает именно сравнение и контроль, а не только первый запуск.

Если свести все к одному правилу, оно простое. LoRA выбирают там, где нужно подтянуть словарь, короткий формат и типовые ответы. Полный fine-tune имеет смысл там, где модель обязана держать форму, стиль и согласованность ответа даже на длинных и шумных сценариях. Решать это лучше не по ощущениям, а по серии одинаковых тестов на своей русской задаче.