SnowPro Specialty: Gen AI Question 185
Single answerExtracting data from text using COMPLETEA retail company stores customer support emails in a Snowflake table and wants to extract three fields from each email body using SQL: order_id, customer_sentiment, and refund_requested. The team is using the COMPLETE function with a Cortex-supported model. They need the output to be reliable for downstream SQL processing and as easy as possible to parse into columns. Which approach is the BEST choice?
- A
Use COMPLETE with a prompt that asks the model to respond in natural language, then split the text with string functions to derive the three fields.
- B
Use COMPLETE with a prompt that explicitly instructs the model to return only a valid JSON object with fixed keys such as order_id, customer_sentiment, and refund_requested, then parse the JSON in SQL.
- C
Use COMPLETE without any extraction instructions and rely on the model to infer which entities are important, because supported models automatically standardize outputs for SQL use cases.
- D
Use COMPLETE to summarize each email first, store the summary, and then use the summary text as the extracted structured result for analytics.
Show answer and explanation
Correct answer: B
Explanation
When using COMPLETE to extract data from text, the most practical pattern is to design the prompt for structured output, typically JSON with stable keys and constrained values. This reduces ambiguity and improves downstream SQL processing compared with natural-language output. In Snowflake Cortex workflows, COMPLETE is often used for prompt-based extraction, but reliability depends heavily on clear instructions such as returning only JSON, naming required fields explicitly, and avoiding extra commentary. This reflects common LLM best practices and Snowflake guidance for operationalizing model output in SQL-based pipelines.
- A. Incorrect.
This is not the best approach for reliable extraction. While COMPLETE can produce useful free-form text, natural-language responses are harder to parse consistently with SQL string functions because wording, order, punctuation, and formatting can vary between rows. This creates brittle downstream logic and is a common mistake when using LLMs for structured extraction tasks.
- B. Correct.
This is the best choice. For extracting data from unstructured text with COMPLETE, prompt engineering should constrain the response format as much as possible. Asking for a valid JSON object with fixed keys makes the output more suitable for downstream processing, since Snowflake SQL can parse JSON and extract named fields more reliably than parsing free-form prose. This aligns with best practices for using LLMs for structured outputs from text.
- C. Incorrect.
This is incorrect because COMPLETE does not automatically infer and return standardized structured fields suitable for SQL analytics unless you instruct it to do so. Without explicit extraction guidance and output constraints, results may be inconsistent and difficult to operationalize. The misconception here is assuming the model will behave like a deterministic parser by default.
- D. Incorrect.
This is incorrect because summarization is a different task from structured extraction. A summary may omit, paraphrase, or generalize details needed for analytics, such as the exact order_id or a clear Boolean-style refund_requested field. Someone might choose this option because summaries are easier to read, but readability does not equal extractability or schema consistency.