Wann RAG reicht – und wann ein LoRA sinnvoll ist

Das Wichtigste in Kürze

• RAG sucht passende Inhalte in freigegebenen Quellen und gibt sie dem Modell für die aktuelle Aufgabe mit.
• LoRA ist ein kleines Nachtraining, das wiederkehrendes Verhalten des Modells verändert.
• Aktuelle Preise, Bestände, Verträge oder Richtlinien gehören in Quellen, nicht in Modellgewichte.
• Vor einem Training stehen ein guter Prompt, feste Ausgaben und unabhängige Prüfungen.
• Ein LoRA lohnt sich nur, wenn ein stabiler Fehler mit guten Trainingsdaten und einem unangetasteten Test belegt ist.

Der Wunsch taucht in fast jedem Erstgespräch auf: das Modell einmal mit allen Ordnern vom Fileserver trainieren, damit es die Firma kennt. Der Wunsch ist verständlich und führt in die falsche Richtung. Ein Modell, dem die Preisliste antrainiert wurde, beantwortet Preisfragen auch nach der nächsten Preisanpassung — flüssig, überzeugend und falsch.

Wenn ein Modell eine Aufgabe nicht gut genug löst, fallen schnell drei Begriffe: besserer Prompt, RAG oder Fine-Tuning. Sie beheben unterschiedliche Probleme. Die erste Frage lautet deshalb: Fehlt dem System Wissen für diesen Vorgang oder fehlt dem Modell ein wiederkehrendes Verhalten?

RAG beantwortet: Was muss das Modell jetzt wissen? LoRA beantwortet: Wie soll es diese Art von Aufgabe künftig lösen?

RAG bringt Wissen in den aktuellen Vorgang

RAG steht für Retrieval-Augmented Generation: Die Anwendung sucht vor der Modellantwort passende Inhalte in freigegebenen Quellen und gibt diese Auszüge zusammen mit dem Auftrag an das Modell. Der Ablauf ist unspektakulär — eine Frage kommt mit Vorgang und Berechtigung, die Suche findet die passenden aktuellen Stellen, das Modell antwortet auf deren Basis, und unter der Antwort stehen Quelle und Version zum Nachprüfen.

Das eignet sich für Handbücher, Verträge, Richtlinien, technische Dokumente und andere Inhalte, die sich ändern oder mit einer Quelle belegt werden müssen. Eine Aktualisierung erfolgt im Dokumentenbestand. Das Modell muss nicht neu trainiert werden. Wenn die Einkaufsrichtlinie sich ändert, wird ein Dokument getauscht — kein Modell.

LoRA verändert wiederkehrendes Verhalten

LoRA steht für Low-Rank Adaptation. Dabei bleibt das Grundmodell weitgehend unverändert; ein kleiner zusätzlicher Satz von Gewichten wird mit eigenen Eingabe-Ausgabe-Paaren trainiert. Technisch ist das eine sparsame Form des Fine-Tunings, also des Nachtrainierens.

Ein LoRA kann helfen, wenn ein Modell dieselbe Fachsprache, Einordnung oder Ausgabeform immer wieder falsch behandelt. Es liefert aber keine verlässliche aktuelle Datenbank.

Für einen Prototypen im Gesundheitswesen haben wir ein LoRA trainiert. Das Ziel war ein enges, wiederkehrendes Verhalten auf fachlich geprüften Eingaben — nicht mehr. Der Nutzen musste sich in der Abnahme gegen das unveränderte Modell und gegen Lösungen mit Prompt und bereitgestellten Quellen behaupten. Diese Messlatte klingt streng. Sie hat uns schon mehr als ein Training erspart.

Der zentrale Unterschied

Der Weg zur Entscheidung

Die Entscheidung ist eine Kette von Fragen, und die meisten Projekte steigen früh aus. Zuerst: Fehlen aktuelle oder betriebsinterne Fakten? Dann beginnt die Lösung mit RAG oder einer direkten Abfrage des zuständigen Systems. Preise, Bestände, Richtlinien und Verträge gehören in führende Quellen, wo sie sich aktualisieren, belegen und löschen lassen.

Die zweite Frage: Löst ein klarer Prompt die Aufgabe bereits? Vor jedem Training testen wir einen präzisen Auftrag, wenige gute Muster, feste Ausgabefelder und normale Prüfsoftware. Viele Formatprobleme, die nach Trainingsbedarf aussehen, verschwinden an dieser Stelle. In einem Projekt bestand der vermutete Trainingsbedarf am Ende aus zwei zusätzlichen Beispielzeilen im Prompt — das Training hätte Wochen gedauert, die zwei Zeilen einen Nachmittag.

Ein LoRA wird erst interessant, wenn derselbe Fehler über viele Fälle bestehen bleibt: wenn ein repräsentativer Testsatz ein stabiles Muster zeigt, etwa bei Fachbegriffen, Einordnung, Ausgabeform oder einer engen fachlichen Interpretation. Dann braucht es genügend gute Trainingsdaten — konsistente Eingaben mit fachlich bestätigten Ausgaben. Einzelne, widersprüchliche Korrekturen aus dem Alltag reichen nicht; ein Modell, das aus drei sich widersprechenden Korrekturen lernen soll, lernt vor allem den Widerspruch.

