Wie LLM-gestützte Systeme lernen – und warum Benutzung alleine nichts verbessern

Viele Menschen gehen davon aus, dass ein KI-System mit jeder Nutzung automatisch schlauer wird. „Je öfter wir es verwenden, desto besser wird es schon“, heißt es dann. Das klingt verlockend, ist aber falsch. Ein Large Language Model (LLM) verbessert seine Antworten nicht automatisch, nur weil es oft gefragt oder in einer Konversation korrigiert wird. Ohne die richtigen Datenflüsse, Feedback-Schleifen und Verbesserungsmechanismen bleibt die Qualität stehen, oder wird sogar schlechter.

In diesem Beitrag zeige ich praxisnah, was ein LLM-gestütztes System braucht, um durch reale Nutzung besser zu werden, welche Rolle Nutzer-Feedback spielt und wie sich die drei zentralen Stellschrauben – Context-Engineering (Prompting & Orchestrierung), RAG (Retrieval-Augmented Generation) und Fine-Tuning – unterscheiden. Außerdem beschreibe ich, wie man das Ganze in der Praxis mit einer KI-Middleware wie ONE datenschutzkonform und herstellerunabhängig aufsetzt: von der Feedback-Erfassung über Evaluation bis zur kontinuierlichen Verbesserung.

Vorneweg: Was bedeutet „Lernen“ bei LLM-Systemen?

Wenn wir sagen, ein LLM „lernt“, müssen wir unterscheiden zwischen drei Ebenen:

1. Gewichtslernen (Model Weights): Das eigentliche Trainieren oder Fine-Tuning des Modells verändert die Modellgewichte. Das ist der einzige Mechanismus, durch den das Modell selbst neues Wissen oder neue Verhaltensmuster in seine Parameter schreibt.
2. Wissenszufuhr zur Laufzeit (Context): Durch Context-Engineering (also gute Prompts, Tools, Struktur) und RAG (Retrieval aus eigenen Datenquellen) ändert sich nicht das Modell, aber die Information, auf deren Basis es antwortet. Das fühlt sich wie „Lernen“ an, ist aber technisch kein Lernen, sondern bessere Informationsversorgung in der Anfrage.
3. Systemlernen (Pipelines & Policies): Alles rund um Feedback-Schleifen, Bewertung, Regeln, Tool-Aufrufe, Caching, Guardrails, Tests – also die Architektur um das Modell – kann iterativ verbessert werden. Auch das ist kein Gewichtslernen, führt aber sehr real zu höherer Qualität über die Zeit.

Merke: Nur Fine-Tuning schreibt ins Modell. RAG und Context-Engineering schreiben in deine Systemlandschaft (Daten, Prompts, Policies). Für den Nutzer wirkt alles wie „die KI lernt“, aber unter der Haube sind es verschiedenartige Mechanismen – mit sehr unterschiedlichen Kosten, Risiken und Wartungsaufwänden.

Ohne gutes Feedback kein Fortschritt: „Shit in, shit out“

Wenn du weisst, dass dein System besser werden soll, brauchst du Feedback, das

• erfassbar (UI/UX-seitig leicht verfügbar),
• auswertbar (strukturiert, mit Metadaten) und
• nutzbar (an konkrete Verbesserungsmechanismen angebunden)

ist. Sonst bleibt es bei einem Bauchgefühl.

Welche Feedback-Signale zählen?

Explizit:

• Bewertung (Daumen hoch/runter, 1–5 Sterne)
• Korrektur-Vorschlag (Was wäre richtig?)
• Labeling (z. B. „faktisch falsch“, „veraltet“, „unvollständig“, „zu lang“, „zu vertraulich“)
• Task-Outcome (z. B. „Ticket konnte gelöst werden: ja/nein“)

Implizit (verhaltensbasiert):

• Abbruchrate (User bricht Konversation ab → Antwort unbrauchbar?)
• Reformulierung (User fragt dasselbe anders → Antwort traf nicht)
• Zeit bis zum Ziel (lange Bearbeitungszeit → unklarer Output)
• Weiterklicken/Copy-Paste (wurde die Antwort weiterverwendet?)

Kontext-Metadaten:

• Nutzungsfall (Use Case, Persona, Abteilung)
• Datenbasis (welche Quelle, Dokument-Version)
• Modell & Prompt-Version (A/B-Test, Temperaturoptionen)
• Sicherheitskontext (Mandant, Berechtigungen)

