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.
Related Terms
Large Language Model
Semantic Search
Structured Data Extraction
Rent Roll Analysis
Buy Box Matching