Evals sind der einzige Moat: Enterprise-KI-Strategie auf Feedback-Loops aufbauen

Wer KI im Unternehmen einführt, stellt sich früher oder später die falsche Frage. Nicht „welches Modell?” – sondern „wie wissen wir, ob es funktioniert?”

In der Enterprise-KI-Debatte dominiert eine Obsession mit Modellqualität. GPT-5.5 oder Qwen3? Claude oder Gemini? Diese Frage ist in 80 % der Fälle zweitrangig. Was Unternehmen, die KI wirklich produktiv einsetzen, von jenen unterscheidet, die noch in der Pilot-Phase feststecken, ist nicht das Modell: Es ist die Fähigkeit, Vertrauen systematisch zu messen und zu reproduzieren.

Vertrauen in ein KI-System ist kein Gefühl. Es ist eine Messgröße. Und wer sie nicht erhebt, baut auf Sand.

Die Vertrauensfrage ist keine philosophische

Stellen Sie sich ein internes RAG-System vor, das Mitarbeiter mit Informationen aus internen Dokumenten versorgt. Das Modell antwortet flüssig, die Nutzer sind zufrieden, das Dashboard zeigt Adoption. Klingt nach Erfolg.

Was das Dashboard nicht zeigt: 23 % der Antworten sind nicht durch die abgerufenen Dokumente gedeckt – das Modell halluziniert plausibel. 14 % der abgerufenen Chunks sind irrelevant für die eigentliche Frage. Und niemand weiß es, weil niemand misst.

Das ist kein Randproblem. Das ist der Normalfall in Enterprise-KI-Deployments ohne strukturierte Evaluation. Und wenn der erste Mitarbeiter eine falsche Antwort ungeprüft weitergibt – und das passiert – ist der Vertrauensschaden schwer zu reparieren.

RAGAS: Qualität sichtbar machen

RAGAS (Retrieval Augmented Generation Assessment) ist das de-facto-Evaluierungsframework für RAG-Systeme. Es quantifiziert Qualitätsdimensionen, die sonst nur intuitiv bewertet werden:

Faithfulness misst, ob die Antwort tatsächlich in den abgerufenen Dokumenten gedeckt ist. Ein Wert unter 0,7 bedeutet: Das Modell erfindet, zumindest in Teilen. Context Precision und Context Recall messen, ob die Retrieval-Stufe die richtigen Dokumente findet – und ob sie relevante Dokumente vermisst. Response Relevancy prüft, ob die Antwort überhaupt die gestellte Frage beantwortet.

Der DSGVO-freundliche Aspekt: RAGAS funktioniert mit lokal betriebenen Evaluator-Modellen. Wer Ollama ohnehin betreibt, kann Llama 3.3 70B als Judge einsetzen – kein einziges Prompt verlässt das Haus.

from ragas import evaluate
from ragas.metrics import Faithfulness, ResponseRelevancy, ContextPrecision
from ragas.llms import LangchainLLMWrapper
from langchain_ollama import ChatOllama

evaluator_llm = LangchainLLMWrapper(
    ChatOllama(model="llama3.1:70b", base_url="http://localhost:11434")
)

result = evaluate(
    dataset=evaluation_dataset,
    metrics=[Faithfulness(), ResponseRelevancy(), ContextPrecision()],
    llm=evaluator_llm,
)
# {'faithfulness': 0.72, 'response_relevancy': 0.88, 'context_precision': 0.81}

Ein Faithfulness-Wert von 0,72 ist kein Zertifikat, dass alles stimmt. Es ist der Ausgangspunkt: Warum sind 28 % der Antworten nicht vollständig durch den Kontext gedeckt? Liegt es am Chunking? Am Top-K-Wert? Am Prompt-Template? RAGAS zeigt das Problem. Das Team muss es beheben. Genau das ist der Feedback-Loop.

FinOps: Was kosten Ihre Token wirklich?

Die zweite Dimension, die in frühen Enterprise-KI-Deployments regelmäßig fehlt, ist Kostentransparenz. Token-Kosten sind variabel, schnell akkumulierend und oft unsichtbar – bis die Rechnung kommt.

LiteLLM als API-Gateway ist hier die kritische Komponente. Es aggregiert alle Anfragen, vergibt virtuelle Schlüssel pro Team mit eigenem Budget, und protokolliert Token-Verbrauch pro Anfrage, Nutzer und Abteilung. Damit werden Kosten endlich steuerbar: Welches Team verbraucht 60 % des Budgets? Welche Anwendung sendet ineffizient lange System-Prompts?

Der ROI-Aspekt ist konkret: Wer erkennt, dass ein systemseitiger Prompt 2.000 Token pro Anfrage belegt, und ihn auf 400 Token kürzt, senkt die laufenden Tokenkosten auf diesem Kanal sofort um 70 % – oft ohne jede Qualitätseinbuße. Bei 400 aktiven Nutzern und moderater Nutzung entspricht jede eingesparte 1.000 Token pro Anfrage mehreren Tausend Euro pro Jahr.

