KI-Chatbot evaluieren: Warum jedes Modell-Update riskant ist

Haben Sie Ihren Chatbot einmal eingerichtet und danach nie wieder überprüft, ob er immer noch gute Antworten liefert? Genau hier liegt ein Problem, das viele Unternehmen unterschätzen. LLM-Modelle ändern sich laufend: neue Versionen, neue Stärken, manchmal überraschende Schwächen. Was gestern tadellos funktioniert hat, kann nach dem nächsten Modell-Update schiefgehen, ohne dass jemand es bemerkt.

In diesem Artikel zeigen wir, wie wir bei ServasBot jede Änderung am Chatbot systematisch evaluieren. Als Werkzeug nutzen wir LangSmith, eine Plattform für das Beobachten, Testen und Verbessern von LLM-Anwendungen. Sie bekommen eine Schritt-für-Schritt-Anleitung mit echtem Python-Code, den Sie direkt nachstellen können.

Was ist LangSmith?

LangSmith ist eine von LangChain entwickelte Observability- und Evaluationsplattform für LLM-Anwendungen. Sie bietet:

• Tracing: Vollständige Aufzeichnung jedes Schritts in Ihrer LLM-Pipeline. Inputs, Outputs, Zwischenschritte, Latenz und Token-Verbrauch.
• Datasets und Experimente: Kuratierte Test-Datensätze, auf denen Sie verschiedene Modelle und Prompts benchmarken können.
• Evaluatoren: Automatische Bewertung der Antwortqualität, regelbasiert oder per LLM-as-a-Judge.
• Annotation Queues: Strukturiertes menschliches Feedback zu Chatbot-Antworten.
• Online Evaluations: Kontinuierliche Qualitätsüberwachung auf produktiven Traces.

Der typische Workflow sieht so aus:

1. Traces im Produktionsbetrieb sammeln
2. Problematische Antworten in Annotation Queues zur manuellen Überprüfung leiten
3. Geprüfte Beispiele zu Datasets hinzufügen
4. Experimente laufen lassen und Modelle oder Prompts vergleichen
5. Verbesserungen in Produktion ausrollen und mit Online Evaluations bestätigen

Dieser Kreislauf ist der Kern eines professionellen Chatbot-Betriebs, und genau das, was bei ServasBot hinter den Kulissen passiert, wenn wir einen Chatbot für Kunden laufend optimieren.

Schritt 1: LangSmith einrichten

Einen Account erstellen Sie auf smith.langchain.com (per GitHub, Discord oder E-Mail). Im Settings-Bereich legen Sie einen API-Key an. Wichtig: Der Key wird nur einmal angezeigt, also sicher verwahren.

Ein Wort zum Modell in den Beispielen. ServasBot läuft standardmäßig auf Mistral, einem europäischen Anbieter, OpenAI lässt sich optional dazuschalten. Weil Mistral einen OpenAI-kompatiblen Endpunkt anbietet, funktioniert derselbe Client-Code für beide Anbieter, es ändern sich nur base_url und Modellname. Genau das macht den Modellvergleich in Schritt 5 später so unkompliziert.

pip install -U langsmith openai

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY="ls_..."
export LANGSMITH_PROJECT="servasbot-evaluation"
export MISTRAL_API_KEY="..."
export OPENAI_API_KEY="sk-..."

Schritt 2: Tracing aktivieren

Tracing ist die Grundlage von allem. LangSmith zeichnet jeden Schritt Ihrer LLM-Pipeline auf, vom eingehenden User-Input bis zur finalen Antwort, inklusive aller Zwischenschritte wie Tool-Aufrufe oder Retrieval-Schritte.

import os

from openai import OpenAI
from langsmith.wrappers import wrap_openai
from langsmith import traceable

# Mistral über den OpenAI-kompatiblen Endpunkt.
# wrap_openai loggt jeden Aufruf automatisch nach LangSmith.
mistral = wrap_openai(OpenAI(
    base_url="https://api.mistral.ai/v1",
    api_key=os.environ["MISTRAL_API_KEY"],
))

