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
+20 -3
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.
@@ -462,7 +478,7 @@ 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 |
@@ -483,6 +499,7 @@ Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel
| 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 |
---