ReMyndsemantic search vs keyword search
keyword search looks for the letters you typed. semantic search looks for the meaning behind them. that one difference explains why your company wiki returns nothing useful, why a chatbot sometimes finds the right paragraph from a completely different wording, and why almost every serious system in 2026 runs both at once.
this is the plain version: how each method works, what each one is genuinely good at, where each one falls over, and the failure they share. current as of september 2026.
what is keyword search?
keyword search matches strings against strings, and it does it very fast. you type a word, the engine looks up which documents contain that word, and it ranks them by how unusual the word is and how often it appears.
the standard implementations are decades old and extremely good. full text search in sqlite, postgres, elasticsearch and spotlight all work this way. they build an inverted index, which is a lookup table from every word to the list of documents containing it.
that structure is why keyword search is fast. searching 100,000 documents is a dictionary lookup, not a scan.
it also does a little linguistic work. stemming folds "recording" and "recorded" together. stopword removal drops "the" and "of". but the match is still, underneath, characters against characters.
what it is great at: exact identifiers. an error code, a person's surname, an invoice number, a function name, a domain. if you know the literal string, nothing beats it.
where it fails: you searched for "quarterly revenue" and the document says "q3 topline". zero results, and the document was right there.
what is semantic search?
semantic search matches meaning by turning text into numbers. an embedding model reads a chunk of text and outputs a vector, a list of numbers, commonly 384, 768 or 1,536 of them, that positions that text in a space where related meanings sit close together.
your query gets embedded the same way. the engine then finds the vectors nearest to your query vector, usually by cosine similarity, and returns the text those vectors came from.
the useful consequence is that "how do i stop my laptop overheating" can return a document titled "thermal throttling on apple silicon" which shares not one word with the query.
this is also called vector search, and the database that stores those vectors is a vector database. the terms get used interchangeably in marketing copy and they mostly refer to the same mechanism.
how does semantic search actually work, step by step?
the pipeline is four steps and it is worth knowing because every failure mode lives in one of them.
- chunking. documents are split into pieces, often a few hundred words. chunk too big and the vector averages away the detail. chunk too small and it loses the context that made it meaningful.
- embedding. each chunk goes through the model and becomes a vector. this is the expensive step at index time.
- storage. vectors go into an index built for nearest neighbour lookup, so you are not comparing your query against all 100,000 vectors one by one. embedding 10,000 chunks is a real one time cost. keyword indexing the same 10,000 chunks is close to free.
- retrieval. your query is embedded, the nearest chunks come back, and something ranks them.
if you have read what is rag, steps one through four are the retrieval half of it. rag is this pipeline plus a language model that reads the results and writes an answer.
who ships semantic search in 2026?
almost every large vendor does now, and mostly without using the phrase. microsoft copilot retrieves over your work data before it answers. openai, anthropic and google all pair retrieval with a model rather than trusting what the model happened to memorise in training.
the personal versions landed this year. apple shipped siri ai with onscreen awareness and personal context on june 8, 2026. openai shipped a background memory system on june 4, 2026, and anthropic reworked claude's memory into editable entries on july 10, 2026. microsoft rebuilt recall for windows after its 2024 reception, with biometric gating and on device encryption.
none of that changes the index problem further down this page. a better retriever over a corpus that never recorded your afternoon is still a better retriever over the wrong corpus.
semantic search vs keyword search, side by side
the two methods are not competitors so much as opposites, and the table is the fastest way to see it.
| keyword search | semantic search | |
|---|---|---|
| matches on | literal characters | meaning, as a vector |
| finds "q3 topline" for "quarterly revenue" | no | usually |
| finds error code E4021 | yes, exactly | often not |
| index cost | cheap | an embedding model pass per chunk |
| query cost | a dictionary lookup | a vector comparison across the index |
| explainability | you can see why it matched | you cannot, really |
| typo tolerance | poor without fuzzy matching | decent |
| best for | identifiers, names, code, quotes | questions, paraphrase, vague memory |
the row that decides most real systems is the explainability one. keyword search that returns nothing is annoying but honest. semantic search never returns nothing. it returns the five closest things, which may all be wrong, and it looks equally confident either way.
which should you use, and when?
pick by what you know about the thing you are looking for, not by which technology sounds more modern.
- you know the exact string. keyword. an order id, a stack trace, a person's name, a config key.
- you remember the idea but not the words. semantic. this is the "it was about pricing for enterprise customers" case.
- you have a question rather than a term. semantic, then a model on top, which is rag.
- you are searching code or logs. keyword, overwhelmingly. identifiers are the whole point and paraphrase is meaningless.
- you do not know which case you are in. hybrid, which is what most products ship.
hybrid search runs both queries and merges the ranked lists, commonly with reciprocal rank fusion. it is not elegant. it wins because the two methods miss different things, so the union is better than either.
why does search feel worse than it should?
searching is the single most common thing people ask ai to do, and the tooling still disappoints, because the hard part was never the matching algorithm.
per anthropic's economic index for may 2026, the top work task in sampled conversations is "search electronic sources, such as databases or repositories, or manual sources for information" at 4.95%, and the second is searching reference materials at 3.74%. that is 8.69% of everything, and both are retrieval. knowledge retrieval and enterprise search shows up separately as 3.61% of request topics, personal ai assistant at 2.86%, and conversation and meeting intelligence at 0.26%. work is 43.36% of classified conversations, so this is not a hobbyist pattern.
so the demand is enormous. the supply problem is not that keyword search is dumb or that vectors are expensive. it is that both methods can only search an index, and the index only contains what something bothered to record.
the failure both methods share
neither method can find text that was never captured. this is the part that vendor comparisons skip, and it is the reason most personal searches fail.
the number on a slide someone screenshared for 40 seconds was never a file. the error in a terminal you scrolled past was never a file. the message in an app that does not export was never a file. no embedding model can vectorise something nobody wrote down, and no inverted index can point at it.
that is a capture problem, not a ranking problem. it is also why ocr matters more than the choice of search algorithm for personal recall: ocr is what turns pixels into text that either method can then index. the practical version of this is how to find something you saw on your screen.
where remynd sits
remynd records the focused window on a mac, runs ocr locally through apple's vision framework, and keeps the resulting index on your machine, so the text that was never a file becomes searchable text that is.
search over that history runs against the local index. asking a question is the other mode: the retrieved slices go to a cloud model, which is where the network comes in, so this is not a claim that nothing ever leaves your mac. capture, ocr and storage stay local by default, recordings default to 30 days of retention, and you can exclude specific apps or sites from capture entirely.
it is also worth knowing what happened to the last archive in this category. rewind defined it on the mac, and in december 2025 meta acquired the company and shipped an update that disabled screen and audio capture. an index you cannot export is not an archive you own, which is the argument in what happens to your data when an ai app shuts down.
for the category rather than the mechanism, start with screen memory. for how retrieved text gets fed to a model, read what is context engineering.
download remynd free for mac → free to download, runs locally, no card.