Enterprise RAG op Salesforce-data: een architectuur die standhoudt

Kort antwoord: de kwaliteit van retrieval bepaalt of RAG op Salesforce-data werkt, niet welk model je kiest. Een topmodel dat de verkeerde drie records krijgt, antwoordt zelfverzekerd en fout, en een ander model verandert daar niets aan. Wat wel telt: wat je als chunk beschouwt, hoe rechten tijdens retrieval worden afgedwongen, en of je retrieval los van generatie meet.

Waarom faalt RAG op CRM-data vaker dan op documenten?

Omdat een CRM-corpus de aannames breekt waarop document-RAG is gebouwd.

• Records zijn kort en repetitief. Tienduizend cases over hetzelfde product leveren bijna identieke embeddings op, dus similarity search geeft tien varianten van een antwoord.
• Betekenis leeft over objecten heen. Het antwoord op "waarom vertrok deze klant" ligt verspreid over een account, drie opportunities, een contract en een casethread. Geen enkel record bevat het.
• Het corpus verandert continu. Opportunities schuiven op, cases sluiten, contactpersonen wisselen van rol. Een documentcorpus is grotendeels statisch; een CRM-corpus is een bewegend doel met een index erachter.
• Toegang is per gebruiker. Twee mensen met dezelfde vraag moeten terecht verschillende antwoorden krijgen, een scenario dat de meeste RAG-tutorials niet eens kennen.

Wat is de juiste chunk als de bron een Salesforce-record is?

Chunken per veld is de fout die we het vaakst mogen repareren. Een veldwaarde is geen vindbare eenheid van betekenis. Stel in plaats daarvan samen.

1. Chunk op het niveau van een businessgebeurtenis, niet van een veld. Voor een case is dat onderwerp plus omschrijving plus oplossing plus de commentaarthread, als een passage. Voor een opportunity het record plus de sluitreden en de kernnotities.
2. Denormaliseer de identifiers die een mens zou gebruiken. Accountnaam, productnaam, serienummer, contractnummer. Embeddings lossen geen foreign keys op.
3. Bewaar harde metadata naast de vector. Objecttype, record-id, eigenaar, account, laatst gewijzigd. Elk filter dat je ooit bij de query nodig hebt, moet als metadata bestaan, niet als tekst.
4. Houd exacte matching in de lus. Casenummers, SKU's en foutcodes zijn precies waar pure vector search het zwakst is. De hybride search van Salesforce combineert keyword- en vectorindexen en fuseert de gerangschikte resultaten, met betere prestaties dan elk apart (Salesforce Engineering).
5. Her-embed bij wijziging, niet op schema. Koppel herindexering aan wijzigingsgebeurtenissen, anders citeert je agent overtuigd de status van vorig kwartaal.

Hoe maak je retrieval rechtenbewust zonder sharing opnieuw te bouwen?

Dit is de eis die een enterprise-RAG-systeem van een demo scheidt, en er is precies een veilige vorm: filter voordat je ophaalt, op basis van de identiteit van de vragende gebruiker.

Drie patronen, aflopend in houdbaarheid.

• Vooraf gefilterde retrieval. De query draagt de identiteit, de retrievallaag beperkt kandidaten tot wat die gebruiker mag zien, en ranking gebeurt binnen die set. Correct, en het enige dat een audit overleeft.
• Gesegmenteerde indexen. Een index per doelgroep, bijvoorbeeld per regio of business unit. Werkbaar bij een grof en stabiel toegangsmodel, onbeheersbaar zodra dat niet zo is.
• Achteraf filteren. Breed ophalen en daarna weglaten wat de gebruiker niet mag zien. Doe dit niet. Afgeschermde records bezetten alsnog de top-k-plaatsen, dus het antwoord verslechtert stilletjes, en elk rankingsignaal dat de gebruiker ziet verraadt het bestaan van de gefilterde records.

Welke store je ook kiest, identiteit moet helemaal doorlopen: sessie, retrieval, prompt en auditlog. Vraag het taalmodel nooit om toegang af te dwingen. Het is een tekstvoorspeller, geen policy-engine, en een promptinstructie is geen beveiligingsmaatregel.

Hoe weet je of retrieval echt goed is?

De meeste teams kunnen dit niet beantwoorden, en daarom blijven ze van model wisselen. Scheid de twee faalvormen: of het juiste record zat niet in de context, of het zat erin en het model negeerde het. Alleen het tweede is een modelprobleem.

1. Bouw een goldenset van 100 tot 200 echte vragen van echte gebruikers, elk gelabeld met de record-ids die hem werkelijk beantwoorden.
2. Meet retrieval apart met recall at k en mean reciprocal rank. Zit het juiste record niet in de top k, dan redt niets stroomafwaarts je nog.
3. Meet ook contextprecisie. De prompt vullen met bijna-duplicaten kost budget en maakt het model vaag.
4. Draai de goldenset in CI bij elke wijziging aan chunking, embeddings, ranking of filters, en behandel een daling als een gefaalde build.
5. Evalueer pas daarna antwoorden, met citaties naar record-ids zodat een reviewer de claim in Salesforce kan controleren.

Teams die dit meetharnas toevoegen, ontdekken meestal dat hun recall rond de helft lag, en dat geen enkele modelupgrade dat ooit had opgelost.

Hoe ziet een stack eruit die standhoudt?

Native of extern telt minder dan het retrievalcontract. Data 360 ondersteunt vector search en retrievers over ongestructureerde content zoals kennisartikelen, pdf's en transcripties (Salesforce Help), wat grounding dicht bij de data en binnen de governance van het platform houdt. Een externe vectorstore geeft meer controle over chunking, hybride ranking en corpora over systemen heen, wat telt als het antwoord ook in je ERP of ticketsysteem ligt.

Kies er een, maar schrijf eerst het contract op: wat is een chunk, welke metadata draagt elke chunk, hoe wordt identiteit afgedwongen, en wat noemt de goldenset goed. Wij bouwen agentic RAG-systemen volgens dit patroon over Salesforce en 70+ enterprisesystemen, en het is het contract, niet het model, waar de meeste tijd in gaat. Meer over hoe we werken staat bij Tekunda.

FAQ

Lost een groter model slechte retrieval op?

Nee. Komt het antwoordende record nooit in het contextvenster, dan is modelgrootte irrelevant. Repareer eerst recall, vergelijk daarna modellen.

Moet ik fine-tunen in plaats van RAG op CRM-data?

Zelden. CRM-data verandert dagelijks en toegang is per gebruiker, dus een fijngestemd model zou verouderd zijn en sharing niet kunnen respecteren. Fine-tuning is voor gedrag en vorm, retrieval voor feiten.

Hoe voorkom ik dat de agent records lekt die iemand niet mag zien?

Filter kandidaten op de toegang van de vragende gebruiker voordat je rangschikt, en log elke retrieval met die identiteit. Promptinstructies zijn geen toegangscontrole.

Hoe vaak moet de index worden ververst?

Stuur het op wijzigingsgebeurtenissen in plaats van een nachtelijke job. In een CRM-corpus levert een verouderde index antwoorden op die fout zijn op een manier die gebruikers slecht opmerken.