Databricks Generative AI Engineer Associate — Questions d'entraînement et examen blanc

Les tests A/B d'agents GenAI sur Databricks reposent sur la traffic_config d'un serving endpoint, qui répartit les requêtes entre les served entities. Chaque version de l'agent est déployée comme une served_entity distincte sur le même endpoint, et traffic_percentage contrôle la répartition (le total doit faire 100). Les réponses de chaque version sont journalisées séparément dans l'inference table, ce qui permet de comparer qualité, latence et retours des utilisateurs. Analyse des distracteurs : l'option « Utiliser Feature Serving pour étiqueter chaque requête et la router… » est fausse — Feature Serving sert à récupérer des features, pas à router des prompts. L'option « Déployer un endpoint unique avec un hook de prétraitement… » est fausse — les hooks de prétraitement n'offrent ni véritable gestion du trafic ni journalisation indépendante. L'option « Enregistrer chaque version de prompt dans MLflow Model Registry… » est fausse — un notebook de routage maison contourne la gestion du trafic et la journalisation des inférences intégrées à Databricks. Ref: docs.databricks.com/en/machine-learning/model-serving/serve-multiple-models-to-serving-endpoint.html

Les connaissances d'un LLM sont figées au moment de l'entraînement : il ne peut donc pas répondre à des questions sur l'actualité. Un pipeline RAG avec Delta Live Tables (l'option « Un agent de retrieval qui interroge un pipeline Delta… ») ne récupère que des documents indexés, pas des données web en direct. Élargir la fenêtre de contexte avec des instantanés en cache (l'option « Élargir la fenêtre de contexte pour y inclure un instantané en cache de… ») revient encore à utiliser des données périmées. Un fine-tuning hebdomadaire (l'option « Faire un fine-tuning hebdomadaire du modèle de base… ») introduit un décalage de plusieurs jours. Un agent à appel d'outils doté d'une recherche web ou d'outils d'API temps réel (l'option « Un agent à appel d'outils doté d'un outil de recherche web ou d'API temps réel ») interroge des sources de données externes à la demande et renvoie des résultats à la minute près. Databricks le permet via des serveurs MCP, des outils personnalisés et l'intégration de recherche web native avec les modèles Gemini/OpenAI/Anthropic. Ref: docs.databricks.com/en/machine-learning/model-serving/web-search; docs.databricks.com/en/generative-ai/agent-framework/agent-tool.

Lors de la création d'un index vector search Delta Sync avec embeddings managés, le paramètre embedding_source_column identifie la colonne de texte que Databricks va vectoriser automatiquement. La plateforme appelle l'endpoint du modèle d'embedding indiqué, traite le texte par lots et stocke les vecteurs obtenus dans l'index. Les options « auto_embedding_column », « vector_embedding_source » et « text_vectorization_col » sont des noms de paramètres inventés : aucun n'apparaît dans le SDK ni dans l'API REST de Databricks. Pour des embeddings auto-gérés, tu indiques à la place une embedding_vector_column contenant des vecteurs pré-calculés. Ref: docs.databricks.com/en/generative-ai/vector-search/create-index; docs.databricks.com/en/vector-search/query-vector-search.