Stand:
Die Frage kommt in fast jedem Gespräch: „Wir wollen eine KI, die unser Unternehmen kennt. Müssen wir die selbst trainieren?“
Nein. Fast nie. Und die interessante Arbeit beginnt erst hinter diesem Nein.
Es gibt vier Wege, ein Sprachmodell dazu zu bringen, dass es dein Wissen benutzt. Sie unterscheiden sich um Größenordnungen in Aufwand, Kosten und Wartung. Wer den falschen wählt, merkt es meistens erst nach drei Monaten.
Der kurze Weg zur Antwort
Arbeite die Fragen der Reihe nach ab. Die erste, die du mit Ja beantwortest, ist dein Weg.
- Passt dein Wissen in ein Kontextfenster und ändert sich selten? → Nimm Kontext und Anweisungen. Kein RAG, keine Datenbank.
- Ändert sich dein Wissen laufend, oder ist es zu groß fürs Fenster? → Nimm RAG.
- Soll das Modell nicht mehr wissen, sondern anders antworten, und du hast Beispiele dafür? → Nimm Finetuning.
- Baust du ein Grundlagenmodell für einen Markt, der noch keins hat? → Dann trainierst du. Und dann arbeitest du vermutlich nicht in einem mittelständischen Unternehmen, sondern in einem Labor.
Der Rest dieses Textes erklärt, warum die Reihenfolge so ist.
1. Kontext und Anweisungen
Der Weg, den 2024 kaum jemand ernst genommen hat, weil die Fenster zu klein waren. Das hat sich gedreht. Heute schluckt ein brauchbares Modell so viel Text, dass die Handbücher, Richtlinien und Prozessbeschreibungen vieler Abteilungen hineinpassen. Dazu kommen Anweisungsdateien, in denen steht, wie gearbeitet wird.
Vorteile: Du siehst zu jedem Zeitpunkt genau, was das Modell gelesen hat. Eine Änderung ist eine Dateiänderung. Es gibt nichts zu indizieren und nichts, was still veralten kann.
Grenzen: Große Kontexte kosten Rechenzeit bei jeder einzelnen Anfrage, und zwar bevor das erste Wort erscheint. Bei meinem Frage-Bot liegt genau dort der Engpass. Der Systemprompt samt vier Beispielen umfasst rund 1300 Token. Ohne Vorwärmen erscheint das erste Wort nach 18,6 Sekunden, mit vorgewärmtem Zwischenspeicher nach 0,6 Sekunden. Derselbe Prompt, dieselbe Maschine.
Wenn du dich für diesen Weg entscheidest, plane das Vorwärmen von Anfang an ein.
2. RAG
Retrieval Augmented Generation heißt: Vor der Antwort wird gesucht, und das Gefundene wandert als Kontext in die Anfrage. Das Modell selbst lernt dabei nichts. Es bekommt nur besseres Material.
Das ist der Weg für fast alle Unternehmensfälle, und zwar aus einem Grund, der nichts mit Qualität zu tun hat: Wartbarkeit. Ändert sich eine Richtlinie, tauschst du ein Dokument. Kein neues Training, kein neuer Durchlauf, keine Wartezeit.
Zwei Bauformen, die sich in der Praxis bewährt haben:
a. Vektorsuche. Die Texte werden durch ein Einbettungsmodell in Zahlenreihen verwandelt und in einer Vektordatenbank abgelegt. Bei einer Frage wird nach Ähnlichkeit gesucht. Stark bei unstrukturiertem Material und bei Fragen, die den Wortlaut des Dokuments nicht treffen.
Was dabei gern übersehen wird: Das Einbettungsmodell ist ein zweites Modell, das mitlaufen muss. Meines wiegt 322 MB und läuft nebenher. Das ist wenig, aber es ist nicht null, und es muss dasselbe Modell bleiben. Tauschst du es aus, passen die alten Vektoren nicht mehr zu den neuen Fragen, und du indizierst alles neu.
b. Klassische Suche. Die Frage löst eine Volltextsuche aus, die Treffer gehen als Kontext weiter. Weniger Rechenaufwand, nachvollziehbarer, und bei Fachbegriffen oft besser als die Vektorsuche. Schwäche: Bei sehr großen Beständen bläht sich der Kontext auf, oder du musst hart abschneiden.
In der Praxis kombiniert man beides. Die ehrliche Antwort auf „welche Variante ist besser“ lautet: Miss es an deinen eigenen Fragen. Nimm dreißig echte Anfragen aus dem Arbeitsalltag, lass beide Varianten darauf los und sieh dir die Treffer an, bevor du dir die Antworten ansiehst. Ein schlechter Treffer wird auch vom besten Modell nicht mehr gerettet.
3. Finetuning
Hier wird das Modell selbst verändert. Nicht komplett neu gebaut, sondern in Teilen nachjustiert. Verfahren wie LoRA legen dafür eine kleine Zusatzschicht an, statt alle Gewichte anzufassen. Das drückt den Aufwand erheblich.
Der wichtigste Satz zum Thema: Finetuning bringt Verhalten bei, kein Wissen.
Wenn dein Modell in einem bestimmten Ton antworten soll, ein festes Format einhalten oder eine Fachsprache beherrschen muss, ist Finetuning richtig. Wenn es Fakten kennen soll, die sich ändern, ist es falsch. Fakten, die du in Gewichte einbrennst, kannst du nicht mehr korrigieren, ohne neu zu trainieren.
Nötig sind Beispiele, nicht Rohdaten. Gemeint sind Paare aus Anfrage und gewünschter Antwort, sauber und widerspruchsfrei. Die Sammlung dieser Beispiele ist die eigentliche Arbeit. Wer erwartet, den vorhandenen Dokumentenbestand einfach hineinzukippen, wird enttäuscht.
Gleichwohl: In Kombination mit RAG entsteht etwas Schlagkräftiges. Das Finetuning setzt die Stimme, das RAG liefert die Fakten. Jedes Teil macht das, worin es gut ist.
4. Ein eigenes Modell trainieren
Der Vollständigkeit halber, denn die Frage kommt: Ja, man kann. Nein, du willst nicht.
Es braucht einen gewaltigen, sauberen Textbestand, Rechenzeit in einer Größenordnung, die man in Rechenzentren misst, und ein Team, das das Handwerk beherrscht. Am Ende steht ein Modell, das schlechter ist als die frei verfügbaren, weil die frei verfügbaren auf mehr Daten und mehr Rechenzeit beruhen.
Es gibt gute Gründe, das trotzdem zu tun. Eine Sprache, die kein großes Modell gut beherrscht. Eine Fachdomäne mit eigener Notation. Souveränität als politisches Ziel. In einem Unternehmen, das KI einführen will, ist keiner dieser Gründe der erste Schritt.
Was das praktisch heißt
Mein eigener Frage-Bot ist nach Weg 1 gebaut, mit einer sehr schmalen Ausbaustufe von Weg 2. Er läuft auf zwölf CPU-Kernen ohne Grafikkarte. Das kleinere Modell schreibt mit 35 Token pro Sekunde, das größere mit 22. Eine Antwort von rund 450 Zeichen steht damit nach 3,4 beziehungsweise 5,8 Sekunden.
Das ist langsamer als eine Antwort von einem großen Anbieter. Es ist schnell genug für eine Frage, die jemand in einem Forum stellt und nicht in einem Chat. Die Wartezeit ist hier ein Produktmerkmal.
Die Entscheidung für einen der vier Wege ist damit auch eine Entscheidung darüber, wie deine Anwendung sich anfühlen soll. Das kommt in den meisten technischen Diskussionen zu kurz.
Wenn du dabei stecken bleibst: Im Mitgliederbereich kannst du sie mir stellen. Dann haben auch andere etwas davon.
