SnowPro Specialty: Gen AI Question 188
Single answerTranscriptsA support organization stores call-center transcripts in Snowflake and wants to build a GenAI workflow that summarizes each conversation and flags calls where a customer threatened to cancel service. The transcripts are long, contain speaker turns, and sometimes include sensitive personal information. The team wants the simplest approach that stays inside Snowflake as much as possible and can be applied in SQL over many transcript rows. Which approach is the best fit?
- A
Store each transcript as text in a Snowflake table, optionally pre-process or redact sensitive content with SQL, and use AI_COMPLETE in SQL prompts to generate summaries and cancellation-risk classifications per transcript.
- B
Convert every transcript into a Snowflake stage file and use Cortex Search as the primary summarization engine, because Cortex Search is designed to generate abstractive summaries directly from raw transcript files.
- C
Load the transcripts into a vector column and use similarity scoring alone to determine whether a customer threatened cancellation, because embeddings replace the need for LLM-based classification.
- D
Export transcript data to an external LLM service first, because Snowflake SQL functions cannot work directly with transcript text stored in table rows.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to keep transcripts in Snowflake tables and use SQL-native GenAI functions for summarization and classification. This is the simplest and most operationally practical design when the source data is already tabular or can be loaded into rows. In real implementations, teams often first clean or redact transcript content, preserve useful structure such as speaker turns, and then call an LLM through AI_COMPLETE with a prompt that asks for both a concise summary and a structured classification outcome. This aligns with Snowflake best practices of bringing AI to the data, minimizing unnecessary data movement, and using Cortex AISQL functions for scalable inference in SQL. Cortex Search is valuable when retrieval over a corpus is required, but it is not itself the summarization model. Embeddings are also valuable for semantic search and clustering, but they do not replace LLM-based summarization or nuanced transcript classification.
- A. Correct.
Correct. For transcript-centric workflows, a practical pattern is to store transcript text in Snowflake tables and apply SQL-based processing at scale. Sensitive text can be masked, redacted, or otherwise transformed before inference, and Cortex AISQL functions such as AI_COMPLETE can be used to summarize content or classify whether a cancellation threat appears in the transcript. This approach matches the requirement to stay inside Snowflake and operate across many rows using SQL.
- B. Incorrect.
Incorrect. Cortex Search is intended for retrieval over indexed content, not as the primary engine for direct abstractive summarization of raw transcript files. It can support RAG-style applications by finding relevant chunks, but the actual summary generation is performed by an LLM function, not by Cortex Search alone. Also, simply placing files in a stage does not make that the best transcript-processing pattern for row-wise summarization.
- C. Incorrect.
Incorrect. Embeddings and similarity search are useful for semantic retrieval and finding related content, but they do not by themselves perform reliable instruction-following classification such as determining whether a caller threatened to cancel service. That task is better handled with an LLM prompt or a purpose-built classification workflow. This option reflects the common misconception that embeddings can replace all downstream reasoning tasks.
- D. Incorrect.
Incorrect. Snowflake can operate directly on transcript text stored in tables using SQL and Cortex AISQL functions. There is no requirement to export transcript data to an external LLM service first. In fact, keeping the workflow in Snowflake is often preferable for governance, security, and operational simplicity.