SnowPro Specialty: Gen AI Question 156
Single answerIntegration with Cortex SearchA retail company is building a customer-support assistant in Snowflake. They want the assistant to answer questions using only approved product manuals and warranty documents stored in Snowflake, and they need low-latency retrieval to ground LLM responses. The engineering team wants to avoid building and operating their own vector database pipeline. Which approach best meets these requirements when integrating with Cortex Search?
- A
Create a Cortex Search service over the approved document data and have the application query that service to retrieve relevant passages for grounding before calling the LLM
- B
Use SNOWFLAKE.CORTEX.COMPLETE directly on the raw document table and rely on the model to infer which rows are relevant without a search layer
- C
Export embeddings from Snowflake to an external vector database, because Cortex Search requires third-party vector storage for semantic retrieval
- D
Store the documents in an internal stage and query the stage directly from the application, because Cortex Search only works with structured transactional tables
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Cortex Search as the retrieval layer for a grounded assistant. In Snowflake, Cortex Search is intended to support low-latency search over enterprise data for AI applications such as retrieval-augmented generation (RAG). This makes it a strong fit when a team wants relevant passages returned from approved content before invoking an LLM. In contrast, using COMPLETE alone skips retrieval and increases hallucination risk because the model is not explicitly grounded in the most relevant source material. Exporting data to an external vector database adds operational complexity that the scenario explicitly wants to avoid. Best practice for enterprise GenAI in Snowflake is to separate retrieval from generation: use Cortex Search to find relevant context, then use an LLM to synthesize an answer constrained by that context.
- A. Correct.
Correct. Cortex Search is designed to provide low-latency retrieval over Snowflake data for AI search and RAG-style applications. In this scenario, creating a Cortex Search service on the approved manuals and warranty content lets the application retrieve the most relevant passages first, then pass those grounded results to an LLM for answer generation. This aligns with the requirement to keep data in Snowflake and avoid operating a separate vector database pipeline.
- B. Incorrect.
Incorrect. SNOWFLAKE.CORTEX.COMPLETE is for model inference, not document retrieval. Sending raw document tables directly to a completion model does not provide an efficient or reliable retrieval mechanism, especially at scale. A common misconception is that an LLM alone can replace search, but for grounded enterprise Q&A, retrieval should identify relevant context before generation.
- C. Incorrect.
Incorrect. Cortex Search does not require customers to export embeddings to a third-party vector database in order to perform semantic retrieval. This option reflects a common architecture pattern outside Snowflake, but it conflicts with the stated requirement to avoid building and operating an external vector pipeline.
- D. Incorrect.
Incorrect. While documents may originate from files and stages, querying a stage directly is not how Cortex Search is typically integrated for semantic retrieval. Cortex Search is built on Snowflake data objects prepared for search access. The claim that Cortex Search only works with structured transactional tables is also incorrect; it is intended for searching indexed content used in AI applications.