The knowledge base is the part of a retrieval chatbot that gets the least attention and causes the most failures. Retrievers do not read documents; they match against whatever units the knowledge base exposes. Structure the units well, and both sparse and dense retrieval improve. Structure them badly, and no ranking tweak will save you. This article explains the three structural decisions that matter — fragments, fields, and metadata — and shows how they interact with a hybrid BM25-plus-dense retriever like the one ReLU.chat runs in-browser.

Fragments: One Entry, Many Pieces

A knowledge base entry should not be a wall of text. ReLU.chat splits every entry into categorized fragments, each with a type: definition (def), intuition (int), example (ex), formula (form), and application (app).

The split exists because retrievers match semantic units, not documents. A dense embedding of a paragraph that mixes a definition, a worked example, and a formula is a compromise vector: it is similar to queries about any of those things, but not very similar to any one of them. Once fragments are separated, the embedding of the definition fragment sits close to definition queries, the example fragment close to example queries, and so on. Sparse retrieval benefits too — a query asking for "an example" matches the fragment that actually contains examples instead of ranking a mixed paragraph.

Fragment categories also give the policy layer something to act on. ReLU.chat's policy has a frag_count action head that decides how many fragments a response uses; with typed fragments, that decision can be content-aware — a definition plus an example for a new concept, a formula plus an application for a how-to question.

Fields and Field Weighting

Fragments are the retrieval units, but entries still carry identifying fields: a name, aliases, and sometimes a category or domain. These fields feed sparse retrieval, and how they are indexed matters as much as the fragments themselves.

ReLU.chat uses field-weighted BM25 with k1 = 1.5 and b = 0.75 — the standard BM25 tuning that balances term-frequency saturation against document-length normalization. Field weighting is implemented by repetition at index time: entry names are repeated three times and aliases twice when the entry is indexed. Repeating a field is a crude but effective way to boost it — a term that appears three times in a name field outranks the same term appearing once in a fragment body, without changing the scoring formula. Bigram phrase matching is applied in addition, so multi-word names like "Nash equilibrium" match as a phrase rather than as two independent terms.

The effect on retrieval is direct: queries containing an entry's name or alias surface that entry's fragments ahead of generic text that happens to share words. This is what makes a knowledge base answer "what is X" questions correctly even when the dense embedding of X is fuzzy.

Metadata That Controls Behavior

Metadata is where the knowledge base starts acting like a small policy engine. ReLU.chat entries carry five metadata fields: truth_confidence, source_confidence, difficulty, style, and avoid_with.

  • truth_confidence records how certain the entry's content is — how well-established the facts are. Low-confidence entries can be deprioritized for assertive questions.
  • source_confidence records how much the source itself is trusted. An entry quoted from a primary source outranks one assembled from forum posts, other things being equal.
  • difficulty marks how advanced the content is, letting the bot match response depth to the user's question.
  • style describes the register of the content — formal, conversational, technical — which the tone head of the policy can respect.
  • avoid_with lists terms or contexts that should not trigger the entry, acting as a negative filter on retrieval.

Metadata is not decoration; it is retrieval signal. A retriever that ignores metadata returns the same top-k for "explain simply" and "derive the formula". One that uses it can boost low-difficulty fragments for the first query and formula fragments for the second. The key design point is that metadata must be queryable at scoring time, not just stored: confidence values can multiply or gate scores, difficulty can shift the ranking, and avoid_with can hard-block a fragment for specific query terms.

A worked example shows how the pieces fit together — typed fragments, weighted name fields, and metadata on one entry:

{
  "name": "Nash equilibrium",
  "aliases": ["Nash eq", "Nash"],
  "fragments": [
    { "type": "def",  "text": "A Nash equilibrium is a set of strategies where no player can improve by changing strategy alone." },
    { "type": "int",  "text": "Think of it as a stable point: everyone is already doing their best response to everyone else." },
    { "type": "ex",   "text": "In the prisoner's dilemma, both players defecting is the unique Nash equilibrium." },
    { "type": "form", "text": "Strategy profile s* is a Nash equilibrium if u_i(s*_i, s*_-i) >= u_i(s_i, s*_-i) for all players i and strategies s_i." },
    { "type": "app",  "text": "Used to analyze oligopoly pricing, auction bidding, and traffic routing." }
  ],
  "metadata": {
    "truth_confidence": 0.95,
    "source_confidence": 0.9,
    "difficulty": 2,
    "style": "formal",
    "avoid_with": ["cooperative equilibrium", "correlated equilibrium"]
  }
}

The structure is what makes the entry retrievable in five different ways — the name matches name queries, the definition matches "what is" queries, the example matches "give me an example" queries, and the metadata lets the policy tune which fragment surfaces for which user.

Structuring for Hybrid Retrieval

The fragment structure pays off most in hybrid retrieval, where sparse and dense scores are fused. ReLU.chat fuses 70% dense cosine similarity and 30% sparse BM25 into an ensemble rank. Dense retrieval works best on coherent semantic units — the fragment types provide exactly that. Sparse retrieval works best when the exact terms appear in the fragment — the repeated name and alias fields guarantee that. The two systems reinforce each other: the dense side catches paraphrase queries ("why is nobody switching?"), and the sparse side catches exact-term queries ("Nash equilibrium formula"). Well-structured fragments are what keep both sides from contradicting each other, because the same unit is scored twice instead of two different units being scored once each.

Key Takeaway

Knowledge base structure decides retrieval quality before any model is involved. Split entries into typed fragments so dense embeddings stay semantically coherent; weight name and alias fields at index time so sparse retrieval can anchor on exact terms; and store queryable metadata — confidence, difficulty, style, avoid lists — so ranking and policy can respond to the user rather than to the corpus alone.