Praxisregel: Feedback muss strukturiert sein. Ein Freitext „War nicht gut“ hilft kaum. Eine markierte Passage + Label „falsch, Quelle X, Stand Y“ ist Gold wert.

Datenqualität entscheidet

Die härteste Wahrheit im KI-Betrieb: Schlechte Feedback-Daten verschlechtern das System.

Wenn du unklare oder widersprüchliche Labels sammelst, trainierst oder konfigurierst du pures Chaos. Qualitätsmaßnahmen sind deshalb Pflicht:

• Anleitungsqualität für Annotatoren (wer labelt, nach welcher Definition?)
• Doppelte Annotation bei Unklarheiten (Inter-Annotator-Agreement)
• Gold-Standards (kuratierte Referenzfälle)
• Bias-Checks (vermeidet dein Feedback systematisch falsche Präferenzen?)
• Privacy by Design (PII-Erkennung, Maskierung, Zweckbindung, Löschkonzepte)

Drei Wege zur Verbesserung: Context-Engineering, RAG und Fine-Tuning

Diese drei Hebel haben unterschiedliche Eigenschaften. Hier ist der Überblick – danach gehen wir tiefer rein.

1) Context-Engineering: Oft der schnellste Hebel

Ziel: Das Modell präziser steuern, ohne Trainingsaufwand.

Mittel: System-Prompts, Rollen, Output-Schemas (z. B. JSON), Tool-Aufrufe (z. B. Rechnen, Suche, ERP-API), Guardrails, Agent-Orchestrierung (z. B. Plan-Schritte).

Beispiele:

• Ein Incident-Responder-Assistent gibt Antworten immer im Ticket-Template aus, mit Feldern für Impact/Root-Cause/Next Steps.
• Ein Vertriebsassistent nutzt ein Kalkulations-Tool, statt die Marge „zu raten“.
• Ein HR-Bot ruft eine Policy-Datenbank via Tool auf, statt aus dem Gedächtnis zu fabulieren.

Grenzen:

• Kein neues Wissen: Die Antwortqualität hängt stark vom mitgegebenen Kontext und den Tools ab.
• Ohne Tests driften Prompts still und leise.
• Teams verlieren schnell den Überblick über Versionen.

Best Practices:

• Versioniere Prompts.
• Erzwinge strukturierte Ausgaben (Schemata).
• Baue automatisierte Evals (z. B. Regelsuiten: „Antwort muss Quelle nennen“).
• Nutze Agent-Builder, um Tool-Ketten visuell zu testen und zu dokumentieren.

Mit ONE: Der grafische Agent Builder hilft, Prompt-Schritte und Tool-Aufrufe sauber zu orchestrieren. Durch die Middleware bleibst du modellagnostisch – du kannst also verschiedene LLMs testen, ohne ihre Logik neu zu bauen.

2) RAG: Wissen aus deinen Daten – aktuell und belegbar

Ziel: Das LLM soll faktenbasiert aus deinen Quellen antworten – mit Zitaten und aktuellen Inhalten.

Kernbausteine:

• Konnektoren zu Dateispeichern (Share, NAS, S3/Blob), Wissensdatenbanken, Ticketsystemen, Datenbanken
• Indexierung & Chunking (Text in sinnvolle Abschnitte schneiden)
• Vektorisierung (Embeddings), plus Metadaten (Autor, Datum, Mandant, Berechtigung)
• Retrieval-Strategie (Hybrid-Suche, Re-Ranking, Query-Rewriting)
• Antwort-Synthese mit Quellenzitaten

Vorteile:

• Aktualität (keine Modell-Retrainings nötig)
• Transparenz (Quellenangaben)
• Compliance (Zugriffskontrolle pro Nutzer/Mandant)

Grenzen:

• Falsches Chunking oder schlechte Embeddings → irrelevante Treffer
• Berechtigungen sind kritisch: Ein globaler Index ohne ACLs ist ein Compliance-Risiko
• Nicht jedes Problem ist ein Retrieval-Problem (z. B. Stil, Format, Tool-Logik)

Best Practices:

• Hybrid Retrieval (dichte + lexikalische Suche)
• Freshness-Signale (jüngere Dokumente bevorzugen)
• Query-Expansion (Synonyme, Abkürzungen)
• Eval-Suiten (IR-Metriken wie Recall@k, nDCG; Antwort-Metriken wie Faithfulness)
• Data Ops: Dokument-Lebenszyklus, Versionierung, Löschfristen

