Custom Knowledge Base
Zurück zum Blog
Künstliche IntelligenzTechnologie

Custom Knowledge Base: Wie Unternehmen ihre KI mit dem eigenen Fachwissen trainieren

Generisches ChatGPT kennt Ihr Unternehmen nicht. Erst wenn Ihre Dokumente, Prozesse und Daten zur Wissensbasis werden, liefert KI belastbare Antworten. Der Weg dorthin heißt RAG.

Fred HoffmannFred Hoffmann
20. Februar 20268 Min. Lesezeit

Die meisten Unternehmen, die ChatGPT, Claude oder Gemini im Alltag einsetzen, stoßen nach wenigen Wochen an dieselbe Wand: Das Modell kennt die Weltpresse, aber nicht Ihr Produktprogramm. Es formuliert eloquent, hat jedoch keinen Zugriff auf Ihre Angebotsvorlagen, Ihre Preislisten, Ihre technischen Datenblätter oder die Entscheidungen des letzten Quartals. Der spürbare Produktivitätssprung entsteht erst, wenn das Modell mit Ihrem Wissen antwortet, nicht mit seinem Trainingsdatensatz.

Das Problem im Detail

Ein generisches Sprachmodell ist ein hochbegabter Generalist ohne Akte. Fragen Sie ein Standard-ChatGPT nach der Reklamationsfrist aus Ihren AGB, den Einsatzgrenzen Ihrer Maschinenreihe oder der Begründung, warum Kunde X in der letzten Verhandlung Position Y bekommen hat, bekommen Sie eine plausibel klingende, aber freie Antwort. Das reicht für Fließtext, nicht für Vertrieb, Support oder Engineering.

Die naheliegende Lösung, einfach alle Firmendokumente in einen großen Prompt zu kippen, scheitert an den Kontextfenstern. Selbst Modelle mit ein bis zwei Millionen Tokens Kontext lassen sich nicht mit einer vollständigen Unternehmensdokumentation füllen, ohne dass Latenz, Kosten und Qualität der Antworten kippen. Je mehr Text im Fenster steht, desto eher übersieht das Modell das Relevante. Zudem müssten Sie bei jeder Anfrage dieselben Dokumente erneut mitschicken.

Der Mechanismus: Retrieval-Augmented Generation

Der etablierte Weg heißt Retrieval-Augmented Generation, kurz RAG. Das Prinzip ist elegant: Das Sprachmodell bleibt generisch, bekommt aber bei jeder Anfrage genau die Textpassagen aus Ihrem Firmenwissen mitgeliefert, die zur Frage passen. Nicht mehr, nicht weniger. Die Antwort entsteht dann auf Basis dieses frisch zugespielten Kontexts.

Technisch läuft das in vier Schritten. Erstens: Ihre Dokumente werden in sinnvolle Abschnitte zerteilt, sogenannte Chunks. Zweitens: Jeder Chunk wird durch ein Embedding-Modell in einen hochdimensionalen Zahlenvektor übersetzt, der seine Bedeutung codiert. Drittens: Diese Vektoren werden in einer Vektor-Datenbank gespeichert. Viertens: Stellt ein Nutzer eine Frage, wird auch diese Frage in einen Vektor übersetzt, die Datenbank liefert die semantisch nächstliegenden Passagen, und genau die fließen in den Prompt des Sprachmodells ein.

Entscheidend ist, dass das Modell selbst nicht umtrainiert wird. Es bleibt das gleiche GPT-, Claude- oder Llama-Modell wie vorher. Es bekommt nur, anders als bei klassischer Nutzung, vor jeder Antwort den richtigen Auszug aus Ihrer Wissensbasis vorgelegt, so wie ein Anwalt, dem man vor der Verhandlung die einschlägigen Aktenseiten hinlegt.

Embedding-Modelle: die semantische Übersetzung

Ein Embedding ist ein Zahlenvektor, in dem semantisch ähnliche Texte nah beieinander liegen. OpenAI bietet mit text-embedding-3-large ein Modell mit bis zu 3072 Dimensionen, das sich auch auf kleinere Dimensionszahlen reduzieren lässt, ohne die Qualität stark zu verlieren. Die günstigere Variante text-embedding-3-small liegt bei 1536 Dimensionen und ist für viele B2B-Wissensbasen vollkommen ausreichend.

Wer die Datenhoheit in Europa halten muss, schaut auf Cohere Embed, das über europäische Regionen betrieben werden kann, oder auf Open-Source-Modelle wie bge-m3 oder die e5-Familie. Diese lassen sich selbst hosten, laufen auf eigener Hardware oder auf einem europäischen GPU-Anbieter und verlassen Ihren Geltungsbereich nie. Die Qualität der Top-Open-Source-Modelle liegt in relevanten Benchmarks inzwischen eng bei den kommerziellen Varianten.

