Unternehmenswissen mit RAG

Unternehmenswissen mit RAG

0:00 Willkommen zu Modul acht. Der Richtlinienlotse hat im letzten Modul gelernt, ehrlich zu sagen, wenn er nichts weiß. Jetzt bekommt er etwas, das er wissen kann: die internen Richtlinien von Brandtner Fördertechnik. Das ist der Moment, auf den viele bei einer KI-Plattform im Unternehmen warten. Endlich Antworten aus den eigenen Dokumenten statt aus dem allgemeinen Wissen eines Modells.

0:22 In diesem Modul klären wir, wann RAG überhaupt der richtige Weg ist, verfolgen ein Dokument vom Hochladen bis in den Index, regeln, wer eine Wissensbasis pflegt, und prüfen die Antwortqualität mit Fragen, die auch die unbequemen Fälle abdecken. Denn genau dort entscheidet sich, ob man einem Wissensassistenten vertrauen kann.

Unternehmenswissen mit RAG

0:41 Zum Abschluss des dritten Tages kommt das Unternehmenswissen ins Spiel. Der Satz auf der Folie enthält zwei Maßstäbe, und beide begleiten uns durch das ganze Modul. Ein Wissensassistent ist nie besser als der Bestand, aus dem er zitiert. Und er ist nie ehrlicher als die Regel, was er tun soll, wenn dort nichts steht.

Wann RAG passt

1:00 Bevor wir Dokumente hochladen, eine Grundsatzfrage. Es gibt mehr als einen Weg, ein Dokument ins Gespräch zu bringen, und nicht jeder passt zu jedem Bestand. Stellen Sie sich eine Prüfung mit offenem Buch vor. Die Prüfungsfrage kommt, Sie schlagen die passenden Seiten auf, legen sie neben das Blatt und schreiben die Antwort mit Blick darauf. Genau das tut Retrieval Augmented Generation.

1:23 Zu jeder Frage werden die passenden Abschnitte aus den Dokumenten gesucht, in eine Vorlage eingesetzt und der Frage vorangestellt. Das Modell antwortet dann auf Grundlage dieser Auszüge, statt nur aus dem, was es im Training gelernt hat. Der Gewinn ist offensichtlich: aktuelles, internes Wissen ohne neues Training. Der Haken liegt in der Suche. Schlägt sie die falschen Seiten auf, hilft auch das beste Modell nicht.

1:48 Drei Wege, und die Logik dahinter ist eine Abwägung zwischen Menge und Vollständigkeit. Bei der gezielten Suche werden nur die relevantesten Abschnitte eingefügt. Das passt für große Bestände und gezielte Fragen, wie beim Richtlinienlotsen. Beim vollen Kontext geht das ganze Dokument in jede Nachricht. Das lohnt sich nur für kurze Leitfäden, die immer gelten. Der dritte Weg ist der neueste: Das Modell entscheidet selbst, wann es nachschlägt, und ruft dafür Werkzeuge auf.

2:16 Das setzt aber ein Modell voraus, das Werkzeuge verlässlich bedient, wie wir es in Modul sechs ausgewählt haben. Umschalten lässt sich das je Datei oder Wissensbasis. Hier kommt eine Rechnung, die überrascht. Ollama wählt das Kontextfenster abhängig vom Grafikspeicher, auf kleineren Karten sind es nur rund viertausend Token.

2:36 Gleichzeitig ergeben fünf Treffer mit je tausend Token schon rund fünftausend Token Auszüge, bevor die eigentliche Frage überhaupt kommt. Das passt schlicht nicht zusammen, und gekürzt wird still. Die Lösung ist aber nicht einfach ein riesiges Kontextfenster. Ein langes Fenster ersetzt keine Auswahl, Veraltetes und Widersprüchliches landet dann eben auch mit im Prompt.

2:58 Für Lotsenhaus heißt das ganz praktisch: Zuerst die Kontextlänge des lokalen Modells auf inferenz-01 prüfen, dann erst RAG testen.

Vom Dokument zum Index

3:06 Jetzt verfolgen wir ein Dokument auf seinem Weg in die Wissensbasis. Und dabei gilt ein harter Satz: Was beim Einlesen verloren geht, findet keine Suche je wieder. Fünf Stationen, und jede kann etwas kaputt machen. Zuerst wird Text extrahiert, samt Tabellen, wenn es gut geht. Dann wird der Text in Abschnitte geschnitten, mit etwas Überlappung, damit kein Satz genau an der Schnittkante verloren geht.

