KI-Validierung: Datenherkunft und Modellbezug dokumentieren

Einordnung und Geltungsbereich

Der Beitrag beschreibt eine methodische Datenübersicht. Die konkreten Anforderungen des Annex-22-Konsultationsentwurfs 2025 sind als Entwurf einzuordnen. Er behandelt unter anderem Testdatenauswahl und Unabhängigkeit; nicht jede hier vorgeschlagene Tabellenzeile ist eine wörtliche Normvorgabe.

Quellen: [1] [2]

Eine Datenliste braucht Beziehungen zum Modell und zum Einsatz

Beschreiben Sie Transformationen und Labels. Ein Bild kann beschnitten, eine Messreihe normalisiert oder ein Ergebnis manuell klassifiziert worden sein. Diese Schritte beeinflussen die spätere Prüfaussage. Unklare oder systematisch fehlerhafte Kennzeichnungen lassen sich nicht durch ein gutes Gesamtergebnis wegdiskutieren.

Verknüpfen Sie Datenstände mit den jeweiligen Modell- und Testständen. Werden Daten nachträglich bereinigt oder für eine weitere Trainingsrunde verwendet, ändert sich die Aussage ihrer bisherigen Rolle. Eine Übersicht sollte solche Übergänge sichtbar machen und eine unbemerkte Nutzung von Testinformationen für die Entwicklung verhindern.

Quellen: [1] [2] [3]

Datenherkunft mit Modellzweck und Prüfaussage verbinden

Ein Datenbestand kann groß sein und dennoch den vorgesehenen Einsatz unzureichend repräsentieren. Erfassen Sie deshalb Herkunft, Entstehungsbedingungen, Auswahl und fachliche Bedeutung. Bei Bilddaten können Standort, Gerät, Beleuchtung und Defektart relevant sein. Bei Prozessdaten können Zeitpunkt, Einheit und Betriebszustand entscheidend sein. Die Auswahl richtet sich nach der tatsächlichen Aufgabe.

Der hier betrachtete Annex-22-Konsultationsentwurf 2025 ist als Entwurf einzuordnen. Er behandelt unter anderem repräsentative Testdaten, überprüfte Labels, begründete Vorverarbeitung und Unabhängigkeit der Testdaten. Die folgenden Inventarfelder sind eigene methodische Konkretisierungen. Nicht jede Tabellenzeile ist eine wörtliche Entwurfsvorgabe.

Trennen Sie Daten für Entwicklung, Training und abschließende Prüfung nachvollziehbar. Auch Daten, die indirekt zur Auswahl eines Modells oder seiner Parameter verwendet wurden, können die Unabhängigkeit der späteren Prüfaussage beeinflussen. Eine umbenannte Kopie bleibt derselbe inhaltliche Bezug. Die technische Dateitrennung allein beantwortet diese Frage nicht.

Quellen: [1] [2] [3]

Eine Datenherkunftsakte mit überprüfbaren Feldern erstellen

Verknüpfen Sie Datenpaket, Quelle, Zeitraum und verantwortliche Stelle. Ergänzen Sie Transformationen und Labels. Bei manueller Kennzeichnung sollte verständlich sein, nach welcher fachlichen Regel sie erfolgte und wie ihre Richtigkeit geprüft wurde. Ein Label ist nicht automatisch wahr, nur weil es bereits im Quellsystem stand.

Dokumentieren Sie bekannte Grenzen. Wenn ein Standort oder eine seltene Defektart fehlt, ist dies eine Information für die Einsatzgrenze. Ein guter Gesamtwert darf diese Lücke nicht verdecken. Die Entscheidung kann zusätzliche Daten, eine begrenzte Nutzung oder eine andere Prüfmethode erfordern.

Quellen: [1] [2] [3]

Beispiel: Bilder desselben Objekts landen in Training und Test

Das Szenario ist konstruiert. Ein Team teilt Bilddateien zufällig in Training und Test. Mehrere Aufnahmen desselben physischen Objekts landen in beiden Gruppen. Der Test kann dadurch leichter ausfallen, als es bei wirklich neuen Objekten der Fall wäre. Die genaue Wirkung hängt vom Modell und den Bildern ab; der Fall zeigt eine mögliche Abhängigkeitsquelle.

Erfassen Sie deshalb die Herkunft auf einer passenden Gruppierungsebene. Das kann physisches Objekt, Charge, Sitzung oder eine andere fachlich relevante Einheit sein. Prüfen Sie, ob verwandte Daten die unabhängige Bewertung beeinflussen. Der Entwurf behandelt ausdrücklich auch physische Objekte im Zusammenhang mit Testdatenunabhängigkeit.

Die eigene Kontrolle kann bekannte Gruppenreferenzen und eine geprüfte Splitregel verwenden. Dokumentieren Sie, welche Personen Zugriff auf Testdaten hatten und ob diese Informationen später in Entwicklung oder Auswahl eingeflossen sind. Ein hoher Testwert bleibt nur im Rahmen dieser bekannten Bedingungen interpretierbar.

Quellen: [1] [2] [3]

Untergruppen und seltene Fälle gesondert betrachten

