Free Databricks GenAI Associate Exam Flashcards

RAG retrieves fresh documents at query time, so it beats fine-tuning when the knowledge is proprietary, frequently changing, or must be cited. Fine-tuning is better for shaping style, tone, or stable behavior, but it cannot efficiently encode weekly policy updates and does not give you source attribution.

Hardcoding answers into a system prompt works only for tiny, static knowledge. As soon as the source documents change or the question space grows, the prompt becomes unmaintainable and answers go stale. RAG scales because the knowledge lives outside the model and is fetched on demand.

Use plain RAG when one retrieval pass answers the question. Choose an agent when the task needs multiple steps, tool calls, conditional branching, or iterative retrieval. Agents add flexibility but also add latency, cost, and harder evaluation, so do not graduate to one unless single-pass retrieval genuinely cannot solve the problem.

Break a GenAI request into explicit stages such as retrieval, context assembly, generation, and post-processing so each can be measured and fixed independently. Monolithic prompts hide where quality is lost, which makes debugging slow. Explicit stages give you clear failure boundaries and let you swap components without rebuilding the whole app.

Context augmentation inserts retrieved chunks into the prompt so the model conditions its answer on supplied evidence instead of parametric memory. The consequence is that answer quality is bounded by retrieval quality: if the wrong chunks are retrieved, even a strong model will produce a wrong or unsupported answer.

Delta Sync indexes automatically follow a Delta table and refresh as the table changes, so they are the default when the source is Delta. Direct Vector Access indexes skip the sync and require you to manage vectors and metadata yourself, which only makes sense when the embeddings come from outside Databricks or the source is not a Delta table.

A standard Delta Sync index reads the source Delta table's change stream to apply incremental updates. If Change Data Feed is not enabled on the table, index creation fails because there is no supported way to track row changes. Enable CDF on the source table before creating the index.

A Vector Search endpoint is the compute resource that hosts one or more indexes and serves similarity queries. It is separate from the index itself, so you can host multiple indexes on one endpoint and size the endpoint independently from the data. Endpoint sizing affects latency and cost, not correctness.

The index needs a column that holds the embedding vector for each row. For Delta Sync indexes Databricks can compute the embedding for you from a text column; for Direct Vector Access indexes you must supply the precomputed vector column. Mismatched dimensions between the embedding column and the query vector cause queries to fail.

Hybrid search combines vector similarity with keyword matching, which helps when queries contain rare proper nouns, codes, or IDs that pure semantic retrieval misses. Use it when exact term matches matter; pure vector search is better when paraphrase and meaning dominate the query.

Small chunks give precise retrieval but may fragment context so the model cannot see a complete idea. Large chunks preserve surrounding context but dilute relevance and consume the context window faster. Pick chunk size based on document structure and the kind of answer the user needs, then measure retrieval quality rather than guessing.

Overlap between adjacent chunks prevents a single idea from being split at a boundary, so the model still sees enough context to interpret each chunk. Overlap increases storage and token cost, so use it where boundary splits hurt answer quality, not on every pipeline by default.

The embedding model fixes the dimensionality and semantic space of the index, so the query embedder and the index embedder must match exactly. Switching embedding models forces a full reindex because old vectors and new vectors are not comparable. Choose based on language coverage, dimension, latency, and quality on your own evaluation set.

Re-ranking takes a larger pool of candidate chunks and scores them again with a more expensive model, pushing the most relevant chunks to the top. It is the standard fix when recall is acceptable but top-k precision is poor. The tradeoff is added latency per query, so apply it only after first-stage retrieval is working.

Metadata filters restrict retrieval to rows that match conditions such as source, language, or date, so the model only sees eligible evidence. Use them when the user's question implies a scope, for example 2026 policies only. Without filters, the retriever may return older or out-of-scope chunks that mislead the answer.

The system prompt sets persistent behavior such as role, rules, format, and safety constraints that applies across turns. The user prompt carries the per-request instruction and any retrieved context. Put stable instructions in the system prompt so they are not accidentally overridden by user input or context injection.

Few-shot examples teach the model the desired output pattern by showing labeled input-output pairs in the prompt. It is the cheapest way to steer format, tone, or extraction behavior without training. The risk is that examples consume the context window and can bias the model toward example-specific patterns, so keep examples representative and minimal.

