Enterprise RAG auf Salesforce-Daten: eine tragfahige Architektur

Kurze Antwort: Uber den Erfolg von RAG auf Salesforce-Daten entscheidet die Qualitat der Suche, nicht die Wahl des Modells. Ein Spitzenmodell, dem die falschen drei Datensatze vorgelegt werden, antwortet selbstbewusst falsch, und ein Modellwechsel andert daran nichts. Drei Dinge bewegen wirklich etwas: was Sie als Chunk behandeln, wie Berechtigungen wahrend der Suche durchgesetzt werden, und ob Sie Suche getrennt von Generierung messen.

Warum scheitert RAG auf CRM-Daten haufiger als auf Dokumenten?

Weil ein CRM-Korpus die Annahmen bricht, auf denen Dokument-RAG aufbaut.

• Datensatze sind kurz und repetitiv. Zehntausend Falle zum gleichen Produkt erzeugen nahezu identische Vektoren, die Ahnlichkeitssuche liefert also zehn Varianten einer Antwort.
• Bedeutung liegt zwischen Objekten. Die Antwort auf "warum ist dieser Kunde gegangen" verteilt sich auf einen Account, drei Opportunities, einen Vertrag und einen Fallverlauf. Kein einzelner Datensatz enthalt sie.
• Der Korpus verandert sich standig. Opportunities wechseln die Phase, Falle schliessen, Kontakte wechseln die Rolle. Ein Dokumentkorpus ist weitgehend statisch, ein CRM-Korpus ein bewegliches Ziel mit einem Index dahinter.
• Zugriff ist benutzerspezifisch. Zwei Personen mit derselben Frage mussen zu Recht unterschiedliche Antworten bekommen, ein Fall, den die meisten RAG-Anleitungen gar nicht kennen.

Was ist der richtige Chunk, wenn die Quelle ein Salesforce-Datensatz ist?

Feldweises Chunking ist der Fehler, den wir am haufigsten reparieren sollen. Ein Feldwert ist keine auffindbare Bedeutungseinheit. Setzen Sie stattdessen zusammen.

1. Chunken Sie auf Ebene eines Geschaftsereignisses, nicht eines Feldes. Bei einem Fall sind das Betreff, Beschreibung, Losung und Kommentarverlauf als eine Passage. Bei einer Opportunity der Datensatz samt Abschlussgrund und Kernnotizen.
2. Denormalisieren Sie die Bezeichner, die ein Mensch nutzen wurde. Accountname, Produktname, Seriennummer, Vertragsnummer. Vektoren losen keine Fremdschlussel auf.
3. Fuhren Sie harte Metadaten neben dem Vektor. Objekttyp, Datensatz-Id, Eigentumer, Account, letztes Anderungsdatum. Jeder Filter, den Sie zur Abfragezeit brauchen, muss als Metadatum existieren, nicht als Text.
4. Behalten Sie exakte Treffer im Spiel. Fallnummern, Artikelnummern und Fehlercodes sind genau dort, wo reine Vektorsuche am schwachsten ist. Die hybride Suche von Salesforce kombiniert Stichwort- und Vektorindex und fusioniert die Ranglisten, mit besserer Leistung als jede Methode allein (Salesforce Engineering).
5. Neu einbetten bei Anderung, nicht nach Zeitplan. Koppeln Sie die Neuindizierung an Anderungsereignisse, sonst zitiert Ihr Agent uberzeugt den Stand des letzten Quartals.

Wie wird die Suche berechtigungsbewusst, ohne Sharing neu zu bauen?

Das ist die Anforderung, die ein Unternehmens-RAG von einer Demo trennt, und sie hat genau eine sichere Form: vor dem Abruf filtern, mit der Identitat der fragenden Person.

Drei Muster, absteigend nach Haltbarkeit.

• Vorgefilterte Suche. Die Abfrage tragt die Identitat, die Suchschicht beschrankt Kandidaten auf das Sichtbare, und die Rangfolge entsteht innerhalb dieser Menge. Korrekt, und als Einziges auditfest.
• Segmentierte Indizes. Ein Index je Zielgruppe, etwa je Region oder Geschaftsbereich. Tragfahig bei grobem, stabilem Zugriffsmodell, sonst unbeherrschbar.
• Nachtragliches Filtern. Breit abrufen und danach entfernen, was die Person nicht sehen darf. Bitte nicht. Gesperrte Datensatze belegen trotzdem die Top-k-Platze, die Antwort verschlechtert sich also unbemerkt, und jedes sichtbare Ranking-Signal verrat die Existenz der herausgefilterten Datensatze.

