Databricks Generative AI Engineer Associate: MLflow for GenAI Evaluation
GenAI evaluation answers a difficult question: is the application getting better in ways that matter to users? Traditional software tests can verify deterministic rules, but language-model applications also need to measure relevance, correctness, groundedness, safety, completeness, retrieval quality, tool behavior, and sometimes conversational experience. MLflow gives Databricks teams a way to connect those measurements to traces, datasets, scorers, application versions, and human feedback.
The current Generative AI Engineer exam includes evaluation and monitoring as a distinct section and expects engineers to use MLflow scoring and tracing, select monitoring metrics, understand judges that require ground truth, use custom scorers, and incorporate subject-matter-expert feedback. That makes evaluation a core part of Databricks GenAI engineering rather than a final QA task.
Begin with the behavior the application is responsible for
Evaluation criteria should come from the job the application performs. A retrieval assistant may be judged on whether it uses the correct policy and cites relevant evidence. A summarizer may need factual preservation, concise output, and format compliance. A tool-using agent may need to choose the correct action, pass valid parameters, and stop before a high-risk change without approval.
The broader agent evaluation principle applies: generic fluency is not enough. Define failure in business terms, then decide which automated and human measurements can detect it.
Build an evaluation dataset from real tasks
A useful dataset contains representative normal cases, important edge cases, historical failures, and safety or policy scenarios. Some examples may include an expected answer or facts; others may be evaluated against guidelines rather than one exact response. Version the dataset so teams can compare releases against the same evidence.
Production failures are especially valuable. When a user finds a case the application handles badly, convert it into a reusable test after privacy and governance requirements are satisfied. The evaluation suite should become a memory of important behavior so fixes do not disappear in later releases.
Use scorers that match the property being measured
MLflow supports model-based judges, code-based checks, and custom scorers. A deterministic format check is usually better in code than in an LLM judge. A nuanced assessment such as whether an answer follows a domain guideline may benefit from a judge. Retrieval metrics and groundedness checks should be separated from style checks so failures are interpretable.
Some judges require ground truth; others can evaluate against criteria or retrieved context. Choose the scorer based on the available evidence. The application should not be penalized for legitimate wording differences when the requirement is semantic correctness, and it should not pass merely because the wording sounds professional.
Traces make evaluation component-aware
MLflow Tracing can capture the full execution path: user input, retrieval, prompt construction, model calls, tool calls, intermediate outputs, latency, token use, and final response. Scoring the trace gives evaluators access to evidence that is invisible in the final text alone.
This is critical for hallucination analysis. If the retriever returned the correct source but the model ignored it, the fix differs from a case where retrieval never found the source. Trace-aware evaluation supports targeted engineering instead of treating all wrong answers as the same model defect.
Evaluate retrieval and generation separately
RAG systems contain at least two quality problems: finding the right evidence and using that evidence correctly. Measure whether relevant chunks are retrieved and ranked appropriately before judging the final response. Otherwise, a generation scorer can reveal that an answer is wrong without telling the team whether the problem belongs to the index or the model.
The existing RAG evaluation approach makes this separation explicit. The planned Vector Search design then provides the retrieval variables—chunking, embeddings, filtering, synchronization, and endpoint choices—that can be changed and re-tested.
Compare versions with the same evidence
Changing a model, prompt, retrieval strategy, tool description, or post-processing rule can improve one scenario and hurt another. Evaluation runs should compare candidate versions against a stable dataset and record the configuration that produced each result. Aggregate metrics are useful, but review important regressions even when the overall average improves.
Version tracking should extend beyond the model. A prompt-only change can materially alter behavior. A new chunking pipeline can change every retrieved context. A tool schema update can change which action an agent selects. Evaluation is reliable when the application version includes the dependencies that actually influence output.
Use expert feedback to calibrate automated judges
Subject-matter experts can identify subtle domain problems that generic scorers miss. They can determine whether a financial explanation is misleading, whether a support answer ignores a policy exception, or whether a technical recommendation is unsafe in the organization’s environment. Collect that feedback in a structured form rather than leaving it in chat messages or issue descriptions.
Human labels can also test whether an automated judge aligns with expert judgment. When they disagree, inspect why. The judge may need a more specific rubric, the dataset may contain ambiguous cases, or experts may themselves be applying inconsistent standards. Evaluation becomes stronger when the organization treats scoring criteria as an engineered artifact.
Offline evaluation and production monitoring serve different purposes
Offline evaluation is controlled. It can run before release on a curated dataset and compare versions repeatedly. Production monitoring observes live behavior, where users, data, and traffic patterns can differ from the test set. The same scorer definitions can bridge the two environments, but sampling, cost, privacy, and latency requirements may differ.
The planned production monitoring workflow uses live traces to detect quality changes after deployment. A production failure should feed back into the offline evaluation dataset, closing the loop between release testing and real-world behavior.
Evaluation should influence release decisions
Metrics are useful only if they change what the team does. Define minimum requirements for critical properties such as safety, format compliance, task success, or groundedness. A candidate model that lowers latency but fails important safety cases should not be promoted simply because the average score is higher.
The release process should preserve evaluation evidence with the deployed version. That gives operators a baseline when users report a regression and makes rollback decisions defensible. The goal of MLflow evaluation is not to produce a dashboard full of scores; it is to create a repeatable decision process for improving GenAI applications without losing known good behavior.
Cost should be part of evaluation as well. A candidate can improve answer quality by using a much larger model, retrieving more documents, and invoking more judges, but that architecture may not be viable at production volume. Measure quality together with latency and cost per task so the team can choose the smallest system that meets the business requirement.
Finally, keep evaluation data governed. Traces and examples may contain user prompts, proprietary documents, or tool outputs. Apply access controls, retention policies, redaction where appropriate, and clear ownership. The evidence used to improve a GenAI system is itself a sensitive production asset and should be managed accordingly.
A scorer should map to a decision the team is prepared to make. Deterministic code is useful for properties such as schema validity, required fields, exact policy checks, or known answer keys. LLM judges are useful for more nuanced properties such as relevance, completeness, or groundedness when the criterion is clearly defined. Human review remains the reference point for ambiguous or domain-specific cases. Mixing these methods gives stronger evidence than relying on one aggregate score.
Trace-level evaluation is especially valuable for multi-component applications. A low-quality final answer may originate in query rewriting, retrieval, tool selection, prompt construction, model generation, or post-processing. If only the final text is scored, the team knows that the application failed but not why. Evaluating trace components can localize the problem and prevent expensive changes to a model when the real issue is poor retrieval or a deterministic transformation.
Version comparison should control the evidence being used. Run candidate versions against the same evaluation dataset and the same core scorers, then inspect both aggregate results and important individual cases. Averages can hide regressions in rare but high-risk tasks, so release gates should include critical-case pass rates alongside overall quality metrics. When the evaluation dataset changes, record that change so historical comparisons remain interpretable.
Production examples should periodically refresh the offline dataset. New user phrasing, new documents, changed policies, and novel tool failures create cases that were not present during initial development. Curating those cases into a versioned evaluation set turns production incidents and expert feedback into regression tests. That feedback loop is what allows MLflow evaluation to support continuous improvement rather than one-time model selection.
Evaluation should also account for abstention behavior. A GenAI system is sometimes correct precisely because it refuses to guess when evidence is missing, asks for clarification, or escalates to a person. Include such cases in the dataset and score them according to the desired behavior. Otherwise, an evaluator may reward confident answers in situations where the safer application should recognize uncertainty and stop.
When several scorers disagree, inspect the underlying traces rather than collapsing everything into a single composite number too quickly. A response can be relevant but ungrounded, complete but unsafe, or well formatted while using the wrong evidence. Preserving the individual dimensions makes tradeoffs visible and helps teams assign fixes to the right component. Composite release rules can still be useful, but they should be built on interpretable criteria rather than hiding them.