What are the best platforms for testing and improving LLMs for specific tasks?

Summary

• A good testing platform scores outputs against criteria you define for your task, on test cases you curate. On Databricks, MLflow evaluation datasets hold inputs and optional expectations, and scorers (built-in LLM judges, custom judges and code-based checks) grade each run.
• The same scorers can run before and after release. mlflow.genai.evaluate() compares app versions on a dataset, and production monitoring (Beta) applies scorers to a configurable sample of live traces.
• Failures become test cases. MLflow Tracing records each step of a run, and a trace with a ground-truth expectation can be added to an evaluation dataset.
• Improvement has more than one lever. Prompts can be versioned and optimized (both Beta), Model Serving can split traffic between models for A/B testing, and Databricks recommends AI Runtime (Public Preview) for fine-tuning now that Foundation Model Fine-tuning has reached end of life.

What are the best platforms for testing and improving LLMs for specific tasks?

The best platform covers the whole improvement loop: trace real behavior, turn failures into test cases, score each change against task-specific criteria, release carefully and keep monitoring. On Databricks that loop runs in MLflow, the same open source MLflow managed by Databricks, with traces, evaluations and prompts stored in Unity Catalog alongside your data. The rest of this page lists what to look for and how each piece works.

Key capabilities to evaluate

Capability	Why it matters
Task-specific scoring	Your task has its own definition of correct, so you need custom judges and code checks as well as built-in ones.
Test cases from real usage	Failing production interactions are representative examples to test against.
Version comparison	Prompt, model and agent changes should be scored on the same cases to catch regressions.
Human review	Domain experts define what a good answer looks like and correct the judges.
Production monitoring	The scoring you trust in development should keep running on live traffic.
Controlled rollout	A challenger should see a share of traffic before it replaces the current version.
Governed storage	Traces, datasets and prompts need access control and an audit trail.

How does Databricks approach testing and improving LLMs?

Trace first. MLflow Tracing records the inputs, outputs, latency, token usage and cost of every intermediate step, and you can store traces as Unity Catalog Delta tables.
Build test cases. An evaluation dataset has required inputs and optional expectations, with reserved keys such as guidelines, expected_facts and expected_response. Experts can record a ground-truth expectation on a trace and add that trace to a dataset, and the Review App lets them label traces. For new human-review workflows, Databricks recommends review queues (Beta).
Score. Scorers come in four approaches: built-in judges such as Correctness and RetrievalGroundedness (including Guidelines judges that pass or fail natural-language rules), custom LLM judges, code-based scorers for exact matching or format validation, and third-party scorers for specialized metrics from open source frameworks. mlflow.genai.evaluate() runs your app over a dataset with the scorers you choose. Each judge uses a Databricks-hosted LLM by default, and you can change the judge model. Databricks says judge outputs should not be used to train, improve or fine-tune an LLM.
Improve. MLflow Prompt Registry (Beta) versions prompts and uses aliases such as "production" and "staging" for A/B tests and gradual rollouts. mlflow.genai.optimize_prompts() (Beta, MLflow 3.5.0 or later) improves prompts from evaluation metrics and training data using the GEPA algorithm. Foundation Model Fine-tuning has reached end of life, and Databricks recommends AI Runtime (Public Preview), a serverless GPU environment, for training and fine-tuning models. You can then serve the trained model with Model Serving.
Release and monitor. A Model Serving endpoint can serve several models and split traffic between them to compare performance and run A/B tests. Production monitoring (Beta) schedules your scorers against an experiment and evaluates a configurable sample of incoming traces.

What does this look like for specific tasks?

A support assistant might use a Guidelines judge for policy and tone and a Correctness judge with expected facts for resolutions. A document-extraction agent might use a code-based scorer for exact matches on extracted fields. A retrieval-based assistant can add the RetrievalGroundedness judge, which asks whether the response is grounded in the context it was given.

FAQs

What's the difference between evaluation and monitoring?

Evaluation runs your app against a dataset, for example nightly or before a release. Production monitoring runs the same scorers on a sample of live traces so regressions show up after release.

How do I know a change didn't cause a regression?

Run mlflow.genai.evaluate() on the same dataset for each version and compare the results. The Databricks tutorial follows this pattern: create a dataset, evaluate, interpret results, improve, then compare versions.

What if my judge disagrees with my experts?

Use judge alignment, which trains custom LLM judges to match human evaluation standards through feedback. You can also write a code-based scorer when a rule is deterministic.

Can I use my own model as the judge?

Yes. Change the judge's model argument, using the format <provider>:/<model-name>. The default is a Databricks-hosted LLM.