SnowPro Specialty: Gen AI Question 172
Single answerInvoke Cortex functions within the application code (for example, Streamlit)A team is building a Streamlit in Snowflake app that lets support analysts summarize long case notes stored in a Snowflake table. The developers want the app to call a Snowflake Cortex LLM from the application code when a user selects a case, and they want to avoid moving data out of Snowflake unnecessarily. Which implementation is the best fit for this requirement?
- A
In the Streamlit app, open a Snowpark session and execute a SQL statement such as SELECT SNOWFLAKE.CORTEX.COMPLETE('snowflake-arctic', CONCAT('Summarize this case: ', case_notes)) against the selected row.
- B
Export the case notes from Snowflake to an external Python service, call a third-party LLM there, and write the summary back to Snowflake because Cortex functions cannot be invoked from Streamlit code.
- C
Create a materialized view that automatically stores the result of SNOWFLAKE.CORTEX.COMPLETE for every row, then have Streamlit read from that view whenever a user opens a case.
- D
Use Streamlit to call SNOWFLAKE.CORTEX.COMPLETE directly from the browser with JavaScript so the user can invoke the model without requiring a Snowflake session.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to invoke a Cortex function from the Streamlit application's Python code by using the Snowpark session to run SQL such as SNOWFLAKE.CORTEX.COMPLETE. This is the practical pattern when building interactive applications in Streamlit in Snowflake: user input is handled in the app, and inference is executed inside Snowflake. It minimizes data movement, simplifies security, and uses built-in Cortex AISQL capabilities as intended. Snowflake documentation for Cortex AISQL and Streamlit in Snowflake shows that applications can execute SQL through the active session, making it possible to call functions like COMPLETE from application code rather than requiring an external service.
- A. Correct.
Correct. In a Streamlit in Snowflake application, developers can use the Snowpark session available to the app and execute SQL that invokes Snowflake Cortex AISQL functions such as SNOWFLAKE.CORTEX.COMPLETE. This keeps the data and model invocation inside Snowflake, which aligns with the requirement to avoid unnecessary data movement. It is also a realistic implementation pattern for application code that responds to user interaction.
- B. Incorrect.
Incorrect. This option introduces unnecessary data egress and external orchestration, which conflicts with the stated requirement. It is based on the misconception that Cortex functions are unavailable from application code. In practice, Streamlit in Snowflake can use a Snowpark session to execute SQL statements that call Cortex functions within Snowflake.
- C. Incorrect.
Incorrect. A materialized view is not an appropriate mechanism for this use case. Cortex COMPLETE is intended for on-demand generative inference, and materialized views are designed for deterministic query results that Snowflake can maintain automatically. This option also computes summaries for every row whether or not a user requests them, which is inefficient for interactive applications.
- D. Incorrect.
Incorrect. Streamlit apps in Snowflake do not bypass Snowflake authentication and execution by calling Cortex directly from client-side browser JavaScript. The supported pattern is to invoke Cortex through Snowflake-executed code, typically via SQL issued from the Streamlit app's Python code using the Snowpark session. This distractor reflects a common misunderstanding between client-side UI code and server-side execution in Streamlit in Snowflake.