Welcher Speicher es auch wird, die Identitat muss durchgangig mitlaufen: Sitzung, Suche, Prompt und Auditprotokoll. Bitten Sie nie das Sprachmodell, Zugriff durchzusetzen. Es ist ein Textvorhersager, keine Richtlinien-Engine, und eine Prompt-Anweisung ist keine Sicherheitskontrolle.

Woran erkennen Sie, ob die Suche wirklich gut ist?

Die meisten Teams konnen das nicht beantworten, und deshalb wechseln sie standig das Modell. Trennen Sie die beiden Fehlerarten: Entweder war der richtige Datensatz nicht im Kontext, oder er war da und das Modell hat ihn ignoriert. Nur Zweiteres ist ein Modellproblem.

1. Bauen Sie ein Referenzset aus 100 bis 200 echten Nutzerfragen, jeweils mit den Datensatz-Ids beschriftet, die sie wirklich beantworten.
2. Messen Sie die Suche allein mit Recall at k und Mean Reciprocal Rank. Fehlt der richtige Datensatz in den Top k, rettet Sie nichts weiter unten.
3. Verfolgen Sie auch die Kontextprazision. Den Prompt mit Fast-Duplikaten zu fullen kostet Budget und macht das Modell ausweichend.
4. Fuhren Sie das Referenzset in der CI bei jeder Anderung an Chunking, Vektoren, Ranking oder Filtern aus und behandeln Sie einen Ruckgang als Build-Fehler.
5. Erst danach bewerten Sie Antworten, mit Zitaten auf Datensatz-Ids, damit eine Prufung in Salesforce moglich ist.

Teams, die dieses Messgerust erganzen, stellen meist fest, dass ihr Recall bei etwa der Halfte lag und kein Modellwechsel das je behoben hatte.

Wie sieht ein tragfahiger Stack aus?

Nativ oder extern zahlt weniger als der Suchvertrag. Data 360 unterstutzt Vektorsuche und Retriever uber unstrukturierte Inhalte wie Wissensartikel, PDFs und Transkripte (Salesforce Hilfe), was die Verankerung nah an den Daten und innerhalb der Governance halt. Ein externer Vektorspeicher gibt mehr Kontrolle uber Chunking, hybrides Ranking und systemubergreifende Korpora, was zahlt, wenn die Antwort auch im ERP oder im Ticketsystem liegt.

Wahlen Sie eines, aber schreiben Sie zuerst den Vertrag auf: Was ist ein Chunk, welche Metadaten tragt jeder Chunk, wie wird Identitat durchgesetzt, und was nennt das Referenzset gut. Wir bauen agentische RAG-Systeme nach diesem Muster uber Salesforce und uber 70 Unternehmenssysteme hinweg, und die meiste Zeit fliesst in den Vertrag, nicht in das Modell. Mehr zu unserer Arbeitsweise bei Tekunda.

FAQ

Behebt ein grosseres Modell schlechte Suche?

Nein. Gelangt der antwortende Datensatz nie ins Kontextfenster, ist die Modellgrosse gleichgultig. Erst den Recall reparieren, dann Modelle vergleichen.

Sollte ich lieber feinabstimmen statt RAG auf CRM-Daten?

Selten. CRM-Daten andern sich taglich und Zugriff ist benutzerspezifisch, ein feinabgestimmtes Modell ware also veraltet und konnte Sharing nicht respektieren. Feinabstimmung ist fur Verhalten und Format, Suche fur Fakten.

Wie verhindere ich, dass der Agent gesperrte Datensatze preisgibt?

Kandidaten vor dem Ranking nach den Rechten der fragenden Person filtern und jede Suche mit dieser Identitat protokollieren. Prompt-Anweisungen sind keine Zugriffskontrolle.

Wie oft sollte der Index aktualisiert werden?

Steuern Sie ihn uber Anderungsereignisse statt uber einen Nachtlauf. In einem CRM-Korpus erzeugt ein veralteter Index Antworten, deren Fehler Nutzer nur schwer bemerken.