Training vs. Kontext: Warum Unternehmenswissen nicht in der Cloud sicher ist
In den Trainingsdaten von Large Language Models steckt erstaunlich viel Wissen. In den aktuellsten Topmodellen unfassbar viel und richtig genau. Aber genau dieses gefühlt allmächtige Wissen führt dazu, dass viele Anwendungen sich zu sehr auf das trainierte Wissen verlassen und den Kontext vernachlässigen.
Das Paradoxon der modernen KI
Die großen KI-Unternehmen entwickeln und trainieren große Modelle, die auf ein umfangreiches Weltwissen zugreifen. Damit braucht es für viele Antworten gar keine Web-Recherche, weil das Modell das Wissen implizit kennt und sofort souverän antworten kann. Im B2B-Umfeld gibt es aber zwei große Probleme:
- Die Cloud-Modelle eignen sich aus Datenschutzsicht und aus Souveränitätssicht nicht als Basis. Einerseits darf man viele Unternehmensdaten nicht in die Cloud schicken (DSGVO), andererseits sollte man sich auf bestimmte Modelle nicht verlassen (Stichwort Fable5 „Verbot", sprich, es war tagelang schlicht nicht verfügbar).
- Wenn das Modell etwas nicht weiß, halluziniert es gerne, um trotzdem eine Antwort zu liefern. Die Grenzen des eigenen Wissens sind diffus, und wenn der Prompt nicht explizit Grenzen setzt, passiert das häufiger.
Dazu kommt: Wenn man über die Zeit eine Anwendung nutzt und auf ein bestehendes Modell aufsetzt, wächst das Wissen nicht weiter. Das Modell wird nicht ständig auf die neuesten Daten trainiert. Das Wissen ist sozusagen eingefroren. Außerdem gibt es zu keinem Modell eine belastbare Information darüber, auf Basis welcher Daten es trainiert wurde. Das ist schlicht nicht nachvollziehbar. Man muss sich darauf verlassen, dass das Trainierte auch stimmt und dass es dem entspricht, was das eigene Unternehmen genauso sieht.
Der wesentlichste Punkt ist allerdings: Das Modell kann vieles gar nicht wissen. Viel Wissen und Know-how steckt im Unternehmen selbst. Das wurde nie publiziert und war schon gar nicht Teil des Trainings. Hier gibt es also nicht einmal eine Chance, dass das LLM es wissen kann.
Die Lösung: Kontext-Engineering als Kernkompetenz
Oft gilt der Irrglaube: Der perfekte Prompt löst alle Probleme. Die Erfahrung zeigt, dass man mit einem perfekten Prompt ein unzureichendes Modell nicht zu korrekten Ergebnissen bringt. Was ein Modell nicht kann, kann es nicht. Beispielsweise ein Tool-Call: Es gibt einfach Modelle, die das nicht können. Da hilft auch kein Prompt. Genauso mit dem Kontext: Die Kunst ist es, ausreichend Kontext mitzuschicken, aber gleichzeitig den Kontext so zu formulieren, dass er die eigentliche Aufgabenstellung im Prompt nicht überlagert. Die Herausforderungen bei Kontext sind jedenfalls:
- Datenqualität
- Strukturerkennung
- Aktualität
- Etwaiges Rauschen
Wie kommt man zu gutem Kontext? Meistens ist die Antwort: deterministisch, sprich, man baut sich ganz klassisch mit Algorithmen Prozesse, die aus vorhandenen Datenquellen einen Kontext bereitstellen, der in den Prompts verwendet wird. Entweder mit Tool-Calls oder direkt eingebaut, je nach Anforderung.
Ein Beispiel aus der Praxis: Angenommen, das Modell soll einen Systembefehl für einen internen Server bauen. Die reine Unix-Syntax hat auch ein 35B-Modell aus dem Training parat, das ist allgemeines Können. Was es nicht wissen kann, ist der Name des Servers und dessen IP-Adresse. Die stehen nirgends im Internet, sondern nur im Unternehmen. Genau diese Fakten werden deterministisch in den Kontext injiziert oder per Tool-Call geholt. Erst aus beidem zusammen, dem allgemeinen Können und den spezifischen Fakten, entsteht der fertige, korrekte Befehl. Der Kontext ersetzt hier nicht das Wissen des Modells, er ergänzt es um genau das, was das Modell gar nicht wissen kann.
Und hier zeigt sich ein zweiter, oft unterschätzter Punkt: Ein starkes Modell erkennt, wenn ihm eine Information fehlt, und fragt nach, um welchen Server es überhaupt geht. Ein schwaches Modell rät und baut den Befehl womöglich auf dem falschen System. Guter Kontext ist also die halbe Miete. Die andere Hälfte ist ein Modell, das mit Lücken im Kontext umgehen kann, statt sie zu überspielen.
Man sieht das auch schön bei smartllm: Die Input-Tokens seit Start liegen deutlich über den Output-Tokens. Der Grund: Bei den gebauten Anwendungen wird sehr viel Kontext mitgeschickt, damit das Ergebnis für die eigene Anwendung maßgeschneidert ist. Generelles Wissen kann das schlicht nicht abdecken.
Wichtig ist dabei: Kontext ist immer entscheidend, in der Cloud genauso wie lokal. Das ist kein Argument für das eine oder das andere. Aufgaben wie Zusammenfassen oder das Finden von Widersprüchen arbeiten mit dem, was man rein schickt, nicht mit dem, was das Modell irgendwann gelernt hat. Je mehr die Antwort im Kontext steckt, desto weniger ist das Weltwissen der Flaschenhals. Aber Vorsicht vor dem Kurzschluss, dass damit automatisch ein kleines Modell reicht: Kontext ersetzt, was ein Modell wissen muss, nicht, wie gut es denken muss. Einen kurzen Befehl aus sauberem Kontext bauen, das schafft auch ein kleineres Modell. Ein langes Dokument durchdringen, Widersprüche über viele Seiten hinweg erkennen und daraus einen Plan ableiten, das braucht Denkleistung. Und die hängt an der Modellgröße, egal wie gut der Kontext ist.
Eigene Modelle trainieren auf das Unternehmenswissen?
Sehr oft kommt dann der Vorschlag, man müsse bestehende LLMs mit entsprechender Lizenz einfach weiter trainieren, und zwar auf das konkrete Unternehmenswissen. Der Grundgedanke ist sicherlich nicht verkehrt, aber der Aufwand ist absurd im Vergleich dazu, wie einfach es ist, Modelle unverändert zu betreiben und sauber den Kontext mitzuschicken. Vor allem: Möchte man nach einigen Wochen lokal auf eine bessere Version migrieren, müsste man wieder ein neues Modell trainieren. Das ist akademisch vielleicht herausfordernd, aber praktisch völlig unbrauchbar. Gleiches gilt für den Versuch, sehr kleine Modelle auf nicht leistungsfähigen Rechnern zu betreiben. Auch das ist etwas, das wir nicht empfehlen können. Es gibt Anwendungsfälle für die kleinen Modelle, aber im Großen und Ganzen ist es für den Beginn einfach viel zu viel Testaufwand. Ein vernünftiges Modell beginnt bei etwa 30b (Milliarden Parameter) in nicht zu kleiner Quantisierung (mindestens 4 Bit). Der Grund ist schlicht die Hardware: Ein 30b-Modell läuft auf einer Maschine mit 64 GB RAM, also einer überschaubaren einmaligen Anschaffung. Für ein 397b-Modell braucht man dagegen zwei über QSFP gekoppelte NVIDIA DGX Spark und liegt schnell bei über 10.000 Euro Anschaffungskosten. Das ist für viele Unternehmen am Anfang völlig aus dem Rahmen. Nach unten wird es dagegen nicht günstiger im Sinne von besser, sondern nur wilder: Ein 35b kann schon viel, längst nicht alles, aber man kann damit tatsächlich arbeiten. Mit einem 8b oder 9b geht das nicht mehr, das taugt nur dazu, mal eben eine einfache Entscheidung zu treffen. Alles darunter mag für eng umrissene Spezialfälle reichen, aber zum Einstieg ist der Testaufwand einfach zu groß.
Warum „Open Weights" und lokales Hosting wesentliche Bausteine für Souveränität sind
Nachdem bei Unternehmen fast zwangsläufig nicht nur völlig belanglose Daten im Kontext stehen, ist es für bestimmte Aufgaben oft unerlässlich, dass keine LLMs in der Cloud verwendet werden. Auch wenn die Cloud bessere Modelle und einen größeren KV-Cache bietet, ist lokales Hosting oft die bessere und sicherere Alternative. Kein Risiko, was mit den Daten passiert, und auch kein Risiko, dass mal ein Modell abgeschaltet wird, auf das man aber auf die eine oder andere Art angewiesen ist.
Ganz zu schweigen von den Kosten. Cloud kostet bei jedem Zugriff und bei jeder Aufgabenstellung. Zugegeben, entsprechende Infrastruktur ist nicht billig, aber wenn man halbwegs eine lauffähige Anwendung baut, dann werden in weiterer Folge viele Requests verarbeitet, und die Kosten laufen mit. Oft ist es auch eine Philosophiefrage, ob man als Unternehmen KI-Rechner selbst betreiben möchte. Vor allem darf man nicht unterschätzen, wie viele Tokens man verbraucht, wenn man eine Anwendung mit LLMs betreibt. Am Ende sind da schnell ein paar hundert oder tausend Euro Cloud-Rechnung beisammen. Und das nur fürs Testen. Vielleicht läuft die Anwendung dann auch gar nicht.
Die Zukunft der KI ist „hybrid"
Wir haben jetzt das Für und Wider lokal gehosteter LLMs abgewogen. Für die Zukunft ist im Businessbereich vermutlich eine Hybrid-Lösung die sinnvollste. Überall da, wo es um sensible Daten geht, führt an der lokal gehosteten KI kein Weg vorbei. Überall dort, wo es um Leistung und nicht um Daten geht, kann die Cloud die pure Power ausspielen. Das setzt aber voraus, dass man die eigene Anwendung auch so bauen kann, dass für unterschiedliche Anforderungen verschiedene LLMs angesprochen werden können und auch der Output entsprechend verarbeitet werden kann.
Folglich der Tipp: Mit beidem beschäftigen und das Beste beider Welten mitnehmen. Die Ebenen sind vielfältig: Kosten, Datensouveränität, Datenschutz, usw.