Produktwissen im Angebotsprozess: Wann RAG hilft – und wann Suche reicht

Im technischen Vertrieb entsteht schnell die Frage, ob für Produktwissen bereits ein RAG-System notwendig ist. Oft ist diese Frage zu früh gestellt. Zuerst sollte geklärt werden, welche Aufgabe gelöst werden soll: ein exakter Wert aus einem führenden System, ein vorhandenes Dokument oder ein formulierter Antwortentwurf aus mehreren Quellen.

Dieser Beitrag verwendet ein Trixner-Entscheidungsraster. Es ist ein redaktionelles Arbeitsmodell und kein allgemeingültiger Standard. Es ordnet drei technische Wege nach der gewünschten Ausgabe ein: strukturierte Produktdaten, klassische Suche und Retrieval-Augmented Generation.

Strukturierte Produktdaten liegen in definierten Feldern und Datensätzen vor – etwa Artikelnummer, Variante, Abmessung oder interner Status. Wenn ein verbindlicher Wert gesucht wird, sollte zuerst geklärt werden, welches System diesen Wert fachlich führt.

Volltextsuche durchsucht indexierte Textfelder und ordnet Treffer nach ihrer Relevanz. Die aktuelle Elastic-Dokumentation beschreibt sie als lexikalische Suche, bei der Dokumente und Suchanfragen für die Suche analysiert werden. Das Ergebnis bleibt eine Trefferliste mit Originalquellen.

Retrieval-Augmented Generation (RAG) verbindet Abruf und Textgenerierung. Die ursprüngliche RAG-Publikation beschreibt dafür einen Retriever, der Textpassagen auswählt, und einen Generator, der diese Passagen bei der Antworterzeugung verwendet. Das Ergebnis ist ein formulierter Entwurf – nicht die ursprüngliche Quelle selbst.

Die Tabelle ist keine automatische Systemauswahl. Sie trennt zunächst die Erwartungen. Erst danach lässt sich entscheiden, welche Such- oder Generierungskomponente überhaupt geprüft werden soll.

Für exakt definierte Werte ist eine generierte Antwort meist nicht der erste Prüfpunkt. Entscheidend ist, wo Artikel, Varianten und gültige Zustände fachlich geführt werden. Ein Sprachmodell kann später beim Erklären oder Formulieren unterstützen; die Herkunft des konkreten Werts sollte davon getrennt bleiben.

• Ist die Anfrage über Artikelnummer, Variante oder ein anderes eindeutiges Merkmal bestimmbar?
• Liegt der benötigte Wert bereits in einem strukturierten Feld vor?
• Welches System gilt intern als führende Quelle?
• Welche Werte dürfen nur nach einer fachlichen oder kaufmännischen Prüfung verwendet werden?

Wenn diese Fragen klar beantwortet werden können, ist zunächst ein sauberer Datenzugriff zu prüfen. RAG ersetzt keine fehlende Festlegung darüber, welcher Produktdatensatz gelten soll.

Eine Suche ist ein guter Ausgangspunkt, wenn Mitarbeitende vor allem die richtige Originalquelle finden müssen. Das gilt besonders dann, wenn Produktnamen, Artikelnummern, Normbegriffe oder Dokumenttitel bekannt sind und die gefundene Passage anschließend selbst gelesen werden soll.

• Reicht eine Liste passender Dokumente oder Textstellen als Ergebnis?
• Sind die verwendeten Begriffe in Anfrage und Quelle ähnlich?
• Kann die Frage überwiegend aus einer einzelnen Quelle beantwortet werden?
• Soll der Nutzer bewusst im Originaldokument weiterarbeiten?

Praxis-Kniff: Nehmen Sie eine kleine Auswahl realer Suchanfragen aus Vertrieb und Technik. Notieren Sie für jede Anfrage, ob ein passendes Originaldokument gefunden wurde und ob dieses Dokument allein für die weitere Bearbeitung ausreicht. Die Auswahl ist eine Arbeitsprobe, kein allgemeiner Mindestumfang.

RAG kommt als zusätzliche Schicht infrage, wenn die gewünschte Ausgabe über eine Trefferliste hinausgeht. Der Nutzer stellt eine Frage in normaler Sprache, relevante Passagen werden abgerufen und ein Modell formuliert daraus einen Entwurf. Die Quellen sollten dabei für die Prüfung sichtbar bleiben.

Für einen begrenzten Pilot können insbesondere folgende Situationen geprüft werden:

