SnowPro Specialty: Gen AI Question 184
Single answerSQL interfaceA data engineering team is building a support-ticket summarization pipeline directly in Snowflake. Ticket text is stored in a table, and analysts want to generate summaries using SQL so the output can be joined with existing reporting queries. The team also wants to avoid maintaining external application code for inference. Which approach best meets these requirements using Snowflake's SQL interface?
- A
Use a SQL SELECT statement that calls a Cortex LLM function, such as SNOWFLAKE.CORTEX.COMPLETE, against the ticket text and store the results in a table or view.
- B
Create a standard SQL UDF that contains Python model weights and run the LLM entirely inside the UDF so no Snowflake AI function is needed.
- C
Export the ticket data to an external REST service from SQL, invoke the model there, and reload the summaries because Snowflake SQL cannot invoke LLM capabilities directly.
- D
Use a masking policy with embedded prompt text so Snowflake automatically replaces ticket text with generated summaries whenever analysts query the table.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake's SQL interface for Cortex AI through AISQL functions. In practice, teams commonly use SQL functions such as SNOWFLAKE.CORTEX.COMPLETE to perform tasks like summarization, extraction, classification, and question answering directly in queries. This is well aligned with the scenario because it keeps data in Snowflake, simplifies governance, and lets analysts join generated outputs with existing tables and BI queries. It also reduces operational overhead compared with exporting data to external inference services. Best practice is to use built-in Cortex SQL functions for managed model inference when the requirement is direct SQL-based generative AI inside Snowflake. Candidates should recognize that governance features like masking policies and extensibility mechanisms like UDFs serve different purposes and are not substitutes for the SQL AI interface.
- A. Correct.
Correct. Snowflake provides SQL-accessible Cortex AISQL functions that let teams invoke LLM capabilities directly from SQL. Using a SELECT statement with a function such as SNOWFLAKE.CORTEX.COMPLETE allows summarization to be performed inside Snowflake, which fits the requirement to integrate results with existing SQL reporting and avoid separate inference application code. The output can be materialized into a table, dynamic table, or exposed through a view depending on the pipeline design.
- B. Incorrect.
Incorrect. Standard SQL UDFs are not the intended mechanism for packaging and running full LLM model weights inside Snowflake. This reflects a common misconception that any custom AI workload should be embedded in a UDF. For SnowPro Gen AI scenarios, Snowflake's supported SQL interface for managed LLM inference is through Cortex AISQL functions rather than attempting to host an LLM manually in a conventional UDF.
- C. Incorrect.
Incorrect. This option describes an external orchestration pattern, but the scenario explicitly asks for a SQL-based approach inside Snowflake and to avoid maintaining external application code for inference. Snowflake SQL can directly invoke managed AI capabilities through Cortex functions, so exporting data to an outside REST service is unnecessary for this use case.
- D. Incorrect.
Incorrect. Masking policies are for data protection and conditional obfuscation, not for performing generative summarization as part of analytical workflows. Someone might choose this because policies execute during query processing, but their purpose is governance, not LLM-driven text generation or prompt execution.