157 lines
14 KiB
Markdown
157 lines
14 KiB
Markdown
# Sovereign RAG Tutor – Integrationsarchitektur gegenüber mastersolution ONE
|
||
|
||
**Entscheidungsvorlage**
|
||
|
||
**Bezug:** Konzeptdokument Sovereign RAG Tutor, Abschnitt 6.4, Punkt 1
|
||
|
||
| | |
|
||
| ----------------- | --------------------------------------------------------------- |
|
||
| erstellt durch: | d-opt GmbH<br>Oberneumarker Str. 59 <br>08496 Neumark (Sachsen) |
|
||
| erstellt von: | Florian Förster |
|
||
| Erstellungsdatum: | 05.08.2026 |
|
||
| geändert von: | Florian Förster |
|
||
| Änderungsdatum: | 05.08.2026 |
|
||
| Dokumentversion: | V0.1 |
|
||
|
||
---
|
||
|
||
## 1. Die Entscheidung auf einen Blick
|
||
|
||
### Worum es geht
|
||
|
||
Der Sovereign RAG Tutor muss mit mastersolution ONE zusammenarbeiten. Moodle bringt seit Version 4.5 ein eigenes KI-Subsystem mit. Zu entscheiden ist, ob der Tutor als Bestandteil dieses Subsystems gebaut wird oder als eigenständiges System, das an mastersolution ONE angebunden wird.
|
||
|
||
### Empfehlung von d-opt
|
||
|
||
**Der Tutor wird als eigenständiges, mandantenfähiges System gebaut und über etablierte Standardverfahren an mastersolution ONE angebunden.** Die Anbindung nutzt Mechanismen, die in Moodle seit Jahren stabil verfügbar sind und über alle bei Endkunden anzutreffenden Versionsstände hinweg gleich funktionieren.
|
||
|
||
### Die drei tragenden Gründe
|
||
|
||
**1. Betreibbarkeit über die reale Kundenlandschaft.** Die Endkunden von mastersolution betreiben unterschiedliche Moodle-Versionen und unterschiedlich stark angepasste Installationen. Das KI-Subsystem hat sich seit seiner Einführung in jeder Moodle-Version verändert – im Halbjahrestakt. Ein Produkt, das darauf aufsetzt, müsste dauerhaft in mehreren Ausprägungen gleichzeitig gepflegt und getestet werden. Der empfohlene Weg entkoppelt die Produktentwicklung vom Moodle-Releasezyklus: Der Tutor wird einmal weiterentwickelt und funktioniert über die gesamte erwartbare Versionsspanne der Endkunden hinweg, weitgehend unabhängig von deren Upgrade-Tempo. Das ist der Unterschied zwischen einer einmaligen Entwicklungsleistung und einer dauerhaften Wartungslast, die über die gesamte Produktlebensdauer mitläuft.
|
||
|
||
**2. Die Kernfunktion lässt sich im Subsystem nicht abbilden.** Das Moodle-Subsystem kennt einen festen Satz von KI-Funktionen: Text erzeugen, Bild erzeugen, zusammenfassen, erklären. Die zentrale Leistung des Tutors – eine Antwort mit Quellenbeleg, Verweis auf den Dokumentabschnitt oder Video-Zeitpunkt und Angabe des Betriebsmodus – ist keine davon. Sie müsste in ein Format gepresst werden, das dafür nicht vorgesehen ist. Damit ginge genau das Merkmal verloren, das mastersolution in den gemeinsamen Gesprächen als erste Anforderung formuliert hat: dass jede Aussage und jede Empfehlung des Systems begründbar ist.
|
||
|
||
**3. Schutz des finanzierten Produktkerns.** Moodle-Erweiterungen unterliegen nach verbreiteter Lesart der GPLv3: Wer Kernlogik in ein Moodle-Plugin legt, muss diese bei Auslieferung offenlegen. Da mastersolution die Entwicklung maßgeblich finanziert, entstünde so die Situation, dass ein wesentlicher Teil des Investments öffentlich verfügbar wäre – einschließlich für die Wettbewerber im Moodle-Ökosystem, die im Konzept als Marktdruck beschrieben sind. Der empfohlene Weg hält den Produktkern proprietär; ein etwaiges moodleseitiges Verbindungsstück enthält keine Kernlogik und ist damit unkritisch. Die lizenzrechtliche Einordnung im Detail wird im Rahmen der ohnehin vorgesehenen juristischen Begleitung bestätigt; die empfohlene Architektur ist so gewählt, dass sie unter jeder Auslegung Bestand hat.
|
||
|
||
### Was diese Entscheidung _nicht_ festlegt
|
||
|
||
Wie tief der Tutor später in die Moodle-Oberfläche eingebettet wird – als eigene Ansicht, als Kursbaustein oder tiefer –, bleibt **offen**. Der empfohlene Weg wird bewusst so gebaut, dass eine engere Einbettung später nachgerüstet werden kann, ohne die Architektur zu verändern. Diese Frage lässt sich nach den Erfahrungen aus den Stufen 1 und 2 beantworten, wenn echte Nutzungsdaten vorliegen – und sie ist eine Produktentscheidung von mastersolution, keine technische Vorfestlegung.
|
||
|
||
Entschieden wird heute also das Fundament, nicht das Erscheinungsbild.
|
||
|
||
### Was mastersolution beiträgt
|
||
|
||
Die moodleseitigen Bestandteile der Anbindung – Registrierung der Schnittstelle, Konfiguration der Zugriffsrechte, Abbildung des Rollenmodells – liegen bei mastersolution. Dort ist die Moodle-Kompetenz vorhanden, dort ist die Kenntnis der kundenspezifischen Anpassungen, und dort ist die GPL-Frage unproblematisch, weil es sich um Konfiguration und schmale Verbindungsstücke handelt. d-opt liefert den souveränen Dienst.
|
||
|
||
### Zeitpunkt
|
||
|
||
Die Entscheidung ist Voraussetzung für die Grobplanung von Stufe 1 – sie bestimmt Auslieferungsform und Aufwandsstruktur. Solange sie offen ist, lässt sich die Planung nur unter Vorbehalt erstellen.
|
||
|
||
---
|
||
|
||
## 2. Das KI-Subsystem von Moodle
|
||
|
||
Seit Moodle 4.5 (Oktober 2024) enthält Moodle einen eigenen Rahmen für KI-Funktionen. Er besteht aus drei Arten von Bausteinen: **Anbieter** (die Anbindung an ein Sprachmodell, im Standard OpenAI, Azure, seit Version 5.2 auch Google Gemini und Amazon Bedrock), **Einsatzorte** (die Stellen in der Oberfläche, an denen Nutzer KI verwenden – Texteditor und Kurs-Assistent) sowie einen **Vermittler**, der beides verbindet und jede Nutzung protokolliert.
|
||
|
||
Der Rahmen ist durchdacht gestaltet und bringt Eigenschaften mit, die für ein regelkonformes KI-Angebot wichtig sind: eine Zustimmungspflicht zur KI-Nutzung am Ort der Nutzung, Steuerung über das Moodle-Rollenmodell, seit Version 5.1 zusätzlich Schalter auf Kurs- und Aktivitätsebene, und eine zentrale Protokollierung. Diese Ausstattung ist der stärkste Grund, eine Integration überhaupt zu erwägen – und sie ist in der Bewertung entsprechend berücksichtigt worden.
|
||
|
||
Drei Eigenschaften stehen dem Vorhaben jedoch entgegen:
|
||
|
||
- Der Katalog der KI-Funktionen ist fest im Moodle-Kern verankert. Eine neue Funktionsart hinzuzufügen bedeutet praktisch, einen Beitrag zum Moodle-Kern zu leisten – mit dem Zeitplan und den Prioritäten von Moodle HQ.
|
||
- Der Rahmen ist auf einzelne, kurze Aktionen ausgelegt. Die Erschließung von Videobeständen und der Aufbau des Wissensgraphen sind Stapelverarbeitungen mit völlig anderem Laufzeitprofil.
|
||
- Der Rahmen wird je Moodle-Installation konfiguriert. Ein Betreibermodell mit mehreren getrennten Mandanten ist darin nicht vorgesehen. Dass diese Lücke real ist, zeigt der Markt: Mehrere verbreitete KI-Plugins setzen auf ein zusätzliches Fremdplugin auf, das genau diese Mandantenverwaltung nachrüstet.
|
||
|
||
---
|
||
|
||
## 3. Die geprüften Wege
|
||
|
||
| |Weg|Bewertung|
|
||
|---|---|---|
|
||
|**A**|Tutor vollständig als Moodle-Erweiterung im KI-Subsystem|Ausgeschlossen. Kernfunktion nicht abbildbar; Produktkern offenlegungspflichtig; die ab Stufe 2 nötige Rechenkomponente für das Sprachmodell lässt sich nicht in einer Moodle-Installation betreiben.|
|
||
|**B**|Eigenständiger Dienst, Bedienoberfläche als Moodle-Erweiterung im KI-Subsystem|Nicht empfohlen. Das Antwortformat wäre durch den festen Moodle-Funktionskatalog vorgegeben; Belege und Video-Zeitpunkte ließen sich nicht sauber darstellen. Zudem dauerhafte Pflege über alle Kundenversionsstände und angepassten Oberflächen hinweg.|
|
||
|**C**|Eigenständiger Dienst mit standardbasierter Anbindung|**Empfohlen.** Entkoppelt vom Moodle-Releasezyklus; volle Kontrolle über Antwortformat und Oberfläche; Produktkern geschützt; mandantenfähig.|
|
||
|**D**|Weg C, ausgelegt für spätere engere Einbettung|**Empfohlene Ausprägung.** Kein nennenswerter Mehraufwand, hält die Gestaltungsfreiheit offen.|
|
||
|
||
**Faire Einordnung zu Weg B:** Bei einer einheitlichen, durchgängig aktuellen Moodle-Landschaft wäre dieser Weg ernsthaft erwägenswert – vor allem wegen der in Kapitel 2 beschriebenen Governance-Ausstattung. Der Ausschluss folgt aus der konkreten Kundenlandschaft von mastersolution, nicht aus einer generellen Schwäche des Moodle-Subsystems.
|
||
|
||
---
|
||
|
||
## 4. Zielarchitektur
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph MS["mastersolution ONE (Moodle)"]
|
||
KURS[Kurse, Materialien, Videos]
|
||
ROLLEN[Rollen und Berechtigungen]
|
||
UI[Aufruf aus dem Kurs]
|
||
end
|
||
|
||
subgraph TUTOR["Sovereign RAG Tutor (eigenständiger Dienst)"]
|
||
VAULT[Knowledge Vault]
|
||
LLM[Souveränes Sprachmodell]
|
||
GOV[Mandanten- und Governance-Schicht]
|
||
end
|
||
|
||
KURS -->|Materialübernahme| VAULT
|
||
ROLLEN -->|Identität und Berechtigungen| TUTOR
|
||
UI -->|Aufruf per Standardschnittstelle| TUTOR
|
||
TUTOR -.->|Antwort mit Beleg und Rücksprung ins Material| MS
|
||
```
|
||
|
||
Der Tutor läuft On-Premise beim Endkunden oder in einem deutschen Rechenzentrum – die Souveränitätszusage bleibt in beiden Betriebsformen unverändert. Die Anbindung erfolgt über LTI (ein seit Jahren etablierter Standard für die Anbindung externer Lernwerkzeuge an Lernplattformen, in Moodle seit Version 3.8 verfügbar) sowie über die regulären Moodle-Schnittstellen für Inhalte und Lernereignisse.
|
||
|
||
---
|
||
|
||
## 5. Was der empfohlene Weg zusätzlich verlangt
|
||
|
||
Zwei Punkte sollen offen benannt werden, weil sie in die Planung gehören:
|
||
|
||
**Die Governance-Ausstattung entsteht als Bestandteil des Tutors.** Zustimmungspflicht, Protokollierung und Rechtefeinsteuerung kommen bei diesem Weg nicht aus dem Moodle-Kern, sondern werden im Tutor selbst umgesetzt. Der Aufwand ist real. Er relativiert sich aus zwei Gründen: Erstens fällt er ohnehin an, weil das Betreibermodell mit getrennten Mandanten und das Regulatorik-Paket der Stufe 3 Anforderungen stellen, die der Moodle-Kern nicht erfüllt. Zweitens gilt eine eigene Lösung einheitlich über alle Endkunden hinweg statt in mehreren Ausprägungen je Moodle-Version – und sie wird Teil der mitgelieferten Compliance-Ausstattung, die im Konzept als Verkaufsargument gegenüber den Endkunden vorgesehen ist.
|
||
|
||
**Die Oberflächen-Einbettung ist zunächst weniger nahtlos.** Der Rücksprung aus einer Antwort in das Kursmaterial oder zum Video-Zeitpunkt ist Kernfunktion und wird umgesetzt; er läuft aber über Verweise statt über eine native Moodle-Komponente. Wie weit die Einbettung später gehen soll, ist genau der in Abschnitt 1 beschriebene offene Freiheitsgrad.
|
||
|
||
---
|
||
|
||
## 6. Auswirkung auf die Ausbaustufen
|
||
|
||
**Stufe 1 (Souveräne Suche)** berührt das KI-Subsystem gar nicht – es kommt kein Sprachmodell zum Einsatz. Zu klären sind hier die Materialübernahme und die Übergabe von Identität und Berechtigungen. Diese Stufe eignet sich zugleich als Erprobung des Anbindungsverfahrens.
|
||
|
||
**Stufe 2 (Nachschlage-Assistent)** bringt die Rechenkomponente für das Sprachmodell mit eigenem Betriebsprofil – ein weiterer Grund für die Trennung. Mit dem ersten Kontakt der Nutzer zum Sprachmodell wird die Basis-Governance fällig: Zustimmung und Protokollierung. Sie fügt sich zeitlich in die ohnehin gegen Ende dieser Stufe beginnende juristische Begleitung.
|
||
|
||
**Stufe 3 (Kompetenzmodell und Tracking)** benötigt Zugriff auf die Lernereignisse aus dem LMS und baut die Governance zur vollen Regulatorik-Ausstattung aus.
|
||
|
||
**Stufe 4 (Adaptive Didaktik)** bringt erstmals schreibende Vorgänge im LMS mit sich, etwa die Einschreibung in generierte Lernpfade. Es bleibt bei der im Konzept festgelegten Logik: Das System stößt an, entscheidet aber nicht.
|
||
|
||
---
|
||
|
||
## 7. Offene Fragen an mastersolution
|
||
|
||
Vier Punkte werden für die verbindliche Planung benötigt:
|
||
|
||
1. **Rolle der nativen Moodle-App.** Wird sie bei den Endkunden relevant genutzt? Die Antwort beeinflusst die Gestaltung der Nutzerschnittstelle.
|
||
2. **Mandantenzuschnitt.** Entspricht ein Endkunde jeweils einer eigenen Moodle-Installation, oder gibt es Installationen mit mehreren Mandanten? Das beeinflusst die Berechtigungsarchitektur.
|
||
3. **Zugriff auf die Systeme.** Zusage, dass der Tutor über die regulären Moodle-Schnittstellen auf Materialien, Rollen und Lernereignisse zugreifen kann.
|
||
4. **Übernahme der moodleseitigen Bestandteile** der Anbindung durch mastersolution.
|
||
|
||
---
|
||
|
||
## 8. Wann die Entscheidung zu überprüfen ist
|
||
|
||
Die Empfehlung ist auf Dauer angelegt, aber nicht auf Ewigkeit. Drei Entwicklungen würden eine erneute Prüfung auslösen:
|
||
|
||
- **Moodle erweitert sein KI-Subsystem substanziell** – etwa um dialogfähige, quellenbasierte Funktionsarten _und_ eine Mandantenverwaltung. Dann würde eine engere Einbettung attraktiv. Die empfohlene Architektur bliebe gültig, weil der Kern eigenständig bleibt; zu prüfen wäre dann der Ausbaupfad, nicht die Grundsatzentscheidung. Genau dafür ist Weg D ausgelegt.
|
||
- **Die Versionslandschaft der Endkunden vereinheitlicht sich** auf einen aktuellen Stand. Der Wartungsvorteil würde kleiner; die Empfehlung bliebe wegen der Funktionsdeckung und der Lizenzfrage bestehen.
|
||
- **Die Antworten auf die Fragen 1 und 2 aus Kapitel 7** weichen von den derzeitigen Annahmen ab. Betroffen wären die Anbindungsdetails, nicht die Grundsatzentscheidung.
|
||
|
||
---
|
||
|
||
## Anhang: Ergänzung zum Glossar
|
||
|
||
**KI-Subsystem (AI Subsystem):** Der seit Moodle 4.5 im Moodle-Kern enthaltene Rahmen für KI-Funktionen, bestehend aus Anbietern, Einsatzorten und einem vermittelnden Kern.
|
||
|
||
**LTI (Learning Tools Interoperability):** Etablierter offener Standard für die Anbindung externer Lernwerkzeuge an Lernplattformen. Er regelt den Aufruf aus dem Kurs heraus, die Anmeldung des Nutzers sowie die Übergabe von Kurs- und Rolleninformationen. In Moodle seit Version 3.8 verfügbar.
|
||
|
||
**GPLv3:** Die Open-Source-Lizenz, unter der Moodle steht. Nach verbreiteter Auslegung erstreckt sie sich auch auf Moodle-Erweiterungen und verpflichtet dann dazu, deren Quellcode bei Weitergabe offenzulegen. Die Einordnung im Einzelfall ist Gegenstand der vorgesehenen juristischen Begleitung.
|
||
|
||
**Mandantenfähigkeit:** Die Eigenschaft eines Systems, mehrere Endkunden mit getrennten Daten, Konfigurationen und Berechtigungen auf einer gemeinsamen Produktbasis zu betreiben.
|