Mit ONE: Als datenschutzkonforme KI-Middleware verbindet ONE jede Datenquelle herstellerunabhängig mit dem LLM deiner Wahl. Du kannst mehrere Vektorindizes pro Mandant führen, ACLs erzwingen, und dank MCP-Server Tools (z. B. Such-, Re-Ranking- oder hauseigene APIs) standardisiert einbinden.

3) Fine-Tuning: Wenn das Modell wirklich „lernen“ soll

Ziel: Das LLM erlernt dauerhafte Fähigkeiten oder Stile, z. B.

• Deine Domänensprache (Fachjargon, Tonalität)
• Spezifische Workflows (z. B. Klassifikationslabel, Extraktionsschemata)
• Policy-Konformität (z. B. immer zuerst X prüfen, dann Y)

Voraussetzungen:

• Qualitativ hochwertige, repräsentative Beispiele in ausreichender Menge
• Klare Zieldefinition (Was soll besser werden? Wie messen wir das?)
• Sauberes Splitten (Train/Val/Test, keine Datenleckage)
• Evaluations-Pipeline (vorher/nachher; A/B vs. Baseline)

Grenzen:

• Kosten und Zeit (Datenaufbereitung ist die Hauptarbeit)
• Drift-Risiken (neue Daten machen altes Fine-Tuning obsolet)
• Generalität (zu enge Trainingsdaten → schlechtere Answers außerhalb des Zielraums)

Best Practices:

• Starte klein: Instruction-Tuning mit kuratierten 200–2.000 Beispielen kann reichen.
• RLHF/RLAIF (Präferenzlernen) gezielt einsetzen, wenn du konsistente Stilpräferenzen brauchst.
• Regularisierung (z. B. Mix aus allgemeinen und spezifischen Daten), um Überanpassung zu vermeiden.
• Kontinuierliche Evals – und Rollback-Strategie.

Mit ONE: Du kannst Fine-Tuning-Pipelines herstellerunabhängig anstoßen, Feedback-Daten kuratieren, Datenschutzregeln durchsetzen und die neuen Modell-Versionen kontrolliert ausrollen. Über den Agent Builder definierst du, wann welches Fine-tuned-Modell für welchen Use Case genutzt wird.

Wie aus täglicher Nutzung echte Verbesserung wird: Der Lern-Kreislauf

Ein belastbarer Kreislauf sieht so aus:

1. Instrumentieren & Loggen
2. • Prompt, Kontext, genutzte Tools, Queried Docs, Antwort, Zitate
   • Nutzer, Mandant, Rollen (für Berechtigungen)
   • LLM-Version, Prompt-Version, RAG-Index-Version
2. Feedback einsammeln
3. • Explizit (Daumen, Labels, Korrekturen) in der UI
   • Implizit (Abbrüche, Zeit, Reformulierungen) per Telemetrie
3. Kurieren & Anreichern
4. • Deduplizieren, PII-Maskierung, Korrektheits-Tags
   • Zuordnung zu Use Cases (z. B. „Einkauf“, „IT-Support“, „HR-Policy“)
4. Evaluieren
5. • Offline-Evals: Testsets (Gold-Fragen) regelmäßig gegen neue Prompt/RAG/Fine-Tuning-Kandidaten laufen lassen
   • Metriken: Genauigkeit, Faithfulness, Quellenabdeckung, Zeit-zur-Lösung, Akzeptanzrate, Policy-Verstöße
5. Verbesserungen ableiten
6. • Context-Engineering: Prompt-Regeln, Output-Schemas, Tool-Sequenzen anpassen
   • RAG-Tuning: Chunking, Re-Ranking, Filter, Freshness, ACL-Fixes
   • Fine-Tuning: Neue, saubere Trainingsbeispiele generieren
6. Sicher ausrollen
7. • A/B-Tests mit Shadow-Traffic
   • Feature-Flags, Rollback-Plan, Change-Log
7. Governance
8. • Datenschutz (Rechtsgrundlage, Zweckbindung, DSFA, Löschkonzepte)
   • Audit-Trails (wer hat wann was geändert)
   • Modell-Katalog (Versionen, Evaluationsberichte)

Mit ONE: Dieser Kreislauf lässt sich End-to-End aufsetzen: Feedback-Capture in Custom GPTs/Assistenten, Logging über die Middleware, Eval-Jobs, RAG-Index-Updates und – wo nötig – Fine-Tuning-Runs. Der MCP-Server standardisiert Tool-Anbindungen (Suche, Re-Ranking, interne Systeme), der Agent Builder verknüpft alles visuell.

