Databricks Generative AI Engineer Associate: Design applications Practice Questions

Text summarization is the model task specifically designed to condense long documents into shorter, coherent representations—exactly what is needed for an executive summary of earnings reports. Text classification assigns a label to input text rather than condensing it. Named-entity extraction identifies specific entities (names, dates, organizations) rather than producing a summary. Conversational chat is designed for interactive, multi-turn dialogue, not for batch document condensation.

Including three worked examples makes this few-shot prompting; showing the reasoning process within each example is chain-of-thought prompting. Together, few-shot CoT is one of the most effective prompting strategies for complex classification and reasoning tasks. Zero-shot would mean no examples are provided, which contradicts the scenario. RAG involves retrieving external documents at inference time—there is no retrieval step described. Fine-tuning modifies model weights through training, which is distinct from in-context prompting techniques.

Zero-shot prompting asks the model to perform a task using only the task description and input, with no labeled examples provided. Few-shot prompting would require providing example input-output pairs in the prompt. Chain-of-thought prompting guides the model through explicit reasoning steps. RAG augments the prompt with retrieved external documents, which is unrelated to the labeling/examples dimension of prompting.

Correct (B & C): (B) is measurable: it specifies a numeric threshold (90%), an evaluation method (expert rubric), and a testing phase—making it actionable for engineers to design and validate against. (C) is measurable: it defines a specific safety constraint (no exercises above stated fitness level), an enforcement mechanism (post-generation filter), and a clear pass/fail criterion (flagged and blocked). Together they reflect best practice for defining quality and guardrail requirements before engineering begins. (A) is wrong: 'high-quality and relevant' is vague—it specifies no metric, threshold, or evaluation method, making it untestable. (D) is wrong: 'accurate and avoid harmful outputs whenever possible' is aspirational and unmeasurable; it provides no criteria for determining whether the requirement is met. (E) is wrong: 'feel fast enough' is subjective with no numeric target (e.g., p95 latency < 3 seconds); it cannot be tested or verified as stated.

Fine-tuning is favored when (A) the base model cannot learn the desired behavior from prompt examples alone—such as a proprietary output schema—because fine-tuning bakes that behavior into the weights; and (C) when at scale, long few-shot prompts become prohibitively expensive, since a fine-tuned model can produce the same quality output with a much shorter prompt. Real-time knowledge from the past two weeks is better served by RAG or tool use, since fine-tuning still produces a static snapshot. An internal document repository suggests RAG, not fine-tuning. A task the base model already handles well requires neither fine-tuning nor complex prompting.