Wofür würdest du in einer Machine-Learning-Pipeline tatsächlich Tests schreiben?

Test die deterministischen Teile richtig und die stochastischen verhaltensbasiert. Unit-Test die Feature-Transformationen gegen Fixtures, erzwing Schema- und Wertebereichs-Verträge auf den Inputs, halt einen Golden-Row-Test, der die serialisierte Pipeline lädt und prüft, dass bekannte Inputs bekannte Scores ergeben, und schreib verhaltensbasierte Tests auf die Modell-Outputs (Invarianz, gerichtete Erwartungen) statt eine exakte Accuracy-Zahl zu behaupten.

Der Großteil einer Pipeline ist ganz normaler Code und testet sich genau wie ganz normaler Code. Feature-Transformationen bekommen Unit-Tests gegen kleine Fixtures, inklusive der hässlichen Fälle: Nulls, eine im Training nie gesehene Kategorie, ein negativer Wert dort, wo nur positive erwartet wurden. Input-Daten bekommen Vertragsprüfungen, also Schema, Typen, Wertebereiche und erwartete Null-Raten, ausgeführt als Gate vor dem Training statt hinterher als seltsames Modell entdeckt. Dann ein Golden-Row-Test, bei dem ich eine serialisierte Pipeline und eine Handvoll fixer Inputs mit ihren erwarteten Scores aufhebe, und CI schlägt fehl, wenn ein Refactoring sie verändert. Das hat mir mehr als einmal stille Preprocessing-Änderungen gefangen. Beim Modell selbst behaupte ich keine Accuracy über einem Wert, weil das flaky und ein schlechtes Gate ist. Ich schreibe stattdessen verhaltensbasierte Tests: Invarianz, also dass das Ändern eines irrelevanten Felds den Score kaum bewegt, und gerichtete Erwartungen, also dass das Erhöhen eines Features mit bekanntem monotonem Zusammenhang die Vorhersage in die richtige Richtung schiebt. Volle Trainingsläufe sind für jeden Commit zu langsam, die laufen also nächtlich, mit einem schnellen Smoke-Training auf einer winzigen Stichprobe in CI, um zu beweisen, dass die Pipeline end to end noch läuft.