Bleibt der Kandidat im Rennen, muss der Zusatznutzen messbar sein. Grundmodell, Prompt mit Quellen und LoRA laufen auf demselben unangetasteten Abnahmesatz, und das Training muss einen wichtigen Fehler oder Prüfaufwand deutlich senken. Zuletzt der Betrieb: Jeder Adapter ist an ein Grundmodell und eine technische Umgebung gebunden und braucht Dokumentation, Sicherheitstests, Rückschritttests und einen späteren Updateweg. Ein LoRA ist kein Abschluss, sondern ein weiteres Bauteil mit eigenem Lebenslauf.

Erste Wahl, zweite Wahl, keine Wahl

RAG ist meist die erste Wahl für interne Handbücher und Prozessbeschreibungen, Verträge, Berichte und technische Unterlagen — überall dort, wo Wissen eine Quellen- und Versionspflicht hat, sich häufig ändert, unterschiedlichen Zugriffsrechten unterliegt oder wo Fundstellen geprüft werden müssen.

Ein LoRA ist prüfenswert bei stabilen und häufigen Einordnungs- oder Extraktionsmustern, bei Fachsprache, die das Grundmodell systematisch verfehlt, bei einer festen Ausgabeform, die trotz guter Vorgaben instabil bleibt, oder bei einer engen fachlichen Interpretation mit geprüften Trainingsdaten — und nur dann, wenn die Fallmenge groß genug ist, damit die gesparte Prüfzeit den Trainingsaufwand trägt.

Und manchmal gehen beide Techniken am Problem vorbei: wenn die führenden Daten falsch oder nicht erreichbar sind, der Prozess keine klare fachliche Regel besitzt, eine Berechnung schlicht in normale Software gehört, die Verbindung zum Zielsystem fehlt, die Freigabeoberfläche schlecht ist oder das Grundmodell Bilder, Sprache oder die Länge der Eingabe grundsätzlich nicht beherrscht. Kein Training repariert eine Schnittstelle, die es nicht gibt.

RAG getrennt prüfen

Bei RAG gibt es zwei Fehlerstellen: die Suche — wurden die richtigen, erlaubten und aktuellen Stellen gefunden? — und die Antwort — nutzt das Modell diese Stellen richtig und bleibt es bei den Quellen? Tests enthalten deshalb auch alte Fassungen, widersprüchliche Dokumente, fehlende Treffer und getrennte Rechte.

Eine gute Antwort kann eine schlechte Suche verdecken. In einem Test beantwortete das Modell eine Frage zu einer verbreiteten Industrienorm korrekt, obwohl die Suche nichts gefunden hatte — es kannte die Norm aus dem Training. Bei der Frage nach der hauseigenen Rabattregelung wäre dieselbe Lücke weniger glimpflich ausgegangen. Deshalb werden Suche und Antwort getrennt bewertet, nicht nur das Endergebnis.

LoRA getrennt prüfen

Training, Auswahl und Abnahme nutzen getrennte Daten. Zusätzlich wird geprüft, ob der Adapter andere benötigte Fähigkeiten verschlechtert hat: Sprache, Format, Sicherheit oder allgemeine Stabilität. Ein Adapter, der die Fachsprache trifft und dafür das Ausgabeformat vergisst, ist kein Fortschritt.

Grundmodell, Adapter, Trainingsdaten und wichtige Einstellungen werden gemeinsam versioniert.

Prüffragen für die Entscheidung

• Fehlt Wissen oder fehlt Verhalten?
• Muss die Information aktuell, löschbar und belegbar sein?
• Wurden Prompt, feste Ausgabe und Prüfregeln zuerst getestet?
• Gibt es einen unangetasteten Abnahmesatz?
• Sind die Trainingsdaten konsistent und rechtmäßig nutzbar?
• Senkt das LoRA einen wichtigen Fehler oder Aufwand deutlich?
• Ist der spätere Betrieb von Modell, Adapter und Suche geklärt?

Fazit der Serie

RAG und LoRA sind keine Reifegrade derselben Lösung. Sie erfüllen verschiedene Aufgaben: RAG bringt kontrolliertes Wissen in einen Vorgang, LoRA verändert ein wiederkehrendes Verhalten. Agenten, Regeln, Quellen und Tests machen daraus einen betrieblichen Prozess.

Der Grundsatz der ganzen Serie bleibt derselbe: Die kleinste Technik, die den nachgewiesenen Engpass löst, ist meist die beste. Manchmal sind das zwei Zeilen im Prompt.

Quellen und weiterführende Hinweise

1. Forschungsarbeit: Retrieval-Augmented Generation
2. Forschungsarbeit: LoRA – Low-Rank Adaptation
3. Hugging Face: LoRA als effizientes Nachtraining
4. NIST: AI Risk Management Framework

Wissen und Verhalten brauchen verschiedene Werkzeuge

Eine saubere Diagnose verhindert unnötiges Training und hält Unternehmenswissen aktuell und prüfbar.

Architektur besprechen