SnowPro Specialty: Gen AI Question 54
Single answerCortex SearchA retail company is building an internal support assistant on Snowflake. Agents need to ask natural-language questions such as "What is the return policy for refurbished laptops in Canada?" and receive grounded answers based only on the company's policy documents stored in a Snowflake table. The team wants to use Cortex Search so the application can retrieve the most relevant document chunks before sending them to an LLM for answer generation. Which approach best meets this requirement?
- A
Create a Cortex Search service on the table containing the policy text, then have the application query the service to retrieve relevant chunks for retrieval-augmented generation.
- B
Use a standard SQL VIEW over the policy table and rely on SELECT statements with ILIKE filters, because Cortex Search is only for structured column filtering rather than semantic retrieval.
- C
Store the documents in an internal stage and query the files directly with Cortex Complete, because Cortex Search cannot index text stored in Snowflake tables.
- D
Train a custom LLM inside Snowflake on the policy documents, because Cortex Search is intended only for web-scale internet search use cases.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to create and query a Cortex Search service over the company's policy content. In Snowflake Gen AI architectures, Cortex Search is used to retrieve relevant passages from enterprise data stored in Snowflake, which is then commonly combined with an LLM to implement retrieval-augmented generation (RAG). This approach helps ground responses in trusted internal content and reduces hallucinations compared with prompting an LLM without retrieval. Basic SQL string matching is usually insufficient for natural-language relevance, and custom model training is unnecessary for this use case. Snowflake documentation describes Cortex Search as a managed retrieval capability for building AI search and RAG applications on Snowflake data.
- A. Correct.
Correct. Cortex Search is designed to provide low-latency retrieval over Snowflake data for AI-powered search and RAG scenarios. A common pattern is to create a Cortex Search service over a table or query result containing the source text (often chunked documents plus metadata), then query that service at runtime to retrieve the most relevant passages and pass them to an LLM for grounded generation.
- B. Incorrect.
Incorrect. A VIEW with ILIKE filters provides keyword matching, not the semantic retrieval and ranking capabilities expected from Cortex Search. This option reflects a common misconception that basic SQL text filters are equivalent to AI retrieval. While SQL filtering can help with metadata constraints, it does not replace Cortex Search for natural-language relevance matching.
- C. Incorrect.
Incorrect. Cortex Search is specifically used to index searchable content from Snowflake data sources, including text stored in tables. This option confuses document storage with retrieval architecture. Although staged files may be part of an ingestion pipeline, querying files directly with Cortex Complete is not the standard way to build a grounded enterprise search experience.
- D. Incorrect.
Incorrect. The scenario requires retrieval over company documents, not model training. Cortex Search supports retrieval for enterprise data; it is not limited to internet-scale search. Training a custom LLM is also unnecessary and significantly more complex when the practical requirement is to retrieve relevant internal content and use it in a RAG workflow.