From 437f078d08107839f48cdb21c27ae9463e605604 Mon Sep 17 00:00:00 2001 From: foefl Date: Fri, 17 Jul 2026 12:27:42 +0200 Subject: [PATCH] =?UTF-8?q?internes=20Konzept=20-=20Erg=C3=A4nzung=20quali?= =?UTF-8?q?tative=20Aufwandseinordnung?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ... RAG Tutor – Internes Konzeptdokument.md | 65 ++++++++++++------- 1 file changed, 41 insertions(+), 24 deletions(-) diff --git a/01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md b/01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md index 3a4ca37..66c26b5 100644 --- a/01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md +++ b/01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md @@ -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 | ---