HNSW index

The exact way to find the records nearest a query vector is to compute a distance against every record. At a thousand records that is fine; at millions it means millions of computations per query, making real-time answers impossible.

HNSW gets past this with an approximate solution. Vectors are arranged in a layered graph; search descends into a coarse region at the top layer and refines through lower layers. It finds the correct neighbours with very high probability without scanning every record.

"Approximate" does not mean incorrect; it means the probability of missing the true nearest neighbour is small but not zero. Index parameters let you tune that probability: denser graph connectivity raises recall at the cost of memory and indexing time.

In document search that trade is usually accepted comfortably. Retrieval returns not the single closest passage but the closest several, and the model uses whichever is relevant; missing one neighbour rarely changes the outcome.

On small archives the index type is irrelevant; exact search over a few thousand vectors is fast enough. The difference appears as the archive grows.

In KobiGPT the Pro plan reaches 12500 documents, and since each document is split into multiple chunks, the vector count is a multiple of the document count. At that scale index structure is the main determinant of query latency.

A useful way to evaluate hnsw is to follow one real question from the source document to the final answer. Record which file was selected, what context reached the model, and what a reviewer would need to verify. This turns a definition into an operational check and makes the result comparable across teams.

The same check should include ownership and change management. Decide who updates the relevant documents, how an outdated result is reported, and which access boundary applies. KobiGPT can provide the assistant and the cited document context, but the organisation still owns the source material, permissions, and the decision made from the answer.