HR Assistant — LoRA Fine-Tuning
Практическая реализация LoRA-дообучения Qwen2.5 для matching-модели HR-ассистента. Четыре эксперимента показали, что инженерия датасета важнее тюнинга адаптера.
Валидный JSON ещё не значит правильный ответ
Базовая модель выдавала корректный JSON, но принимала плохие matching-решения. Формат выучен; смысл — нет.
- Формат ≠ смысл. Модель быстро выучила JSON-шаблон, но не логику matching-решений.
- Loss — не целевая метрика. Validation loss не предсказывал качество бизнес-решений.
- Нужен контролируемый датасет. Teacher labels должны отражать реальные критерии matching.
Почему LoRA, а не облачный API
Локальный адаптер даёт контроль над данными и итеративность. Скорость и экономия — не начальные преимущества, а области для последующей работы.
- Быстрый inference
- Меньше инфраструктуры
- Данные уходят на внешний сервис
- Меньше контроля над поведением
- Данные не покидают инфраструктуру
- Контроль overfitting и гиперпараметров
- Быстрые итерации датасета (~3 мин)
- Inference требует оптимизации
Четыре эксперимента — цепочка открытий
Каждый эксперимент отвечал на вопрос, оставленный предыдущим. Гиперпараметры LoRA не менялись.
Эволюция метрик
Два независимых измерения качества: точность matching-решений и средняя абсолютная ошибка композитного score.
Точность решений
Точность matching-решений росла неравномерно: 44% → 78% → 67% → 80%. Падение на Exp 003 — осознанная жертва recall ради устойчивости к hard negatives.
Рис. 1. Decision accuracy: Base Qwen vs LoRA по четырём экспериментам.
Ошибка оценки
Средняя абсолютная ошибка композитного score снизилась с 38 до 15 баллов. Base model ошибался сильнее всех.
Рис. 2. MAE score: Base Qwen vs LoRA по четырём экспериментам. Меньше — лучше.
External validation
На 102 независимых парах кандидат–вакансия LoRA достигла 93.1% decision accuracy против 94.1% у GPT-4o-mini. Модель обобщается, но score калибруется не идеально.
Рис. 3. External validation scatter: LoRA score против reference score.
Telegram Production Smoke
Offline-метрики неэквивалентны production-качеству. Runtime smoke на реальном API выявил failure modes, которых не было в тестовой выборке.
Рис. 4. Production smoke matrix по категориям и экспериментам.
- Exp 002 провалил negative-кейсы на реальном API.
- Hard negatives в Exp 003 устранили это: smoke 7/7 passed.
- Truncation bug: при max_tokens=300 возникал HTTP 422. Фикс — max_tokens=512 + graceful JSON extraction.
Dataset Engineering
Рост качества шёл за счёт инженерии датасета, а не адаптера. На каждом шаге добавлялись примеры, которые устраняли конкретный дефект.
общий baseline
+ edge cases
устраняет false positives
+ borderlines
восстанавливает recall
- Гиперпараметры LoRA оставались неизменными на протяжении всех экспериментов.
- Единственная систематически меняющаяся переменная — состав и баланс teacher dataset.
- Hard negatives устранили false positives; positives и borderlines вернули recall.
Итоговые выводы
Четыре эксперимента и финальное Telegram-расследование привели к чёткому пониманию границ: что доказано, что частично доказано и что требует следующего цикла.
Доказано
Инженерия датасета важнее тюнинга адаптера. Hard negatives и positives/borderlines — рабочие рычаги качества. Технический контур и deployment воспроизводимы.
Частично доказано
93.1% decision accuracy на external holdout и 100% production smoke pass. Hard-negative качество в реальных сценариях требует дополнительной stratified evaluation.
Next cycle
Калибровка score, уменьшение latency, расширение teacher dataset и добавление hard-negative метрик в валидационный pipeline.