Besseres Retrieval am Beispiel AI-Staffing: Late Interaction Retrieval, Cross-Encoder und LLMs im Vergleich

In diesem Blogpost schauen wir uns an, wie man ein Dokumenten-Retrieval-System durch verschiedene Ansätze verbessern kann. Das zeigen wir anhand eines internen Beispiels, bei dem es beim Staffing um das Matching von Projektbeschreibungen mit den passendsten Kandidat:innen geht. Wir betrachten Late Interaction Retrieval als eine Alternative oder Ergänzung zu Standard Embeddings sowie Cross-Encoder für präziseres Scoring. Zusätzlich schauen wir auf LLM-basierte Zusammenfassungen und strukturierte Informationsextraktion, ergänzt durch einen LLM-as-a-Judge Mechanismus zur Qualitätssicherung. Zum Schluss betrachten wir listenweises LLM-basiertes Reranking für die finale Auswahl passender Kandidat:innen. Diese Prinzipien lassen sich gut auf andere Anwendungsfälle übertragen, wie AI Agents, die auf einem RAG-System operieren.

Einleitung und Hintergrund

Im Folgenden stellen wir Erweiterungen unseres internen AI-Staffing-Projekts vor, das bereits unsere Kollegin Laura Weber in ihrem Blogpost zu Textembeddings & Vektorsuche vorgestellt hat.

Kurz zusammengefasst geht es darum, auf Basis gegebener Projekt- oder Stellenbeschreibungen die jeweils passendsten Berater:innen zu finden. Je nach Chunking erfolgt die Suche entweder auf Ebene ganzer CVs oder auf Ebene einzelner Projekte innerhalb eines CVs. Die nachfolgenden Verbesserungsmethoden lassen sich auch auf andere Problemstellungen anwenden, bei denen es um Retrieval bzw. die Suche der relevantesten Dokumente zu einer gegebenen Query geht. Ein wichtiger Anwendungsfall sind hier Retrieval-Augmented Generation-Systeme (RAG-Systeme) für Large Language Models (LLMs) im Rahmen von Generative AI (GenAI) Anwendungen.

Verbesserungen entstehen nicht nur auf Modellebene, sondern auch im Preprocessing. Dazu gehören geeignete Tools zur Verarbeitung unterschiedlicher Dokumententypen und in vielen Fällen auch ein OCR-Schritt (Optical Character Recognition). Einige CVs lieferten beispielweise leere oder fast leere Inhalte nach der Textextraktion, da es sich tatsächlich nicht um Freitext, sondern um Bilder gehandelt hat, in denen der Text eingebettet war. Der Hauptfokus ist aber die modellbasierte Erweiterung. Hierzu schauen wir uns zuerst die Begrenzungen von Einzelvektor-Embedding-Modellen an, wie sie in Retrieval-Systemen meist zum Einsatz kommen.

Motivation: Die Beschränkungen von Einzelvektor-Embeddings

Wenn im Retrieval-Kontext von Embeddings die Rede ist, sind meist Einzelvektor-Embeddings gemeint. Oft wird auch von „Dense Embeddings“ gesprochen, weil ein Textabschnitt in einen einzelnen dichten Zahlenvektor kodiert wird, der den Inhalt der Textpassage auch semantisch zusammenfasst. Dies passiert separat für Query (Projektbeschreibung) und Kandidat:innen-Dokumente (CVs bzw. Projekte aus CVs). Genau darin liegt eine zentrale Grenze dieses Ansatzes: Bei der Kompression in einen einzigen Vektor kann relevante Information verloren gehen. Query und Dokument werden zunächst unabhängig voneinander encodiert. Erst danach vergleicht man die erzeugten Embedding-Vektoren über eine Ähnlichkeitsberechnung wie die Cosine-Similarity. Man spricht deshalb in diesem Zusammenhang auch von Bi-Encodern. Gerade in diesem Use Case, aber auch bei anderen wie z. B. im medizinischen oder rechtlichen Bereich, kommt es stark auf einzelne Schlüsselbegriffe an, die in einem einzelnen Embedding -Vektor leicht untergehen können. Am Ende repräsentiert nur ein einziger Vektor den gesamten Dokumententeil.

