FactSet cuts model training and deployment from days to hours with Databricks

From RAG to fine-tuned open models

FactSet's Text-to-Formula (TTF) system takes a natural-language request from an investment professional and converts it into a formula in FactSet Query Language (FQL). The company first built TTF around retrieval-augmented generation (RAG), which retrieves relevant examples and information for each request.

As usage grew, queries became more specialized and formulas more complex. According to Databricks, the RAG approach then hit a quality ceiling. FactSet responded by adding fine-tuned open models to its Compound AI architecture, so that models learn the structure and patterns of FQL instead of relying mainly on retrieval at inference time.

In earlier work on TTF, FactSet found that incorporating fine-tuned models reduced end-to-end latency by about 60%, the post says.

Why training every few weeks changes the infrastructure needs

As FactSet gathered more training data, fine-tuning moved from an experimental workflow to a recurring part of development. The team now fine-tunes roughly every two to three weeks. Preparing an environment and configuring GPU compute may be manageable for an occasional experiment, the post explains, but repeating that work for every new dataset or model adds overhead to each cycle.

Requirements also shift between experiments. FactSet has worked with Llama-based models and continues to evaluate newer open models. Different models, prompt lengths and output characteristics can call for different compute configurations, so a fixed GPU setup would make experimentation harder.

FactSet uses Databricks AI Runtime to run these jobs on serverless GPU infrastructure. Engineers can pick compute for a particular training run without first provisioning and configuring the GPU environment.

Training inside the existing Databricks workflow

The TTF workflow already runs on Databricks for data, experimentation, model management and governance. FactSet uses MLflow to track model development and experiments, and its underlying data stays governed in its existing Lakehouse environment. Running fine-tuning with AI Runtime keeps GPU training in that same flow, so engineers can work with governed data, train a model, track the artifacts and move toward deployment without a separate GPU stack.

Nikhil Sunderraj, Principal Machine Learning Engineer at FactSet Research Systems, Inc., said that AI Runtime "greatly streamlined the process of training a custom Text To Formula (TTF) model." He added that it allowed the team to "move quickly, maintain our Lakehouse workflows, and deliver a high-quality model with full governance."

The fine-tuning pipeline is built on Databricks Lakeflow Jobs and Pipelines as a reusable framework. According to the post, it is designed to be adopted across different TTF tasks and by other teams with minimal setup effort.

What it means for model choice

FactSet is exploring additional fine-tuned models for tasks such as query decomposition, component extraction and library identification. More specialized models make fast, repeatable training more important, according to the post.

Databricks argues that keeping model choice open requires more than downloading new weights, because the training and deployment workflow has to keep pace. For a system retrained every few weeks, it says, the time saved compounds: new data can reach a new model sooner, and engineers can spend more of each iteration improving TTF rather than preparing infrastructure. The figures and benefits described come from Databricks' own account of FactSet's experience.