Iterate prompts against an evaluation set, not single conversations, because a prompt that fixes one case often breaks another. Hold the model and retrieval fixed while you change one prompt variable at a time, then re-measure. Prompts committed without an eval set regress silently in production.

The context window caps how much text the model can attend to in one call, including system prompt, retrieved chunks, conversation history, and the user query. Overstuffing the window causes truncation, higher cost, and sometimes degraded attention. Retrieve selectively and trim history rather than padding the window with low-value context.

Pay-per-token is the default Foundation Model API mode and is best for prototyping and low or bursty traffic because you only pay for what you use. Provisioned throughput reserves capacity for predictable latency and higher volume, which is the right choice for production workloads that need performance guarantees. Switching to provisioned is a cost tradeoff, not a quality change.

The Foundation Model API serves curated open and proprietary base models from Databricks-hosted endpoints with a unified interface. It removes the need to stand up your own inference infrastructure and lets you swap models behind a stable endpoint. You still own prompt engineering, evaluation, and governance; the API only provides model access.

External model serving lets you register and call third-party models such as OpenAI or Anthropic through a Databricks-hosted endpoint. The benefit is unified governance, logging, and AI Gateway controls across providers. The cost is added network hop latency and dependency on the external provider's rate limits and availability.

Larger models generally give better quality but raise latency, cost, and context-window pressure. Pick the smallest model that clears your evaluation threshold, not the largest available. Re-evaluate whenever a new model lands, because the cost-quality frontier moves quickly.

A serving endpoint bundles a model with compute and an API. You configure scale, throughput mode, and environment separately from the model, so the same registered model can be served different ways for dev and production. Misconfigured compute is a common cause of latency regressions that look like model-quality problems.

pyfunc packaging lets you bundle a GenAI application including prompts, retrieval, post-processing, and model into one MLflow model with a consistent predict interface. That makes a RAG app deployable through the same Model Serving endpoints used for classical ML, so governance, monitoring, and CI/CD treat it uniformly.

Registering the GenAI model in MLflow gives it a version, stage, and lineage, which are the prerequisites for controlled promotion and rollback. Without registration you cannot safely move from prototype to production, because there is no auditable artifact to promote, compare, or roll back.

ResponsesAgent standardizes how an agent is exposed so Databricks tooling such as playground, evaluation, and deployment can drive it uniformly. Wrapping a custom agent in ResponsesAgent is what enables downstream product features without forcing you to reimplement them. Skipping the wrapper means losing integration with the platform's agent lifecycle.

Separate retrieval, prompt assembly, generation, and post-processing into explicit components so each can be measured and swapped independently. Monolithic GenAI apps are hard to debug because a regression could come from any stage with no clear boundary. Stage separation also enables independent CI/CD for prompts, indexes, and models.

Inference tables automatically log requests and responses for a served model, giving you a queryable history of production traffic. They are the foundation for post-hoc evaluation, drift detection, and retraining decisions. Without them you have no structured record of what the model actually saw or returned in production.

A chain is a fixed sequence of calls where control flow is known at design time. An agent decides which tool or step to call next based on the model's reasoning over intermediate results. Use a chain when the workflow is deterministic; use an agent when the path depends on the content of the answer.

Tool calling lets the model emit a structured request to invoke an external function such as a search, a database lookup, or a calculator, and then condition its next answer on the returned result. It is the bridge between the model and live data. The model decides when to call a tool, but you define which tools exist and validate the call schema.

The Databricks LangChain integration exposes Vector Search as a vector store and models as LLM components, so you can compose retrieval, prompts, and tools with standard LangChain primitives. The benefit is portability of chain code; the risk is hiding platform-specific behavior behind abstractions, so you still need to understand the underlying Databricks components.

LangGraph models an agent as a graph of nodes and edges with explicit state passed between them, which is what you need when an agent loops, branches, or keeps memory across turns. Plain LangChain chains are linear, so reach for LangGraph when control flow is conditional or cyclic. The tradeoff is more code and harder debugging for simpler cases.

Persistent state lets an agent remember intermediate results, conversation history, or tool outputs across calls, which is required for multi-step and multi-turn agents. Without persistence the agent restarts every call and cannot reason over prior steps. Choose storage that matches the state's lifetime: in-memory for a request, Delta or a key-value store for cross-session memory.

