AWS a introduit une nouvelle méthode pour réduire les factures de recherche d’information par IA sur Amazon Bedrock. Si vous développez des applications de génération augmentée de récupération (RAG), cette configuration peut réduire vos dépenses en tokens, mais vos utilisateurs risquent d’attendre les réponses plus longtemps.
Dans un article publié le 2026-08-21 sur le AWS Machine Learning Blog, AWS a montré comment placer un petit modèle entre la récupération et la réponse finale. Au lieu d’envoyer de longs blocs de texte à un grand modèle, un modèle rapide extrait d’abord uniquement les phrases pertinentes exactes.
Comment fonctionne cette configuration
L’architecture de référence s’exécute dans une fonction AWS Lambda à l’aide de l’Amazon Bedrock Converse API. Vous avez besoin d’un compte AWS, de permissions IAM et de l’accès aux modèles.
Le pipeline répartit le travail entre deux modèles :
– Claude Haiku agit comme compresseur, sélectionnant les extraits textuels exacts correspondant à la question de l’utilisateur.
– Claude Sonnet lit uniquement le texte réduit et rédige la réponse finale.
AWS a testé trois approches sur plus de 500,000 documents issus de neuf types de sources d’entreprise et 500 questions réparties dans 10 catégories : baseline RAG, compression seule, et rerank plus compression.
Ce que montrent les chiffres
Selon AWS, la réduction du contexte génère d’importantes économies :
– Volume de tokens : Chute à 12% avec la compression (8.6x moins de tokens) et 10% avec le rerank plus compression (10.1x moins de tokens), par rapport à 100% pour le baseline RAG.
– Coût total : Tombe à 67% (une économie de 33%) et 64% (une économie de 36%).
– Score de qualité : Reste proche de la référence (97.5% et 97.6% contre 100%), sur la base d’un juge LLM évaluant l’exactitude, l’exhaustivité, la précision des citations et la concision.
– Taux d’hallucination : Chute de 51% pour la référence à 44% avec la compression et 38% avec le reranking, la fidélité étant mesurée séparément.
– Latence : Augmente de +19% pour la compression et de +12% pour le rerank plus compression. La vitesse en prend un coup.
Les affirmations que vous devriez vérifier vous-même
Ces chiffres proviennent entièrement de tests internes menés par AWS sur un corpus unique évalué par un juge LLM. Personne en dehors d’AWS ne les a vérifiés de manière indépendante, et ils ne constituent pas une garantie de performance pour d’autres charges de travail, niveaux de prix ou modèles. Ajouter un appel de modèle supplémentaire crée un nouveau point de défaillance. Le compresseur pourrait accidentellement supprimer des faits essentiels, affaiblir les citations ou échouer face à des segments mal formés et à des injections de prompts.
Comment tester ce modèle
Ne modifiez pas encore votre pipeline de production. Testez d’abord vos propres données.
Configurez un ensemble fixe de requêtes de test avec votre retriever, vos paramètres de top-k, de découpage en blocs (chunking) et vos identifiants de modèles. Exécutez les requêtes sur les trois voies : baseline RAG, compression, et rerank plus compression. Enregistrez les tokens d’entrée, les tokens de sortie, le coût Lambda, le coût des modèles ainsi que la latence p50 et p95. Plus important encore, examinez directement les extraits compressés. Vérifiez ce qui est supprimé. Si la latence de queue explose ou si des preuves clés disparaissent, conserver votre approche baseline RAG reste le choix le plus sûr.