KI für automatisches Ausfüllen von Stellenfiltern

KI-gestützte Autofill-Funktion für Jobsuchfilter mit datengetriebener Datenbank

Bewerber kämpfen oft mit Filtern auf Plattformen wie HeadHunter, SuperJob, Zarplata.ru und TrudVsem. Analysen zeigen: Nutzer öffnen das Filterpanel, geben Daten planlos ein, erhalten irrelevante Ergebnisse – von Tausenden von Hausmeisterjobs bis zu leeren Listen – und verlassen die Seite. Maßnahmen wie Hinweise, Pflichtfelder und Hervorhebungen scheiterten: Die Conversion sank, weil Nutzer eingeschüchtert waren oder Unsinn wie „Job“ eingaben.

Schlüsselinsight: Es liegt an der Komplexität. Jede Plattform verwendet eigene IDs für Städte (HeadHunter hat 1.600 mit IDs, SuperJob eigene), Spezialisierungen, Erfahrungsstufen. Vollständige Wörterbücher in ein LLM zu packen bedeutet 140.000 Tokens pro Anfrage (25–40 RUB), Halluzinationen oder Pleite.

Datengetriebene KI-Pipeline-Architektur

Die Lösung nutzt eine bestehende Datenbank mit Tabellen job_filters, job_filter_options, job_service_filters, city_master und city_source_map. Diese kartieren kanonische Werte zu plattformspezifischen IDs (z. B. Moskau: HeadHunter=1, SuperJob=4).

Das System kategorisiert automatisch Filter mit is_ai_eligible = true:

• Kleine Wörterbücher (≤30 Optionen): Erfahrung (noExperience, between1And3), Beschäftigungsart (FULL, PART). Direkt in den Prompt (~400 Tokens).
• Große Wörterbücher (>30): Städte, Rollen. LLM gibt Text aus („Moskau“), Code löst IDs aus der DB.
• Freitext: Anfragen wie „Python-Backend-Entwickler“.
• Zahlen: Gehalt aus Lebenslauf oder LLM.

Prompts werden dynamisch aus der DB generiert. Beispiel:

== MEHRFACHWAHL-FILTER ==
experience: noExperience="Keine Erfahrung", between1And3="1-3 Jahre"
employment_form: FULL="Vollzeit"

== WÖRTERBUCH-FELDER ==
city_name: "Moskau"

== TEXTFELDER ==
text: 2-8 Wörter

Eingabe: Lebenslauf-Zusammenfassung (Fähigkeiten, Erfahrung), gewünschte Rolle, Zielplattformen. Ausgabe – JSON ohne IDs:

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

Verarbeitungsphasen und Auflösung

Phase 1: Prompt-Generierung und LLM-Aufruf

BuildSearchFiltersPromptTask erstellt die Anweisung. LLM (GigaChat) analysiert die Nutzerintention, wählt aus kleinen Wörterbüchern, benennt große.

Phase 2: Code-Nachbearbeitung

• Auflösung: SearchCitiesAction sucht „Moskau“ in city_master, mappt zu IDs via city_source_map.
• Anpassung: Konvertiert between1And3 ins Plattform-API-Format.
• Zusammenbau: unified_filters + filter_labels für Frontend.

Ergebnis: Vorgefüllte Filter für alle Plattformen. Nutzer prüfen und speichern.

Skalierbarkeit: Neue Plattform/Filter – einfach DB-Daten ergänzen; Prompt und Pipeline passen sich automatisch an.

Leistungsmetriken

| Ansatz | Tokens | Kosten pro Anfrage | Genauigkeit |

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

| Naiv (volle Wörterbücher) | 140.000 | 25–40 RUB | Niedrig (Halluzinationen) |

| Datengetrieben | 850 + 150 | 0,1 RUB | Hoch (DB-Auflösung) |

Einsparungen: 150-fach. Absprungrate bei Suchen gesunken, durchschnittlicher Umsatz pro Nutzer aus bezahlten Features gestiegen.

Wichtige Erkenntnisse

• Rollenverteilung: LLM übernimmt Semantik, DB die ID-Mapping – spart Tokens und Fehler.
• Auto-Klassifizierung: 30-Optionen-Grenze dynamisch; neue Filter kodierfrei integrierbar.
• JSON-Ausgabe: Strenges LLM-Format vereinfacht Parsing.
• Skalierung: Bewältigt Tausende Nutzer ohne Kostenexplosion.
• UX: Autofill senkt Einstiegshürden.

— Editorial Team