Разработка рекомендательной системы кандидатов для HR (AI-матчинг)

Реализация рекомендательной системы кандидатов для HR

HR-отдел обрабатывает 100 резюме в день вручную. Результат: 70% нерелевантны, лучшие кандидаты теряются в PDF-хаосе. Причина — keyword search не понимает контекста: кандидат со стеком Python+PyTorch пишет «искусственный интеллект», а рекрутер ищет «ML». Мы используем semantic matching эмбеддингами: время скрининга сокращается с 4 часов до 15 минут, точность совпадений растёт на 30%. Система рекомендаций кандидатов (HR-матчинг) на базе семантического матчинга резюме и fine-tuning решает эту проблему. Средняя экономия бюджета на рекрутинг составляет до 3 000 000 рублей в год, а стоимость закрытия одной вакансии снижается с 50 000 до 15 000 рублей.

Как semantic matching решает проблему нерелевантных откликов?

Семантический матчинг преобразует текст резюме и вакансии в векторные представления (embeddings) с помощью модели all-mpnet-base-v2. Затем вычисляется косинусная близость между векторами. Дополнительно учитываются навыки, опыт и зарплатные ожидания с весами 0.5/0.35/0.15. Такой подход даёт рост точности на 30% по сравнению с keyword search и сокращает время ручного просмотра на 80%. Recall@10 у semantic matching в 1.5 раза выше, чем у keyword search.

Какие проблемы решаем?

1. Matching по ключевым словам не работает для сложных вакансий. Разработчик со стеком Python+PyTorch пишет в резюме «искусственный интеллект», а не «ML». Semantic matching понимает синонимы и контекст.

2. Bias в алгоритмах. Если модель обучена на исторических наймах, она воспроизводит неосознанные предпочтения рекрутеров. Мы внедряем обязательный ethnic/age/gender audit после каждого цикла.

3. Неструктурированные данные. Резюме содержат произвольные поля, описание опыта разного объёма. Система нормализует их в единый векторный формат.

Как мы это делаем: стек и архитектура

Используем sentence-transformers (all-mpnet-base-v2) для генерации 768-мерных embeddings. Для вакансий и кандидатов строим композитный вектор из текста (summary + опыт + навыки + образование). Веса компонентов подбираются через grid search.

Ключевой приём: fine-tuning модели на корпусе HR-резюме и JD с контрастной функцией потерь. Это даёт прирост recall@10 на 12%.

from sentence_transformers import SentenceTransformer
import numpy as np
import pandas as pd
from anthropic import Anthropic

class HRRecommendationSystem:
    def __init__(self):
        self.encoder = SentenceTransformer('all-mpnet-base-v2')
        self.llm = Anthropic()
        self.candidate_index = {}
        self.job_index = {}

    def index_candidate(self, candidate_id: str, resume: dict):
        """Индексирование резюме"""
        # Структурированное текстовое представление
        resume_text = self._resume_to_text(resume)
        embedding = self.encoder.encode(resume_text, normalize_embeddings=True)

        self.candidate_index[candidate_id] = {
            'embedding': embedding,
            'skills': resume.get('skills', []),
            'experience_years': resume.get('total_experience_years', 0),
            'current_salary': resume.get('current_salary', 0),
            'location': resume.get('location', '')
        }

    def index_job(self, job_id: str, job_description: dict):
        """Индексирование вакансии"""
        jd_text = self._jd_to_text(job_description)
        embedding = self.encoder.encode(jd_text, normalize_embeddings=True)

        self.job_index[job_id] = {
            'embedding': embedding,
            'required_skills': job_description.get('required_skills', []),
            'min_experience': job_description.get('min_experience_years', 0),
            'salary_max': job_description.get('salary_max', 0),
            'location': job_description.get('location', '')
        }

    def _resume_to_text(self, resume: dict) -> str:
        """Конвертация резюме в текст для энкодинга"""
        parts = []
        if resume.get('summary'):
            parts.append(resume['summary'])
        if resume.get('skills'):
            parts.append("Skills: " + ", ".join(resume['skills']))
        for exp in resume.get('experience', [])[:3]:
            parts.append(f"{exp.get('title', '')} at {exp.get('company', '')}: {exp.get('description', '')[:200]}")
        for edu in resume.get('education', [])[:2]:
            parts.append(f"{edu.get('degree', '')} in {edu.get('field', '')} from {edu.get('institution', '')}")
        return ". ".join(parts)

    def _jd_to_text(self, jd: dict) -> str:
        """Конвертация JD в текст"""
        parts = [
            jd.get('title', ''),
            jd.get('description', '')[:500],
            "Requirements: " + ", ".join(jd.get('required_skills', [])),
            "Nice to have: " + ", ".join(jd.get('preferred_skills', []))
        ]
        return ". ".join(p for p in parts if p)

    def match_candidates_to_job(self, job_id: str,
                                  n: int = 20,
                                  hard_filters: dict = None) -> list[dict]:
        """Топ-N кандидатов для вакансии"""
        if job_id not in self.job_index:
            return []

        job = self.job_index[job_id]

        scored = []
        for cid, candidate in self.candidate_index.items():
            # Hard filters (compliance)
            if hard_filters:
                if (hard_filters.get('min_experience') and
                        candidate['experience_years'] < hard_filters['min_experience']):
                    continue
                if (hard_filters.get('location') and
                        candidate['location'] != hard_filters['location'] and
                        not hard_filters.get('remote_ok', False)):
                    continue

            # Semantic similarity
            semantic_score = float(
                np.dot(job['embedding'], candidate['embedding'])
            )

            # Skill match
            required = set(job['required_skills'])
            has = set(candidate['skills'])
            skill_match = len(required & has) / max(len(required), 1)

            # Salary fit
            salary_ok = (
                1.0 if job['salary_max'] == 0
                else min(1.0, job['salary_max'] / max(candidate['current_salary'] * 1.2, 1))
            )

            final_score = 0.5 * semantic_score + 0.35 * skill_match + 0.15 * salary_ok

            scored.append({
                'candidate_id': cid,
                'score': final_score,
                'semantic_score': semantic_score,
                'skill_match': skill_match,
                'skill_gap': list(required - has)
            })

        scored.sort(key=lambda x: x['score'], reverse=True)
        return scored[:n]

    def generate_match_explanation(self, job_id: str,
                                    candidate_id: str) -> str:
        """AI-объяснение совместимости"""
        job = self.job_index.get(job_id, {})
        candidate = self.candidate_index.get(candidate_id, {})

        required_skills = set(job.get('required_skills', []))
        candidate_skills = set(candidate.get('skills', []))

        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=200,
            messages=[{
                "role": "user",
                "content": f"""Explain candidate-job match for a recruiter.

Required skills: {', '.join(required_skills)}
Candidate has: {', '.join(candidate_skills)}
Experience years: {candidate.get('experience_years', 0)}
Missing skills: {', '.join(required_skills - candidate_skills) or 'None'}

Write 2-3 sentences: strengths, gaps, and overall recommendation (Strong Match/Potential Match/Weak Match)."""
            }]
        )
        return response.content[0].text

