Сколько видеокарт вы прямо сейчас греете впустую, пытаясь заставить монструозную 70B-модель выучить корпоративный сленг через системный промпт?
Скорее всего, ответ вам не понравится. Индустрия одержима гигантизмом. Кажется, что если взять самую тяжелую сеть, впихнуть в нее мегабайт контекста и приправить это многоэтажным промптом, она решит любую задачу. На деле она начинает галлюцинировать, путать спецификации и сжигать бюджет на инференс с каждым запросом. Дообучить свою LLM за разумные деньги: когда LoRA дешевле и точнее гигантской модели — это не фантастика, а суровая инженерная необходимость для тех, кто гоняет ИИ в закрытых контурах на реальном железе.
Промптинг, RAG или файнтюнинг: где проходит граница
Промптинг дешев на старте, но катастрофически дорог в проде. Каждый токен контекста стоит денег и, что критичнее, миллисекунд. Когда вы пихаете в промпт глоссарий на десять тысяч слов и десяток примеров (few-shot), latency улетает в космос. Модель начинает захлебываться в собственных attention-матрицах.
RAG (Retrieval-Augmented Generation) спасает, если нужно искать факты по базе знаний. Взяли векторную БД, прикрутили гибридный поиск, вытащили релевантные чанки, отдали LLM. Но RAG не меняет поведение модели. Он дает только фактуру.
Если сеть должна писать код в специфическом внутреннем фреймворке, парсить логи проприетарного формата или выдавать жесткий JSON без единого лишнего слова — RAG здесь бессилен. Он не заставит Llama 3 заговорить на языке инженеров конкретного завода. Модель тупо забудет системную инструкцию к середине генерации.
Тут на сцену выходит файнтюнинг. Изменение самих весов.
Магия адаптеров: почему LoRA ломает экономику гигантов
Полный файнтюн (Full Fine-Tuning) — это боль. Обновлять все веса условной Llama-3-8B целиком означает арендовать кластеры A100/H100, жонглировать терабайтами VRAM через FSDP (Fully Sharded Data Parallel) и рисковать сломать модель из-за микроскопической ошибки в learning rate.
LoRA (Low-Rank Adaptation) делает нас умнее. Мы намертво замораживаем оригинальные многомиллиардные веса модели. Рядом с линейными слоями трансформера вставляем маленькие матрицы-адаптеры низкого ранга. Обучаем только их. При инференсе просто математически складываем базовые веса с весами адаптера.
Разница в количестве обучаемых параметров колоссальная.
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM
config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM"
)
model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B")
peft_model = get_peft_model(model, config)
peft_model.print_trainable_parameters()
# Вывод: trainable params: 13,631,488 || all params: 8,043,892,736 || trainable%: 0.1694
Меньше 0.2% параметров. Вот ваша цена за дообучение.
Это в сотни раз дешевле. С подходом QLoRA (квантование базовой модели до 4 бит) зафайнтюнить 8B-сеть можно на одной серверной L4 или даже десктопной RTX 4090. В проде маленькая дообученная модель с правильным LoRA-адаптером рвет базовую 70B-модель на узких задачах в щепки. По точности — паритет или чистая победа малыша. По скорости — превосходство на порядок. На edge-железе без выхода в интернет это просто единственный рабочий вариант. Тяжелую сеть вы туда физически не впихнете.
Теперь о реальности. Все думают, что проблема файнтюнинга кроется в железе или гиперпараметрах. Ошибка. Проблема в данных.
Скармливать сети сырые дампы из вашей Jira — прямой путь к катастрофе. Garbage in, garbage out. Модель не станет умнее. Она научится генерировать токсичные комментарии в стиле ваших мидлов и плодить баги в коде. Для качественного файнтюна не нужны миллионы строк. Нужно от 500 до 3000 идеальных примеров (пар запрос-ответ). Форматирование должно быть вылизано. Если в тренировочном сете есть лишние пробелы — модель будет генерировать лишние пробелы в проде.
Здесь же кроется главный риск — catastrophic forgetting (катастрофическое забывание). Сеть переобучается на узкую задачу и теряет базовые навыки рассуждения. Вчера она была универсальным помощником, а сегодня умеет только парсить конкретный тип логов, да и то с галлюцинациями. Лечится это только подмешиванием общеинтеллектуальных датасетов. Добавляете к вашим специфическим логам 10-20% качественных инструкций общего назначения, чтобы веса не деградировали.
Критерии: когда вам реально нужен файнтюн
Не тащите LoRA везде. Это инструмент для специфических сценариев. Когда нужно бить снайперски, а не накрывать площадь артобстрелом.
- Строгий формат вывода. Модель должна выдавать жестко структурированный YAML/JSON для автоматического парсинга, где малейшая вольность ломает пайплайн. Промптинг дает сбои в p99. LoRA сводит ошибки формата к нулю.
- Специфический язык или Tone of Voice. Проприетарные языки разметки, внутренние библиотеки, не представленные в публичном доступе, или жесткие требования к стилю общения B2B-саппорта.
- Edge-инференс и лимиты по VRAM. Сервер в закрытом контуре. 16 или 24 гигабайта VRAM. В облако нельзя. В этих условиях дообученная 8B-модель — абсолютный король.
- Отказ от облаков по соображениям безопасности. Данные не должны покидать периметр предприятия ни при каких условиях. Гонять локально гигантскую универсальную LLM — экономическое самоубийство, а специализированный файнтюн укладывается в бюджет на железо.
Если задача решается через RAG с нормальным эмбеддингом и реранкером — делайте RAG. Оставьте веса в покое. Собирать датасет для файнтюна только ради фактологии — выстрел в ногу, завтра ваши факты изменятся.
Но когда контекст раздувается, а latency бьет по рукам, выжимать корпоративный сленг из 70-миллиардного монстра системным промптом — дилетантство. Замораживайте веса. Обучайте адаптер. Сжимайте экспертизу в миллионы параметров.