Qdrant e DRAG with KNEE: como tornar RAG adaptativo e não gastar tokens extras

Saiu um resumo prático sobre como tornar um sistema RAG menos voraz e mais preciso. No centro está DRAG with KNEE, uma abordagem baseada em Qdrant e Python que seleciona o volume de contexto dinamicamente, em vez de usar um top_k fixo.

Por que o static top_k quebra

Quase qualquer um que tenha construído RAG em cima de PDFs longos enfrentou o mesmo problema: se você pegar poucos chunks, o modelo perde contexto importante e começa a inventar. Se pegar muitos, ruído entra no prompt, e junto dele vêm custos crescentes, latência e o risco de que a LLM se prenda a um fragmento aleatório. Um único parâmetro top_k nesse cenário tenta resolver muitos problemas diferentes e quase sempre faz isso mal.

O autor chama esse compromisso de fraqueza fundamental do RAG clássico. Um número fixo de documentos não leva em conta nem o tipo de query, nem a estrutura do arquivo original, nem a densidade de informação útil dentro do corpus. Para um fato curto, alguns trechos podem ser suficientes, mas para uma pergunta complexa sobre um documento multi-página, não são.

Como resultado, o sistema ou alimenta insuficientemente o modelo com contexto ou, ao contrário, o sobrecarrega com texto irrelevante e queima o orçamento de tokens.

Como o DRAG funciona

A ideia de DRAG with KNEE é não apenas encontrar chunks similares, mas primeiro ver os documentos como uma hierarquia e depois decidir dinamicamente onde parar a seleção. Em vez de um limite rígido, o algoritmo analisa a distribuição de relevância e procura um ponto de inflexão—aquele joelho depois do qual fragmentos adicionados trazem cada vez menos benefício. Tudo que vai para a cauda longa após este ponto pode ser cortado sem perda perceptível de sentido.

Na prática, isso parece uma estratégia mais adaptativa de extração de contexto. O sistema não é obrigado a retornar o mesmo número de chunks para cada query: em um caso serão três, em outro dez, e em um terceiro vários grupos relacionados de diferentes partes do documento. Por isso, RAG se adapta melhor à estrutura real do conhecimento, em vez de uma constante pré-selecionada.

• Primeiro, candidatos são encontrados por similaridade vetorial
• Depois são agrupados e ordenados por documentos e níveis
• Então o algoritmo procura o ponto onde a utilidade começa a cair drasticamente
• Apenas o núcleo relevante sem a cauda longa de ruído entra no contexto final

Essa abordagem é especialmente útil onde o conhecimento não fica em uma base FAQ arrumada, mas em instruções espalhadas, relatórios, regulamentos e PDFs grandes. Em tais corpora, distâncias entre fragmentos dizem pouco por si só se você não levar em conta como esses fragmentos se conectam entre si e como rapidamente seu valor para responder cai. É exatamente aqui que a análise geométrica deixa de ser um ornamento matemático e se torna um filtro prático.

Por que Qdrant aqui

Um diferencial à parte do artigo é que ele não se perde em pura teoria. O autor mostra como construir um pipeline desses usando Qdrant e Python, ou seja, em uma stack familiar que já é usada em muitos projetos RAG. Qdrant é responsável pela busca vetorial e trabalho com candidatos, enquanto a lógica de DRAG with KNEE adiciona uma camada de adaptação sobre ela: não apenas encontrar algo similar, mas entender quanto conteúdo similar você realmente precisa dar ao modelo agora.

Para equipes que já implantaram retrieval padrão e esbarraram em qualidade de respostas ou custos de inference, esse é um sinal importante. O problema pode não estar em embeddings ou na LLM em si, mas em como exatamente você está cortando e entregando contexto. Se você substituir o top_k estático por corte dinâmico pelo ponto de inflexão, pode simultaneamente reduzir ruído e melhorar acurácia sem reconstruir completamente a arquitetura.

O que isso significa

RAG está gradualmente saindo da sintonia grossa no espírito de um parâmetro para todos os casos. O material sobre DRAG with KNEE mostra um deslocamento simples mas importante: o próximo nível de qualidade não é apenas uma boa busca, mas a habilidade de parar a tempo para que a LLM receba contexto suficiente para uma resposta, em vez de uma sobrecarga de texto aleatória.