RAG oder Fine-Tuning? Erst den Fehler des Firmenchatbots verstehen

«Wir müssen die KI mit unseren Daten trainieren.» Der Satz steht oft am Anfang eines Firmenchatbots. Zuerst sollte aber die Frage stehen, was dem System fehlt. Kennt es aktuelle Vertragsbedingungen nicht? Hält es das gewünschte Ausgabeformat nicht ein? Oder liegen Ihre Unterlagen schlicht widersprüchlich vor? Diese Probleme brauchen unterschiedliche Lösungen. Ein Training ist nicht automatisch die passende Antwort auf fehlendes Firmenwissen.

Für viele kleine Unternehmen lohnt sich zunächst ein klarer Auftrag mit wenigen ausgewählten Unterlagen. Wenn daraus eine regelmässige Wissenssuche wird, kommt Retrieval Augmented Generation, kurz RAG, infrage. Fine-Tuning verändert dagegen das Modell anhand von Trainingsbeispielen. Beide können zusammen eingesetzt werden, lösen aber nicht dieselbe Aufgabe. Die Entscheidung sollte am beobachteten Fehler hängen, nicht an der beeindruckenderen Bezeichnung.

Drei Wege und ihre eigentliche Arbeit

Die AWS-Übersicht zu Dokumentenfragen unterscheidet direkt mitgegebenen Kontext, RAG und Anpassungen am Modell. Mit Anweisungen legen Sie Aufgabe, Grenzen und gewünschte Ausgabe fest. Für einen begrenzten Fall können Sie die relevanten Informationen direkt mitgeben. RAG sucht zur Frage passende Inhalte aus einem Bestand und stellt diese für die Antwort bereit. Fine-Tuning passt Modellverhalten anhand von Beispielen an. Auch ein angepasstes Modell benötigt einen Weg zu Fakten, die nach dem Training geändert werden.

Die AWS-Gegenüberstellung von RAG und Fine-Tuning empfiehlt für Fragen zu eigenen Dokumenten einen Einstieg mit RAG. Das ist eine hilfreiche Orientierung, keine Garantie für Ihr Projekt. Ob die Suche die richtige Passage findet und die Antwort diese korrekt nutzt, müssen Sie im konkreten Bestand prüfen.

Beginnen Sie mit einer Fehlerliste

Sammeln Sie echte Fragen, die das System beantworten soll, und schreiben Sie die erwartete Antwortgrundlage dazu. Dazu kommen Fragen ohne verfügbare Antwort und mindestens ein Fall mit widersprüchlichen Quellen. Verwenden Sie anonymisierte Beispiele. Es geht nicht darum, möglichst viele Gesprächsprotokolle hochzuladen, sondern um eine prüfbare Beschreibung des benötigten Verhaltens.

Ordnen Sie jeden Fehler zu. Wurde die gültige Quelle nicht gefunden? Wurde sie gefunden, aber falsch verstanden? Stimmt der Inhalt, aber das Format nicht? Oder wurde eine unerlaubte Handlung versprochen? Ein besseres Sprachmodell kann einen schlechten Suchbestand nicht zuverlässig reparieren. Ein grösserer Suchbestand kann eine unklare Freigaberegel nicht ersetzen. Diese Zuordnung schützt Sie vor einer teuren Lösung für das falsche Problem.

Wann einfache Anweisungen genügen können

Wenn Sie wenige stabile Regeln und einen kleinen klaren Kontext haben, beginnen Sie mit einer einfachen Variante. Beispielsweise soll ein Assistent Anliegen in drei definierte Kategorien einordnen und fehlende Angaben benennen. Geben Sie die Kategorien, Beispiele und Grenzen vor. Prüfen Sie erst, welche Fälle danach noch misslingen.

Diese Variante hat ebenfalls Grenzen. Wenn sich Unterlagen häufig ändern oder je Frage verschiedene Quellen benötigt werden, wird das manuelle Mitgeben unübersichtlich. Eine überlange Anweisung kann widersprüchliche Regeln verstecken. Halten Sie also nicht aus Prinzip an der einfachen Variante fest. Verwenden Sie deren Testergebnisse, um den nächsten notwendigen Schritt zu begründen.

Wann RAG die passende nächste Frage ist

RAG ist interessant, wenn Antworten von einem grösseren oder wechselnden Dokumentbestand abhängen. Der Aufwand liegt dann in Quellenpflege, Suche, Metadaten und Zugriffsrechten. Ein neues Preisblatt sollte eine alte Version nachvollziehbar ersetzen. Eine interne Personalunterlage darf nicht deshalb in einer Kundenantwort auftauchen, weil ihre Wörter gut zur Frage passen.

