SnowPro Specialty: Gen AI Question 246
Single answerError conditionsA data engineering team is building a support-ticket summarization pipeline in Snowflake using Cortex AISQL functions. During load testing, some rows fail because the input text exceeds the model's token limit, while other rows fail intermittently due to temporary service-side issues. The team wants the pipeline to continue processing successful rows, identify the specific failure reason for each unsuccessful row, and avoid treating all failures as the same type of problem. Which approach best meets these requirements?
- A
Wrap the Cortex function call in TRY_COMPLETE so that any failure returns NULL, then treat all NULL results as transient errors and retry them later.
- B
Execute the Cortex function directly in a SQL statement, capture the returned error message and code for failed rows, and branch handling logic so token-limit errors are corrected by reducing input size while transient service errors are retried.
- C
Preprocess all input by truncating every ticket to a fixed small length before calling the model, because token-limit errors and transient service errors cannot be distinguished at runtime.
- D
Run the Cortex function in a separate warehouse size for oversized inputs and a larger warehouse for transient failures, because most Cortex errors are caused by insufficient virtual warehouse resources.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to preserve and inspect the actual error returned for each failed request, then apply remediation based on the error category. In real Snowflake GenAI workflows, oversized prompts or inputs must typically be reduced, truncated more carefully, or chunked before resubmission, while transient service-side failures may be retried with backoff. A robust production pipeline should not collapse all failures into a single NULL or generic status because that hides operationally important differences. This reflects a core best practice for error conditions in AI pipelines: classify errors, retry only when appropriate, and fix deterministic request-construction issues such as token limits at the source. Refer to Snowflake Cortex AISQL function documentation and Snowflake best practices for handling function errors and designing resilient data pipelines.
- A. Incorrect.
Incorrect. Converting all failures to NULL removes the distinction between different error conditions. The scenario explicitly requires identifying why each row failed and handling token-limit issues differently from transient service issues. Treating every NULL as transient would cause unnecessary retries for requests that need input reduction instead.
- B. Correct.
Correct. This approach preserves error details and supports differentiated remediation. Oversized-input errors should be handled by reducing or chunking the input, while intermittent service-side failures are better candidates for retry logic. This aligns with practical error handling for GenAI workloads: inspect the specific error condition rather than applying one generic fallback to every failure.
- C. Incorrect.
Incorrect. Although truncation can reduce token-limit failures, applying aggressive truncation to all rows can unnecessarily degrade output quality and does not address intermittent service-side failures. The key misconception is assuming all errors should be prevented with one preprocessing rule instead of using targeted handling based on the actual error returned.
- D. Incorrect.
Incorrect. Cortex model inference errors such as token-limit violations or temporary service issues are not generally solved by changing warehouse size. Virtual warehouses are relevant to SQL query execution, but model-specific request failures need to be addressed through request sizing, retry strategy, and error-aware application logic.