Alex - stock.adobe.com

IA générative : Salesforce « accorde » son RAG au CRM

Salesforce a lancé en disponibilité générale les deux modules composant son système RAG. L’éditeur anticipe qu’il faut « accorder » chacun des composants aux cas d’usage du CRM.

Le 18 juin dernier, Salesforce a présenté un benchmark LLM consacré à certaines tâches de son CRM. Si le choix du grand modèle de langage est important, c’est surtout l’architecture RAG (Retrieval Augmented Generation) qui guide la pertinence des résultats d’un système infusé à l’IA générative. Cette conviction est partagée par de plus en plus d’éditeurs et par certains clients.

Pour autant, et malgré les discours autour du RAG as a Service, concevoir un système de ce type n’est pas aussi aisé qu’il n’y paraît. Alors qu’il est habituellement le premier à simplifier et à édulcorer les défis techniques, Salesforce fait preuve d’un certain réalisme au moment de proposer son offre de services.

Le 6 juin 2024, il a annoncé la disponibilité générale de Data Cloud Vector Database et d’Einstein Copilot Search.

Data Cloud Vector Database est un service d’indexation et de vectorisation des données low-code/no-code. Techniquement, l’item qui en ressort est un index stocké dans Data Cloud, activable à travers plusieurs services de la plateforme CRM. Einstein Copilot Search est le module de recherche hybride de Salesforce configurable depuis l’interface de la plateforme Einstein 1. Celui-ci est également disponible dans plusieurs solutions de l’éditeur, sous d’autres noms.

Comme ailleurs, ce sont les deux mêmes faces d’une même pièce. « Quand nous parlons de RAG, nous parlons de la structuration de données sous forme de vecteurs et de l’interrogation de cette base vectorielle », rappelle Olfa Kharrat, architecte IA & Data chez Salesforce, lors d’un point presse.

Cette approche est un des moyens de répondre aux deux principaux défis de l’IA : les données et leur traçabilité. « Les entreprises ont besoin d’ancrer les résultats de l’IA générative. Cela s’appelle le “grounding” ».

Des techniques génériques au service de cas d’usage spécifiques

L’architecture RAG est une des techniques d’ancrage des résultats des modèles d’IA générative dans une « vérité terrain », mais il est aussi possible d’appeler des attributs structurés ou des fonctions externes (un module de calcul de prédiction, une API, etc.) qui contiendraient l’information souhaitée.

Le RAG, lui, serait particulièrement utile pour trouver les quelques documents répondant à la question de l’utilisateur. « Cela n’a pas de sens d’envoyer au LLM des centaines de milliers d’articles de connaissances, pour une question concernant un produit en particulier », illustre Olfa Kharrat.

« Cela n’a pas de sens d’envoyer au LLM des centaines de milliers d’articles de connaissances pour une question concernant un produit en particulier. »
Olfa KharratArchitecte Data & IA, Salesforce

 L’architecte rappelle qu’il faut d’abord charger des documents ou des données dans Data Cloud, puis les « chunker », c’est-à-dire les découper en extraits choisis avant de les vectoriser à l’aide d’un modèle d’embeddings.

De l’autre côté, il s’agit de convertir les prompts des utilisateurs en vecteurs qui serviront à une étape de recherche de similarité sémantique. « Une fois une question vectorisée, l’on va pouvoir extraire tous les chunks de documents qui ont un sens proche de cette question », explique Olfa Kharrat.

Dans Data Cloud, il s’agit d’ingérer des données structurées ou non structurées en les intégrant à une Data Model Object, un objet pour grouper différentes données dans Data Cloud.

Mais dans une architecture RAG, « il y a beaucoup de paramètres à prendre en compte », prévient l’architecte.

« Beaucoup de clients nous posent la question : “pourquoi faire du RAG dans Salesforce et non pas passer par une plateforme tierce ?”. Ce que nous constatons aujourd’hui, c’est que pour obtenir une architecture RAG optimale, il faut qu’elle soit “accordée” en fonction du cas d’usage ».

Les défis du RAG (et les solutions en cours de déploiement chez Salesforce)

Salesforce liste ainsi plusieurs points à prendre en compte dans la conception d’un système RAG.

Il y a d’abord le choix de la stratégie de « chunking ». Ce découpage est d’abord formel. Salesforce prend pour l’instant uniquement en charge la combinaison de deux techniques d’extraction de passage basé sur le HTML et sur des balises Windows. Pour les fichiers textes et PDF, le découpage est effectué phrase par phrase et est fonction d’un certain nombre de tokens, 512 par défaut.

