Notezbeta
Back to blog

Semantic Search for Notes, Explained

semantic-searchDenis Povarov

You know the note exists. You wrote it three months ago, it contained the answer to exactly the problem in front of you, and you cannot find it — because you are searching "caching" and the note says "memoize", or you are searching "deploy failure" and the note says "release broke". Keyword search fails precisely when your memory of the wording fails, which is most of the time after a few weeks.

Semantic search fixes this by matching on meaning rather than exact words. This post explains how it works, where it beats keyword search, where it doesn't, and what it changes about how you organize notes.

How keyword search fails

Traditional search tokenizes your notes into words and matches your query against them, perhaps with stemming ("deploys" matches "deploying") and fuzzy matching for typos. It is fast and predictable, but it is fundamentally string matching: the query and the note must share vocabulary.

Notes are the worst case for this. They are written quickly, in the vocabulary of the moment, with no editor enforcing consistent terminology. The same concept appears as "auth", "login", "sign-in", and "session" across four notes written in four different moods. To find your own note, you must guess which words your past self used — a memory test, when the whole point of notes is not having to remember.

How semantic search works

Semantic search replaces string matching with meaning matching, using embeddings: a machine learning model maps a piece of text to a vector — a long list of numbers — positioned so that texts with similar meaning get vectors that are close together. "Memoize the session lookup" and "cache the login check" land near each other in that space even though they share no words.

The mechanics, end to end:

  1. Indexing. When you save a note, the system runs it through an embedding model and stores the resulting vector alongside the note. This is why AI-enabled note apps meter "embedding tokens" — each note's text is processed by a model at save time.

  2. Querying. Your search query gets embedded the same way.

  3. Matching. The system finds the stored vectors nearest to the query vector and returns those notes, ranked by closeness.

The practical effect: you search for the concept as you think of it now, and the note surfaces regardless of how you phrased it then. In Notez this runs on every search, alongside a keyword match, and the landing page example is real: searching "that caching idea" finds the note, because the match is on meaning, powered by embeddings.

From search to answers

Once notes are embedded, a second capability comes almost free: retrieval-augmented generation (RAG). Instead of returning a list of matching notes, the system retrieves the most relevant ones and feeds them to a language model, which composes an answer — with the source notes cited.

This changes the interaction from "find documents" to "ask questions". Notez's Ask your notes feature works this way: ask "what have I written about focus and deep work?" and it retrieves the relevant notes across your vault and answers with sources. The sources matter — an answer you can trace back to your own notes is verifiable; a bare answer is not.

Where semantic search is weak

Honesty about limits keeps expectations right:

  • Exact strings. Searching for a specific error code, flag name, or identifier is a job for keyword matching. Good systems run both — Notez pairs a keyword search with the semantic one on every query and merges the results (the hybrid search post covers the mechanics) — and when you know the exact string, search for the exact string.

  • Very short notes. A three-word note gives the embedding model little meaning to work with. It is still findable, just with less semantic advantage.

  • Recall is probabilistic. Nearest-neighbor ranking means the right note is usually at the top, not provably always. For a canonical reference you consult weekly, a favorite or a link is more reliable than any search.

What it changes about organizing notes

The interesting consequence is behavioral. Elaborate folder hierarchies and mandatory tagging schemes exist mostly to make retrieval possible under keyword search — they are pre-payment for future findability. When search works by meaning, most of that upfront tax becomes optional.

A reasonable division of labor:

  • Capture without ceremony. Write the note in whatever words come. No title, no folder decision, no tags required — semantic search will find it by content.

  • Use tags for enumeration, not retrieval. Tags earn their keep when you want all notes of a kind — everything tagged research, every 1on1 note — because "all of X" is exactly what similarity ranking does not guarantee.

  • Use links for structure. Explicit links between notes (and the backlinks they create) encode relationships search cannot infer: this decision came from that discussion.

  • Add what you open daily to favorites. Navigation beats search for the top five notes.

Does it matter in practice?

The test is simple: how often do you fail to find a note you know exists? If the answer is "regularly", the bottleneck is retrieval, and semantic search removes it more cheaply than any discipline of consistent naming ever will. Systems that depend on humans using the same words twice lose to systems that don't — because after enough months, nobody does.

Continue reading