Vektor-Datenbanken: wo das Wissen lebt

Die Vektor-Datenbank ist das Herzstück jeder Custom Knowledge Base. Sie muss Millionen von Embeddings speichern, Metadaten mitverwalten und bei jeder Anfrage in Millisekunden die ähnlichsten Vektoren finden. Für die Auswahl sind drei Fragen entscheidend: Wo liegen die Daten, wie tief ist der Wartungsaufwand, und wie lässt sich das System in bestehende Infrastruktur integrieren.

Pinecone ist ein vollständig gemanagter Managed Service, schnell einsetzbar, in der Standardkonfiguration aber US-lastig. Weaviate lässt sich als Managed Cloud in Europa betreiben oder komplett selbst hosten und unterstützt von Haus aus hybride Suche aus Vektor- und Keyword-Treffern. Qdrant ist ein performanter Open-Source-Kandidat, der sich schlank im eigenen Kubernetes-Cluster betreiben lässt. Und pgvector ist die pragmatische Lösung für alle, die bereits PostgreSQL einsetzen: eine offizielle Extension, die Vektor-Spalten, Cosinus-Distanz sowie HNSW- und IVFFlat-Indizes direkt in die Datenbank bringt, die ohnehin Ihre Geschäftsdaten hält.

Für die meisten unserer Mandanten ist pgvector die richtige Antwort. Keine neue Datenbank, kein zusätzlicher Betrieb, keine weiteren Vendor-Verträge, Backups laufen mit der bestehenden PostgreSQL-Infrastruktur. Wenn das Volumen in den zweistelligen Millionen Chunks wachsen soll oder spezielle Filter- und Re-Ranking-Szenarien gefragt sind, wechseln wir zu Weaviate oder Qdrant.

Chunking: der unterschätzte Hebel

Die Qualität einer RAG-Pipeline hängt maßgeblich davon ab, wie die Dokumente in Abschnitte zerteilt werden. Zu große Chunks verwässern die Semantik, zu kleine reissen Zusammenhänge auseinander. In der Praxis arbeiten wir je nach Material mit 500 bis 1000 Tokens pro Chunk und 10 bis 20 Prozent Überlappung zwischen benachbarten Chunks, damit Sätze nicht mitten im Argument abbrechen.

Wichtiger als die reine Tokenzahl ist die Struktur. Verträge werden nicht einfach nach 800 Tokens geschnitten, sondern nach Paragraphen und Klauseln. Technische Datenblätter zerteilen wir nach Produkten und Kennwertblöcken, Produktkataloge nach Artikelnummern. Je präziser die Grenzen an die Semantik der Qülle angelehnt sind, desto treffender sind später die Retrieval-Ergebnisse. Metadaten wie Dokumenttyp, Version, Gültigkeitsdatum und Zugriffsrechte wandern als Filterfelder mit in die Vektor-Datenbank.

DSGVO und Datenhoheit

Für deutsche Unternehmen ist das Hosting-Setup keine Nebenfrage, sondern entscheidet über die Einführbarkeit. Artikel 44 ff. DSGVO regeln Drittlandtransfers, und spätestens wenn Kundendaten, Personalakten oder Projektkalkulationen im Spiel sind, wird die Region, in der Embeddings und Rohdaten liegen, prüfungsrelevant. Das EU-U.S. Data Privacy Framework hat die Lage seit 2023 entspannt, aber nicht trivialisiert.

Wir setzen Knowledge Bases in drei Varianten auf. Vollständig EU-gehostet mit europäischen Embedding-Modellen und Self-Hosted-Vektor-DB für alles, was unter Berufsgeheimnis, Betriebsrat oder Exportkontrolle fällt. Hybrid, wenn die Rohdaten in Europa bleiben und nur anonymisierte Prompts an ein US-LLM gehen. Und voll gemanagt bei unkritischen Inhalten wie öffentlich zugänglichen Produktunterlagen. In jedem Fall liegen Auftragsverarbeitungsverträge, technisch-organisatorische Maßnahmen und ein nachvollziehbares Löschkonzept vor, bevor die erste Datei indiziert wird.

Unser Vorgehen bei SK Online Marketing

Wir implementieren Custom Knowledge Bases als RAG-Pipeline, die sich in Ihre bestehende Systemlandschaft einfügt, statt sie zu ersetzen. Der erste Schritt ist immer die Qüllen-Inventur: Welche Dokumente, Datenbanken und Tickets enthalten das Wissen, das heute im Kopf einzelner Mitarbeiter steckt? Aus dieser Liste wird ein Prioritätskanon, denn nicht jedes Dokument gehört in die erste Ausbaustufe.