3:32 Jeder Abschnitt wird in einen Zahlenvektor übersetzt, der seine Bedeutung abbildet, und landet in der Vektordatenbank. Erst bei einer Frage kommt der letzte Schritt: suchen, sortieren, einfügen. Warum ist diese Reihenfolge so wichtig? Weil Fehler nach rechts wandern. Eine Tabelle, die bei der Extraktion zerfällt, kann keine spätere Station mehr reparieren, egal wie gut das Suchverfahren ist.

3:56 Die erste Station verdient eine eigene Folie, denn hier gibt es die meisten Optionen. Die Logik der Tabelle: Je schwieriger das Dokument, desto spezialisierter die Engine. Der eingebaute Standard reicht für saubere Textdateien, scheitert aber an gescannten PDFs. Tika läuft lokal und ist ein solider Allrounder. Docling erkennt Layout und Tabellen, was für ein Dokument wie das Projekthandbuch PH-3 entscheidend sein kann.

4:21 Bei Diensten von außen, etwa der OCR von Mistral, stellt sich wieder die Datenklassenfrage. Und der wichtigste Rat steht in der Fußzeile: Erst eine Datei hochladen und die extrahierte Vorschau wirklich lesen. So sieht die Laborkonfiguration in lotsenhaus-betrieb aus. Das Muster: Alles bleibt im Haus. Die Extraktion übernimmt ein lokaler Tika-Server, das Embedding läuft über Ollama auf inferenz-01 mit einem eigenen Embedding-Modell.

4:47 Der Text wird nach Token geschnitten, und die Suche kombiniert Vektorsuche mit klassischer Stichwortsuche, mit fünf Treffern. Damit verlassen weder Dokumente noch Suchanfragen das Unternehmen. Die Fußzeile kennen Sie im Prinzip schon aus Modul sechs, hier ist sie besonders tückisch. Nach dem ersten Start gelten diese Werte aus der Datenbank, nicht mehr aus der Compose-Datei. Wer später etwas in der Datei ändert, sieht keine Wirkung.

5:14 Neun Stellschrauben, und es wäre ein Fehler, an allen gleichzeitig zu drehen. Die Tabelle gliedert sich in zwei Gruppen. Oben steht, wie geschnitten wird: Größe, Überlappung, Trennung an Überschriften und das Zusammenführen zu kleiner Abschnitte. Unten steht, wie gesucht wird: wie viele Treffer, ob die Stichwortsuche mitläuft und mit welchem Gewicht, wie viele Treffer das Reranking übrig lässt und ab welcher Relevanz ein Treffer verworfen wird.

5:39 Der Unterschied ist praktisch wichtig. Änderungen am Schnitt betreffen den Index, Änderungen an der Suche wirken sofort. Und das Reranking braucht ein eigenes Modell, das lokal geladen wird. Vier Fallen beim Einlesen. Die erste ist besonders heimtückisch: Gescannte Seiten ohne OCR-fähige Engine. Das Dokument erscheint als indiziert, ist aber leer, und niemand merkt es, bis eine Frage ins Leere geht. Die zweite: Die Mindestgröße für Abschnitte auf null lassen.

6:07 Dann zerfallen Inhaltsverzeichnisse in viele winzige Abschnitte, die die Trefferliste verstopfen. Die dritte ist ein methodischer Fehler. Hybride Suche einschalten, ohne vorher und nachher mit denselben Referenzfragen zu vergleichen, ist Raten mit besserem Gefühl. Und die vierte betrifft den Betrieb. Die eingebaute Vektordatenbank mit mehreren Workern oder Replikaten zu betreiben, führt zu Abstürzen.

Wissensbasen betreiben

6:33 Eine Wissensbasis ist kein Projekt mit Ende, sondern ein Bestand, der lebt. Richtlinien bekommen neue Fassungen, Dokumente veralten. Jetzt geht es darum, wer pflegt und was beim Austausch passiert. Eine Wissensbasis ist am ehesten mit einem Handapparat in einer Bibliothek vergleichbar. Eine kuratierte Sammlung, die an einem bestimmten Platz steht, hier an einem Modell oder einem Chat.

