Funktioniert dein RAG wirklich? KI-Systeme in Produktion evaluieren

Die Frage, die du nicht beantworten kannst

Ich sage es direkt: Die meisten Teams, die ein RAG-System oder einen KI-Agenten in Produktion betreiben, können eine einfache Frage nicht beantworten. Ist es gut? Sie haben eine Demo, die jemanden beeindruckt hat, ein paar handverlesene Beispiele und ein vages Gefühl, dass die Nutzer zufrieden wirken. Das ist keine Evaluation, das ist Hoffnung. Und Hoffnung sagt dir nicht, ob die Änderung von letzter Woche etwas verbessert oder still verschlechtert hat.

KI zu evaluieren ist schwerer als klassische Software zu evaluieren, weil es selten die eine korrekte Ausgabe gibt. Ein Retrieval kann teilweise richtig sein, eine Antwort kann plausibel, aber falsch sein, und derselbe Input kann unterschiedliche Outputs erzeugen. Aber schwerer heißt nicht unmöglich. Du misst KI-Qualität genauso, wie du alles misst, was du nicht mit bloßem Auge prüfen kannst: Testset bauen, Metriken definieren, dagegen bewerten und die Zahlen über die Zeit beobachten. Dieser Guide zeigt dir, wie.

Wenn du nicht sagen kannst, ob deine KI nach einer Änderung besser oder schlechter geworden ist, betreibst du kein System, du hoffst auf eines. Evaluation ist das, was Hoffnung in Engineering verwandelt.

Wir bauen messbare KI, und wir betreiben Confidence Scoring und einen Review-Loop in unserer eigenen Exfinity-Plattform. Dieser Guide ist genau diese Disziplin. Für die Retrieval-Architektur selbst sieh dir unseren Guide zu Enterprise-RAG-Systemen an, und das ist Kernarbeit unserer KI-Services.

Wen interessiert was

Zwei Arten von Evaluation

Es gibt zwei Modi, und du brauchst beide.

Offline-Evaluation läuft gegen ein festes Testset, bevor du auslieferst. Du hast bekannte Fragen und bekannte gute Antworten, und du bewertest das System dagegen. Das ist dein Regressions-Gate: Es sagt dir, ob eine Änderung geholfen oder geschadet hat, bevor echte Nutzer es spüren.

Online-Evaluation läuft gegen echten Traffic, nachdem du ausgeliefert hast. Echte Nutzer fragen Unerwartetes, und du misst über Confidence Scores, Feedback und Ergebnisse, wie sich das System in freier Wildbahn schlägt. Das fängt ab, was dein Testset nicht vorhergesehen hat.

Der Fehler ist, nur eines zu tun. Nur offline übersieht, was echte Nutzer wirklich fragen. Nur online heißt, du findest Regressionen erst, wenn sie Kunden treffen. Unser KI-Observability-Guide behandelt die Online-Seite im Detail.

Bau zuerst das Testset

Alles beginnt mit einem Testset: repräsentative Fragen, gepaart mit dem, wie eine gute Antwort aussieht. Das ist der eine Baustein mit dem größten Hebel, den du bauen kannst, denn ohne ihn ist jede Evaluation subjektiv.

Ein gutes Testset sind nicht hundert einfache Fragen. Es ist eine bewusste Mischung.

1. Häufige Fälle. Die Fragen, die Nutzer tatsächlich am meisten stellen.
2. Harte Fälle. Mehrdeutige, mehrteilige oder Randfragen, bei denen das System wahrscheinlich ins Rutschen kommt.
3. Bekannte Fehler. Jeder Bug, den du je gefunden hast, als permanenter Regressionscheck hinzugefügt.
4. Adversariale Fälle. Fragen, die gezielt Halluzination oder Datenabfluss provozieren sollen.

Halte es versioniert, erweitere es bei jedem neuen Fehler, den du findest, und lass es bei jeder Änderung laufen. Das verwandelt "ich glaube, es ist besser" in "Recall ist zwei Punkte gestiegen und nichts hat regrediert." Unser Guide von Prototyp zu Produktion zeigt, wie du das von Anfang an aufbaust.

Miss Retrieval und Generierung getrennt

Eine RAG-Antwort kann aus zwei sehr unterschiedlichen Gründen schlecht sein: Das Retrieval hat die falschen Dokumente geliefert, oder das Retrieval war in Ordnung und das Modell hat aus guten Dokumenten eine schlechte Antwort geschrieben. Wenn du nur die finale Antwort misst, kannst du nicht unterscheiden, welcher Fall vorliegt, und du kannst nicht reparieren, was du nicht lokalisieren kannst.

