LLM-Aufrufe nachvollziehbar machen — im eigenen Haus

TL;DR

Wenn ein Nutzer sagt "die Antwort war falsch", brauchen Sie drei Dinge: die Frage, die abgerufenen Abschnitte und die Antwort — zusammen, mit Zeitstempel. Ohne diese Zusammenschau ist Fehlersuche Raten. Langfuse liefert das selbst betrieben, mit Docker Compose in einer Stunde. Die eigentliche Arbeit ist die Regelung, was protokolliert werden darf.

Das Problem, das Kennzahlen nicht lösen

Ihre Überwachung zeigt: Alle Dienste laufen, Antwortzeiten im Rahmen, GPU-Auslastung normal.

Und eine Fachabteilung meldet, dass die Antworten zu Prüfintervallen seit einer Woche falsch sind.

Standardüberwachung hilft hier nicht. Sie misst, ob Systeme laufen, nicht ob sie Sinn ergeben. Was Sie brauchen, ist die Möglichkeit, eine konkrete Anfrage nachzuvollziehen: Was wurde gefragt, welche Abschnitte kamen aus dem Abruf, welcher Prompt ging ans Modell, was kam zurück, wie lange dauerte jeder Schritt.

In den meisten Fällen, die wir untersucht haben, war die Antwort in Schritt zwei zu finden: Der Abruf lieferte die falschen Abschnitte. Ohne Nachverfolgung hätte man das Modell gewechselt und nichts verbessert.

Der Aufbau

# docker-compose.yml
services:
  langfuse:
    image: langfuse/langfuse:latest
    depends_on: [langfuse-db]
    environment:
      DATABASE_URL: postgresql://langfuse:${DB_PASS}@langfuse-db:5432/langfuse
      NEXTAUTH_URL: https://trace.intern
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      SALT: ${SALT}
      # Keine Registrierung von außen, keine Telemetrie
      AUTH_DISABLE_SIGNUP: 'true'
      TELEMETRY_ENABLED: 'false'
    restart: unless-stopped

  langfuse-db:
    image: postgres:17
    environment:
      POSTGRES_USER: langfuse
      POSTGRES_PASSWORD: ${DB_PASS}
      POSTGRES_DB: langfuse
    volumes: ["langfuse-data:/var/lib/postgresql/data"]
    restart: unless-stopped

volumes: { langfuse-data: }

TELEMETRY_ENABLED: 'false' ist der Schalter, den Sie bewusst setzen sollten. Voreingestellt melden viele Werkzeuge Nutzungsdaten an ihre Hersteller — bei einer Installation, die gerade wegen Datenhoheit im eigenen Haus steht, ist das ein Widerspruch.

Die Anbindung an das Gateway ist eine Zeile:

# LiteLLM config.yaml
litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

Damit läuft jeder Modellaufruf über das Gateway automatisch in die Nachverfolgung — ohne dass eine einzelne Anwendung angepasst werden muss. Das ist der Grund, warum das Gateway die richtige Stelle dafür ist.

Was Sie zusätzlich protokollieren sollten

Der Modellaufruf allein reicht nicht. Der interessante Teil ist der Abruf davor:

from langfuse.decorators import observe, langfuse_context

@observe(name="rag-anfrage")
def frage_beantworten(frage: str, nutzer_gruppen: list[str]) -> str:
    abschnitte = abrufen(frage, nutzer_gruppen)

    # Der Schritt, der bei der Fehlersuche fast immer die Antwort liefert
    langfuse_context.update_current_observation(
        metadata={
            "treffer": [
                {"id": a.id, "score": round(a.score, 3),
                 "quelle": a.payload["quelle"]}
                for a in abschnitte
            ],
            "gruppen": nutzer_gruppen,
        }
    )
    return modell_aufrufen(prompt_bauen(frage, abschnitte))

Die Bewertungswerte der Treffer sind dabei das Wertvollste. Wenn der beste Treffer bei 0,31 liegt, hat der Abruf nichts Passendes gefunden — und das Modell hat trotzdem geantwortet. Das ist die häufigste Ursache für falsche Auskünfte, und man sieht sie in einer Zeile.

Was protokolliert werden darf

Der Teil, der länger dauert als die Installation.

Ein vollständiges Aufrufprotokoll enthält die Frage eines identifizierbaren Nutzers mit Zeitstempel. Das ist eine personenbezogene Verarbeitung und ermöglicht eine Leistungs- und Verhaltenskontrolle — damit mitbestimmungspflichtig nach Betriebsverfassungsgesetz.

Was sich in der Praxis bewährt hat:

