RAG-Wissensbasis aufbauen: Von PDFs zu Antworten

Eine RAG-Wissensbasis beantwortet Fachfragen aus Ihren eigenen PDFs, ohne dass ein Sprachmodell dafür neu trainiert werden muss. Statt das Modell mit statischem Wissen zu füttern, durchsucht Retrieval-Augmented Generation Ihre Dokumente zur Laufzeit, zieht die relevanten Textstellen heraus und lässt das Modell daraus eine belegte Antwort formulieren. Genau das unterscheidet RAG von rein generativen Chatbots: Antworten stammen aus Ihren Quellen, nicht aus dem Trainingsdatensatz. Für Mittelständler, deren Wissen in Handbüchern, Normen, Verträgen und technischen Dokumentationen steckt, ist das der schnellste Weg zu einem funktionierenden KI-Assistenten. NeXify AI setzt solche Systeme für B2B-Kunden zum Tagessatz von 449 Euro um – inklusive Datenaufbereitung, Embedding-Pipeline und Anbindung an bestehende Systeme. Was konkret dahintersteckt, zeigt dieser Leitfaden: von der PDF-Extraktion über das Chunking bis zur Antwortgenerierung mit Quellenverweis. Wer selbst bauen will, findet die Architektur. Wer bauen lassen will, findet unter KI-Begleiter den passenden Einstieg.

Bevor irgendein Vektorspeicher angelegt wird, steht die Frage: Welche Dokumente sollen überhaupt rein? Der häufigste Fehler beim RAG-Aufbau ist nicht die Technik, sondern ein ungepflegter Dokumentenbestand. Dubletten, veraltete Versionen, gescannte PDFs ohne Textebene, passwortgeschützte Dateien – all das landet sonst ungefiltert in der Wissensbasis und verschlechtert die Antwortqualität messbar. Ein Bereinigungsdurchlauf vor dem Import kostet bei einem Bestand von einigen tausend PDFs je nach Zustand ein bis drei Tage, spart aber dauerhaft falsche oder widersprüchliche Antworten. Entscheidend ist außerdem eine klare Quelle-der-Wahrheit-Regel: Pro Thema existiert genau ein aktuelles Dokument. Was ersetzt wurde, fliegt raus oder wird als archiviert markiert. Wer diesen Schritt überspringt, bekommt später Antworten, die sich gegenseitig widersprechen – und verliert das Vertrauen der Nutzer schneller, als jede technische Optimierung es zurückholen kann. NeXify AI liefert diesen Aufbereitungsschritt als Teil des Leistungsumfangs mit, inklusive Prüfung auf Textebene, Dubletten und Versionskonflikte.

Retrieval-Augmented Generation folgt einem klaren Pipeline-Prinzip. Dokumente werden extrahiert, in Chunks zerlegt, als Vektoren in einer Datenbank gespeichert. Bei einer Anfrage wird die Frage ebenfalls vektorisiert, die ähnlichsten Chunks werden per Ähnlichkeitssuche gefunden, und ein Sprachmodell generiert aus Frage und Kontext eine Antwort. Der Markt dafür wächst rasant: Der globale RAG-Markt wurde laut Branchenanalysen auf rund 1,1 Milliarden US-Dollar im Jahr 2024 geschätzt und soll bis 2030 mit einer jährlichen Wachstumsrate von über 40 Prozent auf mehr als 8 Milliarden US-Dollar anwachsen (laut Marktbenchmark RAG-Systeme 2025). Für DACH-KMU relevanter ist eine andere Zahl: Unternehmen, die RAG auf internen Wissensbeständen einsetzen, berichten in Befragungen von 30 bis 50 Prozent weniger Zeit für die Informationssuche in Support- und Fachabteilungen (laut Marktbenchmark DACH-KI 2026). Das deckt sich mit den Projekterfahrungen von NeXify AI: Sobald die Trefferquote der Suche über 85 Prozent liegt, kippt die Nutzerwahrnehmung – aus einem Spielzeug wird ein Werkzeug, das täglich genutzt wird.

