SnowPro Specialty: Gen AI Question 53
Single answerCortex SearchA support engineering team wants to build a RAG-style assistant over internal troubleshooting articles stored in a Snowflake table. They need a managed search service that returns the most relevant text passages for a user query, supports filtering results to a specific product line, and can be called from an application at query time. They want to minimize custom infrastructure and avoid building their own vector index pipeline. Which approach best meets these requirements?
- A
Create a Cortex Search service on the troubleshooting content, define the searchable text and filter attributes, and query the service from the application to retrieve relevant results.
- B
Create a standard view over the articles table and use SQL LIKE predicates from the application for retrieval, because Cortex Search is only intended for structured data lookups.
- C
Generate embeddings with Cortex functions, store them in a table, and rely on Dynamic Tables alone to serve low-latency semantic search directly to the application without a search service.
- D
Use Snowpipe Streaming to continuously ingest articles and assume this provides semantic retrieval and metadata filtering without any additional search configuration.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Cortex Search as the managed retrieval layer. In real-world GenAI applications, Cortex Search is intended to simplify retrieval over enterprise text stored in Snowflake, making it well-suited for RAG scenarios where an application must fetch relevant passages at query time. A key practical benefit is reducing custom infrastructure compared with hand-building an embeddings pipeline, similarity search logic, and serving API. Filtering by metadata such as product line is also a common requirement in enterprise search workflows and aligns with Cortex Search design patterns. By contrast, SQL LIKE is too limited for high-quality retrieval, Dynamic Tables are orchestration/maintenance tools rather than a semantic search endpoint, and Snowpipe Streaming is an ingestion technology rather than a retrieval solution. Candidates should recognize when a managed search service is preferable to assembling multiple lower-level components for a production GenAI application.
- A. Correct.
Correct. Cortex Search is designed as a managed retrieval service for relevant text search over Snowflake data and is a strong fit for RAG-style applications. It supports defining the indexed/searchable content and returning relevant results at query time, and it can include filterable attributes for scenarios such as restricting results by product line. This matches the requirement to minimize custom infrastructure and avoid building and operating a separate vector indexing pipeline.
- B. Incorrect.
Incorrect. A view plus SQL LIKE can support basic keyword matching, but it does not provide the managed semantic-style retrieval experience expected for a modern RAG application. The statement that Cortex Search is only for structured data lookups is also false. Cortex Search is specifically intended to help retrieve relevant unstructured text content stored in Snowflake for AI applications.
- C. Incorrect.
Incorrect. Generating embeddings and storing them in tables is part of a custom retrieval architecture, but Dynamic Tables do not themselves provide an end-user semantic search service. You would still need to design and operate the retrieval logic, similarity search pattern, and serving layer. This option conflicts with the requirement to avoid building a custom index pipeline and to use a managed service callable from the application.
- D. Incorrect.
Incorrect. Snowpipe Streaming addresses ingestion latency for incoming data, not semantic retrieval. While it may help keep source data fresh, it does not create a search experience or replace the need to configure a retrieval service. Metadata filtering and relevance ranking still require an appropriate search layer such as Cortex Search.