Every team with a wiki has run this experiment. Someone searches "how do I get reimbursed for travel", gets nothing useful, asks in Slack, and a colleague replies with a link to a page titled "T&E policy". The answer existed. Search couldn't find it. That gap, between the words people search with and the words documents happen to use, is the whole difference between keyword search and semantic search, and it explains more about why knowledge bases feel broken than any amount of "just tag your pages better".
Keyword search, in plain English
Keyword search matches the words in your query against the words in documents. Modern versions are cleverer than that sounds: they stem words so "reimbursed" matches "reimbursement", weight rare terms over common ones, and rank pages where your terms cluster together. Fifty years of refinement have made keyword search extremely good at what it does.
What it does, though, is match strings. It has no idea that "get money back for travel" and "T&E policy" are about the same thing, because they share no words. When the searcher's vocabulary and the author's vocabulary line up, keyword search is fast, precise, and cheap. When they don't, it returns nothing, and the knowledge might as well not exist.
Semantic search, in plain English
Semantic search matches meaning instead of strings. Every document (and every query) is converted into a vector embedding, a long list of numbers that acts like coordinates for meaning: texts about similar things end up near each other, regardless of the words they use. Searching becomes "find the passages whose coordinates are closest to my question's coordinates".
That's the entire trick. "Get money back for travel" and "employees may claim travel expenses within 30 days" land close together in that space because they mean similar things, so the T&E page surfaces even though not one word overlaps with the query.
The trade-offs are real too. Semantic search is fuzzier by nature: it can surface things that are merely related when you wanted an exact match, it's harder to reason about ("why did this rank first?"), and it will cheerfully find you the most semantically similar wrong answer when nothing genuinely relevant exists.
When each one wins
| You're searching for | Winner | Why |
|---|---|---|
| An exact identifier: error code, invoice number, "PROJ-1234" | Keyword | Exact strings are the one thing embeddings are worse at |
| A concept you can't name precisely: "the thing about laptop refresh timing" | Semantic | Meaning matches even when vocabulary doesn't |
| A quote or phrase you remember verbatim | Keyword | String match is definitionally perfect here |
| A question phrased in your words, answered in someone else's | Semantic | The T&E problem, solved |
| A person, product, or codename | Keyword | Names are tokens, not meanings |
| "Do we have anything about X?" exploration | Semantic | Nearby-in-meaning beats contains-the-word |
Notice the pattern: keyword search wins when you know the exact words, semantic search wins when you know what you mean. Real search problems are a mix, which is why serious systems run hybrid search, both engines at once, merging the results. The question was never really "which one", it's "why would you settle for only one".
Why your wiki feels unsearchable
Knowledge bases are close to a worst-case environment for pure keyword search:
- Vocabulary drifts. The doc says "provisioning", the searcher says "setup". The doc says "PTO", the new hire says "vacation". Every mismatch is a silent miss.
- Titles are written for authors, not searchers. "Q3 Platform Migration Retro" contains none of the words in "why did we move off Heroku".
- The answer is a sentence, not a page. Even when search finds the right page, it hands you 3,000 words and wishes you luck. The fact you need is in paragraph fourteen.
- Stale pages match as well as current ones. Keyword relevance knows nothing about which of the four "deployment process" pages is the one people actually follow.
The first two are vocabulary-mismatch problems that semantic retrieval largely dissolves. The last two point at something beyond search entirely.
From finding pages to getting answers
Here's the shift that matters: once retrieval works on meaning, you can stop returning pages and start returning answers. This is retrieval-augmented Q&A, and it's the same embedding machinery pointed at a better goal. Your question is matched against passages (not just titles), the most relevant passages are retrieved, and a model composes an answer from them, citing where each claim came from.
That last clause is what keeps meaning-based answers honest. Fuzzier retrieval plus a fluent model could just produce confident nonsense; citations back to the exact source sentence make every answer checkable. It's the difference between search that ends with "here are ten links" and search that ends with "the reimbursement window is 30 days, and here's the sentence that says so".
This is the model Sidenote applies to the pages you already have open. Reading a Confluence space? Sidenote reads the live page in place, read-only, and answers questions from its actual text, with a citation on every claim that scrolls to the exact sentence when clicked. No re-indexing project, no export, no separate search silo, and there's a practical walkthrough in our guide to finding information in your company wiki. Cited summaries, explanations, and glossaries are on the free plan; asking questions in chat is Pro, with an opt-in 7-day trial that needs no card.
Frequently asked questions
Is semantic search just better than keyword search?
No, it's better at different queries. Semantic search wins when the searcher's words differ from the document's words, which in a knowledge base is constantly. Keyword search wins on exact strings: codes, names, verbatim phrases. That's why production systems increasingly run hybrid search rather than replacing one with the other.
Do I need a vector database to get semantic search on my docs?
Only if you're building the pipeline yourself: embedding documents, storing vectors, running similarity search at scale. If you're consuming rather than building, tools do this under the hood. Sidenote, for instance, retrieves by meaning from the page you have open without you standing up any infrastructure.
What is hybrid search?
Running keyword and semantic retrieval together and merging the ranked results, so exact matches and meaning matches both surface. It exists because each method has blind spots the other covers: embeddings fumble exact identifiers, keywords miss vocabulary mismatches. Most modern enterprise search products are hybrid, whatever the marketing name.
How is asking a document a question different from searching it?
Search returns locations; a question returns a claim. Meaning-based Q&A retrieves the relevant passages and composes an answer from them, so instead of opening the right page and skimming for paragraph fourteen, you get the fact plus a citation to the sentence it came from. The citation is essential: it's what makes the composed answer verifiable rather than merely plausible.