FactSet verkürzt Training und Bereitstellung von Modellen mit Databricks von Tagen auf Stunden
FactSet hat nach eigenen Angaben die Zeit für Einrichtung, Training und Bereitstellung eines individuellen Text-to-Formula-Modells mit Databricks AI Runtime von Tagen auf Stunden reduziert. Das Finanzdatenunternehmen trainiert seine Modelle alle zwei bis drei Wochen neu, daher wirkt sich die Geschwindigkeit der Infrastruktur laut Databricks direkt auf den Entwicklungszyklus aus.
- FactSet zufolge hat Databricks AI Runtime die Zeit für Einrichtung, Training und Bereitstellung eines individuellen Text-to-Formula-Modells von Tagen auf Stunden verkürzt.
- TTF wandelt Anfragen in natürlicher Sprache in Formeln der FactSet Query Language (FQL) um.
- Ein anfänglicher RAG-Ansatz stieß bei komplexen Formeln an eine Qualitätsgrenze, weshalb FactSet feinabgestimmte offene Modelle ergänzte.
- Frühere Arbeiten ergaben, dass feinabgestimmte Modelle die End-to-End-Latenz um rund 60 % senkten.
- FactSet führt etwa alle zwei bis drei Wochen ein Fine-Tuning durch und nutzt dafür serverlose GPU-Rechenleistung, MLflow und seine Lakehouse-Umgebung.
Von RAG zu feinabgestimmten offenen Modellen
Das Text-to-Formula-System (TTF) von FactSet nimmt eine Anfrage in natürlicher Sprache von einem Investmentprofi entgegen und wandelt sie in eine Formel in der FactSet Query Language (FQL) um. Zunächst baute das Unternehmen TTF auf Retrieval-Augmented Generation (RAG) auf, bei der für jede Anfrage passende Beispiele und Informationen abgerufen werden.
Mit wachsender Nutzung wurden die Abfragen spezialisierter und die Formeln komplexer. Laut Databricks stieß der RAG-Ansatz damit an eine Qualitätsgrenze. FactSet reagierte darauf, indem es seiner Compound-AI-Architektur feinabgestimmte offene Modelle hinzufügte. Die Modelle lernen so die Struktur und die Muster von FQL, statt sich bei der Inferenz hauptsächlich auf den Abruf von Informationen zu stützen.
In früheren Arbeiten an TTF stellte FactSet fest, dass der Einsatz feinabgestimmter Modelle die End-to-End-Latenz um rund 60 % senkte, heißt es in dem Beitrag.
Warum Training im Wochentakt die Anforderungen an die Infrastruktur verändert
Mit zunehmenden Trainingsdaten wurde das Fine-Tuning bei FactSet von einem experimentellen Workflow zu einem wiederkehrenden Teil der Entwicklung. Das Team führt inzwischen etwa alle zwei bis drei Wochen ein Fine-Tuning durch. Eine Umgebung vorzubereiten und GPU-Rechenleistung zu konfigurieren, lasse sich bei einem gelegentlichen Experiment noch bewältigen, erläutert der Beitrag. Wiederhole man diese Arbeit für jeden neuen Datensatz oder jedes neue Modell, entstehe jedoch in jedem Zyklus zusätzlicher Aufwand.
Auch die Anforderungen ändern sich von Experiment zu Experiment. FactSet hat mit Modellen auf Llama-Basis gearbeitet und evaluiert weiterhin neuere offene Modelle. Unterschiedliche Modelle, Promptlängen und Ausgabecharakteristika können verschiedene Compute-Konfigurationen erfordern, sodass ein festes GPU-Setup das Experimentieren erschweren würde.
FactSet nutzt Databricks AI Runtime, um diese Jobs auf einer serverlosen GPU-Infrastruktur auszuführen. Ingenieure können die Rechenressourcen für einen bestimmten Trainingslauf auswählen, ohne zuvor die GPU-Umgebung bereitstellen und konfigurieren zu müssen.
Training im bestehenden Databricks-Workflow
Der TTF-Workflow läuft bereits auf Databricks, und zwar für Daten, Experimente, Modellverwaltung und Governance. FactSet verwendet MLflow, um die Modellentwicklung und die Experimente nachzuverfolgen, und die zugrunde liegenden Daten bleiben in der bestehenden Lakehouse-Umgebung unter Governance. Wird das Fine-Tuning mit AI Runtime ausgeführt, bleibt das GPU-Training in diesem Ablauf. Ingenieure können so mit governten Daten arbeiten, ein Modell trainieren, die Artefakte nachverfolgen und in Richtung Deployment gehen, ohne einen separaten GPU-Stack zu benötigen.
Nikhil Sunderraj, Principal Machine Learning Engineer bei FactSet Research Systems, Inc., sagte, AI Runtime habe den Prozess des Trainings eines individuellen Text-To-Formula-Modells (TTF) "erheblich vereinfacht". Es habe dem Team ermöglicht, "schnell voranzukommen, unsere Lakehouse-Workflows beizubehalten und ein hochwertiges Modell mit vollständiger Governance zu liefern".
Die Fine-Tuning-Pipeline basiert auf Databricks Lakeflow Jobs and Pipelines und ist als wiederverwendbares Framework angelegt. Laut dem Beitrag soll sie sich mit minimalem Einrichtungsaufwand für verschiedene TTF-Aufgaben und von anderen Teams einsetzen lassen.
Was das für die Modellwahl bedeutet
FactSet prüft weitere feinabgestimmte Modelle für Aufgaben wie die Zerlegung von Abfragen, die Extraktion von Komponenten und die Identifikation von Bibliotheken. Je spezialisierter die Modelle werden, desto wichtiger werde schnelles, wiederholbares Training, heißt es in dem Beitrag.
Databricks argumentiert, dass es für eine offene Modellwahl mehr braucht als den Download neuer Gewichte, denn auch der Trainings- und Deployment-Workflow müsse Schritt halten. Bei einem System, das alle paar Wochen neu trainiert wird, summiere sich die gesparte Zeit: Neue Daten könnten schneller in ein neues Modell einfließen, und die Ingenieure könnten in jeder Iteration mehr Zeit auf die Verbesserung von TTF statt auf die Vorbereitung der Infrastruktur verwenden. Die genannten Zahlen und Vorteile stammen aus der eigenen Darstellung von Databricks zu den Erfahrungen von FactSet.
