Embedding-Modelle selbst hosten: das Fundament jeder RAG-Suche

Die meisten RAG-Projekte scheitern nicht an der Datenbank und nicht am Sprachmodell. Sie scheitern an einem Baustein, über den kaum jemand spricht: dem Embedding-Modell. Es entscheidet, ob Ihre Suche den richtigen Absatz findet oder knapp daneben greift. Und genau dieses Modell überlassen viele Unternehmen einem externen API-Anbieter – samt jeder Zeile, die sie durchsuchen wollen.

Das muss nicht sein. Ein Embedding-Modell lässt sich mit überschaubarem Aufwand selbst betreiben. Oft läuft es sogar auf Hardware, die Sie ohnehin im Haus haben. Dieser Beitrag zeigt, warum sich der Schritt lohnt, welches Modell zu welchem Zweck passt und worauf Sie im Betrieb achten sollten.

Was ein Embedding-Modell wirklich leistet

Ein Embedding-Modell übersetzt Text in Zahlen. Aus einem Satz, einem Absatz oder einer ganzen Rechnungszeile wird ein Vektor – eine Liste aus mehreren hundert Kommazahlen. Texte mit ähnlicher Bedeutung landen in diesem Zahlenraum nahe beieinander, auch wenn sie kein einziges Wort teilen. „Kündigungsfrist“ und „Vertrag vorzeitig beenden“ rücken zusammen, obwohl die Suche nach Stichworten hier leer ausginge.

Dieser eine Schritt bestimmt die Qualität der gesamten Pipeline. Reranking, Hybrid-Suche, die Wahl der Vektordatenbank – all das arbeitet mit den Vektoren, die das Embedding-Modell liefert. Sind die Vektoren schwach, hilft kein noch so gutes Sprachmodell dahinter. Es bekommt dann schlicht die falschen Absätze vorgelegt und formuliert daraus eine überzeugend klingende, aber falsche Antwort.

Deshalb lohnt sich der genaue Blick. Ein Embedding-Modell ist kein austauschbares Zahnrad, sondern das Fundament, auf dem Ihre Suche steht.

Warum Sie das Modell ins Haus holen sollten

Der erste Grund ist der Datenschutz. Wer Embeddings über eine fremde API erzeugt, schickt seine Dokumente an einen Dritten – Verträge, Personalakten, Konstruktionsunterlagen. Für viele regulierte Branchen ist das allein schon ein K.-o.-Kriterium. Ein selbst gehostetes Modell verarbeitet alles innerhalb Ihres Netzes. Kein Byte verlässt das Haus.

Der zweite Grund sind die Kosten. Embeddings fallen nicht nur einmal an. Jedes neue Dokument muss eingebettet werden, jede Suchanfrage ebenfalls, und bei jeder Modell-Umstellung indexieren Sie den gesamten Bestand neu. Bei Millionen von Textabschnitten summiert sich das. Ein eigenes Modell auf vorhandener Hardware macht diese Dauerkosten kalkulierbar.

Der dritte Grund ist Kontrolle. Sie bestimmen, wann ein Modell wechselt. Kein Anbieter schaltet Ihnen über Nacht eine Version ab, die Sie zur Neuindexierung zwingt. Und Sie können das Modell auf Ihre Fachsprache anpassen – ein Hebel, den eine geschlossene API gar nicht erst bietet.

Welches Modell zu Ihrem Anwendungsfall passt

Die gute Nachricht: Sie müssen nichts selbst trainieren. Mehrere frei verfügbare Modellfamilien liefern heute eine Qualität, die vor zwei Jahren noch den großen Anbietern vorbehalten war. Entscheidend ist die Auswahl nach Ihrem konkreten Bedarf, nicht nach dem Spitzenplatz in irgendeinem Ranking.

Für deutschsprachige oder gemischte Bestände brauchen Sie ein mehrsprachiges Modell. BGE-M3 und multilingual-e5-large decken über hundert Sprachen ab und liefern bei deutschen Fachtexten solide Treffer. Jina Embeddings v3 und Nomic Embed sind weitere ernstzunehmende Kandidaten, Nomic punktet mit offenem Trainingsdatensatz. Für rein englische Inhalte reicht oft ein kleineres Modell wie gte-base oder mxbai-embed-large.

Achten Sie auf drei Kennzahlen:

• Vektorgröße (Dimensionen): Mehr Dimensionen bedeuten mehr Speicher und langsamere Suche. 768 oder 1024 sind für die meisten Fälle ein guter Mittelweg. Manche Modelle lassen sich gekürzt betreiben, ohne viel Qualität zu verlieren.
• Maximale Eingabelänge: Passt ein typischer Absatz hinein? Modelle mit 512 Token kappen längere Abschnitte stillschweigend – ein häufiger, unsichtbarer Fehler.
• Sprachabdeckung: Ein reines Englisch-Modell liefert bei deutschen Verträgen schwache Vektoren, auch wenn es im Benchmark glänzt.