6:57 Wer darauf zugreifen darf, regeln dieselben Rechte, die Sie schon von den Assistenten kennen. Entweder privat mit Lese- oder Schreibrecht für bestimmte Gruppen und Personen, oder öffentlich für alle Angemeldeten. Und auch hier gilt die Regel aus Modul sieben: Schreibrecht ist praktisch Eigentum. Wer es hat, darf nicht nur Dokumente austauschen, sondern die Wissensbasis auch weiter teilen.

7:20 Deshalb gehört dieses Recht in wenige, klar benannte Hände. Die Tabelle setzt das Prinzip für die Wissensbasis Richtlinien um. Die Logik: Rechte folgen der Verantwortung, nicht der Hierarchie. lh-wissen pflegt und verantwortet die Fassungen, also bekommt nur diese Gruppe Schreibrecht. Alle Anwender lesen über den Richtlinienlotsen. Auffällig ist die dritte Zeile.

7:41 Die Plattformadministration bekommt kein Recht auf die Inhalte, denn sie betreibt Lotsenhaus, pflegt aber keine Richtlinien. Fachgruppen brauchen nichts extra, sie sind über die Anwendergruppe abgedeckt. Die Fußzeile beschreibt eine wertvolle Eigenschaft: Ein an Wissensbasen gebundenes Modell durchsucht nur diese, nicht alles, was die fragende Person sonst noch sehen dürfte.

8:04 Diese Tabelle beantwortet eine Frage, die im Betrieb sicher kommt: Ich habe eine Einstellung geändert, was muss ich jetzt tun? Die Logik folgt dem Weg des Dokuments von vorhin. Je weiter vorn die Änderung ansetzt, desto mehr muss neu gemacht werden. Eine neue Abschnittsgröße lässt alte Abschnitte weiter gelten, ein Neuaufbau des Index ist empfohlen.

8:24 Ein neues Embedding-Modell macht ihn zwingend, sonst passen Fragen und Abschnitte nicht mehr zusammen. Bei einer neuen Extraktions-Engine hilft der Neuaufbau gar nicht, weil er mit dem einmal extrahierten Text arbeitet. Dann bleibt nur, die Dateien neu hochzuladen. Ein konkreter Fall: Die Reisekostenrichtlinie RL-07 bekommt eine neue Fassung. Der rote Faden der Schritte ist Klarheit darüber, was gilt.

8:49 Zuerst prüft lh-wissen die neue Fassung und vermerkt Gültigkeitsdatum und Vorgänger. Dann wird die alte Fassung entfernt, nicht daneben liegen gelassen, denn sonst findet die Suche beide. Erst danach kommt die neue Datei hinein, und es wird gewartet, bis die Verarbeitung abgeschlossen ist. Die Referenzfragen zu RL-07 laufen erneut, mit Blick auf die Quellen.

9:12 Und die Änderung landet im Protokoll von lotsenhaus-betrieb. Für große Quellen gibt es ein Werkzeug namens oikb, das inkrementell spiegelt. Sobald Wissen nicht mehr von Hand hochgeladen, sondern aus anderen Systemen gespiegelt wird, entsteht eine neue Frage. Ein Spiegelwerkzeug liest Quellen wie Git, Confluence oder S3 und schreibt sie mit den Rechten seines eigenen Kontos in Lotsenhaus.

9:36 Danach gelten die Rechte der Wissensbasis, nicht mehr die Freigaben im Quellsystem. Ein Dokument, das im Original nur eine kleine Gruppe sehen darf, kann in Lotsenhaus plötzlich für alle lesbar sein. Bei externen Wissensquellen kommt eine technische Bedingung hinzu: Sie brauchen dasselbe Embedding-Modell. Die Prüffrage am Ende ist einfach und unbequem: Sieht in Lotsenhaus jemand mehr als im Original?

Antwortqualität

9:59 Die Wissensbasis steht und wird gepflegt. Aber ob sie gute Antworten liefert, ist damit noch nicht gesagt. Und eine gute Antwort ist auch eine, die zugibt, dass sie nichts weiß. Vier Wege, auf denen eine Antwort aus dem Bestand danebengeht, und jeder hat eine andere Ursache. Fehlt ein Abschnitt, weil er nicht extrahiert oder nicht gefunden wurde, füllt das Modell die Lücke mit Plausiblem.

10:24 Bei Widersprüchen wie den beiden Fassungen von RL-07 werden beide gefunden, mit verschiedenen Kilometerpauschalen. Bei veralteten Dokumenten ohne Datum im Text kann das Modell nicht erkennen, welche Fassung gilt. Am gefährlichsten ist der letzte Punkt, weil er Vertrauen erzeugt. Eine angezeigte Quelle heißt nur, dass dieser Abschnitt eingefügt wurde. Sie heißt nicht, dass er die Aussage in der Antwort tatsächlich trägt.