Miss die beiden Stufen getrennt.

Wenn die Qualität sinkt, zeigt dir diese Trennung, wo du suchen musst. Sinken die Retrieval-Metriken, dann repariere Chunking, Embeddings oder Hybrid-Suche, behandelt in unserem Guide zur Vektorsuche-Architektur. Sinken die Generierungsmetriken bei gutem Retrieval, dann repariere den Prompt oder das Modell. Unser Guide zur RAG-Zuverlässigkeit in Produktion behandelt die Fehlermodi.

Ein durchgerechnetes Beispiel: ein Testset-Eintrag

Mach Evaluation konkret mit einem einzelnen Testfall, denn die ganze Disziplin ist aus diesen gebaut.

Ein Testset-Eintrag ist eine Frage, die Dokumente, die abgerufen werden sollten, und das, was eine gute Antwort enthält.

Question:        "What is the cancellation policy for same-day tours?"
Should retrieve: policy-doc-cancellations (chunk 3)
Good answer:     states same-day tours are non-refundable, cites the policy

Jetzt fahre eine Änderung, sagen wir eine neue Chunking-Strategie, und bewerte das System dagegen.

Retrieval:   was the right chunk in the top k?        yes  -> recall ok
Rank:        where did it land?                        rank 1 -> good
Faithfulness: did the answer stick to the chunk?       yes -> no invention
Relevance:   did it actually answer the question?      yes
Attribution: did it cite the source?                   yes

Ein grüner Fall beweist nichts. Hundert davon, über häufige Fragen, harte Fragen, jeden früheren Bug und adversariale Versuche hinweg, geben dir eine Zahl: Diese Änderung hat den Retrieval-Recall um zwei Punkte angehoben und nichts regredieren lassen, oder sie hat still den Same-Day-Tour-Fall gebrochen, der vorher bestanden hat. Das ist der Unterschied zwischen "es fühlt sich besser an" und "hier ist, was sich geändert hat." Jeder Bug, den du je findest, wird hier ein permanenter Eintrag, damit derselbe Fehler nicht unbemerkt zurückkommen kann. Unser Guide zu Enterprise-RAG-Systemen behandelt das Tuning des Retrievals, das diese Metriken messen.

Confidence Scoring: Evaluation, die live läuft

Offline-Metriken brauchen bekannte Antworten. In Produktion hast du die nicht, also brauchst du ein Signal, das das System auf jeder Antwort ohne Ground Truth berechnen kann. Dieses Signal ist ein Confidence Score.

Ein praktikabler Confidence Score ist ein Komposit aus Faktoren, die du zur Laufzeit messen kannst. In Exfinity wird jede Antwort auf vier davon bewertet: ob das Retrieval nützliche Ergebnisse geliefert hat, ob die Antwort die Policy-Checks bestanden hat, ob sie substanziell und kein bloßer Stub ist, und ob genug Gesprächstiefe da war, um sie zu verankern.

confidence = retrieval * 0.4      // haben die Tools nützliche Ergebnisse geliefert
           + policy * 0.2         // gibt es Validierungswarnungen
           + completeness * 0.2   // substanziell, kein bloßer Stub
           + memory * 0.2         // genug Kontext, um verankert zu sein

Eine Antwort unter einem Schwellenwert wird als niedrige Konfidenz markiert und an menschliches Review geroutet, bevor ihr vertraut wird, und das System klassifiziert, warum sie niedrig war: ein Retrieval-Miss, ein Policy-Block, ein Halluzinationssignal wie ein vergangenes Datum, das als aktuell präsentiert wird. Das gibt dir ein Live-Qualitätssignal auf jeder einzelnen Antwort, nicht nur auf deinem Testset. Es ist Evaluation, die in Produktion läuft, kontinuierlich.

Schließ den Kreis: Review, das das System verbessert

Ein Confidence Score, der nur Probleme markiert, ist eine Warnleuchte. Ein Confidence Score, der mit einem Review-Loop verdrahtet ist, ist ein System, das sich verbessert.

