// Fallstudie
Automatische Aufsatzbewertung via LLM-Ensemble
1'750 Texte, strikter Datenschutz und Custom-Statistiken.
"Es ist mit dem aktuellen Stand der Technik nicht möglich." Das war das Fazit einer initialen Machbarkeitsstudie, nachdem Fachexperten diverse Tests mit SOTA-Sprachmodellen durchgeführt hatten. Zudem verschärfte sich das Problem durch strenge Datenschutzvorgaben: Da die Aufsätze hochsensible persönliche Daten enthielten, war die Nutzung von APIs wie OpenAI oder Anthropic rechtlich ausgeschlossen.
Als der Leiter des Gesamtprojekts mich nach meiner Einschätzung fragte, baute ich an einem Sonntagmorgen einen Proof of Concept. Mein Ansatz: Die Evaluation musste auf kleine, datenschutzkonforme lokale Modelle heruntergebrochen und über eine strikte Pipeline orchestriert werden. Dieser PoC bewies, dass das Projekt realisierbar war. Das Commitment ging so weit, dass meine Frau und ich eigens für die offizielle Umsetzung dieses Projekts eine Firma gründeten.
Die Umsetzung: Voller Stack von Grund auf
Aufgrund administrativer Hürden blieben letztlich nur knapp drei Monate reine Entwicklungszeit für die initiale Systementwicklung. In dieser stark komprimierten Phase orchestrierte ich die asynchrone AI-Pipeline in Go zur Bewertung von ca. 1'750 Kurztexten und baute das Frontend inklusive Human-in-the-Loop GUI und Custom-Statistik-Engine in SvelteKit. Das aufwendige Rater-Training und die Etablierung breit abgestützter Anker-Texte erfolgten danach in einer dedizierten zweiten Projektphase.
Mein Verantwortungsbereich:
- AI Engineering & Orchestration (Go): Konzeption einer asynchronen Multi-Modell-Architektur (Gemma2, Phi-3, Llama via Ollama), die das fehlende Denkvermögen grosser Cloud-Modelle durch Ensembles ausglich.
- Custom Statistics Engine (TypeScript): Verzicht auf Python/Pandas zugunsten einer nativen Implementierung akademischer Metriken (Krippendorff's Alpha, Gwet's AC2, ICC) direkt in TypeScript für die Evaluierung von Rater-Bias.
- Full-Stack & UX: Bau des Human-in-the-Loop Interfaces (inklusive komplexer PDF-Reporting-Generierung mit
gopdf), welches in der anschliessenden Trainingsphase für Workshops zur Konsensfindung genutzt wurde.
Tech-Stack & Tools
- Modelle (Lokal via Ollama)
- Gemma2-9b-SimPO Phi-3-14B-Reasoning Llama 3
- LLM Orchestration
- Go (Backend) Prompt Chaining LLM-as-a-Judge
- Stats & Frontend
- TypeScript SvelteKit Custom IRR-Engine
- NLP Tools
- LanguageTool (Deterministische Grammatik)
- PDF Generation
- signintech/gopdf
Architecture Records / Decisions
Datenschutz & Deployment
// adr
Lokale Modelle vs. SOTA-APIs (OpenAI/Anthropic)
finalcontext
Da die Aufsätze besonders schützenswerte Daten (persönliche Erlebnisse, PII) von Lernenden enthielten, war ein Versand an externe Cloud-Anbieter in den USA rechtlich und ethisch ausgeschlossen.
decision
Lokales Deployment via Ollama
gains
- 100% Data Privacy und rechtliche Compliance.
- Keine variablen Token-Kosten bei der Evaluierung von 1'750 Texten mit Multi-Modell-Ansatz.
costs
- Hardware-Limitierungen erforderten den Einsatz kleinerer Modelle (< 15B Parameter) anstelle massiver State-of-the-Art Modelle.
consequences
- Die mangelnde Kapazität einzelner lokaler Modelle zwang zur architektonischen Innovation (Ensemble-Methode).
alternatives
- Cloud SOTA-APIs (GPT-4 / Claude) — Trotz initialer Tests ausgeschlossen aufgrund von strikten Datenschutzvorgaben bei Bildungsdaten.
Modell-Architektur
// adr
Single-Model vs. Multi-Model Ensemble
finalcontext
Vorprojekt-Tests durch Fachexperten mit einzelnen Modellen ergaben, dass die automatische Bewertung von Aufsätzen zu inkonsistent und fehleranfällig sei. LLMs tendierten dazu, Kriterien zu vermischen und wiesen eine hohe Varianz auf.
decision
Multi-Model Ensemble mit Synthese-Schritt
gains
- Drastische Reduktion von Modell-Bias und Einzel-Halluzinationen.
- Spezialisierung: Kleinere, lokale Modelle (z.B. Phi-3, Gemma2) reichten im Verbund für die Einzelkriterien völlig aus.
costs
- Höherer Rechenaufwand (3x Evaluierung + 1x Synthese pro Text).
consequences
- Die Architektur erforderte eine Orchestrierung in Go, da die Evaluierung eines Textes nun ein komplexer asynchroner Flow war.
alternatives
- Ein grosser Call an ein lokales 70B Modell — Zu langsam für den Durchsatz und ein einzelnes Modell liefert keine inhärente Konfidenzmetrik.
Pragmatismus vs. AI-Hype
// adr
LLM vs. Regelbasierte Systeme für Orthografie
acceptedcontext
Bei den Dimensionen "Rechtschreibung und Grammatik" halluzinierten die damaligen Modelle häufig Fehler oder übersahen offensichtliche Mängel, da LLMs auf semantischer und nicht auf syntaktischer Zeichenebene operieren.
decision
LanguageTool (Regelbasiert)
gains
- 100% deterministische, korrekte Grammatik- und Rechtschreibprüfung.
- Massive Entlastung der LLM-Pipeline für diese spezifische Metrik.
alternatives
- Starkes Prompt-Engineering für Orthografie — Führte zu Dead-Ends. Die Erkenntnis: Ein guter AI-Engineer weiss, wann man besser keine KI einsetzt.
Deep Dives
// LLMOps & Orchestrierung in Go
Das lokale LLM-Ensemble: Reduktion von Non-Determinismus
Wie inkonsistente LLM-Outputs durch ein asynchrones Multi-Modell-Setup (Gemma, Phi, Llama) mathematisch stabilisiert wurden.
Um in einem Educational-Kontext eine verlässliche Bewertung zu garantieren, darf man sich nicht auf die stochastische Tagesform eines einzelnen Modells verlassen. Da aus Datenschutzgründen nur lokale Modelle in Frage kamen, entwickelte ich in Go eine komplexe Orchestrierungs-Pipeline, welche die lokalen Ollama-Instanzen parallel ansprach.
Der Synthese-Workflow
Jedes Bewertungskriterium wurde strikt isoliert (Dynamic Prompt Chaining). Die drei Hauptmodelle beurteilten den Text völlig unabhängig voneinander.
Ein viertes LLM fungierte anschliessend als Judge/Synthesizer. Es analysierte die drei generierten Scores und Begründungen. Stimmten die Modelle überein, wurde ein hoher Certainty-Wert vergeben. Gab es Diskrepanzen, wurde der Text für den Human-in-the-Loop geflaggt.
// Data Science & TypeScript Engine
IRR-Statistik from Scratch (Kein Python, kein Pandas)
Implementierung akademischer Goldstandards zur Quantifizierung von Rater-Bias (Krippendorff, Gwet's AC2, ICC) rein in TypeScript.
Die beste KI-Bewertung ist wertlos, wenn sie nicht gegen verlässliche menschliche Baselines ("Ground Truth") gemessen werden kann. Statt auf bewährte Data-Science-Stacks wie Python oder SciPy zurückzugreifen, schrieb ich die komplette statistische Evaluierung nativ in TypeScript, um sie tief in die SvelteKit-Architektur zu integrieren.
1. Triangulation der Zuverlässigkeit (Das Kappa-Paradoxon)
Sich auf eine einzige IRR-Metrik zu verlassen, ist gefährlich. Die Engine berechnete in Echtzeit:
- Krippendorff's Alpha (Corrected): Nutzte Interval Weights, um grosse Diskrepanzen mathematisch härter abzustrafen.
- Gwet's AC2: Wurde bewusst implementiert, um das Kappa-Paradoxon zu lösen (bei welchem Metriken wie Cohen's Kappa trotz hoher Übereinstimmung eine tiefe Reliabilität anzeigen, wenn eine Bewertungskategorie dominiert).
- Intraclass Correlation Coefficient (ICC): Auf Basis eines ANOVA-Frameworks berechnet, um zu messen, wie viel Score-Varianz auf echte qualitative Unterschiede der Texte zurückzuführen ist und wie viel auf Messfehler.
2. Rater-Outlier Detection (Severity vs. Inconsistency)
Um zu erkennen, warum Rater (menschlich oder KI) vom Konsens abweichen, trennte das System die Fehler via Z-Scores in Severity (systematischer Bias) und Inconsistency (Rauschen). Ein Wert von flaggte Rater automatisch für gezielte Nachschulungen (Kalibrierung vs. Basis-Retraining).
3. Custom APD Consensus
Neben den abstrakten akademischen Werten berechnete die Engine die APD Consensus Metrik (Mean Pairwise Absolute Difference), normalisiert auf eine Skala von 0-1. Dies erlaubte es nicht-technischen Stakeholdern, die Qualität sofort zu erfassen ("Die Rater liegen durchschnittlich nur 5% der Skala auseinander").
// Frontend & UX (Phase 2)
Der Human-in-the-Loop Workflow (Konsensfindung)
Aufbau eines 4-stufigen, iterativen GUI-Workflows für 180 Anchor-Texte zur Etablierung einer stabilen menschlichen Ground Truth.
Nach der initialen Systementwicklung wurde das HitL-Interface in einer dedizierten Folgephase genutzt, um verlässliche Anker-Texte zu generieren und das Bewertungsteam zu trainieren.
Der Prozess für 180 Texte wurde in vier strikte Phasen unterteilt (Blind-Beurteilung, IRR-Auswertung, Workshop & Überarbeitung, Validierungs-Tranche). Dieses Tooling bildete das methodische Fundament, auf dem die LLM-Modelle final evaluiert werden konnten.
(Side-Note: Eine der hartnäckigsten Hürden im Frontend/Reporting war kurioserweise keine AI-Metrik, sondern der zwingende Wunsch der Projektleitung nach einem lupenreinen Blocksatz in der PDF-Ausgabe der Resultate, was mit signintech/gopdf schliesslich erfolgreich gelöst wurde).
Business Outcome & Erkenntnisse
Innerhalb von nur drei aktiven Entwicklungsmonaten wurde das Kernsystem für ein Vorhaben realisiert, das anfänglich als "technisch unmöglich" eingestuft worden war. 1'750 Aufsätze wurden unter strikten Datenschutzauflagen (lokale Inferenzen) asynchron und mit methodisch nachweisbarer Zuverlässigkeit ausgewertet.
Dieses Projekt zeigte eindrücklich, dass erfolgreiches AI Engineering selten bedeutet, einfach einen API-Key für das grösste Modell in den Code zu kleben. Es geht um Systemarchitektur, das Management von stochastischen Risiken (Ensembles) und das pragmatische Wissen, wann deterministische Tools (wie LanguageTool) der KI überlegen sind. Dafür eine eigene Firma zu gründen und die Architektur von Grund auf neu zu denken, war eine der prägendsten Erfahrungen meiner Laufbahn.