Tatsächlich gibt es sogar fundamentale, theoretische Begrenzungen von Einzelvektor-Embedding-Methoden, die sich auch durch die Erhöhung der Embedding-Dimension nicht wirksam vermeiden lassen, wie in einem Google Paper zu theoretischen Limitierungen gezeigt wurde. Diese theoretischen Grenzen sind in der Praxis nicht immer der entscheidende Punkt. Relevanter sind oft die getrennte Encodierung von Query und Dokument und der Verlust wichtiger Keywords. Der Punkt mit den Schlüsselwörtern ist ein Grund, warum in Anwendungen (z. B. mit Databricks: https://docs.databricks.com/aws/en/vector-search/query-vector-search) oftmals eine hybride Suche zum Einsatz kommt, die auch Keyword-based Search beinhaltet. Im Folgenden schauen wir uns noch eine andere Möglichkeit an.

Multivektor-Embeddings und Late Interaction Retrieval

Die im letzten Abschnitt genannten Punkte sind entscheidende Motivationen zur Einführung von Multivektor-Embedding-Methoden. Ein wichtiges Beispiel dieser Art sind Late Interaction Retrieval Methoden, insbesondere Varianten von ColBERT (siehe https://arxiv.org/pdf/2004.12832 für das ursprüngliche Paper, inzwischen gibt es einige Erweiterungen).

Die Kernidee ist Folgende: Anstatt die Token-Embeddings früh im neuronalen Netz in einen Vektor zusammenzuführen, werden sie zwar kontextualisiert, aber als Entitäten beibehalten. Dies ermöglicht anschließend Ähnlichkeitsberechnungen auf dieser granularen Ebene. Late Interaction Retriever propagieren dabei Token-Embeddings von Projekt- bzw. Stellenbeschreibung und CVs durch separate Encoder getrennt und unaggregiert bis zum Scoring ans Ende des neuronalen Netzwerks. Dadurch kann das Modell die jeweilige Projektbeschreibung und CV-Informationen auf Token-Embedding-Ebene vergleichen. Dies ist einer Keyword-Suche ähnlicher, aber enthält dennoch semantische Informationen.

Für dieses Scoring am Ende gibt es einen „Late Interaction Head“ im neuronalen Netzwerk. Bei ColBERT und dessen Varianten geschieht das über den MaxSim Operator. Für jedes feste Token der Query (Projekt-/Stellenbeschreibung) wird das Dokument-Token (wie z. B. ein Projekt in einem CV) gesucht, das die höchste Ähnlichkeit aufweist. Die Ähnlichkeitsberechnung ergibt sich aus dem Innenprodukt der jeweiligen finalen Token-Embedding-Vektoren. Anschließend werden diese gefundenen Ähnlichkeiten über alle Query-Tokens aufsummiert oder gemittelt, was einen Gesamtscore ergibt, der die Ähnlichkeit zwischen der Stellenbeschreibung und des jeweiligen CVs (bzw. einem Projekt aus dem CV) widerspiegelt. Da diese Berechnung pro Stellenbeschreibung für alle CVs oder (CV, Projekt aus CV)-Paare erfolgt, kann man diejenigen Personen mit den höchsten Scores als die potenziell relevantesten Kandidat:innen betrachten.

Ein Beispiel aus dem AI-Staffing

War das zu abstrakt? Ein konkretes Beispiel hilft weiter. Für die exemplarische Stellenbeschreibung „Wir suchen einen Senior Data Scientist mit viel Erfahrung im Umgang mit Sensordaten und Robotik“ sehen wir in der folgenden Grafik in der linken Spalte zunächst eine Zerlegung dieser Anfrage in einzelne Tokens. Für jedes gegebene Query-Token der Stellenbeschreibung sehen wir dann in der zweiten Spalte das Token mit der höchsten Ähnlichkeit aus der passendsten Projektbeschreibung. Oftmals ist das ähnlichste Token aus dem jeweiligen Projekt im CV gleich zum jeweiligen Token der Stellenbeschreibung.

Es gibt aber auch einige Ausnahmen (wie „such“ und „so“ in der dritten Zeile). Die dritte Spalte ist für die Berechnung nicht entscheidend, veranschaulicht aber das Umfeld des ähnlichsten Tokens im CV-Projekt. Die letzte Spalte gibt die Ähnlichkeit zwischen dem Query-Token und dem ähnlichsten Token des CV-Projekts an. Der Mittelwert dieser letzten Spalte ergibt den Gesamtähnlichkeitsscore für das Projekt aus dem CV zur Stellenbeschreibung. Wenn man dies für alle Projekte aus den CVs macht und für das Projekt mit dem höchsten Score die jeweilige Person ermittelt, erhält man dementsprechend die vermutlich passendsten Kandidat:innen.

In dieser Grafik wurde bereits aus dem Pool aller (CV, Projekt)-Paare das Projekt mit dem höchsten Gesamtscore gefunden und abgebildet. Der Kandidat oder die Kandidatin mit dem zugehörigen CV kann demnach als die vermutlich geeignetste Person angesehen werden. Im Beispiel tragen insbesondere Tokens wie „senior“, „sensor“ und „robot“ stark zum Gesamtscore bei. Das zeigt gut, warum der Ansatz für diesen Use Case sinnvoll ist.

‍

Stärken und Schwächen des Ansatzes

In diesem Beispiel werden bereits einige Vorteile dieses Ansatzes deutlich: Durch die Ähnlichkeitsberechnung auf Token-Embedding-Ebene ist die Methode im Vergleich zu anderen Embedding-Methoden gut interpretierbar und kann oftmals auch eine höhere Genauigkeit erzielen. Das liegt auch daran, dass die Betrachtung auf Token-Embedding-Level Ähnlichkeiten zu einer erweiterten Keyword-Suche aufweist und dadurch wichtige Schlüsselworte nicht so leicht untergehen.

Allerdings gibt es auch Nachteile: Vor allem der Speicherbedarf ist deutlich höher als bei klassischen Einzelvektor-Methoden. Erweiterungen von ColBERT wie ColBERTv2 versuchen diesem Problem bedingt entgegenzutreten. Auch ist es möglich, Late Interaction Retrieval nur als Verfeinerung eines vorherigen anderen Retrieval-Systems zu nutzen. Hinzu kommt ein möglicher Bias zugunsten längerer CVs oder Projektbeschreibungen mit viel Prosa: Weniger relevante Tokens können zufällig einen höheren Ähnlichkeitsscore bewirken. Dies sieht man in obiger Grafik z. B. am Score des Tokens „eine“, welches an sich keine Relevanz hat. Dies sind Gründe, nicht mit Late Interaction Retrieval aufzuhören, sondern auch weitere Verfahren einzusetzen.

Cross-Encoder

Sowohl Standard Einzelvektor-Embedding-Methoden als auch Multivektor-Embedding-Methoden encodieren alle Dokumententeile in der Datenbank unabhängig von den Queries. Erst wenn alle Embedding-Vektoren der Projektbeschreibungen aus den CVs und der Stellenbeschreibungen erzeugt wurden, können sie im Rahmen einer Vektorähnlichkeitsberechnung miteinander verglichen werden. Naheliegend ist deshalb die Frage: Warum nicht ein Projekt direkt in Beziehung zur Stellenbeschreibung bewerten? An dieser Stelle kommen Cross-Encoder ins Spiel.

Cross-Encoder vergleichen eine Stellenbeschreibung und einen CV bzw. ein Projekt aus dem CV simultan, indem sie beide gemeinsam in encodierter Form durch ein neuronales Netz „schieben“. Auf dieser Basis geben sie einen Score aus, der ebenfalls eine Ähnlichkeit widerspiegelt, aber bei der beide Texte in den Prozess eingegangen sind und nicht erst die getrennten Endergebnisse miteinander verglichen werden. Dies weckt die Hoffnung, dass man dadurch genauere Ergebnisse erzielen kann als bei Embeddings, welche zuerst unabhängig gebildet und anschließend abgeglichen (bzw. deren Ähnlichkeit berechnet) werden. Schließlich können auf diese Weise feingranulare Zusammenhänge zwischen Stellenbeschreibung und CV-Projekt besser abgebildet werden.

Wie gut Cross-Encoder im Use Case funktioniert haben

Im AI-Staffing-Projekt lieferten Cross-Encoder plausible Ergebnisse, Late Interaction Retrieval war in unserem Fall allerdings noch präziser. Jedoch ist dies auch abhängig von den konkreten (vortrainierten) Modellen und problemspezifischen Anforderungen. Auch durch die starke Abhängigkeit von Keywords in diesem Anwendungsszenario ist dieser Ausgang erklärbar. Viele andere Anwendungsfälle können zugunsten von Cross-Encodern ausfallen, ebenso ist oftmals eine Architektur mit beiden Arten in Kombination interessant.

Warum Cross-Encoder meist erst im zweiten Schritt zum Einsatz kommen

Die oft höhere Genauigkeit hat allerdings ihren Preis: Cross-Encoder sind deutlich rechenintensiver. Sie skalieren nicht linear mit der Eingabelänge, sondern oftmals quadratisch. Außerdem muss die gemeinsame Encodierung für jede Stellenbeschreibung und jedes CV-Projekt Paar erneut erfolgen. Aus diesem Grund bieten sie sich als Verfeinerung bzw. Reranker in einem zweiten Schritt an, nach einer Vorauswahl durch eine Einzelvektor-Embedding-basierte Suche (Bi-Encoder) oder Late Interaction Retrieval. In diesem Fall wird die Anzahl an notwendigen Scorings durch Cross-Encoder begrenzt.

Ebenso ist es hilfreich, bei Cross-Encodern aus Performancegründen die Länge der Inputtexte (Stellenbeschreibung und Projektbeschreibung aus CV) zu begrenzen. Einige Cross-Encoder können auch nur mit vergleichsweise kleinen Inputs umgehen (begrenzte Kontextlängen). Da kürzere Texte die Laufzeit senken und der Längenbeschränkung entgegenwirken, führt uns dies als eine der Motivationen direkt zum nächsten Ansatz.

Strukturierte LLM-basierte Textzusammenfassungen und Informationsextraktion

LLMs bieten nicht nur hinsichtlich der Kontextlängenbegrenzung Vorteile gegenüber Cross-Encodern. Sie können CVs auch qualitativ so verdichten, dass nachgelagerte Modelle präziser arbeiten:

• Kürzere CVs oder CV-Projektbeschreibungen steigern die Effektivität der darauf operierenden Modelle, sowohl durch Steigerung der Effizienz (weniger Text als Input), als auch der damit verbundenen niedrigeren Kosten.
• Die Genauigkeit kann erhöht werden, da der Fokus auf dem Wesentlichen liegt und unnötige Füllwörter rausgekürzt werden.
• Eine einheitliche Sprache und Struktur verbessert die Vergleichbarkeit unterschiedlicher CVs, was ebenfalls zu einer höheren Genauigkeit führt.
• Mit gutem Prompt Engineering lassen sich die Zusammenfassungen gezielt auf den Use Case ausrichten, etwa auf typische Anforderungen im Data-, AI- und Beratungskontext.
• Zusammen mit den kurzen Textbeschreibungen können auch wichtige Keywords, Ratings usw. extrahiert werden.
• Frontier LLMs mit hohem Reasoning-Aufwand wie zum Beispiel von OpenAI können dabei auch komplexe Zusammenhänge, Analoga und implizite Erfahrungen zuverlässig verdichten. Da diese Zusammenfassungen nur in bestimmten zeitlichen Abständen erfolgen müssen (nach CV-Updates) und gecached werden können, halten sich auch die Kosten in Grenzen.

Wie LLM-as-a-Judge die Qualität absichert

Um die Qualität weiter zu erhöhen, kann in einem zweiten Schritt ein weiteres LLM als Judge eingesetzt werden. Dieses Modell nimmt ebenfalls die Persona von HR und fachlichen Experten ein, gleicht die erzeugten Zusammenfassungen mit den CVs ab, bewertet sie anhand definierter Kriterien und verbessert sie bei Bedarf. So lassen sich fehlende Informationen, unklare Formulierungen oder Halluzinationen leichter erkennen. In diesem Schritt ist beispielsweise aufgefallen, dass in manchen Projektbeschreibungen bereits in den Ausgangs-CVs (Rohdaten) bestimmte Keywords gefehlt haben, die dann anhand der Freitextangaben automatisch ergänzt wurden.

Da die Ergebnisse dieser Zusammenfassungen zur Verbesserung der finalen Outputs wiederum als Input in nachgelagerte Ranking-LLMs fließen, kann man dies auch als eine Form des Context Engineerings sehen.

Technische Umsetzung mit strukturierten Outputs

Als Technologie für diese Umsetzung bietet sich das Instructor Python-Package an. Dies erlaubt besonders gute Zusammenfassungen und Extraktionen in ein strukturiertes Format, z. B. JSON-Objekte mit vordefinierten Feldern, welche wiederum als Basis zum Aufbau einer NoSQL-Datenbank wie MongoDB dienen können. Dazu können entsprechende Datenklassen für CVs und Projekte mit Beschreibungen der einzelnen Felder (wie z. B. Gesamterfahrung in Jahren in einem Bereich oder für einen Skill) angelegt werden, wonach sich die aufgerufenen LLMs richten sollen. Das Package baut auf Pydantic Validierungen auf, um konsistente Typen sicherzustellen. Verletzt ein LLM-Call ein Schema, können automatisierte Neuversuche gestartet werden, um eine hohe Qualität zu gewährleisten.

In der folgenden Grafik sehen wir ein Beispiel, wie solche Zusammenfassungen und Extraktionen aussehen können. Tatsächlich hat man so auch die Flexibilität, die nachgelagerten Methoden wie Late Interaction Retriever, Cross-Encoder usw. auf eines der anderen Felder anzuwenden, z. B. Keyword-basierte Bewertungen auf Basis der Erfahrungsdauer mit Methoden oder Technologien. Ebenso ist es möglich, auch für die Stellenbeschreibungen Zusammenfassungen zu generieren und auf diesen zu operieren.

‍

LLM-basiertes Reranking von Kandidatenlisten

LLMs sind nicht nur für Zusammenfassungen und Extraktionen interessant, sondern auch für einen letzten Schritt in der Pipeline: Reranking.

Warum können LLMs als Reranker besonders stark sein? Während Cross-Encoder wie besprochen zwar sowohl die jeweilige Stellenbeschreibung als auch einen CV (bzw. eine Projektbeschreibung eines CV oder ein anderes Feld aus der CV-Zusammenfassung der jeweiligen Kandidat:innen) berücksichtigen, ist dies eben auf ein solches CV-Dokument begrenzt. Mit LLM-basierten Rerankern, die auf Listenebene operieren, kann man noch einen Schritt weiter gehen. Hiermit ist es möglich, zu einer Stellenbeschreibung nicht nur ein CV-Dokument zum Scoring zu übergeben, sondern eine größere Liste an möglichen Kandidat:innen. Dadurch hat das Modell mehr Kontext und bewertet Kandidat:innen nicht isoliert, sondern im direkten Vergleich. Genau das kann die Qualität des Rankings verbessern.

Hinzu kommt, dass den LLMs zusätzliche Nebeninformationen in den Kontext übergeben werden können. Dies erhöht die Qualität weiter, da State-of-the-Art LLMs mit so vielen Parametern und Daten trainiert wurden, dass sie oftmals auch sehr komplizierte Zusammenhänge besser durchschauen können. Zum Beispiel können sie die Erfahrung mit Schlüsseltechnologien in Relation zu unterschiedlichen Projekten setzen, die von verschiedener Dauer und Relevanz zur Technologie waren.

Vor- und Nachteile von Rerankings

Außerdem können LLMs ihr Ranking begründen. Man schreibt dem LLM-Reranker vor, nach welchen Kriterien es zu ranken hat und liefert neben einer Stellenbeschreibung eine Menge an relevanten CV-Dokumenten, die es nach Relevanz ordnen und sein Vorgehen dabei begründen soll. Das erhöht die Transparenz und erleichtert die fachliche Überprüfbarkeit und Interpretierbarkeit. Auch kann hier ebenfalls LLM-as-a-Judge zum Einsatz kommen.

Die Nachteile von LLM-basiertem Reranking liegen in der höheren Laufzeit, den Kosten und den möglichen Grenzen des Context Windows.

Deshalb eignen sie sich in aller Regel nur für den letzten Schritt zum Reranken einer bereits selektierten Vorauswahl statt der gesamten Menge an Kandidat:innen. Dies begrenzt die Laufzeit und die Kosten.

So kann eine mehrstufige Retrieval-Pipeline aussehen

In der Praxis kann eine solche Pipeline in vier Schritten aufgebaut sein:

1. Preprocessing und automatisierte LLM-Zusammenfassungen
2. Erste Vorauswahl mit Late-Interaction-Retrieval-System (und optionalen Standard Embeddings zuvor)
3. Verfeinerung der größeren Vorauswahl durch Cross-Encoder
4. Finales LLM-basiertes Reranking

Die im letzten Schritt erzeugte Liste gibt an, welche Kandidaten zu einer gegebenen Stellenbeschreibung am besten passen und warum. Die nachstehende Grafik zeigt ein Beispiel, wie ein solches Endergebnis aussehen kann.

‍