A Point On Natural Language Search

Most people treat filter-based search as a solved problem. It is a workaround.

When Rightmove or Airbnb shows you a price slider, a bedroom counter, and a list of amenity checkboxes, what they are doing is translating your intent into something a relational database can query. It works when your requirements are categorical, but it breaks when they are contextual.

"Quiet, professional, walking distance from King's Cross, for a 45-minute confidential conversation" cannot be expressed as a filter. Noise level is not a checkbox. "Professional atmosphere" is not a category. The filter interface forces users to decompose human context into discrete attributes, and that decomposition loses information every time.

There is a harder problem underneath this. Apply several filters to a small database and you frequently get zero results. Baymard Institute found that 50% of sites fail to provide users with effective ways to recover from a search that yields nothing. A Harris Poll survey of more than 10,000 consumers commissioned by Google Cloud found that 76% said an unsuccessful search resulted in a lost sale. Filters on a small or inconsistently described corpus produce dead ends.

What changes this is an architecture called Hybrid Search

You keep the relational database. Location coordinates, opening hours, capacity: these stay in PostgreSQL, with PostGIS handling the spatial queries. Nothing gets replaced.

What you add is a vector layer. You take the qualitative description of each listing and run it through an embedding model: OpenAI's ada-002, Cohere's Embed, or whatever fits the use case. The model converts each description into a dense vector, a point in high-dimensional space where semantically similar concepts cluster together. "Quiet corner with soft seating" ends up near "calm, professional atmosphere." "Lively bar with sports screens" ends up far away.

When a user types a natural language query, you embed that too. You run Approximate Nearest Neighbour search, using HNSW indexing in pgvector, to find the listings whose embeddings are closest to the query. You then combine those semantic results with traditional structured filters using Reciprocal Rank Fusion. RRF merges ranked lists from different retrieval methods by position rather than score, so you never have to normalise incompatible signals. One ranked list comes out, reflecting both semantic intent and hard constraints.

This runs entirely inside PostgreSQL with the pgvector extension. No separate vector database. No synchronisation layer. AWS benchmarks on Aurora PostgreSQL with pgvector 0.8.0 show up to 9x faster query processing and up to 100x improvement in result relevance versus earlier implementations. Hybrid search with RRF consistently delivers 20–30% better retrieval effectiveness than either pure keyword or pure vector search alone.

Airbnb worked this out some time ago. Their engineering team published the details in 2023. The problem they had was that hosts described the same attributes in hundreds of different ways: "lockbox," "lock box," "box for the key," "keybox." They built what they called LAEP, Listing Attribute Extraction Platform. NER models scanned listing text, extracted attribute phrases, and a word2vec model mapped those phrases to a standard taxonomy via cosine similarity.

The output was a consistent, queryable vocabulary across millions of listings. Semantic understanding replaced keyword matching.

In February this year Rightmove, the UK's largest property platform, launched conversational search built with Google's Gemini models. Users can now type "cottage with a sea view within a 30-minute commute" instead of setting filters. To do it, Rightmove spent years building an AI Keywords feature that scans listing images and text to extract structured attributes their existing filters could never capture. They are retrofitting semantic retrieval onto millions of listings described inconsistently over 26 years. It works. But it is genuinely hard.

The semantic layer is only as good as the vocabulary your database is described in

You cannot embed a listing that says "coffee shop, Central London" and expect it to surface when someone types "quiet corner table for a confidential conversation near a tube station." The embedding model cannot extract signal that is not there. The vector representation of a thin description is a thin representation. Garbage in, garbage in.

Build the database from scratch with retrieval in mind, using a consistent and rich descriptive vocabulary that maps deliberately onto what users will actually ask for, and the semantic layer works properly from day one. You are designing for the query.

The real value of all of this is expressive rather than ergonomic. Filters can only capture requirements you can decompose into discrete categories. Natural language captures requirements that live in combination: contextual, qualitative, multi-dimensional. Users do not think in filters. They think in intent. For a wide class of searches, those two things are different.

The queries that fail on filter-based search are almost never the simple ones. They are the specific ones: multi-part, contextual, particular. According to a Semrush study, traffic from AI and long-tail search converts at 4.4 times the value of broad traditional search. Specificity is the signal. And filter interfaces systematically fail specific searches because specificity requires expressing combination and context together, which filter boxes cannot do.

Consider: "find me a cottage with a sea view within a 30-minute commute." You could theoretically build filters for that. A sea view checkbox. A commute time slider. But no one searching for a home thinks in those terms separately. The intent is a single coherent thought, and the filter decomposition loses the coherence. Rightmove has one billion monthly minutes of users who know exactly what they mean. A platform that size has concluded that the filter paradigm, for this class of search, is over.

Natural language search is most valuable when the right answer depends on a combination of requirements, at least one of which is qualitative or contextual, in a search space where the wrong result has a real cost. That covers more products than most teams think.

The misunderstanding worth correcting is this: natural language search is not a smoother interface over the same underlying capability. Quite often it's the only interface that produces an answer at all.