𝗝'𝗮𝗶 𝗰𝗼𝗻𝘀𝘁𝗿𝘂𝗶𝘁 𝘂𝗻 𝗥𝗔𝗚 𝗱𝗲 𝘇𝗲𝗿𝗼 𝗲𝗻 𝗣𝘆𝘁𝗵𝗼𝗻 𝗽𝗼𝘂𝗿 𝗹𝗲 𝗰𝗼𝗺𝗽𝗿𝗲𝗻𝗱𝗿𝗲
J'ai utilisé LangChain en production pendant six mois. Je ne pouvais pas expliquer comment cela fonctionnait. Je ne savais pas pourquoi je choisissais des métriques spécifiques ni comment le texte devenait des vecteurs. La bibliothèque cachait la logique.
Pour remédier à cela, j'ai supprimé le framework. J'ai écrit un pipeline RAG de zéro en utilisant 500 lignes de Python pur.
Voici ce que j'ai appris en construisant la pile manuellement.
Le problème des boîtes noires Lorsque vous utilisez des bibliothèques de haut niveau, vous perdez le contrôle. J'ai vu des modèles halluciner des faits ou donner de mauvaises citations. Je ne pouvais pas dire si l'erreur provenait du chunker, du modèle d'embedding ou du prompt.
Lorsque vous le construisez vous-même, chaque couche est inspectable. Vous pouvez afficher les chunks exacts envoyés au LLM. Vous pouvez voir précisément où une phrase est coupée.
Les cinq couches du RAG Le RAG n'est pas un algorithme unique. Il s'agit de cinq processus différents empilés les uns sur les autres :
- Chunking : décider comment diviser le texte.
- Embedding : transformer le texte en mathématiques.
- Retrieval : trouver les bons morceaux.
- Construction du prompt : dire au modèle comment se comporter.
- Génération : obtenir la réponse finale.
Leçons tirées de la construction
Le chunking est l'étape la plus importante La plupart des tutoriels sautent cette étape. Si vous n'utilisez pas de chevauchement (overlap), vous perdez le contexte aux limites. J'ai utilisé une fenêtre glissante avec un chevauchement au niveau des caractères. Cela garantit que le modèle voit la connexion entre deux chunks.
Les métriques de distance comptent J'ai passé des heures à déboguer de mauvais résultats de recherche. Le problème ne venait pas des données, mais de la métrique. ChromaDB utilise la distance L2 par défaut. Pour une recherche sémantique, vous avez besoin de la similarité cosinus (Cosine similarity). Une seule ligne de code a tout changé.
Les prompts ont besoin de contraintes Un LLM est un outil de complétion, pas un oracle. Si vous posez une question vague, il inventera une réponse. J'ai appris à utiliser un modèle de refus strict. J'ai dit au modèle : « Si le contexte ne contient pas la réponse, dites que vous ne savez pas. » Cela a fait chuter les hallucinations de 40 % à 5 %.
Traitez vos requêtes par lots Envoyer une requête HTTP par chunk est lent. Les envoyer par lots est beaucoup plus rapide. Cela permet au modèle local de mettre le travail en pipeline.
Testez de bas en haut N'écrivez pas les tests à la fin. Testez d'abord votre chunker. Ensuite, testez votre embedder. Puis, testez votre store. Si vous testez à la fin, vous testez les bugs au lieu de la logique.
Si vous avez l'impression de ne pas vraiment comprendre votre stack IA, construisez-la vous-même. Le code n'est pas le but. C'est la réflexion qui est le but.
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi