AI do autouzupełniania filtrów ofert pracy

Automatyczne wypełnianie filtrów ofert pracy dzięki AI i bazie danych

Użytkownicy portali z ofertami pracy często mają problem z ustawieniem filtrów na tablicach ogłoszeniowych takich jak Pracuj.pl, OLX Praca, No Fluff Jobs czy Indeed. Analiza pokazuje: odwiedzający otwierają panel filtrów, wpisują dane chaotycznie, dostają nieistotne wyniki — od tysięcy ofert sprzątaczy po pustą listę — i odchodzą. Próby rozwiązania przez ostrzeżenia, obowiązkowe pola i podświetlenia nie zadziałały: konwersja spadała, użytkownicy się zniechęcali lub wpisywali bezsensowne zapytania typu „praca”.

Kluczowy wniosek: problem leży w złożoności. Każdy serwis używa unikalnych ID dla miast (Pracuj.pl — 1600 miast z ID, OLX Praca — własne), specjalizacji, doświadczenia. Przesyłanie wszystkich słowników do LLM daje 140 000 tokenów na zapytanie (25–40 zł), halucynacje lub bankructwo.

Architektura data-driven pipeline'u dla AI

Rozwiązanie opiera się na istniejącej bazie danych z tabelami job_filters, job_filter_options, job_service_filters, city_master i city_source_map. Te struktury już mapują wartości kanoniczne na ID serwisów (np. Warszawa: Pracuj.pl=1, OLX Praca=4).

System dzieli filtry na kategorie automatycznie po fladze is_ai_eligible = true:

• Małe słowniki (≤30 wartości): doświadczenie (noExperience, between1And3), forma zatrudnienia (FULL, PART). Przesyłane do promptu (~400 tokenów).
• Duże słowniki (>30): miasta, role. LLM zwraca tekst („Warszawa”), kod rozwiązuje ID z bazy.
• Wolny tekst: zapytanie typu „Python backend developer”.
• Liczby: pensja z CV lub LLM.

Prompt generowany dynamicznie z bazy. Przykład:

== FILTRY Z WYBOREM ==
experience: noExperience="Brak doświadczenia", between1And3="Od 1 do 3 lat"
employment_form: FULL="Pełny etat"

== POLA SŁOWNIKOWE ==
city_name: "Warszawa"

== TEKSTOWE ==
text: 2-8 słów

Wejście: esencja CV (umiejętności, doświadczenie), pożądane stanowisko, serwisy. Wyjście — JSON bez ID:

{
  "text": "Python backend developer",
  "area_name": "Warszawa",
  "experience": "between1And3",
  "salary": {"from": 250000}
}

Fazy przetwarzania i rozwiązywania

Faza 1: Generowanie promptu i wywołanie LLM

BuildSearchFiltersPromptTask zbiera instrukcję. LLM (GigaChat) parsuje intencje użytkownika, wybiera z małych słowników, nazywa duże.

Faza 2: Postprocesing w kodzie

• Rozwiązywanie: SearchCitiesAction szuka „Warszawa” w city_master, mapuje na ID wg city_source_map.
• Adaptacja: konwertuje between1And3 na format API serwisu.
• Składanie: unified_filters + filter_labels dla frontendu.

Rezultat: wypełnione filtry dla wszystkich serwisów. Użytkownik sprawdza i zapisuje.

Skalowalność: nowy serwis/filtr — tylko dane w bazie, prompt i pipeline adaptują się automatycznie.

Metryki efektywności

| Podejście | Tokeny | Koszt zapytania | Dokładność |

|-----------|--------|-----------------|------------|

| Naiwne (wszystkie słowniki) | 140 000 | 25–40 zł | Niska (halucynacje) |

| Data-driven | 850 + 150 | 0,1 zł | Wysoka (rozwiązywanie z bazy) |

Oszczędność: 150x. Wskaźnik odrzuceń na wyszukiwaniu spadł, wzrost średniego przychodu z płatnych funkcji.

Co ważne

• Podział ról: LLM dla semantyki, baza dla mapowania ID — minimalizuje tokeny i błędy.
• Auto-klasyfikacja: próg 30 wartości dynamiczny, nowe filtry integrują się bez kodu.
• Struktura JSON: ścisłe wyjście LLM ułatwia parsowanie.
• Skala: tysiące użytkowników bez drożenia.
• UX: automatyczne wypełnianie obniża barierę wejścia.

— Editorial Team