Fine-Tuning oder RAG: was das Wissen Ihres Unternehmens wirklich ins Modell bringt

Was jede Technik tatsächlich ändert

Die eine Technik ändert die Parameter des Modells. Die andere ändert das, was Sie ihnen zur Abfragezeit vorlegen. Zwei Berater können eine Stunde lang streiten, ohne das zu klären.

Retrieval-augmented Generation, im Mai 2020 von Lewis und Kollegen definiert, verbindet das parametrische Gedächtnis des Modells mit einem durchsuchbaren nicht-parametrischen. Nützlich ist vor allem ihre eigene Einordnung: Die Herkunft der Entscheidungen eines Modells zu belegen und sein Weltwissen zu aktualisieren waren, in ihren Worten, offene Forschungsfragen. Anthropics Glossar beschreibt den Mechanismus operativ: Dokumente werden zur Laufzeit abgerufen und ins Kontextfenster gelegt. Kein einziges Gewicht bewegt sich.

Fine-Tuning ist das Gegenteil. NVIDIAs Leitfaden zur Anpassung zieht die Linie klar: Fine-Tuning aktualisiert die vortrainierten Gewichte, während promptbasierte Techniken sie eingefroren lassen. Anthropics Glossar sagt, was das einbringt: ein Modell, das die Muster des Tuning-Datensatzes abbildet und nachahmt. Muster, nicht Fakten.

LoRA, von Hu und Kollegen im Juni 2021, friert das Basismodell ein und schiebt trainierbare Matrizen niedrigen Rangs in jede Transformer-Schicht. Die Schlagzeile: Gegenüber einem mit Adam feinabgestimmten GPT-3 175B senkte es die trainierbaren Parameter um das 10.000-Fache und den GPU-Speicher um das Dreifache, den Trainingsspeicher von 1,2 TB auf 350 GB und den Checkpoint auf 35 MB. Zwei Bedingungen fallen dabei meist unter den Tisch: Diese Parameterreduktion wurde bei Rang 4 und allein an den Query- und Value-Projektionen gemessen, während die PEFT-Dokumentation von Hugging Face heute empfiehlt, alle linearen Schichten anzupassen, und die Vergleichsbasis ist die der Autoren selbst. Berichtet werden außerdem 25 Prozent kürzere Trainingszeit und keine zusätzliche Inferenzlatenz.

QLoRA, von Dettmers und Kollegen im Mai 2023, setzt LoRA auf ein auf vier Bit quantisiertes Basismodell: ein 65B-Modell, abgestimmt auf einer einzigen GPU mit 48 GB, bei erhaltener Aufgabenleistung in 16 Bit, während ein Tuning desselben Modells in 16 Bit mehr als 780 GB brauchte. Die Mechanismen: ein Vier-Bit-Typ namens NormalFloat, ein zweiter Quantisierungsdurchgang, der die Quantisierungskonstanten von 0,5 Bit je Parameter auf 0,127 senkt, und ausgelagerte Optimierer. Die Angabe von 99,3 Prozent der ChatGPT-Leistung gilt allein für den Vicuna-Benchmark.

Die Entscheidungstabelle, und welche Zeilen gesichert sind

Ordnen Sie die Probleme zu, nicht die Techniken; die letzte Spalte ist die, die Sie lesen sollten.

Die Zeile zur Zugriffskontrolle ist Schlussfolgerung, keine belegte Aussage: Keine Primärquelle empfiehlt Metadatenfilter als Autorisierungsmechanismus, aber der Abruf lässt sich je Nutzer filtern, Gewichte nicht.

Sie werden auch hören, die Modellanbieter sagten, Fine-Tuning sei das falsche Werkzeug für Fakten. Das tun sie nicht. OpenAIs Seiten zu Optimierung, Fine-Tuning und Best Practices enthalten keine solche Aussage; Anthropics Glossar definiert beides und vergleicht es nie; NVIDIA veröffentlicht keine Regel dafür, parametereffizientes Tuning dem vollen Tuning vorzuziehen. Die Regel ist durch die Forschung weiter unten gut gestützt; eine Herstellerposition ist sie nicht. Die eine veröffentlichte Schwelle stammt von Anthropic: unter 200.000 Token Korpus, also etwa 500 Seiten, legen Sie alles in den Prompt und bauen kein RAG. Unser Leitfaden zu RAG auf Unternehmensdaten deckt den Rest ab.

