Tu veux que ton LLM réponde sur tes données métier. Deux options principales : injecter du contexte récupéré par similarité (RAG), ou laisser le modèle appeler des fonctions qui interrogent tes systèmes (tool use). Le choix n'est pas évident, et la doc des frameworks pousse souvent par défaut vers le RAG.
Quand chacun marche
| Critère | RAG | Tool use |
|---|---|---|
| Volume de données | Excellent jusqu'à millions de docs | Limité à ce qu'on peut décrire en quelques tools |
| Fraîcheur | Dépend du re-indexage | Temps réel |
| Précision sur une requête exacte | Approximative (similarité) | Exacte (SQL, API) |
| Coût | Embeddings + storage vectoriel | Appels API/SQL |
| Effort d'implémentation | Élevé (ingestion, chunking, retrieval) | Moyen (définir les tools) |
| Cas typique | Documentation, archives | CRM, catalogue, dashboards |
La vraie ligne de partage
Le critère décisif, c'est la nature de tes données. Si elles sont structurées (lignes de DB, enregistrements, métriques), le tool use gagne presque toujours. Le LLM compose un appel précis et obtient une réponse exacte. Si elles sont non-structurées (PDF, articles, transcripts), le RAG reste pertinent.
Erreur classique : appliquer le RAG à un catalogue produit. Le LLM "trouve" des produits similaires à la requête mais rate le filtre "couleur rouge ET prix < 50 €" qu'un SELECT SQL gère trivialement.
Le pattern hybride
Le tool use est souvent plus puissant qu'on croit. Tu exposes un tool search_docs(query) qui fait du RAG en interne, le LLM décide quand l'appeler, et tu garderais aussi des tools pour les données structurées. Le modèle orchestre.
Conséquence : démarrer en tool use, ajouter du RAG comme un tool quand tu as un corpus non-structuré spécifique. Pas l'inverse.
Trois questions pour trancher
- Mes données sont-elles dans une DB ou dans des fichiers texte ? Le premier cas penche tool use.
- Ai-je besoin d'une réponse exacte ou approximative ? Exacte = tool use.
- Combien d'opérations métier distinctes ? Plus de 30 ? Le RAG sur la doc des tools peut devenir un meta-tool utile.
L'industrie a sur-vendu le RAG en 2023-2024. La maturité est en train de basculer vers le tool use comme primitive par défaut, le RAG comme cas particulier.