What is a knowledge base?

What exactly are we talking about?

A knowledge base is an organised body of information built to be queried. That last part is what matters: what separates a knowledge base from a folder of documents is that it is structured around the questions people will ask it, not around the order in which content arrived.

The term comes from symbolic AI in the 1970s, where the knowledge base was the body of facts and rules an expert system consulted — MYCIN, developed at Stanford between 1972 and 1976 to diagnose bacterial infections, is the canonical example. Usage later broadened to cover any structured documentation.

What are the three main forms?

Form	Audience	Typical content	Success measure
Public	Customers, users	FAQs, guides, troubleshooting	Fewer support tickets
Internal	Employees, teams	Procedures, decisions, runbooks	Self-service without asking a colleague
Personal	One person	Reading, notes, sources	Reuse in actual output

All three fail the same way, for the same reason. The content is there, but the person looking for it does not find it, so they redo the work or ask someone. Every time that happens, the odds that anyone consults the base next time drop a little further.

How do you build a base people actually use?

1. Start from questions, not documents. List the twenty questions people genuinely ask, then write the pages that answer them. The reverse order produces complete documentation nobody queries.
2. One page per question. A page covering six topics will rank well for none of them and will be abandoned mid-read.
3. Date it and sign it. A page with no update date and no author cannot be judged by its reader, who will go and verify it elsewhere.
4. Plan for expiry. Set a review cadence and archive without sentiment. Stale content costs more than missing content, because it actively misleads.
5. Track failed searches. Zero-result queries are the most reliable shopping list you will ever get for what to write next.

Why is search the critical point?

A knowledge base is reached through search, not navigation. Past a few hundred entries nobody browses the tree: people type three words and judge the entire base on the first five results. Search quality therefore sets the perceived value of all the content behind it.

The problem is harder than it looks. Keyword search requires the reader to guess the vocabulary the writer used — the vocabulary problem, quantified as early as 1987 by George Furnas and his co-authors: two people pick the same term for the same object in fewer than 20% of cases.

Semantic search fixes that flaw and introduces another one: the threshold. On a measured corpus of 948 syntheses embedded with the bge-m3 model, the query "feudalism" — five genuinely relevant documents in the base — tops out at 0.510 similarity, while a query matching nothing tops out at 0.424. Nine hundredths separate the two situations. An article about Cleopatra still scores 0.350 against "feudalism", because any two texts in the same language share a floor of resemblance. There is no natural zero, so there is no universal threshold.

How do you get search that actually returns the source?

Two mechanisms. First, merge both signals: semantic catches different phrasings, lexical guarantees exact terms, proper nouns and references included. Second, stop judging relevance on an absolute value and judge it on distance: a relevant document stands out from the score distribution of its own query, whereas on a query with no answer every candidate bunches together.

That is how Synthiz works. Search combines semantic and lexical over normalised scores, and relevance is computed per query as mean + z*stddev across the distribution, with an absolute floor so a lone document cannot artificially stand out when nothing matches. In practice you retrieve a source without remembering the words you used to describe it, and a query with no answer returns zero results rather than noise — the only honest answer, and the one that keeps trust in the base intact.