Was Fine-Tuning an GPU-Speicher kostet

Den Trainingsspeicher beherrschen die Modellzustände, und der Multiplikator ist umstritten: Der Streit verschiebt jede Zahl um ein Drittel.

Die ZeRO-Arbeit von Rajbhandari und Kollegen schlüsselt Adam in gemischter Präzision auf: zwei Byte je Parameter für fp16-Gewichte, zwei für fp16-Gradienten, dazu eine fp32-Hauptkopie sowie Momentum und Varianz mit je vier Byte, zusammen sechzehn. Die Seite zur Speicheranatomie von Hugging Face führt dieselben Bestandteile auf und kommt auf 18, weil sie fp32-Gradienten statt fp16 annimmt. Die QLoRA-Arbeit legt 12 nahe: Ihre 780 GB für ein 65B-Modell sind genau 65 Milliarden mal 12 Byte, ohne jene Hauptkopie. Arbeitsbereich: 16 bis 18 Byte je Parameter.

Unsere Rechnung aus den Multiplikatoren oben, keine Angaben von Herstellern oder aus Arbeiten. GB = 10⁹ Byte; nur Modellzustände, die Aktivierungen kommen obendrauf. LoRA nimmt eine eingefrorene bf16-Basis und einen Adapter an NVIDIAs Obergrenze von unter 1 Prozent an; QLoRA 0,516 Byte je Parameter.

Also: Kein volles Fine-Tuning eines 8B-, 32B- oder 70B-Modells passt auf eine Karte mit 96 GB, noch vor jeder Aktivierung, und die Aktivierungen tragen einen Term, der quadratisch mit der Sequenzlänge wächst. LoRA auf 70B passt ebenfalls nicht. QLoRA auf 70B passt. Der Glaube, ein 7B-Modell lasse sich auf einer Karte vollständig abstimmen, verwechselt Inferenz- mit Trainingsspeicher: Dieses Modell braucht 14 GB, um es in FP16 auszuliefern, und rund 112 GB für volles Tuning, ein Verhältnis von acht zu eins. Ein Acht-Bit-Optimierer könnte die Lücke schließen; keine Primärquelle nennt seine Byte je Parameter, also drucken wir keine.

Die Ersparnis von QLoRA hat ihren Preis, und NVIDIA veröffentlicht beide Hälften auf einer Seite. Dass QLoRA „bis zu“ 60 Prozent speichereffizienter sei als LoRA, ist eine Herstelleraussage über das eigene Produkt, und die Ersparnis schrumpft mit wachsender Batch-Größe. Direkt darunter, und keine Werbung: Das Training mit QLoRA ist 50 bis 200 Prozent langsamer als mit LoRA.

Das Dokument, das fast niemand zitiert: NVIDIAs Planungsmatrix, auf L40-Karten mit 48 GB.

NVIDIAs Konfigurationsmatrix für NeMo Microservices; der Gesamt-VRAM ist unsere eigene Multiplikation.

NVIDIA plant für einen 8B-LoRA-Job zwei L40-Karten ein, 96 GB, während die Gewichtsrechnung rund 17 GB ergibt; die Differenz sind Aktivierungen, Framework-Overhead und Voreinstellungen des Dienstes, und danach richtet sich die Beschaffung. Und NVIDIA führt für kein einziges 70B-Modell eine Konfiguration mit allen Gewichten. Beim Ausliefern läuft es andersherum: vLLM betreibt viele LoRA-Adapter auf einer einzigen Kopie der Basisgewichte, und bei 35 MB kostet ein Mandant dann fast nichts.

Was der Betrieb von RAG kostet und niemand einplant

RAG gilt als die günstige Variante, weil es keinen Trainingslauf braucht. Dort liegt sein Aufwand aber nicht.

