Machine-Learning-Entwicklung

Viele Fragen im Unternehmen beantwortet Standardsoftware. Ein eigenes Modell wird interessant, wenn eine Entscheidung von so vielen Einflüssen abhängt, dass sich keine brauchbaren Regeln mehr aufschreiben lassen: Springt dieser Kunde ab? Wie hoch fällt der Schaden aus? Sieht dieser Vorgang nach Betrug aus? Wir entwickeln solche Modelle von der Fragestellung bis zur Anbindung. Prognosen über die Zeit und der laufende Betrieb haben eigene Seiten.

Braucht es überhaupt ein Modell?

Häufig nicht. Sind die Kriterien bekannt und stabil, etwa bei einer Freigabegrenze, ist ein Regelwerk einfacher, billiger und leichter zu prüfen. Geht es um Texte, also Anfragen sortieren oder Angaben aus Schreiben auslesen, reicht meist ein vortrainiertes Sprachmodell ohne eigenes Training. Für Vorhersagen aus Tabellendaten wie Preisen, Risiken oder Ausfällen ist ein Sprachmodell dagegen selten das richtige Werkzeug.

Ein eigenes Modell lohnt sich, wenn drei Dinge zusammenkommen: genug historische Fälle mit bekanntem Ausgang, ein Muster, das für feste Regeln zu komplex ist oder ständig veraltet, und eine Entscheidung, die so oft fällt, dass eine bessere Trefferquote spürbar wird. Das klären wir, bevor die Entwicklung beginnt. Reichen Regeln, sagen wir das.

Erst die Entscheidung, dann die Daten

Am Anfang steht die Frage, welche Entscheidung das Modell verbessern soll. Daraus folgt die Zielgröße und mit ihr die Frage nach den Kosten von Fehlern. Ein übersehener Betrugsfall kostet etwas anderes als ein zu Unrecht geprüfter Vorgang, und davon hängt ab, welche Kennzahl zählt und wie das Modell eingestellt wird. Als Maßstab dient eine einfache Vergleichslösung, etwa eine Regel oder der Durchschnitt der Vergangenheit. Schlägt das Modell sie nicht klar, lohnt der Aufwand nicht.

Den größten Teil der Arbeit nimmt danach die Datenaufbereitung ein. Daten aus mehreren Systemen werden verbunden, fehlende Werte, Dubletten und uneinheitliche Schlüssel behandelt. Beim Feature Engineering entstehen daraus Merkmale wie die Zahl der Bestellungen der letzten 90 Tage oder die Zeit seit dem letzten Kontakt. Ein Merkmal darf nur enthalten, was zum Zeitpunkt der Vorhersage schon bekannt wäre. Bei seltenen Ereignissen wie Betrug oder Ausfällen entscheidet außerdem nicht die Gesamtmenge der Daten, sondern wie viele und wie gute Beispiele des seltenen Falls vorliegen.

Welches Verfahren passt

Für tabellarische Daten, also Aufträge, Kunden, Verträge oder Sensorwerte, sind Baumverfahren wie Gradient Boosting meist der erste Ansatz. In Vergleichsstudien schneiden sie bei mittelgroßen Tabellen häufig besser ab als neuronale Netze, sie sind schnell trainiert und lassen sich gut erklären. Seit Kurzem gibt es auch vortrainierte Modelle für Tabellen. TabPFN wurde 2025 in der Fachzeitschrift Nature für kleine Datensätze vorgestellt. Wir prüfen so ein Modell im Einzelfall gegen Gradient Boosting.

Deep Learning spielt seine Stärken bei Bildern, Audio, langen Texten und sehr großen Datenmengen aus. Empfehlungen entstehen je nach Datenlage aus dem Verhalten ähnlicher Kunden, aus Produkteigenschaften oder aus beidem. Bei der Anomalieerkennung fehlen oft Beispiele für den Fehlerfall. Das Modell lernt dann, was normal ist, und markiert Abweichungen. Sprachaufgaben löst man heute meist mit vortrainierten Modellen. Je nach Aufgabe genügt eine gut formulierte Anweisung, sonst wird mit eigenen Beispielen nachtrainiert, oder Texte werden in Vektoren umgewandelt und mit einem kleinen Modell klassifiziert.

Woran man einem Modell trauen kann

Ein Modell muss an Daten geprüft werden, die es beim Training nie gesehen hat. Bei zeitabhängigen Daten teilen wir nach dem Datum auf, damit es nicht die Zukunft kennt. Besonders tückisch ist Data Leakage: Informationen, die erst nach dem Ereignis vorliegen, rutschen in die Merkmale. Das Modell glänzt im Test und versagt im Einsatz. Zu gute Testergebnisse sind deshalb ein Warnsignal und kein Erfolg.

Erklärbar machen wir Modelle mit Verfahren wie SHAP. Es zeigt, wie stark einzelne Merkmale eine konkrete Vorhersage nach oben oder unten bewegt haben und welche im Ganzen wichtig sind. Das deckt Fehler im Modell auf und macht Ergebnisse für den Fachbereich nachvollziehbar. Es beschreibt Zusammenhänge in den Daten, belegt aber keine Ursachen.

Betrifft die Entscheidung Menschen, etwa bei Bewerbungen, Krediten oder Preisen für Personen, vergleichen wir zusätzlich die Fehlerraten nach Gruppen und suchen in den Merkmalen nach indirekten Verzerrungen. Rein technisch lässt sich Fairness nicht abschließend lösen, denn jemand muss entscheiden, was als gerecht gelten soll. Einige dieser Anwendungen zählen nach dem EU AI Act zur Hochrisiko-KI, für die Pflichten ab Dezember 2027 gelten. Die rechtliche Einordnung gehört zur Rechtsberatung, die technische Seite behandelt der Schwerpunkt EU AI Act.

Vom Notebook ins System

Ein Modell hilft erst, wenn seine Ergebnisse dort ankommen, wo entschieden wird. Läuft es als API, fragt das System für einen einzelnen Fall an und bekommt die Antwort sofort. Das passt zu Empfehlungen im Shop oder zur Prüfung einer Transaktion. Als Batch-Prozess bewertet das Modell in festen Abständen alle Fälle, etwa jede Nacht, und schreibt die Ergebnisse ins Data Warehouse, von wo Berichte, CRM oder Planung darauf zugreifen. Welche Variante passt, hängt davon ab, wie schnell die Antwort gebraucht wird.

Zur Bereitstellung gehören geprüfte Eingaben, eine nachvollziehbare Modellversion und ein Rückfall für den Fall, dass das Modell ausfällt. Ein Modell, das nicht in einen Prozess eingebunden ist, bleibt ein Experiment. Bei der Übergabe erhält das Team Code, trainierte Modelle, Dokumentation, Testfälle und eine Beschreibung der Datenbasis. Wie Modelle dauerhaft betrieben, überwacht und neu trainiert werden, beschreibt der Schwerpunkt MLOps.