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 heisst RAG.

Stefan KühneStefan Kühne
15. April 20268 Min. Lesezeit

Die meisten Unternehmen, die ChatGPT, Claude oder Gemini im Alltag einsetzen, stossen 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 Datenblaetter oder die Entscheidungen des letzten Quartals. Der spuerbare Produktivitaetssprung 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 Begruendung, 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 grossen Prompt zu kippen, scheitert an den Kontextfenstern. Selbst Modelle mit ein bis zwei Millionen Tokens Kontext lassen sich nicht mit einer vollständigen Unternehmensdokumentation fuellen, ohne dass Latenz, Kosten und Qualität der Antworten kippen. Je mehr Text im Fenster steht, desto eher übersieht das Modell das Relevante. Zudem muessten Sie bei jeder Anfrage dieselben Dokumente erneut mitschicken.

Der Mechanismus: Retrieval-Augmented Generation

Der etablierte Weg heisst 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 laeuft 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 einschlaegigen Aktenseiten hinlegt.

Embedding-Modelle: die semantische Übersetzung

Ein Embedding ist ein Zahlenvektor, in dem semantisch aehnliche 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 laesst, ohne die Qualität stark zu verlieren. Die guenstigere 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 europaeische 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 europaeischen 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 aehnlichsten Vektoren finden. Für die Auswahl sind drei Fragen entscheidend: Wo liegen die Daten, wie tief ist der Wartungsaufwand, und wie laesst sich das System in bestehende Infrastruktur integrieren.

Pinecone ist ein vollständig gemanagter Managed Service, schnell einsetzbar, in der Standardkonfiguration aber US-lastig. Weaviate laesst sich als Managed Cloud in Europa betreiben oder komplett selbst hosten und unterstuetzt 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 laesst. 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 Geschaeftsdaten haelt.

Für die meisten unserer Mandanten ist pgvector die richtige Antwort. Keine neue Datenbank, kein zusaetzlicher Betrieb, keine weiteren Vendor-Vertraege, 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 unterschaetzte Hebel

Die Qualität einer RAG-Pipeline haengt massgeblich davon ab, wie die Dokumente in Abschnitte zerteilt werden. Zu grosse Chunks verwaessern die Semantik, zu kleine reissen Zusammenhaenge 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 Saetze nicht mitten im Argument abbrechen.

Wichtiger als die reine Tokenzahl ist die Struktur. Vertraege werden nicht einfach nach 800 Tokens geschnitten, sondern nach Paragraphen und Klauseln. Technische Datenblaetter zerteilen wir nach Produkten und Kennwertbloecken, Produktkataloge nach Artikelnummern. Je präziser die Grenzen an die Semantik der Quelle angelehnt sind, desto treffender sind spaeter die Retrieval-Ergebnisse. Metadaten wie Dokumenttyp, Version, Gueltigkeitsdatum 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 spaetestens 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 europaeischen Embedding-Modellen und Self-Hosted-Vektor-DB für alles, was unter Berufsgeheimnis, Betriebsrat oder Exportkontrolle faellt. Hybrid, wenn die Rohdaten in Europa bleiben und nur anonymisierte Prompts an ein US-LLM gehen. Und voll gemanagt bei unkritischen Inhalten wie oeffentlich zugaenglichen Produktunterlagen. In jedem Fall liegen Auftragsverarbeitungsvertraege, technisch-organisatorische Maßnahmen und ein nachvollziehbares Loeschkonzept 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 einfuegt, statt sie zu ersetzen. Der erste Schritt ist immer die Quellen-Inventur: Welche Dokumente, Datenbanken und Tickets enthalten das Wissen, das heute im Kopf einzelner Mitarbeiter steckt? Aus dieser Liste wird ein Prioritaetskanon, denn nicht jedes Dokument gehoert in die erste Ausbaustufe.

Parallel waehlen 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 groessten Unterschied macht die Betriebsebene. Eine Wissensbasis ist kein Projekt, sondern ein Produkt. Wir richten Auto-Ingest für Ihre Quellsysteme ein, damit neue Vertragsversionen und aktualisierte Datenblaetter automatisch in die Basis fließen. Wir liefern Evaluations-Sets, mit denen Sie messen, ob Antworten über die Zeit präziser oder schwaecher 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 Auskuenfte aus Ihrer Dokumentation, inklusive Quellenverweis 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 guenstiger als Fine-Tuning eines grossen Basismodells und laesst 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.
  • Aktualitaet: Tauschen Sie ein Dokument aus, aendert sich die Antwort ab der nächsten Anfrage. Bei Fine-Tuning muessten Sie das Modell erneut trainieren.

Abgrenzung zu Fine-Tuning

Fine-Tuning und RAG werden oft als Alternativen verkauft, sind es aber nicht. Fine-Tuning veraendert 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 weiss 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 Aktualitaet. Die meisten Unternehmens-Assistenten brauchen zu Beginn ausschließlich RAG. Fine-Tuning kommt spaeter, wenn die Wissensbasis steht und die Frage nach einheitlicher Markenstimme oder spezifischen Output-Formaten wirklich noetig wird.

Typische Anwendungen

Die staerksten Hebel sehen wir in drei Szenarien. Erstens im internen Support-Chatbot: Mitarbeiter fragen in natuerlicher Sprache nach IT-Richtlinien, Reisekosten-Regeln oder Produktspezifikationen und bekommen Antworten mit Quellenangabe, 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 schlaegt 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.