Aufbewahrungsfrist festlegen und durchsetzen. 30 Tage für vollständige Inhalte, danach nur noch aggregierte Kennzahlen. Automatisiert, nicht als Vorsatz.

Nutzerkennung pseudonymisieren. Für die Fehlersuche brauchen Sie meist nicht den Namen, sondern nur die Unterscheidbarkeit von Sitzungen. Eine Kennung, die sich täglich ändert, reicht für die technische Analyse und ist deutlich weniger eingriffsintensiv.

Zugriff auf die Nachverfolgung begrenzen. Nicht die ganze IT — die benannten Plattform-Verantwortlichen. Über die Verzeichnisgruppe, nicht über lokale Konten.

Transparenz gegenüber den Nutzern. Schreiben Sie in die Oberfläche, dass Anfragen zur Qualitätssicherung protokolliert werden und wie lange. Verdeckte Protokollierung zerstört das Vertrauen in die Plattform schneller als jeder technische Fehler.

Und der Punkt, der zuerst kommt: Klären Sie das mit dem Betriebsrat, bevor Sie produktiv gehen. Eine nachträgliche Regelung ist deutlich mühsamer als eine vorherige.

Was Sie damit tatsächlich tun

Drei wiederkehrende Anwendungen aus Projekten:

Beschwerden nachvollziehen. "Die Antwort war falsch" wird zu "Der Abruf lieferte einen Abschnitt aus der Fassung von 2019, weil die aktuelle nicht indexiert war."

Kontextlänge prüfen. Die Verteilung der Eingabe-Token zeigt, wo zu viel mitgeschickt wird — der größte Kostenhebel, wie im Beitrag zum Senken der Token-Kosten beschrieben.

Anwendungsfälle erkennen. Welche Fragen werden tatsächlich gestellt? Die Verteilung ist regelmäßig eine andere als die bei der Einführung angenommene — und der beste Hinweis darauf, wo weiter investiert werden sollte.

Häufig gestellte Fragen

Warum reicht normale Anwendungsüberwachung für KI-Systeme nicht?

Weil sie misst, ob Dienste laufen, nicht ob die Antworten stimmen. Ein RAG-System kann bei perfekten technischen Kennzahlen systematisch falsche Auskünfte geben, etwa weil der Abruf veraltete Dokumente liefert. Dafür brauchen Sie eine Nachverfolgung, die Frage, abgerufene Abschnitte und Antwort zusammen festhält.

Was ist bei der Protokollierung von Nutzeranfragen zu beachten?

Ein Aufrufprotokoll mit Nutzerkennung und Zeitstempel ermöglicht eine Leistungs- und Verhaltenskontrolle und ist damit mitbestimmungspflichtig. Legen Sie vor der Einführung eine Aufbewahrungsfrist fest, pseudonymisieren Sie die Nutzerkennung, begrenzen Sie den Zugriff auf benannte Verantwortliche und weisen Sie die Nutzer in der Oberfläche darauf hin.

Wie binde ich die Nachverfolgung an, ohne jede Anwendung anzupassen?

Über das Gateway. Wenn alle Modellaufrufe dort durchlaufen, genügt eine Konfigurationszeile, um sie vollständig zu erfassen. Anzupassen ist nur der Abrufschritt davor, weil das Gateway ihn nicht sieht — und genau dieser Schritt liefert bei der Fehlersuche meist die Antwort.

Welche Informationen sind bei der Fehlersuche am wertvollsten?

Die Bewertungswerte der abgerufenen Abschnitte. Wenn der beste Treffer weit unter dem üblichen Niveau liegt, hat der Abruf nichts Passendes gefunden und das Modell hat trotzdem geantwortet — die häufigste Ursache für falsche Auskünfte. Ohne diese Werte im Protokoll sieht man nur das Ergebnis und nicht die Ursache.

Muss die Nachverfolgung im eigenen Haus laufen?

Wenn die Anfragen und Dokumentinhalte das Haus nicht verlassen dürfen, ja — die Nachverfolgung enthält genau diese Inhalte im Klartext. Ein cloudbasiertes Werkzeug in einer sonst lokal betriebenen Kette ist ein Bruch in der Argumentation. Der Selbstbetrieb ist mit Docker Compose in etwa einer Stunde eingerichtet.

Der nächste Schritt

Schalten Sie die Nachverfolgung ein und schauen Sie sich eine Woche später zwanzig zufällige Anfragen an — mit den Bewertungswerten des Abrufs. Was Sie dort sehen, verändert Ihre Prioritätenliste zuverlässiger als jede Planung. Beim Aufbau unterstützen wir gern.