Machine learning

Building models where one is needed and, more often, productionising the one you already have.

Feature engineering registered in the Feature Store, MLflow for experiments and the registry, a Model Serving endpoint with its own service principal, an evaluation gate that has to pass before a new version is promoted, drift monitoring on the inference table, and the retraining job on a Lakeflow schedule.

Eighty of our engineers are Databricks-certified, and the pipelines underneath are at /services/data-engineering.

Less than teams expect on the serving itself and more than they expect on everything around it. The endpoint is straightforward.

Reproducing the training set, moving feature computation somewhere that runs without one person's laptop, and deciding what happens when the model degrades are where the work actually is. That's usually two to six weeks depending on how the features were built.

On a schedule to begin with, because it's honest and it's cheap, then on a drift signal once there's enough production history to know what normal looks like. Retraining on drift before you can characterise drift produces a model that chases noise. Lakehouse Monitoring's inference profile gives the inputs and predictions a baseline to be measured against, window by window.

Both, and the second is more common. Most teams we meet have a data scientist who has already found something that works and no path from there to an endpoint anyone will depend on.

Where a model does need building, our engineers work alongside your data scientists rather than replacing them, because the domain knowledge that makes a feature useful is already in your building.

When a rule does the job. A threshold somebody can explain beats a model nobody can, if the threshold catches the cases that matter. We've replaced planned models with three lines of SQL more than once, and the client kept the budget.

A model earns its place when the pattern is real, the data to learn it exists, and the cost of being wrong is one you can measure.

MLOps is the discipline of shipping and running models the way software is shipped and run. Versioned features, tracked experiments, a registry that says which model is live, a gate before promotion, monitoring after it, and a rollback.

You need it the moment a model's output feeds a decision somebody is accountable for. Before that, a notebook is fine, and we'll say so.

Yes, and the first question is whether the data has to move. Lakehouse Federation reads Snowflake, SQL Server, Synapse and others in place, which is enough for a first model.

If the model goes to production, the features usually want to live on Delta next to the serving endpoint, and that's the point at which the migration conversation at /services/databricks starts.

This page is models that predict, score or classify, and reach an endpoint. Agents and applications built on language models, with retrieval, tools and a governance boundary, are at /services/ai-systems. The two share the platform, MLflow and AI Gateway among them, and often share an engagement, but the failure modes are different and so is the evaluation.

Yes, that's the forward-deployed model at /services/forward-deployed. A working team with a lead who owns the outcome, in your workspace and your repository, rather than individual contractors you manage. Ask for the certification count of any partner you talk to, because it's checkable and a tier isn't.

With one model, end to end, because a proof of concept that never serves a request teaches nobody anything. We pick it with you, take it from wherever it is to a monitored endpoint, and write down what was decided and why. If the estate itself is the question, the two-week Databricks Health Check at /databricks/health-check comes first.