Parallel wählen wir den Stack nach Datenhoheit und Volumen. Embedding-Modell, Vektor-Datenbank, Orchestrierungs-Framework wie LangChain oder LlamaIndex und das Sprachmodell selbst werden als eine Einheit entworfen, nicht als Zufallssammlung. Ein Ingest-Pipeline-Job verwandelt Ihre Dokumente in Chunks und Embeddings, ein Retrieval-Layer beantwortet Anfragen, ein Re-Ranker sortiert die Treffer nach, bevor sie an das Sprachmodell gehen.

Den größten Unterschied macht die Betriebsebene. Eine Wissensbasis ist kein Projekt, sondern ein Produkt. Wir richten Auto-Ingest für Ihre Qüllsysteme ein, damit neue Vertragsversionen und aktualisierte Datenblätter automatisch in die Basis fließen. Wir liefern Evaluations-Sets, mit denen Sie messen, ob Antworten über die Zeit präziser oder schwächer werden. Und wir schulen Ihr Team, wie man Chunks, Filter und Prompts pflegt, ohne selbst ein Machine-Learning-Team zu werden. Mehr dazu auf unserer KI-Beratung.

Messbare Hebel

  • Antwortqualität: Modelle mit RAG liefern belegbare Auskünfte aus Ihrer Dokumentation, inklusive Qüllenverweis auf den exakten Abschnitt. Das Halluzinationsrisiko sinkt deutlich.
  • Skalierbarkeit: Neue Dokumente werden indiziert, das Modell muss nicht neu trainiert werden. Von hundert auf eine Million Chunks ist eine Frage der Infrastruktur, nicht der Methodik.
  • Kosten: Eine RAG-Pipeline ist um Größenordnungen günstiger als Fine-Tuning eines großen Basismodells und lässt sich mit offenen Embeddings und pgvector im dreistelligen Euro-Bereich pro Monat betreiben.
  • Zugriffskontrolle: Dokumente tragen Berechtigungs-Metadaten. Der Vertrieb sieht Kundendaten, die Fertigung Produktionsunterlagen, niemand mehr, als er darf.
  • Aktualität: Tauschen Sie ein Dokument aus, ändert sich die Antwort ab der nächsten Anfrage. Bei Fine-Tuning müssten Sie das Modell erneut trainieren.

Abgrenzung zu Fine-Tuning

Fine-Tuning und RAG werden oft als Alternativen verkauft, sind es aber nicht. Fine-Tuning verändert das Verhalten des Modells, RAG erweitert sein Wissen. Ein fein getuntes Modell schreibt besser im Stil Ihrer Marke, formatiert konsequent Ihre Angebots-Struktur oder befolgt eine bestimmte Gesprächslogik. Aber es weiß nicht, welcher Preis heute in der SAP-Tabelle steht, und es wird das auch morgen nicht wissen.

Die Faustregel: Fine-Tuning für Stil und Verhalten, RAG für Fakten und Aktualität. Die meisten Unternehmens-Assistenten brauchen zu Beginn ausschließlich RAG. Fine-Tuning kommt später, wenn die Wissensbasis steht und die Frage nach einheitlicher Markenstimme oder spezifischen Output-Formaten wirklich nötig wird.

Typische Anwendungen

Die stärksten Hebel sehen wir in drei Szenarien. Erstens im internen Support-Chatbot: Mitarbeiter fragen in natürlicher Sprache nach IT-Richtlinien, Reisekosten-Regeln oder Produktspezifikationen und bekommen Antworten mit Qüllenangabe, anstatt in einem veralteten Intranet zu suchen. Zweitens im Vertriebsassistenten: Der Vertrieb beschreibt einen Interessenten, das System zieht passende Referenzen, Preismodelle und technische Eckdaten aus der Wissensbasis und schlägt die beste Argumentationslinie vor. Drittens im Proposal-Generator: Aus einer Ausschreibung werden automatisch Angebotsbausteine zusammengesetzt, inklusive Referenzen und technischer Beschreibungen aus Ihren eigenen, bereits gewonnenen Projekten.

Fazit

Sprachmodelle entfalten ihren wirtschaftlichen Wert erst, wenn sie Ihr Wissen kennen. Der Weg dorthin führt nicht über teures Fine-Tuning, sondern über eine sauber gebaute RAG-Pipeline: klug zerteilte Dokumente, ein passendes Embedding-Modell, eine Vektor-Datenbank in der richtigen Region und eine Orchestrierung, die Ihr Team selbst pflegen kann. Wer die Custom Knowledge Base einmal hat, hat keine Chatbot-Spielerei gebaut, sondern ein Betriebssystem für unternehmensinternes Wissen.

Hat Ihnen dieser Artikel gefallen?

Kontaktieren Sie uns für weitere Informationen zu diesem Thema.