A natural language query is a plain-language question posed to a data system that the system translates into a formal database query and answers, without the user writing code. In commercial real estate it lets an analyst ask "which assets have leases expiring in 2026 above market rent" against a portfolio database and get rows back, instead of writing SQL or building a filter by hand.
How Natural Language Query Works
A natural language query works by translating a plain-language question into a structured query, most often SQL, running it against the database, and returning the result. A language model maps the words in the question to the tables, columns, and filters of a known schema, generates the query, executes it, and passes the rows back, ideally showing the query it wrote so a user can check it.
The translation step is the hard part, called text-to-SQL. On the BIRD benchmark, which pairs 12,751 natural language questions with SQL across 95 databases and 37 domains, the top single model, Gemini-SQL2, reaches 80.04% execution accuracy while a human baseline is 92.96%, per BIRD leaderboard reporting. The roughly 13-point gap is why the generated query, not only the answer, should be visible to the analyst.
Component | Function |
Schema map | The tables and columns the model can reference |
Parser | The language model that turns the question into SQL |
Execution | Running the generated query against the database |
Result | The rows returned, with the query shown for review |
Why Natural Language Query Matters
A natural language query matters because it removes the analyst-to-engineer handoff for routine portfolio questions. Most asset management questions, such as expiring leases, rent-to-market gaps, or DSCR by property, are simple filters that today wait in a queue for someone who can write the query. Letting the analyst ask directly turns a next-day request into a same-minute answer.
The accuracy ceiling sets the operating rule. Because even leading text-to-SQL systems sit near 80% on BIRD versus a 92.96% human baseline, a natural language query is a fast first draft that an analyst confirms, not an unchecked source of truth. A quotable line for the desk: trust the answer only as far as you would trust the query it was built from, so keep the query visible.
Example
A natural language query is clearest on one portfolio question. An asset manager overseeing 40 properties asks, "Which retail assets have a lease expiring in 2026 where in-place rent is below market rent?"
Step | What happens |
Question | Plain English is typed into the query box |
Translation | The model writes SQL joining leases to the rent table |
Filter | property_type = 'retail', expiry year 2026, in_place_rent below market_rent |
Execution | The query runs across all 40 properties |
Result | 7 assets returned, with the generated SQL shown for review |
Without a natural language query, the asset manager files a request and waits for an analyst to write the join and filter, often a day of turnaround. With it, the SQL is generated and run in seconds and returns 7 assets. Because the system displays the query, the asset manager confirms the 2026 filter and the below-market condition are correct before acting on the 7 rows.
Variations and Edge Cases
A natural language query behaves differently by data structure, question complexity, and how much ambiguity the question carries. A simple filter is reliable; a multi-table aggregation with a vague term is where errors concentrate. The variants below show where design and accuracy shift.
Variant | Treatment |
Text-to-SQL | The question becomes SQL against a relational database |
Semantic layer | The model queries defined business metrics, not raw tables |
Conversational | Follow-up questions refine the prior query in context |
Ambiguous terms | "Good deals" or "underperforming" need a definition first |
Aggregation | Sums and group-bys are more error-prone than single filters |
Natural Language Query vs Semantic Search
A natural language query is often confused with semantic search, and the difference is what comes back. A natural language query translates a question into a precise database query and returns exact rows or a computed value, such as the 7 assets that meet three conditions. Semantic search ranks documents or passages by meaning and returns the closest matches for a person to read.
A natural language query is for structured data and exact answers, counts, filters, and sums over a database. Semantic search is for unstructured text and relevance, finding the leases or notes most related to a concept. One computes; the other retrieves. CRE teams use natural language query over a rent roll or portfolio table and semantic search over a document set.
Frequently Asked Questions
What is a natural language query in commercial real estate? A natural language query is a plain-English question posed to a data system that translates it into a database query and answers it, without the user writing code. It lets an analyst ask a portfolio database a question directly, such as which leases expire in 2026 above market rent.
How accurate is natural language query to SQL? It is a strong draft, not a certainty. On the BIRD text-to-SQL benchmark the top single model reaches about 80% execution accuracy against a 92.96% human baseline, so the generated query should be visible and confirmed before an analyst acts on the result.
Do I need to know SQL to use a natural language query? No. The point of a natural language query is that the user asks in plain language and the system writes the query. Knowing enough to sanity-check the generated query helps, because it lets you confirm the filters match what you asked.