mastersolution/rag-tutor-documentation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

internes Konzept - Ergänzung qualitative Aufwandseinordnung

Browse Source
This commit is contained in:
Florian Förster
2026-07-17 12:27:42 +02:00
parent d025296810
commit 437f078d08
1 changed files with 41 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md
+41 -24
View File
@@ -1,6 +1,6 @@
# Sovereign RAG Tutor – Internes Konzeptdokument
**Status:** Entwurf v0.3 · **Stand:** Juli 2026 · **Vertraulichkeit:** intern **Führendes Dokument** – das Kundendokument wird als gefilterte Teilmenge hieraus abgeleitet.
**Status:** Entwurf v0.4 · **Stand:** Juli 2026 · **Vertraulichkeit:** intern **Führendes Dokument** – das Kundendokument wird als gefilterte Teilmenge hieraus abgeleitet.
---
@@ -438,7 +438,23 @@ Die vier Stufen (5.1) werden sequenziell beauftragt und abgenommen; innerhalb de
**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 Unmittelbar nächste Schritte
### 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.
@@ -461,28 +477,29 @@ Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel
### 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|
| 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 |
---