Ein Gesamtkennwert kann eine schwache Untergruppe verdecken. Beschreiben Sie relevante Gruppen anhand des vorgesehenen Einsatzes, etwa Standort, Gerät, Material oder Fehlerart. Prüfen Sie, ob Datenmenge und Verteilung eine passende Aussage erlauben. Der Entwurf fordert eine angemessene statistische Grundlage; dieser Artikel nennt dafür keine universelle Mindestzahl.

Seltene kritische Fälle können gezielte zusätzliche Daten oder Prüfungen benötigen. Eine rein häufigkeitsproportionale Auswahl würde sie möglicherweise kaum enthalten. Die Auswahl muss fachliche Folgen berücksichtigen. Künstlich erzeugte Daten dürfen nicht unkritisch als gleichwertiger Ersatz realer Bedingungen behandelt werden; ihre Eignung und Grenzen benötigen eine Begründung.

Berichten Sie Ergebnisse je relevanter Gruppe, soweit dies für die Aussage erforderlich ist. Eine starke Gesamtgenauigkeit ist kein ausreichender Beleg, wenn gerade eine kritische Klasse häufig übersehen wird. Akzeptanzkriterien sollten vor der abschließenden Prüfung festgelegt sein und den vorgesehenen Einsatz abbilden.

Quellen: [1] [2] [3]

Änderungen an Daten und Labels kontrollieren

Eine nachträgliche Bereinigung verändert den Datenstand und möglicherweise die Prüfaussage. Dokumentieren Sie Grund, Umfang und Wirkung. Ein falsch gelabelter Fall kann korrigiert werden; die Korrektur sollte jedoch nicht bloß dazu dienen, ein schlechtes Modellergebnis passend zu machen. Fachliche Referenz und Modellleistung sind auseinanderzuhalten.

Versionieren Sie relevante Pakete und Vorverarbeitung. Ein identischer Dateiname beweist keinen identischen Inhalt. Die konkrete technische Methode kann unterschiedlich sein; entscheidend ist der nachvollziehbare Bezug zwischen Datenstand, Modellstand und Testbericht. Erhalten Sie auch dokumentierte Ausschlüsse und ihre Gründe.

Wenn Testinformationen für eine weitere Entwicklungsrunde verwendet werden, muss ihre Rolle erneut bewertet werden. Der frühere Test ist dann nicht ohne Weiteres eine unabhängige Bestätigung des angepassten Modells. Beschreiben Sie einen geeigneten neuen Prüfweg statt die gleiche Kennzahl unbegrenzt weiterzuverwenden.

Quellen: [1] [2] [3]

Datenherkunft an den Betrieb übergeben

Der Betrieb benötigt die bekannte Einsatzgrenze. Neue Geräte, andere Beleuchtung oder geänderte Materialien können Eingaben außerhalb des bisherigen Datenraums erzeugen. Die Herkunftsakte hilft, solche Unterschiede zu erkennen. Sie ist nicht nur eine Entwicklungsunterlage, sondern Grundlage für spätere Änderungsbewertung.

Benennen Sie Verantwortliche für Datenqualität, fachliche Labels und technische Verarbeitung. Eine einzige Person muss nicht alle Rollen übernehmen. Die Zusammenarbeit sollte sicherstellen, dass Modellkennzahlen und fachliche Bedeutung verbunden bleiben. Offene Grenzen werden in der Nutzungsentscheidung sichtbar behandelt.

Quellen: [1] [2] [3]

Arbeitsvorlage: Datenpaket, Modellstand und unabhängigen Test verbinden

Wählen Sie ein Datenpaket und dokumentieren Sie seine tatsächliche Rolle. Im Beispiel stammen Bilder aus mehreren Standorten und von bekannten physischen Objekten. Die Aufteilung muss diese Herkunft berücksichtigen. Eine zufällige Dateiaufteilung kann verwandte Daten in verschiedene Gruppen bringen und die Prüfaussage beeinflussen.

Erhalten Sie die Verbindung zwischen Aufbereitung, Label und Modelltest. Ein später korrigierter Datenbestand ist ein neuer Stand. Prüfen Sie, ob dadurch Ergebnisse oder Unabhängigkeit anders zu bewerten sind. Die Dokumentation soll reale Nutzung zeigen, nicht nur im Nachhinein saubere Ordnernamen vergeben.

Berichten Sie bekannte Lücken und Untergruppen. Ein hoher Gesamtwert kann eine schwache kritische Klasse verdecken. Die Entscheidung sollte die tatsächliche Datenabdeckung berücksichtigen und bei Bedarf Nutzung begrenzen oder zusätzliche Evidenz verlangen. Eine universelle ausreichende Datenmenge wird hier nicht festgelegt.

Quellen: [1] [2] [3]

Die nächsten Schritte

• Einsatzbereich und relevante Datenvariationen beschreiben.
• Herkunft, Auswahl und Aufbereitung nachvollziehbar erfassen.
• Datenrollen und Versionsbezüge kontrollieren.
• Lücken und Änderungen vor einer erweiterten Nutzung bewerten.