• Die Antwort soll Informationen aus mehreren freigegebenen Dokumenten zusammenführen.
• Anfrage und Quelle verwenden unterschiedliche Bezeichnungen für denselben Sachverhalt.
• Der Vertrieb benötigt einen kompakten Arbeitsentwurf statt nur einer Trefferliste.
• Die Antwort soll auf die verwendeten Passagen oder Dokumente zurückverweisen.
• Bei fehlender Grundlage soll das System keine fertige Aussage formulieren, sondern die Lücke sichtbar machen.

Diese Punkte beschreiben Prüfanlässe, keine zugesicherte Wirkung. Ob RAG für den eigenen Bestand geeignet ist, zeigt erst ein Test mit freigegebenen Quellen, realen Fragen und zuvor festgelegten Bewertungskriterien.

RAG enthält selbst einen Suchschritt. Der Unterschied liegt vor allem darin, was nach dem Abruf passiert: Eine klassische Suche zeigt Treffer; ein RAG-Ablauf übergibt ausgewählte Passagen zusätzlich an ein Sprachmodell. Auch die Art des Abrufs kann kombiniert werden. Microsoft und Elastic dokumentieren beispielsweise technische Ansätze, die lexikalische und semantische Suche gemeinsam verwenden.

Für Produktwissen kann daher eine abgestufte Architektur sinnvoll sein:

1. Strukturierte Filter grenzen Produktgruppe, Variante oder Gültigkeitsbereich ein.
2. Eine Suchkomponente ruft passende Dokumente oder Passagen ab.
3. Nur wenn ein formulierter Entwurf benötigt wird, erhält ein Sprachmodell den ausgewählten Kontext.
4. Ein Mensch prüft Quellen, Werte und den vorgesehenen Verwendungszweck.

Diese Reihenfolge ist eine Gestaltungsoption. Sie soll verhindern, dass ein generatives Modell Aufgaben übernimmt, für die ein klarer Datensatz oder eine Trefferliste bereits die passendere Ausgabe wäre.

Vor einer Tool- oder Plattformentscheidung können Geschäftsführung, Vertriebsleitung und Technik den Anwendungsfall anhand dieser sechs Fragen eingrenzen:

1. Ausgabe: Wird ein exakter Wert, eine Originalquelle oder ein formulierter Entwurf benötigt?
2. Datenform: Liegt die Information strukturiert vor oder nur in Dokumenten und Freitext?
3. Quellenumfang: Genügt eine Quelle oder müssen mehrere Passagen zusammengeführt werden?
4. Aktualität: Woran wird der freigegebene Stand erkannt?
5. Zugriff: Welche Rollen dürfen die verwendeten Inhalte sehen?
6. Freigabe: Wer prüft die Ausgabe, bevor sie in einen Angebotsprozess einfließt?

Praxis-Kniff: Legen Sie drei Spalten mit den Überschriften „Wert“, „Quelle“ und „Entwurf“ an. Ordnen Sie reale Produktfragen zunächst nur nach der erwarteten Ausgabe zu. Erst im zweiten Schritt wird für jede Gruppe ein technischer Lösungsweg diskutiert.

Wenn RAG nach der Einordnung als Kandidat übrig bleibt, sollte der erste Testbereich fachlich eng beschrieben werden. Dafür können eine Produktgruppe, ein definierter Dokumentbestand und eine verantwortliche Nutzergruppe festgelegt werden.

Zum Prüfplan gehören sowohl beantwortbare als auch bewusst nicht beantwortbare Fragen. Bewertet wird nicht nur der Textstil. Wichtiger sind die verwendete Quelle, der richtige Produkt- und Variantenbezug, sichtbare Unsicherheit sowie der Umfang der notwendigen Korrektur.

Wie Scope, Testfragen und Abbruchkriterien für diesen Schritt vorbereitet werden können, beschreibt der Beitrag RAG-Pilot richtig planen.

Für exakte Produktwerte führt der erste Weg zu strukturierten Daten und klaren Verantwortlichkeiten. Für das Auffinden bekannter Quellen kann eine gut eingerichtete Suche ausreichen. RAG wird dann interessant, wenn aus mehreren passenden Passagen ein prüfbarer Arbeitsentwurf entstehen soll.

Die drei Wege schließen einander nicht aus. Ein belastbarer Pilot trennt sie jedoch sauber nach Aufgabe, Quelle und Freigabe. Wer diese Entscheidung am eigenen Produktwissen prüfen möchte, findet unter RAG-Pilot den passenden nächsten Schritt.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Full-text search
• Retrieval-augmented generation (RAG) in Azure AI Search