Modern Loft Apartment
Strong matchOptional details unconfirmed
- Price
- 750.0 USD total for 5 night(s)
- Budget
- Within your budget of 750.0 USD
Confirmed · 3
- Kitchen
- Wifi
- BudgetPRICE: 750.0 <= allowed total 750.0
Not confirmed · 1
- Quiet streetOptional
Conversational accommodation search
Describe your stay.
Get answers you can check.
Booking AI turns a plain-English request into explicit requirements, checks every listing against them, and shows what is confirmed, what is not, and why.
Recorded backend output · sample data
Apartment in Baku from April 10 to 15 with WiFi and a kitchen, up to $150 per night. A quiet street would be nice.
InspectorWhy this result
Selected because all required constraints are confirmed. 3 requirements confirmed, 1 optional detail not confirmed.
Multi-turn conversation
New search, refinement, listing questions and general chat, with explicit state between turns.
Seven-stage pipeline
LLMs interpret language; deterministic code matches, verifies evidence and ranks.
1,000+ offline tests
Hermetic test suite plus golden-set and end-to-end evaluation.
Why conversational search
A stay is a set of requirements, some strict and some flexible. Filters flatten them into fields, and the real answer often sits in the listing text.
With filters and pages
- Translate “quiet, with a proper kitchen” into checkboxes that may not exist
- Re-enter dates, budget and amenities every time one thing changes
- Open listing after listing to see whether a filter really applied
With Booking AI
- Say what you need in your own words, required and nice-to-have alike
- Refine with one sentence; the rest of the search stays as it was
- See per listing what is confirmed, not confirmed or not satisfied, and why
What Booking AI can do
Everything happens in one conversation: search, refine, ask, and see the reasoning behind each result.
Search in natural language
Describe the kind of accommodation you want, without filling out a page of filters.
“Find an apartment in Baku with WiFi and a balcony.”
Refine your search
Change your preferences mid-conversation. Everything you said before stays in the search.
“Actually, I also need a kitchen.”
Ask about a listing
Ask a follow-up about a recommended property. The answer comes from that listing’s data, or says it couldn’t be verified.
“Does the first apartment allow pets?”
Understand the recommendations
Each result shows which of your requirements are confirmed, not confirmed or not satisfied, and why it was recommended.
ConfirmedNot confirmedNot satisfied
Clarify preferences
When a request is ambiguous, Booking AI asks one follow-up question instead of guessing.
“Do you mean $200 per night or for the whole stay?”
Keep some wishes optional
Say what would only be nice to have. Optional wishes are kept apart from requirements and marked as not confirmed when the listing data is silent.
“A quiet street would be nice.”
How it works
Seven stages run on every search turn. Under each one, a real request recorded on the sample dataset shows what that stage produces.
- 1Router
- 2Intent / state
- 3Retrieval
- 4Matching
- 5Evidence
- 6Ranking
- 7Response
A question about a shown listing takes a shorter path: Router → the shown listing it refers to → the question turned into requirements (LLM) → matching and evidence for that listing → a verdict rendered directly, without the response LLM. A clarifying question can end any turn before retrieval.
LLM interprets language and evidenceDeterministic decides state changes and verdicts
- 1
Conversation Router
LLMDecides what each message is: a new search, a change to the current one, a question about a shown listing, or general chat. An ambiguous turn gets a clarifying question, and a reference like “the first one” is checked against the results actually shown.
“Apartment in Baku from April 10 to 15 with WiFi and a kitchen, up to $150 per night. A quiet street would be nice.”
→ new search · later “Only show places with a balcony.” → change to the current search
- 2
Intent Extraction / State Update
LLM + DeterministicAn LLM turns a new request into a typed search, or a follow-up into a small patch to it. Code validates dates, asks when a budget could be per night or for the stay, and applies the patch, so earlier requirements are kept.
city: Baku · stay: 10 Apr 2026 – 15 Apr 2026 · budget: up to 150 USD per night
- wifi · Required
- kitchen · Required
- quiet street · Optional
- 3
Retrieval
DeterministicCandidate listings for the city and dates come from the listing source: a bundled sample dataset in the demo, or an optional Apify-based retriever. Retrieval does not use embeddings.
Apartments in Baku available 10 Apr 2026 – 15 Apr 2026 from the sample dataset, priced for the requested nights.
- 4
Structured and Numeric Matching
DeterministicEach requirement is checked against canonical listing fields such as amenities, policies and room facilities. Price, bedrooms, bathrooms and area are compared as numbers; an area must belong to the room or apartment being booked.
- ✓Kitchen · Kitchen
- ✓Wifi · WiFi
- ✓Budget · PRICE: 750.0 <= allowed total 750.0
- ?Quiet street · no structured field
- 5
Textual Evidence Resolution
LLM + DeterministicRequirements no field can answer are read from the listing text. The model must quote its evidence, each quote is verified against the listing, and code turns the signals into confirmed, not confirmed or not satisfied.
Another sample listing, Sunny Central Apartment, asked about a “quiet location”:
“Quiet street but still central.”
quote found in listing text → confirmed
- 6
Ranking & Selection
DeterministicEligible listings are sorted into strong, partial and weak matches and the top ones are selected. A required item that is not confirmed never makes a strong match.
- 1. Modern Loft Apartmentstrong · score 30
- 2. City Center Compact Loftstrong · score 30
- 7
Response generation
LLMAn LLM words the already-decided outcome, with a deterministic fallback. Answers about listing facts are rendered directly from the verdict, so a decided fact is never reworded.
The reply is worded from the decided outcome: 2 strong matches in Baku. Listing cards and the Decision Inspector come straight from the same data.
Evaluation & Reliability
Each component is scored on its own hand-labelled golden set, whole conversations are scored end to end, and every change runs against an offline regression suite.
Ranking & selection
Component-level
Given listings with known verdicts, are the right ones surfaced, in the right order?
- top-1 correct
- 101 / 103top-1 correct
- ineligible listings shown
- 0 / 103ineligible listings shown
Deterministic · re-run on the current code · 103 hand-labelled cases · report
Constraint extraction
Component-level
Does a plain-English request become the right set of requirements?
- F1 over 202 requirements
- 0.79F1 over 202 requirements
- requests with the exact set
- 132 / 166requests with the exact set
LLM · saved run, April 2026 · measured before later prompt changes · report
Evidence resolution
Component-level
Given a requirement and a listing’s text, is the verdict YES, NO or UNCERTAIN?
- correct verdicts (114 of 120 cases scored)
- 98 / 114correct verdicts (114 of 120 cases scored)
- critical YES ↔ NO flips
- 0critical YES ↔ NO flips
LLM · saved run, April 2026 · measured before quote verification was added · report
End-to-end evaluation
50 hand-labelled requests run through the whole pipeline and are scored on the decision the answer implies — yes, no or uncertain — and on the top result. Each critical false “yes” was traced to a cause; the fixes that followed include quote verification, visible optional preferences, budget-scope questions and area attribution.
The last full run predates those fixes, so no end-to-end score is shown for the current system · method
Regression & reliability
- 1,000+ offline tests run without network access or API keys.
- 7 multi-turn scenarios cover search, refinement, follow-ups and clarification.
- 29 failure-handling tests: a provider or retrieval error ends the turn with a typed failure and leaves the conversation unchanged.
Tests guard behaviour and contracts; they are not a measure of model accuracy.
measured on the current code · saved run of an earlier version
FAQ
Is there an interactive demo I can try?
Not publicly yet. An interactive chat demo exists and runs against the same backend, but it is not online for now. The example conversation on this page is recorded output from that backend on a sample dataset.
How does Booking AI understand my preferences?
A language model turns your message into a structured search: city, dates, guests, budget and a list of requirements, each marked as required, nice to have or excluded. Code then validates it — for example, it asks whether a budget is per night or for the whole stay instead of assuming.
What happens if listing information is incomplete?
Requirements are checked against structured listing fields first. If a field does not answer it, a model reads the listing text and has to quote it; the quote is verified against the listing. Anything still unproven is shown as “not confirmed” — it is never counted as a yes, and a required item that is not confirmed keeps a listing from being a strong match.
Can I refine my search?
Yes. Say what to change — “only places with a balcony”, “make it a hotel instead” — and the existing search is updated while everything else is kept. You can also ask about a listing you were shown, such as “Does the first one have parking?”.
Does Booking AI use real accommodation data?
The examples on this site were recorded on a bundled sample dataset, so listings, prices and links are illustrative and say nothing about real availability. The backend also has an optional Apify-based retriever for live listing data, which is not enabled in the demo.
Can I book accommodation through the assistant?
No. Booking AI is a search and decision assistant. It does not take bookings or payments and does not guarantee availability or prices.
Which languages does it support?
English. Requests in other languages are not supported yet.
Can I inspect the source code?
Yes. The whole project, including the backend, its tests and the evaluation harness, is on GitHub. View source code.
Built by
Leyla Mehtiyeva
AI engineering projectBooking AI was designed and built independently, end to end: conversation state, typed contracts between stages, evidence verification, evaluation, the API and this site.
- Python
- Pydantic v2
- FastAPI
- Google ADK
- Gemini 2.5 Flash-Lite
- Astro
- React
- Tailwind CSS
- pytest
Code, tests and evaluation are on GitHub.
View source code