Ramp verkürzte die Bereitstellung von ML-Modellen mit einem YAML-Konfigurationssystem von 4 Monaten auf 5 Minuten

Ramps erstes Kreditrisikomodell benötigte fast vier Monate und mehr als 3.000 Codezeilen, um in die Produktion zu gelangen. Als Finanzdienstleistungsunternehmen musste Ramp außerdem sicherstellen, dass die Ausgaben jedes Modells auf Abruf exakt reproduzierbar sind, was durch maßgeschneiderten, einmaligen Bereitstellungscode schwer zu gewährleisten war. Diskussionen über maschinelles Lernen konzentrieren sich tendenziell auf das Modell selbst, doch die Ingenieurszeit wurde tatsächlich von der „Feature Pipeline“ dominiert – dem Code, der Rohdaten bereinigt, umwandelt und in nutzbare Eingaben überführt –, was das Team auf 99 % der eigentlichen Arbeit schätzte.

Das Engineering-Team von Ramp entwickelte Turbo, ein YAML-basiertes Konfigurationssystem, um dies zu standardisieren. Sie identifizierten die Entitäten, die jeder ML-Workflow gemeinsam hat: eine Feature Pipeline (Rohdaten zu Features) und eine Model Pipeline (Features zu Vorhersagen). Eine Klasse „JobSpec“ liest eine YAML-Datei, materialisiert diese als Pydantic-Objekte und übermittelt sie an eine Compute-Umgebung – einen Train Job, der ein neues Modell anpasst, oder einen Predict Job, der eines aus dem Modellspeicher lädt. Da beide Jobs dasselbe Schema verwenden, kommt die Bereitstellung eines Modells dem Kopieren einer Konfigurationsdatei und dem Bearbeiten einiger Zeilen nahe.

Der Nutzen war unmittelbar: Pipelines, die heute in einer Konfigurationsdatei beschrieben werden, liefern bei erneuter Ausführung in ein oder zwei Jahren dieselben Ergebnisse, solange sich die zugrunde liegenden Daten nicht geändert haben, was die Anforderung der Reproduzierbarkeit direkt erfüllt. Ein migriertes Zeitreihen-Prognosemodell erhielt zudem ohne zusätzlichen Aufwand eine konsistente Feiertagsbehandlung, da jedes mit der Abstraktion erstellte Modell dieselbe Feature-Engineering-Logik erbt, statt sie unabhängig neu zu implementieren.

Jede ML-Pipeline in zwei wiederverwendbare Teile (Features, Modell) verwandeln, die in einer YAML-Datei beschrieben werden

Die Trennung der Feature Pipeline von der Model Pipeline als wiederverwendbare Entitäten bedeutete, dass die 99 % der ML-Arbeit, die nicht aus Modellierung besteht, nur einmal gelöst werden musste.

Ein deklaratives YAML-Schema statt einer Codebibliothek bedeutete, dass Ingenieure ohne ML-Hintergrund Modelle bereitstellen und warten konnten, ohne selbst Pipeline-Code schreiben zu müssen.

Dass Training und Vorhersage ein Schema gemeinsam nutzten, bedeutete, dass ein Entwickler nur einen Satz von Konzepten lernen musste, um beides zu tun, statt separater Tools für jede Phase.

Die Standardisierung des Feature Engineerings (z. B. der Feiertagsbehandlung in Zeitreihenmodellen) behob eine ganze Klasse von Inkonsistenzfehlern auf einmal, statt jedes Modell separat zu patchen.

Wenn dieselbe zweistufige Pipeline-Form in verschiedenen Systemen wiederkehrt, kodiere sie einmal als deklaratives Schema – es verwandelt eine nur Experten vorbehaltene, mehrmonatige Aufgabe in etwas, das jeder Ingenieur ausfüllen kann.

Als Ramp über Turbo schrieb, konnte ein neues Modell in unter 5 Minuten mit durchschnittlich etwa 40 Zeilen YAML bereitgestellt werden, verglichen mit 4 Monaten und über 3.000 Codezeilen zuvor. Fast 20 Modelle waren in Produktion, erstellt von 9 verschiedenen Entwicklern, von denen viele vor Turbo noch nie ein Modell für maschinelles Lernen trainiert oder bereitgestellt hatten.