1. Fine-tuning вместо RAG
Если задача — отвечать по документам, ценам, политикам, FAQ или базе знаний, fine-tuning плохо подходит как основной механизм. Документы меняются, модель может забывать или искажать факты, источники не видны.
2. Нет baseline
Без сравнения с обычной моделью и хорошим промптом вы не знаете, дал ли fine-tuning пользу.
3. Train и test перемешались
Если одинаковые примеры попали и в обучение, и в тест, метрика будет завышена. Проверяйте дубликаты до split и после split.
4. Слишком маленький или однообразный датасет
Модель может запомнить шаблон и плохо работать на реальных формулировках. Добавляйте разнообразие входов, edge cases и негативные примеры.
5. Противоречивые ответы
Если один и тот же тип вопроса размечен по-разному, модель учится хаосу. Нужен единый annotation guideline.
6. Хардкод токенов
Токены Hugging Face, OpenAI, Gemini и других сервисов нельзя хранить в коде. Используйте переменные окружения и не коммитьте .env.
7. Игнорирование privacy
Fine-tuning на персональных данных может привести к утечкам, регуляторным проблемам и невозможности безопасно поделиться моделью. Удаляйте PII и проверяйте лицензию данных.
8. Нет safety-кейсов
Обычные метрики не показывают, как модель ведёт себя на вредных, манипулятивных или high-stakes запросах. Нужен отдельный набор safety-тестов.
9. Нет мониторинга после деплоя
Качество модели меняется вместе с пользователями, данными и зависимостями. Логи, alerts, evals и rollback нужны так же, как для обычного backend.
10. Ожидать, что fine-tuning решит всё
Fine-tuning не заменяет хороший UX, права доступа, базу данных, RAG, валидацию, тесты и продуктовые ограничения. Это один инструмент в архитектуре.