Die meisten stellen sich vor, man kippt seine Dokumente in ein Sprachmodell und stellt Fragen. So funktioniert es nicht — und genau deshalb liefern viele KI-Wissenssuchen selbstbewusst formulierten Unsinn. Was zwischen Ihren Dokumenten und einer guten Antwort wirklich passiert.
Die Vorstellung ist verlockend einfach: Man nimmt alles, was das Unternehmen weiß — Datenblätter, Verträge, Projektakten, das Wiki — kippt es in ein Sprachmodell und kann fortan jede Frage stellen. ChatGPT kann doch reden, also wird es das schon irgendwie durchsuchen.
Tatsächlich läuft das anders. Und dieses Missverständnis ist der Grund, warum so viele erste Gehversuche mit KI-Wissensmanagement enttäuschen: Die Antworten klingen souverän, sind aber falsch, unvollständig oder beziehen sich auf das falsche Dokument. Es lohnt sich zu verstehen, was zwischen einer Frage und einer guten Antwort tatsächlich passiert — nicht um es selbst zu bauen, sondern um zu erkennen, woran es liegt, wenn eine KI-Suche schlechte Ergebnisse liefert.
Ein Sprachmodell kennt nur das, womit es trainiert wurde. Ihre internen Dokumente gehören nicht dazu — das Modell hat Ihre Konstruktionsunterlagen oder Ihre Mandantenakten nie gesehen. Fragt man es trotzdem, antwortet es aus seinem allgemeinen Training und rät den Rest. Genau das nennt man Halluzination.
Der naheliegende Einwand: Dann gebe ich ihm die Dokumente eben mit der Frage zusammen. Das geht — aber nur bis zu einer bestimmten Menge. Jedes Modell hat ein Kontextfenster, eine Obergrenze dafür, wie viel Text es gleichzeitig verarbeiten kann. Ein paar Seiten passen hinein. Zehntausend Dokumente nicht.
Die Kontextfenster werden zwar größer — manche Modelle nehmen heute hunderte Seiten auf einmal. Trotzdem löst das die Aufgabe nicht: Je mehr irrelevanter Text mitläuft, desto schlechter findet das Modell das Entscheidende darin. Wichtige Stellen mitten in einem langen Kontext werden nachweislich übersehen, und mit jeder Frage die gesamte Wissensbasis durchzureichen wird zudem teuer und langsam. Mehr hineinzukippen macht die Antwort also nicht besser, sondern oft schlechter.
Die eigentliche Aufgabe ist deshalb nicht “dem Modell alles geben”, sondern: dem Modell bei jeder Frage genau die drei, vier relevanten Stellen geben — und sonst nichts. Das System, das diese Vorauswahl trifft, ist der Kern. Das Sprachmodell formuliert am Ende nur noch. Im Fachjargon heißt dieser Aufbau RAG — Retrieval-Augmented Generation, also “Erzeugung, ergänzt durch Heraussuchen”. Das Heraussuchen ist der Teil, der über die Qualität entscheidet, und er besteht aus vier Schritten.
Ein 80-seitiges Handbuch ist als Ganzes nutzlos für die Suche. Niemand stellt eine Frage, die sich auf 80 Seiten gleichzeitig bezieht — sondern auf einen Absatz darin. Also werden alle Dokumente in kleinere Stücke zerschnitten, sogenannte Chunks.
Klingt banal, ist aber die erste Stelle, an der eine Suche kaputtgehen kann. Schneidet man zu grob, enthält ein Chunk mehrere Themen, und die Suche wird unscharf. Schneidet man zu fein, reißt man Zusammenhänge auseinander — die Antwort steht im einen Chunk, die Bedingung dazu im nächsten, und das System findet immer nur die Hälfte. Wer eine Tabelle oder eine Stückliste stumpf nach Zeichenzahl zerschneidet, zerstört genau die Struktur, die sie lesbar macht.
Gutes Chunking richtet sich nach der Bedeutung, nicht nach dem Lineal. Das ist der erste Punkt, an dem sich ein Nachmittagsprojekt von einer durchdachten Lösung unterscheidet.
Jetzt kommt der Schritt, der die ganze Sache erst intelligent macht. Jeder Chunk wird in eine Zahlenreihe übersetzt, ein sogenanntes Embedding. Man kann sich das wie eine Koordinate vorstellen: Texte mit ähnlicher Bedeutung bekommen ähnliche Koordinaten und liegen damit nah beieinander.
Der entscheidende Unterschied zur klassischen Suche: Es geht um Bedeutung, nicht nur um Stichworte. Eine normale Volltextsuche nach “Mitarbeiter krankgemeldet” findet nur Dokumente, in denen genau diese Wörter stehen. Ein Embedding versteht, dass “Arbeitsunfähigkeit”, “Krankschreibung” und “AU-Bescheinigung” dasselbe Feld betreffen — auch wenn kein einziges Wort übereinstimmt. Genau diese Bedeutungssuche fehlt den meisten gewachsenen Firmensuchen.
Die Stichwortsuche ganz zu ersetzen wäre allerdings ein Fehler. Bei exakten Bezeichnern — Artikelnummern, Fehlercodes, Normen wie “DIN EN 1090”, Paragraphen wie ”§ 5 Abs. 2” — ist die wörtliche Suche der semantischen überlegen, weil hier eben nicht die ungefähre Bedeutung zählt, sondern das exakte Zeichen. Gute Systeme kombinieren deshalb beides (man spricht von hybrider Suche): Bedeutung für die Fließtext-Fragen, exakter Treffer für Teilenummern und Normen. Gerade im technischen Mittelstand entscheidet diese Kombination über brauchbare Ergebnisse.
Wird eine Frage gestellt, wird auch sie in so ein Embedding übersetzt. Dann sucht das System die Chunks, deren Koordinaten der Frage am nächsten liegen. Das ist die Vektorsuche: kein Abgleichen von Wörtern, sondern Finden des inhaltlich Ähnlichsten.
Das Ergebnis ist eine Trefferliste — sagen wir, die zwanzig Chunks, die der Frage bedeutungsmäßig am nächsten kommen. Und hier glauben viele, sie seien fertig: Treffer gefunden, dem Modell geben, antworten lassen. Das ist der Punkt, an dem die Qualität kippt.
Die Vektorsuche ist schnell, aber grob. Sie findet, was ungefähr passt, und sortiert dabei oft mittelmäßig. Der wirklich relevante Absatz landet vielleicht auf Platz sieben, während oben drei Chunks stehen, die nur thematisch in der Nähe sind. Gibt man dem Sprachmodell diese Reihenfolge ungefiltert, baut es seine Antwort auf den falschen Stellen auf — und klingt dabei genauso überzeugt wie bei einer richtigen.
Ein Reranker ist ein zweites, genaueres Modell, das die Trefferliste der Vektorsuche noch einmal prüft und neu ordnet: Welcher dieser zwanzig Chunks beantwortet die konkrete Frage tatsächlich am besten? Erst die drei, vier obersten gehen ans Sprachmodell.
Dieser Schritt fällt kaum ins Gewicht, weil der Reranker nur die zwanzig vorgefilterten Treffer bewertet, nicht die gesamte Wissensbasis. Trotzdem wird er in schnell gebauten Systemen oft gespart — weil eine Suche auch ohne ihn schon “irgendwie Treffer” liefert. Der Unterschied zwischen “irgendwie Treffer” und “die richtige Antwort mit der richtigen Quelle” ist aber genau der, der darüber entscheidet, ob Ihre Mitarbeiter dem System nach zwei Wochen noch vertrauen oder es wieder ignorieren.
Dokumente sinnvoll zerschneiden, in Bedeutung übersetzen, das Ähnlichste finden, das Relevanteste nach oben sortieren — und erst dann das Sprachmodell formulieren lassen. Fällt einer dieser Schritte weg oder ist schlecht gemacht, leidet die Antwort, egal wie gut das Modell ist.
Ein erstes, naives RAG-System ist an einem Nachmittag gebaut — es gibt fertige Bausteine für jeden der vier Schritte. Genau das verleitet zu der Annahme, KI-Wissenssuche sei ein gelöstes Problem. Der Prototyp beeindruckt in der Demo und enttäuscht im Alltag.
Der Unterschied liegt in den Details, die in der Demo nicht auffallen: Wie schneidet man eine Stückliste, ohne ihre Struktur zu zerstören? Wie geht das System mit Tabellen, gescannten PDFs, widersprüchlichen Dokumentständen um? Wie stellt man sicher, dass ein Mitarbeiter über die Suche nur findet, was er ohnehin sehen darf? Wie verhindert man, dass das Modell bei einer Frage ohne gute Quelle trotzdem etwas erfindet, statt ehrlich “weiß ich nicht” zu sagen?
Das sind keine Modell-Fragen. Das sind Ingenieurs-Fragen — und sie entscheiden darüber, ob aus einer beeindruckenden Demo ein System wird, dem Ihr Unternehmen im Tagesgeschäft vertraut.
Genau diese Schritte sind unser Handwerk. Wenn Sie überlegen, Ihr Firmenwissen mit KI durchsuchbar zu machen — oder ein erster Versuch nicht die Antworten geliefert hat, die Sie erwartet haben — schauen wir uns das gerne an. In einem kostenlosen Erstgespräch klären wir in 30 Minuten, woran es liegt und was sich für Sie lohnt.
Mehr dazu, wie wir das umsetzen, auf unserer Seite zur KI-Wissensdatenbank.
Wenn ihr wissen wollt, was davon für euch relevant ist — wir klären das in 30 Minuten.
Gespräch buchen