𝗝'𝗮𝗶 𝗱𝗲́𝗽𝗲𝗻𝘀𝗲́ 𝟱𝟬𝟬 $ 𝗲𝗻 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗥𝗔𝗚 𝗮𝘃𝗮𝗻𝘁 𝗱𝗲 𝗰𝗼𝗺𝗺𝗲𝘁𝘁𝗿𝗲 𝟳 𝗲𝗿𝗿𝗲𝘂𝗿𝘀

J'ai construit un pipeline RAG pour la recherche dans des documents privés. Cela m'a coûté 500 $ en calcul et des semaines de débogage. Les résultats étaient mauvais. Les utilisateurs recevaient des réponses non pertinentes et les requêtes étaient lentes.

J'ai audité le pipeline et j'ai trouvé 7 erreurs courantes. Les corriger a tout changé.

  1. Découpage par tokens fixe Je divisais les documents par nombre fixe de tokens. Cela détruisait le contexte. Une phrase pouvait être coupée en deux. Le LLM recevait des données fragmentées et donnait de mauvaises réponses.
  • La solution : Utiliser le découpage sémantique (semantic chunking) avec la récupération du document parent (parent-document retrieval).
  • Découper selon des limites naturelles comme les paragraphes ou les titres.
  • Créer de petits segments enfants (child chunks) pour la recherche.
  • Renvoyer le document parent complet au LLM lorsqu'une correspondance est trouvée.
  • Ajouter un chevauchement de 10 à 20 % entre les segments.
  1. Poids de recherche par défaut J'utilisais une répartition 50/50 entre la recherche vectorielle et la recherche par mots-clés. Pour la documentation technique, les mots-clés exacts sont plus importants.
  • La solution : Utiliser des poids dynamiques.
  • Requêtes factuelles : 35 % vectoriel, 65 % mots-clés.
  • Requêtes sémantiques : 75 % vectoriel, 25 % mots-clés.
  1. Sur-optimisation des paramètres HNSW J'avais réglé ef_construction sur la valeur maximale. Sur un index volumineux, cela a fait planter mon serveur et a consommé toute ma RAM.
  • La solution : Utiliser des paramètres HNSW appropriés.
  • Maintenir M entre 8 et 32.
  • Régler ef_construction à 200.
  • Régler ef_search à 50.
  1. Mauvais modèles d'embedding J'utilisais un modèle généraliste entraîné sur du texte web. Il ne comprenait pas mes documents d'ingénierie technique.
  • La solution : Passer à un modèle affiné (fine-tuned) pour le contenu technique ou le code.
  1. Décalage de langage naturel Les utilisateurs posent des questions comme « pourquoi mon build est-il lent ? ». La documentation utilise des termes comme « optimisation du pipeline CI ». Il n'y avait aucun chevauchement.
  • La solution : Ajouter une étape de réécriture de requête par LLM.
  • Réécrire la requête de l'utilisateur en termes techniques avant la recherche.
  1. Contexte redondant Récupérer les 10 meilleurs segments signifiait souvent obtenir le même paragraphe trois fois. Cela provoquait des hallucinations.
  • La solution : Utiliser la pertinence maximale marginale (MMR) pour garantir la diversité des résultats.
  1. Évaluation uniquement de bout en bout Je vérifiais uniquement la réponse finale. Je ne savais pas si le problème venait de la récupération ou du LLM.
  • La solution : Évaluer la récupération séparément.
  • Suivre le taux de succès (hit rate) et le rang de réciprocité moyen (MRR).
  • Construire un ensemble de tests de 100 paires requête-document.

Résultats après corrections : • Pertinence de la réponse : 45 % à 85 % • Latence de requête : 3,2 s à 1,8 s • Coût mensuel : 180 $ à 95 $

Commencez par le chunking. Ensuite les poids. Puis la qualité des embeddings.

Quel est votre plus gros casse-tête avec le RAG ? Dites-le moi en commentaires.

Source : https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi