You have created a RAG pipeline or fine-tuned a model on Databricks that produces answers. It can be hard to tell whether those answers are of high quality or merely appear adequate in a demo for stakeholders who anticipate project success.
Databricks LLM evaluation involves scoring the output of a language model or RAG pipeline with Databricks together with MLflow, addressing correctness, relevance, and groundedness. It employs mlflow.evaluate() for both built-in and custom scorers, and it separates retrieval quality from generation quality so that failures can be corrected at their origin. Running evaluations regularly captures drift before customers notice it.
That is the point where evaluation proves its value. Databricks combined with MLflow provides actual tools for scoring an LLM's output: built-in metrics for correctness and groundedness, a framework to create your own scorers, and a tracking server that logs each run so you can pinpoint when quality declined. What it does not supply automatically are the metrics that matter for your use case, the correct way to configure them, or the common pitfalls teams encounter. That is the area we are most frequently asked about at Shipshape Data, since a big portion of our effort involves turning AI prototypes into production-ready solutions for businesses.
This guide describes the metrics, MLflow procedures, and typical mistakes. It targets individuals assessing LLM or RAG systems on Databricks who need more objective proof than simply noting that "it read fine when I tried it".
The scope of evaluation on Databricks
Evaluation involves several layers instead of a single test. Most issues arise when teams implement only one of these layers. You ought to grasp all the available layers before choosing which ones your project needs.
The quality of the output from the model
Start with the text that the model outputs. You need to assess three particular attributes. Correctness indicates if the answer aligns with a known ground truth. Relevance indicates if the answer addresses the specific question posed. Fluency indicates whether the text reads smoothly and does not exhibit the disjointedness that appears when a model goes beyond its context window.
These three are relevant whether you are using a single large language model with a prompt or a five-stage pipeline, and they form the baseline of any rigorous evaluation plan, not the limit. MLflow's mlflow.evaluate() addresses this directly: point it to a dataset of inputs and expected outputs, and its built-in scorers evaluate responses on these dimensions without requiring you to code the scoring logic. If the built-in metrics are unsuitable, you can register your own Python function and it integrates into the same pipeline, without needing separate infrastructure.
Evaluating a RAG pipeline as two separate problems
When employing retrieval-augmented generation, the evaluation process poses two separate questions. First, you need to ascertain whether the system pull back the right chunks of context. Second, you must check whether the model employed that context correctly or produced inaccurate information that seems plausible.
These two questions need different metrics. Mixing them together is the most frequent error we see in RAG evaluation.
A model may generate confident, well-structured replies even when it relies on the wrong source document. Evaluating only the final answer will miss this mistake.
MLflow and Databricks supply distinct metrics for every phase of the workflow. Chunk relevance evaluates whether the documents returned by the retriever are pertinent to the user query. Faithfulness evaluates whether the generated answer derives from the retrieved context rather than being invented. Both metrics should be applied to determine if a problem arises in retrieval or in generation. Doing so lets you target the exact component of the system that is malfunctioning.
How to write your own scoring functions
Certain quality dimensions lack established metrics. When your project needs a domain-specific focus, a defined brand voice, or compliance with internal legal policies, you need to build a custom scorer. MLflow lets you register a regular Python function as a metric. You can execute this function alongside the built-in scorers in the same evaluation workflow. Its outputs will be listed in the same table as metrics such as faithfulness and toxicity.
This part of the platform offers lasting usefulness. You are not confined to a predetermined list of dimensions set by others. By coding a function and using it for each run, you set the criteria for your application. That results in an evaluation framework tailored to your business requirements instead of a generic benchmark meant for another scenario.
Why this matters once the system is live
Putting a model into a production product alters its risk profile. In a notebook you manage the inputs and choose the examples. You only present the successful runs to others.
In production your model meets whatever a real user types at 11pm on a Tuesday, plus every edge case nobody thought to test for, plus data that quietly drifts underneath it over the following six months. Without a formal evaluation process sitting between you and that reality, you have no way of knowing when outputs degrade, when retrieval quietly breaks, or when the model starts producing answers that are wrong with total confidence.
The costs of skipping it
Teams that skip evaluation during development frequently discover errors only after the product is released. Such problems include hallucinated answers, retrieval chains delivering stale information, and replies that stray from the intended topic. These issues go beyond ordinary technical bugs. They erode user trust in a way that is hard to recover. When an AI assistant gives a confident but wrong answer, users tend to double-check all subsequent outputs. That attitude removes the main advantage of using the tool.
Correcting a quality issue after launch costs more than detecting it during development. The expenses involve engineering effort, support tickets, and the challenge of rebuilding user trust. Evaluation shifts these costs to an earlier phase when fixing a bug remains cheap.
Reasons to perform multiple evaluation passes
You must evaluate the system thoroughly before you launch it. However, that first evaluation alone is insufficient.
The model's behaviour varies when the retrieved data changes, when users pose unforeseen questions, and when the vendor modifies the base model without your consent. Evaluation ought to be incorporated into your MLflow workflow so that it executes on a schedule or during deployment events. This lets you detect a regression in the same week it appears, instead of waiting for a customer to report it.
Viewing evaluation as a pre-launch task will cause you to overlook the slow degradation that many production AI systems experience. Adding continuous evaluation from the start delivers continuous quality feedback across the system's lifecycle, instead of a single assessment at launch.
Metrics you should employ
Numerous teams devote weeks to selecting appropriate metrics. Databricks LLM evaluation provides numerous scoring dimensions, yet executing all metrics for each job is slow and inefficient. Select metrics that align with your particular use case. Additional metrics can be added as the system evolves and you pinpoint specific failure points.
Retrieval and generation, scored apart
In constructing a RAG application, make faithfulness and answer relevance your main generation metrics. Faithfulness assesses whether the response relies wholly on the retrieved context. The metric penalises the model when it adds information absent from the source material. Answer relevance gauges how effectively the response answers the user's specific query. It highlights cases where an answer is factually correct yet fails to address the actual question.
In the retrieval process, chunk relevance and context precision show whether the retriever operates correctly. Chunk relevance assesses each retrieved document against the query individually. Context precision quantifies the share of retrieved information that is useful, as opposed to filler that fills the context window without adding value.
Merging these two data sets lets you identify whether a failure happened during retrieval or during generation. This data indicates to engineers which component of the system needs their focus.
Toxicity, safety, and your particular metrics
Toxicity scoring and safety classification are mandatory for systems that engage with end users. MLflow provides built-in toxicity metrics that detect harmful, offensive, or off-brand output prior to production release. These metrics automatically evaluate every response in the evaluation set. This offers a systematic standard instead of depending on occasional manual checks.
Establish at least one domain-specific metric early in the process instead of waiting until the system is functional. A financial application must measure numerical accuracy. A legal application should measure citation correctness by confirming that cited cases or clauses exist and back the model's claims. These particular metrics reveal failures that generic benchmarks overlook. Encoding these metrics as reusable MLflow scorers guarantees that each model version is evaluated against the same standard, preventing reviewers from depending on inconsistent manual checks.
Setting up evaluation with MLflow in Databricks
mlflow.evaluate() serves as the main tool for structured evaluation in Databricks. You supply a model, a dataset that includes inputs and ground truth, and a list of metrics. The function yields a results object and records all metrics to the MLflow tracking server. Since it operates inside Databricks notebooks or jobs, you can incorporate it into your existing workflow without creating a separate evaluation system.
What the call needs
Begin by defining an evaluation dataset as a pandas DataFrame that contains your input queries, ground truth responses where available, and any retrieved context documents generated by your RAG pipeline. Next, invoke mlflow.evaluate(), directing it to your model-either a logged MLflow model URI or a simple callable Python function-and the scorers you wish to apply. MLflow manages the scoring, aggregation, and logging within the active run without additional intervention.
A typical invocation includes four primary arguments. data refers to the DataFrame that holds your inputs and expected outputs. model can be either a logged MLflow model URI or a Python callable. evaluators ought to be set to "default" in order to activate the built-in LLM scorers. extra_metrics represents a list of custom scoring functions you have built for your particular domain.
Record the evaluation in the same MLflow run as your model artefacts rather than creating a separate run. This approach guarantees that your quality data and model version stay linked. It enables rapid review of results when investigating a deployment rollback, avoiding the need to search through unrelated records.
Reading the results and catching regressions
Once you have evaluated multiple model versions or prompt updates, you can employ the MLflow experiment tracking UI to compare runs side by side. You may plot metrics over time and filter results by score thresholds to pinpoint the run where a quality dimension declined. This turns regression detection into a straightforward process. If faithfulness scores fall between version three and version four, the UI displays the change instantly, preventing later discovery of the issue via support tickets.
For large-scale evaluation, attach your evaluation jobs to Databricks Workflows. Configure them to run on a schedule that matches your deployment frequency. This configuration delivers a continuous quality signal in the background. It guarantees that you need not manually check metrics after an error occurs.
Using an LLM as a judge without fooling yourself
An LLM judge is a distinct model employed to score the outputs of another model. It serves as a useful tool since it can assess tone, reasoning, and policy compliance far faster than a human reviewer. The main risk lies in using an uncalibrated judge. If you rely on scores that have not been verified, you might optimise your system for the judge's particular preferences instead of the needs of your users. These two outcomes may look similar in data reports yet differ in practice.
How to select and constrain the judge model
Only certain models work effectively as judges. You need to choose a model that follows instructions precisely and yields consistent scores across different inputs. You should constrain the model's behaviour by employing a detailed prompt. The prompt must contain a clear rubric, defined score ranges, and examples that illustrate the requirements for each score level.
Using a vague prompt will produce inconsistent scores. Metrics that vary between runs cannot be trusted, rendering the measurement process useless.
Do not allow a model to evaluate its own results. This practice compromises the accuracy of all subsequent metrics.
Do not use the same model to evaluate its own output. If a model scores its own answers, it will favour its own phrasing style. This creates a feedback loop that inflates scores without improving quality. You must also treat the judge prompt as a versioned asset and test it with your production model. A change to the judge prompt will alter evaluation results as significantly as a change to the model itself.
Checking the judge against actual people
Create a small validation set labelled by humans before you use an LLM judge for large-scale tasks. This set should include a representative sample of the inputs you expect to receive. Run the judge on these inputs and calculate how often it agrees with the human labels. If the correlation is high, you can trust the judge for broader use. If the agreement is low, you must improve the rubric instead of adding more data to the existing prompt.
Perform re-validations on a periodic basis. You should not set up the judge once and then ignore it.
A judge model that is tested against a specific set of queries can lose its accuracy as your users or retrieval data change. You will not detect this performance drop unless you actively monitor the system.
Where we see this go wrong in practice
A few patterns turn up often enough on client projects to call out.
Teams often create an evaluation dataset early in development using a few examples written in a single afternoon. They then continue to use this same dataset without updates. After six months, these examples no longer reflect actual user behaviour, and the resulting scores measure a system that is outdated. You should update the dataset regularly as the product evolves. Do not wait for a failure to occur before making these changes.
Another mistake is tracking every available metric simply because the platform provides them. You should instead focus on the two or three metrics that correspond to failure modes you have actually experienced. A dashboard containing fifteen metrics without established thresholds will be ignored within a month. Select fewer metrics and decide what "good enough to ship" means for each one. You must then take action when those numbers change.
Teams often lack a baseline for comparison. They evaluate a new prompt or model version in isolation and receive a faithfulness score, such as 0.82. They cannot determine if this result represents an improvement or a regression because they did not log the score of the previous version. Every evaluation run should be compared directly against the run it replaces. A metric functions as a number rather than a signal if it lacks this context.
A plan you will continue to follow
Databricks LLM evaluation is a continuous process rather than a single task. It occurs during every stage of development, including the initial prototype and long-term production. You should begin by selecting a small set of core metrics that fit your specific use case. Create a ground truth dataset using actual user queries instead of invented examples. Integrate mlflow.evaluate() into your workflow before you deploy the system.
Next, include retrieval metrics in addition to generation metrics. You must validate any LLM judge against human labels to ensure accuracy. Schedule regular evaluation runs so that performance regressions appear on a dashboard rather than through support tickets. These processes do not need to be complex at the start. They must function consistently, and a specific person must be responsible for reviewing the results.
If you would like someone to review your evaluation setup before you base your quarterly roadmap on it, talk to us. We work on these systems frequently and are available to review what you have built.
If you want to use this within your own systems instead of a demo, you can use our AI development services.
Frequently asked questions
What is Databricks?
Databricks is the platform used for the evaluation work in this guide, and it is paired with MLflow to measure the performance of language models and RAG pipelines. It includes a tracking server that records every run, allowing teams to identify when a quality metric decreased instead of depending on a single successful demonstration.
What is Databricks used for?
Databricks runs and evaluates LLM and RAG systems. It logs model versions and runs mlflow.evaluate() using a dataset of inputs and expected outputs. It tracks metrics such as faithfulness and correctness over time. The tool functions within an existing notebook or job workflow, which removes the need for a separate evaluation stack.
What changes when an LLM moves from a Databricks notebook into production?
When you are developing a notebook, you manage the inputs and select the examples you present, which makes the potential risks seem limited. However, once the model is in use, it will respond to any input from a user, including unexpected cases that were not tested and data that changes over time. Without a regular evaluation process, you will not be able to detect when the model's performance declines or its retrieval functions stop working correctly.
Which metrics matter most for evaluating an LLM or RAG pipeline on Databricks?
When building a RAG application, evaluate faithfulness and answer relevance for the generation component first. Next, assess chunk relevance and context precision for the retrieval component. Measuring these two areas separately allows you to determine if errors occur during retrieval or during generation. You should include toxicity and safety checks if the system interacts with end users. You should also implement a domain-specific metric early in the development process instead of adding it later.
How do you use an LLM as a judge without fooling yourself?
Avoid using the same model to evaluate its own responses. Keeping the judging model separate stops a feedback loop that raises scores without enhancing real quality. Add a specific rubric and examples to the judge prompt. Test the prompt on a small set of human-labelled data before applying it to large tasks. Regularly check performance as query types evolve.