vectara/hallucination-leaderboard: eine Rangliste für Halluzinationen beim Zusammenfassen kurzer Dokumente
Leaderboard Comparing LLM Performance at Producing Hallucinations when Summarizing Short Documents
Auf einen Blick
- Was ist das?
- Das Repository vergleicht LLMs anhand der Hallucination Evaluation Model von Vectara und veröffentlicht eine Tabelle mit Halluzinationsrate, faktischer Konsistenz, Antwortquote und durchschnittlicher Zusammenfassungslänge. Der Nutzen liegt in der Messmethode, nicht in der Rangfolge selbst.
- Für wen ist es gedacht?
- Wer ein LLM für Zusammenfassungen kurzer Dokumente auswählt und dafür eine reproduzierbare Kennzahl braucht, findet hier eine dokumentierte Messmethode und die dazugehörigen Modellversionen. Wer Halluzinationen in langen Kontexten, in mehrsprachigen Quellen oder in Werkzeugaufrufen bewerten will, ist mit dieser Rangliste falsch bedient, weil die Aufgabe auf kurze Dokumente und Zusammenfassungen festgelegt ist.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 127 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Frage die Rangliste beantwortet und welche nicht
Die Tabelle beantwortet eine einzige, eng umrissene Frage: Wie oft fügt ein Modell beim Zusammenfassen eines kurzen Dokuments Informationen hinzu, die im Ausgangstext nicht stehen. Gemessen wird mit dem Hallucination Evaluation Model von Vectara, kurz HHEM. Das ist eine andere Fragestellung als die übliche Bewertung von Modellqualität anhand von Benchmarks für Reasoning, Code oder Instruktionsbefolgung. Wer ein Modell für Chat, Agenten oder Codegenerierung sucht, bekommt hier keine Grundlage. Wer ein Modell für Zusammenfassungen einsetzt und dafür eine Zahl braucht, die sich auf eine benannte Aufgabe bezieht, bekommt sie.
Die Zielgruppe ist entsprechend schmal: Teams, die Summarization-Pipelines betreiben und zwischen mehreren Modellen entscheiden müssen, sowie Entwickler, die prüfen wollen, ob ein günstiges Modell für ihren Anwendungsfall ausreicht. Die Antwortquote in der Tabelle ist dabei kein Nebenwert. Modelle wie snowflake/snowflake-arctic-instruct mit 62,7 Prozent oder google/gemma-3-4b-it mit 67,3 Prozent liefern in einem erheblichen Teil der Fälle gar keine Zusammenfassung. Eine niedrige Halluzinationsrate bei gleichzeitig niedriger Antwortquote sagt wenig über die Brauchbarkeit aus.
HHEM als Messinstrument und die vier Spalten der Tabelle
Das Repository enthält selbst kein Auswertungsskript für die Modelle. Es veröffentlicht das Ergebnis der Bewertung durch HHEM, einem Modell von Vectara, das die faktische Übereinstimmung zwischen einem Quelltext und einer Zusammenfassung prüft. Der Datenfluss ist also: Ein Dokument wird einem LLM zur Zusammenfassung vorgelegt, die Ausgabe wird zusammen mit dem Original an HHEM übergeben, und HHEM entscheidet, ob die Zusammenfassung faktisch konsistent ist. Die Halluzinationsrate ist das Komplement der faktischen Konsistenzrate, weshalb beide Spalten zusammen immer 100 Prozent ergeben.
Die vierte Spalte, die durchschnittliche Zusammenfassungslänge in Wörtern, ist die interessanteste und die am leichtesten zu übersehende. Sie reicht von 54,7 Wörtern bei openai/gpt-5.4-mini-2026-03-17 bis 254,4 Wörtern bei openai/gpt-5.1-high-2025-11-13. Ein Modell, das ausführlicher zusammenfasst, hat mehr Gelegenheit, etwas hinzuzufügen. Ob die Rangliste diesen Effekt herausrechnet, geht aus dem vorliegenden Material nicht hervor. Wer zwei Modelle mit stark unterschiedlicher Ausgabelänge vergleicht, sollte diesen Punkt zumindest im Kopf behalten.
Die Antwortquote wird als eigene Spalte geführt, und das ist eine bewusste Designentscheidung. Ohne sie wäre ein Modell, das häufig die Zusammenfassung verweigert, in der Rangliste künstlich gut platziert. Die Tabelle macht diesen Trade-off sichtbar, statt ihn zu verstecken.
Versionsstände: warum die Zahlen nicht über die Zeit vergleichbar sind
Das README benennt zwei frühere Stände ausdrücklich: eine erste Version auf Basis von HHEM-1.0 im Branch hhem-1.0-final und eine neuere Version auf Basis des vorherigen Datensatzes im Branch hhem-2.3-old-dataset. Daraus folgt, dass sich sowohl das Bewertungsmodell als auch der Datensatz im Laufe der Zeit geändert haben. Eine Halluzinationsrate von 6,1 Prozent aus einem älteren Stand ist nicht dieselbe Größe wie 6,1 Prozent im aktuellen Stand.
Das ist für die praktische Nutzung der wichtigste Punkt überhaupt. Wer die Tabelle zitiert, muss den Stand mitliefern. Der Kopf der Tabelle nennt ein Datum, im vorliegenden Material den 11. Mai 2026, und der Plot trägt einen eigenen Zeitstempel im Dateinamen, hier 2026-04-20. Dass Tabelle und Plot unterschiedliche Daten tragen, ist ein Hinweis darauf, dass die Aktualisierung nicht in einem einzigen Schritt erfolgt. Wer den Plot als Beleg für die Tabellenwerte verwendet, kann damit danebenliegen.
Ein Repository ohne veröffentlichte Releases verstärkt das Problem. Es gibt keine Versionsnummer, an der man sich festhalten könnte. Die einzige stabile Referenz sind Branch-Namen wie hhem-2.3-old-dataset.
Was das Repository an Code enthält und was nicht
Die Hauptsprache ist Python, und die Lizenz ist Apache-2.0. Das README beschreibt im Wesentlichen die Ergebnisse und verlinkt auf einen interaktiven Leaderboard auf Hugging Face Spaces unter vectara/leaderboard. Eine Anleitung, wie die Bewertung lokal nachgefahren wird, findet sich im vorliegenden Material nicht. Es gibt keinen dokumentierten Installationsbefehl, keine Konfigurationsschlüssel und keine Beschreibung der Eingabedaten. Wer die Zahlen selbst reproduzieren will, muss sich an das HHEM-Modell von Vectara wenden, das nicht Teil dieses Repositories ist.
Das ist eine Einschränkung, die man klar benennen sollte: Das Projekt ist eine Veröffentlichung von Messergebnissen, kein Werkzeugkasten. Der Nutzen liegt darin, dass die Bewertungsmethode benannt und versioniert ist, nicht darin, dass man sie ohne Weiteres selbst ausführen kann. Wer eine eigene Auswertung über die eigenen Dokumente braucht, wird hier nicht fündig.
Die Apache-2.0-Lizenz erlaubt die kommerzielle Nutzung und die Weitergabe mit den üblichen Bedingungen, darunter die Beibehaltung von Lizenz- und Urheberrechtshinweisen. Das betrifft den Inhalt des Repositories. Für das HHEM-Modell selbst und für die auf Hugging Face gehosteten Modellgewichte gelten eigene Bedingungen, die von der Repository-Lizenz nicht abgedeckt sind. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, wo man vor einer Übernahme nachsehen muss.
Wo die Rangliste in die Irre führt
Die Aufgabe ist auf kurze Dokumente festgelegt. Das steht im Titel des Repositories und wird durch die Beschreibung bestätigt. Ein Modell, das kurze Texte sauber zusammenfasst, kann bei langen Eingaben, bei mehreren Dokumenten oder bei Tabellen ganz anders abschneiden. Die Rangfolge lässt sich nicht auf diese Fälle übertragen.
Der zweite Fehlgebrauch ist die Übertragung auf andere Aufgaben. Eine niedrige Halluzinationsrate beim Zusammenfassen sagt nichts über die Zuverlässigkeit bei Frage-Antwort-Szenarien, bei der Extraktion strukturierter Daten oder bei Werkzeugaufrufen. Die gemessene Größe ist eng definiert, und die Übertragung auf andere Aufgaben ist nicht durch das Material gedeckt.
Der dritte Punkt ist die Rangfolge selbst. Die Abstände zwischen benachbarten Modellen sind klein. Zwischen antgroup/finix_s1_32b mit 1,8 Prozent und openai/gpt-5.4-nano-2026-03-17 mit 3,1 Prozent liegt mehr als ein Prozentpunkt, aber im Mittelfeld liegen viele Modelle innerhalb weniger Zehntelprozentpunkte beieinander. Ob solche Abstände außerhalb des Konfidenzintervalls der Bewertung liegen, lässt sich aus dem vorliegenden Material nicht beantworten. Wer aus einem Rangunterschied von 0,1 Prozentpunkten eine Modellentscheidung ableitet, überinterpretiert die Daten.
Andere Messansätze und der Unterschied in der Methode
Der naheliegende Vergleich ist ein generisches LLM-Benchmark wie MMLU oder ein Bewertungsschema, bei dem ein stärkeres Modell als Richter über die Ausgaben eines anderen urteilt. Der Unterschied liegt nicht im Aufwand, sondern in der Konstruktion. Ein Richter-Modell ist selbst ein Sprachmodell und bringt dessen Fehler mit, und die Bewertung ist schwer zu versionieren, weil sich das Richtermo dell mit jedem Update ändert. HHEM ist dagegen ein fest umrissenes Modell für eine einzige Entscheidung, und das Repository benennt die Version, auf der die Zahlen beruhen. Das ist der eigentliche Grund, warum die Tabelle überhaupt zitierfähig ist.
Der Preis dafür ist die Enge. Ein generisches Benchmark deckt viele Fähigkeiten ab und liefert ein unscharfes Gesamtbild. HHEM liefert eine scharfe Zahl für eine Aufgabe und nichts darüber hinaus. Wer wissen will, ob ein Modell Anweisungen befolgt, Rechenaufgaben löst oder Code schreibt, braucht eine andere Quelle. Wer wissen will, wie oft es beim Zusammenfassen kurzer Dokumente etwas erfindet, bekommt hier eine Antwort mit benannter Methode und benanntem Stand.
Pflegeaufwand und was vor einer Übernahme zu prüfen ist
Das Repository wird regelmäßig aktualisiert. Der letzte Push liegt laut den Metadaten auf dem 11. Mai 2026, und das README kündigt an, dass die Aktualisierung fortgesetzt wird, sobald sich das Bewertungsmodell und die Modelle ändern. Für Nutzer bedeutet das: Die Zahlen, die man heute zitiert, sind in einigen Monaten überholt, und die Aktualisierung erfolgt ohne Versionsnummer, an der man sich festhalten könnte. Wer die Tabelle in einer internen Entscheidungsvorlage verwendet, sollte das Datum und den Branch-Stand mitführen.
Ein Upgrade-Pfad im üblichen Sinn existiert nicht, weil es keinen Code gibt, den man aktualisieren müsste. Der Aufwand liegt beim Nachverfolgen, nicht beim Einbauen. Praktisch heißt das, den Branch-Namen zu notieren, etwa hhem-2.3-old-dataset, wenn man einen älteren Stand zitiert, und beim Wechsel auf einen neuen Stand die Zahlen nicht zu mischen.
Vor jeder Übernahme in eine eigene Entscheidung sind drei Dinge zu prüfen. Erstens, welcher HHEM-Stand den veröffentlichten Zahlen zugrunde liegt. Zweitens, ob die Antwortquote der verglichenen Modelle nahe genug beieinanderliegt, dass der Vergleich sinnvoll ist. Drittens, ob die eigene Aufgabe überhaupt Kurzdokument-Zusammenfassung ist. Wenn nicht, ist diese Rangliste das falsche Werkzeug.
Redaktionelles Fazit
Wer ein LLM für Zusammenfassungen kurzer Dokumente auswählt und dafür eine reproduzierbare Kennzahl braucht, findet hier eine dokumentierte Messmethode und die dazugehörigen Modellversionen. Wer Halluzinationen in langen Kontexten, in mehrsprachigen Quellen oder in Werkzeugaufrufen bewerten will, ist mit dieser Rangliste falsch bedient, weil die Aufgabe auf kurze Dokumente und Zusammenfassungen festgelegt ist. Vor jeder Übernahme in eine eigene Entscheidung ist zu klären, welche HHEM-Version den veröffentlichten Zahlen zugrunde liegt, denn das Repository führt ältere Stände in eigenen Branches wie hhem-1.0-final und hhem-2.3-old-dataset.
Community-Notizen