Qdrant et DRAG with KNEE : comment rendre RAG adaptatif et ne pas gaspiller de tokens supplémentaires

Un décodage pratique est sorti sur la façon de rendre un système RAG moins gourmand et plus précis. Au cœur du sujet se trouve DRAG with KNEE, une approche basée sur Qdrant et Python qui sélectionne le volume de contexte dynamiquement, plutôt que d'utiliser un top_k fixe.

Pourquoi le static top_k échoue

Presque quiconque ayant construit un RAG sur de longs PDFs a rencontré le même problème : si vous prenez trop peu de chunks, le modèle perd le contexte important et commence à inventer. Si vous en prenez trop, du bruit entre dans le prompt, et avec lui viennent des coûts croissants, de la latence et le risque que l'LLM s'accroche à un fragment aléatoire. Un seul paramètre top_k dans ce schéma essaie de résoudre trop de problèmes différents et le fait presque toujours mal.

L'auteur appelle ce compromis une faiblesse fondamentale du RAG classique. Un nombre fixe de documents ne tient compte ni du type de requête, ni de la structure du fichier source, ni de la densité d'information utile dans le corpus. Pour un fait court, quelques extraits peuvent suffire, mais pour une question complexe sur un document multi-pages, ce n'est pas le cas.

En résultat, le système ou sous-alimente le modèle avec du contexte ou, au contraire, le surcharge avec du texte non pertinent et brûle le budget de tokens.

Comment DRAG fonctionne

L'idée de DRAG with KNEE n'est pas seulement de trouver des chunks similaires, mais d'abord de voir les documents comme une hiérarchie, puis de décider dynamiquement où arrêter la sélection. Au lieu d'une limite rigide, l'algorithme analyse la distribution de la pertinence et cherche un point d'inflexion—ce coude après lequel les fragments ajoutés apportent de moins en moins d'avantage. Tout ce qui va dans la longue queue après ce point peut être coupé sans perte de sens notable.

En pratique, cela ressemble à une stratégie plus adaptative d'extraction de contexte. Le système n'est pas obligé de retourner le même nombre de chunks pour chaque requête : dans un cas il y en aura trois, dans un autre dix, et dans un troisième plusieurs groupes connexes de différentes parties du document. De ce fait, RAG s'adapte mieux à la structure réelle des connaissances plutôt qu'à une constante pré-sélectionnée.

• Premièrement, les candidats sont trouvés par similarité vectorielle
• Puis ils sont groupés et triés par documents et niveaux
• Après cela, l'algorithme cherche le point où l'utilité commence à chuter fortement
• Seul le noyau pertinent sans la longue queue du bruit entre dans le contexte final

Cette approche est particulièrement utile là où les connaissances ne résident pas dans une base FAQ bien ordonnée, mais dans des instructions dispersées, des rapports, des règlementations et de grands PDFs. Dans ces corpus, les distances entre fragments disent peu par elles-mêmes si vous ne tenez pas compte de la façon dont ces fragments sont connectés les uns aux autres et de la rapidité avec laquelle leur valeur pour la réponse diminue. C'est exactement ici que l'analyse géométrique cesse d'être un ornement mathématique et devient un filtre pratique.

Pourquoi Qdrant ici

Un atout distinct de l'article est qu'il ne sombre pas dans la pure théorie. L'auteur montre comment construire un tel pipeline en utilisant Qdrant et Python, c'est-à-dire sur une pile familière déjà utilisée dans de nombreux projets RAG. Qdrant est responsable de la recherche vectorielle et du travail avec les candidats, tandis que la logique de DRAG with KNEE ajoute une couche d'adaptation au-dessus : non seulement trouver quelque chose de similaire, mais comprendre la quantité de contenu similaire que vous avez réellement besoin de donner au modèle maintenant.

Pour les équipes qui ont déjà déployé la retrieval standard et se sont heurtées à des problèmes de qualité des réponses ou de coûts d'inférence, c'est un signal important. Le problème peut ne pas être dans les embeddings ou dans l'LLM elle-même, mais dans la façon exacte dont vous coupez et servez le contexte. Si vous remplacez le top_k statique par une coupure dynamique au point d'inflexion, vous pouvez simultanément réduire le bruit et améliorer la précision sans reconstruire complètement l'architecture.

Ce que cela signifie

RAG s'éloigne graduellement du réglage brut à l'esprit d'un paramètre pour tous les cas. Le matériel sur DRAG with KNEE montre un changement simple mais important : le prochain niveau de qualité n'est pas seulement une bonne recherche, mais la capacité à s'arrêter à temps pour que l'LLM obtienne suffisamment de contexte pour une réponse, au lieu d'une surcharge aléatoire de texte.