SnowPro Specialty: Gen AI Question 171
Single answerInvoke Cortex functions within the application code (for example, Streamlit)A team is building a Streamlit in Snowflake application that lets support analysts summarize long case notes and generate suggested replies. The developers want the app to invoke Snowflake Cortex functions directly from the Streamlit code while keeping the architecture simple and avoiding unnecessary data movement outside Snowflake. Which approach is the best fit for this requirement?
- A
From the Streamlit app, open a Snowpark session and execute SQL that calls a Cortex function such as SNOWFLAKE.CORTEX.COMPLETE or SUMMARIZE on the case-note text stored in Snowflake.
- B
Export the case notes from Snowflake to local Python memory, call a third-party LLM API directly from Streamlit, and write the generated response back to Snowflake.
- C
Create an external function for text generation because Cortex functions cannot be invoked from application code such as Streamlit.
- D
Use Streamlit only to collect user input, then require analysts to manually run Cortex SQL statements in Snowsight worksheets to get summaries and suggested replies.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to call Cortex functions from the Streamlit application through the Snowpark session by executing SQL in Snowflake. In Streamlit in Snowflake, developers commonly use the session object to run queries, including calls to Cortex SQL functions such as text generation and summarization functions. This keeps the workflow inside Snowflake, simplifies the architecture, and avoids exporting data to external services unless there is a specific business need. Snowflake documentation and examples for Cortex AI functions show that these capabilities are exposed through SQL and are therefore accessible from application code that can submit SQL, including Streamlit in Snowflake.
- A. Correct.
Correct. In Streamlit in Snowflake, the application can use the active Snowpark session to execute SQL statements that invoke Cortex functions. This is the practical pattern when you want application code to call Cortex directly while keeping data processing close to the data in Snowflake. It reduces unnecessary data movement and aligns with how Cortex SQL functions are intended to be consumed from app code.
- B. Incorrect.
Incorrect. Although technically an application could call an external API, this does not meet the stated goal of keeping the architecture simple and avoiding unnecessary data movement outside Snowflake. It also introduces additional operational, security, and governance concerns compared with invoking Cortex functions directly inside Snowflake.
- C. Incorrect.
Incorrect. This reflects a common misconception. Cortex functions are designed to be callable from SQL, and application code such as Streamlit can execute that SQL through the Snowpark session. An external function is not required just to access Cortex capabilities from a Streamlit app.
- D. Incorrect.
Incorrect. This approach breaks the application workflow and does not satisfy the requirement to invoke Cortex functions within the application code. It adds unnecessary manual steps and undermines the value of an integrated Streamlit application.