RAG d'entreprise sur les données Salesforce : une architecture solide

Réponse courte : c'est la qualité de la recherche documentaire qui décide si le RAG sur des données Salesforce fonctionne, pas le choix du modèle. Un modèle de pointe à qui l'on donne les trois mauvais enregistrements répondra avec assurance et à côté, et changer de modèle n'y change rien. Trois choses comptent vraiment : ce que vous considérez comme un fragment, la manière dont les droits sont appliqués pendant la recherche, et le fait de mesurer la recherche séparément de la génération.

Pourquoi le RAG sur des données CRM échoue-t-il plus souvent que sur des documents ?

Parce qu'un corpus CRM casse les hypothèses sur lesquelles repose le RAG documentaire.

• Les enregistrements sont courts et répétitifs. Dix mille requêtes sur le même produit produisent des vecteurs presque identiques, la recherche par similarité renvoie donc dix variantes d'une seule réponse.
• Le sens vit entre les objets. La réponse à "pourquoi ce client est-il parti" se répartit sur un compte, trois opportunités, un contrat et un fil de requête. Aucun enregistrement ne la contient.
• Le corpus change sans arrêt. Les opportunités changent d'étape, les requêtes se ferment, les contacts changent de rôle. Un corpus documentaire est surtout statique, un corpus CRM est une cible mouvante avec un index derrière.
• L'accès est propre à chaque utilisateur. Deux personnes posant la même question doivent légitimement obtenir des réponses différentes, un cas que la plupart des tutoriels RAG n'envisagent même pas.

Quel est le bon fragment quand la source est un enregistrement Salesforce ?

Le découpage champ par champ est l'erreur qu'on nous demande le plus souvent de corriger. La valeur d'un champ n'est pas une unité de sens récupérable. Assemblez plutôt.

1. Découpez au niveau d'un événement métier, pas d'un champ. Pour une requête : objet, description, résolution et fil de commentaires, rendus en un seul passage. Pour une opportunité : l'enregistrement, son motif de clôture et les notes clés.
2. Dénormalisez les identifiants qu'un humain utiliserait. Nom du compte, nom du produit, numéro de série, numéro de contrat. Les vecteurs ne résolvent pas les clés étrangères.
3. Conservez des métadonnées dures à côté du vecteur. Type d'objet, identifiant, propriétaire, compte, date de dernière modification. Tout filtre dont vous aurez besoin à la requête doit exister comme métadonnée, pas comme texte.
4. Gardez la correspondance exacte dans la boucle. Numéros de requête, références produit et codes d'erreur sont précisément là où la recherche vectorielle pure est la plus faible. La recherche hybride de Salesforce combine index par mots-clés et index vectoriel puis fusionne les résultats classés, avec de meilleures performances que chacun isolément (Salesforce Engineering).
5. Re-vectorisez au changement, pas selon un calendrier. Liez la réindexation aux événements de modification, sinon votre agent citera avec aplomb le statut du trimestre dernier.

Comment rendre la recherche respectueuse des droits sans reconstruire le partage ?

C'est l'exigence qui sépare un système RAG d'entreprise d'une démonstration, et elle n'a qu'une forme sûre : filtrer avant de rechercher, avec l'identité de l'utilisateur qui pose la question.

Trois modèles, du plus solide au moins solide.

• Recherche pré-filtrée. La requête porte l'identité, la couche de recherche restreint les candidats à ce que cet utilisateur peut voir, et le classement se fait dans cet ensemble. Correct, et le seul qui survive à un audit.
• Index segmentés. Un index par audience, par région ou par unité. Viable quand le modèle d'accès est grossier et stable, ingérable sinon.
• Filtrage à posteriori. Rechercher large puis retirer ce que l'utilisateur ne peut pas voir. À éviter. Les enregistrements restreints occupent quand même les placés du top k, la réponse se dégrade donc en silence, et tout signal de classement exposé révèle l'existence des enregistrements écartés.

Quel que soit le stockage, l'identité doit circuler de bout en bout : session, recherche, invite et journal d'audit. Ne demandez jamais au modèle de langue d'appliquer les droits. C'est un prédicteur de texte, pas un moteur de politique, et une consigne d'invite n'est pas un contrôle de sécurité.

Comment savoir si la recherche est réellement bonne ?

La plupart des équipes ne savent pas répondre, et c'est pour cela qu'elles changent de modèle. Séparez les deux modes d'échec : soit le bon enregistrement n'était pas dans le contexte, soit il y était et le modèle l'a ignoré. Seul le second est un problème de modèle.

1. Constituez un jeu de référence de 100 à 200 vraies questions d'utilisateurs, chacune associée aux identifiants qui y répondent vraiment.
2. Mesurez la recherche seule avec le rappel à k et le rang réciproque moyen. Si le bon enregistrement n'est pas dans le top k, rien en aval ne vous sauvera.
3. Suivez aussi la précision du contexte. Remplir l'invite de fragments quasi identiques coûte du budget et rend le modèle évasif.
4. Exécutez le jeu de référence en CI à chaque changement de découpage, de vecteurs, de classement ou de filtres, et traitez une baisse comme un échec de build.
5. Évaluez seulement ensuite les réponses, avec des citations vers les identifiants pour qu'un relecteur puisse vérifier dans Salesforce.

Les équipes qui ajoutent ce harnais découvrent en général que leur rappel tournait autour de la moitié, et qu'aucune mise à niveau de modèle n'allait corriger cela.

À quoi ressemble une pile qui tient ?

Natif ou externe compte moins que le contrat de recherche. Data 360 prend en charge la recherche vectorielle et des retrievers sur du contenu non structuré comme les articles de connaissance, les PDF et les transcriptions (aide Salesforce), ce qui garde l'ancrage près des données et dans la gouvernance de la plateforme. Un stockage vectoriel externe donne plus de contrôle sur le découpage, le classement hybride et les corpus multi-systèmes, ce qui compte quand la réponse vit aussi dans l'ERP ou l'outil de tickets.

Choisissez l'un ou l'autre, mais écrivez d'abord le contrat : ce qu'est un fragment, quelles métadonnées chaque fragment porte, comment l'identité est appliquée, et ce que le jeu de référence appelle bon. Nous construisons des systèmes RAG agentiques sur ce modèle, à travers Salesforce et plus de 70 systèmes d'entreprise, et c'est au contrat, pas au modèle, que nous consacrons le plus de temps. Plus de détails sur notre façon de travailler chez Tekunda.

FAQ

Un modèle plus gros corrige-t-il une mauvaise recherche ?

Non. Si l'enregistrement qui contient la réponse n'entre jamais dans la fenêtre de contexte, la taille du modèle n'a aucune importance. Corrigez le rappel d'abord, comparez les modèles ensuite.

Faut-il affiner un modèle plutôt que faire du RAG sur des données CRM ?

Rarement. Les données CRM changent tous les jours et l'accès est par utilisateur : un modèle affine serait périmé et incapable de respecter le partage. L'affinage sert au comportement et au format, la recherche aux faits.

Comment éviter que l'agent divulgue des enregistrements interdits ?

Filtrez les candidats selon les droits de l'utilisateur avant le classement, et journalisez chaque recherche avec cette identité. Les consignes d'invite ne sont pas un contrôle d'accès.

À quelle fréquence rafraîchir l'index ?

Pilotez-le par les événements de modification plutôt que par un traitement nocturne. Dans un corpus CRM, un index périmé donne des réponses fausses d'une manière difficile à détecter pour les utilisateurs.