Retrieval on AIBussin — AI applications, systems and books

What Remembering Means

Mon, 14 Sep 2026 05:00:01 +0100

A small team spends a week arguing about where to keep its event log.

They start with SQLite. It works at first, then slows to a crawl once several writers hit it at once. So they move the event store to PostgreSQL and write down why. Within a month nobody thinks about it any more. It is just how the system works.

A few months later, a new contributor asks the team’s AI assistant to scaffold a second service, with its own event log.

From Similarity to Search

Mon, 07 Sep 2026 11:00:00 +0000

Part III — Retrieval Is an Experiment

Retrieval in four lines

# assume embed() returns L2-normalized vectors, so dot product == cosine (Chapter 4)
query_vec = embed(query) # one unit vector
scores = corpus_vecs @ query_vec # a cosine score for every document
order = np.argsort(-scores) # rank all n documents, best first
results = [corpus[i] for i in order[:k]] # keep the top k

That is the whole primitive for the simple policy shown here. A vector database may add several different kinds of machinery around it: an ANN index or quantization may approximate the same ranking more cheaply; sharding may distribute the computation; filtering may change the eligible candidate set; persistence and replication may make the system operable. Do not collapse all of those into “faster search” — some preserve the target policy, some approximate it, and some redefine it.

Bring Back Only What You Need

Wed, 23 Sep 2026 05:00:14 +0100

Chapter 13 left the model holding a tidy live context and a shelf of external artifacts:

Incident 17 — lock-order inversion.
Evidence: artifact://incident-17

plus five more references of the same shape. Then the current task changes. The user asks why the deadlock appeared only under concurrent import. The incident artifact probably matters. So might the benchmark report, the migration plan, and the compiler run. The naive response is to load everything, which recreates within one turn the exact occupancy problem Chapter 13 solved. Leaving was only half the problem. Existence plus recoverability does not mean admission. This chapter decides what comes back.

Context Is a Bottleneck

Mon, 14 Sep 2026 05:00:14 +0100

Chapter 10 took selection as far as a frozen run has taken it: which memories the present work needs, admitted by an explicit, traceable policy at a fixed budget.

This chapter shows selection is not enough. Admission assumes the admitted memories fit. Increasingly they do not — and the Chapter 10 run puts a number on the shortfall.

The ledger oracle reaches perfect required-evidence recall on a mean of 587 estimated tokens. The best non-oracle Chapter 10 condition spends 1,161 to reach 0.902 recall. Rendered with the source headers and validity marks the reader actually sees, those become roughly 805 against 1,505. The gap survives rendering.

Search, Memory and Long Context

Fri, 28 Aug 2026 11:10:00 +0100

Chapter 15 measured an agent that had every advantage. Two files, one defect, a bounded tool surface, a budget it used well. It found both implicated files, held both halves of the bug in context, and still stopped one step short. That was a reasoning failure, and Chapter 17 exists to attack it.

This chapter is about the problem that sits before the reasoning problem. The fixture had two files. A real repository has thousands, and a bounded tool surface does not tell the program which of them to read. Something has to decide what evidence the program even looks at, and that decision is not one mechanism. It is at least five, and they are routinely collapsed into a single word.

Retrieval Is Not Geometry

Wed, 09 Sep 2026 01:50:00 +0000

Part VI — Crossing Embedding Spaces · Did it find the counterpart, or recreate the neighborhood?

The result that looks like success

Fit a bridge, translate a held-out source vector, and ask the simplest possible question: does the exact native target counterpart show up nearby? On the Wave 6 benchmark, for a paired ridge bridge translating mxbai-embed-large-v1 into Qwen3-Embedding-8B, the answer is about as good as that question can get. Across 589 held-out sentences, using the same fitted bridge and the same translated vectors throughout:

RELATE: Searching Embeddings by Relation, Not Just Similarity

Wed, 05 Aug 2026 23:24:45 +0100

Embeddings are everywhere in modern AI.

They power semantic search, retrieval-augmented generation, recommendations, clustering, duplicate detection, code search, memory systems, and many of the mechanisms through which an AI system decides what information is relevant.

Yet most systems interrogate embeddings in essentially the same way:

Take two vectors and calculate cosine similarity.

That is useful. But it also makes a strong assumption.

It assumes that the information we care about is expressed directly through the default geometry of the embedding space.