SYSTEM_PROMPT = (
    "Du bist ein freundlicher Kundenservice-Assistent "
    "für ein österreichisches KMU. Beantworte Fragen "
    "kurz, präzise und auf Deutsch. "
    "Wenn du dir nicht sicher bist, sage das offen."
)

@traceable  # Die Funktion wird als vollständiger Trace aufgezeichnet
def servasbot_answer(question: str, model: str = "mistral-medium-latest") -> str:
    response = mistral.chat.completions.create(
        model=model,
        temperature=0,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": question},
        ],
    )
    return response.choices[0].message.content

if __name__ == "__main__":
    print(servasbot_answer("Was sind eure Öffnungszeiten?"))

Nach dem Ausführen erscheint der Trace automatisch in LangSmith im Projekt servasbot-evaluation. Sie sehen den exakten System-Prompt, die User-Frage, die Modellantwort sowie Latenz und Token-Verbrauch.

Wer das native Mistral-SDK bevorzugt, kommt mit dem @traceable-Dekorator ebenso ans Ziel. LangSmith erwartet dann die Angabe von Anbieter und Modell als Metadata, etwa @traceable(run_type="llm", metadata={"ls_provider": "mistral", "ls_model_name": "mistral-medium-latest"}).

Ein Trace enthält Spans, also hierarchische Ausführungsschritte. Bei einem einfachen Chatbot sind das zwei: die äußere servasbot_answer-Funktion und der eigentliche Modell-Aufruf. Bei komplexeren Anwendungen wie RAG-Chatbots mit Wissensdatenbank kommt der Retrieval-Schritt mit den gefundenen Dokumenten dazu, was beim Debugging den entscheidenden Unterschied macht.

Multi-Tenant: Traces pro Kunde und Branche separieren

Wer einen Chatbot-Service für mehrere Kunden betreibt (so wie ServasBot mit Fahrschulen, Tourismus-Betrieben und Autohäusern), braucht Tenant-Isolation in den Traces. Ohne Metadata sehen Sie später nur einen großen Topf an Traces, ohne Möglichkeit, branchenspezifische Failure-Patterns zu finden.

Die Lösung: jedem Trace tenant_id und industry als Metadata mitgeben.

from langsmith import traceable

@traceable(metadata={"tenant_id": tenant_id, "industry": industry})
def chat_handler(message: str, tenant_id: str, industry: str):
    # ... Chatbot-Logik
    return servasbot_answer(message)

Alternativ lässt sich Metadata auch zur Laufzeit über RunnableConfig setzen, wenn die Werte erst während der Anfrage bekannt sind. Mit dieser Tagging-Disziplin können Sie später Filter wie „nur Tourismus-Traces mit negativem User-Feedback" oder „alle Fahrschul-Traces des letzten Monats" definieren. Genau das macht Online-Evaluation in Multi-Tenant-Setups erst sinnvoll.

Schritt 3: Das Golden Dataset aufbauen

Ein Golden Dataset ist eine Sammlung von Testfragen mit erwarteten Antworten. Es ist der Maßstab, an dem alle Modelle und Prompt-Varianten gemessen werden.

Wie viele Beispiele brauchen Sie? Bereits 10 bis 50 gut gewählte Beispiele liefern enormen Mehrwert. Wichtiger als die Anzahl ist die Abdeckung: typische Anfragen, Edge Cases und häufige Fehlerquellen.

3a. Dataset in der LangSmith-GUI erstellen

Der einfachste Einstieg geht direkt über die LangSmith-Oberfläche, kein Code nötig:

1. Datasets & Testing in der linken Navigation aufklappen
2. „+ New Dataset" klicken, Namen vergeben (z.B. ServasBot-Goldstandard-v1) und Beschreibung eintragen
3. Dataset öffnen, „+ Add Example" für jeden Testfall: Input (die Nutzerfrage) und Output (die erwartete Referenzantwort) eintippen
4. Speichern, fertig

3b. Der mächtigere Weg: „Add to Dataset" direkt aus einem Trace

In der Praxis wächst ein Golden Dataset selten nur durch manuelles Eintippen. Der schnellere Weg: Sie sehen in der Produktion einen interessanten oder fehlerhaften Trace und übernehmen ihn direkt:

