Habr AI mostrou como montar seu próprio RAG retriever no LangChain para nomes e termos

Habr AI publicou um guia prático para engenheiros de RAG que não obtêm a precisão necessária na busca por vetores padrão em nomes, títulos e termos raros. O artigo mostra como construir um recuperador TF-IDF customizado, integrá-lo no LangChain e testá-lo contra soluções típicas em um benchmark.

Onde os embeddings falham

A ideia principal do artigo é simples: nem toda tarefa de busca precisa ser resolvida com o mesmo esquema de vetores. Os embeddings funcionam bem em perguntas gerais, mas frequentemente tropeçam em entidades nomeadas. Para RAG isso é particularmente doloroso, porque o modelo pode formular uma resposta com confiança enquanto se baseia no contexto errado. O erro não ocorre no estágio de geração, mas antes — quando o sistema recupera o fragmento errado do documento.

O ponto fraco da busca padrão aparece onde diferenças literais importam. Nomes de pessoas, nomes de produtos, empresas, sistemas internos, abreviações técnicas e termos raros podem ser muito semelhantes em contexto semântico mas criticamente diferentes em uma tarefa prática. Se tais entidades são mal separadas no espaço de embeddings, a qualidade dos resultados cai mesmo com uma boa camada LLM. Então a ideia de um recuperador customizado aqui parece não como um adorno para a stack, mas como uma forma de fechar uma classe específica de erros.

"E para isso eu tenho meu próprio recuperador."

Esquema do recuperador customizado

A parte prática começa com a camada mais compreensível — preparação de dados. Documentos precisam ser divididos em fragmentos, ou chunks, para que a busca retorne não o texto inteiro, mas uma peça específica relevante. Depois disso, uma representação TF-IDF é construída para o conjunto de chunks. Isso ajuda a classificar fragmentos por importância de palavra e encontrar correspondências mais rapidamente onde a precisão literal importa mais que a similaridade semântica. Então, no topo do índice, a lógica de busca customizada é adicionada e tudo isso é empacotado em uma interface LangChain. No artigo, este pipeline parece maximamente prático:

• corpus é limpo e trazido para forma operacional
• documentos são divididos em chunks para retorno de contexto preciso
• um modelo TF-IDF é construído a partir dos chunks
• resultados de busca são envolvidos em um recuperador customizado para LangChain
• perguntas de teste são preparadas separadamente para comparação com opções padrão

A força dessa abordagem é a previsibilidade. O engenheiro entende melhor por que o sistema selecionou um fragmento ou outro, e pode depurar os resultados sem infraestrutura complexa ao redor de um banco de dados de vetores. Além disso, esse recuperador é mais barato de operar e mais rápido de configurar para experimentos locais. Isso não é uma substituição universal para soluções modernas, mas uma ferramenta boa para domínios onde correspondências exatas de entidades e formulações importam, não "significado similar."

Como os resultados são validados

Uma ênfase separada é colocada em comparação, não apenas em montagem. Após criar um recuperador customizado, o autor propõe executá-lo contra duas ou três soluções padrão e observar a qualidade e velocidade dos resultados. Este passo é importante porque uma implementação customizada pode facilmente parecer melhor em alguns exemplos manuais mas perder em um conjunto mais amplo de consultas. O benchmark aqui atua como um filtro contra auto-engano e ajuda a entender exatamente onde a busca especializada oferece ganhos reais.

Para preparação de perguntas, o artigo usa Ollama. Esta é uma forma conveniente de montar rapidamente um conjunto de teste para seu corpus sem se prender a uma API externa e sem gastar tempo em marcação completamente manual. Como resultado, o material demonstra uma abordagem de engenharia madura: primeiro identifique um erro típico, depois selecione um mecanismo de busca mais adequado para ele, e apenas depois compare resultados em um conjunto controlado de consultas. Para times construindo serviços RAG internos, tal disciplina geralmente é mais importante que promessas altas sobre uma stack "mágica."

O que isso significa

A análise da Habr AI mostra uma mudança na maturidade da prática de RAG: o mercado está se afastando da crença em um recuperador universal para ajuste mais estreito da busca aos dados e tipos de erro. Para teams com bases de conhecimento, catálogos, textos legais ou diretórios internos este é um bom sinal: às vezes um ganho de qualidade notável vem não de um novo modelo, mas de uma camada de busca adequadamente montada.