RAG d'entreprise sur les donnees Salesforce : une architecture solide

Reponse courte : c'est la qualite de la recherche documentaire qui decide si le RAG sur des donnees Salesforce fonctionne, pas le choix du modele. Un modele de pointe a qui l'on donne les trois mauvais enregistrements repondra avec assurance et a cote, et changer de modele n'y change rien. Trois choses comptent vraiment : ce que vous considerez comme un fragment, la maniere dont les droits sont appliques pendant la recherche, et le fait de mesurer la recherche separement de la generation.

Pourquoi le RAG sur des donnees CRM echoue-t-il plus souvent que sur des documents ?

Parce qu'un corpus CRM casse les hypotheses sur lesquelles repose le RAG documentaire.

• Les enregistrements sont courts et repetitifs. Dix mille requetes sur le meme produit produisent des vecteurs presque identiques, la recherche par similarite renvoie donc dix variantes d'une seule reponse.
• Le sens vit entre les objets. La reponse a "pourquoi ce client est-il parti" se repartit sur un compte, trois opportunites, un contrat et un fil de requete. Aucun enregistrement ne la contient.
• Le corpus change sans arret. Les opportunites changent d'etape, les requetes se ferment, les contacts changent de role. Un corpus documentaire est surtout statique, un corpus CRM est une cible mouvante avec un index derriere.
• L'acces est propre a chaque utilisateur. Deux personnes posant la meme question doivent legitimement obtenir des reponses differentes, un cas que la plupart des tutoriels RAG n'envisagent meme pas.

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

Le decoupage champ par champ est l'erreur qu'on nous demande le plus souvent de corriger. La valeur d'un champ n'est pas une unite de sens recuperable. Assemblez plutot.

1. Decoupez au niveau d'un evenement metier, pas d'un champ. Pour une requete : objet, description, resolution et fil de commentaires, rendus en un seul passage. Pour une opportunite : l'enregistrement, son motif de cloture et les notes cles.
2. Denormalisez les identifiants qu'un humain utiliserait. Nom du compte, nom du produit, numero de serie, numero de contrat. Les vecteurs ne resolvent pas les cles etrangeres.
3. Conservez des metadonnees dures a cote du vecteur. Type d'objet, identifiant, proprietaire, compte, date de derniere modification. Tout filtre dont vous aurez besoin a la requete doit exister comme metadonnee, pas comme texte.
4. Gardez la correspondance exacte dans la boucle. Numeros de requete, references produit et codes d'erreur sont precisement la ou la recherche vectorielle pure est la plus faible. La recherche hybride de Salesforce combine index par mots-cles et index vectoriel puis fusionne les resultats classes, avec de meilleures performances que chacun isolement (Salesforce Engineering).
5. Re-vectorisez au changement, pas selon un calendrier. Liez la reindexation aux evenements 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 separe un systeme RAG d'entreprise d'une demonstration, et elle n'a qu'une forme sure : filtrer avant de rechercher, avec l'identite de l'utilisateur qui pose la question.

Trois modeles, du plus solide au moins solide.

• Recherche pre-filtree. La requete porte l'identite, la couche de recherche restreint les candidats a ce que cet utilisateur peut voir, et le classement se fait dans cet ensemble. Correct, et le seul qui survive a un audit.
• Index segmentes. Un index par audience, par region ou par unite. Viable quand le modele d'acces est grossier et stable, ingerable sinon.
• Filtrage a posteriori. Rechercher large puis retirer ce que l'utilisateur ne peut pas voir. A eviter. Les enregistrements restreints occupent quand meme les places du top k, la reponse se degrade donc en silence, et tout signal de classement expose revele l'existence des enregistrements ecartes.

Quel que soit le stockage, l'identite doit circuler de bout en bout : session, recherche, invite et journal d'audit. Ne demandez jamais au modele de langue d'appliquer les droits. C'est un predicteur de texte, pas un moteur de politique, et une consigne d'invite n'est pas un controle de securite.

Comment savoir si la recherche est reellement bonne ?

La plupart des equipes ne savent pas repondre, et c'est pour cela qu'elles changent de modele. Separez les deux modes d'echec : soit le bon enregistrement n'etait pas dans le contexte, soit il y etait et le modele l'a ignore. Seul le second est un probleme de modele.

1. Constituez un jeu de reference de 100 a 200 vraies questions d'utilisateurs, chacune associee aux identifiants qui y repondent vraiment.
2. Mesurez la recherche seule avec le rappel a k et le rang reciproque moyen. Si le bon enregistrement n'est pas dans le top k, rien en aval ne vous sauvera.
3. Suivez aussi la precision du contexte. Remplir l'invite de fragments quasi identiques coute du budget et rend le modele evasif.
4. Executez le jeu de reference en CI a chaque changement de decoupage, de vecteurs, de classement ou de filtres, et traitez une baisse comme un echec de build.
5. Evaluez seulement ensuite les reponses, avec des citations vers les identifiants pour qu'un relecteur puisse verifier dans Salesforce.

Les equipes qui ajoutent ce harnais decouvrent en general que leur rappel tournait autour de la moitie, et qu'aucune mise a niveau de modele n'allait corriger cela.

A 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 structure comme les articles de connaissance, les PDF et les transcriptions (aide Salesforce), ce qui garde l'ancrage pres des donnees et dans la gouvernance de la plateforme. Un stockage vectoriel externe donne plus de controle sur le decoupage, le classement hybride et les corpus multi-systemes, ce qui compte quand la reponse vit aussi dans l'ERP ou l'outil de tickets.

Choisissez l'un ou l'autre, mais ecrivez d'abord le contrat : ce qu'est un fragment, quelles metadonnees chaque fragment porte, comment l'identite est appliquee, et ce que le jeu de reference appelle bon. Nous construisons des systemes RAG agentiques sur ce modele, a travers Salesforce et plus de 70 systemes d'entreprise, et c'est au contrat, pas au modele, que nous consacrons le plus de temps. Plus de details sur notre facon de travailler chez Tekunda.

FAQ

Un modele plus gros corrige-t-il une mauvaise recherche ?

Non. Si l'enregistrement qui contient la reponse n'entre jamais dans la fenetre de contexte, la taille du modele n'a aucune importance. Corrigez le rappel d'abord, comparez les modeles ensuite.

Faut-il affiner un modele plutot que faire du RAG sur des donnees CRM ?

Rarement. Les donnees CRM changent tous les jours et l'acces est par utilisateur : un modele affine serait perime et incapable de respecter le partage. L'affinage sert au comportement et au format, la recherche aux faits.

Comment eviter 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 identite. Les consignes d'invite ne sont pas un controle d'acces.

A quelle frequence rafraichir l'index ?

Pilotez-le par les evenements de modification plutot que par un traitement nocturne. Dans un corpus CRM, un index perime donne des reponses fausses d'une maniere difficile a detecter pour les utilisateurs.