SnowPro Specialty: Gen AI Question 107
Single answerEMBED_TEXT_768A retail company stores millions of product descriptions in Snowflake and wants to build semantic search entirely in SQL. An engineer plans to generate embeddings with EMBED_TEXT_768 and compare them with a user query embedding to return the most similar products. Which approach is the most appropriate for implementing this in Snowflake?
- A
Generate a 768-dimension embedding for each product description with EMBED_TEXT_768, generate another embedding for the user's query with the same function, and rank rows by vector similarity between the stored and query embeddings.
- B
Use EMBED_TEXT_768 on the product descriptions, but compare the resulting vectors to the raw query text directly because Snowflake automatically converts the query string during comparison.
- C
Use EMBED_TEXT_768 for product descriptions and EMBED_TEXT_1024 for the user query, then compare them because larger query embeddings improve semantic search accuracy even when dimensions differ.
- D
Skip embedding the product descriptions and instead apply EMBED_TEXT_768 only to the query at runtime, then use LIKE against the description column because embedding only the query is sufficient for semantic retrieval.
Show answer and explanation
Correct answer: A
Explanation
The correct design for semantic search with EMBED_TEXT_768 is to embed both the documents and the user query using the same embedding function so they live in the same vector space. In Snowflake, EMBED_TEXT_768 produces a 768-dimension vector representation suitable for downstream similarity search. Best practice is to precompute embeddings for relatively static text such as product descriptions, store them, and compute the query embedding at runtime before ranking by vector similarity. This reduces repeated computation and supports practical retrieval-augmented patterns. Key principles reflected in Snowflake documentation and GenAI best practices are: use the same embedding function for both corpus and query, ensure vector dimensions match, and use vector similarity rather than string matching for semantic retrieval.
- A. Correct.
Correct. Semantic search with EMBED_TEXT_768 requires both the source text and the query text to be represented in the same embedding space and dimensionality. A practical pattern is to precompute and store embeddings for product descriptions, generate an embedding for the incoming query, and then use a vector similarity calculation to rank the closest matches. This is the standard retrieval workflow for embeddings in Snowflake-based GenAI solutions.
- B. Incorrect.
Incorrect. Snowflake does not automatically transform raw text into a compatible embedding during vector comparison. The query must be embedded explicitly with the same embedding function or model family used for the stored content. Comparing a vector to a plain string is a category error and reflects a misunderstanding of how semantic search works.
- C. Incorrect.
Incorrect. Embeddings must be compatible for similarity comparison. If one side is a 768-dimension vector and the other is a 1024-dimension vector, they cannot be compared meaningfully in the same vector similarity operation. The misconception here is that higher dimensionality is inherently better regardless of compatibility; in practice, matching embedding model and dimension is essential.
- D. Incorrect.
Incorrect. Embedding only the query and then relying on LIKE against raw text would produce keyword-style matching, not semantic retrieval across the product catalog. LIKE does not use vector meaning and would miss semantically similar descriptions that do not share the same wording. For scalable semantic search, the corpus should also be embedded.