SnowPro Specialty: Gen AI Question 86
Single answerSnowflake CortexA retail analytics team stores customer support tickets in a Snowflake table and wants to add an AI-powered summarization feature directly inside Snowflake. The team must minimize operational overhead, avoid managing external model infrastructure, and ensure analysts can invoke the capability from SQL in existing workflows. Which approach best meets these requirements?
- A
Use a Snowflake Cortex complete or summarization function directly in SQL against the ticket text stored in Snowflake tables.
- B
Export the ticket data to an external LLM provider, build a custom REST service for summarization, and call it from analysts' BI dashboards.
- C
Train a new transformer model inside a Snowflake virtual warehouse using standard SQL statements, then publish it as a warehouse-scoped function.
- D
Create a materialized view that automatically converts all ticket text into embeddings and human-readable summaries without calling any AI function.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Cortex functions directly in SQL. Cortex is intended to bring generative AI capabilities closer to enterprise data inside Snowflake, allowing teams to run inference such as summarization and text generation without exporting data to external model-serving systems. For this scenario, the key decision factors are operational simplicity, SQL accessibility, and reduced data movement. External API-based architectures may work technically, but they introduce more governance, integration, latency, and maintenance burden. Likewise, standard Snowflake warehouses are not a mechanism for training custom transformer foundation models through ordinary SQL commands, and materialized views do not automatically create summaries. This aligns with Snowflake best practices for using Cortex to apply LLM-powered functions directly where the data already resides.
- A. Correct.
Correct. Snowflake Cortex is designed to provide AI capabilities such as text generation and summarization directly within Snowflake, accessible from SQL. This aligns with the team's goals: low operational overhead, no need to manage external model infrastructure, and simple integration into existing SQL-based analytics workflows. Keeping the data in Snowflake also reduces unnecessary data movement.
- B. Incorrect.
Incorrect. Although an external LLM integration could produce summaries, it increases operational complexity and requires managing external services, networking, security, and application logic. This directly conflicts with the requirement to minimize operational overhead and avoid managing external model infrastructure.
- C. Incorrect.
Incorrect. Snowflake virtual warehouses are compute resources for executing workloads, but they are not used to train and publish custom transformer foundation models through standard SQL in the way described here. This option reflects a common misconception that Snowflake warehouses function like generic ML training clusters for arbitrary deep learning model development.
- D. Incorrect.
Incorrect. Materialized views do not independently perform generative AI summarization. Embeddings and summaries require explicit AI function calls or supported processing workflows. This distractor reflects the misconception that Snowflake automatically derives semantic representations or generated text merely by storing text in a view.