SnowPro Specialty: Gen AI Question 250
Single answerCortex SearchA retail company wants to build an internal support assistant that answers employee questions using product manuals stored in a Snowflake table. The team plans to use Cortex Search so the assistant can retrieve relevant passages before sending them to an LLM. The manuals table includes columns for MANUAL_TEXT, PRODUCT_LINE, REGION, and LAST_UPDATED. Security requirements state that support agents in Europe must only retrieve European content, and the team wants users to be able to filter results to a specific product line at query time. Which design is the most appropriate?
- A
Create a Cortex Search service over the manuals table, index MANUAL_TEXT as the searchable content, include PRODUCT_LINE and REGION as filter attributes, and enforce access through Snowflake role-based permissions and query-time filters.
- B
Create a standard view that selects MANUAL_TEXT and ask the LLM to scan the entire view directly, because Cortex Search does not support metadata-based filtering.
- C
Store each manual as a VARIANT document in a new table and use Snowpipe Streaming instead of Cortex Search, because filtering by REGION must be implemented outside Snowflake.
- D
Create a Cortex Search service using LAST_UPDATED as the searchable text column and MANUAL_TEXT as metadata, then rely on the LLM prompt to ignore results from the wrong region.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Cortex Search as the retrieval layer over the manuals table, with the main text content indexed for search and structured columns exposed for filtering. In a RAG pattern, retrieval should return only relevant passages before they are passed to the model. PRODUCT_LINE and REGION are natural filter attributes because users may want to constrain results by product line, and region-based data access should be enforced as part of the retrieval design rather than delegated to prompt instructions. This aligns with Snowflake best practices for Cortex Search: use it to search unstructured text stored in Snowflake, combine it with structured metadata for filtering, and rely on Snowflake governance and role-based access controls to protect data. The distractors reflect common mistakes: using the LLM as the primary retrieval engine, confusing ingestion services with retrieval services, and trusting prompts instead of enforcing data access controls in the platform.
- A. Correct.
Correct. Cortex Search is designed for retrieval over Snowflake data and supports searchable text plus structured attributes that can be used for filtering. In this scenario, MANUAL_TEXT should be the indexed/searchable content, while PRODUCT_LINE and REGION are appropriate metadata/filter columns. Using Snowflake access controls together with query-time filtering is the practical design for restricting retrieval and enabling product-line filtering in an internal assistant.
- B. Incorrect.
Incorrect. A common misconception is that an LLM alone can replace retrieval. Scanning an entire view with an LLM is inefficient, costly, and less reliable for retrieval-augmented generation. Cortex Search is specifically intended to retrieve relevant text from Snowflake data, and metadata/filtering is a key part of making search results precise and secure.
- C. Incorrect.
Incorrect. Snowpipe Streaming is for ingesting data, not for semantic retrieval. Reformatting manuals into VARIANT documents does not solve the retrieval problem and does not eliminate the need for a search service. The statement that REGION filtering must be implemented outside Snowflake is also incorrect; Snowflake supports governance and filtering patterns within the platform.
- D. Incorrect.
Incorrect. The searchable text should be the manual content, not a timestamp such as LAST_UPDATED. Putting MANUAL_TEXT into metadata would make retrieval ineffective. Relying on prompt instructions for regional restriction is also a poor security design because retrieval controls should be enforced before the LLM sees the content, not left to model behavior.