Christophe MontagneInterim CTO · Advisory

Building It/2 min read

03Not all knowledge is alike

Five questions that decide how a source is treated: index it, query it live, extract it, or only point to it.

A common assumption is that the knowledge base is a single pipeline: load the documents, cut them into passages, index them, and the job is done. That works for a demo on a clean sample. It fails on real company knowledge, because different kinds of knowledge need different treatment, and the data dictates the treatment, not the tool.

Five questions reveal what a source needs:

  • How structured is it: rows in a database, tables in a report, or free text?
  • How fast does it change: yearly, monthly, by the minute?
  • What is the smallest piece that is true on its own: a figure, a table, a step, a whole procedure?
  • What does "version" mean here: a revision, an accounting period, a timestamp?
  • At what level are access rights set: document, section, row?

Four familiar kinds of knowledge give very different answers (Figure 3).

How structured it is free text rows and fields How fast it changes rarely constantly Procedures point to the whole procedure Manuals index text, extract tables Financial data query the source, never compute Inventory query live, never copy index query the system of record point to the source
Figure 3. Four kinds of knowledge, by structure and rate of change

Financial data is structured and must be exact. The system queries the governed source and never computes or estimates a figure itself. The hard part is definitions: which revenue, which scope, which period.

Inventory changes constantly, so any copy is stale within hours. The system queries it live.

Manuals are the classic case for indexing: long, versioned, often scanned. What each passage applies to decides everything, and tables such as torque values are better extracted as structured data.

Procedures look like manuals but behave differently. Order, completeness, approval status and effective date are part of the content, and a summary that drops one step is a wrong answer. The system often points to the full procedure rather than paraphrasing it.

For each source, then, the knowledge base does one of four things: index it, query it live, extract it into structured form, or only point to it. Real collections mix all four. In the rail company, the question "what torque, for this locomotive?" may need the retrofit records, which behave like an inventory, to identify the exact configuration, and then the manual for the value.

This is why tools are chosen last. A library built to index text is the wrong tool for a ledger, however good it is.