LoRA: как дообучить LLM на своих данных при ограниченном железе

Прямой ответ

LoRA (Low-Rank Adaptation) — метод дообучения, при котором исходные веса модели замораживаются, а обучаются только небольшие добавочные матрицы низкого ранга, встроенные в слои внимания. Вместо миллиардов параметров обучаются миллионы, поэтому дообучение модели 7B становится возможным на одной видеокарте потребительского класса.

Как это устроено:

1. Для выбранного слоя W добавляется разложение ΔW = B·A, где A и B — матрицы размеров r × d и d × r при малом ранге r (обычно 4–64).
2. При инференсе используется W + ΔW; адаптеры можно «влить» в веса или применять отдельно.
3. Одна базовая модель может обслуживать несколько адаптеров — это удобно для разных задач и клиентов.

QLoRA добавляет квантование базовой модели (обычно 4 бита) с обучением адаптеров в высокой точности, что снижает требования к видеопамяти ещё примерно вдвое — связь с квантованием описана в статье про квантование моделей.

Ключевые гиперпараметры:

• r (rank). Ёмкость адаптера. Малый ранг (8) — быстрее и устойчивее к переобучению; большой (64) — выразительнее, но требует больше данных.
• lora_alpha. Масштаб обновления; часто берут alpha = 2·r. Важен не абсолютный масштаб, а отношение alpha / r.
• lora_dropout. Регуляризация, обычно 0.05.
• Целевые модули. Обычно q_proj, k_proj, v_proj, o_proj; добавление MLP-слоёв увеличивает ёмкость и стоимость.

Когда LoRA оправдана, а когда нет:

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

Практика: подготовка данных и запуск

Формат датасета. Наиболее распространён формат «инструкция — вход — выход» в JSONL:

{"messages": [
  {"role": "system", "content": "Ты ассистент поддержки. Отвечай по шаблону компании."},
  {"role": "user", "content": "Клиент просит вернуть товар через 40 дней. Что ответить?"},
  {"role": "assistant", "content": "1. Срок возврата — 30 дней... 2. Предложите обмен..."}
]}

Требования к данным, которые важнее гиперпараметров:

1. Качество сильнее объёма. 300 выверенных примеров обычно полезнее 5000 шумных.
2. Однородность стиля. Если ответы в датасете написаны по-разному, модель усреднит стиль и потеряет точность формата.
3. Покрытие граничных случаев. Отказы, неполные данные, запросы вне компетенции — модель должна уметь отвечать «не знаю» так, как вы ожидаете.
4. Отдельный тестовый набор. Он не участвует в обучении и служит для оценки — методика в статье про eval для LLM.

Проверка окружения перед запуском:

nvidia-smi --query-gpu=name,memory.total,memory.used,driver_version --format=csv
python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Расхождения драйверов и версий CUDA — частая причина падений; разбор — в статье про PyTorch, CUDA и VRAM.

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

Практический сценарий: после дообучения модель стала отвечать хуже

Контекст: дообучали модель 7B на 1200 примерах внутренних ответов поддержки; формат соблюдается, но ответы стали шаблонными и потеряли аккуратность в деталях.

1. Диагностика. Сравниваем базовую модель и адаптер на тестовом наборе из 60 запросов: адаптер выигрывает по формату, но в 11 случаях даёт устаревшие условия возврата, которые были в обучающих примерах.
2. Причина. В датасете были примеры со старой версией политики, плюс 3 эпохи обучения на небольшом наборе привели к запоминанию формулировок.
3. Исправление. (а) Чистим датасет: единая актуальная версия политики, удаляем противоречивые примеры; (б) снижаем число эпох до 1–2 и ранг до 8; (в) фактические условия выносим из модели в промпт/поиск, чтобы их можно было обновлять без переобучения.
4. Проверка. После переобучения расхождений по политике нет, формат сохраняется; фиксируем тестовый набор как регрессионный.
5. Профилактика. Вносим правило: датасет для дообучения проходит ревью так же, как код; каждый новый адаптер сопровождается прогоном тестового набора.

Вывод: LoRA эффективно переносит навык и формат, но плохо подходит для хранения фактов. Ошибки в данных после дообучения становятся частью модели и видны во всех ответах.

FAQ

Можно ли дообучить модель на ноутбуке? Для моделей 1.5–3B с QLoRA — да, при 16–24 ГБ памяти и терпении к длительности. Для 7B и выше нужен GPU с 24 ГБ и более либо аренда. Перед стартом проверьте, сколько памяти реально доступно, и уменьшите размер батча с градиентным накоплением.

Как применять обученный адаптер в инференсе? Два варианта: слить адаптер с базовыми весами и получить обычную модель (удобно для квантования в GGUF), либо загружать адаптер поверх базовой модели в рантайме (удобно для нескольких адаптеров на одной базе).

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

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

Источники: LoRA paper, PEFT docs (Hugging Face), QLoRA paper — ссылки в шапке.