Praxisbeispiel: Vom „Chatbot“ zum produktiven Assistenten

Ausgangslage:

Ein Unternehmen führt einen IT-Support-Assistenten ein. Erste Version: ein generisches LLM mit einem groben System-Prompt. Ergebnis: wechselhafte Antworten, veraltete Informationen, keine Quellen.

Ziel:

Hohe Erstlösungsquote (>70 %), Antworten mit Quellen, DSGVO-konform, Zugriff nur auf freigegebene Dokumente.

Schritt 1 – Context-Engineering (2 Wochen):

• Klare System-Instruktion: Tonfall, Verbote (keine Vermutungen), Zitationspflicht.
• Output-Schema: „Diagnose | Schritte | Quellen“.
• Tool: Ticket-System-API für Ticketnummern, Rechengrundlagen (z. B. Kosten), Status-Nachschlagen.
• Guardrails: Wenn Quelle fehlt → Nachfragen/Abbruch.

Schritt 2 – RAG (4 Wochen):

• Anbindung von Wissensartikeln, Change-Logs, Runbooks; Chunking nach Überschriften.
• Hybrid-Retrieval, Freshness-Boost für die letzten 90 Tage.
• Zugriff mandanten- und rollenbasiert; sensible Doks nur für 2nd-Level-Support.
• Eval-Set aus 200 echten Tickets (anonymisiert). Metriken: Recall@5, Faithfulness, Zeit-zur-Lösung.

Schritt 3 – Feedback & Evals (laufend):

• UI mit Daumen + Labels („falsch“, „veraltet“, „unvollständig“).
• Implizites Feedback: Abbruchrate, Rückfragen-Zähler.
• Wöchentliches Eval-Dashboard: Vergleich Prompt-Versionen, Retrieval-Parameter.

Schritt 4 – Fine-Tuning (optional, 6–8 Wochen):

• 1.000 kuratierte Q/A-Paare aus echten Tickets (mit korrekten Runbooks).
• Ziel: besserer Tonfall, Schritt-für-Schritt-Erklärungen, Fehlerdiagnose.
• A/B-Rollout; Rückfall auf Base-Modell möglich.

Ergebnis nach 3 Monaten:

• Erstlösungsquote 74 % → 82 %
• Anteil Antworten mit Quelle: 96 %
• Durchschnittliche Bearbeitungszeit −28 %
• Weniger Eskalationen wegen Berechtigungsleaks (dank ACLs)

Lehre: Nicht „mehr Benutzung“, sondern strukturierte Feedback-Schleifen + gezielte Hebel treiben Qualität.

Häufige Irrtümer und Anti-Patterns

1. „Wir sammeln erstmal alles an Feedback.“
2. Ohne Label-Definitionen wird das unbrauchbar. Lieber kleiner, klarer Katalog (z. B. „falsch/fair/korrekt“, „Quelle fehlt“, „policy-kritisch“).
3. „Fehler? Dann direkt Fine-Tuning!“
4. Oft reicht RAG-Fix (Dokument aktualisieren, Chunking ändern) oder Prompt-Regel. Fine-Tuning ist der spätere Hebel.
5. „Ein globaler Vektorindex für alle“
6. Klingt effizient, bricht aber Berechtigungen und Mandantentrennung. Baue logische Indizes pro Bereich/Mandant.
7. „Halluzinationen? Das Modell ist schlecht.“
8. Häufig fehlen Quellen oder Tools. Erst RAG und Guardrails härten, dann über Modellwechsel nachdenken.
9. „Wir messen später.“
10. Ohne Baseline weisst du nie, ob es besser wurde. Lege vor dem ersten Livegang ein Eval-Set an.

Entscheidungshilfe: Welcher Hebel wofür?

• Du brauchst Aktualität, Zitate, Compliance? → RAG zuerst.
• Du brauchst stringente Formate/Workflows/Tools? → Context-Engineering.
• Du brauchst konsistenten Stil, Domain-Sprache oder spezielle Aufgabenfähigkeiten? → Fine-Tuning – aber erst, wenn RAG & Prompts sitzen.

Kombination ist normal:

Ein guter Produktionsassistent nutzt Context-Engineering für Struktur, RAG für Fakten und ggf. leichtes Fine-Tuning für Stil/Task-Spezifika.

Metriken, die wirklich helfen