1. Trace in der Trace-Ansicht öffnen (z.B. eine reale Kundenanfrage)
2. Oben rechts „Add to Dataset" klicken
3. Ziel-Dataset auswählen (ServasBot-Goldstandard-v1)
4. Die Referenzantwort bei Bedarf korrigieren, ein Klick, kein Code

Dieser Workflow ist besonders wertvoll, weil echte Nutzerfragen das Dataset mit der Zeit robuster machen als ausgedachte Testfragen. Bei ServasBot fließen Beispiele aus Produktions-Traces automatisch in die Review-Queue und von dort ins Dataset.

3c. Bulk-Import per Code (optional, einmalig)

Für das initiale Seeding aus einer bestehenden FAQ-Datenbank oder CSV-Quelle ist der Python-Weg praktisch. Er läuft einmalig und kann in Git eingecheckt werden:

from langsmith import Client

client = Client()

dataset_name = "ServasBot-Goldstandard-v1"
dataset = client.create_dataset(
    dataset_name,
    description="Goldstandard-Testfälle für ServasBot KMU-Chatbots",
)

client.create_examples(
    dataset_id=dataset.id,
    examples=[
        {
            "inputs": {"question": "Was sind eure Öffnungszeiten?"},
            "outputs": {"answer": "Wir sind Mo bis Fr von 8 bis 18 Uhr für Sie da."},
        },
        {
            "inputs": {"question": "Wie kann ich einen Termin vereinbaren?"},
            "outputs": {"answer": "Telefonisch, per E-Mail oder über unser Kontaktformular."},
        },
        {
            "inputs": {"question": "Liefert ihr auch nach Wien?"},
            "outputs": {"answer": "Ja, wir liefern österreichweit, auch nach Wien."},
        },
        {
            "inputs": {"question": "Kannst du mir Aktien empfehlen?"},
            "outputs": {"answer": "Das ist nicht mein Fachgebiet. Ich helfe bei Fragen zu unserem Unternehmen."},
        },
        {
            "inputs": {"question": "Sprecht ihr auch Englisch?"},
            "outputs": {"answer": "Yes, we also speak English. Feel free to ask in English."},
        },
    ],
)

Nach dem initialen Seeding per Code wird das Dataset in der Regel über die GUI gepflegt, mit dem „Add to Dataset"-Button aus Traces und dem „+ Add Example"-Dialog. Das ist der reale Alltag.

Kategorien für ein solides Golden Dataset

Schritt 4: Evaluatoren definieren

Evaluatoren sind Funktionen, die Chatbot-Antworten automatisch bewerten. LangSmith unterstützt zwei Hauptansätze: code-basiert (deterministisch) und LLM-as-a-Judge (semantisch).

Code-basierte Evaluatoren

Schnell und 100 % reproduzierbar, ideal für strukturelle Checks:

def antwort_nicht_leer(outputs: dict, reference_outputs: dict) -> bool:
    """Prüft, ob eine Antwort überhaupt vorhanden ist."""
    return bool(outputs.get("response", "").strip())

def antwort_nicht_zu_lang(outputs: dict, reference_outputs: dict) -> bool:
    """Antwort soll höchstens doppelt so lang sein wie die Referenzantwort."""
    actual = len(outputs.get("response", ""))
    reference = len(reference_outputs.get("answer", ""))
    return actual < 2 * reference if reference > 0 else actual < 500

def keine_halluzinierten_links(outputs: dict, reference_outputs: dict) -> bool:
    """Prüft, ob keine URLs in der Antwort enthalten sind."""
    import re
    response = outputs.get("response", "")
    return not bool(re.search(r'https?://', response))

LLM-as-a-Judge (semantisch)

Ein LLM bewertet die Qualität der Antwort anhand eines Rubrik-Prompts. Ähnlich einem menschlichen Reviewer, aber skalierbar. In der MT-Bench-Studie von Zheng et al. (NeurIPS 2023) erreichte GPT-4 als Judge über 80 % Übereinstimmung mit menschlichen Bewertern. Das ist genau das Niveau, das auch zwischen Menschen untereinander beobachtet wird.