Wenn eine Antwort niedrige Konfidenz hat, prüft sie ein Mensch. Wenn die Antwort gut hätte sein sollen, wird die freigegebene Antwort zurück in die Wissensbasis gefaltet, sodass dieselbe Frage beim nächsten Mal eine gute Antwort abruft. In Exfinity stimmt dieser Auto-Learn-Loop sogar seinen eigenen Schwellenwert ab: Wenn Reviewer fast alles Markierte freigeben, sinkt der Schwellenwert, um mehr zu fangen; wenn sie viel ablehnen, steigt er, um Rauschen zu reduzieren. Das System wird messbar besser dadurch, dass es benutzt wird, statt sich nur anzusammeln. Das ist das Human-in-the-Loop-Muster, angewandt auf die Qualität selbst, und es verbindet sich mit den Memory-Mustern in unserem Guide zu Agenten-Memory.

Mach ein Gate daraus, keinen Report

Evaluation, die einen Report produziert, den niemand liest, ändert nichts. Evaluation, die ein Deploy gated, ändert alles. Verdrahte dein Offline-Testset in die Pipeline, sodass eine Änderung, die die Qualität unter die Latte drückt, den Build fehlschlagen lässt, genauso wie ein fehlschlagender Unit-Test.

Das ist der Wechsel von "wir evaluieren manchmal" zu "wir können keine Regression ausliefern." Es ist die eine Praxis, die Teams, deren KI-Qualität besser wird, am stärksten von Teams trennt, deren Qualität driftet. Unser KI-Observability-Guide zeigt, wie du die Online-Metriken genauso ins Alerting verdrahtest.

So startest du

1. Bau ein Testset. Häufige Fälle, harte Fälle, bekannte Fehler und adversariale Fälle. Versioniere es.
2. Trenn die Metriken. Miss Retrieval und Generierung getrennt, damit du weißt, wo du suchen musst.
3. Füge einen Confidence Score hinzu. Ein Live-Signal auf jeder Antwort, mit einem Review-Schwellenwert.
4. Schließ den Kreis. Route niedrige Konfidenz an menschliches Review, falte gute Antworten zurück.
5. Gate das Deploy. Lass den Build bei einer Qualitätsregression fehlschlagen, nicht nur bei einem kaputten Test.

Das ist stufenweise angelegt und passt zu unserer Methodik. Unsere Teams für Individualsoftware und Consulting bauen messbare KI. Starte über Kontakt oder hol dir ein sauber umrissenes Angebot.

Wie das typischerweise schiefgeht

1. Kein Testset. Jede Evaluation ist subjektiv. Bau eins und versioniere es.
2. Nur die finale Antwort messen. Du kannst nicht sagen, ob Retrieval oder Generierung versagt hat. Trenn sie.
3. Nur offline oder nur online. Offline übersieht echte Fragen, online findet Regressionen spät. Mach beides.
4. Ein Confidence Score ohne Loop. Markieren ohne Reparieren ändert nichts. Route ins Review, falte zurück.
5. Ein Report, den niemand liest. Gate das Deploy auf Qualität, damit eine Regression nicht ausgeliefert werden kann.

Wer das baut

Oronts ist ein gründergeführtes Softwareunternehmen in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team, das KI baut, die du messen kannst. Unsere eigene Exfinity-Plattform bewertet jede Antwort, routet niedrige Konfidenz ins Review und verbessert sich aus dem Loop. Wir bauen das Testset, die Metriken, das Confidence Scoring und den Review-Loop, und übergeben dir ein System, dessen Qualität du wirklich sehen und verteidigen kannst. Sieh dir unsere Seiten zu Services und Lösungen an.

Das Wichtigste

• Wenn du nicht sagen kannst, ob deine KI nach einer Änderung besser oder schlechter geworden ist, hoffst du, statt Engineering zu betreiben.
• Bau ein versioniertes Testset aus häufigen Fällen, harten Fällen, bekannten Fehlern und adversarialen Fällen.
• Miss Retrieval und Generierung getrennt, damit du weißt, welches von beiden du reparieren musst.
• Füge einen Live-Confidence-Score mit Review-Schwellenwert hinzu und schließ den Kreis, damit das System sich verbessert.
• Gate das Deploy auf Qualität, damit eine Regression nicht ausgeliefert werden kann.

Evaluation ist keine Phase, die du einmal machst. Sie ist das Instrumentenbrett, nach dem du das System fliegst. Bau es früh, gate immer darauf, und deine KI verbessert sich, statt zu driften.

Nicht sicher, ob deine KI wirklich funktioniert? Erzähl uns, was du betreibst. Starte über Kontakt oder hol dir ein sauber umrissenes Angebot.