Snowflake Cortex suite, including Cortex Models and Functions, Cortex Fine-tuning, Cortex Search for RAG and unstructured data use cases, Cortex Analyst for text-to-SQL, and Cortex Agents

The Cortex suite is the managed generative AI plane that sits next to the standard Snowflake compute and storage planes. Every Cortex surface inherits Snowflake's data-residency boundary: prompts, embeddings, retrieved chunks, and model outputs stay inside the account's region under the standard service terms, and access flows through the same RBAC layer that protects tables and views. A practitioner choosing between Cortex surfaces is choosing between contracts, billing models, and accuracy profiles rather than between fundamentally different deployment shapes.

Cortex Models and Functions cover the generative endpoints accessible through SQL, Python, and REST. AI_COMPLETE (and the legacy alias SNOWFLAKE.CORTEX.COMPLETE) calls a hosted large language model with a prompt and optional structured-output schema. Task-specific functions such as AI_CLASSIFY, AI_EXTRACT, AI_SENTIMENT, AI_FILTER, AI_AGG, AI_SIMILARITY, and AI_EMBED each wrap a generative call behind a strongly typed return shape so that pipelines do not need to parse free-form LLM output. The billing model is per-token credit consumption tracked through CORTEX_AISQL_USAGE_HISTORY. The accuracy profile is whatever the chosen base model offers; the practitioner picks the model via the model parameter from the published list (Claude family, Llama family, Mistral, Snowflake Arctic, OpenAI hosted, plus task-tuned models such as snowflake-arctic-extract).

Cortex Fine-tuning (Public Preview) layers a managed training pipeline on top of the supported base models. The function SNOWFLAKE.CORTEX.FINETUNE accepts a training dataset, a validation dataset, and a base model identifier and returns a fine-tune job that, on completion, registers a tuned model the practitioner can invoke through AI_COMPLETE by name. The practitioner does not provision GPUs; Snowflake schedules training capacity, meters credit consumption against the warehouse, and stores the tuned weights inside the Snowflake-managed model boundary. The supported base list is narrower than the Cortex inference list; verify the current matrix in the documentation before committing to a tuning plan.

Cortex Search is the indexed retrieval surface. The practitioner defines a CORTEX SEARCH SERVICE over a base table, picks an embedding model (snowflake-arctic-embed-l-v2.0 or comparable), specifies the text column, optional attributes for filtering, and a target warehouse. Snowflake then incrementally ingests, embeds, and indexes the rows; queries combine a vector similarity search with lexical scoring and an optional reranker. Cortex Search is read-only from the application's perspective and is billed against indexing compute, embedding tokens, and serving requests. The accuracy profile blends lexical recall with semantic ranking, which makes it the default RAG choice for Snowflake-resident text.

Cortex Analyst is the text-to-SQL surface grounded in a Semantic View. The practitioner publishes a YAML specification that declares tables, columns, relationships, metrics, synonyms, sample queries, and verified queries; Cortex Analyst then accepts natural-language questions, plans an answer against that semantic surface, generates Snowflake SQL, executes it, and returns the rows plus a textual answer. Because the SQL surface is bounded by the semantic model, Cortex Analyst is read-only and cannot mutate data. Custom Instructions allow the practitioner to bias the answer style; the Verified Query Repository pins known-good SQL for high-traffic questions.

Cortex Agents orchestrate the surfaces above. An agent is a server-side object that declares a system prompt, a set of tools (cortex_analyst_text_to_sql, cortex_search, sql_exec, custom tools backed by stored procedures or HTTP), and a base model. The agent receives a user message, reasons over which tool to invoke, executes it inside the account, and returns a structured response. Agents are how a single natural-language request becomes a multi-step plan that hits both structured and unstructured retrieval surfaces.

-- A single Cortex AISQL call: generative completion against a hosted model
SELECT AI_COMPLETE(
 model => 'claude-3-5-sonnet',
 prompt => 'Summarize this support ticket in two sentences: ' || ticket_body,
 model_parameters => {'temperature': 0.2, 'max_tokens': 200}::VARIANT
) AS summary
FROM support.raw_tickets
WHERE ingested_at = CURRENT_DATE();

-- Defining a Cortex Search service over a documentation corpus
CREATE OR REPLACE CORTEX SEARCH SERVICE docs_search
 ON content_text
 ATTRIBUTES product_family, doc_type, language
 WAREHOUSE = search_wh_small
 TARGET_LAG = '1 hour'
 EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