Das Embedding-Modell ist ein eigener GPU-Dienst: NVIDIAs NIM-Matrix für Retrieval verlangt für das eigene 1B-Embedding-Modell im nicht optimierten FP16-Profil mindestens 3,6 GiB GPU-Speicher, und die Spanne auf dieser Seite ist sechzehnfach, von 2 GiB bis 33 GiB für bge-m3. Darum herum stehen vier weitere Dienste: NVIDIAs Unternehmensarchitektur für RAG nennt die Microservices für Sprachmodell, Embedding und Reranking, dazu die Dokumentenextraktion und Milvus, als Grundausstattung vier GPUs, 40 vCPU und 200 GiB. Nur eine dieser GPUs bedient das Sprachmodell.

Die Voreinstellungen für das Chunking sind nicht einmal in sich stimmig: Die Bibliothekskonstante von LlamaIndex sind 1.024 Token mit 20 Token Überlappung, während der eigene Satz-Splitter 200 verwendet, und der Basis-Splitter von LangChain steht auf 4.000 Zeichen mit 200, während das eigene Tutorial 1.000 und 200 nimmt. Ein wiederkehrender Fehler gehört richtiggestellt: NVIDIAs RAG-Einführung schreibt, die Embedding-Modelle von OpenAI kodierten bis zu 1.536 Token und schnitten darüber hinaus stillschweigend ab. Das Abschneiden gibt es; die Zahl stimmt nicht. OpenAI dokumentiert 8.192 Token Eingabe, und 1.536 ist die Dimension des Ausgabevektors seines kleinen Modells.

Reranking lohnt sich. Anthropic hat auf eigenen Korpora eine Fehlerrate von 5,7 Prozent in den ersten 20 Treffern gemessen, die mit kontextuellen Embeddings auf 3,7 fällt, mit zusätzlichem kontextuellem BM25 auf 2,9 und auf 1,9, wenn die besten 150 Ergebnisse auf 20 umsortiert werden: Die relativen Verbesserungen von 35, 49 und 67 Prozent werden meist ohne diese Basis von 5,7 Prozent zitiert. Milvus veröffentlicht keine Byte-Zahl je Vektor, der Speicher gehört also gemessen.

Nun die Zahl, die die Servingkosten entscheidet. NVIDIAs Formel für den KV-Cache lautet: zwei, mal Zahl der Schichten, mal versteckte Dimension, mal Byte je Element, und das je Token. Für Llama 2 7B in 16 Bit sind das 2 × 32 Schichten × 4.096 × 2 Byte, also 512 KiB je Token. Abgerufene Passagen sind Token wie alle anderen, 4.000 Token Kontext je Anfrage kosten also rund 2 GiB KV-Cache je gleichzeitiger Anfrage und rund 62 GiB bei 32 gleichzeitigen Anfragen: zwei Drittel einer Karte mit 96 GB, ausgegeben für abgerufenen Text, bevor ein einziges Token erzeugt ist. Diese Multiplikation ist unsere, und sie nimmt Multi-Head-Attention an wie bei Llama 2 7B. Aktuelle Modelle dieser Größe nutzen Grouped-Query-Attention mit weit weniger Key-Value-Köpfen und entsprechend geringeren Kosten je Token; rechnen Sie die Formel also mit Ihrer eigenen Konfiguration. Die Zahl der Key-Value-Köpfe aktueller Llama-3.1-Checkpoints konnten wir nicht bestätigen, wir drucken sie daher nicht. Unser Beitrag dazu, wie viele Nutzer eine RTX PRO 6000 bedient, rechnet das von Anfang bis Ende durch.

Was die veröffentlichten Vergleiche wirklich gefunden haben

Ovadia und Kollegen haben auf der EMNLP 2024 Mistral 7B, Llama2 7B und Orca2 7B auf MMLU-Teilmengen und an einer Aufgabe zu aktuellen Ereignissen geprüft, also an Wissen, das die Modelle nicht gesehen haben konnten. Mit Mistral 7B erreichte bei aktuellen Ereignissen das Basismodell 0,481, das Basismodell mit Retrieval 0,875, das feinabgestimmte Modell 0,504 und das feinabgestimmte Modell mit Paraphrasen 0,588. Ihr Fazit: „LLMs tun sich schwer damit, neue faktische Informationen durch unbeaufsichtigtes Fine-Tuning zu lernen“.

