Aufräumen vor Retrieve oder Train
Betriebsmodell zum Inventarisieren, Scrubben und zweckfreigeben von Corpora vor RAG-Retrieval oder Modelltraining — Müll raus, Vertrag rein.
Begriffe vor dem Lesen
- Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, verantwortliche Person, Aktualität, Herkunft oder Qualitätsnachweis.
- KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
- Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
- Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
- KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.
Qualität, Quellkorrektur und AI-Nutzung
Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.
Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.
Policy-Bot-Prep ist nicht „SharePoint Policies und HR-Exports in den Vector Store kippen“. Es ist ein kontrollierter Pfad von Inventar zu gescrubtem, zweckfreigegebenem Corpus — sonst wird der Müll aus Teil 1 zu RAG-Kontext.
Nachbarn bleiben für Tiefe führend: Metadaten für AI…, Datenhygiene.
Vorher: Müll-Assets vergiften den AI-Kontext. Weiter: DQ-Gates für AI-Fitness.
Entscheidung
Bevor ein Corpus Retrieval oder Training speist:
- Inventory — Quellen, Owner, Hygiene-Klasse, Sensitivität; Link Exclusion Register Teil 1;
- Scrub — blocked Assets entfernen; Dedup; PII/Secrets maskieren; Noise droppen; Transforms protokollieren;
- Purpose approve — getrennte Cards für
retrievalundtraining; Metadata-Vertrag Pflicht; Fitness in Teil 3; - Ingest — nur freigegebene Snapshots; Version pin; Lineage Corpus-ID → Job-ID;
- Owner für Corpus-Zweck, Steward für Prep Pack, Custodian für Job-Pin. Raw-Shares sind nie Produktionskontext. Zweckwechsel startet Freigabe neu.
Inventory ──► Scrub ──► Purpose Card ──► Snapshot ──► Index / Train-Job
│ │
└── blocked ───┴── zurück zur Hygiene-Disposition
Prep-Workflow
1. Corpus benennen
Owner vergibt Corpus-ID, AI-Produkt (Chat / Agent / Fine-Tune) und Zweck. Steward importiert das Exclusion Register und markiert blocked Sources. Ohne ID ist jeder Share „der Corpus“.
2. Scrubben und loggen
Steward definiert Schritte (PII-Scan, Dedup, Sprache, Toxicity). Custodian schreibt Counts in/out, Hit-Rates und Hashes ins Run-Log. Ein Scrub ohne Log ist eine Behauptung — Evidence zählt, nicht „wir haben einmal Regex laufen lassen“.
3. Zweck getrennt freigeben
Owner stellt getrennte Purpose Cards inkl. Nicht-Ziele aus. Privacy sieht Train-Karten. Dieselbe CSV für Index und Fine-Tune ohne zweite Card ist der Leakage-Keim.
4. Snapshot pinnen
Custodian lässt Jobs nur die freigegebene Snapshot-ID lesen. Steward verlangt das Metadata-Profil vor Ingest — Metadaten für AI…. Live-Crawl unapproved Pfade bleibt verboten.
5. Rebuild auslösen
Owner hängt Source-Retire, PII-Incident und Schema-Bruch an Rebuild oder Chunk-Purge — Löschung die hält. Steward aktualisiert corpus-prep-v1. Stilllegung ohne Rebuild lässt tote Docs im Index.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Corpus-Owner | Steward | corpus-prep-v1 + Exclusion-Link |
| Steward | Custodian | Scrub-Rezept + Run-Log |
| Owner | Privacy | Purpose Cards retrieval vs. training |
| Steward | Fitness-Owner (Teil 3) | Snapshot zur Gate-Prüfung |
| Custodian | Index / Train-Job | freigegebene Snapshot-ID |
Anti-Patterns
- Raw-Partnerfreigaben direkt in den Produktion-Index crawlen
- Dedup und personenbezogene Daten-Scrub auf „später“ schieben
- Dieselbe CSV für Chatbot und Dienstleister-Fine-Tune nutzen
- Metadata-Profil auf Papier, Job zieht den Partnerfreigabe
- Quell-Asset stilllegen, ohne Dokumentbestand-Rebuild
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Corpus-ID, Owner, Steward und Produkt für ein Retrieval-Corpus festlegen.
- Exclusion Register importieren und blocked Sources markieren.
- Scrub-Schritte fahren und Run-Log mit Counts speichern.
- Einen Job so härten, dass er nur die freigegebene Snapshot-ID liest.
Data Junk Before AI
Part 2 of 6
View series