Warum 95 % Genauigkeit im KI-System wenig aussagt

Ein ähnlicher Fall war wenige Wochen zuvor beim österreichischen Obersten Gerichtshof gelandet. In einer Nichtigkeitsbeschwerde fanden sich zahlreiche Fehlzitate, darunter höchstgerichtliche Entscheidungen, die es gar nicht oder jedenfalls nicht mit dem behaupteten Inhalt gab. Der OGH ging davon aus, dass das Vorbringen offenbar ohne ausreichende fachliche Kontrolle mit KI erstellt worden war. (OGH 7.10.2025, 14 Os 95/25i.)

Beide Fälle zeigen ein Problem, das nicht nur Kanzleien betrifft. Sobald Unternehmen KI für Verträge, Richtlinien, technische Dokumentationen oder internes Wissen einsetzen, stellt sich dieselbe Frage:

Wie misst man eigentlich, ob ein solches System zuverlässig ist?

Eine einzelne Genauigkeitsquote reicht dafür nicht.

95 Prozent – aber welche fünf Prozent sind falsch?

Nehmen wir an, ein Anbieter testet sein Wissenssystem mit 100 Fragen. 95 Antworten werden als richtig bewertet.

Das Ergebnis lautet: 95 Prozent Genauigkeit.

Das klingt zunächst gut. Für eine Risikobewertung fehlt aber eine entscheidende Information: Was ist bei den übrigen fünf Fragen passiert?

Das System kann relevante Information übersehen haben. Eine Vertragsklausel war vorhanden, wurde aber nicht gefunden.

Oder es hat Information hinzugefügt, die in den Unterlagen überhaupt nicht vorkommt.

Beides ist falsch. Technisch sind es aber unterschiedliche Probleme.

Zwei Fehler, zwei Ursachen

Bei einem KI-Wissenssystem – häufig als RAG-System umgesetzt – passieren Fehler grob an zwei Stellen.

Das System findet relevante Information nicht.

Die gesuchte Information ist beispielsweise in einem Handbuch vorhanden, gelangt aber bei der Suche nicht in den Kontext des Sprachmodells. Ursache können unter anderem Chunking, Indexierung, Metadaten, Suchverfahren oder Ranking sein.

Das ist ein Retrieval-Problem.

Das System formuliert etwas, das durch die vorhandenen Quellen nicht gedeckt ist.

Das Sprachmodell ergänzt eine plausible Information, interpretiert eine Passage zu weit oder stellt eine Behauptung auf, für die es im bereitgestellten Kontext keinen ausreichenden Beleg gibt.

Das ist ein Grounding- beziehungsweise Generierungsproblem.

Für den Nutzer können beide Antworten überzeugend aussehen. Deshalb reicht es nicht, am Ende lediglich „richtig“ oder „falsch“ zu zählen.

Ein gutes Evaluationsverfahren muss zeigen, wo der Fehler entstanden ist.

Quellenangaben allein lösen das Problem nicht

Eine häufige Antwort auf Halluzinationen lautet: Das System soll einfach seine Quellen anzeigen.

Das ist sinnvoll, reicht aber nicht.

Eine Quellenangabe beweist zunächst nur, dass das System ein Dokument verlinkt hat. Sie beweist noch nicht, dass dieses Dokument die konkrete Aussage tatsächlich unterstützt.

Ein System kann beispielsweise schreiben:

„Der Vertrag kann mit einer Frist von drei Monaten gekündigt werden.“

und daneben korrekt auf den Vertrag verweisen.

Wenn in der zitierten Passage aber sechs Monate stehen, hat das System zwar eine Quelle geliefert – die Aussage bleibt trotzdem falsch.

Bei sensiblen Anwendungen sollte deshalb nachvollziehbar sein, welche Passage eine konkrete Aussage belegt. Nicht nur das Dokument, sondern möglichst die relevante Stelle darin.

Für Nutzer wird eine Antwort damit überprüfbar. Für Tests entsteht gleichzeitig eine klare Frage: Ist diese Behauptung durch die angegebene Quelle tatsächlich gedeckt?

Das System muss auch keine Antwort geben dürfen

Ein weiterer Punkt wird bei Demos gerne übersehen: Ein Wissenssystem sollte nicht jede Frage beantworten müssen.

Wenn die benötigte Information in den freigegebenen Unterlagen nicht vorhanden ist, kann die richtige Antwort schlicht sein:

„Dazu finde ich in den verfügbaren Dokumenten keine belastbare Information.“

Das ist kein Fehler des Systems.

Problematisch wird es erst, wenn das Modell die fehlende Information durch etwas ersetzt, das plausibel klingt.

Technisch lässt sich dieses Verhalten nicht mit einem einzigen Prompt zuverlässig lösen. Gute Systeme kombinieren dafür mehrere Mechanismen – etwa Retrieval-Schwellenwerte, Prüfungen auf ausreichenden Kontext, klare Regeln für unbeantwortbare Fragen und gegebenenfalls einen zusätzlichen Validierungsschritt.

Entscheidend ist nicht, dass das System möglichst oft irgendeine Antwort liefert. Entscheidend ist, dass es unterscheiden kann, wann seine Datenbasis für eine Antwort ausreicht.

So sollte man die Qualität tatsächlich testen

Wir testen Wissenssysteme nicht mit ein paar allgemeinen Beispielprompts, sondern mit Fragen aus dem tatsächlichen Dokumentenbestand.

Für jede Frage ist vorher bekannt, welche Information gefunden werden müsste und welche Quelle sie belegt.

Danach interessiert nicht nur die Gesamtzahl korrekter Antworten. Mindestens drei Ergebnisse sollten getrennt betrachtet werden:

