SnowPro Specialty: Gen AI Question 155
Single answerIntegration with Cortex SearchA retail company is building an internal support assistant in Snowflake to answer employee questions using product manuals, warranty policies, and troubleshooting guides stored in a table. The team wants to use Cortex Search so the application can retrieve the most relevant passages and pass them to an LLM for grounded responses. They also want search results to stay current as source data changes and to restrict results by product line based on the signed-in user's context. Which approach best meets these requirements?
- A
Create a Cortex Search service on the source table, specify the text column to index, include product line as an attribute/filter column, and query the service from the application with a filter based on the user's allowed product lines.
- B
Create a dynamic table that summarizes the manuals into one row per product, and have the application call COMPLETE directly on that table without using retrieval, because Cortex Search is only for exact keyword matching.
- C
Export the documents to an external vector database, because Cortex Search does not support keeping search results in sync with changes to Snowflake tables.
- D
Store the documents in a standard table and query them with ILIKE predicates at runtime, because Cortex Search services cannot apply metadata-based filtering such as product line restrictions.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to create and use a Cortex Search service directly on the support-content dataset, model the searchable text appropriately, and include business metadata such as product line as filterable attributes. This aligns with a standard Snowflake RAG pattern: store content in Snowflake, use Cortex Search for retrieval, and pass retrieved context to an LLM for answer generation. Compared with ad hoc SQL text matching or skipping retrieval entirely, Cortex Search improves relevance and supports operational requirements such as freshness and scoped retrieval. In Snowflake best practices, metadata columns are important for narrowing search results to the right subset of content, and retrieval should be combined with generation when the goal is accurate, grounded answers from enterprise documents.
- A. Correct.
Correct. Cortex Search is designed for retrieval over Snowflake data and can be used to power RAG-style applications. A search service is created over a source query/table, with one or more text columns used for retrieval and optional attribute columns for filtering. Using product line as a filterable attribute lets the application enforce context-based restrictions at query time. Cortex Search is also intended to stay updated as underlying source data changes, which fits the requirement for current results.
- B. Incorrect.
Incorrect. This option reflects a common misconception that generation alone is sufficient. Calling COMPLETE directly on summarized rows removes the retrieval step needed for grounded answers and typically reduces answer quality for detailed support content. It is also wrong to describe Cortex Search as only exact keyword matching; it is built for semantic/hybrid retrieval scenarios rather than simple string search.
- C. Incorrect.
Incorrect. While external vector databases are sometimes used in other architectures, they are not required here. Cortex Search is specifically intended to provide retrieval natively within Snowflake over Snowflake-managed data. The statement that it cannot stay synchronized with source table changes is inaccurate and contradicts the intended managed-service behavior.
- D. Incorrect.
Incorrect. ILIKE-based scanning is a poor fit for semantic retrieval across manuals and guides, especially at scale. It also misses the benefit of purpose-built retrieval ranking. The claim that Cortex Search cannot apply metadata filters is false; filtering by attributes such as product line is a standard reason to model metadata in the search service.