Zum Inhalt springen
Search the hub
Aufräumen vor Retrieve oder Train

Aufräumen vor Retrieve oder Train

Betriebsmodell zum Inventarisieren, Scrubben und zweckfreigeben von Corpora vor RAG-Retrieval oder Modelltraining — Müll raus, Vertrag rein.

Category
Data Governance
Reading time
4 min
Published
Tags
data-governance ai-governance training-data rag data-quality stewardship metadata
Download PDF

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:

  1. Inventory — Quellen, Owner, Hygiene-Klasse, Sensitivität; Link Exclusion Register Teil 1;
  2. Scrub — blocked Assets entfernen; Dedup; PII/Secrets maskieren; Noise droppen; Transforms protokollieren;
  3. Purpose approve — getrennte Cards für retrieval und training; Metadata-Vertrag Pflicht; Fitness in Teil 3;
  4. Ingest — nur freigegebene Snapshots; Version pin; Lineage Corpus-ID → Job-ID;
  5. 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.

  1. Corpus-ID, Owner, Steward und Produkt für ein Retrieval-Corpus festlegen.
  2. Exclusion Register importieren und blocked Sources markieren.
  3. Scrub-Schritte fahren und Run-Log mit Counts speichern.
  4. Einen Job so härten, dass er nur die freigegebene Snapshot-ID liest.

Data Junk Before AI

Part 2 of 6

View series

Knowledge check

Tour