Enterprise RAG auf Salesforce-Daten: eine tragfähige Architektur

Kurze Antwort: Über den Erfolg von RAG auf Salesforce-Daten entscheidet die Qualität der Suche, nicht die Wahl des Modells. Ein Spitzenmodell, dem die falschen drei Datensätze vorgelegt werden, antwortet selbstbewusst falsch, und ein Modellwechsel ändert daran nichts. Drei Dinge bewegen wirklich etwas: was Sie als Chunk behandeln, wie Berechtigungen während der Suche durchgesetzt werden, und ob Sie Suche getrennt von Generierung messen.

Warum scheitert RAG auf CRM-Daten häufiger als auf Dokumenten?

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

• Datensätze sind kurz und repetitiv. Zehntausend Fälle zum gleichen Produkt erzeugen nahezu identische Vektoren, die Ähnlichkeitssuche 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 enthält sie.
• Der Korpus verändert sich ständig. Opportunities wechseln die Phase, Fälle schließen, 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 müssen 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 häufigsten reparieren sollen. Ein Feldwert ist keine auffindbare Bedeutungseinheit. Setzen Sie stattdessen zusammen.

1. Chunken Sie auf Ebene eines Geschäftsereignisses, nicht eines Feldes. Bei einem Fall sind das Betreff, Beschreibung, Lösung und Kommentarverlauf als eine Passage. Bei einer Opportunity der Datensatz samt Abschlussgrund und Kernnotizen.
2. Denormalisieren Sie die Bezeichner, die ein Mensch nutzen würde. Accountname, Produktname, Seriennummer, Vertragsnummer. Vektoren lösen keine Fremdschlüssel auf.
3. Führen Sie harte Metadaten neben dem Vektor. Objekttyp, Datensatz-Id, Eigentümer, Account, letztes Änderungsdatum. 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 schwächsten 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 Änderung, nicht nach Zeitplan. Koppeln Sie die Neuindizierung an Änderungsereignisse, sonst zitiert Ihr Agent überzeugt 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 Identität der fragenden Person.

Drei Muster, absteigend nach Haltbarkeit.

• Vorgefilterte Suche. Die Abfrage trägt die Identität, die Suchschicht beschränkt 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 Geschäftsbereich. Tragfähig bei grobem, stabilem Zugriffsmodell, sonst unbeherrschbar.
• Nachträgliches Filtern. Breit abrufen und danach entfernen, was die Person nicht sehen darf. Bitte nicht. Gesperrte Datensätze belegen trotzdem die Top-k-Plätze, die Antwort verschlechtert sich also unbemerkt, und jedes sichtbare Ranking-Signal verrät die Existenz der herausgefilterten Datensätze.

Welcher Speicher es auch wird, die Identität muss durchgängig 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 können das nicht beantworten, und deshalb wechseln sie ständig 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 Kontextpräzision. Den Prompt mit Fast-Duplikaten zu füllen kostet Budget und macht das Modell ausweichend.
4. Führen Sie das Referenzset in der CI bei jeder Änderung an Chunking, Vektoren, Ranking oder Filtern aus und behandeln Sie einen Rückgang als Build-Fehler.
5. Erst danach bewerten Sie Antworten, mit Zitaten auf Datensatz-Ids, damit eine Prüfung in Salesforce möglich ist.

Teams, die dieses Messgerüst ergänzen, stellen meist fest, dass ihr Recall bei etwa der Hälfte lag und kein Modellwechsel das je behoben hatte.

Wie sieht ein tragfähiger Stack aus?

Nativ oder extern zählt weniger als der Suchvertrag. Data 360 unterstützt Vektorsuche und Retriever über unstrukturierte Inhalte wie Wissensartikel, PDFs und Transkripte (Salesforce Hilfe), was die Verankerung nah an den Daten und innerhalb der Governance hält. Ein externer Vektorspeicher gibt mehr Kontrolle über Chunking, hybrides Ranking und systemübergreifende Korpora, was zählt, wenn die Antwort auch im ERP oder im Ticketsystem liegt.

Wählen Sie eines, aber schreiben Sie zuerst den Vertrag auf: Was ist ein Chunk, welche Metadaten trägt jeder Chunk, wie wird Identität durchgesetzt, und was nennt das Referenzset gut. Wir bauen agentische RAG-Systeme nach diesem Muster über Salesforce und über 70 Unternehmenssysteme hinweg, und die meiste Zeit fließt in den Vertrag, nicht in das Modell. Mehr zu unserer Arbeitsweise bei Tekunda.

FAQ

Behebt ein größeres Modell schlechte Suche?

Nein. Gelangt der antwortende Datensatz nie ins Kontextfenster, ist die Modellgröße gleichgültig. Erst den Recall reparieren, dann Modelle vergleichen.

Sollte ich lieber feinabstimmen statt RAG auf CRM-Daten?

Selten. CRM-Daten ändern sich täglich und Zugriff ist benutzerspezifisch, ein feinabgestimmtes Modell wäre also veraltet und könnte Sharing nicht respektieren. Feinabstimmung ist für Verhalten und Format, Suche für Fakten.

Wie verhindere ich, dass der Agent gesperrte Datensätze preisgibt?

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

Wie oft sollte der Index aktualisiert werden?

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