We were hiding our own search feature
How Trezio combines literal and semantic search — and the wrong assumption that kept the useful half switched off exactly when it mattered most.
Search in a personal library has a problem that search on the web does not. On the web, you are looking for something you have never seen. In your own library, you are looking for something you definitely saved, half-remember, and cannot name. Those need different machinery.
Two kinds of matching, in a deliberate order
Trezio runs literal search first — your actual words, matched across titles, descriptions, notes and voice-note transcripts. Then it appends semantically related results underneath: items that mean what you asked for without containing the words you typed.
The ordering is the whole design. Literal matches always rank first. Semantic results are added after them, and they never reorder or displace a literal hit.
If you type an exact phrase you know is in there, the AI is not permitted to bury it under something it finds more interesting. That constraint is the feature.
Plenty of tools do the opposite — hand the whole query to a model and present whatever comes back. That feels magical until the day you search for an exact title and it is not at the top, at which point you stop trusting the search box entirely.
The mistake we shipped
The first version of this had a gate on it. Semantic search only ran when literal search returned fewer than five results. The reasoning seemed obvious: semantic matching is there to help when your words did not find anything, so why run it when literal search already found plenty?
That reasoning was wrong, and it was wrong in a way that made the feature useless precisely when it was needed.
Literal search here is a per-word OR across every field. So a natural-language query — the kind you type when you cannot remember the title — does not return zero results. It returns dozens. Search for something like "that place where you can generate great landing pages" and the words "that", "you" and "can" match half your library before anything relevant surfaces.
Which meant the gate saw a healthy pile of literal results, concluded that search was doing fine, and switched off the one mechanism that could actually have found what you meant. The vaguer your memory, the more certainly it disabled itself.
The fix was to remove the gate. Semantic augmentation now runs for any real query on an unfiltered first page, regardless of how many loose literal hits already exist.
When it runs, and when it stays out of the way
Semantic matching is deliberately narrow about when it participates. It only augments a plain, global search — the first page of results, with no folder narrowing and no type, date or exclusion filters applied.
The reason is straightforward: if you have asked for voice notes from last month inside one folder, appending items that satisfy none of those conditions would be a bug, not a feature. A filter is an instruction, and augmentation must not quietly violate it.
It also fails quietly. If the semantic layer errors for any reason, it returns nothing and you get ordinary literal results. Search never breaks because the clever part broke.
What this means when you are actually using it
- Type exact words when you have them — they will always win.
- Type a description when you do not. "The thing about pricing psychology" can surface something you saved as "how to charge more".
- Search reads your notes and your voice-note transcripts too, so anything you said out loud is findable as text.
- If you have filtered down to a folder or a type, you are in literal territory. Clear the filters to let semantic matching help.
None of this makes search perfect. It makes it predictable, which over a library you keep for years is worth considerably more.