Habr AI a montré comment créer son propre RAG retriever dans LangChain pour les noms et les termes

Habr AI a publié un guide pratique pour les ingénieurs RAG qui n'obtiennent pas la précision requise lors d'une recherche vectorielle standard sur les noms, titres et termes rares. L'article montre comment construire un récupérateur TF-IDF personnalisé, l'intégrer dans LangChain et le tester par rapport aux solutions typiques sur un benchmark.

Où les embeddings échouent

L'idée principale de l'article est simple : toute tâche de recherche n'a pas besoin d'être résolue avec le même schéma vectoriel. Les embeddings fonctionnent bien sur les questions générales, mais échouent souvent sur les entités nommées. Pour RAG, c'est particulièrement douloureux, car le modèle peut formuler une réponse avec assurance tout en s'appuyant sur un mauvais contexte. L'erreur ne se produit pas à l'étape de génération, mais plus tôt — lorsque le système récupère le mauvais fragment du document.

Le point faible de la recherche standard apparaît là où les différences littérales comptent. Les noms de personnes, les noms de produits, les entreprises, les systèmes internes, les abréviations techniques et les termes rares peuvent être trop similaires dans un contexte sémantique mais critiquement différents dans une tâche pratique. Si ces entités sont mal séparées dans l'espace des embeddings, la qualité des résultats baisse même avec une bonne couche LLM. L'idée d'un récupérateur personnalisé ici ne semble donc pas être un ornement pour la stack, mais un moyen de fermer une classe spécifique d'erreurs.

"Et pour cela, j'ai mon propre récupérateur."

Schéma du récupérateur personnalisé

La partie pratique commence par la couche la plus compréhensible — la préparation des données. Les documents doivent être divisés en fragments ou chunks, pour que la recherche retourne non pas tout le texte, mais une partie spécifique pertinente. Ensuite, une représentation TF-IDF est construite pour l'ensemble des chunks. Elle aide à classer les fragments par importance des mots et à trouver des correspondances plus rapidement là où la précision littérale importe plus que la similarité sémantique. Ensuite, au-dessus de l'index, une logique de recherche personnalisée est ajoutée et tout cela est emballé dans une interface LangChain. Dans l'article, ce pipeline semble maximalement pratique :

• le corpus est nettoyé et mis en forme opérationnelle
• les documents sont divisés en chunks pour un retour de contexte précis
• un modèle TF-IDF est construit à partir des chunks
• les résultats de recherche sont enveloppés dans un récupérateur personnalisé pour LangChain
• les questions de test sont préparées séparément pour comparaison avec les options standard

La force de cette approche est la prévisibilité. L'ingénieur comprend mieux pourquoi le système a sélectionné tel ou tel fragment, et peut déboguer les résultats sans infrastructure complexe autour d'une base de données vectorielle. De plus, un tel récupérateur est moins cher à exploiter et plus rapide à mettre en place pour des expériences locales. Ce n'est pas un remplacement universel aux solutions modernes, mais un bon outil pour les domaines où les correspondances exactes d'entités et de formulations importent, pas la "similarité sémantique."

Comment les résultats sont validés

Un accent particulier est mis sur la comparaison, pas seulement sur l'assemblage. Après la création d'un récupérateur personnalisé, l'auteur propose de l'exécuter contre deux ou trois solutions standard et d'observer la qualité et la vitesse des résultats. Cette étape est importante car une implémentation personnalisée peut facilement sembler meilleure sur quelques exemples manuels mais perdre sur un ensemble plus large de requêtes. Le benchmark agit ici comme un filtre contre l'autodéception et aide à comprendre exactement où la recherche spécialisée apporte des gains réels.

Pour la préparation des questions, l'article utilise Ollama. C'est un moyen pratique de constituer rapidement un ensemble de tests pour votre corpus sans vous lier à une API externe et sans passer du temps sur un balisage entièrement manuel. En résultat, le matériel démontre une approche d'ingénierie mature : d'abord identifier une erreur typique, puis sélectionner un mécanisme de recherche plus approprié pour cela, et seulement après comparer les résultats sur un ensemble de requêtes contrôlé. Pour les équipes construisant des services RAG internes, une telle discipline est généralement plus importante que les promesses grandioses d'une stack "magique."

Ce que cela signifie

L'analyse de Habr AI montre un changement dans la maturité de la pratique RAG : le marché s'éloigne de la croyance en un récupérateur universel vers un réglage plus étroit de la recherche aux données et aux types d'erreurs. Pour les équipes ayant des bases de connaissances, des catalogues, des textes juridiques ou des répertoires internes, c'est un bon signal : parfois un gain de qualité notable vient non pas d'un nouveau modèle, mais d'une couche de recherche correctement assemblée.