HackerRanks Open-Source-ATS: Derselbe Lebenslauf schwankt zwischen 90, 74 und 88 Punkten
(danunparsed.com)- Beim wiederholten Ausführen von HackerRanks Open-Source-ATS-Recruiting-Agent mit demselben Lebenslauf und demselben Befehl schwankten die Bewertungen zwischen 66 und 99 Punkten; bei einem Cutoff von 85 Punkten fielen 65 % durch
- Das Tool parst PDF-Lebensläufe und ruft das LLM sechsmal auf, um Basisdaten, Berufserfahrung, Ausbildung, Skills, Projekte und Auszeichnungen zu strukturieren; anschließend werden zusätzlich GitHub-Informationen einbezogen und mit 100 Punkten plus 20 Bonuspunkten bewertet
- Technische Skills waren in 98 von 100 Durchläufen mit 8/10 Punkten nahezu konstant, doch die Projektbewertung zeigte starke Schwankungen und pendelte zwischen „fehlende architektonische Komplexität“ und „zeigt reale Deployments“
- Nicht nur beim Standardmodell gemma3:4b mit temperature 0.1, sondern auch bei temperature 0 blieb Nichtdeterminismus bestehen; selbst mit Gemini ergab sich bei einem Cutoff von 60 Punkten eine Durchfallquote von 28 %
- Der Bereich Berufserfahrung erhielt selbst bei einem alten Lebenslauf mit nur einem Praktikum 25/25 Punkte, sodass LLM-Scoring eher zu zufallsabhängiger Filterung werden kann, statt die Qualität von Bewerbern zu unterscheiden
Derselbe Lebenslauf erhält jedes Mal andere Punkte
- HackerRanks Open-Source-ATS hiring-agent wurde zum Testobjekt, nachdem es auf LinkedIn und Reddit Aufmerksamkeit bekommen hatte
- Die erste Ausführung ergab 90/100 Punkte; nachdem Debug-Ausgaben entfernt wurden, lieferte ein erneuter Lauf mit demselben Lebenslauf und demselben Befehl 74/100 Punkte
- Nach dem Deaktivieren von
DEVELOPMENT_MODEund 100 wiederholten Durchläufen reichte die Punktespanne von 66 bis 99 Punkten - Wenn die Schwelle eines Unternehmens bei 85 Punkten liegt, fällt derselbe Lebenslauf mit einer Wahrscheinlichkeit von 65 % durch
Bewertungspipeline und Punktestruktur
- Das Tool parst einen PDF-Lebenslauf zu Text und ruft anschließend mehrfach ein LLM auf, um Bewerberinformationen zu strukturieren
- Basisdaten
- Berufserfahrung
- Ausbildung
- Skills
- Projekte
- Auszeichnungen
- Es scannt das GitHub-Profil und die wichtigsten Repositories und fügt diese Informationen als zusätzlichen Kontext hinzu, bevor alle Daten gemeinsam an die LLM-Bewertung gehen
- Das Standardmodell ist das lokal ausgeführte gemma3:4b, die temperature ist auf 0.1 gesetzt
- Die Bewertung erfolgt auf einer Skala von 100 Punkten, mit bis zu 20 zusätzlichen Bonuspunkten
- Open-Source-Beiträge: 35 Punkte
- Persönliche Projekte: 30 Punkte
- Berufserfahrung: 25 Punkte
- Technische Skills: 10 Punkte
- Startup-Erfahrung, Portfolio-Website, technischer Blog usw.: bis zu 20 Bonuspunkte
Konsistente und schwankende Bereiche
- Technische Skills waren nahezu konsistent: In 98 von 100 Durchläufen gab es 8/10 Punkte
- Ob Technologien wie React vorhanden sind, ähnelt eher einer Checkliste, sodass der subjektive Ermessensspielraum des LLM gering ist
- Der Bereich Projekte hingegen wurde je nach Durchlauf sehr unterschiedlich beurteilt
- In manchen Läufen wurden Projekte als „fehlende architektonische Komplexität“ bewertet
- In anderen Läufen wurden sie als „zeigt reale Deployments“ bewertet
- temperature 0.1 ist eine niedrige Einstellung, doch selbst eine Senkung auf temperature 0 beseitigte das Problem nicht
- Auch in einem im Oktober 2025 eröffneten GitHub issue fielen die Bewertungen bei temperature 0 in sechs aufeinanderfolgenden Läufen mit 27, 34, 32, 34, 34, 30 unterschiedlich aus
Instabilität bleibt auch beim Modellwechsel
- Da gemma3:4b ein lokales Modell ist, wurde auch der Einfluss des Modells überprüft
- Mit Gemini wurde die Punkteverteilung enger und lag zwischen 48 und 64 Punkten
- Liegt der Cutoff jedoch bei 60 Punkten, fällt ein Bewerber unabhängig vom Inhalt seines Lebenslaufs mit 28 % Wahrscheinlichkeit durch
- Die Open-Source-Bewertung wurde konsistenter, die Projektbewertung schwankte jedoch weiterhin stark
Das Gegenproblem bei Berufserfahrung: konsistent, aber nutzlos
- Der Bereich Berufserfahrung erhielt in allen Durchläufen 25/25 Punkte
- Selbst ein alter Lebenslauf mit nur einem Praktikum erhielt 25/25 Punkte
- Der Production-Abschnitt im Bewertungs-Prompt besteht nur aus zwei Zeilen
- Analyse realer Arbeit, Praktika und Production-Erfahrung in den Abschnitten
workundvolunteer - Zusätzliche Berücksichtigung von Rollen als Gründer, Mitgründer oder früher Startup-Engineer
- Analyse realer Arbeit, Praktika und Production-Erfahrung in den Abschnitten
- Es fehlen Kriterien, Beispiele oder Benchmarks, die 15 von 25 Punkten unterscheiden
- Dadurch können ein Praktikum eines Junior Engineers, zehn Jahre Distributed-Systems-Erfahrung eines Principal Engineers und der im Test verwendete Lebenslauf alle 25/25 Punkte erhalten
Praktische Risiken beim Lebenslauf-Screening
- Aufgaben wie das Parsen von Lebensläufen in strukturierte Daten oder das Prüfen, ob Python-Kenntnisse vorhanden sind, sind vergleichsweise gut geeignete Einsatzfälle für LLMs
- Die Einschätzung, ob die Erfahrung eines Kandidaten 18 oder 24 Punkte wert ist, führt eher zu einem Vibe-Check
- Auch die Struktur, in der Open Source und Projekte zusammen 65 % Gewichtung ausmachen, kann Einstellungsentscheidungen verzerren
- Ein Bewerber mit zwei Praktika und einem Open-Source-Projekt könnte höher bewertet werden als ein Engineer mit 30 Jahren Erfahrung, der S3 gebaut hat
- Engineers, die wichtige Arbeit geleistet haben, die nicht auf GitHub sichtbar ist, könnten mehr als die Hälfte der Punkte verlieren
- Engineers, die befugt sind, AI-Tools für das Lebenslauf-Screening einzuführen, sollten bedenken, dass ein Tool, das Qualität nicht unterscheiden kann, schlicht zu einem Mechanismus werden kann, der Bewerber aussortiert
Korrektur
- In Zeile 1 des Templates resume_evaluation_criteria.jinja steht „Software Intern“
- Diese Formulierung ist nicht dokumentiert und wird an keiner anderen Stelle im Repository referenziert
- Dasselbe Template vergibt später Bonuspunkte für Rollen als Gründer, Mitgründer und frühe Startup-Engineers
- Auch bei erneuter Ausführung mit einem expliziten Senior-SWE-Prompt blieben die Ergebnisse gleich; die Bewertungsdimensionen funktionieren unabhängig vom Job-Level
1 Kommentare
Hacker-News-Kommentare
Es ist erstaunlich, wie viele Leute nicht wissen, dass LLMs als rein stochastischer Prozess arbeiten, deshalb ist so ein tiefgehender Beitrag willkommen.
Ich bin gerade auf Jobsuche, und vielleicht ist das der Grund, warum es heute so schwer ist, Rückmeldungen zu bekommen. Der Lebenslauf wird einfach in irgendein LLM-Schwarzes-Loch geworfen, und niemand scheint zu wissen, wie das tatsächlich funktioniert.
Die Erklärung im Artikel, „temperature 0.1 — ein niedriger Wert, von dem man annimmt, dass er das Modell zu deterministischem Output hin lenkt“, ist nicht korrekt. Temperature ist kein Determinismus-Schalter, sondern ein Wert, der die Sampling-Verteilung beeinflusst; sie wird nur spitzer, bleibt aber weiterhin eine Verteilung.
Genauer gesagt existiert temperature 0 selbst nicht. Mathematisch wird die Verteilung, je näher die Temperature an 0 heranrückt, immer spitzer, der wahrscheinlichste Sample nähert sich praktisch unendlich an und der Rest nahezu 0.
In realen Implementierungen bedeutet
temperature=0nicht, dass dieselbe Formel wie für Werte ungleich 0 verwendet wird, sondern dass in einem separaten Zweig einerif-Anweisung der häufigste Sample gewählt wird, um eine Division durch 0 zu vermeiden.Wegen Batch-Verarbeitung oder implementierungsabhängigen Fließkommafehlern ändert sich die Wahrscheinlichkeitsverteilung selbst jedoch oft von Lauf zu Lauf, und dadurch ändert sich auch das gezogene Sample.
Zwei Menschen können denselben Lebenslauf lesen und zum gleichen Schluss kommen, und zwei Patienten mit denselben Symptomen und demselben klinischen Bild können unterschiedliche Krankheiten haben.
Die Erklärung, dass alte KI vor allem an den Kosten der Pflege von Wissensbasen gestorben sei, überzeugt mich nicht wirklich; ich denke eher, dass das Fehlen eines allgemeinen Inferenzsystems zum Umgang mit Unsicherheit das Kernproblem war.
Dass Spock ständig Dinge sagt wie „Captain, die Überlebenswahrscheinlichkeit bei dieser Mission beträgt 21 %“, wirkte auf mich immer wie ein Running Gag. Aus bayesscher Sicht gibt es auch für Wahrscheinlichkeitsverteilungen wiederum Wahrscheinlichkeitsverteilungen, daher wäre „Die Chance, diese Mission zu überleben, ist β(5,1)“ eigentlich die passendere Formulierung.
In diesem Sinne ist es gar nicht so seltsam, den Lebenslauf 100-mal in diese Maschine zu stecken und sich die Wahrscheinlichkeitsverteilung der Punktezahl anzusehen.
[1] Trotzdem bin ich die Art Verrückter, die im Bett liegt und auf dem Tablet Bilder sortiert, bis das visuelle System zusammenbricht.
Bei MoE muss ein doppelter Input allerdings auch im gesamten Batch identisch sein. Batch-Nachbarn können die Expertenauswahl beeinflussen.
Die Kernel müssen deterministisch sein, und bei Reasoning-Modellen darf es keine systemweite Umschaltung des Aufwandsniveaus geben, die etwa auf die Auslastung des gesamten Clusters reagiert.
Kurz gesagt: In herkömmlicher Cloud-Infrastruktur ist selbst temperature 0 wahrscheinlich nicht deterministisch, aber bei Edge-Inferenz kann es ziemlich zuverlässig deterministisch sein.
Die Formulierung, 0.1 sei deterministischer, halte ich dennoch für eine recht vernünftige Zusammenfassung. Wird bei temperature 0.1 nicht viel häufiger in Richtung der „Antwort von temperature 0“ gesampelt als bei temperature 0.9?
Ich habe unzählige Male gehört: „Wenn du konsistente Ergebnisse willst, setz die Temperature auf 0.“
Es gibt ein paar Gründe, warum das nicht so sein muss, aber wenn man wie der Autor ein lokales Modell ausführt, sollten diese Gründe meiner Meinung nach nicht gelten.
Wenn man noch die Tendenz von KI hinzunimmt, von KI erzeugten Code zu „bevorzugen“, sowie weitere Verzerrungen, dann ist diese Vorgehensweise in der EU mit hoher Wahrscheinlichkeit auf mehrere Arten sehr illegal, weil sie gegen Antidiskriminierungsgesetze verstößt
Ich würde sagen, dass es im Allgemeinen zulässig sein kann, Bewerbungen zufällig auszusortieren, wenn es einfach zu viele davon gibt. Aber es muss tatsächlich zufällig sein und unabhängig vom Inhalt des Lebenslaufs
Bei KI ist die Zufälligkeit nicht unabhängig von der tatsächlichen Bewertung des Lebenslaufs, daher trifft das hier nicht zu
Generell kann man nicht garantieren, dass KI keine systematischen Verzerrungen anwendet, und es gibt starke Anzeichen dafür, dass sie genau das wahrscheinlich tut
Menschen kann man trainieren und anweisen, Vorurteile zu ignorieren. Natürlich funktioniert auch das nicht verlässlich, aber zumindest wird die Verantwortung für illegale Verzerrungen damit an die einstellende Person delegiert, die gegen diese Anweisung verstößt
Beim Einsatz von KI hingegen trägt der Nutzer die Verantwortung, egal was angewiesen wurde. Zudem kann man technisch eventuell „zeigen oder beweisen“, dass eine bestimmte KI in einem bestimmten Kontext stark verzerrt ist. Bei menschlichen Mitarbeitenden ist das technisch zwar ebenfalls möglich, in der Praxis aber fast nie
Letztlich verlagert sich das rechtliche Risiko von einer „individuellen und meist bestreitbaren“ Ebene hin zu systematisch nachweisbarer Verzerrung. Anders gesagt: Wenn bekannt ist, dass KI bei Einstellungen eingesetzt wird, können Menschen das juristisch systematisch angreifen
Schon rein mathematisch ist es also wahrscheinlich, dass dies auf irgendeine Weise mit Race, Geschlecht und anderen geschützten Gruppen in den USA korreliert
Deshalb könnte es auch in den USA mit einer einzigen guten Klage illegal werden. Man muss nicht einmal gewinnen; wenn es vor Gericht nur lange genug standhält, reicht das schon, um andere Unternehmen davon abzuschrecken, so etwas zu nutzen
Ich möchte nicht in der Position eines Beklagten sein, der beweisen muss, dass mein KI-Screener sämtliche Einstellungsregeln vollständig einhält. Das wäre ein Albtraum
[1]: https://gwern.net/everything
Den vierten Lebenslauf aus dem Stapel zu ziehen und dieser Person den Job anzubieten, wäre dumm, aber ein vollkommen faires Verfahren für eine Einstellungsentscheidung
KI ist jedoch sehr gut darin, Bias zu erfassen; daher wäre es nicht überraschend, wenn sie beim Aussortieren von Lebensläufen Kriterien wie den Namen eines Bewerbers heranzieht, obwohl das absolut kein zulässiger Maßstab sein darf
Es könnte zum Beispiel sein, dass alle Lebensläufe durchkommen, in denen steht, dass jemand einen Tippfehler in einem großen Open-Source-Projekt behoben hat, während Lebensläufe, in denen nur das eigene Projekt genannt wird, mit 60% Wahrscheinlichkeit aussortiert werden. Dann verliert man mehr gute Kandidaten als schlechte
Ich stimme zu, dass das wie ein irrationaler Spielautomat funktioniert und daher unerwünschte indirekte Diskriminierungseffekte haben kann. Aber es dürfte wohl nicht leicht sein zu zeigen, dass wegen „Religion oder Weltanschauung, Behinderung, Alter oder sexueller Orientierung“ diskriminiert wird. Möglich ist es, aber Anwälte müssten viel Arbeit investieren, um das vor Gericht zu belegen
Interessanter ist der EU AI Act. Dieser Teil gilt zwar erst ab dem 2. Dezember 2027, aber KI-Systeme, die für Einstellung oder die Auswahl natürlicher Personen eingesetzt werden, insbesondere für die Platzierung zielgerichteter Stellenanzeigen, die Analyse und Filterung von Bewerbungen sowie die Bewertung von Kandidaten, sind eindeutig Hochrisiko-KI-Systeme
Das heißt nicht, dass sie verboten sind, aber später könnten LLMs von Hochrisiko-KI-Anwendungsfällen ausgenommen werden. Denn sie könnten ausnahmslos unter Article 6 fallen
Solange die Standards noch nicht veröffentlicht sind, habe ich keinerlei Vorstellung, wie man beim Einsatz von LLMs für solche Aufgaben den folgenden Teil von Article 10 einhalten soll
„(f) Verzerrungen prüfen, die sich auf die Gesundheit und Sicherheit von Menschen auswirken, Grundrechte negativ beeinträchtigen oder zu nach EU-Recht verbotener Diskriminierung führen könnten, insbesondere wenn Datenausgaben die Eingaben künftiger Vorgänge beeinflussen
(g) geeignete Maßnahmen zur Erkennung, Verhinderung und Minderung möglicher Verzerrungen ergreifen, die gemäß (f) identifiziert wurden“
Im Moment halte ich das bei allgemeinen LLMs technisch für unmöglich, selbst wenn der Modellanbieter vollständig kooperiert. Bei kleineren Modellen könnte sinnvolles Auditing vielleicht möglich sein
Der EU AI Act könnte am Ende alle Vibe-Coding-artigen Ansätze aus Hochrisiko-Anwendungsfällen nach Annex III ausschließen, bei denen man „LLMs verwendet, aber nicht so genau weiß, warum“, und das erscheint plausibel
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
„Die betroffene Person hat das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung — einschließlich Profiling — beruhenden Entscheidung unterworfen zu werden, die ihr gegenüber rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt“
Die Ausnahmen in 22(2) sind schwer anwendbar. Es ist schwer zu behaupten, dass dies wirklich erforderlich ist, und im Beschäftigungskontext ist Einwilligung kaum tragfähig. Möglich wäre es, wenn spezielles EU- oder mitgliedstaatliches Recht es erlaubt, aber dann bräuchte es eine gesonderte Rechtsgrundlage
An diesem Punkt könnte man auch einfach den Witz übernehmen: „Ich will keine Pechvögel einstellen, also werfe ich mit geschlossenen Augen die Hälfte der Lebensläufe weg“
Dieses Verfahren begünstigte qualifizierte Studierende aus weniger wohlhabendem Hintergrund gegenüber solchen, die genug Ressourcen hatten, die damals immer komplexeren manuellen Kriterien zur Lebenslaufbewertung zu ihren Gunsten auszunutzen
Es gab dann organisierte Kampagnen nach dem Muster „Wollt ihr angehende Ärzte per Glücksspiel auswählen?“, und am Ende wurde das Losverfahren stillschweigend abgeschafft
Die verbleibende Hälfte der Kandidaten hat bei dieser Auswahl bereits etwas von ihrem Glück verbraucht und wird im Durchschnitt daher weniger Glück haben als die weggeworfene Hälfte
Ausbildung und Training wurden in den vergangenen Jahrzehnten massiv ausgeweitet, sodass die Zahl der Arbeitssuchenden immer weiter gestiegen ist, während die Schaffung neuer Jobs nicht Schritt gehalten hat
Wenn sich Dutzende Kandidaten auf eine einzige offene Stelle bewerben, kann ein Arbeitgeber Lebensläufe miserabel vorsortieren oder die Hälfte wegwerfen und trotzdem noch eine qualifizierte Person einstellen
„Ich scheide mit einer Wahrscheinlichkeit von 65 % aus. Exakt derselbe Lebenslauf, anderes Glück“ — aus der Perspektive von jemandem, der in den letzten Jahren Hiring-Pipelines für technische Rollen betrieben hat, ist das ehrlich gesagt sogar eine hervorragende Zahl.
Ich sage das nur ungern objektiv, aber es stimmt.
35 % Chance, technisches Personal ohne Aufwand in die nächste Runde zu bringen? Selbst mit domänenspezifischen Vorabfragen habe ich schon über 100 Bewerber pro Stunde gesichtet. Dann kommen also 35 „vorausgewählte“ Bewerber pro Stunde heraus.
Werden dabei valide Kandidaten ausgesiebt? Ja. Hat man trotzdem einen Kandidatenpool, der 35-mal größer ist als benötigt? Leider ebenfalls ja.
Die Zahl der Bewerber ist so hoch, dass die Chance, ohne Eingreifen von AI in die nächste Runde zu kommen, in Wirklichkeit deutlich geringer wäre. Wenn du dich nicht sofort beworben hast — und zwar mit einem AI-Bot — dann stehen mehr als 50 Leute vor dir, und irgendwann muss eine erschöpfte technische Führungskraft erst einmal bis zu deinem Lebenslauf kommen.
Es gibt einen Grund, warum es einen Referral-Bonus gibt.
Mithilfe modernster Technologie lässt es nur die besten* 1 % der Bewerbungen durch.
*gemessen an unseren proprietären, nicht öffentlichen und nicht deterministischen Metriken, die
Math.randomsein können — oder auch nichtEin Gate, das den Lebenslaufzufluss reduziert, ist nur dann nützlich, wenn diese Reduktion mit Qualität korreliert. Andernfalls zieht es den Einstellungsprozess nur in die Länge oder führt am Ende dazu, dass man die Hiring-Kriterien unnötig senkt.
So etwas wie „John Schmidt“, „John J. Schmidt“, „John J. J. Schmidt“, „John Jacob J. Schmidt“, „J. J. Jingleheimer Schmidt“.
Wenn die ersten 50 Bewerbungen ohnehin Bots sind, warum liest man Lebensläufe dann nach Bewerbungsreihenfolge?
Noch besorgniserregender ist, dass andere Systeme, falls sie wie dieses ATS arbeiten, offenbar nach Faktoren urteilen, die eine große Zahl ziemlich ordentlicher oder guter Kandidaten aussortieren.
Zum Beispiel werden 65 Punkte für die Kombination aus persönlichen Projekten und Open-Source-Beiträgen vergeben. Das mag gut sein, wenn Technik dein einziges Interesse ist und du keine Familie, keine Unterhaltsverpflichtungen und keinen zweiten oder dritten Job hast.
Aber sobald auch nur eines davon zutrifft, scheinen die Chancen massiv gegen dich zu stehen.
Man fragt sich, wie viele dieser Systeme so gestaltet sind, dass sie wohlhabende Menschen begünstigen, die sich außer Studium oder einem einzigen Job in der gewünschten Branche um kaum etwas kümmern müssen und sich mit fast schon spezialisiertem Sonderinteresse auf Technik fixieren können.
Bei mir selbst zum Beispiel ist es so, dass ich außerhalb der Arbeit fast keine privaten Projekte mache. Meine gesamte tatsächliche Programmiererfahrung stammt aus dem, was ich während der Arbeitszeit für Arbeitgeber getan habe.
Meine Hobbys liegen in techniknahen Bereichen wie 3D-Druck, Hardware/Arduino und Fotografie, aber ich bin nicht der Typ, der massenhaft Projekte auf GitHub erstellt und hochlädt.
Ich würde auch niemals Fake-CRUD- oder SaaS-Apps bauen, nur um sie potenziellen Arbeitgebern zu zeigen. Das ist Zeitverschwendung.
Ich habe bewusst überhaupt keine solche Online-Präsenz aufgebaut. Mein GitHub hat keine öffentlichen Repositories, und ich blogge nicht.
Diese Tendenz hat sich auch auf den Bereich Operations/Systemadministration ausgeweitet, in dem ich arbeite, und dort ist es sogar noch schlimmer. Natürlich habe ich nicht jede Menge umgebungsspezifischer Skripte auf meinem GitHub hochgeladen — warum sollte ich? Für jemanden, der nicht in meiner Abteilung meiner aktuellen Firma arbeitet, hätte das keinerlei Bedeutung.
Das Wort Determinismus hat einen fast magischen Effekt, der jedes Online-Schreiben, das es berührt, in eine Schieflage bringt.
Sobald das Wort fällt, kann man fast garantieren, dass es in die falsche Richtung geht. Trotzdem geht es hier um echte Determiniertheit im Sinn von gleichem Input, gleichem Output — nicht um irgendwelche anderen irrelevanten Dinge.
Determiniertheit ist wichtig für Reproduzierbarkeit, aber will man in diesem Fall wirklich, dass der Output reproduzierbar ist? LLM-Ausgaben deterministisch zu machen, ist relativ trivial. Wenn man Batching verwendet, nutzt man batch-invariante Kernel, setzt die Temperature auf 0 oder — besser, weil Random Sampling einen Zweck hat — fixiert einfach den Seed. In manchen Systemen ist das bereits möglich.
Aber das macht das Ergebnis nicht nützlicher. Es verdeckt nur die Tatsache, dass der Agent tatsächlich nicht sicher ist. Schau dir die Spannweite der Bewertungen an. Er sagt immer noch nichts voraus, nur dass der Score jedes Mal derselbe wäre. Will man das wirklich?
Was hier passiert, ist, dass man viel zu weitreichende Antworten erwartet, während man viel zu wenig Information liefert — nur einen einzelnen Lebenslauf, der fast schon auf dem Niveau von Rauschen liegt.
Das ist ein grundlegender Designfehler, unabhängig davon, ob ein LLM verwendet wird oder nicht. Jede Umfrage, Prüfung, jedes Gesetz und jedes Wahlsystem ist extrem sensibel für Framing, weil es mit zu wenig Information arbeitet. Nur existieren diese Dinge im Gegensatz zu diesem Konstrukt nicht im Vakuum.
Las-Vegas-Algorithmen sind nicht deterministisch, aber zu 100 % korrekt. Der Trade-off ist, dass die Zeit bis zur richtigen Antwort stark variieren kann.
Der Fehler hier ist nicht, dass ein nichtdeterministisches System verwendet wurde. In gewissem Sinn könnte der Fehler sogar sein, dass zu wenig davon verwendet wurde. Es ist ein nützlicheres Signal, denselben Lebenslauf fünfmal neu zu bewerten und zu sehen, dass die Streuung der Scores groß ist, als ihn nur einmal zu bewerten.
Jeder hat schon davon gehört, dass in der Stunde vor dem Mittagessen härtere Urteile gefällt werden.
Wenn man verhindern will, dass Leute den Filterprozess ausoptimieren, muss man ihn bis zu einem gewissen Grad nichtdeterministisch machen.
Zum Beispiel, indem man nicht hart bei den Top 100 abschneidet, sondern die Wahrscheinlichkeit, dass bessere Kandidaten den Filter passieren, exponentiell erhöht.
Dann lohnt es sich weniger, den Filterprozess im Goodhart-Stil anzugreifen. Die Wahrscheinlichkeit steigt kaum, und es gibt deutlich sinnvollere Wege, die eigene Zeit zu nutzen.
Wenn das Basismodell
gemma3:4bist, dann ist es ein extrem kleines ModellKein LLM ist ein perfekter und reproduzierbarer Richter, aber ein 4B-Modell in so ein System zu stecken, kommt fast dem Anschluss eines Zufallszahlengenerators gleich
Das ganze Experiment wirkt so, als hätte jemand ein Open-Source-ATS-Projekt bauen wollen, dann per Vibe-Coding ein ATS zusammengeschustert und es nur so weit gebracht, dass die Tests gerade eben durchlaufen
Es gibt wahrscheinlich Arten der Lebenslaufanalyse, die auch mit diesem Modell gut funktionieren würden. Aber sicher nicht nach dem Muster „Hey du Blechhaufen, an welchen Projekten hat diese Person gearbeitet?“
Man braucht Extraktion, Aufbereitung, vermutlich Vergleich über OCR und zusätzliche Aufbereitung, mehrere LLM-Analysen pro Signal, einen Evaluator usw.
Nichts davon müsste zwingend ein großes Modell sein. Mit einem großen Modell würde es vielleicht etwas besser werden, aber weil der Kontext sehr klein ist, können auch solche Modelle gut funktionieren, wenn man sie korrekt einsetzt
Ich habe das ATS selbst ausprobiert und ähnlich merkwürdige Erfahrungen gemacht
Es konnte mein GitHub-Profil nicht finden, deshalb landete ich bei einer Punktzahl in den 70ern, und danach mochte es einige bekannte Ruby-Bibliotheken, die ich gebaut habe, nicht
Nach mehreren Durchläufen begann es, das halbwegs richtig zu erkennen, aber bei formaler Bildung bekam ich immer Punktabzug
Das ist ekelhaft
Zertifizierungen oder Auszeichnungen hat es auch nicht erkannt. Ich habe ein paar PRs mit Verbesserungsvorschlägen von Leuten übernommen (https://github.com/Zem-0/hiring-agent); das hat zwar geholfen, aber insgesamt ist dieses ATS stark auf Leute mit umfangreichen GitHub-Open-Source-Beiträgen voreingenommen
Es hat mich immer überrascht, dass Tech-Unternehmen mehr als 300.000 Dollar zahlen, weil gute Ingenieure schwer zu finden sind, Recruiter aber faktisch ohne Unterstützung arbeiten und völlig unterschiedliche Maßstäbe dafür haben, was ein „guter Kandidat“ ist
ATS schicken wegen ihrer miserablen Filterheuristiken mehr als 50 % der Lebensläufe ins schwarze Loch, die Hiring-Teams haben das ATS aus Gründen wie Google-Gmail-Integration ausgewählt, und die Filtertechnik dieses ATS wurde nie von irgendjemandem im Engineering- oder Datenteam überprüft
Ich habe es mit meinem Lebenslauf versucht und somehow GSoC-Bonuspunkte bekommen
BONUS POINTS: 5.0------------------------------Google Summer of Code (GSoC) participation: +5Dabei habe ich nie an GSoC teilgenommen und das auch nicht in meinen Lebenslauf geschrieben
Bekannte Halluzination https://github.com/interviewstreet/hiring-agent/issues/240