Zwei optimierte RAG-Systeme befragen, um über 160 Bewerbungs-PDFs mit natürlicher Sprache zu durchsuchen. Erwartete Dauer: ca. 45 Minuten.
160 Fake-Lebensläufe wurden in zwei separate LightRAG-Instanzen hochgeladen. Version 1 und Version 2 unterscheiden sich: Eine nutzt die Standard-Einstellungen, die andere hat einen optimierten Embedding-Prozess (Chunk-Strategie, Normalisierung, Tokenisierung).
Retrieval-Augmented Generation (RAG) ist ein dreistufiger Prozess: (1) Relevante Dokumente aus einer Wissensbasis abrufen (Retrieve), (2) den LLM-Prompt mit diesem Kontext anreichern (Augment), (3) eine fundierte Antwort generieren (Generate). Die Qualität des Retrievals hängt direkt von der Embedding-Qualität ab.
| Version | URL |
|---|---|
| Version 1 | pizza-lightrag-1.aipizzasim.com/webui/ |
| Version 2 | pizza-lightrag-2.aipizzasim.com/webui/ |
Stellen Sie auf beiden Instanzen identische Query-Parameter ein, bevor Sie die Testfragen stellen:
| Parameter | Wert |
|---|---|
| Query Mode | hybrid |
| Response Format | Multiple Paragraphs |
| KG Top K | 10 |
| Chunk Top K | 20 |
| Max Entity Tokens | 6000 |
| Max Relation Tokens | 8000 |
| Max Total Tokens | 30000 |
| Enable Rerank | ✅ |
| Only Need Context | ☐ |
| Only Need Prompt | ☐ |
| Stream Response | ✅ |
hybrid setzen — nicht naive. Naive ignoriert den Knowledge Graph und verwässert den Vergleich.
Jede Frage wird auf beiden Instanzen mit identischen Parametern gestellt. Notieren Sie die Antworten.
| # | Frage | Was wird getestet |
|---|---|---|
| 1 | Wie viele Lebensläufe sind insgesamt im System gespeichert? | Vollständigkeit / Counting |
| 2 | Wie viele Personen besitzen einen Führerschein der Klasse B? | Attribut-Extraktion |
| 3 | Welche fünf Skills oder Kenntnisse kommen am häufigsten vor? | Aggregation über Dokumente |
| 4 | Wie viele Personen haben einen Hochschulabschluss (Bachelor, Master, Diplom)? | Kategorisierung / NER |
| 5 | Welche Person hat die meisten Jahre Berufserfahrung, und in welchem Bereich? | Entity-Linking + Ranking |
| 6 | Liste alle Personen auf, die sowohl Python als auch SQL erwähnen. | Multi-Attribut-Filter |
Tragen Sie die Antworten beider Versionen in die folgende Tabelle ein:
| # | Version 1 Antwort | Version 2 Antwort | Korrekt/Plausibel? | Qualitätsurteil |
|---|---|---|---|---|
| 1 | ___ | ___ | Tatsächlich: 160. RAG zeigt weniger (Top-K Limitation) | ___ |
| 2 | ___ | ___ | ___ | ___ |
| 3 | ___ | ___ | ___ | ___ |
| 4 | ___ | ___ | ___ | ___ |
| 5 | ___ | ___ | ___ | ___ |
| 6 | ___ | ___ | ___ | ___ |
Diskutieren Sie im Team die folgenden Fragen:
Frage 1 („Wie viele CVs?“) wird fast nie die korrekte Antwort 160 ergeben. RAG-Systeme retrieven nur die Top-K relevantesten Chunks (hier: KG Top K=10, Chunk Top K=20) — sie sehen also nie ALLE Dokumente auf einmal. Das ist eine fundamentale Eigenschaft von RAG: Es ist optimiert für Relevanz, nicht für Vollständigkeit. Für exakte Zählungen bräuchte man eine Datenbank-Abfrage, kein RAG.
| Parameter | Version 1 (Default) | Version 2 (Optimiert) |
|---|---|---|
| Entity Types | Keine gesetzt (LLM entscheidet frei) | Person, Age, Position, DrivingLicense, LicenseIssuingCountry, WorkExperience, Organization, Language, LanguageProficiency, Education, Location, Availability, Vehicle |
| Temperature (Retrieval) | 0.9 | 0.1 |
Explizite Entity Types sorgen dafür, dass der Knowledge Graph konsistent aufgebaut wird — z.B. wird „Führerschein Klasse B“ zuverlässig als DrivingLicense-Entity erkannt, statt vom LLM ignoriert zu werden. Niedrige Temperature (0.1) macht die Extraktion reproduzierbar: dieselbe Frage liefert (fast) immer dasselbe Ergebnis, statt bei jedem Durchlauf andere Entitäten zu extrahieren.
| # | Frage | Referenzantwort | RAG-typische Abweichung |
|---|---|---|---|
| 1 | Wie viele Lebensläufe insgesamt? | 160 | RAG antwortet typisch 10–30 (Top-K Limitation — sieht nie alle Dokumente) |
| 2 | Führerschein Klasse B? | 96 Personen | RAG findet nur einen Bruchteil; verschiedene Schreibweisen erschweren die Extraktion |
| 3 | Top-5-Skills? | 1. Defensives Fahren (~30) • 2. Kundeninteraktion (~28) • 3. Python (23) • 4. HACCP/Lebensmittelhygiene (~20) • 5. Routenoptimierung (~20) | RAG aggregiert schlecht über viele Dokumente; nennt oft nur Skills aus den Top-K Chunks |
| 4 | Hochschulabschluss? | ~47 Personen 4 PhD, 11 Master, 17 Bachelor, 15 Diplom |
RAG erkennt fremdsprachige Abschlüsse schlecht; „Hotel Management Diploma“ vs. Hochschul-Diplom ist ambig |
| 5 | Meiste Berufserfahrung? | Thomas Richter (#008) — 30 Jahre, Buchführung/Administration. Danach: Robert Schwarz (#042, ~28 J., ERP/IT), Giuseppe Ferrara (#036, ~27 J., Küche) | RAG findet selten die richtige Person; müsste alle CVs vergleichen |
| 6 | Python UND SQL? | 8 Personen: James Chen (#011), Natalia Ivanova (#041), Amélie Moreau (#045), Priya Sharma (#079), Sophie Dubois (#121), Raj Patel (#147), Wei-Lin Chou (#156), Felix Wagner (#160) | RAG findet meist nur 2–4; Multi-Attribut-Filter ist eine RAG-Schwäche |
Bei der Erstellung dieser Referenzantworten wurden zwei unabhängige KI-Instanzen (Claude Opus) eingesetzt: Eine las die CVs in 4 Gruppen à 40 Stück sorgfältig durch, die andere (Codex-Verifier) versuchte alle 160 auf einmal zu analysieren. Ergebnis: Der Codex-Verifier halluzinierte in mehreren Fällen — er behauptete z.B., Personen hätten SQL-Kenntnisse, obwohl deren CV kein SQL erwähnt, oder zählte Führerscheine bei Personen, die gar kein Führerschein-Feld im CV hatten. Die sorgfältigere Analyse (kleinere Batches, mehr Aufmerksamkeit pro CV) war in allen strittigen Fällen korrekt.
Lektion für die Praxis: Das gleiche Problem, das RAG-Systeme bei diesen Fragen haben — unvollständige Erfassung, falsche Zuordnung, Halluzination bei Aggregation — betrifft auch grosse Sprachmodelle direkt. Je mehr Dokumente auf einmal verarbeitet werden, desto höher das Halluzinations-Risiko. Teile-und-Herrsche (Dokumente in Gruppen aufteilen) liefert zuverlässigere Ergebnisse als alles auf einmal zu verarbeiten.