Почему fine-tuning обязателен для HR-моделей?

Без fine-tuning модель не понимает HR-сленг: «тимлид» VS «team lead», «зп» VS «salary». Адаптация на корпусе из 1000 размеченных пар повышает recall@10 на 12% и снижает количество ложных срабатываний. Мы используем contrastive loss — минимизируем расстояние между релевантными парами и максимизируем для нерелевантных. Дополнительно применяем RAG для генерации match explanation: модель обращается к векторной базе знаний для поиска похожих кейсов. Определение contrastive loss из официальной документации PyTorch.

Сравнение подходов: keyword search vs semantic matching

Семантический подход даёт рост точности на 30% и сокращает время ручного просмотра на 80%.

Метрики до и после fine-tuning

Fine-tuning на HR-данных даёт устойчивый прирост качества.

Что вы получаете

• Документация API и инструкция по интеграции с ATS.
• Доступ к демо-версии на ваших данных для тестирования.
• Обучение HR-специалистов работе с системой (2 часа онлайн).
• Поддержка на этапе пилота и гарантия устранения bias (disparate impact < 0.8).

Процесс работы

1. Аналитика: аудит текущих данных (резюме, JD), выявление bias-рисков.
2. Проектирование: выбор модели (BERT, RoBERTa), определение весов признаков.
3. Реализация: разработка pipeline индексации, REST API, LLM-объяснений.
4. Тестирование: A/B тест на исторических наймах, метрики recall@k, precision@k.
5. Деплой: интеграция с ATS, мониторинг дрейфа данных, retrain каждые 3 месяца.

Чек-лист типичных ошибок при внедрении

• Использование embedding модели без адаптации к HR-сленгу (fine-tuning обязателен).
• Игнорирование salary fit — кандидаты с завышенными ожиданиями уходят на этапе оффера.
• Отсутствие hard filters — нарушение compliance (зарплатный диапазон, локация).
• Слишком высокая веса semantic score — подавляет редкие hard skills.

Сроки и стоимость

Базовая версия (matching + hard filters) — от 2 недель. Полная система с fine-tuning, bias audit и ATS интеграцией — от 6 недель. Стоимость рассчитывается индивидуально после анализа ваших данных. Свяжитесь с нами для оценки проекта — пришлём коммерческое предложение за 1 день.

Мы реализовали 12+ HR-рекомендательных систем для компаний с 500+ сотрудниками. 5 лет на рынке AI-решений. Гарантируем отсутствие bias в модели и сертифицированный опыт работы с sentence-transformers. Подробнее о bias-аудите можно прочитать на Wikipedia. Наши инженеры — авторы open-source библиотек для NLP. Получите консультацию — расскажем, как ускорить ваш рекрутинг в 10 раз.