En clair, cette approche est surtout adaptée aux articles de connaissances au format HTML déjà enregistrés en tant qu’UDMO (Unstructured Data Model Object) au sein de la plateforme Salesforce. Ici, la stratégie de découpage consiste à optimiser la sélection sur les balises contenant généralement l’information recherchée. En clair, il faut que les données soient semi-structurées.

Cela est voué à changer, selon Olfa Kharrat.

« Pour l’instant, les clients n’ont pas totalement la main sur la stratégie de chunking, mais plus tard, nous intégrerons des moyens de détecter si les réponses sont contenues dans des chunks consécutifs ou si les chunks sont éloignés, ce qui implique d’appliquer une forme de clustering », indique-t-elle.

Ces approches sont liées aux méthodes de division par phrase et de chunking en fonction de la fenêtre d’attention glissante du modèle d’embedding.  

Il existe aussi une autre méthode nommée « prepending » consistant à « chaîner » différents chunks suivant les extraits qu’ils représentent. « Avec cette méthode, nous pouvons enrichir des données non structurées avec des données structurées, ce qui va améliorer considérablement les performances du RAG », avance Olfa Kharrat.

C’est là qu’entre en jeu le défi de sélectionner le bon modèle d’embeddings. Pour l’instant, Salesforce propose d’utiliser E5-Large-V2, un modèle multilingue générant des vecteurs de 1 024 dimensions. Pour rappel, les modèles d’embeddings ne peuvent être configurés pour une langue particulière.

« Nous sommes en train de déployer notre propre modèle d’embeddings », indique l’architecture.

En effet, Salesforce AI Research a entraîné SFR-Embedding, un modèle de 7 milliards de paramètres dérivé de Mistral 7B et des travaux de Microsoft, pouvant générer des vecteurs contenant jusqu’à 4 096 dimensions. Il est actuellement le meilleur de sa catégorie au classement/benchmark MTEB.

Du côté de la recherche, il peut être nécessaire d’employer plusieurs méthodes pour obtenir de meilleurs résultats. En juillet, Salesforce lancera en bêta un module de recherche hybride, mêlant algorithme de recherche vectorielle (de type Hierarchical Navigable Small World ou HNSW) et recherche par mot clé (BM25), à l’instar d’Elasticsearch ou Snowflake (entre autres).

« Dans un cas d’usage lié à Service Cloud, où l’on peut chercher un extrait contenant le nom exact d’un produit, cette hybridation a du sens », justifie l’architecte.

En l’occurrence, Salesforce fusionne les résultats des deux modèles, puis les reclasse (rerank) avant de les infuser dans un prompt. Par ailleurs, il est fortement possible qu’il soit nécessaire de réécrire les questions afin que les résultats soient pertinents. Cette tâche peut être confiée à un LLM.

Olfa Kharrat prévient qu’il est très important d’évaluer la qualité du RAG. « Pour cela, nous utilisons des LLM qui contrôlent la qualité de l’extraction », indique Olfa Kharrat. Cette technique est nommée « LLM as a Judge ».

Il faut aussi superviser la qualité de la recherche des documents. Pour cela, Salesforce s’appuie sur les statistiques de recherche (typiquement, le nombre de fois qu’un système RAG sélectionne le bon ou le mauvais extrait), mais également la précision (la proportion d’extraits pertinents parmi les extraits proposés) et le rappel (la proportion des extraits pertinents parmi l’ensemble des extraits pertinents).

« Nous souhaitons d’abord couvrir les cas d’usage principaux dans les différents “clouds” Salesforce, en commençant par Sales et Service Cloud. »
Olfa KharratArchitecte Data & IA, Salesforce

À noter que l’architecte n’a pas eu le temps d’évoquer les méthodes « d’hydratation » des index, à quelles fréquences sont-ils rafraîchis en fonction de l’évolution de la documentation ?

La méthodologie mise en place par Salesforce vaut pour pratiquement tous les cas d’usage, mais lui se concentre sur les usages autour de son CRM.

« Nous souhaitons d’abord couvrir les cas d’usage principaux dans les différents “clouds” Salesforce, en commençant par Sales et Service Cloud », précise l’architecte data et IA.

Pour approfondir sur IA appliquée, GenAI, IA infusée