Hardware und Betrieb: weniger, als Sie denken

Ein Embedding-Modell ist um ein Vielfaches kleiner als ein Sprachmodell. Die gängigen Vertreter umfassen einige hundert Millionen Parameter und passen bequem auf eine einzelne Grafikkarte der Mittelklasse. Für kleinere Bestände genügt oft sogar die CPU, besonders wenn Sie das Modell per ONNX oder in quantisierter Form ausliefern.

Für den produktiven Betrieb setzen Sie nicht auf ein selbstgeschriebenes Skript. Fertige Server wie Text Embeddings Inference von Hugging Face oder die Einbindung über Ihren vorhandenen Inferenz-Server bündeln Anfragen, lasten die GPU gleichmäßig aus und liefern eine saubere Schnittstelle. So verarbeiten Sie tausende Abschnitte pro Sekunde, statt jeden einzeln durch die Pipeline zu schieben.

Trennen Sie zwei Lastprofile sauber: Die Erstindexierung eines großen Archivs ist ein Stapellauf, den Sie nachts laufen lassen. Die Suchanfrage zur Laufzeit braucht niedrige Latenz, betrifft aber nur einen kurzen Text. Wer beides mit derselben Konfiguration fährt, verschenkt entweder Durchsatz oder Antwortzeit.

Auf die eigene Fachsprache anpassen

Hier liegt der eigentliche Vorteil des Selbsthostings. Ein allgemeines Modell kennt Alltagssprache gut, aber Ihre internen Kürzel, Produktnamen und Normbezeichnungen behandelt es wie Fremdwörter. Ein Maschinenbauer mit tausenden Bauteilnummern oder eine Kanzlei mit eigenem Formularwesen spürt das sofort an mittelmäßigen Treffern.

Mit einigen tausend Beispielpaaren – Frage und passender Textabschnitt – lässt sich ein offenes Modell nachschärfen. Dieses Feintuning dauert auf einer einzelnen GPU oft nur Stunden und hebt die Trefferquote in der eigenen Domäne deutlich. Die Beispielpaare gewinnen Sie aus Support-Tickets, aus dem Suchverhalten Ihrer Mitarbeiter oder aus bereits beantworteten Anfragen. Bei einer fremden API ist dieser Weg schlicht versperrt.

Die häufigsten Stolpersteine

Der teuerste Fehler ist ein später Modellwechsel. Vektoren verschiedener Modelle sind nicht kompatibel. Stellen Sie um, müssen Sie den kompletten Bestand neu einbetten – bei großen Archiven ein Projekt von Tagen. Wählen Sie das Modell also früh mit Bedacht, statt es später unter Druck zu tauschen.

Zweiter Stolperstein: die Abschnittslänge. Betten Sie ganze Seiten in einen Vektor ein, verwischt die Bedeutung und die Suche wird unscharf. Schneiden Sie zu klein, fehlt der Kontext. Zielen Sie auf sinnvoll abgegrenzte Abschnitte, die zur Eingabegrenze Ihres Modells passen.

Dritter Punkt: Prüfen Sie, ob Ihre Datenbank dieselbe Normalisierung erwartet wie Ihr Modell liefert. Viele Modelle geben normierte Vektoren aus, manche nicht. Passt das nicht zusammen, rechnet die Ähnlichkeitssuche falsch – und niemand merkt es, weil Ergebnisse ja trotzdem erscheinen. Testen Sie deshalb von Anfang an mit echten Fragen aus dem Arbeitsalltag, nicht mit konstruierten Beispielen.

Fazit: klein im Aufwand, groß in der Wirkung

Das Embedding-Modell ist der am meisten unterschätzte Hebel jeder KI-gestützten Suche. Es selbst zu hosten, kostet weniger Hardware und Mühe als ein Sprachmodell, schützt Ihre Daten vollständig und öffnet die Tür zur Anpassung an Ihre Fachsprache. Wer hier sorgfältig wählt, legt ein Fundament, auf dem jede weitere RAG-Komponente verlässlich aufbaut.

Sie möchten eine RAG-Suche auf Ihren eigenen Dokumenten aufbauen – datenschutzkonform und auf Ihre Branche zugeschnitten? Die Experten von AI-Designers begleiten Sie von der Modellauswahl bis zum produktiven Betrieb. Sprechen Sie uns an.

Bilder: AI-Designed