SnowPro Specialty: Gen AI Question 213
Single answerCalling the modelA data engineering team is building an internal support assistant in Snowflake. They store ticket text in a table and want to generate concise summaries directly in SQL so analysts can join the results with other warehouse data. The team also wants to avoid managing external API infrastructure and keep model invocation governed within Snowflake. Which approach best meets these requirements?
- A
Call a Cortex LLM function such as SNOWFLAKE.CORTEX.COMPLETE from SQL against the ticket text stored in the table.
- B
Export the ticket text from Snowflake to an external Python service and invoke the model there, because Snowflake SQL cannot call LLMs directly.
- C
Use only vector search on the ticket text, because vector search replaces the need to call a language model for summarization.
- D
Create a materialized view with a user-defined function that trains a custom model inside Snowflake for each query.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to call a Snowflake Cortex model function directly from SQL, because the requirement is specifically about calling the model while keeping execution and governance inside Snowflake. In Snowflake, Cortex LLM functions enable model invocation from SQL without requiring the team to build and operate separate external inference infrastructure for common text-generation use cases such as summarization. This aligns with Snowflake best practices for in-platform generative AI workflows: keep data close to compute, simplify operational complexity, and integrate outputs with SQL analytics. By contrast, external services add operational overhead, vector search does not replace text generation, and the custom-training materialized-view option describes capabilities that do not match how model calling is performed in Snowflake. Candidates should recognize that for 'calling the model' in Snowflake, Cortex SQL functions are the practical and governed choice for supported generation tasks.
- A. Correct.
Correct. Snowflake Cortex provides SQL-accessible LLM functions, including functions used to call models directly from within Snowflake. This approach fits the scenario because the team wants to invoke a model in SQL, avoid external API orchestration, and keep processing governed inside Snowflake. It also supports practical downstream analytics because the generated output can be joined with relational data in SQL workflows.
- B. Incorrect.
Incorrect. Exporting data to an external service may be possible in some architectures, but it does not best meet the stated requirements. The scenario explicitly wants to avoid managing external API infrastructure and keep invocation within Snowflake. A common misconception is that LLM calls must happen outside the warehouse; Snowflake Cortex is specifically designed to reduce that need for supported generative AI tasks.
- C. Incorrect.
Incorrect. Vector search is useful for retrieval, similarity matching, and retrieval-augmented workflows, but it does not itself generate summaries. Someone might pick this because vector capabilities are often discussed alongside GenAI, but retrieval and generation are different steps. To create a concise ticket summary, the team still needs to call a language model.
- D. Incorrect.
Incorrect. Materialized views do not train a custom model for each query, and Snowflake does not use a materialized view as the mechanism for per-query model training in this scenario. This option combines multiple incorrect assumptions: that the team needs custom model training, that such training should happen on each query, and that a materialized view is the appropriate object for that purpose.