IA pour le remplissage automatique des filtres d'emploi

Remplissage automatique IA des filtres de recherche d'emploi avec base de données pilotée

Les chercheurs d'emploi peinent souvent avec les filtres sur des sites comme HeadHunter, SuperJob, Zarplata.ru et TrudVsem. Les analyses montrent que les utilisateurs ouvrent le panneau de filtres, saisissent des données au hasard, obtiennent des résultats inadaptés — de milliers d'offres de concierge à des listes vides — et abandonnent. Les solutions comme les avertissements, les champs obligatoires et les surlignages ont échoué : les conversions ont chuté car les utilisateurs se sentaient intimidés ou tapaient n'importe quoi comme « emploi ».

Clé de compréhension : c'est la complexité. Chaque plateforme utilise des ID uniques pour les villes (HeadHunter en a 1 600 avec ID, SuperJob les siens), spécialisations, niveaux d'expérience. Déverser les dictionnaires complets dans un LLM coûte 140 000 tokens par requête (25–40 RUB), provoque des hallucinations ou mène à la faillite.

Architecture du pipeline IA piloté par les données

La solution exploite une base de données existante avec les tables job_filters, job_filter_options, job_service_filters, city_master et city_source_map. Celles-ci font le mapping des valeurs canoniques vers les ID spécifiques aux plateformes (ex. : Moscou : HeadHunter=1, SuperJob=4).

Le système catégorise automatiquement les filtres marqués is_ai_eligible = true :

• Petits dictionnaires (≤30 options) : expérience (noExperience, between1And3), contrat (FULL, PART). Envoyés dans le prompt (~400 tokens).
• Gros dictionnaires (>30) : villes, postes. Le LLM sort du texte (« Moscou »), le code résout les ID via la DB.
• Texte libre : requêtes comme « développeur backend Python ».
• Chiffres : salaire du CV ou du LLM.

Les prompts sont générés dynamiquement depuis la DB. Exemple :

== FILTRES À CHOIX MULTIPLES ==
experience: noExperience="Aucune expérience", between1And3="1-3 ans"
employment_form: FULL="Temps plein"

== CHAMPS DICTIONNAIRE ==
ville: "Moscou"

== CHAMPS TEXTE ==
texte: 2-8 mots

Entrée : résumé du CV (compétences, expérience), poste désiré, sites cibles. Sortie — JSON sans ID :

{
  "texte": "développeur backend Python",
  "nom_ville": "Moscou",
  "experience": "between1And3",
  "salaire": {"de": 250000}
}

Phases de traitement et résolution

Phase 1 : Génération du prompt et appel LLM

BuildSearchFiltersPromptTask monte l'instruction. Le LLM (GigaChat) analyse l'intention utilisateur, choisit dans les petits dictionnaires, nomme les gros.

Phase 2 : Post-traitement par code

• Résolution : SearchCitiesAction cherche « Moscou » dans city_master, mappe les ID via city_source_map.
• Adaptation : convertit between1And3 au format API de la plateforme.
• Assemblage : filtres_unifies + labels_filtres pour le frontend.

Résultat : filtres pré-remplis pour tous les sites. Les utilisateurs vérifient et sauvegardent.

Évolutivité : nouveau site/filtre — juste ajouter les données en DB ; le prompt et le pipeline s'adaptent automatiquement.

Métriques de performance

| Approche | Tokens | Coût par requête | Précision |

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

| Naïve (dictionnaires complets) | 140 000 | 25–40 RUB | Faible (hallucinations) |

| Pilotée par données | 850 + 150 | 0,1 RUB | Élevée (résolution DB) |

Économies : 150x. Taux d'abandon sur recherche réduit, revenu moyen par utilisateur des fonctionnalités payantes en hausse.

Enseignements clés

• Séparation des rôles : le LLM gère la sémantique, la DB les mappings ID — réduit tokens et erreurs.
• Auto-classification : seuil de 30 options dynamique ; nouveaux filtres intégrés sans code.
• Sortie JSON : format strict du LLM simplifie le parsing.
• Échelle : gère des milliers d'utilisateurs sans pics de coût.
• UX : pré-remplissage abaisse les barrières d'entrée.

— Editorial Team