Файнтюнинг в 2026 году: когда LoRA выигрывает у RAG и как обойтись без кластера

Годами файнтюнинг был той AI-возможностью, до которой большинству команд было не дотянуться. Нужны были GPU-кластеры, ML-инженеры, недели работы. Для прикладных команд экономика почти никогда не сходилась.

В 2026 году это уже не так. LoRA, QLoRA и managed-сервисы файнтюнинга сделали инженерную часть посильной для любой команды с разумным инженерным потенциалом. Полноценный LoRA-файнтюн можно запустить на одной потребительской GPU. Это же можно сделать через хостинговый сервис менее чем за €100 в вычислениях. За две недели сфокусированной работы реально получить продакшен-готовую дообученную модель.

Это меняет расклад. Кейсы, в которых файнтюнинг не имел смысла в 2024 году (слишком дорого, слишком сложно), часто имеют смысл в 2026. А кейсы, в которых команды по умолчанию выбирают RAG, иногда стоило бы решать через файнтюнинг.

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

Когда файнтюнинг выигрывает

Мы кратко касались этого в предыдущей статье; здесь — развёрнутая версия.

1. Согласованность формата и структуры

Если вам нужен вывод в очень специфическом формате — и стабильно, — файнтюнинг побеждает промптинг.

Пример: каждый ответ должен быть ровно 5 пунктами, каждый начинается с глагола, выдержан в определённом тоне. Промптингом можно дойти до 95%. Файнтюнингом — до 99% и выше.

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

2. Согласованность стиля и голоса

Компании со строгими гайдлайнами по голосу часто обнаруживают, что одним промптингом получается дрейф. На тысячах взаимодействий голос съезжает.

Файнтюнинг на 1000+ примерах «вот как звучим мы» даёт модель, которая голос усваивает. Голос согласован, потому что он зашит в модель, а не висит инструкцией в промпте, о которой модель должна помнить.

3. Специализированный домен или DSL

Если в вашем домене непривычная терминология, собственный DSL или специфические паттерны, которые базовая модель плохо знает:

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

Файнтюнинг на 5000 примерах корректного кода в этом DSL даёт модель, которая пишет на нём свободно. Модель «знает» этот DSL так же, как знает Python.

4. Меньшая модель, сравнимое качество

Дообученная модель на 8B иногда может сравняться с универсальной моделью на 70B на конкретной задаче. Выгоды:

• Дешевле инференс (в 10–50 раз).
• Быстрее инференс (в 3–10 раз).
• Можно держать у себя на скромном железе.
• Более предсказуемое поведение на узкой задаче.

При больших объёмах в узких сценариях это даёт существенную экономию.

5. Поведенческая безопасность

Дообучить модель стабильно отказывать в определённых вещах или встраивать конкретные предохранители часто надёжнее, чем строить защиту через промпт.

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

6. Few-shot-паттерны в масштабе

Если вы ловите себя на том, что подкладываете 10-shot-примеры в каждый промпт, и эти примеры съедают заметную часть бюджета токенов, — файнтюнинг эффективнее. «Примеры» запекаются в модель; промпт становится коротким.

Это особенно актуально для сценариев с большим объёмом запросов, где токены промпта суммируются в серьёзные деньги.

Когда файнтюнинг проигрывает

Не менее важно — когда файнтюнить не нужно.

1. Знания, которые меняются

Дообученные модели — это снимки во времени. Новая информация требует переобучения. Для динамических знаний (текущие события, данные по конкретному аккаунту, последние политики) с этим справляется RAG; файнтюнинг — нет.

Если ваш «нам нужен файнтюнинг» звучит как «модель должна знать о нашем продукте» — это ошибка. Правильный инструмент — RAG.

2. У вас недостаточно данных

Эффективный файнтюнинг требует значимого объёма обучающих данных. Минимум варьируется:

• LoRA на узкую задачу: 500–1000 примеров.
• LoRA на умеренную сложность: 1000–5000.
• Более общее поведение: 5000+.

Меньше 500 примеров — осмысленный файнтюнинг обычно не получится. Few-shot-промптинг или RAG чаще работают лучше.

3. Базовая модель развивается быстрее, чем вы успеваете

Фронтирные модели идут вперёд быстро. Файнтюн годовой давности часто проигрывает текущей фронтирной модели без всякого дообучения. Поддерживать файнтюн против движущейся базы — отдельная беговая дорожка.

Если у вас нет внятного плана сопровождения, файнтюнинг превращается в технический долг.

4. Вы не дожали промптинг и RAG

Удивительно частый паттерн: команды прыгают в файнтюнинг, не попробовав всерьёз промптинг или RAG. Файнтюн доехал; качество нормальное; но неделя итераций по промпту дала бы тот же результат за 1% от стоимости.

