La plupart des équipes sur-ingénient leur pile RAG en passant directement aux embeddings et aux bases de données vectorielles, alors que les utilisateurs veulent simplement trouver des documents spécifiques. Avant de choisir une architecture, considérez cinq facteurs clés : fraîcheur des données, caractéristiques du corpus, modèles de requête, échelle et capacités de l'équipe.

Commencez par BM25 et la recherche plein texte (Elasticsearch, Postgres). Cette approche n'implique pas de complexité ML, ne coûte rien par requête, s'exécute en moins de 10 ms et est facile à déboguer. Elle gère efficacement de nombreux cas d'usage sans stratégies de chunking ou without évaluation. La principale limitation est le manque de synonymes et l'échec sur les requêtes sémantiques.

Pour les requêtes riches en mots-clés avec des correspondances exactes et une terminologie propriétaire, BM25 est idéal. Lorsque les utilisateurs écrivent des requêtes conversationnelles, utilisez un LLM pour les réécrire en recherches de mots-clés propres. Cela coûte environ 0,001 $ par requête et permet des itérations rapides via des ajustements du prompt système.

Avec les embeddings, de mauvais résultats nécessitent de recréer tout le corpus et des tests de régression. Avec la réécriture des requêtes, corrigez les problèmes en ajustant le prompt système et testez immédiatement. Commencez simple et n'avancez que lorsque vous avez des données prouvant que vous avez besoin d'une complexité supplémentaire.