74 KiB
Sovereign RAG Tutor – Internes Konzeptdokument
Status: Entwurf v0.4 · Stand: Juli 2026 · Vertraulichkeit: intern Führendes Dokument – das Kundendokument wird als gefilterte Teilmenge hieraus abgeleitet.
1. Zweck und Verwendung des Dokuments
Dieses Dokument konsolidiert den Konzeptstand des Projekts "Sovereign RAG Tutor" für den Kunden mastersolution AG. Es richtet sich an das interne Projektteam sowie an alle, die auf dieser Basis später Teilsysteme spezifizieren und implementieren. Es ist ausdrücklich kein Kundendokument: Es enthält die vollständige, ungefilterte Bewertung des ursprünglichen Architekturentwurfs, verworfene Alternativen samt Begründung, ehrliche Aufwands- und Risikoeinschätzungen sowie Spezifikationshinweise, die für die Kundenkommunikation ungeeignet oder zu detailliert wären.
Für die Pflege gilt das Prinzip des führenden Dokuments: Konzeptänderungen werden zuerst hier nachgezogen und anschließend in das Kundendokument propagiert, nie umgekehrt. Die Gliederung beider Dokumente ist bewusst parallel angelegt (Problem → Ziel → Lösung → Roadmap); die Kapitel 2, 3, 5 und 7 bilden die inhaltliche Basis des Kundendokuments, die Kapitel 1, 4, 6, 8 und 9 bleiben primär intern. Jede Änderung an Konzeptentscheidungen ist im Entscheidungsregister (Kapitel 8) mit Datum und Begründung zu vermerken.
2. Ausgangslage und Problemstellung
2.1 Der Kunde: mastersolution AG
Die mastersolution AG (Hauptsitz Plauen, weitere Standorte in Chemnitz und Dresden, gegründet 1999) ist ein Technologieanbieter für Kommunikations- und Lernsoftware im deutschsprachigen Raum. Das Portfolio deckt die gesamte Wertschöpfungskette des digitalen Lernens ab: Lernmanagement (mastersolution ONE auf Moodle-Basis; didab mit dem Zusatzpaket unika), Klassenraum-Management (SUITE: plattformübergreifende didaktische Steuerung mit Echtzeit-Bildschirmeinsicht), IT-Asset-Management (REFLECT), Videoproduktion und immersive Medien (FOCUS, SHOW, VMS) sowie angewandte Forschung in Förderprojekten (SG4BB, MOONRISE, WIDI). Zielmärkte sind der öffentliche Bildungssektor und der Corporate Sector einschließlich Behörden; ein B2C-Geschäft existiert nicht.
Das strategisch wertvollste Asset des Unternehmens ist das Vertrauen seiner Kunden in absolute Datensouveränität: Hosting in zertifizierten deutschen Rechenzentren oder On-Premise, strikte DSGVO-Konformität, Betrieb lizenzunabhängig von Technologien aus den USA, China oder Russland, bis hin zur Bundeswehr-Zertifizierung. Genau dieses Versprechen gerät durch die aktuelle KI-Strategie unter Druck: Die beworbene Anbindung des "OpenAI Frameworks" für Content-Generierung steht in fundamentalem Widerspruch zur Souveränitätspositionierung, während Wettbewerber im Klassenraum-Management (classroom.cloud, Lightspeed, NetSupport) und im Moodle-Ökosystem (Course Creator AI, AI Essay Grader, sokratische Tutor-Plugins, natives AI-Subsystem ab Moodle 4.5) bereits tiefgreifende KI-Funktionen ausliefern. mastersolution steht damit vor der Aufgabe, KI-Funktionalität aufzubauen, ohne das Souveränitätsversprechen zu erodieren – andernfalls droht der Verlust der Differenzierung in beide Richtungen.
2.2 Projektentstehung und Anforderungsquellen
Der Projektanstoß entstand aus einem Erstkontakt der beiden Geschäftsführer. Die zwei ursprünglichen Anwendungsfälle – (1) intelligente, semantische Suche auf einer Lernplattform und (2) Analyse und Erkennung von Kompetenzen mit geführtem Lernprozess – wurden nicht von mastersolution explizit formuliert, sondern von unserer Geschäftsführung aus diesen ersten Gesprächen abgeleitet. Sie sind damit als Arbeitshypothese zu verstehen, nicht als beauftragte Anforderung.
Im ersten gemeinsamen Meeting mit dem Kunden wurden diese Hypothesen validiert und verdichtet. Ergebnisse dieses Termins sind das dokumentierte Brainstorming (Kernmerkmale eines persönlichen Lernassistenten: Nutzeridentifikation mit Lernstand, Nutzung der Kursmaterialien HTML/Quiz/Video, Backlinks und Feedforwards, generierte und gecoachte Lernpfade) sowie eine erste, ausdrücklich unvollständige Anforderungsliste: Nachvollziehbarkeit, Datensicherheit, Geschwindigkeit, Verkürzung digitaler Lernprozesse (insbesondere Onboarding), nutzerzentrierte Sicht mit rollenbasierten Berechtigungen, die zwingend gewahrt werden müssen, sowie die klare Präferenz für pragmatische Lösungen ohne unnötige Komplexität.
Parallel wurden zwei KI-gestützte Recherchen durchgeführt: ein Unternehmensprofil mit Wettbewerbsanalyse und fünf Produktvisionen sowie – aufbauend auf der dort priorisierten Vision 3 – ein konzeptioneller Architekturentwurf für den "Sovereign RAG Tutor" mit sechs Systemkomponenten. Dieser Entwurf ist der Gegenstand der kritischen Bewertung in Kapitel 4 und der Ausgangspunkt des überarbeiteten Lösungskonzepts in Kapitel 5.
2.3 Vorhandene Kompetenzbasis
Für Anwendungsfall 1 existiert im Team belastbare Vorerfahrung: Ein Proof of Concept für hybrides Retrieval (Embedding-Modelle für semantische Ähnlichkeit, kombiniert mit BM25) wurde in einem anderen Projekt bereits umgesetzt, ist jedoch nicht produktionsreif. Für Anwendungsfall 2 – insbesondere für generative Sprachmodelle, Wissensgraphen und Knowledge Tracing – besteht keine unmittelbare Projekterfahrung. Diese Asymmetrie ist eine zentrale Randbedingung des Lösungskonzepts: Die Roadmap muss auf der vorhandenen Kompetenz aufsetzen und die neuen Themenfelder in beherrschbaren Schritten erschließen.
2.4 Problemstellung in einem Satz
mastersolution benötigt einen Weg, KI-gestützte Wissensvermittlung in sein LMS-Ökosystem zu integrieren, der (a) das Souveränitätsversprechen vollständig erhält, (b) die Kundenanforderungen Nachvollziehbarkeit, Berechtigungstreue und Pragmatismus strukturell erfüllt und (c) von unserem Team mit der vorhandenen Kompetenzbasis in beherrschbaren Ausbaustufen realisierbar ist.
3. Zielbild und Abgrenzung
3.1 Zielbild
Im Endausbau ist der Sovereign RAG Tutor ein persönlicher, souveräner Lernassistent innerhalb der mastersolution-Produktwelt, der drei Leistungsversprechen einlöst:
Finden und Verstehen: Nutzer finden über eine hybride semantische Suche und einen Frage-Antwort-Assistenten präzise, belegte Antworten aus dem freigegebenen Materialbestand – mit Quellenangabe bis auf Dokumentabschnitt und Video-Timestamp, strikt gefiltert nach Rolle und Berechtigung.
Kompetenz statt Auswendiglernen: Ein redaktionell validierter Wissensgraph verbindet Kompetenzen, Materialien und Prüfungsfragen. Ein interpretierbares, regelbasiertes Tracking erkennt Wissenslücken und spricht nachvollziehbar begründete Empfehlungen aus (Backlinks auf Grundlagen, Feedforwards auf Anschlussmodule).
Begleitetes Lernen: In Kursen führt ein Coaching-Modus mit sokratischer Gesprächsführung durch den Lernprozess, generierte Prüfungsfragen entlang der Bloom-Stufen prüfen Verständnis statt Wiedererkennung, und automatisch erzeugte Lernpfade verkürzen Onboarding und Schulung messbar gegenüber einer erhobenen Baseline.
Das System wird als mandantenfähiges Produkt betrieben – als gehostete Instanz im deutschen Rechenzentrum oder als autarke On-Premise-Installation – mit identischer Codebasis und einem Evaluationsframework, das Qualität messbar macht und Modell-Updates absichert.
3.2 Nicht-Ziele und bewusste Abgrenzungen
Die folgenden Abgrenzungen sind teilweise regulatorische Zusagen und gehören in identischer Klarheit in das Kundendokument:
Das System betreibt keine Verhaltensüberwachung. In das Kompetenztracking fließen ausschließlich explizite Lernereignisse (Quizantworten, Modulabschlüsse) ein; Verhaltenstelemetrie wie Verweildauern, Navigationsmuster oder Tipprhythmen wird im Standard nicht erhoben.
Das System trifft keine automatisierten Entscheidungen mit erheblicher Wirkung über Personen. Es empfiehlt (Wiederholung, Lernpfad, Freischaltung), die verbindliche Konsequenz zieht ein Mensch oder sie ist rein unterstützend ausgestaltet. Automatisierung ist als bewusste Konfiguration des Endkunden möglich, nicht als Auslieferungszustand.
Die KI-Modelle werden nicht auf Mandantendaten trainiert oder feingetunt. Kundenspezifik entsteht ausschließlich über Index, Graph und Retrieval – über Daten, die beim Mandanten verbleiben.
Das System ist kein Prüfungs- oder Personalbeurteilungswerkzeug. Wirkungsmetriken werden aggregiert erhoben und dienen der Produktqualität, nicht der Leistungsbewertung Einzelner; Vorgesetzten-Sichten sind standardmäßig aggregiert.
Antworten entstehen ausschließlich aus dem freigegebenen Materialbestand (Grounded Generation). Das System mischt kein externes Weltwissen ein und antwortet mit einer expliziten Fehlanzeige, wenn das Material eine Frage nicht deckt.
3.3 Erfolgskriterien auf oberster Ebene
Der Projekterfolg bemisst sich an vier Kriterien: (1) Retrieval-Qualität und daraus resultierendes Nutzervertrauen, gemessen über Goldstandard-Metriken und Nutzungsverhalten; (2) belegte Verkürzung von Lernprozessen gegenüber der bei der Mandanten-Einführung erhobenen Baseline; (3) vollständige Souveränität und Rechtssicherheit, nachgewiesen über die mitgelieferten Compliance-Artefakte; (4) wirtschaftliche Betreibbarkeit als mandantenfähiges Produkt in beiden Betriebsmodellen. Die Operationalisierung erfolgt in Abschnitt 5.6.
4. Bewertung des ursprünglichen Architekturentwurfs
Der aus der zweiten KI-Recherche stammende Architekturentwurf ("Konzeptionelle Detaillierung der Produktvision: Sovereign RAG Tutor") wurde gegen die Kundenanforderungen, das Brainstorming, das Unternehmensprofil und die Kompetenzbasis des Teams geprüft. Dieses Kapitel dokumentiert die Bewertung in voller Schärfe; sie ist die Begründungsgrundlage für nahezu jede Abweichung des Lösungskonzepts (Kapitel 5) vom Recherche-Dokument.
4.1 Was am Entwurf trägt
Die Zerlegung in sechs Komponenten entlang der klassischen ITS-Architektur (Domain/Student/Tutoring/Interface-Modell) ist wissenschaftlich fundiert und schafft klare Verantwortlichkeiten; sie wird übernommen und erweitert. Der Context & Role Manager adressiert die Berechtigungsanforderung direkt und ist die am besten abgedeckte Kundenanforderung. Nachvollziehbarkeit ist konzeptionell verankert (Quellenangaben, Video-Timestamps, Backlinks). Die Souveränitätsargumentation passt exakt zum Geschäftsmodell des Kunden. Die Wettbewerbsanalyse ist brauchbar; die Positionierung – Synthese der Einzelfähigkeiten zu einem geschlossenen System statt Nachbau einzelner Features – ist ein plausibles Alleinstellungsmerkmal.
4.2 Kritikpunkte
K1 – Der Entwurf verletzt die wichtigste Kundenanforderung: Pragmatismus. Das Konzept stapelt nahezu jede fortgeschrittene Technik aufeinander: Multimodal RAG, GraphRAG, Bayesian und Deep Knowledge Tracing, MCP-Integration, sokratischer Orchestrator mit Reinforcement Learning, souveränes LLM. Jede dieser Komponenten ist für sich ein anspruchsvolles Projekt. Der Kunde hat explizit "keine unnötige Komplexität" gefordert; der Entwurf liest sich jedoch wie ein Forschungsprogramm, nicht wie ein Produkt. Es fehlt jede Priorisierung zwischen Kern und Ausbaustufe. Ein Konzept ohne gestufte Roadmap ist gegenüber diesem Kunden unglaubwürdig.
K2 – Der Entwurf ignoriert die vorhandene Kompetenzbasis. Anwendungsfall 1 (hybride Suche, vorhandener PoC) taucht im Konzept praktisch nicht auf – dabei ist genau diese Suche die Retrieval-Grundlage, auf der das gesamte "Sovereign Knowledge Vault" aufbaut, und der einzige Bereich mit Teamerfahrung. Strategisch richtig ist die Umkehrung: Die semantische Suche ist kein separater Anwendungsfall neben dem Tutor, sondern dessen erste Ausbaustufe – ein produktionsreifes hybrides Retrieval mit Berechtigungsfilterung und Quellenangaben ist bereits ein eigenständig verkaufbares Produkt und de facto der Knowledge Vault ohne Graph-Schicht.
K3 – Konflikt zwischen sokratischer Didaktik und Verkürzung von Lernprozessen. Der Entwurf schreibt vor, dass der Tutor direkte Antworten "konsequent verweigert". Der Kunde will aber Onboarding und Schulungen beschleunigen. Ein Techniker mit einer konkreten Prozessfrage im Arbeitskontext will keine Gegenfrage, sondern die belegte Antwort, sofort. Das Konzept unterscheidet nicht zwischen einem Nachschlage-Modus und einem Lern-Modus. Das ist ein konzeptioneller Fehler, kein Detail; die Auflösung erfolgt in Abschnitt 5.2.
K4 – Nachvollziehbarkeit versus Deep Knowledge Tracing. DKT-Modelle sind Blackboxes: Warum das System eine Grundlagenwiederholung verordnet, ist nicht erklärbar – im direkten Widerspruch zur Anforderung Nachvollziehbarkeit. Regelbasierte Ansätze und BKT sind interpretierbar. Der Entwurf nennt beide Verfahren gleichrangig, ohne den Zielkonflikt zu benennen. Hinzu kommt das Cold-Start-Problem: DKT benötigt große Interaktionsdatenmengen, die bei typischen Mittelstandskunden nie entstehen werden. Beides spricht für regelbasiert/BKT als Standard; die Entscheidung fällt in 5.4 endgültig.
K5 – Regulatorik ist unterbelichtet. Ein System, das Kompetenzen von Beschäftigten kontinuierlich bewertet und daraus Konsequenzen ableitet, fällt sehr wahrscheinlich unter die Hochrisiko-Kategorie des EU AI Act (Anhang III: allgemeine und berufliche Bildung, Beschäftigung) und ist in Deutschland mitbestimmungspflichtig (§ 87 BetrVG, Leistungs- und Verhaltenskontrolle). Der Entwurf erwähnt den AI Act nur als Verkaufsargument für Souveränität, nicht als Designconstraint. Für ein B2B/B2G-Produkt ist das eine Lücke, die der Kunde – oder dessen Kunde – sofort sehen wird.
K6 – Die Anforderung Geschwindigkeit wird nicht operationalisiert. Lokale LLM-Inferenz On-Premise setzt GPU-Hardware beim Endkunden voraus. Modellgröße, Latenz, Kosten: Der Entwurf schweigt dazu vollständig. Ohne Dimensionierungsaussage verspricht das Konzept etwas, das am fehlenden GPU-Budget des ersten Endkunden scheitern kann.
4.3 Lücken
L1 – Der Entstehungsprozess des Wissensgraphen fehlt. Der Graphaufbau ist der aufwendigste Teil des Vorhabens; der Entwurf behandelt ihn als gegeben ("das System extrahiert Entitäten"). Es fehlen der redaktionelle Workflow, die Validierungsverantwortung und die Autorenwerkzeuge. Ohne diese Antwort ist der Pedagogical Orchestrator ein Motor ohne Treibstoff. Auflösung in 5.3.
L2 – Das Betreibermodell fehlt. Der Entwurf ist aus der Perspektive eines Systems geschrieben, nicht eines Produkts, das dutzendfach ausgerollt wird: Mandantenfähigkeit, Rollenteilung zwischen mastersolution und Endkunde, Updates bei On-Premise-Installationen bleiben unbeantwortet. Auflösung in 5.5.
L3 – Erfolgsmessung fehlt. "Verkürzung von Lernprozessen" ist die zentrale Nutzenaussage, aber es gibt keine Metrik, keinen Vergleichsmaßstab, kein Evaluationskonzept – auch nicht für das Vertrauensziel der Suche. Auflösung in 5.6.
L4 – Die Moodle-Realität ist unbeantwortet. mastersolution ONE basiert auf Moodle; Moodle 4.5 bringt ein natives AI-Subsystem. Ob die Integration als Moodle-Plugin in dieses Subsystem erfolgt oder als eigenständiger Dienst daneben, hat massive Auswirkungen auf Aufwand und Wartbarkeit. Die Frage bleibt als bewusst offener Punkt im Register (Kapitel 8) und ist vor Beginn der Implementierung von Stufe 1 zu entscheiden.
5. Lösungskonzept
5.1 Phasenmodell: vier Ausbaustufen
Das Lösungskonzept ordnet die Funktionalität in vier aufeinander aufbauende Stufen. Drei Eigenschaften machen dieses Modell tragfähig: Komplexität und Risiko steigen monoton – die frühen Stufen sind mit der vorhandenen Teamkompetenz sofort machbar, die schwierigen Teile kommen, wenn das Fundament trägt. Jede Stufe ist eigenständig produktiv nutzbar und verkaufbar und erfüllt bereits Kernanforderungen. Und jede Stufe erzeugt Daten und Erkenntnisse für die nächste – die Suchlogs aus Stufe 1 zeigen, was Nutzer tatsächlich fragen, was die Graph-Modellierung in Stufe 3 informiert.
flowchart TD
S1["Stufe 1: Souveräne Suche<br/>Hybrides Retrieval, Berechtigungsfilter, Quellen,<br/>Video-Pipeline (parallel), Evaluationsframework"]
S2["Stufe 2: Nachschlage-Assistent<br/>Souveränes LLM, Grounded Q&A, Timestamps<br/>+ vorgezogen: Graph-Pilot, juristische Begleitung"]
S3["Stufe 3: Kompetenzmodell und Tracking<br/>Wissensgraph, Redaktionsworkflow,<br/>regelbasiertes Tracking, Regulatorik-Paket"]
S4["Stufe 4: Adaptive Didaktik<br/>Fragengenerierung → Lernpfade → Coaching"]
S1 --> S2 --> S3 --> S4
Stufe 1: Souveräne Suche
Das produktionsreife Modul aus dem vorhandenen PoC: hybrides Retrieval (BM25 + Embedding-Modelle, Score-Fusion z. B. über Reciprocal Rank Fusion), Cross-Encoder-Reranking als Präzisionsstufe, Berechtigungsfilterung als Kernfeature von Anfang an – jedes Suchergebnis wird vor Anzeige gegen die Nutzerrolle geprüft. Ergebnisdarstellung mit Quellenangabe und direktem Absprung ins Dokument. Bestandteil der Stufe ist das Evaluationsframework (Goldstandard-Testset, nDCG/MRR, Latenzmessung), denn das Vertrauensziel ist ohne Messung nicht erreichbar; dasselbe Framework wird später zum Update-Gate (5.5).
Bewusst nicht enthalten: kein LLM, keine generierten Antworten. Die Suche liefert Fundstellen, keine Synthese. Das hält die Stufe frei von Halluzinationsrisiken und GPU-Anforderungen und macht sie auf vorhandener Serverhardware der Endkunden lauffähig.
Als paralleler Strang läuft die Ingestion-Pipeline für Video: Der Materialbestand der Endkunden enthält viel Video-Content, der bislang selten transkribiert ist. Die Pipeline (lokale Speech-to-Text-Modelle der Whisper-Klasse, keine Cloud-APIs) zerlegt Transkripte in zeitgestempelte Segmente; ein Suchtreffer verlinkt damit bereits in Stufe 1 direkt auf die relevante Videostelle – ohne LLM. Die Pipeline ist architektonisch von der Retrieval-Logik entkoppelt: Die Suche geht mit Textdokumenten (HTML, PDF) produktiv, Videos kommen inkrementell in den Index; ein Transkriptionsstau blockiert nie den Suchbetrieb. Zwei bekannte Risiken: Fachterminologie (industrielle Begriffe, Produktnamen, Abkürzungen sind für generische ASR-Modelle fehleranfällig – es braucht domänenspezifisches Vokabular pro Mandant und eine Stichproben-Qualitätsprüfung) und rein visuelle Inhalte ohne Kommentar (eine Transkription erfasst sie nicht; Keyframe-Beschreibung per Vision-Modell ist die Antwort, aber bewusst als optionale Erweiterung ab Stufe 2, nicht im Kern).
Ebenfalls ab Stufe 1 im Datenmodell verankert: die Inhaltsklassifikation "nur im Kurskontext" (Begründung in 5.2 – nachträgliches Umklassifizieren des Gesamtbestands wäre teuer).
Stufe 2: Nachschlage-Assistent
Das souveräne LLM kommt ins Spiel, in der einfachsten sinnvollen Rolle: Grounded Q&A. Der Nutzer stellt eine Frage, das Retrieval aus Stufe 1 liefert die belegten Fundstellen, das LLM synthetisiert daraus eine Antwort mit Quellenangaben – strikt begrenzt auf die gefundenen Inhalte, mit expliziter Fehlanzeige bei fehlender Materialdeckung. Video-Timestamps werden in Antworten eingebettet. Dies ist der Nachschlage-Modus (5.2): schnelle, belegte Antworten im Arbeitskontext, keine Didaktik.
In dieser Stufe fällt die Infrastrukturentscheidung (Modellauswahl, Quantisierung, GPU-Dimensionierung, On-Premise vs. Rechenzentrum) – zu einem Zeitpunkt, an dem das restliche System noch nicht davon abhängt. Die Erprobungsergebnisse liefern die Zahlen für die Sizing-Profile (5.5). Gegen Ende der Stufe starten zwei vorgezogene Arbeitspakete: der Graph-Pilot mit einem Referenzkurs (5.3) und die juristische Begleitung (5.4).
Stufe 3: Kompetenzmodell und Tracking
Der Wissensgraph wird aufgebaut – LLM-gestützt extrahiert, redaktionell validiert; der vollständige Redaktionsworkflow ist Bestandteil dieser Stufe (5.3). Darauf setzt das regelbasierte, interpretierbare Tracking auf: Kompetenzstände pro Nutzer auf Basis expliziter Lernereignisse, nachvollziehbare Regeln für Wiederholungsempfehlungen, Backlinks und Feedforwards. Jede Empfehlung speichert Regel und Datengrundlage (Logging- und Begründungskonzept im Datenmodell von Anfang an). Mit dieser Stufe greift die Regulatorik vollständig; das Regulatorik-Paket (Konformitätsdokumentation, Muster-Betriebsvereinbarung, DSFA-Vorlage) ist Teil des Stufenumfangs, nicht Nacharbeit.
Stufe 4: Adaptive Didaktik
Die generativen und adaptiven Komponenten, intern in dieser Reihenfolge: zuerst die Fragengenerierung entlang der Bloom-Stufen mit verpflichtendem Experten-Review vor Veröffentlichung – sie ist die am wenigsten riskante generative Komponente (der Mensch prüft vor Wirkung) und liefert dem Tracking zusätzliche Datenpunkte. Dann die automatische Lernpfadgenerierung aus Graph und Lernstand (Delta-Analyse Soll/Ist, berechtigungskonforme Sequenzierung, adaptive Anpassung). Zuletzt der Coaching-Modus mit sokratischer Gesprächsführung (Eliciting → Probing/Guiding → Reconciling, Scaffolding mit Fading). Optional: BKT als probabilistische Verfeinerung des Trackings, sofern die Datenlage des jeweiligen Endkunden es hergibt.
Komponenten-Mapping
Keine Komponente des ursprünglichen Entwurfs wird verworfen; sie werden gestaffelt aufgebaut:
| Komponente | Stufe 1 | Stufe 2 | Stufe 3 | Stufe 4 |
|---|---|---|---|---|
| Sovereign Knowledge Vault | Vektor-Index + BM25, Ingestion inkl. Video, Inhaltsklassifikation | + multimodale Einbettung in Antworten | + Graph-Schicht | – |
| Context & Role Manager | Berechtigungsfilter (lesend) | unverändert | + LMS-Telemetrie (explizite Lernereignisse) | + Aktionen (z. B. Einschreibung) |
| Sovereign Reasoning Core | – | LLM, Grounded Q&A | + Graph-Extraktion (Redaktion) | + didaktische Prompts, Fragengenerierung |
| Cognitive Learner Engine | – | – | regelbasiertes Tracking | + BKT (optional) |
| Pedagogical Orchestrator | – | – | Regeln für Backlinks/Feedforwards | Lernpfade, Sokratik, Modus-Policies |
| Adaptive Interface | Suchoberfläche | Chat + Timestamps | Fortschrittsansicht, Begründungsanzeige | Coaching-Dialog, Modus-Schalter |
| Curation & Review Workbench (neu) | – | Pilot | Redaktionsworkflow produktiv | Fragen-Review |
| Evaluation & Telemetry Framework (neu) | Goldstandard, Metriken | + Groundedness, Abstinenz | + Tracking-Validität | + Wirkungsmetriken |
Die beiden neuen Komponenten (Workbench, Evaluationsframework) sind Ergebnis der Lückenanalyse L1 und L3; Begründung in Kapitel 6.
5.2 Interaktionsmodi: Nachschlagen und Coaching
Die Auflösung von Kritikpunkt K3 ist die explizite Unterscheidung zweier Modi mit einer dreistufigen Policy-Hierarchie. Automatische Kontexterkennung ("das System merkt, dass du lernst") wird verworfen: Sie wäre intransparent – im Widerspruch zur Nachvollziehbarkeitsanforderung – und fehleranfällig, denn die Motivation einer Frage ist von außen nicht zuverlässig erkennbar. Der Nutzer weiß es selbst am besten.
Ebene 1 – Systemdefault: Außerhalb von Kursen (Einstieg über Suche, freie Frage im Arbeitskontext) gilt der Nachschlage-Modus: schnelle, belegte Antwort ohne Didaktik.
Ebene 2 – Autorenpolicy pro Kurs: Der Kurs-Autor legt fest, welche Modi im Kurs verfügbar sind und welcher Default gilt. Drei Policies: frei (Nutzer wählt, Default Nachschlagen), Coaching empfohlen (Nutzer wählt, Default Coaching), Coaching erzwungen (kein Umschalten – etwa für Prüfungsvorbereitung oder Compliance-Schulungen, deren Lernziel direkte Antworten unterlaufen würden). Der Autor überstimmt damit nicht die einzelne Nutzerwahl, sondern definiert den Rahmen, in dem gewählt werden darf.
Ebene 3 – Nutzerwahl innerhalb der Policy: Wo erlaubt, schaltet der Nutzer jederzeit um – über einen sichtbaren Schalter, nicht versteckt in Einstellungen.
Statusabhängige Standard-Policy: Als Standardempfehlung gilt die statusabhängige Variante: Bei erstmaliger Kursbelegung gilt Coaching; nach bestandenem Kurs kann der Nutzer jederzeit zurückkehren und im Nachschlage-Modus interagieren. Diese Variante ist bewusst der rollenabhängigen (z. B. Coaching-Pflicht nur für Auszubildende) vorgezogen: Sie nutzt ein Datum, das das LMS ohnehin führt (formaler Kursabschluss) und benötigt nicht einmal das Stufe-3-Tracking; sie ist trivial nachvollziehbar ("du hast bestanden, deshalb steht dir der Fragemodus offen"); und sie umgeht das Ungleichbehandlungsproblem, weil der Status durch eigene Leistung erreichbar ist statt durch Rollenzuweisung. Sie macht den bestandenen Kurs zum nachschlagbaren Referenzmaterial für den Arbeitsalltag – die Doppelnutzung, die Schulungsinhalte wertvoller macht. Rollenabhängige Policies bleiben technisch trivial abbildbar (Context & Role Manager), sind aber wegen der Mitbestimmungsrelevanz von Ungleichbehandlung nur Option, nicht Standard (Register O6). Bei wiederkehrenden Pflichtschulungen muss definiert sein, ob der Status beim Neuantritt zurückfällt; das ist eine Autoreneinstellung, kein Konzeptproblem (Register O5).
Der Leakage-Pfad und seine Schließung: Erzwingt ein Kurs Coaching, könnte der Nutzer den Kurs verlassen und dieselbe Frage der freien Suche stellen – die Policy wäre wirkungslos. Die Lösung nutzt die vorhandene Stufe-1-Architektur: Die Berechtigungsfilterung des Knowledge Vault wird um eine Inhaltsklassifikation erweitert. Der Autor markiert bestimmte Materialien (Musterlösungen, Prüfungsfragen samt Antworten) als "nur im Kurskontext"; sie erscheinen im freien Nachschlage-Index gar nicht erst. Kein neuer Mechanismus, sondern Wiederverwendung des Rollenfilters – deshalb gehört die Klassifikation ab Stufe 1 ins Datenmodell.
Transparenz im Interface: Der aktive Modus ist jederzeit sichtbar, idealerweise mit unterschiedlicher visueller Anmutung (Nachschlagen: kompakte Antwort mit Quellenliste; Coaching: dialogischer Stil). Ist Coaching erzwungen, sagt das System das offen ("In diesem Kurs begleite ich dich zur Lösung, statt sie direkt zu nennen"). Andernfalls wird die Didaktik als Fehlfunktion wahrgenommen und das Vertrauensziel beschädigt. Das Antwortformat des Stufe-2-Assistenten ist von Beginn an so zu gestalten, dass in Stufe 4 ein zweiter Antwortstil danebentreten kann, ohne das Interface umzubauen.
5.3 Wissensgraph und Redaktionsworkflow
Dieser Abschnitt löst Lücke L1 – nach dem Phasenmodell der gewichtigste Konzeptbaustein, weil ohne ihn die Stufen 3 und 4 kein Fundament haben.
5.3.1 Datenmodell
Der Wissensgraph besteht aus zwei Bausteinen. Knoten sind Kompetenzen bzw. Wissenskonzepte: abgrenzbare Einheiten dessen, was jemand können oder wissen soll ("Manometer ablesen", "Sicherheitsregeln bei Hochvoltanlagen", "Druckabfall-Ursachen diagnostizieren"). Die Granularitäts-Faustregel: Ein Knoten ist etwas, das sich mit einer Handvoll Prüfungsfragen sinnvoll testen lässt. Feiner geschnitten wird der Graph unpflegbar, gröber wird das Tracking nutzlos ("Kompetenz Hydraulik: 60 %" sagt niemandem etwas).
Kanten sind typisierte Beziehungen. Im Sinne der Pragmatik-Anforderung sind genau drei Typen vorgesehen, die alle Szenarien des Brainstormings tragen: setzt-voraus (Kompetenz → Kompetenz; treibt Backlinks, Feedforwards und Lernpfad-Sequenzierung), wird-vermittelt-durch (Kompetenz → Materialabschnitt: Video-Segment, HTML-Kapitel) und wird-geprüft-durch (Kompetenz → Quizfrage; die Kante, über die das Tracking weiß, welche falsche Antwort welche Kompetenz betrifft). Weitere Beziehungstypen (z. B. Ähnlichkeit) sind bewusst zurückgestellt.
Zur Veranschaulichung ein Miniaturbeispiel (Domäne Druckprüfung) mit allen drei Kantentypen:
flowchart TD
H[Hydraulik-Grundlagen]
M[Messtechnik]
D[Druckmessung durchführen]
F[Fehlerdiagnose Druckabfall]
MAT1[/"Video H-03, Segment 02:10–04:35"/]
Q1[/"Quizfragen 12–15"/]
H -->|setzt-voraus| D
M -->|setzt-voraus| D
D -->|setzt-voraus| F
MAT1 -.wird-vermittelt-durch.-> D
Q1 -.wird-geprüft-durch.-> D
Die Speicherung ist unkritisch (Graphdatenbank oder relational); das Neue ist nicht die Haltung der Daten, sondern ihre Erstellung.
5.3.2 Der teilautomatisierte Workflow
Kerngedanke: Das LLM verwandelt Erstellungsarbeit in Prüfarbeit. Der Mensch erschafft den Graphen nicht, er begutachtet Vorschläge. Die Pipeline umfasst fünf Schritte:
flowchart TD
MAT[Materialbestand im Knowledge Vault]
EX["(1) LLM-Extraktion<br/>Kandidaten mit Belegpflicht"]
KON["(2) Konsolidierung<br/>Dubletten, Terminologie"]
REV["(3) Fachliche Prüfung durch Experten<br/>annehmen / bearbeiten / ablehnen"]
FREI["(4) Freigabe<br/>versionierter Graph aktiv"]
MAT --> EX --> KON --> REV --> FREI
FREI -. "(5) Materialänderung: Differenzvorschlag" .-> EX
style REV stroke-width:3px
1. Extraktion mit Belegpflicht. Das souveräne LLM aus Stufe 2 (keine neue Infrastruktur) analysiert die Materialien und schlägt Kompetenz-Kandidaten samt Beziehungen vor. Designregel: Jeder Vorschlag muss mit einem Textbeleg verankert sein – der konkreten Stelle im Dokument oder Transkript, aus der er stammt. Vorschläge ohne Beleg werden verworfen, bevor ein Mensch sie sieht. Das unterdrückt Halluzinationen strukturell (das Modell kann keine Kompetenz erfinden, die nirgends im Material steht) und beschleunigt die Prüfung (der Experte liest den Beleg neben dem Vorschlag, statt selbst zu suchen). Es ist dasselbe Grounding-Prinzip wie beim Nachschlage-Assistenten, nach innen gewendet.
2. Konsolidierung. Dasselbe Konzept erscheint über Dokumente hinweg unter verschiedenen Namen ("Manometer ablesen" / "Druckanzeige prüfen"). Über Embedding-Ähnlichkeit (Stufe-1-Kompetenz) werden Kandidaten geclustert und Zusammenführungen vorgeschlagen. Ohne diesen Schritt erstickt der Graph an Dubletten und das Tracking führt dieselbe Kompetenz mehrfach.
3. Fachliche Prüfung. Der Experte arbeitet in der Curation & Review Workbench mit drei Aktionen pro Vorschlag: annehmen, bearbeiten, ablehnen. Zwei Stellhebel entscheiden über die Zumutbarkeit: Die Oberfläche priorisiert nach Konfidenz und Wirkung – setzt-voraus-Kanten zuerst, denn Fehler dort schlagen direkt auf Nutzer durch (falsche Wiederholungsempfehlungen, blockierte Lernpfade), während eine ungenau benannte Kompetenz nur kosmetisch stört. Und automatische Strukturprüfungen laufen vor dem Menschen: Zyklen in Voraussetzungsketten werden maschinell erkannt und markiert, ebenso verwaiste Kompetenzen ohne Material- oder Fragenverknüpfung. Der Mensch prüft Fachlichkeit, nicht Formalien.
4. Freigabe und Versionierung. Der Graph geht als Version live; jede Änderung ist protokolliert (wer hat wann welchen Vorschlag angenommen). Das ist zugleich die Datengovernance-Dokumentation, die der AI Act für Stufe 3 verlangt – der Redaktionsworkflow erzeugt die Compliance-Artefakte aus Designprinzip P5 nebenbei.
5. Laufende Pflege. Material ändert sich. Bei Aktualisierung eines Dokuments oder Austausch eines Videos stößt das System eine Neu-Extraktion nur für dieses Material an und legt dem Experten einen Differenzvorschlag vor ("diese zwei Kompetenzen wären betroffen, diese Kante entfiele") statt einer Komplettprüfung. Ohne diesen Mechanismus veraltet der Graph schleichend – und ein veralteter Graph ist schlimmer als keiner, weil er falsche Empfehlungen mit Autorität ausspricht.
5.3.3 Warum nicht vollautomatisch
Fachlich: Voraussetzungsbeziehungen sind oft implizites Expertenwissen, das im Material nicht explizit steht – ein erfahrener Ausbilder weiß, dass Konzept A vor B zu lernen ist, auch wenn kein Dokument es sagt. Das LLM findet nur, was belegt ist; die Lücken schließt der Experte. Regulatorisch: Der Graph steuert ab Stufe 3 Empfehlungen mit Wirkung auf Beschäftigte – die menschliche Freigabe seiner Struktur ist wesentlicher Teil der "menschlichen Aufsicht" nach AI Act. Der Review-Schritt ist kein wegzuoptimierender Kostenfaktor, sondern ein ohnehin geschuldeter Compliance-Baustein.
5.3.4 Aufwandserwartung und Verantwortung
Ehrliche Erwartung (gehört sinngemäß auch ins Kundendokument): Teilautomatisiert heißt nicht aufwandsfrei. Erfahrungswerte vergleichbarer Extraktionsprojekte legen eine Aufwandsreduktion um grob eine Größenordnung gegenüber manueller Erstellung nahe – pro Kurs bleibt aber eine Prüfsitzung von Stunden, nicht Minuten. Die Fachexpertise liegt beim Endkunden (dessen Prozesse, dessen Maschinen); der Review-Experte ist typischerweise ein Trainer oder Fachverantwortlicher des Endkunden. Konsequenz: Die Workbench ist kein internes Werkzeug, sondern Produktbestandteil mit Benutzbarkeitsanspruch für Nicht-Techniker.
Timing: Formal gehört der Graphaufbau zu Stufe 3; der Pilot mit einem Referenzkurs startet jedoch gegen Ende von Stufe 2 – die LLM-Infrastruktur steht dann bereits, und die Pilot-Erfahrungen (Granularität, Prüfaufwand, Oberflächenbedarf) informieren die Stufe-3-Planung, bevor sie festgezurrt ist.
5.4 Regulatorik als Designprinzip
Dieser Abschnitt löst Kritikpunkt K5: Regulatorik nicht als Risikoabsatz im Anhang, sondern als konkrete Architekturentscheidungen. Vorbehalt: Die folgende Einordnung ist keine Rechtsberatung; eine juristische Prüfung ist als Projektschritt eingeplant (Beginn Ende Stufe 2, Register O3).
Zeitdruck: Die wesentlichen Pflichten des EU AI Act für Hochrisiko-Systeme nach Anhang III gelten ab August 2026 – praktisch jetzt. Ein Produkt, das in Stufe 3 geht, steht von Tag eins unter dem vollen Regime. Nachrüsten ist keine Option, weil Pflichten wie Logging und Dokumentation die Architektur betreffen.
Einstufung je Stufe (zugleich ein Vorteil des Phasenmodells – die riskanten Teile kommen später und können vorbereitet werden):
| Stufe | Voraussichtliche Einstufung | Wesentliche Pflichten |
|---|---|---|
| 1: Suche | Kein relevantes KI-Risiko (Retrieval, keine Personenbewertung) | Keine spezifischen; DSGVO-Basispflichten |
| 2: Nachschlage-Assistent | Begrenztes Risiko | Transparenz: Kennzeichnung als KI, Hinweis auf mögliche Fehler |
| 3: Kompetenztracking | Sehr wahrscheinlich Hochrisiko (Anhang III: Bewertung von Lernergebnissen; Beschäftigtenkontext) | Risikomanagement, Datengovernance, technische Dokumentation, Logging, menschliche Aufsicht, Genauigkeitsnachweise |
| 4: Adaptive Didaktik | Hochrisiko, soweit Zugang zu Bildung gesteuert wird (Lernpfade, Freischaltung); Fragengenerierung mit Review eher unkritisch | Wie Stufe 3, plus Nachweis menschlicher Kontrolle über generierte Inhalte |
Dazu zwei deutsche Ebenen, für die Endkunden oft die härtere Hürde: Mitbestimmung (Kompetenztracking ist Leistungs- und Verhaltenskontrolle; der Betriebsrat muss per Betriebsvereinbarung zustimmen, § 87 BetrVG) und DSGVO Art. 22 (vollautomatisierte Entscheidungen mit erheblicher Wirkung – automatisches Sperren eines Moduls, Verordnen einer Pflichtwiederholung – nur mit Schutzmechanismen zulässig).
Daraus folgen fünf Designprinzipien:
P1 – Empfehlung statt Entscheidung als Systemgrundsatz. Das System verordnet nichts automatisch – es empfiehlt die Grundlagenwiederholung, schlägt den Lernpfad vor, markiert den Freischaltungskandidaten. Die verbindliche Konsequenz zieht ein Mensch (Nutzer, Trainer, Vorgesetzter), oder sie ist rein unterstützend ausgestaltet. Das entschärft Art. 22 DSGVO und liefert die menschliche Aufsicht des AI Act strukturell statt als nachträglichen Genehmigungs-Button. Konfigurierbar: Manche Endkunden werden Automatik wollen und die Verantwortung übernehmen; der Auslieferungszustand ist konservativ.
P2 – Interpretierbarkeit als Architekturentscheidung, nicht als Option. Beantwortet K4 endgültig: Regelbasiertes Tracking und später BKT sind der Standard, weil jede Empfehlung auf benennbare Regeln und Datenpunkte zurückführbar ist ("Kompetenz X dreimal in Folge nicht bestanden, Voraussetzung Y zuletzt vor acht Monaten geprüft"). Genau diese Begründung wird dem Nutzer angezeigt – Transparenzpflicht und Kundenanforderung Nachvollziehbarkeit werden mit demselben Mechanismus erfüllt. Deep-Learning-Verfahren (DKT) sind eine dokumentierte Nicht-Entscheidung: Blackbox-Charakter im Widerspruch zur Nachvollziehbarkeit, Cold-Start-Problem bei Mittelstandskunden ohne große Interaktionsdatenmengen.
P3 – Datenminimierung bei der Telemetrie. Der Ursprungsentwurf wollte Verweildauern, Navigationsmuster, Tipprhythmen erfassen. Jedes dieser Signale erhöht Mitbestimmungs- und Datenschutzaufwand; für regelbasiertes Tracking sind sie unnötig. Standard: Nur explizite Lernereignisse (Quizantworten, Modulabschlüsse) fließen ins Tracking. Verhaltenstelemetrie ist eine spätere, separat zu vereinbarende Ausbauoption. Pragmatismus und Compliance zeigen hier in dieselbe Richtung – auch Speicher- und Komplexitätskosten sinken.
P4 – Getrennte Sichten für Nutzer und Organisation. Der Lernende sieht seinen eigenen Kompetenzstand vollständig. Vorgesetzte und Personalentwicklung sehen standardmäßig aggregierte oder anlassbezogene Sichten (Abschlussquoten, Zertifikatsstatus), nicht das individuelle Schwächenprofil. Individuelle Einsicht ist möglich, aber als bewusste, protokollierte Konfiguration des Endkunden, die dieser in seiner Betriebsvereinbarung regelt. Das nimmt dem System den Charakter eines Überwachungswerkzeugs – für die Akzeptanz bei den Lernenden ohnehin entscheidend.
P5 – Compliance-Artefakte als Produktbestandteil. mastersolution ist Anbieter im Sinne des AI Act, die Endkunden sind Betreiber – und die wenigsten Mittelständler können die Betreiberpflichten allein stemmen. Ausgeliefert werden: technische Dokumentation, Logging-Konzept, Muster-Datenschutzfolgenabschätzung, Vorlage für die Betriebsvereinbarung. Regulatorik wird damit vom Hindernis zum Verkaufsargument, exakt anschlussfähig an die Souveränitätspositionierung: nicht nur "deine Daten bleiben bei dir", sondern "du kannst das System rechtssicher einführen". Kein Wettbewerber aus der US-Cloud-Welt kann das glaubwürdig anbieten.
Konsequenzen für das Phasenmodell: Das Logging- und Begründungskonzept (jede Empfehlung speichert Regel + Datengrundlage) gehört von Anfang an ins Datenmodell von Stufe 3. Die juristische Begleitung startet als Arbeitspaket am Ende von Stufe 2, nicht erst wenn Stufe 3 entwickelt ist.
5.5 Betreibermodell
Dieser Abschnitt löst Lücke L2. Ausgangspunkt ist eine Realität, die der Ursprungsentwurf ausblendet: mastersolution betreibt nicht ein System, sondern liefert ein Produkt, das in zwei Welten laufen muss – als gehostete Instanz im deutschen Rechenzentrum und als autarke On-Premise-Installation. Beide Welten müssen mit derselben Codebasis funktionieren, sonst erdrückt der doppelte Wartungsaufwand das Produkt wirtschaftlich.
Abgrenzung der Beziehungsebenen: Das Betreibermodell beschreibt den Wirkbetrieb des fertigen Produkts – also die Beziehung zwischen mastersolution als Produktanbieter und dessen Endkunden als Betreibern (zugleich die Anbieter-/Betreiber-Logik des AI Act). Davon zu trennen ist die Entwicklungsebene: Wir sind Entwicklungspartner von mastersolution, und welche der im Folgenden mastersolution zugeordneten Aufgaben während der Entwicklung und ggf. im laufenden Betrieb tatsächlich durch uns ausgeführt werden (Unterauftrag, Betriebsunterstützung, Übergabezeitpunkte je Stufe), ist eine offene kommerzielle Frage, die vor Beauftragung von Stufe 1 zu klären ist (Register O8). Die Zuordnungen in diesem Abschnitt sind also als Ziel-Verantwortung im Produktbetrieb zu lesen, nicht als Aussage darüber, wer die Fähigkeit initial aufbaut.
5.5.1 Trennlinie zwischen Produkt und Mandant
Produktseitig (von mastersolution gepflegt, für alle identisch): die Software, die KI-Modelle (Embedding-Modell, Reranker, LLM, ASR-Modell), das Evaluationsframework, Regelwerk-Vorlagen für das Tracking, die Curation & Review Workbench, die Compliance-Artefakte (Dokumentationsvorlagen, Muster-Betriebsvereinbarung).
Mandantenspezifisch (pro Endkunde entstehend und dort verbleibend): Materialbestand, Index, Wissensgraph, Fachvokabular für die Transkription, Rollen und Berechtigungen, Autoren-Policies, sämtliche Lernstände und Logs.
Daraus folgt die Festlegung, die das Souveränitätsversprechen vervollständigt: Die Modelle werden nicht auf Mandantendaten trainiert oder feingetunt. Die gesamte Kundenspezifik entsteht über Retrieval, Index und Graph – über Daten beim Mandanten, nicht über Modellgewichte. Drei Vorteile: Keine Information kann von Mandant A über das Modell zu Mandant B wandern; alle Mandanten profitieren von zentralen Modellverbesserungen; ein Modell-Update kann kundenspezifisches Verhalten nicht "vergessen", weil keines in den Gewichten steckt. Feintuning bleibt als kostenpflichtige Sonderleistung für Großkunden mit eigener Instanz denkbar, ist aber bewusst nicht der Standard.
5.5.2 Verantwortungsmatrix
| Aufgabe | mastersolution | Endkunde |
|---|---|---|
| Plattform, Modelle, Updates | verantwortlich | – |
| Ingestion-Pipeline einrichten | verantwortlich (Mandanten-Einführung) | liefert Material |
| Wissensgraph: Extraktion | System (automatisch) | – |
| Wissensgraph: fachliche Prüfung | unterstützt (Schulung, Werkzeug) | verantwortlich (Fachexperte) |
| Rollen, Berechtigungen, Policies | Werkzeug | verantwortlich |
| Betriebsvereinbarung, DSFA | liefert Vorlagen | verantwortlich (Betreiberpflicht) |
| Qualitätsüberwachung (Retrieval-Metriken) | Framework + SaaS-Betrieb | bei On-Premise: führt Messung aus |
| Hardware-Betrieb On-Premise | Sizing-Vorgaben, Support | verantwortlich |
Die Matrix macht die fachliche Hoheit über den Graphen beim Endkunden und die Werkzeug- und Prozesshoheit bei mastersolution verbindlich. Das ist zugleich die AI-Act-Logik (Anbieter/Betreiber) und im Kern die Grundlage der vertraglichen Pflichtenteilung.
5.5.3 Updates als beherrschtes Risiko: das Update-Gate
Bei KI-Systemen ändert ein Modellwechsel Verhalten, nicht nur Funktionen: Ein neues Embedding-Modell kann die Suchqualität für die Fachbegriffe eines Kunden verschlechtern, während es im Durchschnitt besser ist; ein LLM-Update kann den Antwortstil verändern. Die Antwort ist im Phasenmodell bereits angelegt: Das Evaluationsframework aus Stufe 1 wird zum Update-Gate. Jeder Mandant besitzt ein eigenes Goldstandard-Testset (aufgebaut bei der Mandanten-Einführung, gepflegt aus realen Suchanfragen); ein Modell-Update wird erst aktiviert, nachdem die Evaluations-Suite auf der Kundeninstanz gegen dieses Testset gelaufen ist und keine Regression zeigt. Dazu gehören versionierte Modell-Releases mit Rollback-Fähigkeit: Das neue Modell wird parallel installiert, geprüft, umgeschaltet; das alte bleibt als Rückfalloption. Nebeneffekt: Der beim Embedding-Wechsel nötige Index-Neubau (bei großen Beständen Stunden) wird zum unterbrechungsfreien Hintergrundprozess statt zur Downtime.
Für vollständig abgeschottete Installationen: signierte Offline-Update-Pakete, die Modelle, Software und Evaluations-Suite bündeln und vor Ort ohne Netzverbindung durchlaufen. Aufwendiger – aber exakt die Disziplin, die die Marktposition des Kunden begründet und die kein US-Cloud-Anbieter anbieten kann.
Die Kehrseite der Abschottung: mastersolution erhält von On-Premise-Instanzen keine Nutzungsdaten zur Produktverbesserung. Vorschlag: ein Opt-in-Telemetriekonzept, das ausschließlich aggregierte Qualitätsmetriken exportiert (Retrieval-Kennzahlen, Antwortlatenzen, Nutzungsvolumen – nie Inhalte, nie personenbezogene Daten), mit einem Exportpaket, das der Kunde vor Übermittlung einsehen kann. Wer auch das ablehnt, bleibt vollständig dunkel; das Produkt muss auch damit leben können.
5.5.4 Hardware-Dimensionierung
Hiermit wird K6 ("Geschwindigkeit") operationalisiert; die Stufen haben radikal unterschiedliche Hardwareprofile:
Stufe 1 kommt ohne GPU oder mit minimaler GPU-Unterstützung aus: BM25 ist trivial; Embedding-Modelle und Cross-Encoder-Reranker sind klein genug für CPU-Inferenz mit akzeptabler Latenz bei typischen Suchlasten. Die souveräne Suche läuft auf vorhandener Serverhardware der Endkunden – eine drastisch gesenkte Einstiegshürde.
Ab Stufe 2 braucht LLM-Inferenz GPU-Kapazität. Das Produkt wird mit zwei bis drei definierten Sizing-Profilen ausgeliefert – etwa ein Basisprofil (eine Inferenz-GPU, kleineres quantisiertes Modell, bis zu einer definierten Zahl gleichzeitiger Nutzer) und ein Standardprofil für größere Organisationen, jeweils mit zugesicherten Latenzkorridoren. Die konkreten Zahlen sind Ergebnis der Stufe-2-Erprobung (Register O2); die Struktur – Profile mit Zusicherungen statt "kommt drauf an" – gibt dem Vertrieb eine belastbare Antwort auf die erste Frage jedes Endkunden. Im SaaS-Betrieb wird GPU-Kapazität über Mandanten gepoolt, was die Kostenstruktur deutlich verbessert – ein Argument, die gehostete Variante zum Standardweg und On-Premise zum Premium-Angebot zu machen.
Batch-Lasten (Video-Transkription, Graph-Extraktion, Index-Neubau) sind vom interaktiven Betrieb architektonisch zu trennen: nicht latenzkritisch, laufen nachts oder auf temporär zugeschalteter Kapazität. Ein Transkriptions-Stau darf die Suchlatenz nie berühren.
5.6 Erfolgsmessung
Dieser Abschnitt löst Lücke L3. Leitprinzip: Jede Stufe hat eigene, zu ihr passende Metriken; die Messinfrastruktur der frühen Stufen trägt die späteren.
Baseline-Prinzip: "Verkürzung von Lernprozessen" ist eine Vergleichsaussage. Werden die Ist-Werte (heutige Onboarding-Dauer, Schulungsdurchlaufzeiten, Bestehensquoten, Trainer-Aufwand für Rückfragen) erst gemessen, wenn das System läuft, ist der Nachweis für immer verloren. Die Baseline-Erhebung ist deshalb Standardschritt der Mandanten-Einführung bei jedem Endkunden – kleiner Aufwand, großer Effekt: Sie verwandelt das zentrale Verkaufsversprechen von einer Behauptung in eine belegbare Zahl und liefert mastersolution Referenzmaterial für den Vertrieb.
| Stufe | Qualitätsmetriken (Systemsicht) | Wirkungsmetriken (Nutzersicht) |
|---|---|---|
| 1: Suche | nDCG/MRR auf Goldstandard, Null-Treffer-Quote, Latenz | Klickrate auf Treffer, Suchabbrüche, wiederkehrende Nutzung |
| 2: Assistent | Groundedness-Quote, Quellenpräzision, Abstinenz-Verhalten | beantwortete Fragen ohne menschliche Hilfe, Feedback-Quote |
| 3: Graph + Tracking | Graphabdeckung, Prüfaufwand pro Kurs, Tracking-Validität | Akzeptanz und Wirksamkeit von Empfehlungen |
| 4: Adaptive Didaktik | Freigabequote generierter Fragen, Pfadqualität | Time-to-Competency, Bestehensquoten, Onboarding-Dauer |
Stufe 1 – Vertrauen messbar machen: Die technischen Metriken (nDCG auf dem Goldstandard) sind zugleich das Update-Gate. Vertrauen selbst ist ein Nutzerphänomen mit zwei ehrlichen Proxies: Verhaltensdaten (kehren Nutzer zur Suche zurück, klicken sie Treffer an – oder suchen sie zweimal und geben auf?) und eine bewusst minimale In-App-Rückmeldung ("War das hilfreich?"). Die Null-Treffer-Quote verdient besondere Aufmerksamkeit: Sie zeigt Lücken im Materialbestand und ist damit zugleich Redaktionswerkzeug – die unbeantworteten Suchanfragen von heute sind die Content-Prioritäten von morgen.
Stufe 2 – Groundedness und Abstinenz: Die kritische Metrik ist der Anteil generierter Antworten, deren Aussagen vollständig durch die zitierten Quellen gedeckt sind – gemessen über regelmäßige menschliche Stichproben anhand einer einfachen Rubrik plus automatisierte Prüfung im Evaluationsframework. Ebenso wichtig das Abstinenz-Verhalten: Sagt das System "dazu finde ich nichts im Material", wenn das die richtige Antwort ist – oder fabuliert es? Dazu gehört ein Testset mit gezielt nicht beantwortbaren Fragen. Ein System, das zuverlässig schweigt, wenn es nichts weiß, ist für das Vertrauensziel wertvoller als eines, das immer irgendetwas sagt.
Stufe 3 – Validität vor Aktivität: Die entscheidende Frage ist nicht, ob das Tracking läuft, sondern ob es stimmt: Sagt die Kompetenzeinschätzung tatsächliche Prüfungsergebnisse voraus? Prüfbar durch Vergleich der Einschätzung vor einer regulären Prüfung mit deren Ergebnis – aggregiert über Nutzer, nicht individuell. Dazu die Empfehlungswirksamkeit: Wird eine empfohlene Grundlagenwiederholung angenommen, und verbessern sich die Ergebnisse danach messbar? Eine Empfehlung, die niemand befolgt oder die nichts bewirkt, ist ein Konzeptfehler, den nur diese Messung aufdeckt.
Stufe 4 – die Ernte: Erst jetzt sind die Kennzahlen messbar, die der Kunde eigentlich kauft: Time-to-Competency (Kursstart bis bestandene Kompetenzprüfung), Onboarding-Durchlaufzeit, Bestehens- und Wiederholungsquoten – jeweils gegen die Baseline. Methodische Ehrlichkeit: Ein sauberes A/B-Experiment ist im Betriebsalltag selten möglich (man kann nicht der halben Belegschaft das bessere Onboarding vorenthalten). Realistisch sind Kohortenvergleiche – Einstellungsjahrgänge vor und nach Einführung – mit benannten Störgrößen. Wissenschaftlich unvollkommen, für eine Geschäftsentscheidung tragfähig; die Alternative (keine Messung) ist schlechter.
Aggregations-Leitplanke: Sämtliche Wirkungsmetriken werden aggregiert erhoben und dienen der Produktqualität – nie der Leistungsbewertung Einzelner. Das ist die konsequente Fortsetzung von P3 und P4: Dieselbe Zahl, die als Kohortenmittelwert unproblematisch ist, wird als Individualwert im Zugriff des Vorgesetzten zum Mitbestimmungsfall. Die Messarchitektur erzwingt diese Trennung technisch, nicht nur organisatorisch: Die Auswertungsschicht kennt für Wirkungsmetriken keine Personenbezüge.
6. Komponentensicht
Kapitel 5 beantwortet "was bauen wir wann"; dieses Kapitel beantwortet "woraus besteht das System". Aus dieser Sicht werden später die Pflichtenhefte je Subsystem geschnitten. Die sechs Komponenten des Ursprungsentwurfs werden übernommen und um zwei ergänzt, die sich aus der Lückenanalyse ergeben. Englische Eigennamen werden beibehalten (Begründung im Entscheidungsregister E15); der Fließtext bleibt deutsch.
6.1 Zusammenwirken der Komponenten
Die folgende Übersicht zeigt die Komponenten und ihre wesentlichen Datenflüsse; die Schnittstellen werden anschließend an drei repräsentativen Abläufen konkretisiert, die zusammen nahezu alle Kanten abdecken.
flowchart LR
UI[Adaptive Interface]
CRM[Context & Role Manager]
ORC[Pedagogical Orchestrator]
VAULT[Sovereign Knowledge Vault]
CORE[Sovereign Reasoning Core]
CLE[Cognitive Learner Engine]
WB[Curation & Review Workbench]
EVAL[Evaluation & Telemetry Framework]
LMS[(LMS / mastersolution ONE)]
UI --> CRM
CRM --> LMS
UI --> ORC
ORC --> CLE
ORC --> VAULT
VAULT --> CORE
CORE --> UI
CLE --> LMS
CORE -.Graph-Vorschläge.-> WB
WB -.Freigabe.-> VAULT
EVAL -.misst querschneidend.-> VAULT
EVAL -.-> CORE
EVAL -.-> CLE
Ablauf A – Nachschlage-Anfrage (ab Stufe 2): Der Nutzer stellt im Adaptive Interface eine freie Frage. Der Context & Role Manager identifiziert ihn gegen das LMS und liefert Rolle, Berechtigungen und – im Kurskontext – Modus-Policy und Bestehensstatus. Die Anfrage geht mit diesen Filterkriterien an den Knowledge Vault (hybrides Retrieval, Reranking; Inhaltsklassifikation und Berechtigungen wirken hier als harte Filter). Die Fundstellen gehen an den Reasoning Core, der eine grounded Antwort mit Quellenangaben und Video-Timestamps synthetisiert oder eine explizite Fehlanzeige zurückgibt. Das Interface stellt die Antwort mit Modus-Kennzeichnung dar. In Stufe 1 endet derselbe Ablauf vor dem Reasoning Core: Das Interface zeigt die gefilterten Fundstellen direkt. Das Evaluation Framework protokolliert Metriken (Latenz, Null-Treffer, Feedback) ohne Personenbezug.
Ablauf B – gecoachte Frage im Kurs (Stufe 4): Gleiche Identifikation über den Context & Role Manager; die Policy ergibt Coaching-Modus. Die Anfrage geht nun nicht direkt ins Retrieval, sondern an den Pedagogical Orchestrator. Dieser holt von der Cognitive Learner Engine den Kompetenzstand, führt gegen die Graph-Schicht des Vault die Gap-Analyse durch und entscheidet die didaktische Reaktion (direkter Hinweis, Backlink, sokratische Gegenfrage). Erst dann instruiert er den Reasoning Core mit didaktischem Prompt und abgerufenen Fakten. Antwortet der Nutzer auf eine Quizfrage, meldet das Interface das Lernereignis über den Context & Role Manager an die Learner Engine, die den Kompetenzstand aktualisiert und ggf. eine Empfehlung samt gespeicherter Begründung (Regel + Datengrundlage) erzeugt.
Ablauf C – Redaktion und Hintergrundprozesse (Batch, ab Stufe 2/3): Neues oder geändertes Material durchläuft die Ingestion des Vault (Chunking, Transkription, Embedding). Der Reasoning Core extrahiert im Batch-Betrieb Graph-Kandidaten mit Belegen; die Workbench legt sie dem Fachexperten priorisiert vor. Freigegebene Änderungen gehen als neue Graph-Version in den Vault. Modell-Updates laufen über das Evaluation Framework als Gate: Erst nach regressionsfreiem Lauf gegen das Mandanten-Goldstandard-Testset wird umgeschaltet. Sämtliche Batch-Lasten sind vom interaktiven Pfad (Abläufe A/B) getrennt.
Zwei Strukturprinzipien werden an den Abläufen sichtbar: Der Orchestrator liegt nur im Kurs-/Coaching-Pfad – der Nachschlage-Pfad umgeht ihn bewusst, was die Latenz niedrig und die Stufen 1–2 unabhängig von Stufe-3/4-Komponenten hält. Und der Context & Role Manager ist der einzige Berührungspunkt zum LMS – alle anderen Komponenten kennen weder Identitäten noch Berechtigungsquellen, was die Moodle-Integrationsfrage (O1) auf eine Komponente isoliert.
6.2 Sovereign Knowledge Vault (Wissensablage und -vernetzung)
Zweck: Ingestion, Indizierung und logische Vernetzung aller Kursmaterialien. Stufen: 1 (Vektor-Index + BM25, Text-Ingestion, Video-Pipeline mit zeitgestempelten Transkript-Segmenten, Inhaltsklassifikation "nur im Kurskontext"), 2 (Einbettung der Timestamps in Antworten, optional Keyframe-Analyse), 3 (Graph-Schicht mit den drei Kantentypen). Änderungen gegenüber Ursprungsentwurf: Die Graph-Schicht ist nachgelagert statt konstitutiv; die Vault startet als reines Retrieval-System. Die Inhaltsklassifikation ist neu (Leakage-Pfad, 5.2). Spezifikationshinweise: Chunking-Strategie pro Materialtyp definieren (HTML-Abschnitte, Transkript-Segmente, Quizfragen als eigene Einheiten). Berechtigungs- und Klassifikationsattribute gehören an jede Index-Einheit, nicht an Dokumente als Ganzes – sonst sind abschnittsgenaue Filterung und Kurskontext-Sperren nicht umsetzbar. Index-Neubau als unterbrechungsfreier Parallelprozess (Update-Gate, 5.5.3). Fachvokabular-Verwaltung pro Mandant für die ASR-Korrektur.
6.3 Context & Role Manager (Identität, Berechtigungen, Aktionen)
Zweck: Identifikation des Nutzers, Verifikation von Rolle und Berechtigungen in Echtzeit, Anwendung als zwingende Filterkriterien auf alle Abfragen; ab Stufe 4 Auslösen autorisierter Aktionen im LMS (z. B. Einschreibung in generierte Lernpfade). Stufen: 1 (lesender Berechtigungsfilter), 3 (Zugriff auf explizite Lernereignisse aus dem LMS), 4 (Aktionen). Änderungen: Telemetrie-Umfang drastisch reduziert (P3): nur explizite Lernereignisse, keine Verhaltensdaten. Spezifikationshinweise: Anbindung an mastersolution ONE (Moodle) klären – hängt an der offenen Moodle-Integrationsfrage (O1). Statusabfrage "Kurs bestanden" für die Modus-Policy (5.2) gehört hierher. Rollenmodell muss die Autoren-Rolle (Workbench, Policies) und die Fachexperten-Rolle (Graph-Review) umfassen, nicht nur Lernende und Vorgesetzte.
6.4 Sovereign Reasoning Core (Sprachmodell)
Zweck: Lokal oder in isolierter, zertifizierter Umgebung gehostetes LLM; synthetisiert Antworten streng auf Basis bereitgestellter Fakten (Grounded Generation); ab Stufe 3 zusätzlich Extraktionsaufgaben (Graph-Kandidaten mit Belegpflicht), ab Stufe 4 didaktisch instruierte Generierung (sokratische Prompts, Fragengenerierung). Stufen: 2 (Q&A), 3 (Extraktion), 4 (Didaktik). Änderungen: Explizite Festlegung: kein Training/Feintuning auf Mandantendaten (5.5.1). Abstinenz-Verhalten ("keine Antwort im Material") ist Pflichtverhalten und wird getestet (5.6). Spezifikationshinweise: Modellauswahl und Quantisierungsstrategie in Stufe-2-Erprobung; Ergebnis sind die Sizing-Profile (O2). Prompt-Templates versionieren – sie sind Verhaltensbestandteil und gehören unter das Update-Gate wie Modellgewichte. Trennung interaktiver Inferenz von Batch-Extraktion (5.5.4).
6.5 Cognitive Learner Engine (Lernstandsmodell)
Zweck: Führt den Kompetenzstand pro Nutzer auf Basis expliziter Lernereignisse; wertet Regeln aus, die Empfehlungen begründen. Stufen: 3 (regelbasiert), 4 (optional BKT). Änderungen: Grundlegende Neuausrichtung gegenüber dem Ursprungsentwurf: regelbasiert statt DKT (P2, K4); Eingangsdaten minimiert (P3); jede Empfehlung speichert Regel und Datengrundlage (Begründungskonzept). Spezifikationshinweise: Regelwerk als konfigurierbare Vorlagen ausliefern (Betreibermodell: Regelvorlagen sind produktseitig, Parametrisierung mandantenspezifisch). Validitätsmessung (Vorhersage vs. Prüfungsergebnis, aggregiert) von Beginn an einbauen. BKT-Erweiterung so vorsehen, dass sie dieselbe Begründungsschnittstelle bedient ("Mastery-Wahrscheinlichkeit 0,4, weil …") – sonst bricht die Nachvollziehbarkeit beim Ausbau.
6.6 Pedagogical Orchestrator (didaktische Steuerung)
Zweck: Entscheidet auf Basis von Lernstand, Graph und Policy, wie das System reagiert: direkte Antwort, Backlink, Feedforward, sokratische Gegenfrage, Lernpfad-Vorschlag. Stufen: 3 (Regeln für Backlinks/Feedforwards), 4 (Lernpfadgenerierung, Sokratik, Modus-Policies). Änderungen: Kein Reinforcement Learning (K1, P2); regelbasierte Entscheidungslogik. Die Modus-Policy-Hierarchie (5.2) liegt hier. Sokratik ist auf den Coaching-Modus beschränkt statt systemweit erzwungen (K3). Spezifikationshinweise: Gap-Analyse (nötige Voraussetzungen laut Graph vs. Lernermodell) als eigenständiger, testbarer Baustein. Lernpfadgenerierung muss Berechtigungen filternd berücksichtigen und darf Freigabeprozesse nur anstoßen, nie selbst entscheiden (P1). Formulierungs-Templates für Backlinks/Feedforwards mit dem Kunden abstimmen – Tonalität ist Produktentscheidung.
6.7 Adaptive Interface (Nutzerschnittstelle)
Zweck: Sucheingabe und -ergebnisse, Chat mit Quellen und Video-Timestamps, Modus-Anzeige und -Schalter, Fortschritts- und Begründungsanzeige, eingebettete Quiz-Snippets. Stufen: 1 (Suche), 2 (Chat), 3 (Fortschritt, Begründungen), 4 (Coaching-Dialog, Modus-Schalter). Änderungen: Modus-Transparenz als Pflichtmerkmal (5.2); Antwortformat ab Stufe 2 vorbereitet für zweiten Antwortstil. Spezifikationshinweise: Absprung in Materialien (Dokumentabschnitt, Video-Timestamp) ist Kernfunktion, kein Nice-to-have – sie trägt die Nachvollziehbarkeit. Begründungsanzeige für Empfehlungen ("weil …") gehört in die Standardansicht, nicht in ein Detail-Popup. Barrierefreiheit früh einplanen (Kundenprodukt didab zeigt die Relevanz der Zielgruppe im Portfolio).
6.8 Curation & Review Workbench (neu: Redaktionswerkzeug)
Zweck: Arbeitsumgebung für Fachexperten des Endkunden: Prüfung der Graph-Vorschläge (annehmen/bearbeiten/ablehnen mit Beleganzeige), Priorisierung nach Konfidenz und Wirkung, Strukturprüfungs-Hinweise, Differenzvorschläge bei Materialänderungen, Versionierung und Freigabe; in Stufe 4 zusätzlich Review generierter Prüfungsfragen. Stufen: 2 (Pilot), 3 (produktiv), 4 (Fragen-Review). Begründung als eigene Komponente: Ergebnis von L1. Die Workbench ist Produktbestandteil mit Benutzbarkeitsanspruch für Nicht-Techniker – kein internes Hilfsskript. Sie ist der Ort, an dem die menschliche Aufsicht (P1, 5.3.3) konkret stattfindet, und erzeugt nebenbei die Governance-Protokolle. Spezifikationshinweise: Die Prüfeffizienz entscheidet über die Akzeptanz des gesamten Graph-Ansatzes; UX-Aufwand hier nicht unterschätzen. Batch-Aktionen (mehrere Vorschläge eines Clusters gemeinsam behandeln) von Beginn an. Vier-Augen-Freigabe als konfigurierbare Option für regulierte Endkunden.
6.9 Evaluation & Telemetry Framework (neu: Qualitätssicherung)
Zweck: Goldstandard-Verwaltung je Mandant, Metrik-Berechnung (5.6), Update-Gate-Ausführung (5.5.3), Abstinenz- und Groundedness-Testsets, aggregierte Wirkungsmetriken ohne Personenbezug, Opt-in-Exportpakete. Stufen: 1 (Retrieval-Metriken, Gate), 2 (Groundedness, Abstinenz), 3 (Tracking-Validität), 4 (Wirkungsmetriken gegen Baseline). Begründung als eigene Komponente: Ergebnis von L3 und tragende Säule des Betreibermodells – ohne dieses Framework gibt es weder das Vertrauensziel noch sichere Updates noch den Nutzennachweis. Es querschneidet alle anderen Komponenten und verdient deshalb ein eigenes Pflichtenheft. Spezifikationshinweise: Muss offline lauffähig sein (Offline-Update-Pakete). Die Aggregations-Leitplanke technisch erzwingen: Auswertungsschicht ohne Personenbezüge für Wirkungsmetriken. Baseline-Erhebung als geführter Einführungsprozess, nicht als Freitext-Fragebogen.
7. Roadmap und nächste Schritte
7.1 Stufenfolge und vorgezogene Arbeitspakete
Die vier Stufen (5.1) werden sequenziell beauftragt und abgenommen; innerhalb der Stufen gelten folgende Verzahnungen:
In Stufe 1 läuft die Video-Ingestion-Pipeline als paralleler Strang zur Kernsuche; die Suche geht mit Textmaterial produktiv, Videos folgen inkrementell. Die Inhaltsklassifikation und das Evaluationsframework sind Bestandteil der Stufe, nicht Zusatz.
Gegen Ende von Stufe 2 starten zwei vorgezogene Pakete: der Graph-Pilot mit einem Referenzkurs (Erkenntnisse zu Granularität, Prüfaufwand und Workbench-Bedarf fließen in die Stufe-3-Planung) und die juristische Begleitung (Konformitätsbewertung, Betriebsvereinbarungs-Vorlage – fertig, bevor Stufe 3 live geht).
Stufe 3 liefert Graph, Workbench, Tracking und das Regulatorik-Paket als Einheit. Stufe 4 folgt intern der Reihenfolge Fragengenerierung → Lernpfade → Coaching.
Mandanten-Einführung (ab erstem Endkunden): Baseline-Erhebung, Aufbau des Goldstandard-Testsets, Fachvokabular für ASR, Rollenmodell-Abbildung. Diese vier Schritte sind Standardprozess, keine Projektindividualität.
7.2 Qualitative Aufwandseinordnung
Die Quantifizierung der Aufwände (Personentage, Kalenderdauern, Preise) erfolgt bewusst erst mit dem Projektplan (O7/O8). Dieses Konzept liefert die qualitative Vorstufe: eine relative Einordnung der Stufen zueinander mit den jeweils dominanten Aufwandstreibern und den bekannten Unsicherheiten. Sie verankert intern wie beim Kunden realistische Erwartungen, ohne kommerzielle Zusagen vorwegzunehmen.
Stufe 1 ist der kompakteste Block. Sie profitiert direkt vom vorhandenen PoC (hybrides Retrieval); die wesentlichen Neuaufwände sind Produktionsreife (Berechtigungsfilterung auf Index-Einheit-Ebene, Evaluationsframework, Betriebsfähigkeit) und die Video-Pipeline als paralleler Strang. Unsicherheit: Die Moodle-Integrationsentscheidung (O1) beeinflusst den Integrationsaufwand spürbar in beide Richtungen.
Stufe 2 liegt über Stufe 1. Dominante Treiber sind nicht die Q&A-Funktionalität selbst, sondern die Modellerprobung (Auswahl, Quantisierung, Latenzverhalten) und die daraus abzuleitenden Sizing-Profile (O2) sowie der Aufbau der Groundedness- und Abstinenz-Testsets. Die Erprobung ist inhärent iterativ und damit schwerer planbar als klassische Entwicklung.
Stufe 3 ist der gewichtigste Block des Vorhabens. Hier fallen vier substanzielle Pakete zusammen: die Graph-Schicht des Vault, die Curation & Review Workbench (UX-Anspruch für Nicht-Techniker, entscheidet über die Akzeptanz des Graph-Ansatzes), das regelbasierte Tracking mit Begründungskonzept und das Regulatorik-Paket (Dokumentation, Vorlagen, juristische Begleitung). Der Graph-Pilot am Ende von Stufe 2 reduziert die Unsicherheit dieser Stufe erheblich – seine Erkenntnisse zu Granularität und Prüfaufwand fließen direkt in die Planung.
Stufe 4 ist in Summe mit Stufe 3 vergleichbar, verteilt sich aber auf drei getrennt lieferbare Pakete (Fragengenerierung → Lernpfade → Coaching), die einzeln beauftragt und abgenommen werden können. Das didaktische Prompt-Engineering des Coaching-Modus ist der am schwersten schätzbare Einzelposten des Gesamtvorhabens.
Eignung für Vertragsmodelle (interne Einschätzung, nicht für das Kundendokument): Stufe 1 eignet sich nach der O1-Entscheidung für eine Festpreisnähe; Stufe 2 sollte wegen des Erprobungscharakters aufwandsbasiert oder mit Erprobungsbudget strukturiert werden; für Stufe 3 ist ein Festpreis erst nach dem Graph-Piloten seriös; Stufe 4 lässt sich paketweise bepreisen. Die Verteilung der Aufwände zwischen d-opt und mastersolution hängt an der Leistungsabgrenzung (O8).
Für das Kundendokument wird dieser Abschnitt auf die relative Einordnung und die Aufwandstreiber reduziert; Vertragsmodell-Einschätzungen und Unsicherheitsdetails bleiben intern.
7.3 Unmittelbar nächste Schritte
Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel zu Kapiteln 2, 3, 5, 7; Umformulierung und Filterung gemäß Kapitel 1). Zweitens: Entscheidungsvorlage zur Moodle-Integrationsfrage (O1) erarbeiten – sie ist vor Implementierungsbeginn von Stufe 1 zu treffen, weil sie Deployment und Update-Weg der gesamten Produktlinie prägt. Drittens: Grobplanung Stufe 1 (Aufwände, Team, Meilensteine) auf Basis der Komponentensicht 6.2, 6.3, 6.7, 6.9.
8. Offene Punkte und Entscheidungsregister
8.1 Offene Punkte
| Nr. | Punkt | Klärungsweg | Zeitpunkt |
|---|---|---|---|
| O1 | Moodle-Integration: Plugin im AI-Subsystem (Moodle 4.5) vs. eigenständiger Dienst | Technische Entscheidungsvorlage; Kriterien: Release-Kopplung, Update-Weg, Mandantenfähigkeit, Aufwand | vor Implementierungsstart Stufe 1 |
| O2 | Sizing-Zahlen der Profile (Modellgröße, GPU, Nutzerzahlen, Latenzkorridore) | Erprobung in Stufe 2 | Ende Stufe 2 |
| O3 | Juristische Prüfung (AI-Act-Einstufung, BetrVG, Art. 22 DSGVO) | Externe Begleitung | Beginn Ende Stufe 2, Abschluss vor Stufe-3-Livegang |
| O4 | Keyframe-Analyse für rein visuelle Videoinhalte | Bedarfsprüfung nach Stufe-2-Erfahrung | Stufe 2+ |
| O5 | Status-Rückfall bei wiederkehrenden Pflichtschulungen | Autoreneinstellung spezifizieren | Stufe-4-Spezifikation |
| O6 | Rollenabhängige Modus-Policies als Option | Nur auf Kundenwunsch; Mitbestimmungsprüfung vorgeschaltet | bei Bedarf |
| O7 | Preis- und Lizenzstruktur | Geschäftsentscheidung mastersolution; folgt dem Betreibermodell | parallel zu Stufe 1–2 |
| O8 | Leistungsabgrenzung zwischen uns und mastersolution: Wer führt welche Aufgaben aus 5.5 während Entwicklung und Betrieb aus (Unterauftrag, Betriebsunterstützung, Übergabezeitpunkte je Stufe)? | Kommerzielle Verhandlung auf Basis der Verantwortungsmatrix | vor Beauftragung Stufe 1 |
8.2 Entscheidungsregister
| Nr. | Entscheidung | Begründung (Kurzform) | Abschnitt |
|---|---|---|---|
| E1 | Vier Ausbaustufen statt Gesamtausbau | Pragmatismus-Anforderung; Risiko monoton steigend; jede Stufe verkaufbar | 5.1 |
| E2 | Suche (Anwendungsfall 1) als Stufe 1 des Tutors, nicht separates Projekt | Nutzt vorhandene Kompetenz; ist der Knowledge Vault ohne Graph | 4.2/5.1 |
| E3 | Kein LLM in Stufe 1 | Halluzinations- und GPU-Freiheit; Fundstellen statt Synthese | 5.1 |
| E4 | Video-Pipeline in Stufe 1 als paralleler Strang; Timestamps schon in der Suche | Hoher Video-Bestand beim Kunden; Mehrwert ohne LLM; entkoppelt vom Suchbetrieb | 5.1 |
| E5 | Keyframe-Analyse nur als optionale Erweiterung ab Stufe 2 | Schweres Geschütz; Kern bleibt schlank | 5.1 |
| E6 | Fragengenerierung in Stufe 4 (nicht 3), dort als erstes | Stufe 3 bereits voll (Graph+Redaktion+Tracking+Regulatorik); Review-gesichert am wenigsten riskant | 5.1 |
| E7 | Zwei Modi (Nachschlagen/Coaching) mit dreistufiger Policy-Hierarchie; keine automatische Kontexterkennung | Löst K3; Nachvollziehbarkeit; Motivation von außen nicht erkennbar | 5.2 |
| E8 | Statusabhängige Standard-Policy (erstmalig Coaching, nach Bestehen Fragemodus) | LMS-Datum vorhanden; trivial nachvollziehbar; kein Ungleichbehandlungsproblem | 5.2 |
| E9 | Inhaltsklassifikation "nur im Kurskontext" ab Stufe 1 im Datenmodell | Schließt Leakage-Pfad; nachträgliche Umklassifikation teuer | 5.2 |
| E10 | Wissensgraph mit genau drei Kantentypen | Pragmatismus; trägt alle Brainstorming-Szenarien | 5.3 |
| E11 | Teilautomatisierter Redaktionsworkflow mit Belegpflicht und menschlicher Freigabe | Vollmanuell unwirtschaftlich; vollautomatisch fachlich und regulatorisch unhaltbar | 5.3 |
| E12 | Regelbasiertes Tracking (später optional BKT); DKT verworfen | Nachvollziehbarkeit (K4); Cold-Start; AI-Act-Transparenz | 5.4 P2 |
| E13 | Nur explizite Lernereignisse als Tracking-Eingang; keine Verhaltenstelemetrie im Standard | Datenminimierung; Mitbestimmungsaufwand; für Regeln unnötig | 5.4 P3 |
| E14 | Kein Training/Feintuning auf Mandantendaten | Souveränität; Mandantentrennung; zentrale Modellpflege | 5.5.1 |
| E15 | Englische Komponentennamen beibehalten | Konsistenz mit Projektname, Recherche-Dokument und späterem Code; Glossar gleicht aus | 6 |
| E16 | Evaluationsframework als Update-Gate je Mandant; versionierte Releases mit Rollback | Modellwechsel ändern Verhalten; mandantenspezifische Regression möglich | 5.5.3 |
| E17 | Empfehlung statt Entscheidung als Auslieferungszustand; Automatik nur als Kundenkonfiguration | Art. 22 DSGVO; menschliche Aufsicht AI Act | 5.4 P1 |
| E18 | Wirkungsmetriken nur aggregiert; technisch erzwungen | Trennung Produktqualität/Leistungskontrolle; Mitbestimmung | 5.6 |
| E19 | Zwei neue Komponenten: Curation & Review Workbench, Evaluation & Telemetry Framework | Ergebnis der Lücken L1/L3; beide pflichtenheft-würdig | 6.8/6.9 |
| E20 | Internes Dokument als führendes Dokument; Kundendokument als abgeleitete Teilmenge | Drift-Vermeidung; Spezifikationsbasis braucht volle Tiefe | 1 |
| E21 | Qualitative Aufwandseinordnung im Konzept; Quantifizierung erst mit Projektplan | Erwartungsverankerung ohne kommerzielle Vorwegnahme; Kundenfassung ohne Vertragsmodell-Einschätzung | 7.2 |
9. Glossar
Abstinenz-Verhalten: Fähigkeit des Systems, bei fehlender Materialdeckung explizit keine Antwort zu geben statt zu spekulieren.
ASR (Automatic Speech Recognition): Automatische Spracherkennung; hier lokale Transkription von Videoinhalten (Whisper-Klasse).
Backlink / Feedforward: Empfehlung zurück auf ein Grundlagenmodul bei erkannter Lücke / Hinweis auf ein logisch nächstes, noch nicht belegtes Modul.
BKT (Bayesian Knowledge Tracing): Interpretierbares probabilistisches Verfahren zur Schätzung der Beherrschenswahrscheinlichkeit einer Kompetenz aus der Antworthistorie.
BM25: Etabliertes lexikalisches Ranking-Verfahren der Volltextsuche; stark bei exakter Fachterminologie.
Cross-Encoder-Reranking: Zweite Retrieval-Stufe, die Query und Kandidat gemeinsam bewertet; deutlich präziser als reine Vektorähnlichkeit, daher nur auf wenige Kandidaten angewandt.
DKT (Deep Knowledge Tracing): Neuronale Variante des Knowledge Tracing; leistungsfähig, aber Blackbox und datenhungrig – hier verworfen (E12).
Embedding: Vektorrepräsentation von Text (oder anderen Medien) in einem semantischen Raum; Grundlage der Ähnlichkeitssuche.
Goldstandard-Testset: Kuratierte Menge aus Suchanfragen mit erwarteten relevanten Treffern; Messgrundlage für Retrieval-Qualität und Update-Gate.
Grounded Generation / Groundedness: Antwortgenerierung strikt auf Basis bereitgestellter Quellen / Grad, zu dem Aussagen einer Antwort durch die zitierten Quellen gedeckt sind.
Knowledge Tracing: Kontinuierliche Schätzung, ob ein Lernender eine Kompetenz beherrscht, auf Basis seiner Interaktionshistorie.
Mandanten-Einführung: Die Einführung des Produkts bei einem Endkunden (Baseline-Erhebung, Goldstandard-Aufbau, Fachvokabular, Rollenmodell). Bewusst abgegrenzt vom Begriff "Onboarding", der in diesem Dokument ausschließlich die Einarbeitung neuer Mitarbeitender beim Endkunden bezeichnet – also den Lernprozess, dessen Verkürzung das System nachweisen soll.
MRR (Mean Reciprocal Rank): Retrieval-Metrik; misst, wie weit oben der erste relevante Treffer steht.
nDCG (normalized Discounted Cumulative Gain): Retrieval-Metrik; bewertet die Qualität der gesamten Trefferreihenfolge.
RAG (Retrieval-Augmented Generation): Architekturmuster: Ein Sprachmodell beantwortet Fragen auf Basis zuvor abgerufener Dokumente statt aus dem Modellwissen.
Reciprocal Rank Fusion (RRF): Einfaches, robustes Verfahren zur Verschmelzung mehrerer Ranglisten (hier: BM25 und Vektorsuche).
Scaffolding / Fading: Didaktisches Prinzip abgestufter Hilfestellung, die mit wachsender Kompetenz schrittweise zurückgenommen wird.
Sokratischer Dialog: Gesprächsführung, die statt Lösungen gezielte Fragen einsetzt (Eliciting → Probing/Guiding → Reconciling); hier auf den Coaching-Modus beschränkt.
Time-to-Competency: Zeitspanne vom Kursstart bis zur bestandenen Kompetenzprüfung; zentrale Wirkungsmetrik der Stufe 4.
Wissensgraph: Strukturiertes Modell aus Kompetenzknoten und typisierten Kanten (setzt-voraus, wird-vermittelt-durch, wird-geprüft-durch); Grundlage von Tracking, Backlinks und Lernpfaden.