AS
 SELECT doc_id, content_text, product_family, doc_type, language
 FROM knowledge_base.chunked_docs;

# Invoking a Cortex Agent over REST from a Streamlit in Snowflake app
import json, requests
from snowflake.snowpark.context import get_active_session

session = get_active_session()
token = session.connection.rest.token
host = session.connection.host

resp = requests.post(
 f"https://{host}/api/v2/cortex/agent:run",
 headers={"Authorization": f"Snowflake Token=\"{token}\"",
 "Content-Type": "application/json"},
 data=json.dumps({
 "model": "claude-3-5-sonnet",
 "messages": [{"role": "user",
 "content": [{"type": "text",
 "text": "Which products had the largest QoQ revenue jump?"}]}],
 "tools": [{"tool_spec": {"name": "analyst", "type": "cortex_analyst_text_to_sql"}},
 {"tool_spec": {"name": "kb", "type": "cortex_search"}}]
 }),
 timeout=60,
)
print(resp.json())

Cortex Analyst capabilities, including Semantic Views, Semantic Views Autopilot, the YAML Specification for Semantic Views, Verified Query, and Custom Instructions

A Semantic View is a Snowflake first-class object that declares the logical model Cortex Analyst is allowed to query. The YAML specification names the base tables, the columns that are queryable, the relationships between tables, the measures and dimensions exposed to the planner, the synonyms a user might say, and the sample questions that anchor the planner's reasoning. The author owns the surface area: a column omitted from the YAML is invisible to Cortex Analyst regardless of underlying grants. The YAML is published into a stage and bound to the Cortex Analyst endpoint at query time through the semantic_model_file parameter.

Semantic Views Autopilot is the assisted-authoring path. The practitioner points Autopilot at a set of tables and lets the service propose an initial YAML covering the obvious join graph, typed measures, and synonym candidates derived from column metadata and sample data profiling. Autopilot output is a draft, not a final artifact: every field should be reviewed for business correctness, sensitive-column omission, and synonym precision before publication. The pattern that ships well is Autopilot for the first 80 percent of the YAML, then hand-curation for measure definitions and verified queries.

A Verified Query is a labelled natural-language question paired with the exact SQL that answers it correctly. The Verified Query Repository stores these pairs alongside the Semantic View. When Cortex Analyst receives a question that semantically matches a verified entry, it returns the verified SQL rather than synthesising new SQL, which collapses the accuracy variance for high-traffic prompts. Verified queries are the right home for revenue, headcount, churn, and any metric where a wrong answer creates a business incident.

Custom Instructions are free-form authoring guidance attached to the Semantic View: tone constraints, default time grain, preferred currency, disambiguation rules ("if the user says revenue, always mean net revenue"), and answer-format preferences. Custom Instructions are not a substitute for verified queries; they steer phrasing and disambiguation, while verified queries pin the SQL.

💡 Exam Trap: Cortex Analyst is read-only against the Semantic View. A scenario that asks the model to insert a row, run a DML statement, or call an external API through Cortex Analyst is testing whether you remember the surface boundary. The right answer routes mutation through a stored procedure or a Cortex Agent tool, not through Cortex Analyst itself.

⚠️ Anti-Pattern: Publishing a Semantic View that exposes raw fact tables with no measures defined. Without typed measures, Cortex Analyst infers aggregations from the natural-language question, which produces inconsistent results across phrasings. Declare each business metric as a measure in the YAML before exposing the view.

📊 Limit: A Cortex Search service incrementally re-embeds rows on a target lag you configure (commonly minutes to hours). The serving query latency target is sub-second for typical corpora, but indexing throughput is bound by the warehouse you attach to the service. Verify current published limits before sizing for tens of millions of chunks.

🎯 Scenario: A product team wants a natural-language interface over the sales mart so that account executives can ask "what is my pipeline by region this quarter". The right architecture is a Semantic View with measures for pipeline_amount and closed_won_amount, dimensions for region and quarter, synonyms ("territory" maps to region), and verified queries for the top ten prompts the team already gets in Slack. Cortex Analyst then answers the long tail through SQL generation while pinning the high-traffic prompts to verified SQL.

Decision Anchor: Choose AI_COMPLETE when the workload is a per-call generative transformation over column data with no retrieval requirement. Choose Cortex Search when the answer must be grounded in a Snowflake-resident text corpus. Choose Cortex Analyst when the answer must come from structured rows behind a published semantic model. Choose Cortex Agents when a single user request needs to chain two or more of the above with reasoning between steps.