Evaluation

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Dieser Post ist optional und vertieft die Evaluation-Methodik aus Post 5. Du kannst direkt zu Post 6 (vLLM Deployment) springen, wenn du mit deinem Training zufrieden bist. TL;DR – Für eilige Leser Das Problem: Training Loss = 0.35 sieht gut aus. Validation Loss = 0.35 zeigt kein Overfitting. Aber sind die generierten Antworten tatsächlich gut? Metrics alleine sagen wenig über Output Quality. ...

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub In Post 7.1 haben wir Dataset-Generierung auf 15 Minuten beschleunigt - ein 9× Speedup der iterative Entwicklung praktikabel macht. Statt 138 Minuten pro Run können wir jetzt 4 Experimente pro Stunde durchführen. Das ermöglicht systematisches Testing verschiedener Models, Prompts und Parameter. Jetzt nutzen wir diese schnelle Iteration: Kann ein besseres Model die Quality von Mistral-7B (77% in Post 7) in Richtung gpt-4o-mini (93%) steigern? Bei 15 Minuten pro Run können wir 3-4 Models in unter einer Stunde testen - was früher einen ganzen Arbeitstag gekostet hätte. ...

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub Hinweis: Detaillierte Definitionen zu technischen Begriffen findest du im Glossar. TL;DR – Für eilige Leser Setup: Llama-3.1-8B (self-hosted) vs. Claude Sonnet 4.5 (commercial), 171 identische Samples, gleicher Judge-Prompt Ergebnisse: Judge A-Ratings B-Ratings C-Ratings Agreement Kappa Claude Sonnet 4.5 111 (64.9%) 50 (29.2%) 10 (5.8%) - - Llama-3.1-8B 167 (97.7%) 3 (1.8%) 1 (0.6%) 65% 0.30 Kernerkenntnisse: Data Sovereignty machbar: Komplette Pipeline self-hosted 8B Models zu optimistisch: Übersehen 90% der B-Ratings, 90% der C-Ratings Use-Case abhängig: Pre-Filtering OK, Final Quality Control nicht Empirisch validiert: 171 Samples zeigen wahre Performance (für unseren Use Case) Framework ready: Llama-70B Test in Post 8.1 möglich Kein Drop-in Replacement für Claude – aber wir wissen jetzt, wo die Grenzen liegen und für welche Use Cases ein 8B Judge trotzdem nützlich ist. ...

Ein RAG-System nach Benchmark-Listen zu bauen, bedeutet für die Daten von jemand anderem zu optimieren. Vor einiger Zeit sprach ich mit einem potenziellen Kunden. Ihm war ein multimodales RAG-System hingestellt worden — mit aktuellen Technologien, sauber aufgesetzt, alles state of the art. Das Problem: Es hat ihm einfach nicht die Informationen gegeben, die er brauchte. Im Gespräch wurde klarer, was er eigentlich wollte: Fragen wie “Welche Analysen haben wir zu Thema X in Verbindung mit Thema Y gemacht?” — über Hunderte von PowerPoint-Dateien hinweg. Für solche Anfragen braucht man entweder eine relationale Datenbank, Graph-RAG oder Agentic RAG. Klassisches RAG ist die falsche Architektur. ...

Im letzten Post haben wir Agenten auf mehrere Schultern verteilt — Handoff, Supervisor, Swarm. Aber egal ob ein Agent oder zehn: Woher weiß man, ob sie gut arbeiten? Bei einem klassischen ML-Modell gibt es klare Metriken: Accuracy, F1-Score, AUC. Man hat ein Testset, lässt das Modell laufen und bekommt eine Zahl. Besser oder schlechter — eindeutig. Bei Agenten ist das anders. Das LLM als zentrale Komponente ist nicht-deterministisch — derselbe Input kann zu unterschiedlichen Pfaden führen. Die Anzahl der Schritte variiert. Und “richtig” ist oft eine Einschätzung, keine Ja/Nein-Entscheidung. War die Diagnose vollständig? Waren die Maßnahmen umsetzbar? Hat der Agent halluziniert? ...