One vector blurs a document about many topics

Search for agents usually turns each document into one vector, a list of numbers that stands for its meaning. Think of a library that gives every book one index card. If a book covers ten topics, its card mixes all ten. A question about one chapter then only half matches. We asked how much is lost, and whether several cards per document win it back. They do. Most of the gain comes from simply having more pieces to search. Pieces shaped around one topic add a smaller extra, and only when questions target one topic.

This is the evidence for the first of the context patterns. It shapes how agents find what they know, the subject of knowledge and memory. The work belongs to the agent data engineering layer (R14). It sits at the chunk and embed stages of the data-to-memory pipeline. The research name for this loss is aspect dilution. An aspectAspect (of a document). One of the distinct things a document is about. An email that confirms a delivery date, flags a billing error, and asks for a contract change has three aspects; a question usually targets one of them. is one topic a document covers.

The test: three setups with one encoder

A purpose card is one searchable piece per topic in a document, with its own vector. Giving a document several cards means giving it several vectors. Cutting the same document into fixed windows also gives several vectors. So if cards beat one pooled vectorPooled (single-vector) embedding. One numeric fingerprint for a whole document. Cheap and standard, but for a document about several things it is an average of all of them, so it matches each of them weakly., that proves nothing about topics. Plain chunks might beat it too. Every test therefore compares three setups.

Every setup uses the same encoder, all-MiniLM-L6-v2. An encoder is the model that turns text into vectors. This one is small and general-purpose. Everything is scored per document. The control is matchedMatched control. A comparison arm given the same budget as the method under test, here the same number of embeddings per document, so the experiment measures the idea rather than the extra capacity.: it gets the same number of pieces per document as the cards.

Step 1: the loss grows with every topic

We built a synthetic collection where we control the number of topics per document. Each document joins k passages from k of ten unrelated topic pools. The pools are legal, logistics, finance, engineering, personnel, marketing, facilities, research, security and procurement. Each passage states one fact. Each query asks about one fact, in wording that shares no template with the passages. Every document holding that fact counts as relevant. So relevance comes from how the data was built, not from a guess. Relevant documents per query grow from 3.7 at k=1 to 33 at k=10. Each setting has five hundred documents and two hundred queries.

Cards are built around anchors. An anchor is a short description of a topic. The card builder uses it to decide which passages go on which card. We tried two kinds. Template anchors are taken from the generator's own sentence templates. Hand-written anchors are short topic descriptions a person wrote, with none of the generator's wording.

The score is nDCG@10nDCG@10. A 0 to 1 score of how good the first ten search results are. It rewards putting the right documents near the top and counts every relevant document the judges marked. A difference of 0.03 is small but real on a few hundred queries; 0.2 is large., a 0 to 1 measure of how good the top ten results are.

The pooled index falls from 0.815 at one topic to 0.294 at ten. Every split setup stays above 0.63.

Against matched chunks, cards built from hand-written anchors gain more as topics grow.

At k=10 the cards use 9.8 pieces per document. The control uses 13.0. That is 25 percent fewer vectors. An earlier version of the same test used template anchors. It gave +0.109 at k=10. The cruder hand-written anchors do better for a simple reason. A topic description is a better stand-in for a topic than one sentence carrying one fact.

Step 2: what the theory predicts

The cause behaves roughly as theory says. We measured how close each query sits to its target document. Closeness here is cosine similarity, a measure of how alike two vectors are. Against the best card, it stays flat as topics grow: 0.476 at k=1 and 0.466 at k=10. Against the pooled vector, it falls steadily from 0.476 to 0.225.

Simple theory treats the pooled vector as the average of k unrelated topic vectors. That predicts closeness falls with one over the square root of k. The measured fall follows k to the power -0.32. It stays above the prediction at every k. Real topics are not fully unrelated. The passages share style and grammar, and encoders squeeze differences together. So the theory gives the worst case for dilution. It is not a forecast the data confirm.

Step 3: more pieces, or better pieces? The LIMIT test

LIMIT is a public test set built to break one-vector search (Weller, Boratko, Naim, Lee, arXiv:2508.21038, Aug 2025). Its authors prove a limit. For a vector of fixed size, some groups of documents can never come back together in the top results. Leading embedding models hit that limit in practice. Each LIMIT document names a person and lists things they like. Each query asks who likes one specific thing. The small version has 46 documents, 44 attributes each, and 1,000 queries. The task looks trivial, yet it defeats meaning-based search. It also gives a perfect split for free: one card per attribute.

We first credited the cards' 0.674 gain to their topic shape, because 30-word chunks gained only 0.076. That was wrong. A reviewer whose job was to break the result reran the test. It changed only the chunk size, as described in how to test a context design. The score rose smoothly with the number of pieces per document.

Two things follow. First, more pieces are needed, and they explain most of the LIMIT result. The topic split must match the questions for the rest of the gain to appear. Second, LIMIT is a best case for cards. It hands over a perfect split, and its queries are exact-attribute lookups. That is why BM25BM25 (keyword search). The classic keyword ranking formula behind most search engines. It matches exact words, so it wins on names, codes, and quotations, where meaning-based search is weak. keyword search wins outright and the hybridHybrid retrieval (reciprocal rank fusion). Running keyword search and meaning-based search side by side and merging the two ranked lists by rank position, so each covers the other's blind spots. only matches it. Real documents arrive unsplit. Someone has to design the card types, and they may be wrong. So read the table as the most that topic-shaped cards can buy. Storage cost depends on the documents too. LIMIT needed 44 cards per document, far more than the small number the pattern assumes elsewhere.

A worked example

A utility's field work order often records a fault, the parts used and a safety note. One vector for the whole order blurs all three. A question about one safety issue then matches the order weakly. Plain chunks are the first fix. Topic cards are worth adding only if they beat those chunks on the questions engineers really ask. This example shows the shape of the problem. We did not test work orders.

What we conclude

Evidence and limits

Measured by the author The synthetic and LIMIT results reproduced exactly, or to floating-point precision, on two machines with two processor types. We ran both machines ourselves. Nobody else has repeated the tests yet.

The synthetic collection is built, not found. The one positive result for topic cards, +0.188, rests on it. The next test that matters is a real collection with single-topic questions judged by people.

Next step

See where topic cards lose, on real scientific text. Or go back to the nine context patterns.