uqlm: Unsicherheitsquantifizierung für LLM-Antworten in einer Bibliothek
[JMLR 2026] "UQLM: A Python Package for Uncertainty Quantification in Large Language Models"
Auf einen Blick
- Was ist das?
- uqlm bündelt mehrere Verfahren zur Halluzinationserkennung hinter einer einheitlichen Schnittstelle. Der Nutzen liegt in der Vergleichbarkeit, der Preis in zusätzlichen Modellaufrufen, die je nach Scorer-Klasse stark ins Gewicht fallen.
- Für wen ist es gedacht?
- Wer bereits mehrere Generierungen pro Prompt bezahlt oder Token-Wahrscheinlichkeiten aus dem eigenen Modell ziehen kann, findet in uqlm eine einheitliche Schnittstelle für sehr unterschiedliche Unsicherheitsmaße. Wer ausschließlich gehostete Modelle ohne Logprobs nutzt und keine Mehrfachgenerierungen finanzieren will, sollte vorher prüfen, ob ein einziger Scorer überhaupt sinnvoll einsetzbar 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 1 Tag.
- 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
Welches Problem uqlm adressiert und für wen es gedacht ist
Sprachmodelle liefern Antworten mit derselben äußeren Form, unabhängig davon, ob sie belegt oder erfunden sind. Genau diese Trennung fehlt in der Standardausgabe. uqlm setzt dort an und liefert für jede Antwort einen Confidence-Wert zwischen 0 und 1, wobei höhere Werte laut README eine geringere Fehlerwahrscheinlichkeit anzeigen. Adressiert sind Teams, die LLM-Ausgaben nicht nur erzeugen, sondern bewerten müssen: Evaluierungsgruppen, die mehrere Verfahren gegeneinander stellen wollen, und Anwendungen, in denen eine Antwort unterhalb eines Schwellenwerts aussortiert oder an einen Menschen weitergereicht werden soll. Die Bibliothek ist kein Guardrail im Sinne einer Regel-Engine. Sie produziert Zahlen, und was mit diesen Zahlen geschieht, bleibt Aufgabe der Anwendung. Das ist eine bewusste Arbeitsteilung, verschiebt aber die eigentliche Entscheidung, welcher Schwellenwert akzeptabel ist, in den Integrationscode.
Vier Scorer-Familien mit sehr unterschiedlichen Kostenprofilen
Die README unterscheidet Black-Box-, White-Box-, LLM-as-a-Judge-, Ensemble- und Long-Text-Scorer. Diese Einteilung ist keine Taxonomie um ihrer selbst willen, sondern folgt den Ressourcen, die ein Verfahren verbraucht. Black-Box-Scorer messen die Konsistenz mehrerer Antworten auf denselben Prompt. Sie funktionieren mit jedem Modell, kosten aber mehrere Generierungen plus Vergleiche, was die README als mittlere bis hohe Latenz und hohe Kosten ausweist. White-Box-Scorer lesen Token-Wahrscheinlichkeiten, die das Modell ohnehin zurückgibt. Sie verursachen laut Tabelle keine zusätzlichen Modellaufrufe, setzen aber Zugriff auf diese Wahrscheinlichkeiten voraus. Eine Fußnote schränkt ein: Für White-Box-Scorer mit Mehrfachgenerierung gilt die Kostenfreiheit nicht. LLM-as-a-Judge-Scorer lassen ein Modell die Antwort bewerten, mit geringer bis mittlerer Latenz und Kosten, die von der Zahl der Richter abhängen. Long-Text-Scorer arbeiten auf Aussagenebene und liegen laut Tabelle bei hoher bis sehr hoher Latenz. Wer nur die Scorer-Liste liest und die Kostenspalte übergeht, plant die Integration falsch.
Der Ablauf im Code: ein Objekt, das generiert und bewertet
Das README zeigt den Einstieg über die Klasse BlackBoxUQ, die mit einem LangChain-Chat-Modell und einer Liste von Scorern instanziiert wird. Im Beispiel steht scorers=["semantic_negentropy"]. Der Aufruf generate_and_score erhält die Prompts und num_responses=5. Das Modell erzeugt also fünf Antworten pro Prompt, die Scorer vergleichen sie und liefern daraus einen Wert. Der Parameter use_best=True aktiviert laut README eine Mitigation: Statt nur zu bewerten, wird die Antwort mit der geringsten Unsicherheit ausgewählt. Das ist der architektonisch interessante Punkt. uqlm endet nicht bei der Messung, sondern kann die Messung unmittelbar in die Auswahl zurückspielen. Die Rückgabe ist ein Objekt mit einer to_df-Methode, was darauf hindeutet, dass die Ergebnisse tabellarisch pro Prompt und Scorer vorliegen. Das README nennt als verfügbare Black-Box-Scorer unter anderem Discrete Semantic Entropy, Number of Semantic Sets und Non-Contradiction Probability, jeweils mit Literaturverweisen. Eine vollständige Liste der Klassen und Parameter lässt sich aus dem hier vorliegenden Material nicht rekonstruieren; dafür ist die Dokumentationsseite unter cvs-health.github.io/uqlm die maßgebliche Quelle.
Installation und Modell-Anbindung
Die Installation erfolgt über pip install uqlm. Als Python-Version nennt das Repository 3.10 oder neuer. Für die Modellanbindung nutzt das Beispiel langchain_openai mit ChatOpenAI und dem Modell gpt-4o-mini, wobei das README ausdrücklich festhält, dass jedes LangChain-Chat-Modell verwendet werden kann. Das ist die zentrale Integrationsentscheidung: uqlm bringt keine eigene Modellabstraktion mit, sondern lehnt sich an LangChain an. Wer bereits LangChain einsetzt, hat damit keinen zusätzlichen Adapter zu schreiben. Wer eine eigene Inferenzschicht betreibt, muss prüfen, ob ein passender LangChain-Wrapper existiert oder ob ein solcher selbst geschrieben werden muss. Die Beispiele im Repository liegen als Jupyter-Notebooks vor, etwa examples/black_box_demo.ipynb. Ob diese Notebooks gegen aktuelle Modellversionen unverändert laufen, lässt sich aus dem Material nicht belegen. Der letzte Push liegt laut Repository-Metadaten im September 2026, die letzte Version v0.6.6 stammt vom 3. September 2026.
Wo uqlm an Grenzen stößt
Der offensichtlichste Fall ist ein Modell ohne Logprob-Zugriff hinter einer API, kombiniert mit einem Kostenbudget, das keine Mehrfachgenerierungen erlaubt. Dann bleibt nur der Judge-Ansatz, und der verlagert das Problem: Ein Richtermodell, das selbst halluziniert, erzeugt Confidence-Werte, die nichts über die eigentliche Antwort aussagen. Die README benennt diese Abhängigkeit nicht als Risiko, die Tabelle macht sie aber sichtbar, weil Judge-Scorer als universell kompatibel geführt werden, ohne dass etwas über die Qualität des Richters gesagt wird. Ein zweiter Punkt betrifft die Schwellenwerte. uqlm liefert Werte zwischen 0 und 1, aber keine kalibrierten Grenzen. Wer 0,8 als akzeptabel setzt, hat diese Zahl nicht aus der Bibliothek, sondern aus eigenen Daten. Drittens: Die Konsistenzverfahren unterstellen, dass mehrere Stichproben desselben Modells überhaupt variieren. Bei stark deterministischen Decodierungsparametern sinkt die Aussagekraft, weil die Antworten identisch ausfallen. Das README geht auf Decodierungsparameter an der gezeigten Stelle nicht ein.
Was andere Bibliotheken anders machen
Der naheliegende Vergleich ist mit Evaluierungsframeworks wie DeepEval oder mit spezialisierten Unsicherheitsbibliotheken, die einzelne Verfahren implementieren. Der Unterschied liegt im Zuschnitt. Ein Framework wie DeepEval ist auf Testfälle und Metriken ausgerichtet: Man definiert eine Suite, führt sie gegen ein Modell aus und erhält ein Ergebnis pro Testfall. uqlm ist auf den laufenden Betrieb ausgerichtet und bewertet einzelne Antworten zur Laufzeit, mit der Option, die beste Antwort auszuwählen. Eine Bibliothek, die nur Semantic Entropy implementiert, deckt ein Verfahren ab; uqlm stellt mehrere Verfahren hinter eine gemeinsame Aufrufsignatur, was den Vergleich zwischen ihnen erst praktikabel macht. Der Preis dafür ist eine zusätzliche Abhängigkeit von LangChain und eine API, die sich an dessen Chat-Modell-Schnittstelle bindet. Wer Semantic Entropy ohne LangChain einsetzen will, ist mit einer schlankeren Einzelimplementierung besser bedient.
Wartung, Versionierung und Lizenz
Zwischen v0.6.4 im Juli 2026 und v0.6.6 im September 2026 liegen drei Patch-Releases innerhalb von etwa fünf Wochen. Das deutet auf aktive Pflege hin, sagt aber nichts über die Stabilität der Schnittstelle aus. Vor einem Upgrade sollte man die Release Notes lesen, denn bei einer Bibliothek, die auf externe Modell-APIs und LangChain aufsetzt, können Änderungen an den Abhängigkeiten mehr Wirkung haben als Änderungen am eigenen Code. Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung und Modifikation erlaubt und eine Klausel zu Patenten enthält. Wer die Bibliothek weiterverbreitet oder modifiziert, muss die Bedingungen der Lizenz einhalten, insbesondere Hinweise auf Änderungen. Das ist keine Rechtsberatung, und für den konkreten Fall sollte man die Lizenz im Repository selbst lesen. Ein Hinweis auf Support-Zusagen oder eine Long-Term-Support-Version findet sich im vorliegenden Material nicht.
Redaktionelles Fazit
Wer bereits mehrere Generierungen pro Prompt bezahlt oder Token-Wahrscheinlichkeiten aus dem eigenen Modell ziehen kann, findet in uqlm eine einheitliche Schnittstelle für sehr unterschiedliche Unsicherheitsmaße. Wer ausschließlich gehostete Modelle ohne Logprobs nutzt und keine Mehrfachgenerierungen finanzieren will, sollte vorher prüfen, ob ein einziger Scorer überhaupt sinnvoll einsetzbar ist. Vor dem Produktiveinsatz ist zu klären, ob die im Repository hinterlegten Demos auf die eigene Modellkonfiguration übertragbar sind, denn die Beispiele nutzen ChatOpenAI.
Community-Notizen