I’m an independent researcher working on a narrow but stubborn problem in retrieval-augmented generation (RAG): teaching these systems to be smarter about which pieces of text they keep and which they can safely swap out. This page tracks that work as it develops.

The line of work: multi-view retrieval with structural markers

RAG systems chop documents into “chunks,” turn each chunk into a vector, and store the vectors in a database. When you ask a question, the system finds the chunks whose vectors sit closest to your question and hands those to a language model as context. Every system that does this has to pick a chunk size, and the choice is a genuine trade-off: small chunks match a query precisely but strip away surrounding context, while large chunks preserve context but bury the relevant sentence in unrelated text.

My current work asks what happens if you refuse to pick. Instead of one size, slice the same document at several fixed sizes on a shared grid — starting every cut from the beginning of the document. When you do that, the same content keeps reappearing across sizes in the retrieved set.

The idea

Those reappearances aren’t a coincidence, and they aren’t fuzzy. Because every size starts from the same origin, a larger chunk exactly contains the smaller chunks that fall inside it. The relationships nest — a large chunk contains a medium one, which contains a small one — forming a structure I call a containment forest.

The useful part is that this structure is detectable for free. Match a short hash fingerprint (SHA-256) of each chunk’s bytes and you can recover the entire forest without any AI in the loop and without any judgment call. Because the containment is exact, it licenses a safe operation: if a small chunk is relevant to a query, you can swap it for its larger enclosing parent without losing any of the relevant content — the parent still contains the small chunk’s bytes, verbatim. That gives a RAG system a concrete lever for managing its token budget: retrieve small for precision, then trade up to the parent when there’s room for more context.

Markers versus cosine similarity

A fair question is whether the cosine similarity these systems already compute can do this job. It can’t do it cleanly. Cosine similarity is a useful but noisy proxy for containment, and it’s symmetric — it gives the same score for a pair in either direction, so it can’t tell you which chunk contains which. Direction is exactly what the swap-upward operation needs. The hash markers, by contrast, are exact and directional. The framing that matters: cosine is a noisy signal; the markers are ground truth.

Why it matters

The payoff is that a system no longer has to commit to a chunk size in advance. It can retrieve at several sizes and then decide, at generation time and against the token budget it actually has, whether to keep the tight match or trade up to its more spacious parent. The decision moves from a guess made when the index is built to an informed choice made when the question is asked.

Open source

The proof-of-concept code is public and built for reproducibility:

github.com/mrissover/slicing-proof — Java 21, Spring Boot, MIT-licensed. It leans on two open-source services, Ollama and Qdrant, that both run locally, and it pins its dependencies and random seed so the results reproduce. The full pipeline runs on a laptop.

Status

This is early, active research — a result I’m still building on rather than a finished story. I’ll add papers, write-ups, and follow-on work here as they’re ready.

Read more

• The Same Text, Sliced Every Which Way — a plain-language walk through the idea.