Die meisten Salesforce-Teams brauchen keine Vektorsuche. Knowledge Articles mit sauberer Struktur lösen 80 Prozent aller Anwendungsfälle. Trotzdem taucht RAG (Retrieval-Augmented Generation) in fast jedem Gespräch über KI in Salesforce auf, als wäre es die einzige Option. Das ist es nicht. Und wer zu früh auf Vektorsuche setzt, baut Komplexität auf, die sich selten auszahlt.
Dieser Artikel erklärt, was RAG tatsächlich bedeutet, wann Knowledge Articles ausreichen und ab welchem Punkt Vektorsuche eine sinnvolle Ergänzung wird. Keine Hype-Versprechen, sondern eine nüchterne Einordnung für Teams, die Salesforce produktiv einsetzen.
Was RAG eigentlich ist
RAG steht für Retrieval-Augmented Generation. Das Prinzip: Ein Sprachmodell (LLM) bekommt nicht nur eine Frage, sondern auch relevante Dokumente als Kontext mitgeliefert. Statt aus seinem Trainingsmaterial zu antworten, nutzt es eure Unternehmensdaten. Das reduziert Halluzinationen und macht die Antworten spezifisch für euren Kontext.
Der entscheidende Punkt: RAG ist ein Muster, keine Technologie. Es beschreibt, wie man einem Sprachmodell externe Informationen zur Verfügung stellt. Das kann über eine einfache Datenbankabfrage passieren, über eine Volltextsuche oder über Vektoren. Die Methode des Retrievals bestimmt, wie gut die Ergebnisse sind, und welchen Aufwand ihr dafür betreibt.
Knowledge Articles: was Salesforce bereits mitbringt
Salesforce Knowledge ist seit Jahren Teil der Service Cloud. Artikel werden in Kategorien organisiert, mit Data Categories versehen und sind über die eingebaute Suche auffindbar. Die Suche basiert auf Keyword-Matching und SOSL (Salesforce Object Search Language), also Volltextsuche mit Stemming und Synonymen.
Für viele Anwendungsfälle reicht das vollkommen aus. FAQ-Seiten, Standard Operating Procedures, Produktdokumentation, Onboarding-Material. Überall dort, wo Inhalte strukturiert sind und Nutzer ungefähr wissen, wonach sie suchen, liefern Knowledge Articles zuverlässige Ergebnisse.
Die Vorteile liegen auf der Hand: Keine zusätzliche Infrastruktur, keine Embedding-Pipeline, keine Vector Database. Alles läuft innerhalb der Salesforce-Plattform. Ihr zahlt, was ihr ohnehin zahlt. Die Wartung beschränkt sich auf das Pflegen der Artikel selbst, nicht auf das Pflegen einer separaten Such-Infrastruktur.
Wo Keyword-Suche an Grenzen stößt
Keyword-basierte Suche funktioniert, solange Nutzer die richtigen Begriffe verwenden. Ein Service-Agent, der nach "Rücksendung defektes Gerät" sucht, findet den Artikel "Retourenabwicklung bei Garantiefällen" nur, wenn die richtigen Synonyme hinterlegt sind. Oder wenn der Artikeltitel zufällig die Suchbegriffe enthält.
Das Problem wird größer, je unstrukturierter die Suchanfragen sind. Kunden beschreiben Probleme in ihrer eigenen Sprache: "Das Ding piept und blinkt rot." Kein Keyword-Index der Welt verbindet das zuverlässig mit dem richtigen Troubleshooting-Artikel. Hier braucht es semantisches Verständnis, die Fähigkeit, die Bedeutung hinter den Worten zu erkennen, nicht nur die Worte selbst.
Ähnliches gilt für Case-Historien. Wenn ein Agent wissen will, wie ähnliche Fälle in der Vergangenheit gelöst wurden, hilft eine Keyword-Suche wenig. Cases sind Freitext, geschrieben von verschiedenen Leuten in verschiedenen Stilen. Die Lösung steckt oft in der Beschreibung, nicht in einem strukturierten Feld.
Wie Vektorsuche funktioniert
Vektorsuche basiert auf Embeddings. Jedes Dokument wird durch ein Sprachmodell in einen Zahlenvektor umgewandelt, der seine semantische Bedeutung repräsentiert. Ähnliche Texte liegen im Vektorraum nahe beieinander, auch wenn sie völlig andere Worte verwenden.
Eine Suchanfrage wird ebenfalls in einen Vektor umgewandelt und dann mit den gespeicherten Vektoren verglichen. Das Ergebnis: Die semantisch ähnlichsten Dokumente, unabhängig von exakten Keyword-Übereinstimmungen. "Das Ding piept und blinkt rot" findet den Artikel über Fehlercodes beim Modell XY-3000, weil der Kontext passt, nicht weil die Worte übereinstimmen.
Das klingt nach einem klaren Upgrade. Ist es auch, aber mit erheblichem Aufwand. Ihr braucht eine Embedding-Pipeline, die eure Dokumente verarbeitet und aktuell hält. Eine Vector Database (Pinecone, Weaviate, pgvector) zum Speichern und Abfragen. Und eine Orchestrierungsschicht, die Salesforce mit dieser Infrastruktur verbindet. Salesforce Data Cloud bietet inzwischen eigene Vector-Search-Funktionen, aber auch die sind nicht ohne Konfigurationsaufwand.
Die Entscheidungsmatrix
Die Entscheidung zwischen Knowledge Articles und Vektorsuche ist keine Glaubensfrage. Sie hängt von vier Faktoren ab:
Datenstruktur: Sind eure Inhalte strukturiert (Artikel, SOPs, FAQ) oder unstrukturiert (Cases, E-Mails, Notizen)? Strukturierte Daten funktionieren mit Knowledge Articles. Unstrukturierte Daten profitieren von Vektorsuche.
Suchverhalten: Wissen eure Nutzer, wonach sie suchen? Wenn ja, reichen Keywords. Wenn Nutzer Probleme in eigenen Worten beschreiben und ihr das richtige Dokument finden müsst, braucht ihr semantische Suche.
Volumen: Bei 200 Knowledge Articles ist Keyword-Suche schnell und effektiv. Bei 50.000 Cases aus fünf Jahren wird die Keyword-Suche zum Glücksspiel. Vektorsuche skaliert besser bei großen, heterogenen Datenmengen.
Budget und Wartung: Knowledge Articles kosten nichts extra. Vektorsuche bedeutet laufende Kosten für Embeddings, Speicher und Wartung. Für ein Team von zehn Service-Agenten lohnt sich der Aufwand selten. Für ein Unternehmen mit 200 Agenten und 100.000 Cases pro Jahr sieht die Rechnung anders aus.
Der Hybridansatz: erst die Basis, dann die Erweiterung
In der Praxis ist die Antwort selten "entweder oder". Der sinnvollste Weg: erst Knowledge Articles sauber aufbauen, dann Vektorsuche als Ergänzung hinzufügen, wo Keyword-Suche nicht ausreicht.
Knowledge Articles bleiben die Basis für alles, was strukturiert und gepflegt werden kann. Die Vektorsuche übernimmt den Long Tail: historische Cases, E-Mail-Verläufe, Freitext-Notizen. Beide Systeme füttern dasselbe RAG-Setup, das Sprachmodell bekommt Ergebnisse aus beiden Quellen.
Dieser Ansatz hat einen weiteren Vorteil: Wenn die Knowledge Articles gut sind, wird die Vektorsuche besser. Denn sie findet nicht nur unstrukturierte Daten, sondern auch die strukturierten Artikel, wenn die semantische Suche relevantere Ergebnisse liefert als das Keyword-Matching.
Wer seine Datenqualität im CRM im Griff hat, hat auch eine bessere Ausgangslage für Vektorsuche. Denn Embeddings sind nur so gut wie die Daten, aus denen sie erzeugt werden.
Die meisten Teams, die wir sehen, sind mit Knowledge Articles noch lange nicht am Limit. Bevor ihr eine Embedding-Pipeline baut, stellt sicher, dass eure bestehenden Artikel vollständig, aktuell und sauber kategorisiert sind. Das allein löst oft mehr Probleme, als die aufwändigste Vektorsuche.