Wenn die Zitate perfekt aussehen, aber die Anzahl der Personen immer noch falsch ist
Ein Gehaltsbericht zitierte das falsche PDF und zählte dennoch zwölf Mitarbeiter als einen – hybride Suche, kompressionsfähige Tabellenverarbeitung sowie Pipeline-Überwachung behoben das Problem.
Eine Frage zur Lohnabrechnung sollte langweilig sein. Wenn man nach der Anzahl der Personen im Lohnverzeichnis vom April 2025 fragt, erwartet man eine Zahl, einen Verweis – und nichts Besonderes. Die Systemausgabe war jedoch eine präzise Formulierung: ein Mitarbeiter, Quell-PDF benannt, Seite geprüft. Im Verzeichnis standen jedoch zwölf Personen.
Genau dieses Versagen macht die durch Suchfunktionen erweiterte Generierung in der Praxis gefährlich. Der Prozess stürzte nicht ab; die Protokolle blieben still. Die Antwort sah aus wie jede andere richtige Antwort derselben Woche. Ein sanftes Versagen mit Fußnote ist schlimmer als ein totaler Absturz, denn niemand behandelt einen höflichen Absatz als ernsthafte Störung.
Dieser Text rekonstruiert den Ablauf, der die Lüge hervorbrachte, die Diagnosen, die sie aufdeckten, sowie die konkreten Änderungen, die die Anzahl wieder auf zwölf brachten. Die verwendeten Tools sind absichtlich gewöhnlich: pdfplumber für PDF-Texte mit Layoutinformationen, ein LangChain-Textteiler nur zum Aufteilen in Abschnitte, MiniLM-Einbettungen, Qdrant für Vektoren, eine hybride Suchmethode aus dichter Suche und BM25, ein Cross-Encoder zur Neubewertung der Ergebnisse sowie ein Kompressor, der den Kontext vor dem Ausführen des Generators komprimieren sollte. Keine dieser Wahlmöglichkeiten war außergewöhnlich. Die Probleme lagen in der Weise, wie diese Tools bei Tabellen und Identifikatoren miteinander interagierten.
Eine einmalige Eingabe, ständige Antworten
Dokumente werden nur einmal eingegeben. Fragen kommen ständig neu. Es ist wichtig, diese Prozesse voneinander zu trennen, wenn man Fehler behebt – schließlich kann eine fehlerhafte Antwort auf veraltete Vektoren, schlechte Filter oder einen Generator zurückzuführen sein, der die richtigen Datensätze nie gesehen hat.
Ingestion durchläuft jedes PDF, extrahiert den Text unter Berücksichtigung der Layoutstruktur, teilt ihn in überschneidende Abschnitte auf, fügt sie ein und speist sie zusammen mit Metadaten in Qdrant ein, die später von Filtern verwendet werden können:
PDF → extract text per page → cut into chunks
→ convert each chunk to 384 numbers → store in a vector database
Die Beantwortung erfolgt über ein anderes Verfahren: Die Frage wird eingebettet, Kandidaten abgerufen, gegebenenfalls Schlüsselworttreffer kombiniert, neu rangiert und komprimiert, anschließend wird das Modell mit beigefügten Zitaten befragt:
question → search → rerank → compress → ask the LLM → cited answer
↓ ↓ ↓
5 chunks 3 chunks ~600 chars
Im theoretischen Rahmen ist dieser Ablauf ein Standardbeispiel. In der Praxis versagen die in Lehrbüchern beschriebenen Annahmen bei Personalregistern, Rechnungstabellen sowie allen Dokumenten, deren Antwort eher eine Struktur als ein Slogan ist.
Warum jeder Bestandteil seinen Platz verdient hat
pdfplumber ist nicht die schnellste PDF-Bibliothek. Sie gehört zu den wenigen, die genügend Layout-Informationen beibehalten, damit die Gehaltszeilen nicht in einen einzigen Absatz verschmelzen. Schnellere Extraktoren, die Tabellen in zusammenhängende Sätze umwandeln, machen spätere Fragen wie „Wie viele Mitarbeiter gibt es?“ nahezu unmöglich, da das Modell die Zeilengrenzen nie wahrnimmt.
Zur Aufteilung des Textes wurde im Rahmen dieses Projekts ausschließlich LangChains rekursiver Zeichenseparator verwendet – kein anderes Element des Frameworks. Das Ziel waren vorhersehbare, überlappende Fenstergrößen, nicht eine vorgefertigte RAG-Kette. Nach einer kurzen Vergleichsphase wurde all-MiniLM-L6-v2 als Embedding ausgewählt: Kleinere Modelle überließen Identifikator-Tokens, größere Modelle verursachten Verzögerungen, ohne das eigentliche Problem zu beheben. Qdrant setzte sich durch wegen der Kontinuität von lokalen zu cloudbasierten Systemen sowie wegen Payload-Filtern, die mit der bereits vorhandenen Dokumenttyp-Klassifizierung des Apps übereinstimmten.
Die hybride Suche kombinierte semantische Ähnlichkeit mit einem Schlüsselwort-Score im BM25-Stil in einem Verhältnis von etwa 0,65 zu 0,35. Die reine semantische Suche war hervorragend bei der Frage „Was ist die Elternzeitrichtlinie?“ und katastrophal bei STL/2025-26/003. Eine Neubewertung mithilfe eines Cross-Encoders bereinigte die Shortlist. Die Kompression sollte sicherstellen, dass vor dem Aufruf des LLM nur Sätze mit hoher Relevanz verwendet wurden. In dieser letzten Phase begann eigentlich die Geschichte, wie aus zwölf Ergebnissen eines wurde.
Die selbstsichere falsche Antwort
Zur Frage nach dem Gehalt wurde eine plausibel erscheinende Seite gefunden und zitiert, wobei die Anzahl der relevanten Ergebnisse unterschätzt wurde. Ein Blick auf die Roh-Scores zeigte bereits den ersten Fehler: Die semantischen Nachbarn schienen „ausreichend nah“ zu sein, während die exakt passenden Einträge im Vergleich zur erzählerischen HR-Prosa in anderen Teilen des Korpus schlecht abschnitten.
0.781 Invoice_INV2025001_Arvind.pdf <- returned
0.779 Invoice_INV2025002_Trident.pdf
0.776 Invoice_INV2025003_Welspun.pdf <- actually wanted
Die Ähnlichkeitsberechnung kann nicht dazu verwendet werden, eine exakte Tokenverarbeitung durchzuführen. Durch Hinzufügen von BM25 sowie Mischen der Scores änderte sich die Rangliste, sodass die Identifikatoren sowie die mit Tabellen versehenen Abschnitte an Bedeutung gewannen:
0.854 Invoice_INV2025003_Welspun.pdf <- correct
0.549 Invoice_INV2025001_Arvind.pdf
0.545 Invoice_INV2025002_Trident.pdf
Allein dadurch wurde die ursprüngliche Anzahl nicht wiederhergestellt. Es sorgte lediglich dafür, dass das richtige Dokument berücksichtigt wurde. Die weiteren Herausforderungen lagen innerhalb des Dokuments selbst.
Mitarbeiteridentifikatoren als Überlebensexperiment
Anstatt über „Vibes“ zu diskutieren, wurden die Mitarbeiteridentifikatoren ST001 bis ST012 in jeder Phase nachverfolgt: Extraktion, Aufteilung in Abschnitte, Abruf, Neuranking, Komprimierung sowie Endmontage der Anfrage.
retrieved chunk ST001 ST002 ST003 ST004 ST005 ... ST012 (12 present)
after rerank ST001 ST002 ST003 ST004 ST005 ... ST012 (12 present)
after compression ST001 ST002 (2 present)
prompt sent ST001 ST002 (2 present)
Mehrere IDs verschwanden zwischen der Kompression und dem Modell. Der Kompressor hielt ein festes Budget für „Hauptsätze“ bereit. Eine Tabellezeile zählt als Satz. Eine dichte Gehaltsliste verbraucht das Budget bereits in den ersten Zeilen, während die späteren Zeilen – sowie der Text, der sie erklärt – niemals in den Prompt gelangen. Das Modell gibt anschließend ehrlich das zurück, was es gesehen hat.
# before — keep the top N
best = scored[:40]
# after — keep the best until the character budget runs out
budget = MAX_CONTEXT_CHARS // TOP_K_AFTER_RERANK
for sentence, score in ranked:
if best and len(sentence) + 2 > budget:
continue
best.append(sentence)
budget -= len(sentence) + 2
Sobald die Kompression die Zeilen durcheinanderbrachte und abschnittsweise entfernte, erschien die Gehaltsliste wie ein Kartenspiel, das in der falschen Reihenfolge ausgegeben wurde. Jede Zahl könnte zwar irgendwo im Kontextfenster vorhanden sein, doch die Struktur, um verschiedene Mitarbeiter zu zählen, fehlte. Die Zählung der Personen in einer Tabelle, die jemand in rangierte Abschnitte unterteilt hat, ist eine andere Aufgabe als das Lesen der Tabelle selbst.
Reranker-Werte, die gut aussahen, aber dennoch schadeten
Die Scores der Cross-Encoder für die kritischen Zeilen wirkten „angemessen“. Angemessen bedeutet jedoch nicht, dass eine vollständige Tabelle erhalten bleibt.
0.446 keep ST001 Rajesh Kumar M CFO 75,000 ...
0.323 keep ST002 Priya Sundaram Finance Mgr 45,000 ...
0.420 keep ST003 Murugan K Sr Accountant 28,000 ...
0.259 DROP ST005 Selvam R Production Mgr 38,000 ... ← below 0.30
0.422 keep ST006 Karthik P Supervisor 18,000 ...
# pick the best by score…
chosen = set(id(p) for p in best)
# …then put them back in document order before joining
best = [p for p in scored if id(p) in chosen]
Die Korrektur bestand nicht darin, überall die Schwellenwerte zu erhöhen. Es ging vielmehr darum, zeilenähnliche Strukturen zu erkennen und sie vor aggressiver Kompression zu schützen. Eine praktische Heuristik: Wenn eine Zeile vier oder mehr Zahlen enthält und sich in derselben Gruppe mindestens drei ähnlichen Zeilen befindet, sollte sie als Tabelleingabe behandelt und unabhängig vom Satzscore beibehalten werden.
ROW_MIN_NUMBERS = 4
TABULAR_MIN_ROWS = 3
def is_row(sentence):
return len(NUMBER_RE.findall(sentence)) >= ROW_MIN_NUMBERSif looks_tabular(sentences):
survivors = [p for p in scored if is_row(p[0]) or p[1] >= threshold]
else:
survivors = [p for p in scored if p[1] >= threshold]
Durch die Befreiung der Tabelleinträge überlebten alle zwölf IDs bei dem nächsten Ausführungsversuch im Prompt. Der Generator hatte schließlich eine Struktur, die er zählen konnte.
Kleine Korrekturen, die weitere Probleme beseitigten
Während der Pfad zur Tabelle geöffnet war, wurden einige damit verbundene Probleme auf dieselbe Weise behandelt: leere Umgebungsvariablen, die stumm die vorgesehenen Standardwerte ersetzten, Dokumenttyp-Filter, die sich zwischen der lokalen Qdrant-Instanz und Qdrant Cloud unterschiedlich verhielten, sowie Antwortdatenpakete, die nur Prosa zurücklieferten, obwohl die Nutzer den Pipeline-Verlauf benötigten.
# the context cap must be at least CHUNK_SIZE × TOP_K_AFTER_RERANK
MAX_CONTEXT_CHARS = 5000 # was 2000 while 1200 × 3 = 3600
Jede Antwort gibt nun nicht nur den Endsatz, sondern auch die gesamte Pipeline zurück – abgerufte IDs, Scores, Komprimierungsentscheidungen sowie Filter – sodass der nächste fehlerhafte Auswertungsergebnis ohne Raten analysiert werden kann:
{
"answer": "12 employees are listed...",
"citations": [{"doc": "Salary_Register_April_2025.pdf", "page": 1}],
"pipeline": {
"retrieved": 5,
"after_rerank": 3,
"chars_before_compression": 3847,
"chars_after_compression": 2103
}
}
Das Filtern nach Dokumenttyp funktionierte bei einer lokalen Qdrant-Instanz, versagte jedoch genauso in Qdrant Cloud, solange die Indizes der Antwortdatenpakete und die Filterstrukturen nicht mit dem übereinstimmten, was tatsächlich in der Cloud-Installation indiziert wurde:
500 — Index required but not found for "doc_type"
Eine verwandte Methode in Python: os.getenv("KEY", "default") gibt einen leeren String zurück, wenn die Variable existiert, aber leer ist. Das ist nicht die Standardlösung. Verwenden Sie lieber or, wenn ein leeres Ergebnis weitergeleitet werden muss:
QDRANT_URL = os.getenv("QDRANT_URL") or "http://localhost:6333"
Wo die Auswertung endete
Nach der hybriden Abfrage, der datenbankorientierten Kompression sowie expliziter Überwachung der Datenpipeline ergab die Abfrage zum April-Register zwölf Ergebnisse mit Quellenangaben, die auf die Zeilen hinwiesen, die diese Anzahl rechtfertigten.
Retrieval: hybrid, 0.65 semantic + 0.35 BM25
Reranking: cross-encoder, 5 in → 3 out
Compression: sentence-level, table-aware, ~35% reduction
Grounding: prompt + threshold + temperature 0.0
Evaluation: 13/15 on the golden set, refusals tested
Latency: ~4s end to end
Cost: ~$0.003 per fifteen-question run
Dafür war kein neues Grundmodell erforderlich. Es genügte, RAG als Datenpipeline zu betrachten, bei der die Überlebensraten der wichtigen Token messbar sind. Tutorials verkaufen „Einbetten, abfragen, generieren“. In der Produktion geht es darum, „zu beweisen, dass die entsprechenden Zeilen den Prompt erreicht haben“.
Operative Gewohnheiten, die zu zuverlässigen Zahlen führen
Bewahren Sie eine Sammlung von Schlüsselfragen auf, die mindestens eine reine Zählung über eine Tabelle, eine präzise Identifikationsabfrage und eine semantische Richtlinienfrage enthält. Wenn nur die semantischen Fragen bestehen, lügt die Demo bezüglich der Bereitschaft.
Protokollieren Sie die Chunk-IDs durch Komprimierung. Wenn eine ID nach dem Abrufen vorhanden ist, aber nach der Komprimierung fehlt, handelt es sich um einen Fehler – auch dann, wenn die endgültige Antwort zufällig heute richtig ist.
Verwenden Sie lieber explizite Hybride für Korpora, die Prosa und unterschiedliche Sprachregister mischen. Allein eine dichte Abfrage wird bei Aufsätzen weiterhin erfolgreich sein, bei Code jedoch scheitern.
Betrachten Sie Zitate als notwendig, aber nicht ausreichend. Eine Seitenzahl neben einer falschen Anzahlangabe bleibt weiterhin eine falsche Anzahlangabe.
Beim Umstieg von lokalem Qdrant auf die Cloud überprüfen Sie erneut die Payload-Indizes sowie das Filterverhalten mit denselben Testfällen. API-Kompatibilität bedeutet nicht automatisch identische Indizierungsstandards.
Der Budgetkontext bezieht sich auf die Struktur insgesamt, nicht nur auf „wichtige Sätze“. Tabellen sind Teil der Struktur. Wenn man sie wie Blog-Paragrafen komprimiert, wird aus zwölf einer.
Warum sanfte Fehler strengere Kontrollmechanismen erfordern
Teams entscheiden oft über den Start von RAG-Systemen danach, ob „die Antworten in einer Tabelle mit Standardanfragen gut aussehen“. Dieser Maßstab übersieht die wirklich wichtigen Fehler in Bereichen wie Lohnabrechnung, Lagerverwaltung und Compliance: fehlerhafte Untergrenzzahlen. Fügen Sie automatische Überprüfungen hinzu, die sicherstellen, dass die extrahierten Entity-Sete auch in den Prompt für bekannte Konfigurationen übernommen werden. Verhindern Sie den Build, wenn nach der Kompression in der Lohnkonfiguration nicht alle Werte von ST001 bis ST012 vorhanden sind.
Derselbe Kontrollmechanismus kann außerdem sicherstellen, dass die Gewichtungen der hybriden Kombinationen tatsächlich in der laufenden Konfiguration aktiviert sind – und nicht nur im README. Eine Abweichung zwischen den Experimenten in den Notizbüchern und der Servicekonfiguration ist eine häufige Ursache dafür, dass BM25 nach einer Refaktorierung „verschwindet“.
Zuletzt sollten die Bediener darin unterwiesen werden, schönen Zitaten misstrauisch zu begegnen. Die Benutzeroberfläche des Produkts sollte internen Nutzern die Spuren der Abruf- und Komprimierungsprozesse neben der Antwort anzeigen, solange der „goldene“ Status für einen Release-Zyklus grün bleibt. Externe Nutzer können den sauberen Absatz beibehalten; interne Nutzer benötigen das „Autopsie-Set“.
Fazit
Im Register stand nie, dass es nur einen Mitarbeiter gibt. Die Verarbeitungskette tat es jedoch, nachdem sie leise die Zeilen entfernt hatte, die dies korrigiert hätten. Um das zu beheben, waren hybride Suchverfahren für Identifikatoren, kompressionsorientierte Verarbeitung der Struktur sowie Antworten erforderlich, die ihre eigenen Beweisspuren enthielten. Sobald diese Elemente vorhanden waren, blieben zwölf weiterhin zwölf – und das nächste zuverlässige Zitat hatte etwas Reales, auf dem es beruhen konnte.
Das ist der Maßstab, den man einhalten sollte: nicht ob das Modell überzeugend klingen kann, sondern ob das System die Fakten nachweisen kann, die diese Zuverlässigkeit rechtfertigen.
Eine genauere Betrachtung der hybriden Bewertung in der Praxis
Dichte Abfragedatenverarbeitung kodiert die Frage sowie jeden Textabschnitt in denselben Vektorraum und ordnet sie mithilfe des Kosinus- oder Skalarprodukts. Das funktioniert, wenn die Sprache des Benutzers mit der Sprache des Dokuments übereinstimmt – beispielsweise bei Themen wie Elternurlaub, Abfindung oder Homeoffice-Richtlinien. Es versagt jedoch, wenn der Benutzer einen unklaren Token einfügt, der kaum in den Trainingsdaten vorkommt und im Embedding-Raum nur selten mit benachbarten Wörtern zusammenvorkommt. Mitarbeitercodes, Rechnungsnummern und Vertragsidentifikatoren gehören genau zu dieser Kategorie von Tokenen.
BM25 und verwandte lexikalische Bewertungsmethoden wenden das Problem um. Sie achten darauf, ob ein Token vorkommt, wie selten es im Korpus ist und wie oft es im Kandidatenabschnitt auftaucht. Es ist ihnen egal, dass „STL/2025-26/003“ semantisch fast nichts mit anderen Inhalten zu tun hat. Die Kombination beider Bewertungen ist keine philosophische Entscheidung, sondern eine Anerkennung dafür, dass Lohnkorpora sowohl essayartige Dokumente als auch registrierungsähnliche Tabellen enthalten.
Die hier verwendete Mischung von 0,65 / 0,35 ist ein Ausgangspunkt, keine Naturgesetz. Korpora mit vielen Codes benötigen möglicherweise mehr lexikalisches Gewicht, während korpora mit viel Erzählstoff weniger benötigen. Entscheidend ist es, beide Arten von Fragen im „goldenen Set“ zu messen und keine Kombination bereitzustellen, die nur narrative Anfragen bewältigt.
Beim Implementieren der Mischung sollten die Werte vor dem Vermischen normalisiert werden. Rohdaten zu Dichteähnlichkeiten und BM25-Werten liegen auf unterschiedlichen Skalen. Teams, die unnormalisierte Zahlen verwenden, stellen oft fest, dass ein Kanal versehentlich dominiert. Sowohl Min-Max- als auch Rank-Fusion (RRF) sind akzeptabel, sofern sie an Beispielen mit exakten IDs getestet werden.
Kompression als verlustbehafteter Codec für Tabellen
Die Kontextkompression existiert, weil Modelle begrenzte Aufmerksamkeitsfenster haben und weil irrelevante Sätze die Aufmerksamkeit ablenken. Die gängige Vorgehensweise ist: Sätze nach Relevanz bewerten, die besten k auswählen und den Rest ignorieren. Dabei wird angenommen, dass Sätze austauschbare Bedeutungseinheiten sind. Tabellenzeilen hingegen sind keine austauschbaren Bedeutungseinheiten. Zeile 7 ohne die Zeilen 1–6 ist keine nur etwas schlechtere Tabelle – es handelt sich um eine fehlerhafte Tabelle.
Die Befreiungsheuristik – viele Zahlen in einer Zeile, mehrere solcher Zeilen in der Nähe – ist absichtlich grob gestrickt. Sie behält einige nicht-tabellenartige Zeilen bei, die numerisch aussehen, und das ist akzeptabel. Falschpositive Ergebnisse kosten Token, falschnegative Ergebnisse kosten Korrektheit. Bei Lohnabrechnungen und Bestandsverwaltung zählt die Korrektheit am meisten.
Erweiterte Detektoren können die PDF-Struktur von pdfplumber nutzen: Zell-Rahmen, ausgerichtete Spalten, wiederholte x-Koordinaten. Solche Signale sind hervorragend, wenn sie verfügbar sind. Die Satzheuristik bleibt als Ersatz nützlich, wenn der Text bereits vor dem Komprimierungsprozess in Markdown oder reinen Text umgewandelt wurde.
Ein weiterer Fehlerfall ist das Umsortieren. Selbst wenn alle Zeilen erhalten bleiben, kann ein Neuanordnen nach Relevanzwert Summen und Zählungen zerstören. Für befreite Tabellenzeilen sollte eine stabile Dokumentreihenfolge gewährleistet werden. Prosa kann frei geordnet werden; Tabellen sollten in der Lese-Reihenfolge bleiben.
Zitate, die die falsche Antwort verteidigen
Citation UX weist oft auf das PDF sowie die Seite hin, die den größten Anteil am abgerufenen Inhalt beigetragen haben. Wenn durch Komprimierung später die Hälfte der Tabelle fehlt, zeigt die Citation weiterhin auf die richtige Datei. Die Nutzer interpretieren dies als Bestätigung. Das Produktdesign sollte entweder die konkreten Zeilen angeben, die in der endgültigen Anfrage verwendet wurden, oder einen Abrufverlauf anzeigen. Andernfalls wird die Benutzeroberfläche zum Komplizen.
Für regulierte Bereiche sollte der genaue Prompt-Context-Hash zusammen mit der Antwort gespeichert werden. Wenn ein Prüfer fragt, warum das System „einen Mitarbeiter“ angab, kann man die abgeschnittene Tabelle erneut anzeigen und den Fehler aufzeigen, anstatt über das Verhalten des Modells zu diskutieren.
Lokale versus Cloud-Vektordatenbanken
Der Dokumenttyp-Filter, der lokal funktionierte und in Qdrant Cloud fehlschlug, erinnert daran, dass „dieselbe API“ nicht gleichbedeutend mit „derselben Indexkonfiguration“ ist. Payload-Indizes, Schlüsselwortfilter und die Handhabung von Nullwerten unterscheiden sich je nach Bereitstellungsmodus. Fixture-Tests sollten an derselben Bereitstellungsklasse ausgeführt werden, die auch in der Produktion genutzt wird. Ein grüner lokaler Testabschluss bei rotem Filter im Cloud-Umfeld bedeutet, dass leere Abfragen unbemerkt durchgeführt werden.
Auch leere Umgebungsvariablen erfordern gleiche Vorsichtsmaßnahmen. Konfigurationsysteme, die für nicht gesetzte Geheimnisse leere Zeichenketten exportieren, umgehen in Sprachen, in denen Leere als wahr angesehen wird, die Standardwerte. Normalisieren Sie die Konfiguration zu Beginn des Prozesses: Behandeln Sie leere Werte als fehlend, wenden Sie anschließend Standardwerte an und geben Sie bei weiterhin fehlenden erforderlichen Schlüsseln einen Fehler aus.
Überlebensfähigkeit messen – nicht nur „Vibes“
Das Employee-ID-Überlebensexperiment dient als Vorlage. Wählen Sie die Entitäten aus, die für eine richtige Antwort erforderlich sind. Überprüfen Sie, ob sie nach der Extraktion, dem Chunking, der Abrufung, der Neubewertung und der Kompression vorhanden sind. Zeichnen Sie die Rückgänge auf. Der erste Abfall ist in der Regel das Fehlermerkmal.
Erweitern Sie die Idee auf numerische Aggregaten. Wenn die Frage eine Summe betrifft, überprüfen Sie, ob jede Addenzell den Prompt erreicht hat. Wenn es um eine Einzelzählung geht, stellen Sie sicher, dass die Menge der eindeutigen Schlüssel vollständig ist. Diese Überprüfungen sind im Vergleich zu Produktionsstörungen unkompliziert.
Was man zunächst nicht als Schuldigen betrachten sollte
Es ist verlockend, dem LLM die Schuld zu geben, wenn die Zählung falsch ist. Manchmal kann das Modell tatsächlich nicht zählen. Häufiger hat das Modell jedoch nie eine zählbare Struktur erhalten. Wechseln Sie die Modelle erst, wenn der Überlebensgraph grün ist. Andernfalls „beheben“ Sie einen Zählfehler dadurch, dass Sie auf ein größeres Modell wechseln, das die von Ihnen gewünschte Zahl erfindet – bis der nächste Datensatz eintrifft.
Ebenso sollten Sie davor zurückhaltend sein, das gesamte Framework zu ersetzen, nur weil ein Kompressor sich falsch verhalten hat. Isolieren Sie den betroffenen Teil, fügen Sie Ausnahmen hinzu, führen Sie Tests durch und machen Sie weiter. Umfassende Überarbeitungen wirken produktiv, führen aber oft wieder zur gleichen Art von Fehlern unter neuen Namen.
Eine minimale Überprülliste für mehr Sicherheit
- Kernfragen: Tabelleinzahl, exakter ID, semantische Richtlinie.
- Hybridisierte Abrufmethode mit normalisiertem Mischverhältnis oder RRF.
- Tabellenorientierte Kompression mit stabiler Zeilenreihenfolge.
- Aufzeichnung der Pipeline-Verläufe für jede interne Antwort.
Führen Sie diese Überprülliste durch, bevor Sie ein Payroll-RAG als „abgeschlossen“ betrachten. Das April-Register wird nicht das letzte Dokument sein, das auf den ersten Blick einfach erscheint und dann höflich versagt.
Folgen für das Team
Sobald die Antwort der zwölf Mitarbeiter stabilisiert war, erkannte dieselbe Telemetrie zwei weitere, weniger auffällige Fehler: einen veralteten Sammlungs-Alias nach einer erneuten Einbeziehung sowie eine Timeout-Situation beim Neurankieren, bei der auf ungeordnete hybride Ergebnisse zurückgegriffen wurde, ohne die Antwort als beeinträchtigt zu markieren. Beide Fehler wären unsichtbar geblieben, wenn die API nur einen String zurückgegeben hätte. Durch das Zurückgeben von Strukturen – Scores, Zeiten, Fallbacks – wurde der Assistent zu etwas, dem die Operator genug vertrauen konnten, um auch um 2 Uhr morgens daran zu feilen.
Das ist die eigentliche Lektion bezüglich der Produkte. RAG-Systeme sind keine Chat-Oberflächen über PDFs – es handelt sich dabei um Datensysteme, die in Absätzen kommunizieren. Behandeln Sie sie wie solche Datensysteme: messen Sie Verluste, bewahren Sie die Struktur bei und lassen Sie niemals zu, dass eine Zitation anstelle von Beweisen dient.
Noch einmal der ursprüngliche falsche Antwort
Die Wiederholung der schlechten Antwort zusammen mit den dazugehörigen Spuren macht die Sache fast langweilig. Das Retrieval-System hatte fast das richtige PDF – das hybride Scoring-Verfahren erledigte dann den Rest. Die Komprimierung verwendete anschließend ihren „Satzbudget“ für die ersten numerischen Zeilen und ignorierte den Rest. Das Modell zählte, was übrig blieb, und zitierte die Datei. Jede Stufe leistete für sich genommen etwas Nachvollziehbares – gemeinsam erzeugten sie jedoch Vertrauen.
Deshalb irreführen stage-lokale Metriken. Retrieval@k mag gesund erscheinen, während die Kompression die Antwort zerstört. Die End-zu-End-Überlebensrate der Entitäten ist die Metrik, die dem Schaden für den Benutzer entspricht. Übernehmen Sie sie frühzeitig – insbesondere dann, wenn Dokumente als Tabellen in PDF-Form vorliegen.
Falls Sie aus dem Vorfall mit den zwölf Mitarbeitern nichts anderes mitnehmen, nehmen Sie Folgendes mit: Höfliche RAG-Fehler sind Pipeline-Bugs, solange das Gegenteil nicht bewiesen ist. Instrumentalisieren Sie den Prozessweg, schützen Sie die Struktur und lassen Sie das System seine Arbeit zeigen, bevor Sie seiner Aussage vertrauen. Sanfte Fehler erfordern strenge Kontrollmechanismen, wiederholte Überprüfungen sowie Operator:innen, die jeden Schritt überwachen können, bevor die Benutzer wieder einer Zählung vertrauen.
Die Überlebensrate der Entitäten bei Kompression bleibt die einfachste und ehrlichste Kontrollmethode für korpora mit vielen Tabellen.
Sobald das nächste Register eintrifft, führen Sie erneut denselben Überlebensverlauf der IDs durch, bevor Sie einer neuen, selbstbewussten Zitation wieder vertrauen.