Databricks Generative AI Engineer Associate — Übungsfragen und Probeprüfung

A/B-Tests von GenAI-Agenten auf Databricks laufen über die traffic_config eines Serving-Endpoints, die Anfragen zwischen served entities aufteilt. Jede Agent-Version wird als eigene served_entity auf demselben Endpoint bereitgestellt, und traffic_percentage steuert die Aufteilung (die Summe muss 100 ergeben). Die Antworten jeder Version werden getrennt in der Inference Table protokolliert, sodass sich Qualität, Latenz und Nutzerfeedback vergleichen lassen. Analyse der Distraktoren: Die Option „Feature Serving nutzen, um jede Anfrage zu markieren und sie … zu leiten“ ist falsch – Feature Serving dient dem Nachschlagen von Features, nicht dem Prompt-Routing. Die Option „Einen einzelnen Endpoint mit einem Pre-Processing-Hook bereitstellen …“ ist falsch – Pre-Processing-Hooks bieten kein richtiges Traffic-Management und kein unabhängiges Logging. Die Option „Jede Prompt-Version im MLflow Model Registry registrieren …“ ist falsch – eigene Routing-Notebooks umgehen das eingebaute Traffic-Management und das Inference-Logging von Databricks. Ref: docs.databricks.com/en/machine-learning/model-serving/serve-multiple-models-to-serving-endpoint.html

Das Wissen eines LLM ist zum Trainingszeitpunkt eingefroren, deshalb kann es Fragen zum aktuellen Geschehen nicht beantworten. Eine RAG-Pipeline mit Delta Live Tables (die Option „Ein Retrieval-Agent, der eine laufend aktualisierte Delta …“) holt nur indexierte Dokumente, keine Live-Daten aus dem Web. Ein vergrößertes Kontextfenster mit zwischengespeicherten Snapshots (die Option „Das Kontextfenster vergrößern, damit ein zwischengespeicherter Snapshot …“) arbeitet weiterhin mit veralteten Daten. Wöchentliches Feintuning (die Option „Das Basismodell wöchentlich … feintunen“) bringt eine Verzögerung von mehreren Tagen mit sich. Ein Tool-Calling-Agent mit Websuche- oder Echtzeit-API-Tools (die Option „Ein Tool-Calling-Agent mit einem Websuche- oder Echtzeit-API-Tool“) ruft externe Datenquellen bei Bedarf auf und liefert topaktuelle Ergebnisse. Databricks unterstützt das über MCP-Server, eigene Tools und die eingebaute Websuche-Integration mit Gemini-/OpenAI-/Anthropic-Modellen. Ref: docs.databricks.com/en/machine-learning/model-serving/web-search; docs.databricks.com/en/generative-ai/agent-framework/agent-tool.

Beim Erstellen eines Delta Sync Vector Search Index mit verwalteten Embeddings bestimmt der Parameter embedding_source_column die Textspalte, die Databricks automatisch einbettet. Die Plattform ruft den angegebenen Endpoint des Embedding-Modells auf, verarbeitet den Text in Batches und speichert die entstehenden Vektoren im Index. Die Optionen „auto_embedding_column“, „vector_embedding_source“ und „text_vectorization_col“ sind erfundene Parameternamen – keiner davon kommt im Databricks SDK oder in der REST API vor. Für selbst verwaltete Embeddings gibst du stattdessen eine embedding_vector_column mit vorberechneten Vektoren an. Ref: docs.databricks.com/en/generative-ai/vector-search/create-index; docs.databricks.com/en/vector-search/query-vector-search.