SnowPro Specialty: Gen AI Question 8
Single answerCortex SearchA retail company is building an internal support assistant in Snowflake. The assistant must answer employee questions using the latest product manuals stored in a Snowflake table, and each answer should cite the exact manual section used. The team wants to avoid building and maintaining its own vector pipeline. Which approach best meets these requirements with Cortex Search?
- A
Create a Cortex Search service on the table containing the manual text and include columns such as document title and section as attributes to return with search results for grounding and citations.
- B
Use AI_COMPLETE directly on the manuals table and rely on the model to infer the most relevant passages without a search index.
- C
Export the manuals from Snowflake to an external vector database, generate embeddings outside Snowflake, and return only the final answer to the assistant.
- D
Create a dynamic table that stores one row per manual and query it with SQL LIKE predicates before sending matching rows to the model.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Cortex Search as the retrieval layer over the manuals stored in Snowflake. Cortex Search is intended for RAG-style applications where relevant chunks or rows must be retrieved from Snowflake data and returned with metadata that can be used for grounding and citations. This is especially useful when the organization wants to keep data in Snowflake and avoid managing a separate embedding and indexing stack. In practice, teams define a Cortex Search service over the source data and include useful attributes, such as document identifiers or section labels, so the application can display source references with the generated answer. This follows Snowflake best practices for building grounded GenAI assistants: use retrieval to supply relevant context, then pass that context to generation rather than relying on the model alone.
- A. Correct.
Correct. Cortex Search is designed for retrieval over Snowflake data and handles the underlying search index so teams do not need to build and operate a separate vector pipeline. By defining the service over the manuals data and returning attributes such as document title, section name, or URL, the application can ground responses and present citations alongside retrieved passages. This aligns directly with the scenario's requirements for fresh content, retrieval, and source attribution.
- B. Incorrect.
Incorrect. AI_COMPLETE can generate answers, but by itself it is not a retrieval system over enterprise documents. Relying only on the model without retrieval increases the risk of hallucinations and does not provide a robust way to fetch the latest relevant manual sections or return precise citations. A common misconception is assuming generation alone replaces retrieval.
- C. Incorrect.
Incorrect. While an external vector database could be used in some architectures, the scenario explicitly wants to avoid building and maintaining a custom vector pipeline. Moving data out of Snowflake and managing external embeddings adds operational complexity and is unnecessary when Cortex Search provides managed retrieval directly on Snowflake data.
- D. Incorrect.
Incorrect. SQL LIKE can support simple keyword matching, but it is not the best fit for a support assistant that needs high-quality semantic retrieval across manuals. It also places the burden on the team to engineer brittle text-matching logic. Another common misconception is treating traditional pattern matching as equivalent to modern retrieval for RAG use cases.