Scaling NLQ to large schemas with schema retrieval and few-shot banks

A schema card works beautifully for ten tables. At three hundred, it blows the context window and drowns the model in irrelevant columns, and accuracy falls off a cliff. The fix is the same idea that powers RAG: don't put the whole schema in the prompt — retrieve the relevant part of it.

Retrieve the schema, don't dump it

Embed each table or collection's schema card, and at query time retrieve only the handful relevant to the user's question to put in the prompt. It's RAG over your own schema (see the RAG-fundamentals and embeddings posts). The model sees five relevant tables instead of three hundred, and both accuracy and cost improve.

A few-shot bank

Keep a growing library of (question → correct query) pairs. For each new question, retrieve the most similar examples and include them as few-shot demonstrations. This moves accuracy more than almost any other single lever — the model learns your schema's conventions and quirks from examples that look like the task in front of it.

The levers that actually move accuracy

• Schema-retrieval quality — if the right tables aren't retrieved, nothing downstream can save the query.
• Relevant few-shot examples — the highest-ROI lever once retrieval is solid.
• Clear column descriptions and synonyms — 'rev' means revenue; tell the model.
• Validate-and-retry — feed execution errors back for a corrected attempt.
• Execution-based evals — measure real accuracy so you know which lever helped (see the silent-failure post).

You don't scale NLQ by using a bigger context window. You scale it the same way you scale RAG — by retrieving only what this question actually needs.