Korrekte Antworten: Die benötigte Information wurde gefunden und korrekt wiedergegeben.

Fehlende Information: Relevante Inhalte wären vorhanden gewesen, wurden vom System aber nicht gefunden oder nicht in die Antwort aufgenommen.

Nicht belegte Aussagen: Die Antwort enthält Informationen, die durch die verfügbaren Quellen nicht ausreichend gestützt werden.

Bei Bedarf lässt sich noch genauer unterscheiden: Hat bereits die Suche versagt? Waren die richtigen Dokumentstellen im Kontext, aber das Modell hat sie falsch verarbeitet? War eine Quellenangabe vorhanden, aber die Quelle passte nicht zur Aussage?

Erst dann wird aus einer einzelnen Erfolgsquote ein brauchbares Bild davon, wo ein System zuverlässig ist und wo nicht.

Sieben Stellen, an denen es schiefgehen kann

Die Trennung in Retrieval- und Grounding-Fehler reicht für ein Anbietergespräch. Wer ein System tatsächlich verbessern will, braucht eine feinere Aufteilung. Die folgenden sieben Stellen lassen sich einzeln prüfen, und genau das tun wir.

1. Suche (Retrieval). Sind die relevanten Fundstellen überhaupt unter den Treffern? Das ist der Fall, der oben als Retrieval-Problem beschrieben ist.
2. Nachsortieren (Reranking). Ein zweiter, genauerer Bewerter ordnet die Treffer neu. Diese Stufe lässt sich getrennt messen, und sie entscheidet darüber, welcher Ausschnitt am Ende beim Sprachmodell ankommt.
3. Fragequalität (Query). Eine unklare oder kontextarme Frage schickt die Suche in die falsche Richtung, bevor der Index überhaupt sinnvoll abgefragt wird.
4. Ausreichender Kontext (Sufficiency). Das System braucht ein Kriterium dafür, ob die gefundenen Informationen für eine vollständige Antwort reichen. Was passiert, wenn es fehlt, steht oben unter „Das System muss auch keine Antwort geben dürfen".
5. Schlussfolgern (Reasoning). Die richtigen Fundstellen im Kontext garantieren noch keine richtige Antwort. Das Modell kann daraus eine falsche Folgerung ziehen.
6. Quellkonflikte (Reconciliation). Widersprechen sich zwei Dokumente, darf das System den Widerspruch nicht glattbügeln. Es muss ihn benennen oder nach einer vorher festgelegten Regel auflösen, etwa zugunsten des jüngeren Dokuments.
7. Zeitbezug (Temporalität). Aktualität gehört zur Antwortqualität. Ein überholtes Dokument liefert Antworten, die formal passen und sachlich falsch sind.

Eine gute Gesamtquote sagt nicht, an welcher dieser Stellen ein System trägt und an welcher es nachgibt. Getrennt geprüft, sagt sie es.

Drei Fragen für ein Anbietergespräch

Wenn du ein KI-Wissenssystem für dein Unternehmen evaluierst, würde ich deshalb nicht zuerst nach einer Genauigkeitsquote fragen.

Interessanter sind diese drei Fragen:

1. Wie trennt ihr Retrieval-Fehler von nicht belegten Aussagen des Sprachmodells?
2. Was antwortet das System, wenn die benötigte Information in meinen Dokumenten nicht vorhanden ist?
3. Kann ich bei einer Aussage sehen, welche konkrete Passage sie belegt?

Noch besser ist es, wenn der Anbieter diese Fragen nicht nur theoretisch beantworten kann, sondern die Ergebnisse anhand eines Testsets aus deinen eigenen Dokumenten zeigt.

Denn ob ein Wissenssystem im Betrieb funktioniert, entscheidet sich nicht daran, ob eine Demo überzeugend wirkt.

Es entscheidet sich an den Fällen, in denen es danebenliegt.

Vor dem Produktivbetrieb testen

Gerade bei Verträgen, internen Richtlinien, technischen Dokumentationen oder regulatorischen Vorgaben ist es wenig sinnvoll, ein Wissenssystem nach Gefühl zu beurteilen.

Deshalb bauen wir für solche Systeme vor der Übergabe ein Testset aus realen Fragen und Dokumenten des Unternehmens auf. Damit lässt sich reproduzierbar prüfen, was gefunden wird, was fehlt und welche Aussagen tatsächlich durch Quellen gedeckt sind.

So entsteht keine theoretische „95-Prozent-Genauigkeit“, sondern ein messbares Bild davon, wie sich das System mit den eigenen Daten verhält.

Wenn du wissen möchtest, wie eine solche Evaluation mit euren Dokumenten aussehen kann, sprich mit uns. Wie eine Zusammenarbeit dabei abläuft, steht auf der Seite zur KI-Beratung.

Häufige Fragen

Wie werden erfundene Antworten verhindert? Vollständig verhindern lässt sich das nicht. Der Anteil lässt sich klein halten und sichtbar machen. Das System bekommt ausschließlich die eigenen Dokumente als Grundlage, belegt jede Aussage mit der Fundstelle und hat eine Regel für den Fall, dass die Grundlage nicht reicht. Ob das im Betrieb hält, zeigt das Testset aus den eigenen Unterlagen.

Woran messe ich, ob es funktioniert? Getrennt an zwei Werten. Wie viele der benötigten Fundstellen das System findet (Trefferquote, Recall), und wie viele Aussagen einer Antwort tatsächlich durch eine Quelle gedeckt sind. Erhoben auf einem Testset aus deinen echten Fragen, nicht auf den Beispielfragen des Anbieters.