An architect is designing a system prompt for a Claude instance that must generate SQL queries from natural language. The model occasionally generates queries using table names from its training knowledge rather than the actual database schema. What is the most reliable technique to ground Claude's SQL generation in the actual schema?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because grounding SQL generation in the actual schema requires providing the schema as explicit context. Placing DDL in a clearly labeled <schema> XML tag makes the authoritative information structurally distinct and easy to reference; the explicit instruction to 'only reference tables and columns present in <schema>' closes the loophole that allows training-data hallucinations.
Full explanation below image
Full Explanation
B is correct because grounding SQL generation in the actual schema requires providing the schema as explicit context. Placing DDL in a clearly labeled <schema> XML tag makes the authoritative information structurally distinct and easy to reference; the explicit instruction to 'only reference tables and columns present in <schema>' closes the loophole that allows training-data hallucinations. This is the primary preventive control. A is wrong because few-shot examples for each table would require one example per table times the number of column combinations; at scale this is impractical and still susceptible to hallucination between examples. C is wrong because extended thinking improves multi-step reasoning but does not provide the model with the actual schema; the model cannot think its way to the correct schema if it was never given the schema — it would still reason from its training knowledge. D is wrong because EXPLAIN-based retry is a detect-and-retry pattern that adds latency and database round-trips; it is a valid fallback but not a substitute for the preventive approach of schema injection.