Agent Bricks are managed Databricks building blocks that handle common agent infrastructure such as tool wiring, memory, and evaluation hooks so you can assemble agents without writing the plumbing yourself. They reduce boilerplate and standardize integration with the platform, which is why the March 18, 2026 blueprint added deeper coverage of them.

MCP standardizes how agents discover and call tools, resources, and prompts across providers and runtimes. It improves interoperability so the same tool can be reused across agent frameworks instead of being rewritten per integration. It does not replace security controls: you still must govern which tools an agent may call and on what data.

Databricks can host a managed MCP endpoint that exposes governed resources, for example a Vector Search index, as a tool an agent can call through the standard protocol. This is preferred over custom connectors because the access path stays inside Databricks governance instead of being a bespoke integration you maintain yourself.

Groundedness measures whether the model's answer is supported by the retrieved evidence, not whether the answer reads well or matches a gold answer. A confident, fluent answer that adds facts not in the sources fails groundedness. It is the metric that catches hallucination in RAG apps most directly.

Retrieval relevance scores whether the retrieved chunks themselves match the user's question, evaluated before the generation step. It isolates retriever quality from generator quality, which lets you fix retrieval without confusing it with prompt or model issues. Low retrieval relevance means no model can rescue the answer.

An LLM judge can scale subjective evaluation, but only with an explicit rubric that tells it what to score and how. Without a rubric the judge drifts and produces noisy grades that correlate with length or tone rather than quality. Always calibrate the judge against human-reviewed examples before trusting it at scale.

Offline evaluation runs against a fixed golden set before launch and tells you whether the app meets a quality bar. Online evaluation observes real traffic after launch and catches drift, edge cases, and operational regressions the golden set missed. You need both: offline is the gate, online is the guardrail.

Custom scorers encode domain-specific pass/fail rules, for example must cite a source or must not mention competitor pricing, that generic metrics cannot capture. Add them when business or compliance constraints are not reflected in standard retrieval or groundedness metrics. The March 18, 2026 blueprint added deeper coverage of custom scorers.

Track latency, error rate, token usage, and prompt length distribution over live traffic to catch regressions that offline tests cannot see. Spikes in latency or failure rate often surface before users complain. Online monitoring is the only way to detect drift caused by upstream model or data changes outside your release cadence.

AI Gateway sits between applications and LLM endpoints to centralize usage logging, policy enforcement, and monitoring across teams and providers. Without it, usage data is scattered across individual apps and there is no single place to enforce rate limits, redaction, or provider failover. It is the right tool when leadership needs cross-team visibility into LLM spend and behavior.

AI Gateway rate limits cap requests or tokens per user, team, or application so one noisy consumer cannot monopolize a shared endpoint. They are a direct control for both spend and throughput, which is the right fix when one team's traffic is driving cost or degrading service for everyone else.

Unity Catalog centralizes access control, lineage, and auditing for data, models, functions, and vector indexes, so a GenAI app can be governed as one asset graph instead of scattered workspace-level controls. It is the foundation when the app must satisfy enterprise permissions, masking, or audit requirements. Ad hoc workspace controls do not scale across teams.

External API tokens and model-provider keys must live in Databricks secret management, not in notebooks, prompts, source code, or run metadata. Embedding credentials in code or prompts creates avoidable disclosure risk and makes rotation painful. Expose secrets only to the identities and jobs that need them.

Guardrails check both input and output for unsafe or out-of-policy content such as prompt injection, PII, harmful requests, or banned topics before the request reaches the model or the response reaches the user. They are distinct from access control: a user may be authorized to call the app but still submit unsafe input that must be blocked.

AI Functions such as ai_parse_document, ai_classify, and ai_extract run AI tasks directly on data in SQL, notebooks, and pipelines, so row-wise inference at scale does not require a custom chain. They fit batch classification, extraction, and summarization over table data. For interactive multi-turn retrieval or tool use, build a RAG or agent app instead.

When the task is deterministic field extraction such as invoice number, vendor name, or total, ask the model for a fixed JSON schema rather than free text. Schema-driven output is easier to validate, test, and wire into downstream systems, and explicit return-only-JSON instructions reduce parsing failures from stray prose.