Die Textqualität entscheidet über alles Weitere. Gute PDFs liefern eine saubere Textebene, klare Überschriftenstrukturen und Metadaten. Schlechte PDFs sind Scans ohne OCR, haben Wasserzeichen, mehrspaltige Layouts oder Tabellen, die beim Export zerfallen. Für den Aufbau der Wissensbasis bedeutet das: OCR für gescannte Dokumente, Layout-Erkennung für mehrspaltige Seiten, Tabellen möglichst als strukturierte Daten statt Fließtext. Bewährt hat sich ein zweistufiger Extraktionsprozess: erst Text und Struktur extrahieren, dann die Struktur nutzen, um semantisch sinnvolle Chunks zu bilden. Ein Chunk, der mitten im Satz beginnt und mitten in einer Tabelle endet, ist für die Vektorsuche weitgehend wertlos. Die Chunk-Größe ist ein Kompromiss: zu groß, und die Suche findet den relevanten Absatz nicht präzise genug; zu klein, und der Kontext geht verloren. In der Praxis liegen gute Werte zwischen 500 und 1.500 Zeichen pro Chunk, mit Überlappung von 10 bis 20 Prozent, damit Sätze an den Rändern nicht abgeschnitten werden. Diese Parameter sind keine Einmal-Entscheidung: Sie müssen am eigenen Dokumentenbestand getestet und iteriert werden, bis die Trefferquote stimmt.

Nach dem Chunking kommt das Embedding: Jeder Textabschnitt wird in einen Vektor überführt, der die semantische Bedeutung abbildet. Welches Embedding-Modell man wählt, hängt von Sprache und Domäne ab. Deutsche Fachtexte mit technischem Vokabular brauchen Modelle, die für den deutschen Sprachraum und idealerweise für technische Domänen trainiert wurden. Ein falsch gewähltes Modell ist der zweithäufigste Grund für schlechte Trefferquoten – direkt nach unsauberen Quelldaten. Der Vektorspeicher selbst ist dagegen meist nicht der Engpass. Ob pgvector in einer bestehenden PostgreSQL-Datenbank oder ein spezialisierter Vektorstore: Für Bestände bis zu einigen hunderttausend Chunks reichen die gängigen Optionen aus, solange die Indexierung sauber konfiguriert ist. Wichtiger als die Datenbankwahl ist die Metadatenpflege. Jeder Chunk sollte wissen, aus welchem Dokument er stammt, welcher Version, welchem Kapitel, welchem Gültigkeitsdatum. Genau diese Metadaten ermöglichen später Quellenangaben in den Antworten und gezielte Filter, etwa: Suche nur in freigegebenen Dokumenten, nicht in Entwürfen.

Der Retrieval-Schritt ist das Herzstück. Die naive Variante – die drei ähnlichsten Chunks per Kosinus-Ähnlichkeit ziehen und dem Modell geben – funktioniert für einfache Fälle, stößt aber schnell an Grenzen. Bessere Ergebnisse liefern Hybrid-Suche aus Vektor- und Stichwortsuche, Relevance-Reranking der Treffer und kontextabhängige Filter. Ein Beispiel aus der Praxis: Die Frage nach der maximal zulässigen Betriebstemperatur einer Anlage liefert mit reiner Vektorsuche oft generische Sicherheitshinweise statt des konkreten Werts aus dem Datenblatt. Die Kombination mit einer Stichwortsuche nach dem Anlagentyp ändert das. Genau solche Feinheiten entscheiden über den Unterschied zwischen einem Assistenten, der die Antwort meistens findet, und einem, auf den sich Fachabteilungen verlassen. NeXify AI setzt deshalb auf einen Testdatensatz mit realen Fragen aus dem Kundenbetrieb: Mindestens 50 bis 100 typische Anfragen, deren korrekte Antwort dokumentiert ist. Daran wird jede Konfigurationsänderung gemessen, bis die Trefferquote stimmt. Ohne diesen Testdatensatz ist jede Optimierung raten im Dunkeln.

