SnowPro Specialty: Gen AI Question 228
Single answerTRY_COMPLETE (SNOWFLAKE.CORTEX)A support analytics team built a SQL pipeline that uses SNOWFLAKE.CORTEX.TRY_COMPLETE to generate short summaries of customer tickets stored in a table. During testing, some rows contain malformed prompts or unsupported model values, and the team notices that a few records cause generation failures. They want the nightly batch job to continue processing all rows without aborting the SQL statement when an individual generation attempt fails. Which approach best meets this requirement?
- A
Use SNOWFLAKE.CORTEX.TRY_COMPLETE instead of COMPLETE so failed generations return NULL rather than raising an error for the statement.
- B
Wrap SNOWFLAKE.CORTEX.COMPLETE in a JavaScript stored procedure because COMPLETE automatically retries invalid rows until they succeed.
- C
Replace TRY_COMPLETE with AI_COMPLETE because AI_COMPLETE ignores invalid model names and returns the closest supported model output.
- D
Use TRY_COMPLETE only inside Snowpark Python, because in SQL it behaves the same as COMPLETE and still aborts the query on generation errors.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use SNOWFLAKE.CORTEX.TRY_COMPLETE when a workload must tolerate per-row failures during generation. In Snowflake Cortex, COMPLETE raises an error when the request fails, which can stop the SQL statement. TRY_COMPLETE is the safer choice for production batch pipelines that should keep processing even when some prompts, parameters, or model references are invalid. A common best practice is to combine TRY_COMPLETE with downstream NULL checks so failed rows can be logged, filtered, or reprocessed later. This pattern aligns with Snowflake's TRY_ family design philosophy: preserve execution by returning NULL instead of throwing an exception in failure cases.
- A. Correct.
Correct. TRY_COMPLETE is designed for error-tolerant generation scenarios. Compared with COMPLETE, it returns NULL when the generation call fails instead of causing the entire SQL statement to error. This is useful for batch processing where some rows may be bad but the overall query should continue.
- B. Incorrect.
Incorrect. COMPLETE does not automatically retry malformed requests until they succeed, and wrapping it in a stored procedure does not change its core error behavior. If COMPLETE encounters an error, that failure can still interrupt processing unless explicitly handled. The scenario specifically calls for row-level tolerance, which is what TRY_COMPLETE provides.
- C. Incorrect.
Incorrect. This describes behavior that does not exist. AI_COMPLETE is not a mechanism for silently correcting invalid model names and returning output from a 'closest' supported model. Relying on automatic model substitution would be unsafe and is not the intended error-handling pattern for Cortex completion functions.
- D. Incorrect.
Incorrect. TRY_COMPLETE is available for SQL usage and its purpose is specifically different from COMPLETE. It does not behave the same as COMPLETE in SQL. The key distinction is that TRY_COMPLETE returns NULL on failure instead of raising an error for that generation call.