In software architecture, "relevance" is often treated as a sorting algorithm. You take a list of items, apply some weights, and present the top ten. In travel, this approach fails because relevance is not a static property of a location. It is a dynamic relationship between a place, a time, and a person.
A beach in winter is a perfect recommendation for an outdoorsy couple on an adventure holiday. It is a terrible recommendation for a group of friends wanting to relax with a cocktail in the sun. The data point (the beach) hasn't changed, but its relevance has inverted entirely based on the context.
To solve this, we cannot simply index "places." We have to index the suitability of those places against specific intents.
The Missing Variable: The Audience
You cannot solve an equation if a primary variable is missing. In traditional travel search, the missing variable is the audience.
Creating a generic itinerary without knowing who it is for is a futile engineering exercise. It results in "top 10" lists that satisfy no one. To create value, we must identify the user. We do this either by inference, for example, analysing the keyword metadata that brought them to the page, or by asking them directly via a simple form.
Once we have the "who," the computational challenge shifts to the "what."
Seeing Behind the Reviews
The industry standard for judging quality is the user review. This is a noisy signal. A five-star rating tells you a place is good, but it doesn't tell you what it is good for.
To build a system that understands relevance, we have to look behind the ratings. We need a deep understanding of the inventory. This is where Obvlo's content engine operates. We don't just scrape listings; we analyse "candidates."
We task our engine to find matches for specific intersections of Traveller Type and Trip Type. We explicitly curate candidates for "Couples x Romantic" or "Friends x Adventure."
If we are curating for a romantic trip, a noisy bar with excellent reviews is rejected by the system. It is a valid location, but it is an invalid candidate for this specific matrix. By doing this at scale, we create a foundational database where relevance is pre-computed, not guessed at runtime.
The Engineering Scale of "Depth"
It is important to understand what "curation" means in terms of compute.
When we configure a new destination on Obvlo's content engine, we trigger a massive set of asynchronous jobs. Whether the destination is a single hotel in one location or a major city with ten neighbourhoods, the process is guided by strict search criteria determined by the customer's target audiences.
To build a single, complete destination database. Taking an example where a destination comprises 3 distinct locations, 40-50 guides, 500-600 curated listings, and 30-40 site pages, the system performs a heavy lift:
- Search Execution: It executes hundreds of unique searches to find raw candidates.
- Evaluation: It runs thousands of LLM-based evaluations on images and textual relevance.
- Generation: It generates tens of millions of tokens to produce the final text and media assets.
This is not a simple database query; it is a generative pipeline that builds a knowledge graph from scratch for every client.
From Database to Answer
Because we accept this computational cost upfront, understanding the nuance of every location before we ever produce a recommendation, we can answer specific, complex queries with a high level of confidence.
This depth allows us to invert the standard search process. Instead of summarising a "top 10" list found elsewhere, we answer specific questions by building the response from the ground up using verified data.
If a user asks, "What is a great 3-day itinerary in New York for a couple visiting before Christmas?" we are not searching the web for keywords. We are querying a curated subset of our database that has already been vetted for "New York," "Couples," and "Winter/Festive." The same applies to hyper-local queries, such as finding things to do for a group of friends near a specific hotel.
Dynamic Generation vs. Static Directories
The result of this deep curation is that we do not serve off-the-shelf directories. Obvlo’s output is dynamically generated.
It doesn't matter if we have two clients who are both hotels in New York, because we build from the ground up, the content we generate will be distinct for each. One might require a focus on quiet luxury for older couples, while the other needs recommendations for nightlife-loving friends.
We aren't presenting a static list of "Things to do in New York." We are assembling a bespoke set of recommendations that fit the specific parameters of the request and the voice of the brand. Quality in AI doesn't come from the model's ability to write pretty sentences. It comes from the depth of the knowledge base it draws upon.
