SnowPro Specialty: Gen AI Question 176
Single answerMulti-turn architectureA retail company is building a customer support copilot in Snowflake that must handle multi-turn conversations such as order-status follow-ups and return-policy clarifications. The team notices two problems in testing: the model sometimes forgets details mentioned earlier in the conversation, and prompt size grows quickly when the full chat history is sent on every turn. Which approach is the MOST appropriate to improve the multi-turn architecture while controlling cost and preserving relevant context?
- A
Store every conversation turn in a table and send the entire raw transcript to the model for each new user message so no context is lost.
- B
Maintain conversation state outside the model, summarize older turns, and send only the latest user message plus the most relevant recent history and summary to the model.
- C
Use a separate warehouse size for each turn so the model can infer prior context from Snowflake compute metadata instead of chat history.
- D
Start a brand-new conversation for each user message and rely on retrieval alone, because multi-turn memory should not be handled at the application layer.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to manage multi-turn state explicitly and optimize what is sent to the model each turn. In real-world Gen AI applications, especially support copilots, the model is stateless across API calls unless the application includes prior context in the prompt. Best practice is to persist conversation history, summarize older turns, and include only the most relevant context for the current turn. This reduces token costs, avoids context-window pressure, and improves response quality. In Snowflake-based Gen AI solutions, teams commonly use application logic and database storage to retain chat state, and combine that with retrieval when external knowledge is needed. This reflects standard conversational architecture guidance: keep memory outside the model, pass structured context intentionally, and avoid blindly replaying the full transcript every time.
- A. Incorrect.
This is incorrect because sending the entire transcript on every turn is not a scalable multi-turn design. Although it may reduce the risk of missing earlier context, it increases token usage, latency, and cost, and can eventually exceed model context-window limits. A common misconception is that complete history is always the safest approach; in practice, production chat systems usually trim, summarize, or selectively include history.
- B. Correct.
This is correct because effective multi-turn architecture typically manages conversation state in the application layer rather than expecting the model to remember prior turns by itself. Summarizing older exchanges and keeping only relevant recent turns helps preserve important context while reducing token consumption and prompt bloat. This is a practical pattern for conversational AI systems in Snowflake-based solutions that orchestrate prompts, retrieval, and memory handling across turns.
- C. Incorrect.
This is incorrect because warehouse sizing affects compute resources for SQL and related processing, not the model's conversational memory. The model cannot infer prior dialog state from Snowflake compute metadata. This distractor targets the misconception that infrastructure settings can replace explicit context management in LLM applications.
- D. Incorrect.
This is incorrect because retrieval can help bring in external knowledge, but it does not replace conversation memory for user-specific details already stated in prior turns, such as an order number or a clarification preference. Starting a new conversation every turn would worsen continuity. In multi-turn systems, retrieval and conversation-state management are complementary, not interchangeable.