Сначала всерьёз попробуйте промптинг и RAG. Потом файнтюнинг.

5. У вас нет evals

Файнтюнинг без evals — это азартная игра. Вы не сможете сказать, помог ли файнтюн, навредил или ничего не изменил. Многие «успешные» файнтюны — это плацебо-победы или вообще регрессии.

Сначала постройте evals. Потом файнтюньте.

Ландшафт файнтюнинга в 2026

Краткая карта.

Хостинговые сервисы

Самый простой путь. Загружаете данные, обучаете, получаете API-эндпоинт с файнтюном.

• OpenAI fine-tuning. Поддерживает GPT-4o, GPT-4o-mini и всё чаще модели поменьше. Надёжно, зрело.
• Anthropic fine-tuning. Поддерживает семейство Claude Haiku. Доступен через облачных партнёров (AWS Bedrock, Google Cloud).
• Google Vertex AI tuning. Поддерживает семейство Gemini.
• Together AI, Fireworks, Anyscale. Тюнят open-source-модели на своей инфраструктуре.
• Cohere. Тюнят модели Cohere.

Стоимость: обычно €10–200 за умеренный файнтюн (5K–50K примеров) плюс наценка на инференс по сравнению с базовой моделью.

Когда выбирать: большинству команд. Удобство перевешивает (умеренную) надбавку в цене.

Self-hosted-файнтюнинг

GPU, код и инфраструктура — на вас.

• Open-source-модели: Llama 4, Qwen 3, Mistral, DeepSeek, Phi, Gemma. Все выпущены с достаточно либеральными лицензиями под файнтюнинг.
• Инструменты: Hugging Face TRL, Axolotl, Unsloth, LLaMA-Factory. Все зрелые.
• Вычисления: для моделей средних размеров достаточно одной H100. Или арендуйте у RunPod, Lambda, Vast.ai, Modal по $1–3 в час.

Стоимость: €50–500 в вычислениях за типичный LoRA-файнтюн. Плюс ваше инженерное время.

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

Лёгкие варианты

Для совсем небольших файнтюнов:

• Unsloth на потребительской GPU. Дообучить небольшую модель (7B) на RTX 4090 за полдня.
• MLX на Apple Silicon. Дообучить небольшие модели на Mac Studio.
• LoRA в Google Colab. Бесплатно или Colab Pro за €10–50 в месяц.

Это работает для экспериментов, маленьких моделей и proof-of-concept-файнтюнов.

Практический рабочий процесс

Для команды, выкатывающей продакшен-файнтюн, процесс такой.

Шаг 1. Валидация необходимости (1–2 дня)

До любой работы с данными проверьте:

• Пробовали ли вы серьёзный промптинг хотя бы неделю?
• Пробовали ли RAG, если в задаче замешаны знания?
• Есть ли evals, которые показывают, что текущий подход недостаточен?
• Можете ли вы внятно сформулировать, что именно файнтюн должен делать лучше?

Если на всё это вы не отвечаете «да» — файнтюнить рано.

Шаг 2. Построить evals (1 неделя)

Без evals файнтюнинг — это казино.

• Соберите eval-набор (100–500 примеров), покрывающий целевое поведение.
• Определите метрики: как выглядит успех? Соответствие формату, попадание в голос, точность и так далее.
• Базовая линия: прогоните eval на базовой модели. Зафиксируйте текущий счёт.

Это понадобится, чтобы понять, помог ли файнтюн.

Шаг 3. Подготовка данных (1–3 недели)

Основная часть работы. Качество обучающих данных определяет качество файнтюна.

Источники:

• Существующие качественные результаты вашей команды.
• Курированные исторические взаимодействия с клиентами.
• Сгенерированные примеры (сильная модель + аккуратный промптинг).
• Данные конкретных клиентов (если уместно; уважайте разрешения и PII).

Формат:

Типичный формат для чат-файнтюнинга:

