Qdrant and DRAG with KNEE: Making RAG Adaptive Without Wasting Tokens

A practical walkthrough has been published on making RAG systems less wasteful and more accurate. It centers on DRAG with KNEE, an approach built on Qdrant and Python that sets the amount of context dynamically instead of relying on a fixed top_k.

Why static top_k breaks down

Almost anyone who has built RAG over long PDFs has hit the same problem. Retrieve too few chunks, and the model misses important context and starts guessing. Retrieve too many, and noise floods the prompt, bringing higher cost, higher latency and a greater risk that the LLM latches onto a random fragment. In this setup, a single top_k parameter tries to solve very different problems and almost always does so poorly.

The author calls this trade-off a fundamental weakness of classic RAG. A fixed number of documents ignores the type of query, the structure of the source file and the density of useful information in the corpus. A couple of passages can be enough for a short fact, but not for a complex question about a multi-page document. As a result, the system either starves the model of context or overloads it with irrelevant text and burns through the token budget.

How DRAG works

The idea behind DRAG with KNEE is not just to look for similar chunks, but first to treat documents as a hierarchy and then decide dynamically where to stop selection. Instead of a hard limit, the algorithm analyzes the distribution of relevance scores and looks for an inflection point, the "knee" beyond which each added fragment contributes less and less. Everything in the long tail past that point can be cut without a noticeable loss of meaning.

In practice, this makes context retrieval more adaptive. The system is not obliged to return the same number of chunks for every query: sometimes it will be three, sometimes ten, and sometimes several linked groups from different parts of a document. This lets RAG fit the real structure of the knowledge rather than a constant chosen in advance.

• First, candidates are found by vector similarity
• Then they are grouped and ordered by document and level
• Next, the algorithm looks for the point where usefulness starts to drop sharply
• Only the relevant core, without the long tail of noise, ends up in the final context

This approach is especially useful where knowledge lives not in a tidy FAQ base but in scattered instructions, reports, policies and large PDFs. In such corpora, distances between fragments say little on their own unless you account for how the fragments relate to each other and how quickly their value for the answer falls off. This is where geometric analysis stops being a mathematical ornament and becomes a practical filter.

Why Qdrant

A plus of the article is that it does not drift into pure theory. The author shows how to build such a pipeline with Qdrant and Python, a familiar stack already used in many RAG projects. Qdrant handles vector search and working with candidates, while the DRAG with KNEE logic adds an adaptation layer on top: not just finding similar material, but working out how much of it the model actually needs right now.

For teams that have already deployed standard retrieval and hit a wall on answer quality or inference costs, this is an important signal. The problem may lie not in the embeddings or the LLM itself, but in exactly how you slice and serve context. Replacing a static top_k with dynamic cutoff at the inflection point can reduce noise and improve accuracy at the same time, without rebuilding the architecture.

What this means

RAG is gradually moving away from crude one-parameter-fits-all tuning. The DRAG with KNEE material shows a simple but important shift: the next level of quality comes not only from good retrieval but from knowing when to stop, so the LLM gets enough context to answer rather than a random pile of text.