import openai
from langsmith.wrappers import wrap_openai

eval_client = wrap_openai(openai.OpenAI())

def korrektheit(inputs: dict, outputs: dict, reference_outputs: dict) -> bool:
    """LLM-as-a-Judge: Ist die Antwort inhaltlich korrekt?"""
    prompt = f"""Du bist ein Qualitätsprüfer für Chatbot-Antworten.

Frage des Nutzers:
{inputs['question']}

Erwartete Antwort (Goldstandard):
{reference_outputs['answer']}

Tatsächliche Chatbot-Antwort:
{outputs['response']}

Ist die tatsächliche Antwort inhaltlich korrekt und hilfreich im Sinne der erwarteten Antwort?
Antworte NUR mit: KORREKT oder FALSCH"""

    result = eval_client.chat.completions.create(
        model="gpt-4o-mini",
        temperature=0,
        messages=[{"role": "user", "content": prompt}],
    ).choices[0].message.content.strip()

    return result == "KORREKT"

In der LangSmith-UI: Alternativ konfigurieren Sie denselben LLM-as-Judge direkt in der Oberfläche. Evaluators → „+ New Evaluator" → Template LLM-as-Judge → Prompt-Vorlage anpassen (mit Platzhaltern für inputs, outputs, reference_outputs) → Modell wählen → Output-Schema festlegen (z.B. boolean correct). Kein Python nötig, die Bewertung läuft in LangSmith.

Goldene Regeln für gute Evaluatoren

1. Binär oder niedrige Granularität bevorzugen. „Korrekt/Falsch" ist zuverlässiger als eine 1-bis-10-Skala.
2. Chain-of-Thought im Evaluator-Prompt. Begründungen verbessern die Konsistenz.
3. Few-Shot-Beispiele einbauen. Zeigen Sie dem LLM-Richter konkrete Beispiele für gut und schlecht.
4. Mit menschlichem Feedback kalibrieren. Sammeln Sie manuelle Korrekturen und vergleichen Sie sie mit dem Evaluator.
5. Separates Modell für Evaluation verwenden. Dasselbe Modell, das die Antwort generiert, sollte sie nicht selbst bewerten.

Schritt 5: Experimente und Modellvergleich

Jetzt kommt der Kern: verschiedene Modelle gegen dasselbe Golden Dataset testen. Weil Mistral und OpenAI beide über einen OpenAI-kompatiblen Client ansprechbar sind, unterscheiden sich die zwei Zielfunktionen nur in base_url und Modellnamen.

import os

from openai import OpenAI
from langsmith.wrappers import wrap_openai
from langsmith import evaluate

mistral = wrap_openai(OpenAI(
    base_url="https://api.mistral.ai/v1",
    api_key=os.environ["MISTRAL_API_KEY"],
))
openai_client = wrap_openai(OpenAI())  # nutzt OPENAI_API_KEY

def _antwort(client, model: str, question: str) -> dict:
    response = client.chat.completions.create(
        model=model,
        temperature=0,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": question},
        ],
    )
    return {"response": response.choices[0].message.content}

def servasbot_mistral(inputs: dict) -> dict:
    return _antwort(mistral, "mistral-medium-latest", inputs["question"])

def servasbot_gpt(inputs: dict) -> dict:
    return _antwort(openai_client, "gpt-4o-mini", inputs["question"])

EVALUATORS = [antwort_nicht_leer, antwort_nicht_zu_lang, korrektheit]

# Experiment 1: der aktuelle Produktionsstand als Baseline
evaluate(
    servasbot_mistral,
    data="ServasBot-Goldstandard-v1",
    evaluators=EVALUATORS,
    experiment_prefix="mistral-medium-baseline",
)

# Experiment 2: der Kandidat, gegen dasselbe Dataset
evaluate(
    servasbot_gpt,
    data="ServasBot-Goldstandard-v1",
    evaluators=EVALUATORS,
    experiment_prefix="gpt-4o-mini-kandidat",
)