Am Ende der Pipeline steht die Antwortgenerierung. Das Sprachmodell bekommt die Frage, die gefundenen Textstellen mit Quellenangaben und eine klare Anweisung: Antworte nur auf Basis des bereitgestellten Kontexts. Wenn der Kontext nicht ausreicht, sage das. Genau diese Anweisung ist entscheidend, denn Sprachmodelle neigen dazu, fehlendes Wissen zu erfinden, statt eine Lücke zuzugeben. Quellenangaben in jeder Antwort sind nicht optional. Nutzer müssen nachvollziehen können, woher eine Information stammt, sonst entsteht kein Vertrauen. In regulierten Branchen – Maschinenbau, Medizintechnik, Finanzdienstleistungen – sind belegbare Antworten ohnehin Pflicht. Die Antwortqualität hängt daneben von der Prompt-Struktur ab: klare Rolle, klarer Auftrag, Kontext sauber abgegrenzt, Ausgabeformat definiert. Wer diese Pipeline einmal sauber aufgebaut hat, kann sie auf weitere Abteilungen und Dokumentenbestände ausdehnen, ohne die Architektur zu ändern. Genau darin liegt der wirtschaftliche Wert: Die erste Wissensbasis kostet Zeit, jede weitere nur noch einen Bruchteil.

Der Betrieb entscheidet über den langfristigen Erfolg. Eine Wissensbasis ist kein Projekt mit Enddatum, sondern ein lebendes System. Dokumente ändern sich, Versionen kommen dazu, Nutzer formulieren neue Fragen. Wer keine Pflege einplant, erlebt die schleichende Erosion: Die Trefferquote sinkt, alte Dokumente liefern überholte Antworten, das Vertrauen schwindet. Minimaler Betriebsaufwand: ein klarer Prozess für Dokument-Updates, ein wöchentlicher oder monatlicher Blick auf erfolglose Suchanfragen und ein Verantwortlicher, der beides koordiniert. Erfolglose Suchanfragen sind der wertvollste Datenbestand zur Verbesserung: Jede Frage ohne brauchbare Antwort zeigt eine Lücke im Dokumentenbestand oder in der Suchkonfiguration. Ebenso wichtig ist die Absicherung: Zugriffsrechte müssen durchgesetzt werden, sensible Dokumente dürfen nicht für alle sichtbar sein. Die Wissensbasis sollte dieselben Berechtigungen respektieren wie das Dokumentenmanagementsystem, aus dem sie gespeist wird. Wer diese Betriebsthemen von Anfang an einplant, baut keine Spielerei, sondern ein System, das Fachabteilungen täglich nutzen. Der Einstieg dafür muss kein Großprojekt sein: NeXify AI startet solche Vorhaben zum Tagessatz von 449 Euro – wer den Umfang selbst einschätzen will, findet auf der Seite zu den KI-Begleitern die Details, oder fragt direkt über das Kontaktformular an.

Technisch lässt sich eine RAG-Wissensbasis heute mit überschaubarem Aufwand aufsetzen – die eigentliche Arbeit steckt in Datenqualität, Chunking-Strategie und kontinuierlichem Testen. Die Reihenfolge entscheidet über das Ergebnis: erst Dokumentenbestand bereinigen, dann Chunking und Embedding am eigenen Material optimieren, dann Retrieval mit realen Testfragen messen, dann in den Betrieb überführen. Jeder Schritt, der übersprungen wird, rächt sich später als schlechte Antwortqualität, und Antwortqualität ist die einzige Kennzahl, die Nutzer wirklich interessiert. Für KMU, die intern niemanden für diese Pipeline abstellen können, lohnt der Blick auf externe Umsetzung: Unsere Preise zeigen transparent, was der Aufbau einer Wissensbasis kostet. Der wichtigste Rat bleibt: klein anfangen, an echten Fragen messen, iterieren. Eine Wissensbasis mit 500 sauber aufbereiteten Dokumenten und geprüfter Trefferquote schlägt jede Lösung mit 50.000 ungepflegten PDFs.