"Kann ich mein LLM anschließen?"
Diese Frage kommt öfter. Manchmal von jemandem, der ein bestimmtes Modell bevorzugt. Manchmal von einem IT-Leiter, der Flexibilität will. Manchmal von jemandem, der ein günstigeres Open-Source-Modell nutzen möchte.
Die Antwort ist immer die gleiche: Nein. Nicht, weil wir nicht wollen. Sondern weil es technisch unverantwortlich wäre.
RAG ist kein API-Wrapper
Das größte Missverständnis über RAG-Systeme: Man könne einfach ein beliebiges LLM anschließen, wie man eine Glühbirne wechselt.
Das stimmt nicht.
RAG ist ein System. Mehrere Komponenten arbeiten zusammen. Das Embedding-Modell wandelt Dokumente in Vektoren um. Die Vektordatenbank speichert sie. Die Retrieval-Logik findet die relevanten Passagen. Und das Sprachmodell generiert die Antwort.
Jede Komponente ist auf die anderen abgestimmt. Wenn Sie das Sprachmodell austauschen, bricht diese Abstimmung zusammen.
Ein Beispiel
Wir haben einen Prompt entwickelt, der dem LLM erklärt, wie es mit den gefundenen Dokumentpassagen umgehen soll.
"Nutze nur die bereitgestellten Dokumente. Wenn Passagen sich widersprechen, erwähne das. Gib immer die Quelle an: Dokument, Seite, Abschnitt."
Klingt simpel. Das Problem: Jedes Modell interpretiert diese Anweisung anders.
Jedes Modell hat seine Eigenheiten
Manche Modelle gewichten den Anfang des Kontexts stärker. Wenn Sie denen zehn Dokumentpassagen geben, achten sie hauptsächlich auf die ersten drei. Andere Modelle fokussieren sich auf das Ende.
Unsere Retrieval-Logik muss das wissen. Sie sortiert die Passagen entsprechend. Wichtigste zuerst für Modell A. Wichtigste am Ende für Modell B.
Wenn Sie das Modell wechseln, ohne die Logik anzupassen, sinkt die Qualität.
Oder nehmen Sie Quellenangaben. Wir wollen, dass das LLM sagt: "Laut Betriebshandbuch Seite 47 gilt folgende Regelung..."
Nicht alle Modelle können das zuverlässig. Manche erfinden Seitenzahlen. Sie wissen, dass eine Seitenzahl erwartet wird, also liefern sie eine. Irgendeine. Die passt dann nicht.
Oder Halluzinationen. Wir wollen, dass das System sagt: "Dazu habe ich keine Informationen in den Dokumenten gefunden."
Einfach, oder? Manche Modelle tun das. Andere erfinden trotzdem eine Antwort. Selbst wenn wir ausdrücklich sagen: "Erfinde nichts."
Was wir getestet haben
Vor einigen Monaten haben wir ein Experiment gemacht. Ein neues Open-Source-Modell kam raus. Gute Bewertungen, schnell, günstig.
Wir haben es ohne große Anpassungen eingebunden. Nur um zu sehen, was passiert.
Das Ergebnis: 40 Prozent der Quellenangaben waren falsch. Das Modell zitierte Dokumente, die gar nicht im Kontext waren. Bei komplexen Fragen ignorierte es Teile des Kontexts. Die Antwortqualität schwankte stark.
Das Modell selbst war gut. Für allgemeine Aufgaben funktionierte es hervorragend. Aber für unser RAG-System? Unbrauchbar ohne umfangreiche Optimierung.
Der Aufwand dahinter
Jedes neue Modell, das wir unterstützen wollen, erfordert:
Prompt-Anpassung. Wir müssen herausfinden, wie das Modell Anweisungen versteht. Wo seine Stärken liegen. Wo seine Schwächen.
Tests mit echten Fragen. Nicht synthetische Beispiele aus Lehrbüchern, sondern richtige Unternehmensfragen. "Wie ist der Prozess für Urlaubsanträge?" "Welche Sicherheitsrichtlinien gelten für externe Dienstleister?"
Validierung der Quellenangaben. Für hunderte Testfragen prüfen: Stimmt die Quelle? Stimmt die Seitenzahl? Ist der Kontext korrekt?
Halluzinationsverhalten prüfen. Was passiert, wenn die Antwort nicht in den Dokumenten steht? Erfindet das Modell? Gibt es zu, dass es nicht weiß?
Performance-Optimierung. Wie schnell antwortet das Modell? Wie viel Kontext verträgt es? Ab wann wird es langsam?
Das dauert Wochen. Manchmal Monate.
Die Illusion der Flexibilität
Man könnte sagen: "Gib den Nutzern einfach die Option. Wer möchte, kann ein anderes Modell einbinden. Auf eigenes Risiko."
Klingt nach Flexibilität. Ist aber unverantwortlich.
Denn der Nutzer merkt nicht sofort, wenn etwas schief geht. Eine erfundene Quellenangabe sieht aus wie eine echte. Ein ignorierter Kontext fällt nicht auf, wenn die Antwort trotzdem plausibel klingt.
Der Nutzer verlässt sich auf das System. Trifft Entscheidungen basierend auf den Antworten. Und wenn die Antworten falsch sind, merkt er es vielleicht erst Monate später.
Das Risiko ist zu groß.
Was wir stattdessen tun
Wir evaluieren neue Modelle kontinuierlich. Wenn ein vielversprechendes Modell erscheint, schauen wir es uns an.
Wir testen es. Passen unsere Prompts an. Prüfen die Qualität. Und wenn es unsere Standards erfüllt, fügen wir es hinzu.
Das dauert länger, als einfach eine API freizuschalten. Aber es liefert zuverlässige Ergebnisse.
Derzeit unterstützen wir zwei Llama-Modelle. Beide haben wir ausführlich getestet. Beide funktionieren nachweislich in unserem System.
Weitere Modelle werden folgen. Aber nur, wenn wir sicher sind, dass sie funktionieren.
Warum das wichtig ist
Wir wollen für die Qualität der Antworten verantwortlich sein.
Ein RAG-System, das "irgendwie funktioniert", ist gefährlich. Erfundene Quellenangaben untergraben das Vertrauen. Ignorierter Kontext führt zu falschen Entscheidungen. Inkonsistente Antworten frustrieren Nutzer.
Wenn jemand KnowledgePilot nutzt und eine Antwort bekommt, soll er sich darauf verlassen können. Nicht: "Funktioniert meistens." Sondern: "Funktioniert."
Das geht nur, wenn wir die Kontrolle über die Modellauswahl behalten.
Die Rechnung ist einfach
Beliebige LLM-Unterstützung bedeutet: Keine Qualitätsgarantie.
Eingeschränkte, aber getestete Modellauswahl bedeutet: Zuverlässigkeit.
Wir haben uns für Zuverlässigkeit entschieden. Das macht uns weniger flexibel. Aber deutlich verlässlicher.
Und Verlässlichkeit ist bei Unternehmenswissen keine Option. Sie ist Voraussetzung.