Fine-tuning LLM или RAG: как выбрать подход и не потратить бюджет зря

Fine-tuning - не загрузка базы знаний в модель

В fine-tuning базовая модель дополнительно обучается на примерах входа и желаемого ответа, чтобы чаще воспроизводить нужное поведение. Это отличается от RAG, где актуальные документы извлекаются во время запроса и передаются как контекст.

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

Сначала диагностируйте тип ошибки

Матрица: prompt engineering, RAG, tools и fine-tuning

Подходы не взаимоисключающие. Tuned model может использовать RAG и tools, но каждый слой должен давать измеримую пользу.

Дерево решения: нужен ли fine-tuning

Когда fine-tuning чаще всего оправдан

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

Когда fine-tuning лучше отложить

• Требования к результату ещё меняются каждую неделю.
• Нет размеченного eval-набора и владельца качества.
• Основная проблема - отсутствие свежих документов.
• Ошибки вызваны плохим OCR, retrieval или tool API.
• Есть несколько десятков противоречивых примеров.
• Данные нельзя законно или договорно использовать для обучения.
• Base model скоро выводится из эксплуатации.
• Сценарий низкочастотный и не окупает обслуживание.
• Ожидается гарантированная истинность всех фактов.

Обучение может закрепить ошибки датасета и скрыть неопределённость за более уверенным стилем.

Baseline до обучения: дайте простой системе честный шанс

Выберите подходящую стабильную base model, сформулируйте контракт, добавьте few-shot examples и structured output. Для знаний подключите минимальный RAG. Измерьте качество, latency, токены, ручные исправления и стоимость успешной задачи.

Сценарий: [название]
Success criteria: [метрики]
Critical errors: [список]
Base model/version: [ID]
Prompt/schema/retrieval versions: [ID]
Eval dataset/version: [ID]
Quality by cohort: [данные]
P50/P95 latency: [данные]
Cost per successful task: [данные]
Top failure clusters: [список]
Гипотеза tuning: какой именно failure cluster должен уменьшиться и почему?

Данные для обучения: качество важнее случайного объёма

Training example показывает не только ответ, но и скрытую policy разметчика. Противоречивые примеры учат нестабильности. Создайте annotation guide с критериями, допустимым отказом и обработкой неоднозначности.

Train, validation и test: разделите до экспериментов

Test set используется для итогового сравнения и не должен направлять каждую правку. Validation помогает выбирать конфигурацию. Train используется для обучения. Разделение делайте так, чтобы почти одинаковые записи одного клиента, документа или цепочки не оказались в разных частях.

Data leakage и дубли: почему метрика может обмануть

Если шаблон того же документа встречается в train и test, результат завышен. Точные дубли легко найти hash, смысловые - embeddings или domain keys. Группируйте split по источнику, клиенту, времени или сущности.

• Удалите exact и near duplicates.
• Исключите ответы, скопированные из test benchmark.
• Проверьте, не содержит prompt правильную метку.
• Сделайте temporal holdout для меняющихся процессов.
• Храните immutable manifest split.
• Не выбирайте «лучший» test subset после результатов.

Права, персональные данные и memorization risk

Данные, допустимые для обычной обработки, не обязательно разрешено использовать для обучения. Проверьте purpose, договоры, лицензии, retention и механизм удаления. Минимизируйте персональные и секретные значения.

Разметка: инструкция для людей - часть модели

Если два эксперта не согласны, модель не узнает единственную правильную policy. Проведите пилот разметки, измерьте agreement по важным классам, обсудите конфликты и обновите guide.

Annotation guide для [задача]:
- цель и нецели;
- единица разметки;
- закрытая taxonomy и определения;
- обязательные свойства ответа;
- допустимый отказ;
- порядок при нескольких подходящих классах;
- примеры positive, negative и boundary;
- правила для неполных данных;
- запрещённые предположения;
- escalation к эксперту;
- журнал спорных решений и версия guide.

Supervised fine-tuning: что именно он оптимизирует

Supervised fine-tuning учит модель воспроизводить целевые ответы из примеров. Google Cloud описывает SFT как способ обучить задаче на размеченных примерах; конкретные минимумы, форматы и поддерживаемые модели зависят от платформы.

Не переносите команды из старого tutorial: APIs и доступность меняются. Например, актуальная документация Gemini API сообщает, что после прекращения поддержки последней tuning-модели fine-tuning там сейчас недоступен, но он поддерживается в отдельной корпоративной платформе Google. Проверяйте текущую страницу выбранного сервиса.

Не обучайте все проблемы одновременно

Первый эксперимент должен проверять одну гипотезу: например, снизить путаницу двух классов или сократить prompt без падения качества. Если одновременно изменить dataset, base model, prompt, retrieval и schema, результат невозможно объяснить.

Evals: средний балл не должен скрывать критическую ошибку

Сравнивайте baseline и tuned candidate на неизменном test set. Автоматические validators проверяют schema и инварианты; domain graders - факты и классы; эксперты - сложные случаи. Критические ошибки имеют отдельный hard limit.

Экономика fine-tuning: считать нужно весь lifecycle

Стоимость включает подготовку и review данных, training jobs, эксперименты, inference tuned model, хранение, evals, monitoring и повторное обучение после дрейфа или смены base model. Экономия возможна, если tuned model уменьшает prompt или позволяет использовать более компактный base, но это нужно доказать.

TCO периода =
data collection + labeling + review +
training/experiments + evaluation +
inference of all attempts +
monitoring + incidents + retraining +
migration/deprecation work

Cost per successful task =
TCO периода / число результатов, прошедших acceptance criteria

Актуальные цены tuning и inference проверяйте у провайдера перед бюджетированием.

RAG и fine-tuning вместе

Комбинация оправдана, когда tuned model стабильно следует доменному контракту, а RAG поставляет свежие факты. Разделяйте ответственность: модель не должна «вспоминать» цену, если она обязана цитировать текущий каталог.

Production rollout: alias, shadow, canary и rollback

Tuned model получает immutable ID и manifest: base model, dataset hash, training config, prompt/schema compatibility и eval report. Приложение использует alias, который можно быстро вернуть на baseline.

1. Offline eval и security review.
2. Shadow на разрешённой выборке без side effects.
3. Canary по стабильному cohort.
4. Сравнение quality, cost, latency и handoff.
5. Постепенное расширение при прохождении gates.
6. Rollback при critical error или нарушении SLO.
7. Observation window после 100%.

Fallback на base model также тестируют: у неё может быть другой prompt и response contract.

Monitoring и дрейф после запуска

Production-распределение меняется: появляются новые продукты, языки и типы обращений. Следите за входными cohorts, label distribution, error taxonomy, abstain, ручными исправлениями и стоимостью.

Итоговый чек-лист перед обучением

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