5 случаев, когда Fine-tuning лучше RAG
Все говорят "RAG для всего". Но есть кейсы, где fine-tuning выигрывает — и это не только про статичные данные.
1. Жёсткий формат вывода
Бот для CRM должен всегда возвращать:
{"name": "...", "phone": "...", "intent": "..."}
RAG не гарантирует формат. Fine-tuning — да. Модель "запоминает" структуру на уровне весов.
2. Доменный жаргон
Врач пишет: "в/в капельно NaCl 0.9% 400мл". Юрист: "п.1 ч.2 ст.158 УК".
RAG найдёт документ, но не научит модель "говорить на языке". Fine-tuning встраивает терминологию в модель.
3. Логика без документов
Расчёт стоимости доставки: вес, габариты, зоны, сезонность, тип клиента — 20 переменных.
Это не в документе, это в голове логиста. Fine-tuning переносит экспертизу в модель.
4. Стиль эскалации
Банковский бот не должен говорить "не знаю". Только: "Уточню у специалиста, ожидайте".
RAG учит контенту, fine-tuning — поведению и тону.
5. Скорость
RAG: эмбеддинг → поиск → генерация = 3 вызова, ~2 сек.
Fine-tuned модель: 1 вызов, ~0.5 сек.
Для голосового бота или real-time чата — критично.
Когда всё же RAG: данные часто меняются, нужны ссылки на источник, конфиденциальность.
Гибрид работает: fine-tuning для формата и стиля + RAG для актуальных данных.
А вы где использовали fine-tuning?
с априорным распределением 
найдите вид апостериорного распределения p(w∣X,Y), выведите формулы для его параметров и покажите, как его максимум (MAP-оценка) связан с ridge-регрессией с коэффициентом регуляризации 
/
