Search that does not rest entirely on embeddings

Vector similarity is very good at the problem it solves: finding text that means something like other text. It is why semantic search feels like magic on a document corpus, where the question is genuinely about meaning.

It is the wrong instrument for a constraint. "A chalet on the North Coast for six people under a budget" contains four facts — a place, a property type, a party size and a price ceiling — and three of them are hard limits. A listing that sleeps four is not a slightly worse answer than one that sleeps six. It is the wrong answer, and no amount of similarity will notice, because the listing's text reads exactly like the request.

A travel search built entirely on embeddings therefore returns beautifully relevant results that cannot be booked, and the failure is invisible until somebody tries.

The design that works in SolvTrav is unglamorous. The model's job is understanding, not retrieval: it turns loose phrasing into structured filters — area, dates, party size, price ceiling — and then a conventional query answers from inventory that actually exists and is actually available.

This puts the model where it is strong and keeps it away from where it is not. Interpreting "somewhere for the family, not too far, first week of August" is a genuine language problem. Deciding whether a property is available on those dates is not, and should never be answered by anything that can be persuaded.

It also makes the system explicable. A user can be shown the constraints that were understood, and correct them. A pure similarity search has nothing to show — only a ranking, and no account of why.

Natural-language search demonstrates well and ships badly, because the demo is chosen from the sentences that work. In production people write sentences that do not resolve: too vague, internally contradictory, or about something the inventory does not model.

So the conversational route needs a floor underneath it. SolvTrav runs a conventional filtered search alongside the assistant, over the same inventory, and the assistant falls back to guided search when a sentence is not enough. Both read the same inventory layer, so neither can offer something the other cannot book.

The assistant also keeps a thread, which sounds like a convenience and is really the same principle: an interrupted search resumes instead of restarting, because the constraints were recorded as constraints rather than living in a conversation.

Most of the engineering in a working search or RAG system is in what gets retrieved and why. A model handed the wrong three results will write a confident, fluent, wrong answer from them, and no amount of prompt work fixes a retrieval problem.

The uncomfortable implication is that the impressive part of these systems is the least of the work. That is usually a sign the architecture is right.