• Task-Erfolg: Wurde das Ziel erreicht? (z. B. Ticket gelöst, richtige Policy gefunden)
• Faithfulness: Deckt die Antwort belegte Aussagen aus Quellen?
• Quellenabdeckung: Prozent Antworten mit Zitaten und akzeptierter Quelle
• IR-Metriken (bei RAG): Recall@k, nDCG, MRR
• Zeit-zur-Lösung: End-to-End
• Akzeptanzrate: Daumen hoch/Run-Rate
• Policy-Verstöße: Blockiert/erkannt durch Guardrails
• Kosten pro Vorgang: Tokens, Tool-Calls, Indexpflege

Tipp: Automatisiere Evals (z. B. nächtlich). Nur was regelmäßig gemessen wird, verbessert sich planbar.

Datenschutz & Compliance von Anfang an

Ein LLM-System lernt nur nachhaltig, wenn es vertrauenswürdig ist.

• Datenminimierung: Nur notwendige Logs/Feedback speichern; PII maskieren.
• Rechtsgrundlagen & Transparenz: Zweckbindung, interne Policy, Schulungen.
• Berechtigungen: Durchgängig – vom Dokumentzugriff bis zum Retrieval.
• Löschkonzepte: Feedback und Logs mit Fristen.
• Auditierbarkeit: Wer hat was trainiert/gerollt? Versionen & Reports.

Mit ONE: Mandantentrennung, ACL-Durchsetzung, Protokollierung und konfigurierbare Speicherorte (eigener Blob/NAS/DB) sind Kernfunktionen – ideal für DSGVO-konformen Betrieb.

Konkreter Umsetzungsplan (90 Tage)

Woche 1–2: Grundlagen

• Use-Cases priorisieren, Erfolgskriterien definieren (OKRs, Metriken)
• Eval-Set anlegen (50–200 kuratierte Fälle)
• Logging-Schema & Datenschutzfreigaben klären

Woche 3–4: Context-Engineering

• System-Prompt, Guardrails, Output-Schemas
• Erste Tools anbinden (über MCP-Server standardisieren)
• Shadow-Traffic + A/B gegen Baseline testen

Woche 5–8: RAG

• Datenquellen anbinden, Chunking/Embeddings, ACLs
• Hybrid-Retrieval + Re-Ranking, Zitierlogik
• IR-Evals aufsetzen, wöchentliche Tuning-Zyklen

Woche 9–12: Feedback-Ops & optionales Fine-Tuning

• UI-Feedback (Daumen + Labels + Korrektur-Feld)
• Pipeline zur Kuration von Trainingsbeispielen aus realer Nutzung
• Falls sinnvoll: leichtes Fine-Tuning für Stil/Extraktion
• Kontrollierter Rollout mit Feature-Flags, Rollback-Plan

Ab Woche 13: Kontinuierliche Verbesserung

• Wöchentliche Evals, monatlicher Datenpflege-Sprint
• Neue Quellen/Tools integrieren, Prompt-Drift verhindern
• Governance-Reviews, Audit-Reports

Checkliste: Lernen aus Nutzung – hast du alles?

• Feedback in der UI (explizit + strukturiert)
• Telemetry für implizite Signale
• Eval-Set + automatisierte Evals
• Prompts versioniert, Guardrails aktiv
• RAG mit ACLs, Hybrid-Retrieval, Freshness
• Quellenpflicht in Antworten
• Kuratierte Trainingsdaten (optional Fine-Tuning)
• A/B-Rollout + Rollback
• Datenschutz: PII-Maskierung, Löschfristen, Audit-Trail
• Kosten-Monitoring (Tokens, Indexpflege, Tool-Calls)

TL;DR

• Benutzung allein macht ein LLM-System nicht besser.
• Echtes „Lernen“ entsteht durch gezielte Feedback-Schleifen, Evaluations-Pipelines und die kluge Kombination der drei Hebel:
• • Context-Engineering für Struktur, Tools und Format (schnell, günstig).
  • RAG für aktuelle, belegte Antworten aus deinen Daten (mittel, sehr wirksam).
  • Fine-Tuning für dauerhafte Fähigkeiten/Stile (aufwendiger, gezielt einsetzen).
• Datenqualität ist der Dreh- und Angelpunkt: Shit in, shit out.
• Mit einer Middleware wie ONE setzt du das Ende-zu-Ende datenschutzkonform und herstellerunabhängig um: Konnektoren, MCP-Tools, grafischer Agent Builder, Feedback-Ops, Evals, RAG-Tuning und optionales Fine-Tuning – alles in einem kontrollierten Kreislauf.