SnowPro Specialty: Gen AI Question 7
Single answerCortex SearchA retail company wants to build an internal support assistant that answers employee questions using thousands of product manuals stored in a Snowflake table. The team needs low-latency retrieval over the manual text and wants search results to include structured metadata such as product_line, region, and last_updated so the application can filter or rank results before sending them to an LLM. Which approach should the team use with Cortex Search to best meet these requirements?
- A
Create a Cortex Search service on the manuals table, define the manual text as the searchable content, and include product_line, region, and last_updated as attributes returned with search results
- B
Create a dynamic table that generates embeddings for each manual chunk, then query the dynamic table directly with SQL similarity calculations because Cortex Search cannot return metadata fields
- C
Use Cortex Complete directly on the manuals table and rely on prompt instructions to search all records at inference time, because Cortex Search is only for exact keyword lookups
- D
Store the manuals in an external stage and use Snowflake file metadata for filtering, because Cortex Search cannot index data stored in Snowflake tables
Show answer and explanation
Correct answer: A
Explanation
The best answer is to create a Cortex Search service over the manuals stored in Snowflake and configure it so the text content is searchable while business metadata is returned as attributes. This aligns with the typical retrieval-augmented generation pattern: use Cortex Search for fast retrieval, then pass the most relevant passages plus metadata into an LLM such as Cortex Complete. A key practical benefit of Cortex Search is that it can return structured attributes with each result, enabling application-side filtering, personalization, or ranking. By contrast, using an LLM alone for retrieval is not a best practice, and building a custom similarity search pipeline is unnecessary when Cortex Search already provides managed retrieval for Snowflake data. See Snowflake documentation for Cortex Search service concepts, including searchable text, returned attributes, and its use in RAG applications.
- A. Correct.
Correct. Cortex Search is designed for low-latency retrieval over Snowflake data and supports returning attributes alongside matching results. In this scenario, the manual text should be indexed as the searchable content, while fields such as product_line, region, and last_updated can be exposed as attributes for downstream filtering, ranking, or prompt construction in a RAG workflow.
- B. Incorrect.
Incorrect. While teams can build custom embedding pipelines, this option is wrong because it claims Cortex Search cannot return metadata fields. Cortex Search services are specifically intended to return relevant results together with selected attributes. Choosing this reflects a common misconception that search output is limited to only the matched text.
- C. Incorrect.
Incorrect. Cortex Complete is for text generation, not document retrieval. Prompting an LLM to search a large table at inference time is not an efficient or reliable replacement for a retrieval layer. This option also incorrectly characterizes Cortex Search as only supporting exact keyword lookups; Cortex Search is intended for semantic and lexical retrieval use cases in enterprise search and RAG scenarios.
- D. Incorrect.
Incorrect. Cortex Search operates on data in Snowflake tables and views, so there is no requirement to move manuals to an external stage. File metadata from staged files is also not a substitute for indexing document content and returning business-specific attributes from a search service.