Assembling and deploying applications Study Guide — Generative AI Engineer Associate

Assembling and Deploying Applications

This domain tests your ability to package GenAI components (chains, agents, RAG pipelines) into production-ready systems on Databricks, covering logging and registration with MLflow and Unity Catalog, serving endpoint configuration, secrets management, inference capture, and rollout strategies. It represents 22% of the exam—one of the largest single domains—so expect 10–12 questions spanning every key topic below.

MLflow Logging and Registering Chains/Agents in Unity Catalog

Core Concepts

MLflow is the primary framework for tracking, packaging, and registering GenAI models on Databricks. For GenAI applications, models are logged as mlflow.pyfunc or, more commonly, using mlflow.langchain or mlflow.langchain.log_model() / mlflow.models.set_model() depending on the flavor.

Key MLflow flavors for GenAI:

Logging a chain with MLflow (key steps):

1. Call mlflow.set_experiment() to target the correct experiment.
2. Use mlflow.langchain.log_model() passing the chain object, an artifact path, and a signature (input/output schema).
3. The model signature (created via mlflow.models.infer_signature()) is critical—serving endpoints use it to validate request payloads.
4. Set an input example to enable automatic signature inference and UI preview.

Unity Catalog registration replaces the legacy Workspace Model Registry. Models are registered to a three-level namespace: <catalog>.<schema>.<model_name>.

mlflow.set_registry_uri("databricks-uc")
mlflow.register_model(
    model_uri="runs:/<run_id>/model",
    name="main.genai_prod.rag_chain"
)

Model versions are immutable once created. Aliases (e.g., @champion, @challenger) replace the legacy Staging/Production stages.

MLflow set_model() vs log_model()

Common Traps

• Using Workspace Model Registry instead of Unity Catalog: The exam tests that mlflow.set_registry_uri("databricks-uc") must be called; without it, models register to the workspace registry, losing governance features.
• Missing model signature: A model logged without a signature can still be served, but the endpoint will not validate inputs—exam distractors offer "no signature needed."
• Confusing set_model() with log_model(): set_model() is used in the Databricks Asset Bundles / chain notebook pattern; it does not require an active run.
• Aliases vs. Stages: The exam may present "set model to Production stage"—this is the legacy pattern. Current answer is to assign the @champion alias.
• Three-level namespace: Forgetting catalog.schema.model format causes registration failures; two-level is a common distractor.

Worked Scenario

Requirement: A team builds a RAG chain in LangChain and must register it in Unity Catalog under catalog prod, schema rag, model name support_bot, with input validation enforced at the serving endpoint.

Reasoning: Use mlflow.langchain.log_model() with an explicit signature argument (not relying on auto-inference alone). Set mlflow.set_registry_uri("databricks-uc") before calling mlflow.register_model("runs:/…/model", "prod.rag.support_bot"). Assign the @champion alias to the registered version for serving.

Model Serving Endpoints: Creation, Scaling, Routes

Endpoint Architecture

Databricks Model Serving (also called Mosaic AI Model Serving) exposes registered models as scalable REST APIs. Each endpoint has one or more served entities (previously called "served models").

Bold decision tree below shows how to configure an endpoint:

How to select endpoint configuration based on workload requirements

Endpoint Configuration Parameters

Endpoint Types Comparison

Routes and Multi-Endpoint Traffic Splitting

An endpoint can serve multiple served entities simultaneously, each receiving a percentage of traffic (must sum to 100%). This enables:

• A/B testing between model versions
• Canary deployments (e.g., 95% v1 / 5% v2)
• Shadow mode is not natively supported via traffic split—shadow requires external tooling

Creating an endpoint via the REST API / SDK:

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import EndpointCoreConfigInput, ServedModelInput

w = WorkspaceClient()
w.serving_endpoints.create(
    name="rag-support-endpoint",
    config=EndpointCoreConfigInput(
        served_models=[
            ServedModelInput(
                model_name="main.genai_prod.rag_chain",
                model_version="3",
                workload_size="Small",
                scale_to_zero_enabled=True,
                traffic_percentage=100
            )
        ]
    )
)

Common Traps

• Traffic percentages must sum to 100: If a question lists 50%+60% across two served entities, that is invalid—exam uses this as a distractor.
• Scale-to-zero ≠ no cold start: Scale-to-zero is valid for cost savings but introduces latency on first request; exam distractors claim it has no downside.
• Foundation Model APIs vs. Provisioned Throughput: Foundation Model APIs are best for variable/bursty workloads; Provisioned Throughput is for consistent high-volume requiring guaranteed throughput SLA.
• Compute size "Small/Medium/Large" refers to the number of concurrent requests, not raw compute—"Small" = 4 concurrent requests.
• Custom model endpoints require the model in Unity Catalog (or workspace registry) before the endpoint can be created.