SnowPro Specialty: Gen AI Question 149
Single answerStructured dataA retail company stores structured customer and order data in Snowflake tables and wants to build a GenAI-powered support assistant. The assistant should answer questions such as, "Which enterprise customers in the Northeast had more than 5 delayed shipments last quarter?" The team wants responses grounded in current warehouse data and needs deterministic filtering, aggregation, and join logic rather than semantic similarity over unstructured text. Which approach is the most appropriate?
- A
Convert the table rows to text documents, create embeddings for each row, and rely only on vector similarity search to answer the question
- B
Use an LLM to generate SQL against the structured Snowflake tables, then execute the SQL and provide the results back to the model for response generation
- C
Export the Snowflake tables to external object storage and fine-tune a model so it memorizes the current customer and shipment data
- D
Use a document AI pipeline to OCR the tables into text and send the extracted text directly to the model without querying Snowflake
Show answer and explanation
Correct answer: B
Explanation
For structured data use cases, best practice is to query the source tables directly rather than forcing the problem into an unstructured retrieval pattern. In Snowflake-based GenAI architectures, this commonly means translating a user question into SQL, validating or governing that SQL as needed, executing it against Snowflake tables, and then using the result set to generate a natural-language answer. This approach is well aligned with workloads that depend on exact predicates, joins, aggregations, and up-to-date enterprise data. By contrast, vector search is most useful for semantic retrieval over text, while OCR/document pipelines are intended for extracting information from unstructured documents. Fine-tuning is also not a substitute for querying live structured data because it does not provide deterministic access to current records. These patterns align with Snowflake guidance to use SQL and governed data access for structured analytics workloads, while reserving retrieval and document-processing techniques for unstructured content.
- A. Incorrect.
This is not the best approach for structured data questions that require exact filters, joins, grouping, and counts. Embeddings and vector similarity are better suited for semantic retrieval over unstructured or semi-structured content, not for deterministic analytical queries such as counting delayed shipments by region and customer segment.
- B. Correct.
This is correct. For structured data in Snowflake, the most appropriate pattern is to use the LLM for natural-language-to-SQL generation, execute the SQL on the underlying tables, and use the query result to formulate the final answer. This keeps answers grounded in current data and leverages SQL for precise relational logic, filtering, joins, and aggregation.
- C. Incorrect.
This is incorrect because fine-tuning is not an appropriate mechanism for keeping answers aligned to frequently changing operational data. A fine-tuned model would quickly become stale, and memorizing enterprise data into model weights is generally poor practice for governed analytics use cases where current, queryable data is required.
- D. Incorrect.
This is incorrect because OCR and document extraction are intended for unstructured documents like PDFs or images, not for data that already exists as structured Snowflake tables. Converting structured tables into text through OCR adds unnecessary complexity and loses the benefits of relational querying.