Prüfen Sie die Suche getrennt von der Formulierung. Zeigen Sie einem Prüfer zunächst nur die gefundenen Passagen. Reichen sie aus, um die Frage zu beantworten? Danach prüfen Sie die Antwort und deren Bezug zur Passage. Wenn die Suche schon falsch liegt, bringt eine elegantere Antwortformulierung wenig. Wenn die Quelle fehlt, braucht das System eine erkennbare Grenze und einen nächsten Schritt.

Wann Fine-Tuning geprüft werden sollte

Fine-Tuning kommt als Untersuchung infrage, wenn ein wiederkehrendes Verhaltensproblem mit guten Anweisungen und Beispielen nicht ausreichend gelöst wird. Das kann eine spezifische Klassifikation oder ein konsequentes Ausgabeformat sein. Dafür brauchen Sie brauchbare Trainingsdaten und einen getrennten Testbestand. Die Verbesserung muss sich ausserhalb der Beispiele zeigen, an denen das Modell angepasst wurde.

Aktuelle Öffnungszeiten, laufende Aufträge und neue Bedingungen sollten Sie nicht als dauerhaft gespeichertes Wissen im Modell voraussetzen. Legen Sie fest, wie diese Informationen zur Laufzeit bereitstehen. Aus einem Fine-Tuning folgt auch keine automatische Quellenangabe oder Berechtigungskontrolle. Solche Funktionen brauchen weiterhin einen definierten Ablauf und überprüfbare Schnittstellen.

So vergleichen Sie den Aufwand

Variante	Laufende Arbeit	Wichtiger Test
Anweisungen	Regeln und mitgegebene Informationen pflegen.	Unklarer Fall ausserhalb der Beispiele.
RAG	Quellen, Index, Rechte und Suche aktualisieren.	Neue Quelle und nicht erlaubte Quelle.
Fine-Tuning	Datensatz, Modellversion und Evaluation betreuen.	Unbekannter Fall im getrennten Testbestand.

Vergleichen Sie neben Modellnutzung auch Suchbetrieb, Pflege, Fehlersichtung und menschliche Nacharbeit. Ein geringerer Preis pro Antwort kann durch häufige manuelle Korrekturen aufgebraucht werden. Ein kleiner Pilot sollte deshalb Zeit für die Pflege sichtbar machen. Notieren Sie, wer eine neue Quelle freigibt und wie eine misslungene Antwort zur Verbesserung zurückfliesst.

Eine Entscheidung mit einem veränderten Dokument

Ein aufschlussreicher Test ist eine bewusst geänderte Regel. Verwenden Sie dafür ein erfundenes internes Dokument und ändern Sie beispielsweise den Annahmeschluss einer Testleistung. Stellen Sie vorher und nachher dieselbe Frage. Das System soll die aktuelle Regel verwenden und die alte nicht wieder als gültig präsentieren. Prüfen Sie ausserdem, ob die Änderung einem Verantwortlichen zugeordnet und rückgängig gemacht werden kann.

Dieses Experiment zeigt, wo die Fakten liegen und welcher Pflegeaufwand entsteht. Es ist kein Nachweis allgemeiner Genauigkeit. Ergänzen Sie andere Fragen und erlaubte Rollen, bevor Sie eine Produktionsentscheidung treffen. Halten Sie Ergebnis, Version und verbleibende Fehler fest, damit die Wahl später begründet werden kann.

Den Testbestand unabhängig halten

Legen Sie vor einer Anpassung fest, welche Fragen zur Entwicklung verwendet werden und welche erst bei der abschliessenden Prüfung erscheinen. Sonst kann ein verbessertes Ergebnis lediglich zeigen, dass das System die bereits bekannten Beispiele besser behandelt. Ergänzen Sie andere Formulierungen desselben Anliegens und Fälle, bei denen sich die fachliche Antwort unterscheiden muss.

Ein kurzer Gesprächsverlauf ist ebenfalls aufschlussreich. Nach einer beantworteten Frage korrigiert die Person eine Angabe oder wechselt das Thema. Prüfen Sie, ob alte Informationen unangemessen in die nächste Antwort einfliessen. Das betrifft den Gesprächsablauf und kann auch bei einer richtigen Dokumentensuche schiefgehen. Erfassen Sie den Fehler deshalb getrennt von fehlenden Quellen.

Vor der nächsten Investition sollte eine verantwortliche Person die verbleibenden Fehler lesen können. Zeigen Sie einige konkrete Beispiele samt erwarteter Grundlage, statt nur einen Gesamtscore vorzulegen. Dann wird nachvollziehbar, ob weitere Quellenpflege, bessere Anweisungen oder eine Untersuchung von Fine-Tuning den nächsten Versuch rechtfertigen.

Die Beiträge zu Quellen und Herkunft von Antworten behandeln die spätere Nachvollziehbarkeit. Hier geht es um die Investitionsentscheidung davor. Für Ihren Firmenchatbot bringen Sie Fragen, gültige Quellen und eine Liste beobachteter Fehler mit. Dann lässt sich prüfen, welche zusätzliche Technik wirklich gebraucht wird.