RAG
Retrieval Augmented Generation (RAG) ist ein KI-Verfahren, das ein Large Language Model mit einem externen Retrieval-System kombiniert. Statt ausschließlich auf das während des Trainings erworbene Wissen zu setzen, ruft RAG zum Zeitpunkt der Anfrage relevante Kontextinformationen aus eigenen Datenquellen ab und speist sie in den Prompt ein. So werden die Antworten in aktuellen, unternehmensspezifischen Informationen verankert.
Retrieval Augmented Generation ist eine Technik, mit der sich Large Language Models im konkreten Unternehmenskontext nutzen lassen. Ein eigenständiges LLM überzeugt beim allgemeinen Schlussfolgern, doch es kennt weder Ihren Debitorenstamm noch Ihre Rahmenverträge, Ihre Historie an Streitfällen oder den Stand Ihres Debitoren-Kontokorrents von heute Morgen. Schlimmer noch: Fragt man es nach Details, die es nicht wirklich kennt, erfindet es gern plausibel klingende Antworten. Das nennt sich Halluzination, und in Finanzteams ist das inakzeptabel.
RAG löst das, indem es verändert, wie das Modell an seine Informationen gelangt. Statt sich allein auf das zu verlassen, was im Training einprogrammiert wurde, ruft das System zum Zeitpunkt der Abfrage die relevantesten Teile Ihrer eigenen Daten ab und speist sie gemeinsam mit der Nutzerfrage in den Prompt ein. Das LLM erzeugt dann eine Antwort, die in diesem abgerufenen Kontext verankert ist. So löst RAG drei Probleme auf einmal: Der Trainingsstichtag spielt keine Rolle mehr, weil die Daten frisch abgerufen werden, fehlendes Unternehmenswissen wird bei Bedarf ergänzt, und Halluzinationen gehen deutlich zurück, weil das Modell die tatsächliche Antwort vor sich hat.
Ein produktives RAG-System besteht aus fünf Komponenten, die zusammenspielen. Erstens der Dokumentenkorpus: jeder Vertrag, jede Rechnung, jede Kundennotiz, jedes Richtliniendokument und jeder Wissensdatenbank-Artikel, auf den das System zugreifen darf. Zweitens ein Embedding-Modell, das jeden Textabschnitt in einen numerischen Vektor umwandelt und so dessen Bedeutung abbildet. Drittens eine Vektordatenbank, die diese Embeddings speichert und eine schnelle Ähnlichkeitssuche über Millionen von Abschnitten hinweg erlaubt.
Dann kommt die Laufzeit ins Spiel. Stellt ein Nutzer eine Frage, wandelt der Retrieval-Schritt die Anfrage in einen Vektor um, durchsucht die Vektordatenbank und ruft die Abschnitte ab, die der Frage semantisch am ähnlichsten sind. Im Generierungsschritt übergibt das System schließlich die abgerufenen Abschnitte zusammen mit der ursprünglichen Anfrage an das LLM, das daraus eine fundierte Antwort formuliert. Der Nutzer sieht eine Antwort in natürlicher Sprache, doch im Hintergrund liest das Modell direkt aus Ihren Dokumenten.
RAG ist das zentrale Arbeitsmuster für KI-native Debitorensysteme, denn fast jede sinnvolle Frage im Forderungsmanagement setzt unternehmensspezifischen Kontext voraus. Fragen Sie einen Finanz-Copiloten Welche Zahlungsbedingungen haben wir mit Kunde X vereinbart?, dann ruft er per RAG den Rahmenvertrag ab, und das LLM zieht die passende Klausel heraus und stellt sie dar. Ein Agent zur Vorsortierung von Streitfällen liest einen eingehenden Streitfall, ruft die zugehörige Rechnung, die relevanten Vertragsklauseln und die bisherige Streitfallhistorie ab und formuliert daraus einen Antwortentwurf mit dem gesamten Kontext, den ein Mitarbeiter sonst mühsam von Hand zusammentragen müsste.
Bei Kreditentscheidungen läuft es genauso. Beantragt ein Kunde eine höhere Kreditlinie, ruft RAG die Zahlungshistorie, das aktuelle Obligo und die relevante Kreditrichtlinie ab, und das LLM erstellt eine begründete Empfehlung, die ein Kreditanalyst prüfen und freigeben kann. Für eingehende Kunden-E-Mails entstehen Antwortentwürfe, die bereits die Kontohistorie enthalten. Interne Fragen wie Wie lautet unsere Richtlinie zu Abschreibungen unter 5.000 Euro? beantwortet das System anhand des tatsächlichen Richtliniendokuments, statt sich auf das Erfahrungswissen einzelner Mitarbeiter zu verlassen.
Beide Techniken bringen einem LLM etwas Neues bei, funktionieren aber grundverschieden. Fine-Tuning verankert neues Wissen über zusätzliches Training fest in den Modellgewichten. Das ist teuer und langsam, und einmal eingebautes Wissen lässt sich nur schwer wieder entfernen oder aktualisieren. RAG hält das Wissen dagegen extern, in Ihrem Dokumentenspeicher, und ruft es erst bei der Anfrage ab. Aktualisierungen wirken sofort: Ändern Sie das Richtliniendokument, berücksichtigt schon die nächste Anfrage die neue Vorgabe.
Im Finanzbereich großer Unternehmen setzt sich RAG fast immer durch. Sie prüfen leichter, weil Sie genau nachweisen, aus welchem Dokument eine Antwort stammt. Sie steuern leichter, weil die Zugriffsrechte an den Dokumenten hängen und nicht tief in den Modellgewichten vergraben sind. Und es kostet weniger, weil Sie nicht bei jeder Vertragsänderung neu trainieren. Fine-Tuning behält seine Berechtigung für eng umrissene Spezialaufgaben, etwa wenn Sie einem Modell ein domänenspezifisches Ausgabeformat oder ein Nischen-Extraktionsmuster beibringen wollen. Doch für Wissen, das sich verändert, ist RAG der Standard.
RAG produktiv ans Laufen zu bringen ist schwieriger, als es das Architekturdiagramm vermuten lässt. Die Dokumentenqualität spielt eine enorme Rolle: Ein sauberes, gut strukturiertes Vertragsarchiv liefert hervorragende Suchergebnisse. Ein Ordner voller gescannter PDFs aus dem Jahr 2008 gibt dagegen nur Rauschen zurück. Der nächste Hebel ist die Chunking-Strategie. Zu kleine Chunks verlieren den Kontext, zu große verwässern die Relevanz und verschwenden Tokens. Auch die Wahl des Embedding-Modells zählt, denn verschiedene Modelle schneiden je nach Inhaltstyp unterschiedlich gut ab.
Ausgereifte Systeme ergänzen ein Re-Ranking, einen zweiten Bewertungsschritt, der die tatsächlich relevantesten Chunks aus der ursprünglichen Treffermenge nach oben holt. Sie setzen eine Zugriffssteuerung durch, sodass ein Kreditanalyst, der das System abfragt, niemals HR-Dokumente zu sehen bekommt. Und sie verlangen Quellenangaben: Jede generierte Antwort verweist auf die zugrunde liegenden Chunks, sodass Sie die Aussage prüfen können, bevor Sie danach handeln. Die typischen Fallstricke sind absehbar: irrelevante Treffer, die dem LLM Unsinn zuführen; ignorierte Dokumentenzeitstempel, die veraltete Daten liefern; und blindes Vertrauen in Ergebnisse, die sich mangels Quellenverweis nicht überprüfen lassen.
In einer KI-nativen Plattform für das Forderungsmanagement ist RAG kein Sonderfeature, sondern grundlegende Infrastruktur. Jeder agentenbasierte Workflow, der Unternehmenswissen braucht, greift auf dieselbe RAG-Schicht zu, ob er einen Streitfall klärt, den Abgleichkontext für die Cash Application (Zahlungsabgleich) liefert, die Bonität bewertet oder als Finanz-Copilot dient. Die Plattform liest Dokumente laufend ein, hält die Embeddings stets aktuell und reicht die Zugriffsrechte aus den zugrunde liegenden Systemen durch. So entsteht eine Finanzumgebung, in der jede KI-Aktion auf dem tatsächlichen aktuellen Zustand des Unternehmens fußt und sich lückenlos bis zur Quelle zurückverfolgen lässt. Genau das unterscheidet eine KI-Demo von einer KI, die Sie im Live-Betrieb hinter einem funktionierenden Forderungsmanagement einsetzen können.
Ein allgemeines LLM wie ChatGPT kennt nur das, was es beim Training gelernt hat. Auf Ihre Verträge, Ihren Kundenstamm oder Ihr Debitorenkonto hat es keinen Zugriff. RAG ergänzt ein LLM um eine Retrieval-Schicht, die zum Abfragezeitpunkt relevante Ausschnitte Ihrer eigenen Daten in den Prompt einspielt. So stützen sich die Antworten auf Ihre betriebliche Realität statt auf die generischen Trainingsdaten des Modells.
RAG verringert sie deutlich, beseitigt sie aber nicht ganz. Das Modell kann den abgerufenen Kontext nach wie vor falsch deuten oder Lücken mit plausibel klingendem Text füllen. Deshalb brauchen produktive RAG-Systeme Quellenverweise auf die Ursprungsdokumente, damit eine Fachkraft im Finanzbereich jede Aussage prüfen kann, bevor sie danach handelt.
Für Wissen, das sich ändert, etwa Verträge, Richtlinien, Kundenhistorie und Buchungsdaten, ist RAG fast immer die richtige Wahl. Sie aktualisieren es schneller, prüfen es leichter, pflegen es günstiger und wahren dabei die Zugriffsrechte. Fine-Tuning bleibt eng abgegrenzten Spezialaufgaben vorbehalten, etwa wenn das Modell ein bestimmtes Ausgabeformat oder ein spezielles Extraktionsmuster erlernen soll.
Mindestens strukturierten Zugriff auf Verträge und Rahmenverträge (MSAs), Rechnungs- und Zahlungshistorie, Streitfallakten, Kreditrichtlinien sowie sämtliche Inhalte einer internen Wissensdatenbank. Qualität zählt dabei mehr als Menge: Saubere, gut strukturierte Dokumente rufen Sie weitaus besser ab als ein wildwucherndes Verzeichnis eingescannter PDFs ohne Metadaten.
Ausgereifte RAG-Systeme setzen die Zugriffskontrolle bereits auf der Retrieval-Schicht durch. Sie filtern die infrage kommenden Dokumente nach Rolle und Berechtigungen des Nutzers, noch bevor diese beim LLM ankommen. Ein Kreditanalyst, der das System abfragt, bekommt nie HR-Dokumente ausgeliefert, selbst wenn das Modell sie technisch lesen könnte, denn der Retrieval-Schritt schließt sie von vornherein aus.
Nein. RAG ist das Standardmuster, um in jeden agentenbasierten Finanzprozess Wissen einzuspeisen, sei es bei der automatisierten Vorsortierung von Streitfällen, bei Kreditentscheidungen, beim Nachschlagen von Kontextinformationen für den Zahlungsabgleich oder beim Erstellen von Kundenkorrespondenz. Überall dort, wo ein KI-Agent aktuellen, unternehmensspezifischen Kontext für eine Entscheidung braucht, bildet RAG die Infrastruktur darunter.