Das tragende Wort ist „unbeaufsichtigt“. Der Fine-Tuning-Arm dieser Studie war fortgesetztes Vortraining auf Rohtext, kein überwachtes Tuning auf Frage-Antwort-Paaren, und genau Letzteres machen die meisten Unternehmen; die Arbeit sagt das in ihrer Zusammenfassung. Sie auf überwachtes Tuning zu verallgemeinern ist der häufigste Lesefehler in diesem Feld. Belegt ist etwas Engeres: Einen Dokumentenkorpus in einen Lauf mit fortgesetztem Vortraining zu kippen bringt diese Fakten nicht zuverlässig in die Gewichte.

Das Gegenergebnis ist die Fallstudie zur Landwirtschaft von Balaguer und Kollegen vom Januar 2024, die überwachtes Tuning einsetzte und beide Verfahren als additiv fand: über 6 Prozentpunkte durch Fine-Tuning und weitere 5 durch Retrieval obendrauf, wobei Retrieval bei kontextuell passenden Daten wirkt und Tuning beim Vermitteln von Fachkönnen. Die beiden lassen sich nicht in Einklang bringen, und wir tun nicht so, als ginge es doch. Ovadias Tabellen zeigen das Basismodell mit Retrieval vor dem feinabgestimmten Modell mit Retrieval, 0,681 gegen 0,659 bei Anatomie ohne Beispiele; Balaguers Tabellen zeigen, dass sich beides addiert. Andere Aufgaben, andere Domänen, andere Tuning-Verfahren.

Zwei weitere Ergebnisse. Soudani und Kollegen haben auf der SIGIR-AP 2024 zwölf Modelle von 80M bis 11B Parametern getestet und Retrieval bei Fakten geringer Popularität mit deutlichem Abstand vorn gefunden; ein kleines feinabgestimmtes Modell mit Retrieval zog mit einem viel größeren gleich, 1,6B gegen 8B: die Logik hinter dem Betrieb eines eigenen Modells statt einer Cloud-API. Und Biderman und Kollegen haben im August 2024 in TMLR LoRA mit vollem Fine-Tuning bei Programmierung und Mathematik verglichen: Bei den üblichen niedrigen Rängen bleibt LoRA deutlich dahinter, und als Mechanismus wird vorgeschlagen, dass volles Tuning Gewichtsänderungen vom 10- bis 100-Fachen des Rangs lernt. Die LoRA-Arbeit selbst beansprucht Gleichstand oder mehr. Beide sind begutachtet und widersprechen sich direkt; erhöhen Sie also den Rang, bevor Sie ein Urteil fällen.

Was kaputtgeht, und was jedes danach verlangt

Der charakteristische Fehler des Fine-Tunings ist katastrophales Vergessen, und der Befund, der ein Projekt stoppen sollte, betrifft die Größe. Luo und Kollegen haben es an Fachwissen, Schlussfolgern und Leseverstehen in Modellen von 1B bis 7B gemessen und fanden es allgemein und mit wachsender Modellgröße stärker. Ein größeres Basismodell ist also keine Abhilfe; Instruction Tuning vor dem Fachtuning half sehr wohl. LoRA ist die Teilantwort, und der Tausch ist ausdrücklich: Dieselbe TMLR-Arbeit, die LoRA in der Zieldomäne schwächer fand, sah es Fähigkeiten außerhalb dieser Domäne besser bewahren als Weight Decay oder Dropout.

Die Fehler von RAG sind benannt und gezählt. Barnett und Kollegen zählen in einem Erfahrungsbericht auf der CAIN 2024 aus drei Fallstudien sieben auf: fehlender Inhalt im Korpus, das richtige Dokument zu niedrig einsortiert, das richtige Dokument bei der Zusammenführung verloren, die Antwort im Kontext, aber nicht extrahiert, eine Ausgabe, die das verlangte Format ignoriert, die falsche Genauigkeitsstufe und eine richtige, aber unvollständige Antwort. Beachten Sie den fünften: Ein falsches Format ist ein Fine-Tuning-Problem innerhalb einer RAG-Fehlertaxonomie. Ihr Urteil lautet, dass sich ein RAG-System nur im Betrieb validieren lässt, und der monatliche Aufwand steckt in ihrer Liste der Stellschrauben: Chunk-Größe, Embedding, Chunking, Abruf- und Zusammenführungsstrategie, Kontextgröße und Prompts.

