Finding the Tables a Query Actually Needs

Generating correct SQL is difficult when the model never receives the table containing the required data. During candidate retrieval, recall measures how much of the relevant material was found.

The amount of irrelevant material matters too. A very broad result set adds processing time and context that can distract the model.

Use complementary sources

Semantic search compares a question with table descriptions by meaning. It helps when the user and the documentation use different words. Exact internal abbreviations can be found through glossary matching.

Another option is to ask a model to select tables from small batches of descriptions. For a large schema, account for the cost and latency of all those calls. Model selection can also be a fallback when cheaper retrieval provides insufficient context.

Tables identified during entity extraction can join the same candidate pool.

Combine, then narrow

A union retains candidates found by only one method. An intersection would discard them, even though those unique matches may be the reason to use several methods.

After combining results, remove duplicates and retain each candidate's source. Rank and select within a context budget, adding connecting tables when schema relationships require them.

If the context is insufficient, the agent can expand its search. Retrieval does not have to be a single irreversible decision.

Measure it on actual questions

For each test question, record the tables needed by a verified solution. Compare individual methods and their combination: what they found, what they missed, and how much extra material they returned.

This shows whether another method earns its cost. Check the complete agent as well. A higher recall score is of limited use if the resulting context overwhelms the next stage.