Experimente vergleichen: In LangSmith markieren Sie mehrere Experimente und klicken Compare. Die Side-by-Side-Vergleichsansicht zeigt pro Testfall die Antworten beider Modelle nebeneinander, darunter die Evaluator-Scores farbcodiert.

• 🟢 Grün: Verbesserung gegenüber Baseline
• 🔴 Rot: Regression, also Verschlechterung
• Grau: keine signifikante Änderung

Der Punkt an dieser Ansicht: Ein Durchschnittswert über alle Testfälle kann sich verbessern, während ein einzelner wichtiger Fall kaputtgeht. Die Zeilenansicht zeigt genau das, ein aggregierter Score verdeckt es.

Warum bei jedem LLM-Update neu evaluieren?

Das ist die zentrale Frage für jeden, der Chatbots produktiv betreibt. Die kurze Antwort: Ein LLM-Update verändert das Verhalten Ihres Chatbots, und ob diese Veränderung eine Verbesserung ist, entscheidet sich erst an Ihren eigenen Anwendungsfällen.

Das klassische Beispiel: der stille Regressions-Fehler

Ein Chatbot antwortet korrekt auf Fragen auf Englisch. Nach einem Modell-Update plötzlich immer auf Englisch, auch wenn der Nutzer auf Deutsch fragt. Ohne systematische Evaluation fällt das erst auf, wenn sich Kunden beschweren. Mit einem Golden Dataset und automatisierten Experimenten in LangSmith fällt es auf, bevor das Update live geht.

Die meisten KMU-Chatbots laufen ohne Evaluation. Man sieht es daran, dass sie nach sechs Monaten schlechter beantworten als am Tag des Livegangs. Nur merkt es niemand, weil niemand misst. Kunden beschweren sich selten, sie gehen einfach zur Konkurrenz.

Die Falle mit den „-latest"-Aliassen

Anbieter stellen praktische Aliase bereit: mistral-medium-latest, mistral-small-latest und ähnliche. Wer die im Produktionscode stehen hat, bekommt neue Modellversionen automatisch, ohne einen einzigen Deploy. Das ist bequem und genau deshalb riskant, weil sich das Verhalten Ihres Chatbots ändern kann, während Sie nichts angegriffen haben.

Die saubere Variante: In Produktion die versionierte Modell-ID festnageln (Mistral vergibt dafür datierte Kennungen wie mistral-medium-2604), und den Wechsel auf eine neue Version erst nach einem Experiment auf dem Golden Dataset vollziehen. Dann entscheiden Sie, wann sich das Verhalten ändert.

Wann muss neu evaluiert werden?

• Bei jedem Modell-Update innerhalb desselben Anbieters
• Bei einem Anbieterwechsel (z.B. Mistral → OpenAI oder Anthropic), siehe Chatbot-Anbieter wechseln
• Bei Prompt-Änderungen (neuer System-Prompt, neue Anweisungen)
• Bei Änderungen in der Wissensdatenbank (neues Firmenwissen, geänderte Preise)
• Bei neuen Anwendungsfällen (neuer Bereich, neue Sprache)
• Regelmäßig im Produktionsbetrieb (mindestens monatlich)

Bei ServasBot gehört Evaluation zum laufenden Service. Jede Änderung am Chatbot-System wird gegen das Golden Dataset getestet, bevor sie beim Kunden live geht.

Genau dieser Aufwand ist der Grund, warum viele Chatbot-Anbieter Evaluation gar nicht leisten. Der Verkauf ist schnell erledigt, die Qualität über Jahre zu halten kostet dauerhaft Zeit.

Schritt 6: Online Evaluation im Produktionsbetrieb

Offline-Evaluation ist wichtig, aber sie hat eine Lücke: Sie testet nur die Fragen, die Sie sich schon ausgedacht haben. Echte Nutzer sind kreativer. Deshalb braucht es Online Evaluation, also automatische Bewertung auf Live-Traffic.

Online-Evaluatoren werden direkt im LangSmith-UI konfiguriert:

1. Links Tracing Projects → Ihr Projekt auswählen
2. Oben rechts „+ New" → „New Evaluator"
3. Evaluator benennen (z.B. „Ton-Kontrolle Produktion")
4. Filter setzen: Alle Traces, nur mit negativem User-Feedback, oder bestimmte Metadaten-Tags
5. Sampling Rate konfigurieren (z.B. 0.2 für 20 % der Traces, zur Kostenkontrolle)
6. Evaluator-Logik definieren: LLM-as-Judge oder Custom Code

Was überwachen wir bei ServasBot in Produktion?

• Hallucination Check: Antwortet der Bot mit Fakten, die nicht in seiner Wissensdatenbank stehen?
• Out-of-Scope Detection: Versucht der Bot Fragen zu beantworten, für die er nicht ausgerüstet ist?
• Ton-Qualität: Bleibt der Bot freundlich und professionell?
• Antwortlänge: Werden Antworten plötzlich zu lang oder zu kurz?
• Spracherkennung: Antwortet der Bot in der richtigen Sprache?

Schritt 7: Annotation Queues für menschliches Feedback

Nicht alles kann ein Algorithmus beurteilen. Für feine Nuancen (Ist die Antwort wirklich hilfreich? Passt der Ton zur Marke?) braucht es menschliches Feedback. LangSmith bietet dafür Annotation Queues: Traces werden in eine Warteschlange gelegt und können dort strukturiert bewertet werden.

Besonders mächtig: Automation Rules schicken Traces automatisch in die Queue, zum Beispiel alle Traces mit negativem User-Feedback, alle mit schlechter Online-Evaluator-Bewertung oder stichprobenartig 5 % aller Traces. Die geprüften Traces können danach ins Golden Dataset übernommen werden, wodurch das Dataset mit echten Produktionsfällen wächst.

In der LangSmith-UI: Links Annotation Queues → „+ New Queue" → Name und Rubrik-Items definieren (z.B. Korrektheit als Pass/Fail, Ton-Qualität als 1–5-Skala, Anmerkungen als Freitext). Danach Queue öffnen: Sie sehen einen Trace nach dem anderen mit Chatbot-Antwort und den Rubrik-Feldern zum Ausfüllen. Durchklicken, bewerten, nächste.

Schritt 8: Prompt Versioning mit dem LangSmith Prompt Hub

System Prompts sind das Herzstück eines jeden LLM-Chatbots. Wenn Sie sie ohne Versionierung ändern, verlieren Sie die Nachvollziehbarkeit. Der Prompt Hub in LangSmith löst das:

• Jede Änderung am Prompt wird als neuer Commit gespeichert
• Sie können Tags setzen: production, staging, v2-test
• Ihr Code referenziert immer den Tag, nicht eine hardcodierte Version
• Sie verschieben den Tag auf einen neueren Commit, ohne den App-Code zu ändern

from langsmith import Client

ls_client = Client()

# Prompt abrufen (immer die aktuell getaggte Produktion-Version)
prompt = ls_client.pull_prompt("servasbot/kmu-chatbot:production")

# Im Code verwenden
messages = prompt.invoke({
    "company_name": "Muster GmbH",
    "opening_hours": "Mo-Fr 8-18 Uhr",
}).to_messages()

Schritt 9: LangSmith CLI und Skills für Coding Agents

LangChain hat 2026 zwei neue Tools veröffentlicht, die das Arbeiten mit Traces direkt aus dem Terminal und aus Coding-Agents wie Claude Code möglich machen: die LangSmith CLI und drei LangSmith Skills (trace, dataset, evaluator). Damit sieht ein Coding-Agent zusätzlich zum Code auch das tatsächliche Verhalten in Produktion.

Der Effekt ist messbar. Laut LangChains eigener Evaluation springt Claude Code auf LangSmith-Tasks von 17 % auf 92 % Lösungsquote, sobald die Skills installiert sind. Hinweis: Es handelt sich um einen In-House-Benchmark des Anbieters, nicht um eine unabhängige Studie. Die Größenordnung ist plausibel, weil ein Agent, der Traces lesen kann, Probleme realitätsnah debugged, während ein Agent ohne Trace-Zugriff rät.

Installation

# LangSmith CLI installieren
curl -sSL https://raw.githubusercontent.com/langchain-ai/langsmith-cli/main/scripts/install.sh | sh

# Auth mit LangSmith API Key
langsmith auth login

# Skills global für Claude Code installieren
npx skills add langchain-ai/langsmith-skills \
    --agent claude-code --skill '*' --yes --global

Drei Skills werden gepullt: trace, dataset, evaluator. Damit hat Claude Code im Repo direkten Terminal-Zugriff auf LangSmith. Ein typischer Use Case: „Schau dir die letzten 50 Traces mit negativem Feedback an, identifiziere die häufigsten Failure-Patterns, schlage Korrektur-Beispiele für das Golden Dataset vor."

Bei ServasBot ist das die Brücke zwischen Tracing-Daten und automatisierter Code-Optimierung. Der Agent sieht, was der Bot tatsächlich antwortet, nicht nur was im Code steht.

Praxis-Roadmap: In 4 Phasen zum Evaluations-Setup

Theorie ist nett, aber wie setzt man das konkret auf? Hier die Reihenfolge, die ich für ein neues Multi-Tenant-Setup empfehle:

Phase 1: CLI und Skills installieren (≈ 30 Minuten)

Siehe Schritt 9. Damit ist der Coding-Agent vorbereitet, mit echten Trace-Daten zu arbeiten.

Phase 2: Tracing-Audit und Metadata-Patches (1 bis 2 Stunden)

Bestehende Coverage prüfen: Sind alle relevanten Funktionen mit @traceable dekoriert? Werden tenant_id und industry als Metadata mitgegeben? Falls nein, nachrüsten und deployen. Ohne saubere Metadata sind alle späteren Schritte wertlos.

Phase 3: Online Evaluators einrichten (≈ 1 Stunde)

Im LangSmith-UI unter Tracing Projects → Rules drei Evaluators anlegen:

• DSGVO-Compliance (LLM-as-Judge, 100 % Sample, Filter environment=production): prüft, ob Antworten personenbezogene Daten korrekt behandeln und keine Cross-Tenant-Leaks passieren.
• Branchen-Tone (LLM-as-Judge, 20 % Sample, gruppiert nach industry): prüft Tonalität pro Branche (formell für Autohaus, freundlich für Tourismus, sachlich für Fahrschule).
• Tool Correctness (Code-based, 100 % Sample): validiert Schema und Parameter aller Tool-Calls deterministisch.

Wichtig: alle Evaluators auf environment=production filtern. Sonst frisst Dev-Traffic Budget.

Phase 4: Annotation Queue (≈ 30 Minuten Setup)

Eine Queue mit folgendem Filter anlegen:

feedback.thumbs_down = true OR DSGVO_Compliance_Score < 0.7

Workflow: alle paar Tage 10 bis 20 Traces durchgehen, korrekte Antwort labeln. Diese werden Ground-Truth für die Offline-Eval-Suite. Reviewer-Profil: zuerst Domain-Expert (oder ich selbst pro Tenant), optional der Kunde für branchenspezifisches Feedback.

Followup (nicht Tag eins)

• Offline-Eval-Suite pro Tenant aus annotierten Traces aufbauen (Richtwert: 50 annotierte Traces pro Tenant für ein erstes brauchbares Dataset)
• CI/CD-Gate im Deployment integrieren (Eval-Suite muss grün sein vor Release)
• Insights Agent auf Production-Traces laufen lassen für Intent-Cluster pro Branche

Der vollständige Evaluations-Kreislauf

Zusammengefasst läuft die Qualitätssicherung bei ServasBot in diesem Kreislauf:

1. Produktion: Traces werden im laufenden Betrieb gesammelt.
2. Online Evaluation: Auffällige Antworten werden automatisch markiert.
3. Annotation Queue: Ein Mensch prüft und korrigiert die markierten Fälle.
4. Golden Dataset: Die geprüften Beispiele werden zum neuen Maßstab.
5. Offline-Experiment: Ein neues Modell oder ein neuer Prompt läuft gegen diesen Maßstab.
6. Vergleich und Entscheidung: Bei einer Regression wird die Änderung verworfen, bei einer Verbesserung ausgerollt.
7. Rollout: Die Online Evaluation bestätigt im Echtbetrieb, dass die Verbesserung hält. Danach beginnt die Runde von vorn.

In Zahlen: Initial-Setup (Golden Dataset, Evaluatoren, erste Experimente) rund 1 bis 2 Tage pro Chatbot. Laufender Betrieb: 2 bis 4 Stunden pro Woche für Trace-Review, Queue-Bearbeitung, neue Dataset-Einträge und Experimente nach jedem Modell- oder Prompt-Update.

Dieser Kreislauf unterscheidet einen Chatbot, der einmal eingerichtet wurde, von einem Chatbot, der laufend besser wird. Er gehört zum Wochenrhythmus und lässt sich nicht in ein abgeschlossenes Projekt packen.

Wer das nebenbei zum operativen Geschäft machen will, hält es nicht lange durch.

Bonus: CI/CD-Integration für Entwickler-Teams

Für Teams mit CI/CD lässt sich der Evaluations-Kreislauf direkt in die Pipeline integrieren. Ein einfaches Pytest-Beispiel:

# test_chatbot_quality.py
from langsmith import evaluate

def test_korrektheit_mindest_score():
    """Chatbot muss mindestens 80 % Korrektheit auf dem Goldstandard erreichen."""
    results = evaluate(
        servasbot_mistral,
        data="ServasBot-Goldstandard-v1",
        evaluators=[korrektheit],
        experiment_prefix="ci-test",
    )

    # ExperimentResults ist iterierbar, jede Zeile enthält die Ergebnisse
    # aller Evaluatoren. Gezielt nach dem Key filtern, damit weitere
    # Evaluatoren das Ergebnis nicht verfälschen.
    scores = [
        result.score
        for row in results
        for result in row["evaluation_results"]["results"]
        if result.key == "korrektheit" and result.score is not None
    ]

    assert scores, "Keine Bewertungen erhalten, läuft der Evaluator?"

    avg_score = sum(scores) / len(scores)
    assert avg_score >= 0.8, (
        f"Korrektheit nur {avg_score:.1%}, mindestens 80 % erforderlich!"
    )

Wenn ein Modell-Update die Korrektheit unter 80 % drückt, bricht der CI-Build, und der Rollout wird gestoppt. Kein Regression erreicht Produktion, ohne gesehen worden zu sein.

Was Sie jetzt tun können

Egal ob Sie Ihren ersten Chatbot bauen oder einen bestehenden verbessern wollen, diese Schritte helfen sofort:

1. LangSmith-Account anlegen und Tracing aktivieren (15 Minuten)
2. 10 bis 20 Golden-Dataset-Beispiele für Ihren Use Case erstellen
3. Einen einfachen Code-Evaluator implementieren (z.B. Antwort nicht leer)
4. Erstes Experiment auf dem Dataset laufen lassen
5. Beim nächsten Modell-Update: zweites Experiment und vergleichen

Quellen und weiterführende Links

• Zheng et al. (NeurIPS 2023): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — peer-reviewte Primärquelle für die über 80 %-Übereinstimmung zwischen GPT-4 als Judge und menschlichen Bewertern.
• LangChain: The agent improvement loop starts with a trace — Vendor-Blog, nützlich für die Workflow-Konzepte.
• LangChain: LangSmith CLI & Skills — Quelle der 17-%-zu-92-%-Zahl. In-House-Benchmark des Anbieters, nicht unabhängig validiert.
• LangSmith: Trace Mistral applications — offizieller Weg, Mistral-Aufrufe zu instrumentieren.
• LangSmith-Dokumentation — offizielle API- und UI-Dokumentation.

Verwandte Artikel

• Warum Ihr KI-Chatbot laufende Betreuung braucht
• Was kostet ein KI-Chatbot für Unternehmen?
• DSGVO und KI: Was KMU wissen müssen
• EU-Hosting vs. US-Cloud: Warum der Serverstandort zählt
• Chatbot-Anbieter wechseln: Was, wenn die KI teurer wird?