10:49 Hier sehen Sie einen Ausschnitt der Vorlage, mit der Open WebUI die gefundenen Abschnitte vor die Frage setzt. Das meiste klingt vernünftig: Wenn du es nicht weißt, sag es. Wenn du unsicher bist, frag nach. Aber eine Regel hat es in sich. Steht die Antwort nicht im Kontext und das Modell glaubt, sie trotzdem zu kennen, soll es sie aus eigenem Wissen liefern, mit einem Hinweis.

11:11 Für einen allgemeinen Assistenten mag das hilfreich sein. Für den Richtlinienlotsen ist es genau das falsche Verhalten, denn eine plausible Reisekostenregel aus dem Training ist keine Regel von Brandtner. Deshalb schließt der Systemprompt des Lotsen das ausdrücklich aus. Die Referenzfragen sind das Prüfgerät dieses Moduls, und die rechte Spalte verrät ihre Logik. Jede Frage prüft eine andere Schwachstelle.

11:36 Die Kilometerpauschale prüft den Widerspruch, erwartet wird der Wert der aktuellen Fassung mit Hinweis auf die alte. Die Frage zu USB-Sticks prüft einen einfachen Treffer in der IT-Nutzungsrichtlinie. Die Meilensteine aus dem Projekthandbuch prüfen, ob Tabellen die Extraktion überstanden haben. Und die Frage nach dem Kantinenbudget prüft die Lücke, denn dazu steht nichts im Bestand. Die Fußzeile ist die Bedingung für alles Weitere.

12:02 Ohne festgehaltene Antwort und Quelle gibt es keinen Vergleich, nur Eindrücke. Die letzten vier Fallen betreffen die Qualitätsprüfung. Die erste kennen Sie schon aus Modul sieben: nur Fragen testen, deren Antwort sicher im Bestand steht. Die zweite ist bequem: eine Antwort mit Quellenangabe für richtig halten, ohne den Abschnitt selbst zu lesen. Die dritte ist ein Symptomkurieren.

12:25 Den Widerspruch der beiden RL-07-Fassungen per Prompt zu glätten, statt die alte Fassung zu entfernen, verschiebt das Problem nur. Und die vierte hat Nebenwirkungen. Wer die RAG-Vorlage global ändert, obwohl die Regel nur für einen Assistenten gelten soll, ändert das Verhalten aller anderen gleich mit.

Übung

12:44 Jetzt bauen Sie die Wissensbasis Richtlinien selbst auf und finden heraus, was Extraktion, Chunking und Suche tatsächlich an den Antworten ändern. In dieser Übung geht es um eine Fähigkeit, die im RAG-Alltag oft fehlt: den Einfluss einer Einstellung zu belegen, statt ihn zu vermuten. Sie bauen eine Wissensbasis auf und vergleichen zwei Konfigurationen anhand Ihrer Referenzfragen.

13:06 Der Bestand ist synthetisch und liegt im Labor bereit, mit beiden Fassungen von RL-07, der IT-Nutzungsrichtlinie und dem Projekthandbuch. Fertig sind Sie, wenn für beide Konfigurationen je Frage ein Ergebnis mit Quelle vorliegt. Und wenn zwei Fälle korrekt behandelt sind, die besonders aufschlussreich sind: der Widerspruch bei RL-07 und die Frage, auf die der Bestand keine Antwort hat.

13:30 Der Ablauf folgt den Kapiteln dieses Moduls. Zuerst legen Sie die Wissensbasis an und vergeben die Rechte. Dann laden Sie die Dokumente hoch und lesen die extrahierte Vorschau des Projekthandbuchs, denn dort zeigt sich, ob die Tabellen heil geblieben sind. Bevor Sie testen, halten Sie fünf Referenzfragen mit Antwort und Quelle fest.

13:50 Dann vergleichen Sie zwei Konfigurationen, einmal mit Standardwerten, einmal mit hybrider Suche und Reranking, und empfehlen begründet eine. Die Fußzeile hält den Vergleich fair: Nur Suchparameter ändern, nicht das Embedding-Modell. Im nächsten Modul öffnen wir Lotsenhaus dann für andere Systeme, über APIs und MCP.