Le pipeline de génération augmentée par récupération (RAG) de Salesforce dépassait 90 % de précision sur les benchmarks standards de récupération de texte, mais tombait à environ 46 % lors de tests sur des documents d'entreprise complexes et représentatifs des clients, tels que des polices d'assurance comportant des tableaux de plusieurs pages et des cellules fusionnées. L'écart n'est apparu qu'après deux trimestres d'escalades clients, et le suspect évident était le LLM lui-même.

Plutôt que de remplacer le modèle ou de réécrire les prompts, l'équipe d'ingénierie a travaillé à rebours à partir de chaque réponse erronée : le contexte récupéré était-il complet ? Sinon, la récupération avait-elle choisi le mauvais segment, ou le découpage avait-il séparé des informations liées, ou l'analyse les avait-elle perdues en premier ? Les tests ont montré que les en-têtes de tableaux étaient séparés de leurs données lors des sauts de page, et que le découpage à taille fixe tranchait les procédures à des frontières de tokens arbitraires, supprimant les titres et les schémas qui leur donnaient leur sens.

L'équipe a ensuite modifié une étape du pipeline à la fois et relancé le même benchmark par étapes pour attribuer chaque gain. L'ajout d'une « analyse intelligente » au niveau des pages, qui oriente les tableaux et graphiques complexes vers un traitement basé sur des modèles, a fait passer une base de référence par étapes de 65,1 % à 84,4 %. L'enrichissement de chaque segment avec des métadonnées et des représentations de questions, combiné à un modèle d'embedding qui étendait la capacité de contexte de 512 à 8 000 tokens, a ajouté 2,4 points supplémentaires pour atteindre 86,8 %. Sur l'ensemble des changements, la précision sur le benchmark élargi de documents d'entreprise est passée d'environ 46 % à plus de 90 %.

Déboguer le pipeline à rebours, une étape isolée à la fois, au lieu de blâmer le modèle

Tester le pipeline à rebours, étape par étape, a permis d'isoler laquelle parmi l'analyse, le découpage, l'enrichissement, l'embedding ou la récupération causait réellement chaque réponse erronée, au lieu de deviner.

Modifier exactement une étape avant de relancer le même benchmark a rendu chaque gain attribuable — de 65,1 % à 84,4 % puis à 86,8 % — plutôt qu'un score combiné opaque.

Orienter les pages selon leur complexité structurelle (texte simple vs tableaux/graphiques/schémas) a évité de faire passer chaque document par une analyse coûteuse basée sur des modèles.

La correction ciblait l'endroit où le sens se perdait — en-têtes séparés des données, procédures coupées aux frontières de tokens — au lieu de demander à un modèle plus intelligent de compenser un contexte manquant.

Lorsqu'un système d'IA échoue en production malgré la réussite des benchmarks, isolez et retestez chaque étape du pipeline séparément avant de toucher au modèle — la défaillance se situe généralement en amont de celui-ci.

Salesforce a également fait passer l'indexation des petits documents d'une architecture par lots basée sur Spark à une architecture juste-à-temps basée sur des services, réduisant le temps d'indexation d'un facteur trois à quatre, de plus de 30 minutes à environ sept à dix minutes. L'équipe a annoncé la disponibilité générale de GraphRAG, qui parcourt un graphe de connaissances à travers les documents pour les questions à sauts multiples, pour novembre 2026.

VÉRIFIEZ LES SOURCES

Les sources

  1. Enterprise AI Accuracy: Building a More Trustworthy RAG Application Salesforce Engineering · engineering.salesforce.com ·