Veröffentlicht am 19 October 2026
Recruiting- und Personalvermittlungsfirmen erzeugen eine enorme Menge an internem Wissen, das meist nirgends durchsuchbar abgelegt ist. Die Notizen eines Recruiters aus einem Screening-Call, das Feedback einer Hiring Managerin dazu, warum ein Kandidat nicht weitergekommen ist, die eigenen Präferenzen eines Kandidaten zu Umzug oder Gehalt — all das landet typischerweise verstreut in Freitextfeldern eines Applicant Tracking Systems, E-Mail-Threads und im Gedächtnis einzelner Recruiter. Wenn Monate später eine ähnliche Stelle frei wird, fängt die Firma faktisch bei null an, obwohl vielleicht jemand im Team bereits einen starken Kandidaten für eine nahezu identische Position gescreent hat.
Das ist ein recht sauberer Anwendungsfall für Retrieval-Augmented Generation, denn das eigentliche Problem ist nicht, dass der Firma Daten fehlen — sondern dass die Daten unstrukturiert vorliegen, über mehrere Systeme verteilt sind und sich mit nichts präziserem als der Erinnerung eines Recruiters daran abrufen lassen, mit wem er gesprochen hat und wann.
Warum die ATS-Suche nicht ausreicht
Die meisten Applicant Tracking Systems unterstützen die Schlagwortsuche über Lebensläufe und Kandidatendatensätze. Das funktioniert bei strukturierten Feldern wie Skill-Tags, Berufserfahrung und Standort recht gut, scheitert aber an den nuancierten Informationen, die tatsächlich darüber entscheiden, ob sich ein erneut geführtes Gespräch lohnt. Eine Schlagwortsuche wird nicht sichtbar machen, dass ein bestimmter Kandidat in der Vergangenheit für eine ähnliche Rolle stark interviewt hat, ein Angebot aber wegen einer Gehaltslücke abgelehnt hat, die heute vielleicht gar nicht mehr relevant ist, oder dass ein Hiring Manager sehr konkrete, nicht generische Rückmeldungen dazu gegeben hat, wonach er jenseits der in der Stellenbeschreibung genannten Anforderungen wirklich gesucht hat.
Diese Informationen stehen in Gesprächsnotizen, Interview-Feedback und E-Mail-Zusammenfassungen, sind aber in natürlicher Sprache verfasst, uneinheitlich formatiert und für alles andere als einen Menschen, der sie liest, praktisch unsichtbar. Ein Recruiter mit langer Betriebszugehörigkeit und gutem Gedächtnis kann das manchmal manuell rekonstruieren. Ein Recruiter, der neu in der Rolle ist, oder eine Firma, die dieses Wissen dem gesamten Team zugänglich machen will, statt es in einzelnen Köpfen zu belassen, kann das nicht.
Was ein RAG-System hier leistet
Die sinnvolle Architektur ist eine Retrieval-Schicht über den historischen Kandidateninteraktionen der Firma, kombiniert mit einem Sprachmodell, das spezifische Fragen beantwortet, die auf diesem abgerufenen Inhalt beruhen, statt Antworten aus allgemeinem Wissen zu generieren. Wenn ein Recruiter eine neue Vakanz öffnet, beginnt er also nicht bei null mit der Suche, sondern kann eine echte Frage stellen: Kandidaten, die im letzten Jahr für eine ähnliche Backend-Engineering-Rolle stark waren, aber ein Angebot wegen der Vergütung abgelehnt haben, oder Kandidaten, die für eine Rolle in Clinical Operations gut interviewt haben, aber aus Gründen, die nichts mit ihrer fachlichen Eignung zu tun hatten, nicht ausgewählt wurden.
Das System ruft die konkreten Interaktionen ab, die für diese Frage tatsächlich relevant sind — nicht nur Keyword-Treffer, sondern semantisch ähnliche frühere Gespräche — und das Sprachmodell fasst zusammen, was es gefunden hat, mit Verweisen auf die Quelldatensätze. So kann der Recruiter die Zusammenfassung anhand der tatsächlichen Notizen prüfen, statt ihr blind zu vertrauen. Dieser Grounding-Schritt ist entscheidend: Ein System, das plausible Zusammenfassungen erzeugt, ohne sie mit realen Datensätzen zu verknüpfen, ist im Recruiting ein Risiko, denn wenn die Historie eines Kandidaten falsch dargestellt wird, hat das reale Folgen sowohl für die Beziehung zum Kandidaten als auch für die Glaubwürdigkeit der Firma gegenüber einem Hiring Manager.
Datenquellen und die Arbeit, sie nutzbar zu machen
Der schwierige Teil eines solchen Projekts ist selten die Retrieval-Architektur selbst — es ist vielmehr, die zugrunde liegenden Daten in einen nutzbaren Zustand zu bringen. Gesprächsnotizen sind oft je nach Recruiter, der sie verfasst hat, inkonsistent in Format und Qualität. Interview-Feedback kann in einem anderen System als dem ATS liegen. E-Mail-Threads müssen so geparst werden, dass der relevante Inhalt von Terminabstimmungen und anderem Rauschen getrennt wird. Bevor ein Retrieval-System sinnvoll ist, braucht es meist eine wichtige Phase der Datenkonsolidierung und -bereinigung: das Ziehen von Daten aus dem ATS, E-Mail und anderen Systemen, in denen Kandidateninteraktionen dokumentiert sind, die Normalisierung von Formaten und in manchen Fällen den Einsatz eines Sprachmodells, um chaotische historische Notizen in eine konsistentere Struktur zu überführen, bevor sie für die Suche indexiert werden.
Genau hier sind Zugriffsrechte noch wichtiger als in einer typischen internen Wissensdatenbank. Kandidatendaten sind sensibel, und eine Recruiting-Firma, die mit mehreren Kunden arbeitet, muss sicherstellen, dass das Retrieval alle bestehenden Vertraulichkeitsgrenzen zwischen Kundenkonten respektiert. Ein Kandidat, der für einen Kunden vertraulich gescreent wurde, darf nicht in einem Retrieval-Ergebnis für eine fachfremde Suche eines anderen Teams auftauchen, und das System muss diese Grenze auf Datenebene durchsetzen, statt sich darauf zu verlassen, dass Recruiter sich merken, wonach sie nicht schauen sollen.
Das System aktuell halten
Eine Wissensdatenbank wie diese ist kein einmaliges Projekt — sie braucht fortlaufend neue Kandidateninteraktionen, sonst veraltet sie und verliert den Wert, für den sie aufgebaut wurde. Das bedeutet in der Regel eine Ingestion-Pipeline, die neue Gesprächsnotizen, Feedback-Formulare und E-Mail-Zusammenfassungen kontinuierlich aufnimmt, verarbeitet und indexiert und sie für die Suche bereitstellt, ohne dass Recruiter dafür mehr tun müssen als die Notizen, die sie im Rahmen ihres normalen Workflows ohnehin bereits erfassen. Das Ziel ist, das System zu einem Nebenprodukt der bestehenden Arbeit zu machen, nicht zu einer zusätzlichen Aufgabe, die obendrauf kommt.
Häufige Stolpersteine, die man einplanen sollte
Der häufigste Fehler bei einem System wie diesem besteht darin, das Retrieval-Ergebnis als fertige Antwort zu behandeln statt als Ausgangspunkt für eine menschliche Entscheidung. Eine Zusammenfassung vergangener Kandidateninteraktionen ist gerade deshalb nützlich, weil sie Recruiter schnell zu den ursprünglichen Notizen zurückführt; sie wird in dem Moment unbrauchbar und sogar riskant, in dem Recruiter die generierte Zusammenfassung ohne Prüfung der Quelle für maßgeblich halten. Quellen sichtbar und leicht öffnbar zu halten, statt sie hinter einem generischen „Quellen“-Link zu verstecken, macht einen spürbaren Unterschied darin, ob Recruiter tatsächlich prüfen, was sie lesen.
Ein zweiter Stolperstein ist Datenspeicherung und Einwilligung. Kandidatendaten haben eine begrenzte Lebensdauer, und viele Rechtsräume sowie Kundenvereinbarungen setzen Grenzen dafür, wie lange bestimmte Kandidateninformationen aufbewahrt oder erneut genutzt werden dürfen, insbesondere bei Kandidaten, die nicht eingestellt wurden. Ein Retrieval-System, das auf historischen Interaktionen aufbaut, muss alle bereits geltenden Aufbewahrungs- und Löschrichtlinien respektieren. Das bedeutet, dass der Retrieval-Index mit Löschungen in den Quellsystemen synchron gehalten werden muss, statt zu einer zweiten, vergessenen Kopie von Daten zu werden, die eigentlich entfernt werden sollten.
Ein dritter Stolperstein ist der Aktualitätsbias. Weil aktuelle Interaktionen naturgemäß zahlreicher und detaillierter sind als ältere, kann ein Retrieval-System unbeabsichtigt erst kürzlich gescreente Kandidaten gegenüber ebenso starken Kandidaten aus weiter zurückliegenden Zeiträumen bevorzugen — einfach weil dort mehr Text zum Abrufen vorhanden ist. Das Retrieval so zu justieren, dass Relevanz stärker gewichtet wird als Aktualität, statt standardmäßig die neuesten Datensätze zu bevorzugen, erfordert meist bewusste Aufmerksamkeit und passiert nicht automatisch.
Wo das Mehrwert schafft
Der klarste Return eines Systems wie diesem zeigt sich in kürzeren Time-to-Fill-Werten bei Rollen, die bereits früher besetzte Positionen ähneln, sowie in weniger verpassten Chancen, starke Kandidaten erneut anzusprechen, die für eine frühere Rolle nicht passend waren, aber für eine aktuelle sehr wohl geeignet sind. Dazu kommt ein weniger offensichtlicher Vorteil: Es reduziert den Verlust von internem Wissen, der entsteht, wenn ein erfahrener Recruiter das Unternehmen verlässt, weil ein wesentlicher Teil dessen, was ihn effektiv gemacht hat, abrufbare Historie war, die sonst mit ihm aus der Tür geht.
Wenn Ihr Team über Jahre an Kandidateninteraktionshistorie verfügt, die faktisch nicht durchsuchbar ist, lohnt es sich, zunächst einzugrenzen, wie ein Retrieval-System über diese Daten konkret aussehen würde, bevor Sie sich auf einen größeren Aufbau festlegen. Die übergeordneten Architekturthemen behandeln wir auf unserer Seite zu RAG und Enterprise-Wissenssystemen, den branchenspezifischen Recruiting-Kontext auf unserer Seite für AI-Software für Recruiting und Personalvermittlung. Wenn Sie besprechen möchten, was das für die Systeme Ihres Unternehmens konkret bedeuten würde, starten Sie mit uns ein Projektgespräch.
Verwandt