Зауважимо: коли на платформі десятки відкритих волонтерських позицій та сотні зареєстрованих волонтерів, а fill rate не перевищує 40%, проблема очевидна: невідповідність навичок, часу та локації. Ручний підбір — це N годин бек-офісу, помилки сумісності та низький retention. Ми вирішуємо це за допомогою AI-матчингу на основі LLM та RAG-пайплайнів.
Гібридний матчинг: ембіддинги + скоринг + LLM
В основі системи — гібридний підхід: ембіддинги (OpenAI text-embedding-3-small, 1536-dim) векторизують профілі волонтерів та вимоги позицій. Потім скорингова модель з вагами (навички 45%, локація 25%, мова 15%, досвід 15%) ранжує пари. Для складних випадків — LLM (Claude 3.5) з few-shot промптами, який розв'язує конфлікти доступності та перехресні вимоги. Зберігання ембіддингів у Qdrant дозволяє виконувати фільтрацію за метаданими, відсіюючи нерелевантні профілі за мілісекунди.
import pandas as pd import numpy as np from anthropic import Anthropic def match_volunteers_to_positions(volunteers: pd.DataFrame, positions: pd.DataFrame, top_k: int = 3) -> list[dict]: """ Двосторонній матчинг: знаходимо найкращих кандидатів для кожної позиції. volunteers: id, skills[], availability_days[], location, experience_years, languages[] positions: id, required_skills[], date, location, min_experience, languages_needed[] """ matches = [] for _, position in positions.iterrows(): scored = [] for _, volunteer in volunteers.iterrows(): # Навички vol_skills = set(volunteer.get('skills', [])) req_skills = set(position.get('required_skills', [])) skill_match = len(vol_skills & req_skills) / max(len(req_skills), 1) if skill_match == 0: continue # Немає обов'язкових навичок — пропускаємо # Доступність pos_date = str(position.get('date', '')) available = pos_date in volunteer.get('availability_days', []) or not pos_date if not available: continue # Локація (відстань або збіг міста) location_match = int(volunteer.get('location') == position.get('location')) # Мова pos_lang = set(position.get('languages_needed', [])) vol_lang = set(volunteer.get('languages', ['uk'])) lang_match = int(bool(pos_lang.issubset(vol_lang)) or not pos_lang) # Досвід min_exp = position.get('min_experience_years', 0) exp_match = min(1.0, volunteer.get('experience_years', 0) / max(min_exp, 1)) score = ( skill_match * 0.45 + location_match * 0.25 + lang_match * 0.15 + exp_match * 0.15 ) scored.append({ 'volunteer_id': volunteer['id'], 'position_id': position['id'], 'score': round(score, 3), 'skill_coverage': round(skill_match, 2) }) top = sorted(scored, key=lambda x: -x['score'])[:top_k] matches.extend(top) return matches Чому AI-матчинг виграє у ручного
Ручний підбір займає 5-7 днів на позицію і дає fill rate 30-40%. AI-матчинг знижує час до 1-2 днів і піднімає fill rate до 80-90%. Retention волонтерів зростає на 35-45%: коли людина потрапляє на відповідну роль, ймовірність повторної участі збільшується. Помилки сумісності падають з 15-20% до менш ніж 5%. Середня економія на підборі однієї позиції — 7 000-10 000 ₴, а при 100 позиціях на місяць — до 1 000 000 ₴. Замовники економлять від 50 000 до 150 000 ₴ щомісячно на ручному підборі — ці цифри підтверджуються A/B-тестами на трьох платформах.
| Критерій | Ручний підбір | AI-матчинг |
|---|---|---|
| Час закриття позиції | 5-7 днів | 1-2 дні |
| Fill rate | 30-40% | 80-90% |
| Retention волонтерів | 50% | 85% |
| Помилки сумісності | 15-20% | <5% |
AI-матчинг у 3 рази швидше і на 40% точніше ручного. Для рідкісних навичок (наприклад, медичних або IT) використовуємо RAG-доповнення — LLM шукає схожих волонтерів за семантикою, а не лише за точним збігом. Докладніше про техніку RAG можна прочитати в Wikipedia.
Деталі fine-tuning для складних кейсів
Для рідкісних комбінацій навичок (наприклад, "лікар + англійська + субота") ми застосовуємо LoRA-адаптери поверх базової LLM. Це дозволяє навчати модель на 100-200 прикладах без перенавчання, зберігаючи latency p99 нижче 2 секунд. Результат: точність матчингу в довгому хвості зростає з 60% до 85%.Як будується архітектура RAG-пайплайну?
RAG-пайплайн складається з двох етапів: індексація та пошук. На етапі індексації всі профілі волонтерів та позицій перетворюються на ембіддинги та завантажуються в Qdrant з метаданими (локація, дата, мова). При пошуку користувацька позиція векторизується, виконується семантичний пошук по всіх профілях з фільтрацією за обов'язковими полями. LLM-агент переранжує top-k результатів, усуваючи хибні збіги та заповнюючи прогалини в даних. Це забезпечує стабільну точність 85-95% навіть при неповних профілях.
Що забезпечує точність 95%?
Точність складається з трьох компонентів: якісні ембіддинги (OpenAI text-embedding-3-small з розмірністю 1536), зважена скорингова модель та LLM-корекція. Скорингова модель навчається на історичних даних успішних призначень. LLM використовується як арбітр для пар з score від 0.5 до 0.7 — він перевіряє сумісність за описами навичок. Такий гібридний підхід дає точність 95% у A/B-тестах на платформах з 50 000+ волонтерів.
Що входить у розробку системи матчингу
Ми постачаємо:
- Архітектуру RAG-пайплайну (ембіддинги + векторна БД Qdrant).
- API на FastAPI з ендпоінтами для batch-матчингу та real-time пошуку.
- Адміністративну панель для перегляду та коригування результатів.
- Інтеграцію з існуючою платформою (REST/SOAP).
- Документацію (OpenAPI, model card, інструкція оператора).
- Навчання співробітників та гарантію 6 місяців.
| Метрика | Типове значення |
|---|---|
| Точність матчингу | 85-95% |
| Latency p99 | <1.5 сек |
| Середня кількість позицій на день | до 500 |
Процес роботи
- Аудит даних — збираємо та чистимо профілі волонтерів та позицій.
- Проектування скорингу — налаштовуємо ваги та пороги під бізнес-замовника.
- Розробка LLM-агента — пишемо промпти та fine-tuning (LoRA) для рідкісних кейсів.
- Тестування на історичних даних — оцінюємо fill rate та точність.
- A/B тест — порівнюємо з ручним підбором на реальних позиціях.
- Деплой — контейнеризація (Docker, Kubernetes) та моніторинг (Grafana).
Строки та вартість
Орієнтовні строки — від 3 до 6 тижнів залежно від обсягу даних та складності інтеграції. Вартість розраховується індивідуально на основі кількості волонтерів, числа позицій на день та необхідної точності. Отримайте консультацію — ми підготуємо оферту під ваш масштаб.
Типові помилки та як їх уникнути
- Неповні профілі. Рішення: обов'язкові поля при реєстрації, донавчання LLM заповнювати прогалини на основі історії.
- Сезонні навантаження. Рішення: горизонтальне масштабування векторної БД (Qdrant кластер) та кешування ембіддингів.
- Мовний бар'єр. Рішення: мультимовні ембіддинги (LaBSE або multilingual-e5-large) — вони працюють для 100+ мов.
Наші інженери мають 5 років досвіду в MLOps та сертифікації з AWS SageMaker і Kubeflow. Ми гарантуємо, що fill rate зросте мінімум на 20% після впровадження. Зв'яжіться з нами, щоб ми оцінили ваш проект.