Ein längeres Kontextfenster rettet keinen schwachen Retriever. Liu und Kollegen fanden in TACL die Leistung am höchsten, wenn die einschlägige Passage am Anfang oder am Ende des Kontexts steht, und in der Mitte abfallend, selbst bei Modellen mit langem Kontext: fünfzig Chunks hineinzustopfen, statt den Ranker zu reparieren, kann die Sache verschlimmern. Auf beiden Seiten ist die Evaluierung nicht optional. OpenAI sagt, bauen Sie die Evaluierungen vor dem Tuning; für den Abruf bewertet Ragas auf der EACL 2024 Relevanz, Treue zur Quelle und Generierungsqualität ohne Referenzantworten.

Der hybride Fall, die Reihenfolge und wie viele Daten nötig sind

NVIDIAs veröffentlichte Position ist eine Reihenfolge und keine Wahl: mit RAG beginnen und dann anpassen, wenn mehr fachspezifische Genauigkeit nötig ist. Die eigene RAG-Einführung sagt ausdrücklich, dass es nicht um die eine oder die andere Technik geht, und nennt die Kombination, die die meisten übersehen: parametereffizientes Tuning innerhalb eines RAG-Systems, das das Sprachmodell oder das Embedding-Modell verfeinert. Den Retriever statt des Generators abzustimmen ist die zu selten besprochene Variante.

Die Reihenfolge, die die Quellen stützen: zuerst die Evaluierungen; dann Prompt- und Kontext-Engineering; den Korpus messen und unter rund 200.000 Token ganz auf Retrieval verzichten; darüber Retrieval aufbauen; erst dann zu LoRA greifen, um Format, Ton, Aufgabentreue und Fachkönnen zu richten; das Embedding-Modell zuletzt abstimmen. OpenAI ergänzt eine Anweisung: Nehmen Sie den Prompt, der vor dem Tuning am besten funktioniert hat, in jedes Trainingsbeispiel mit.

Bei den Daten sind die Zahlen kleiner, als man erwartet. OpenAI nennt ein hartes Minimum von 10 Beispielen, berichtet Verbesserungen ab 50 bis 100 und empfiehlt, mit 50 sorgfältig gebauten Demonstrationen zu beginnen; die Qualitätslatte lautet, dass eine kleinere Menge guter Daten eine größere Menge schlechter Daten schlägt und dass die Beispiele in sich geschlossen, konsistent und in dem Format sein müssen, das zur Inferenzzeit erwartet wird. LIMA hat ein 65B-Modell auf 1.000 kuratierten Prompts feinabgestimmt und wurde in 43 Prozent der Vergleiche gegenüber GPT-4 bevorzugt oder als gleichwertig bewertet; sein Fazit klärt die Frage: Nahezu das gesamte Wissen wird im Vortraining gelernt, und für gute Ausgaben braucht es nur begrenzte Instruktionsdaten. Die QLoRA-Autoren stimmen zu, dass Qualität die Datenmenge schlägt.

Für Fakten kehrt sich die Anforderung um. Ovadia und Kollegen fanden die Genauigkeit monoton mit der Zahl der verwendeten Paraphrasen steigen: jeder Fakt vielfach umformuliert, und Sie verlieren trotzdem gegen Retrieval. Die Größenordnungen stehen in der TMLR-Arbeit: rund 100.000 Prompt-Antwort-Paare, um eine Tätigkeit zu vermitteln, und 20 Milliarden unstrukturierte Token, um ein Fachgebiet zu vermitteln. Zwei Lücken füllen wir nicht mit einer plausiblen Zahl. NVIDIA veröffentlicht in seiner NeMo-Dokumentation keine Mindestzahl an Beispielen, und Anthropic verlangt nur hochwertige Prompt-Completion-Paare, ohne eine Menge zu nennen; die Genauigkeitszahlen in der eigenen Ankündigung sind Kundenmarketing, auf einer Klassifikationsaufgabe.

Eurokommerz liefert die Hardware, auf der diese Entscheidung landet, EU-weit, und bemisst sie lieber an Ihrem Korpus und Ihrer Gleichzeitigkeit als an einem Techniknamen. Unsere Seite zu privater KI und ML zeigt die Plattformen, auf denen wir bauen.

FAQ