Решён
Можно ли смешивать обученные модели нейросети?

Алексей Кузнецов • Машинное обучение •
2.8k
7

Занимаюсь файнтюнингом LLM на своих данных. Обучил две LoRA-адаптера для одной базовой модели (Mistral 7B):

  • Первый адаптер натренирован на корпусе юридических документов, отвечает на вопросы по праву
  • Второй натренирован на медицинских текстах, работает как медицинский ассистент

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

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

Интересует:

  1. Теоретически это вообще корректная операция?
  2. Если да, какой метод дает лучшие результаты (merge, ensemble, что то еще)?
  3. Может правильнее держать модели раздельно и роутить запросы?
UPDATE: Попробовал TIES-merging как советовали ниже. Результат заметно лучше чем простое сложение весов. Юр. бенчмарк упал на 8% вместо 30%, мед. на 5%. Для моих задач приемлемо. Спасибо всем!
Fine-tuningLLMLoRAMistralModel mergingPEFTНейросети

7 ответов

Лучшие Новые Старые
Решение
47
Эксперт • 5 ответов

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

Методы, которые работают лучше:

1. TIES-Merging (Trim, Elect Sign & Merge)
Статья: "Resolving Interference When Merging Models" (Yadav et al., 2023). Суть: перед объединением весов алгоритм обрезает малозначимые дельты, разрешает конфликты знаков и только потом мержит. На практике дает гораздо меньшую деградацию.

В mergekit это делается так:

models:
  - model: base_model
    parameters:
      weight: 1.0
  - model: base_model+lora_legal
    parameters:
      weight: 0.5
      density: 0.5
  - model: base_model+lora_medical
    parameters:
      weight: 0.5
      density: 0.5
merge_method: ties
dtype: float16

2. DARE (Drop And REscale)
Статья: "Language Models are Super Mario" (Yu et al., 2023). Случайно зануляет часть дельт перед мержем, уменьшая интерференцию. Комбинируется с TIES.

3. Task Arithmetic
Считаешь task vector для каждого адаптера (веса_после_FT - веса_базы), масштабируешь коэффициентом 0.3-0.7 и складываешь. Грубее чем TIES, но иногда достаточно.

4. Роутинг (Mixture of Experts / MoE-style)
Держишь оба LoRA раздельно. Классификатор на входе определяет домен запроса и подключает нужный адаптер. Нулевая интерференция, но сложнее в инфре.

Мое мнение: если домены сильно разные (право и медицина - очень разные), роутинг надежнее. Мерж хорош когда домены близкие или задачи дополняющие (например, суммаризация + перевод).

Попробуй TIES через mergekit, поиграй с density и weight. Если деградация больше 10-15% по твоим бенчмаркам, иди в роутинг.

Аватар Алексей Кузнецов
Алексей Кузнецов Автор

Про TIES не знал, спасибо. Поставил mergekit, буду экспериментировать с density. Отпишусь по результатам.

22
Участник • 3 ответа

TL;DR: Смешивать можно, но не в лоб. Используй TIES-merging или роутинг.

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

Минимально рабочий подход: загружай оба LoRA через PeftModel с разными adapter_name, и переключайся между ними через model.set_adapter("legal") / model.set_adapter("medical") в зависимости от запроса. Роутинг можно сделать даже простым классификатором на TF-IDF.

15
Эксперт • 4 ответа

Зачем мержить две LoRA, если можно обучить одну на объединенном датасете? Берешь юр. корпус + мед. корпус, размечаешь системными промптами ("Ты юрист" / "Ты врач"), и делаешь один файнтюн. Модель сама научится переключаться по системному промпту.

Да, нужно больше VRAM и дольше обучать. Но результат стабильнее любого мержа.

Аватар Алексей Кузнецов
Алексей Кузнецов Автор

Рассматривал этот вариант, но у меня данные добавляются инкрементально. Сегодня юр. корпус, завтра мед., послезавтра еще финансовый. Каждый раз переобучать с нуля на объединенном датасете дорого.

31
Участник • 3 ответа

Работаю в компании которая делает вертикальные LLM-продукты. Мы перепробовали все виды мержа на Llama-2 и Mistral. Вот наш опыт:

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

В проде мы остановились на роутинге. Простой BERT-классификатор на входе определяет домен за 5мс, и подключает нужный LoRA через PEFT. Latency увеличивается на копейки, зато качество каждого домена 100% от соло-адаптера.

Мержить имеет смысл только для демок и прототипов. Для прода - роутинг.

0
Участник • 2 ответа

а чо сразу не взять GPT-4 через API? зачем городить этот зоопарк из лор, мержей и роутеров? серьезно. время разработчика тоже денег стоит. пока ты месяц ковыряешься с TIES-мержем, можно за 50 баксов в месяц API дергать и не париться

я понимаю что "свое, приватное, на своем железе", но если данные не военная тайна, то зачем

18
Участник • 1 ответ

Если тебе интересна теория за этим, почитай "Editing Models with Task Arithmetic" (Ilharco et al., 2023). Там вводится понятие task vector - разница между весами дообученной и базовой модели. Показано что эти вектора можно складывать, вычитать и масштабировать, и результат осмысленный.

Но авторы работали с CLIP и полным файнтюном, не с LoRA. С LoRA ситуация сложнее, потому что low-rank аппроксимация теряет информацию, и при сложении двух низкоранговых матриц результат не эквивалентен сложению полных дельт.

Математически: если A = BC и D = EF (две LoRA декомпозиции ранга r), то A+D != (B+E)*(C+F). Ранг суммы может быть до 2r, и простое сложение теряет компоненты. TIES и DARE решают это частично через спарсификацию, но не полностью.

0
Участник • 3 ответа

нашел через гугл, у меня похожая задача только на llama 3.1 8b. кто нибудь пробовал mergekit с llama 3? ties работает или надо что то другое?

Написать ответ

Визуальный редактор (WYSIWYG)
Премодерация гостей

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

Или войдите в систему
Будьте вежливы и соблюдайте правила платформы.