Зауважимо: коли на платформі десятки відкритих волонтерських позицій та сотні зареєстрованих волонтерів, а 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% після впровадження. Зв'яжіться з нами, щоб ми оцінили ваш проект.