Закажите демо-доступ к системе на ваших данных — убедитесь в эффективности.

Разработка рекомендательных систем: от collaborative filtering до real-time serving

На одном проекте для e-commerce с каталогом 300k SKU мы подняли CTR с 1,8% до 4,4% — в 2,4 раза. Первый рывок дала коллаборативная фильтрация вместо «популярное за последние 7 дней», второй — добавление контентных признаков и re-ranking. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная. Ниже — инженерный опыт, который помог это сделать, и архитектуры, которые реально работают в продакшене.

Collaborative Filtering: матричная факторизация и нейронные подходы

Matrix Factorization — классика для implicit feedback (клики, просмотры, покупки без явного рейтинга). ALS (Alternating Least Squares) в библиотеке Implicit обрабатывает матрицы user×item с сотнями миллионов ненулевых значений за минуты на GPU. Latent factors 64–256, регуляризация λ=0.01–0.1 — стартовые параметры. Проблема cold start: для нового пользователя или товара нет истории — классический CF беспомощен, нужны контентные признаки или гибрид.

Neural Collaborative Filtering (NCF) заменяет скалярное произведение на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст, категория, время суток). Sequence-aware модели (SASRec, BERT4Rec) учитывают порядок взаимодействий — state-of-the-art для сессионных рекомендаций.

Как выбрать архитектуру рекомендательной системы?

Ответ зависит от данных, нагрузки и требований к холодному старту. Ниже — три основных подхода с критериями выбора.

Гибридная архитектура на 20–40% эффективнее чистого CF по покрытию long-tail — проверено на каталогах от 100k SKU.

Content-Based Filtering: когда истории взаимодействий мало

Content-based рекомендует на основе характеристик товаров, а не поведения других пользователей — решает cold start для новых items. Текстовые эмбеддинги через sentence-transformers (multilingual-e5-base, BGE-M3) → поиск похожих через FAISS IndexFlatIP — запрос за <5 ms на 100k товаров. Item2Vec (Word2Vec на последовательностях просмотров) даёт интерпретируемые «похожие товары» за пару часов обучения.

Структурированные признаки (категория, бренд, цена) подаются через embedding layers или в gradient boosting — CatBoost работает с категориями без ручного кодирования.

Почему гибридные модели работают лучше?

Production-системы почти всегда двухуровневые. Stage 1 (Retrieval) — быстрый отбор 100–500 кандидатов из 300k товаров через ALS или Two-Tower модель с векторным поиском (FAISS, Qdrant). Stage 2 (Ranking) — тяжёлый ранжировщик на LightGBM или нейросети с cross-features, временем, устройством и контекстом сессии. LightFM — хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры. Наша практика показывает: переход от single-stage к two-stage даёт прирост точности на 15–25% при росте latency всего на 20–30 мс.

Real-Time Serving: архитектура под нагрузку

Latency SLA — 50–100 ms при тысячах запросов в секунду. Base-рекомендации precompute (batch job раз в час) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для событий (клики, добавления в корзину) → обновление контекстных признаков. Feature serving — Redis с TTL (число просмотров за 24 часа, последний кликнутый item). При нагрузке 10k req/s ставим Redis Cluster с репликацией.

A/B тестирование — единственный достоверный способ оценить улучшения. Офлайн-метрики коррелируют с онлайн не всегда. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обязательное чтение для команды. Тест с 5–10% трафика, мониторинг CTR, конверсии, revenue per session. Одна из наших клиентских систем после гибридизации увеличила выручку на 18% за месяц A/B.

Сроки разработки рекомендательной системы

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

Что входит в разработку под ключ

1. Аудит данных — плотность матрицы user×item (обычно <0,1%), распределение активности, temporal паттерны, cold start статистика.
2. Baseline — «популярное» как простой порог, который часто трудно обогнать.
3. Итеративное улучшение — ALS → контентные признаки → two-stage → sequence-aware. Каждый шаг с A/B.
4. Инфраструктура serving — batch precomputation, Redis, real-time re-ranking, мониторинг в Grafana.
5. Документация — model card с метриками, инструкция по деплою, описание признаков.
6. Обучение команды — сессия по интерпретации результатов и дообучению модели.
7. Поддержка — 1 месяц после запуска (фикс инцидентов, донастройка pipeline).

Мы — команда с 7+ годами опыта в рекомендательных системах, реализовали более 30 проектов для e-commerce и медиа. Гарантируем прозрачное A/B‑тестирование и фиксацию улучшения метрик.

Хотите оценить потенциал роста вашего каталога? Свяжитесь с нами для бесплатного аудита данных. Закажите разработку рекомендательной системы — первый прототип в течение двух недель.

from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Больше о математике рекомендательных систем — в Wikipedia.