Das gilt auch für die Modellwahl. Viele Anfragen in einem internen Assistenten brauchen kein Frontier-Modell. Klassifizierung, Zusammenfassung, einfache Recherche – das erledigt ein 32B-Modell lokal genauso gut, zu einem Bruchteil der Kosten. LiteLLM kann das Routing nach Aufgabentyp oder Nutzergruppe automatisch steuern. Wer das nicht abbildet, zahlt Frontier-Preise für Batch-Arbeit.

Langfuse: Der Backbone der Feedback-Loop

Einmalige Evals sind nützlich. Kontinuierliche Evals sind der Moat.

Langfuse (MIT-lizenziert, selbst hostbar, Berliner Unternehmen) ist die Observability-Schicht, die beides verbindet: Alle LLM-Traces landen in Langfuse, RAGAS-Scores werden als Langfuse-Scores zurückgeschrieben, und das Team sieht in einem Dashboard, wie sich die Qualität über Releases, Prompt-Versionen und Datenaktualisierungen entwickelt.

Das ist kein Monitoring im klassischen Sinne – es ist eine Qualitätsdatenbank. Fiel die Faithfulness nach dem letzten Dokument-Update? Gab es einen Qualitätseinbruch nach einem Prompt-Refactoring? Welche Nutzergruppe bekommt die schlechtesten Antworten? Antworten, die vorher rein anekdotisch waren, werden messbar und reproduzierbar.

Die Integration in LiteLLM ist ein Einzeiler in der Gateway-Konfiguration:

litellm_settings:
  success_callback: ["langfuse"]

Damit fließen alle Anfragen automatisch als Traces in Langfuse – mit Modell, Kosten, Latenz und Token-Daten. RAGAS-Scores, die über einen Batch-Job berechnet werden, lassen sich als Scores auf dieselben Traces schreiben. Das Ergebnis ist eine vollständige Qualitäts- und Kostenhistorie über alle Modellversionen hinweg.

Confidence messen: Der nächste Schritt

Evals messen Qualität ex-post – nach der Antwort. Der nächste Schritt ist, Confidence ex-ante einzuschätzen: Das Modell weiß bei manchen Fragen schlicht nicht, was es nicht weiß, und das sollte sichtbar sein.

Praktische Ansätze für den Unternehmenseinsatz: Log-Prob-basierte Konfidenz (wo vom Modell unterstützt), Ensemble-Ansätze (dieselbe Frage mehrfach mit Variation stellen und Konsistenz messen) und Retrieval-Score als Proxy (ein niedriger Similarity-Score beim Retrieval ist oft ein verlässlicher Indikator für eine wahrscheinlich schlechte Antwort).

Kein Ansatz ist perfekt. Aber ein Flagging-System, das niedrig-konfidente Antworten mit einem Human-in-the-Loop-Hinweis versieht, reduziert den Schaden durch Halluzinationen in regulierten oder sicherheitskritischen Anwendungsfällen erheblich. Und es signalisiert den Nutzern: Dieses System kennt seine Grenzen.

Der strategische Blickwinkel

Warum sind Evals der Moat? Weil Modelle kopierbar sind. Wenn GPT-5 heute ein Alleinstellungsmerkmal schafft, ist Qwen4 in sechs Monaten auf demselben Niveau. Was sich nicht kopieren lässt, ist das akkumulierte Wissen darüber, wie ein System in der eigenen Organisation versagt – welche Fragen es nicht beantworten kann, welche Dokumente zu Konfusion führen, welche Nutzergruppen andere Anforderungen haben.

Dieses Wissen ist in den Eval-Daten. Es entsteht nur durch kontinuierliche Messung. Unternehmen, die heute anfangen, diesen Datensatz aufzubauen, sind in zwei Jahren in einer Position, in der kein Modell-Upgrade einen Newcomer einholen kann.

Fazit: Messen ist keine Kür

Unternehmen, die KI ohne strukturierte Evaluation einführen, riskieren etwas Gefährlicheres als schlechte Antworten: Sie riskieren Vertrauensverlust, der schwer reparierbar ist. Ein Mitarbeiter, der zweimal eine falsche KI-Antwort nicht erkannt hat, traut dem System danach nicht mehr.

Der Weg aus diesem Dilemma ist nicht ein besseres Modell. Es ist ein besseres Messsystem.

RAGAS + LiteLLM + Langfuse ist kein exotischer Stack. Es ist eine pragmatische Kombination, die in Verbindung mit dem richtigen On-Prem-Setup an einem Nachmittag steht – und den Unterschied macht zwischen einem Pilot, der stirbt, und einer KI-Infrastruktur, der das Unternehmen vertraut.

Martin Stagl ist Systems Engineer und Data Scientist in Wien. Er schreibt auf stagl.systems über Enterprise-KI-Infrastruktur, DSGVO-konforme Systeme und datengetriebene Architekturentscheidungen im DACH-Raum.