Half of the keys on my keyboard have degraded since January. Some letters are fully dead, as I’ve run out of keys to rebind more useful ones to, and I have no free weeks for the service. Still, I input text and get things done far faster than a year ago, driving my Mac the same way my grandma does, using voice control.
Voice mode allows you to bypass the entire process of converting thoughts into text. You speak at almost the same pace as you think, while typing uses some of your thinking power in the typing process itself.
It improved my English, sped up my work, and constantly stretches my thinking because, as you work faster, you take on more work overall. Voice input is the future, but what truly shook me was one curious query-related conclusion as we move toward it.
Because speaking is faster than typing, voice queries naturally expand in detail and specificity, filling the time that would otherwise be spent typing.
Suppose you want to find one invoice among many. Your internal voice is like:
the invoice we received from Acme in March for the German subsidiary, around €20,000
Your internal typing compiler would most likely compress that into something high-level:
"acme invoice march"
While speaking natively preserves qualifiers in the request, as words are just easier to say:
"find the invoice we got from Acme in March for the German subsidiary around twenty k"
The benefit of such intent preservation is that, if properly supported by the datasource, the time spent comprehending the result set decreases, so you get a double boost: faster inputing and less time spent on manual retrieval.
To support this claim of a shift in demand from short, fuzzy queries to longer, more precise ones, recall that humans are no longer the web’s only actors. Working with talented team of strawberrybrowser.com made me realize how much we underestimate the web work agents are already doing, and how poorly existing search interfaces fit them.
Think about how agents access a proprietary search engine today. LLMs need advanced computer-use capabilities just to navigate the UI, open filter popovers, discover relevant facets through trial and error, and keep iterating until the query finally reflects the original intent, and then spend the precious context window verifying that the results satisfy conditions the agent already knew, but could not express directly through the search bar.
Given these needs, we can formulate the demand for a new generation of search engines as a consolidation of several properties:
The smarter search must still be faster than verifying a worse one.
A better search engine creates value only when producing the better result takes less time than a human or agent would otherwise spend verifying a fuzzier result set.Must be trustworthy enough that users do not need to manually recheck every result.
The new engine creates leverage only when users can trust its judgment enough to stop manually scanning the results themselves.Should proactively resolve ambiguity.
A good system must detect underspecified intent, choose the most probable interpretation, and preserve meaningful alternatives if user meant something else.Should have an option to fail fast.
A better system should catch requests the schema cannot answer before you wait a minute, state clearly what cannot be fetched and give you alternatives.
With this in mind, I’m happy to introduce Gia, a natural-language query compiler, as our best attempt to develop this target design and commoditise natural-language retrieval across proprietary search engines.
Overview
Gia is a natural-language query adapter for an existing database. Consider you have a functioning PostgreSQL, and you want yourself, your users and agents to be able to query against it using plain English. Gia provides a set of SDK and CLI tools to deploy the most efficient query engine for your case within minutes.
To achieve this, Gia:
- hooks into database schema changes to build and refresh a reviewable internal semantic model called Gia World, trackable via git
- at runtime, receives a natural-language query and compiles it into a database QL, executes it locally, and returns the results
Gia’s runtime is a state-of-the-art natural-language retrieval harness that is:
i. Human-expert-level accurate
Gia is evaluated against production-like databases to push natural-language retrieval as close as possible to human-level accuracy on realistic query workloads.
In the special application case of text-to-SQL bench, GiaSQL High, using multiple-candidate generation, achieves 90.56% execution accuracy on Arcwise-Plat-Full, an expert-verified version of BIRD Mini-Dev designed to eliminate annotation errors in the original benchmark. Gia golden-got 451/498 questions, losing to the fine-tuned ReViSQL on 16 ambigious cases.
Gia's kernel wasn't trained on BIRD specifically but made zero value-format understanding errors during the benchmark. The largest source of errors was ambiguity resolution during the inference, with query complexity having little effect on its ability to produce meaningful, production-ready answers.
ii. Ambiguity-aware and able to refuse
Gia can generate multiple search query candidates, choose the most likely interpretation, and fail fast when the request cannot be answered using the available data.
iii. Fast
Across all our client databases and production-like benchmark cases, Gia’s cold-query latency is:
p50: 1.9 s p95: 3.6 s p99: 4.9 s.
Warm query latency uses semantic caching based on query shape algorithm and is almost equal to the latency of the database execution itself.
Sub-second is our biggest target latency-wise, while we believe that Gia is already useful for every case where the time you'd spend manually picking the filters is greater than Gia's query compilation time.
iv. Teachable
Gia tries to one-shot every new query it gets, but it’s still pretty easy to customize its reasoning to your internal decisions. Domain concepts, field conventions, and guidance for fetching specific requests are configurable via the git-trackable World files.
The goal is to expose roughly the same customization depth you would expect when building a natural-language search system internally.
v. Cheap
An average cold query costs about 1 cent to compile, while semantically cached query shapes incur no additional inference cost, and Gia caches heavily. The exact amount depends on the mode, query, and schema complexity, but we’ve never seen anything higher than five cents for ultra-complex cases.
Demo
The interactive showcase below is a GiaSQL·Fast deployment on top of one of BIRD’s open benchmark databases, F1 Archive, with a 2017 F1 knowledge cutoff. You can use the random sample button or challenge Gia on your own.
Compare its query time with the time it would take to express the same request through filters and a fuzzy search bar:
Known limitations
Search quality is still bounded by the quality of the underlying datasource. Gia can do a lot with messy, production-like schemas, and it learns field structure, definitions, conventions, notes, and examples during semantic model initialization. But if the underlying data is fragmented, inconsistently modeled, or poorly described, retrieval quality will eventually hit that ceiling.
Future
Our bet is that in a few years, every single dummy search bar on the internet will be replaced by a smart, schema- and relationship-aware natural-language search engine,
and we’re looking for similarly obsessed people to make this future come true. If you are a potential customer, engineer, GTM, angel investor, or simply care deeply about the problem, reach out to us at yahor@usegia.com, and we’ll be in touch!