Qdrant and DRAG with KNEE: How to Make RAG Adaptive and Avoid Wasting Extra Tokens

Вышел практический разбор того, как сделать RAG-систему менее прожорливой и более точной. В центре — DRAG with KNEE, подход на базе Qdrant и Python, который подбирает объем контекста динамически, а не по фиксированному top_k.

Почему static top_k ломается

Почти любой, кто собирал RAG поверх длинных PDF, сталкивался с одной и той же проблемой: если взять слишком мало чанков, модель не видит важный контекст и начинает додумывать. Если взять слишком много, в промпт уезжает шум, а вместе с ним растут стоимость, задержка и риск того, что LLM зацепится за случайный фрагмент. Один и тот же параметр top_k в такой схеме пытается решить слишком разные задачи и почти всегда делает это плохо.

Автор называет этот компромисс фундаментальной слабостью классического RAG. Фиксированное число документов не учитывает ни тип запроса, ни структуру исходного файла, ни плотность полезной информации внутри корпуса. Для короткого факта бывает достаточно пары отрывков, а для сложного вопроса по многостраничному документу — уже нет.

В результате система либо недокармливает модель контекстом, либо, наоборот, перегружает её нерелевантным текстом и сжигает бюджет на токены.

Как устроен DRAG

Идея DRAG with KNEE в том, чтобы не просто искать похожие куски, а сначала смотреть на документы как на иерархию, а потом динамически решать, где остановить отбор. Вместо жёсткого ограничения алгоритм анализирует распределение релевантности и ищет точку перегиба — то самое колено, после которого добавляемые фрагменты дают всё меньше пользы. Всё, что уходит в длинный хвост после этой точки, можно отсечь без заметной потери смысла.

На практике это выглядит как более адаптивная стратегия извлечения контекста. Система не обязана возвращать одинаковое количество чанков для каждого запроса: в одном случае их будет три, в другом десять, а в третьем — несколько связанных групп из разных частей документа. За счёт этого RAG лучше подстраивается под реальную структуру знаний, а не под заранее выбранную константу.

• Сначала находятся кандидаты по векторной близости Затем они группируются и упорядочиваются по документам и уровням После этого алгоритм ищет точку, где полезность резко начинает падать * В итоговый контекст попадает только релевантное ядро без длинного хвоста шума Такой подход особенно полезен там, где знания лежат не в аккуратной базе FAQ, а в разрозненных инструкциях, отчётах, регламентах и больших PDF. В подобных корпусах расстояния между фрагментами сами по себе мало что говорят, если не учитывать, как эти фрагменты связаны между собой и как быстро падает их ценность для ответа. Именно здесь геометрический анализ становится не математическим украшением, а практическим фильтром.

Зачем тут Qdrant Отдельный плюс статьи — она не уходит в чистую теорию.

Автор показывает, как собрать такой пайплайн с помощью Qdrant и Python, то есть на знакомом стеке, который уже используется во многих RAG-проектах. Qdrant отвечает за векторный поиск и работу с кандидатами, а логика DRAG with KNEE добавляет поверх него слой адаптации: не просто найти похожее, а понять, сколько похожего действительно нужно отдать модели прямо сейчас. Для команд, которые уже внедрили обычный retrieval и упёрлись в качество ответов или расходы на inference, это важный сигнал. Проблема может быть не в embeddings и не в самой LLM, а в том, как именно вы режете и подаёте контекст. Если заменить статический top_k на динамическое отсечение по точке перегиба, можно одновременно снизить шум и улучшить точность без полной перестройки архитектуры.

Что это значит RAG постепенно уходит от грубой настройки в духе один параметр на все случаи.

Материал про DRAG with KNEE показывает простой, но важный сдвиг: следующим уровнем качества становится не только хороший поиск, но и умение вовремя остановиться, чтобы LLM получила достаточно контекста для ответа, а не случайный текстовый перегруз.