{
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

По одному примеру на строку в JSONL.

Объём:

• LoRA, узкая задача: 500–2000 примеров.
• LoRA, умеренная задача: 2000–10000.
• Общее поведение: 10000+.

Больше обычно лучше — до определённого предела. После ~50K примеров отдача падает.

Качество важнее количества.

500 качественных, согласованных примеров побеждают 5000 посредственных. Лучше потратить больше времени на курирование небольшого набора, чем накидать кучу средненького.

Разнообразие.

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

Данные по безопасности и отказам.

Включайте примеры уместных отказов. Иначе дообученные модели часто становятся более «послушными» (готовы сделать что угодно) — это регрессия по безопасности.

Разделение train/eval.

Откладывайте 5–10% на оценку. Никогда не учитесь на этой выборке; используйте только для измерения качества.

Шаг 4. Запустить обучение (от 1 дня до 1 недели)

Для хостинговых сервисов:

# OpenAI example. First upload the files; the API expects file IDs,
# not local paths, for training_file / validation_file.
train = client.files.create(file=open("training.jsonl", "rb"), purpose="fine-tune")
val   = client.files.create(file=open("validation.jsonl", "rb"), purpose="fine-tune")

client.fine_tuning.jobs.create(
    training_file=train.id,
    validation_file=val.id,
    model="gpt-4o-mini",
    hyperparameters={
        "n_epochs": 3,
        "batch_size": 8,
        "learning_rate_multiplier": 1.0,
    },
)

Дождитесь завершения. От часов до дней — зависит от размера датасета и загрузки сервиса.

Для self-hosted (с Axolotl):

base_model: meta-llama/Llama-3.1-8B
load_in_4bit: true

adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

datasets:
  - path: ./data/train.jsonl
    type: chat_template

num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100

output_dir: ./output

Запуск: accelerate launch -m axolotl.cli.train config.yaml

Часы обучения на одной GPU.

Гиперпараметры, которые имеют значение:

• Эпохи: обычно 1–5. Больше — риск переобучения. Следите за validation loss.
• Learning rate: 1e-5 — 5e-4 в зависимости от подхода. LoRA терпит более высокие значения, чем полный файнтюнинг.
• LoRA rank (r): 8–64. Выше — больше ёмкости, больше риска переобучения.
• Размер батча: настолько большой, насколько хватает памяти.

Для первых файнтюнов берите дефолты из известного рецепта. Оптимизируйте гиперпараметры только если у вас есть evals, которые ведут этот процесс.

Шаг 5. Оценить (3–5 дней)

Прогоните eval-набор на дообученной модели.

• Улучшился ли счёт относительно базы?
• На сколько?
• Просели ли где-то (общие способности, безопасность, крайние случаи)?

Частые паттерны:

• Сильное улучшение на целевой задаче, небольшая регрессия в остальном: приемлемо для узкого применения.
• Сильное улучшение на цели, серьёзная регрессия в остальном: переобучили. Уменьшите эпохи или LoRA rank.
• Маржинальное улучшение: данных мало или они посредственного качества. Итерируйтесь по данным, а не по гиперпараметрам.
• Никакого улучшения: что-то не так. Проверьте формат данных, логи обучения, методику оценки.

Шаг 6. Тестирование на продакшене (1–2 недели)

До полной выкатки проведите A/B-тест:

• 5–10% продакшен-трафика — на файнтюн.
• 90–95% — на базу.
• Сравнивайте метрики: оценки качества, обратная связь от пользователей, downstream-сигналы.

После 1–2 недель данных принимайте решение: полная выкатка, ещё итерации или откат.

Шаг 7. Развёртывание (1–2 дня)

Для хостинговых сервисов: просто переключиться на ID файнтюна. Тривиально.

Для self-hosted: поднять инференс-сервер (стандарт — vLLM). Загрузить LoRA-адаптер. Маршрутизировать трафик.

Шаг 8. Мониторинг (постоянно)

Файнтюн в продакшене. Следите за:

• Метриками качества (онлайн-evals, обратная связь от пользователей).
• Дрейфом во времени.
• Не догнала ли вас обновлённая базовая модель (регулярно переоценивайте против актуальной базы).

Шаг 9. Сопровождение (каждые 3–6 месяцев)

Файнтюн — это не «выкатил и забыл».

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

Частый паттерн: ежеквартальный цикл переобучения. Обновили данные, прогнали обучение, оценили, выкатили — если стало лучше.

Разобранный пример

Реальный кейс: файнтюнинг под голос клиентской поддержки.

Задача. У SaaS-компании сильный, дружелюбный, простой голос в коммуникациях поддержки. Промптинг к нему приближался, но непостоянно. Команда хотела надёжного попадания в голос во всех коммуникациях, где помогает AI.

Данные. 3500 исторических тикетов поддержки, где ответ был качественным (по оценке старших специалистов поддержки). Каждый прошёл курирование: убрали PII, привели к единому формату.

Подход. LoRA-файнтюн на Claude 3.5 Haiku через AWS Bedrock.

Гиперпараметры: rank=16, 3 эпохи, learning rate по умолчанию.

Стоимость: ~€80 в вычислениях плюс 2 недели инженерного времени (в основном подготовка данных).

Результат: согласованность голоса на отложенном eval-наборе выросла с 72% до 94% (судья — senior support manager). Видимые пользователям коммуникации «стали больше похожи на нас» по качественному отзыву.

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

ROI: команда оценивает прирост удовлетворённости клиентов по AI-обработанным тикетам в ~15%. Точно атрибутировать трудно, но согласованность голоса дала заметный апгрейд.

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

Типовые формы провала

Несколько паттернов.

Провал 1. Переобучение на маленьких данных. 500 примеров, 10 эпох. Модель запоминает обучающую выборку и проваливается на реальных входах. Лечение: больше данных или меньше эпох.

Провал 2. Катастрофическое забывание. Тяжёлое обучение на узких задачах деградирует общие способности. Модель становится хорошей в вашей штуке и хуже во всём остальном. Лечение: ниже learning rate, меньше эпох или добавить разнообразных нецелевых данных.

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

Провал 4. Недостаточное покрытие eval. Eval-набор лёгкий; продакшен сложный. Файнтюн показывает хорошие оценки; ломается на реальных пользователях. Лечение: включайте сложные случаи в evals.

Провал 5. Гиперпараметрический хаос. Подкручиваете гиперпараметры без методологии. То лучше, то хуже, ничему не учитесь. Лечение: меняйте по одному параметру, оценивайте, учитесь.

Провал 6. Сопровождение провисло. Файнтюн выкатили, команда переключилась, модель устарела. Через полгода обновления базы её обогнали. Лечение: запланируйте переобучения.

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

Провал 8. Тюнинг под неправильную метрику. Обучение толкает модель оптимизировать конкретную метрику, но реальная ценность для пользователя — про другое. Лечение: выбирайте метрики, которые согласуются с пользовательской ценностью, а не легко измеряемые прокси.

Конкретные рабочие рецепты

Несколько мнений в виде рецептов.

Рецепт 1. Строгий структурированный вывод

Цель. Надёжный JSON в заданной схеме.

Данные. 2000 примеров (вход, валидный JSON-вывод).

Рецепт. LoRA, rank=8, 3 эпохи на маленькой модели (8B). Комбинировать с constrained generation на инференсе.

Итог. Соответствие схеме 99% и выше, очень быстро.

Рецепт 2. Попадание в голос

Цель. Согласованный бренд-голос в клиентских коммуникациях.

Данные. 3000+ примеров (контекст промпта, in-voice-вывод). Курируется людьми, которые умеют оценивать попадание в голос.

Рецепт. LoRA, rank=16, 2–3 эпохи на средней модели (8–70B). Пониженный learning rate (1e-4) для стабильности.

Итог. Согласованность голоса, которой одними промптами не добиться.

Рецепт 3. Специализированный DSL или домен

Цель. Генерация кода в собственном DSL.

Данные. 5000–20000 примеров (описание, валидный код).

Рецепт. LoRA на код-специализированной модели (Code Llama, DeepSeek Coder), rank=32, 3–5 эпох. Под код часто нормально работает более высокий learning rate (2e-4).

Итог. Свободная генерация в DSL.

Рецепт 4. Меньшая модель, сравнимое качество

Цель. Заменить большую модель меньшей дообученной — ради стоимости/латентности.

Данные. 10K–50K примеров, сгенерированных большой моделью на реальных входах (синтетика).

Рецепт. LoRA на маленькой модели (8B), rank=16, 2–3 эпохи. Инференс на vLLM ради пропускной способности.

Итог. Снижение стоимости в 5–10 раз, сравнимое качество на узкой задаче.

Рецепт 5. Файнтюн под безопасность и отказы

Цель. Надёжный отказ в конкретных проблемных категориях.

Данные. 1000–3000 примеров (проблемный запрос, уместный отказ) плюс 1000+ примеров нормальных взаимодействий (чтобы модель не «перерефьюзила»).

Рецепт. LoRA, rank=8, 2 эпохи, низкий learning rate (5e-5) для тонких поведенческих сдвигов.

Итог. Надёжный отказ в целевых категориях при сохранении полезности на нормальных запросах.

Стратегический вопрос

Помимо механики, файнтюнинг — это стратегический выбор:

• Хотим ли мы вкладываться в эту способность вдолгую или будем использовать фронтирные модели для всего?
• Готовы ли мы поддерживать файнтюн неопределённо долго?
• Стоит ли прирост качества постоянной операционной сложности?

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

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

Итог

Файнтюнинг в 2026 году доступен так, как ещё недавно не был. LoRA, хостинговые сервисы и дешёвые вычисления означают: небольшая команда может выкатить продакшен-файнтюн за 2–4 недели, потратив на вычисления менее €500.

При этом для большинства задач формата «AI недостаточно хорош» файнтюнинг — всё ещё неправильный ответ. Сначала всерьёз надавите на промптинг. Попробуйте RAG. Поставьте evals. Только потом тянитесь к файнтюнингу — и только когда можете внятно сформулировать, какой именно разрыв он должен закрыть.

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

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