SnowPro Specialty: Gen AI Question 249
Single answerCortex SearchA retail company is building an internal support assistant on Snowflake. Product manuals, warranty policies, and troubleshooting guides are stored in a Snowflake table and updated daily. The assistant must answer questions using only approved documents, return the most relevant passages quickly, and respect existing role-based access controls so regional support teams only see documents they are authorized to access. Which approach is the MOST appropriate when implementing Cortex Search for this use case?
- A
Create a Cortex Search service on the documents table or a prepared query, and apply Snowflake role-based access controls so queries only return content the caller is authorized to see.
- B
Export the documents to an external vector database because Cortex Search cannot work directly with Snowflake tables that are updated regularly.
- C
Use only SQL text filters with ILIKE on the documents table, because Cortex Search is designed only for structured numeric lookups rather than semantic retrieval.
- D
Precompute embeddings manually for every document and build a custom UDF-based retrieval layer, because Cortex Search does not manage indexing or retrieval for enterprise search scenarios.
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because Cortex Search is the Snowflake-native retrieval capability for building AI search and RAG-style applications over data stored in Snowflake. It is appropriate when an organization needs relevant, low-latency retrieval from unstructured or semi-structured content while preserving Snowflake governance. In practice, teams commonly define a source table or query that contains the text to be searched and any metadata needed for filtering or authorization. Keeping the workflow inside Snowflake aligns with platform best practices around security, governance, and reduced data movement. By contrast, exporting to an external vector store or replacing semantic retrieval with simple ILIKE filters introduces unnecessary complexity or weaker retrieval quality. This aligns with Snowflake documentation and product guidance describing Cortex Search as a managed retrieval service for AI applications built on Snowflake data.
- A. Correct.
Correct. Cortex Search is designed for low-latency hybrid retrieval over data stored in Snowflake. A Cortex Search service can be created from a table or query result, making it suitable for document collections such as manuals and policies that are refreshed over time. Because the data remains in Snowflake, existing governance and role-based access controls can be applied so users only retrieve documents they are permitted to access. This directly matches the scenario's requirements for relevance, speed, and security.
- B. Incorrect.
Incorrect. This is a common misconception from teams familiar with external RAG architectures. Cortex Search is specifically intended to provide retrieval over Snowflake data, so exporting to an external vector database is not required for this use case. Moving data out would also add operational complexity and potentially weaken governance compared with keeping retrieval inside Snowflake.
- C. Incorrect.
Incorrect. ILIKE-based filtering can help with exact keyword matching, but it is not an appropriate replacement for Cortex Search when the goal is to retrieve the most relevant passages from natural-language questions. Cortex Search is built for search and retrieval scenarios, including semantic relevance, whereas plain SQL string matching would likely miss conceptually relevant results and provide a poorer user experience.
- D. Incorrect.
Incorrect. Cortex Search is intended to simplify enterprise retrieval without requiring customers to hand-build the full embedding, indexing, and ranking pipeline. While custom pipelines are possible in Snowflake, they are not the most appropriate answer here because the requirement is to implement a practical, governed search service quickly over Snowflake data.