What it means to search bookmarks by meaning

Matching words against matching meaning

Every search you have ever used in a browser is a text match. You type "drone", it looks for the letters d-r-o-n-e in the titles it stored, and it returns the ones that contain them. Nothing about the search understands what a drone is. Change your word and the result changes completely, even though your intention did not.

Search by meaning inverts that. It does not compare your words with the stored words. It compares a representation of what you meant with a representation of what each page was about. Two texts about the same subject score as close even when their vocabulary does not overlap; two texts that share a word but not a subject do not.

• "the drone part I printed" finds a page called "Pavo20 camera mount and antenna holder".
• "what did I save about keeping an AI library private" finds three articles, none of which uses that phrasing.
• A question typed in Portuguese finds a page written in English, because meaning is not spelling.

How a page becomes a list of numbers

The technical name is an embedding, and the idea underneath it is simpler than the word suggests. A model reads a piece of text and produces a fixed-length list of numbers — a vector. The model is trained so that the position of that list means something: texts about similar subjects land near one another, and texts about unrelated subjects land far apart.

Think of it as a map with far more than two directions. On a real map, two towns near each other are geographically close. Here, two texts near each other are close in subject. The numbers are the coordinates, and there are typically several hundred to a few thousand of them rather than two.

For bookmarks the sequence is: fetch the saved page, reduce it to text, have a model write one plain line saying what it is, and turn that line into a vector. Storing a description rather than the whole page is what keeps a library of six hundred links to roughly three megabytes on disk.

Searching is then arithmetic. Your question becomes a vector by the same route, and every stored vector is compared with it. Comparing a question against six hundred saved links takes about a millisecond on a Mac — the ranking is never what you wait for.

Why the score matters, and why a good search says nothing

Every comparison produces a number between roughly nought and one. The uncomfortable truth about that number is that the gap between right and wrong is narrower than you would hope.

Measured on a real library of six hundred links: a genuinely correct answer scores around 0.60, and links with nothing to do with the question sit at 0.44 to 0.47. That is a sixth of the scale between "this is what you wanted" and "this is noise".

The consequence is that a fixed cut-off does not work. Set it low and seventeen near-misses come through behind one good hit; set it high and real answers are thrown away. The rule that does work is a relative one — keep only what is close to the best result, and only when the best result clears a bar at all.

Which means a search that finds nothing has to say so. A tool that always returns three results has taught you that its results mean nothing, and after that you check every one of them by hand, which is the thing you were trying to avoid.

What has to leave your machine, and what it costs

Turning text into a vector needs a model, and the good multilingual ones are large. So there is one thing this approach cannot do entirely on a Mac: the text has to be sent somewhere to be turned into numbers.

• Describing and embedding each page happens once, at import. That is the part that costs money, and it is proportional to how many links you have — importing six hundred links cost about $0.42 at the prices used here.
• Embedding a question happens every time you press Return, and costs thousandths of a cent.
• The comparison itself happens on your Mac against a file on your disk, and costs nothing at all. So does browsing, filtering and anything else that does not involve a new question.

The distinction worth holding on to is that the library never travels. What is sent is the question you typed, or at import the page being described — never the collection.

Where it does not help

Search by meaning is bad at the things word search is good at, and it is worth knowing which is which before you rely on it.

• Exact phrases. If you remember a sentence verbatim, you want a full-text index, which keeps the sentence. Meaning-based search kept a description instead, and the sentence is gone.
• Code, error messages and identifiers. A stack trace has no subject to be near.
• Anything the description missed. Sites that serve a JavaScript shell give up no text, so their description comes from the title and the domain alone — thinner, and it shows in the results.
• Very small libraries. With forty bookmarks you can read the list. This only starts paying at the point where you cannot.