Wie Noxidox deine Dokumente versteht: RAG, Vektoren und die Suche erklärt

Wie findet eine KI die richtigen Informationen in hunderten Seiten Dokumenten, ohne jedes einzelne Dokument vollständig lesen zu müssen? Genau hier kommt Retrieval-Augmented Generation, kurz RAG, zur Anwendung. Bei Noxidox setze ich auf dieses Prinzip, um Dokumente direkt auf dem Apple-Gerät durchsuchbar zu machen. Ein wichtiger Bestandteil ist dabei eine Vektorsuche. Was zunächst nach komplizierter Mathematik klingt, lässt sich eigentlich recht anschaulich erklären.
Was ist RAG und warum braucht eine KI das überhaupt?
Sprachmodelle können Texte zusammenfassen, Fragen beantworten und Zusammenhänge erklären. Sie haben allerdings eine entscheidende Einschränkung: Sie können nicht unbegrenzt viele Informationen gleichzeitig berücksichtigen. Wenn man hunderte PDFs mit Verträgen, Besprechungsprotokolle, technische Dokumentationen und persönliche Notizen hat und jetzt wissen möchte: „Welche Fristen wurden in meinen bisherigen Verträgen für eine Kündigung vereinbart?“
Eine KI kennt die Dokumente nicht. Die relevanten Inhalte müssen ihr erst zur Verfügung gestellt werden. Bei hunderten Dokumenten wäre es aber weder praktisch noch effizient, alle in eine Anfrage zu packen.
RAG löst dieses Problem in zwei Schritten:
- Retrieval – Finden: Das System durchsucht die Dokumente und ermittelt die Textstellen, die zu deiner Frage passen.
- Generation – Antworten: Die KI erhält deine Frage zusammen mit den gefundenen Textstellen und formuliert daraus eine verständliche Antwort.
Die KI muss also nicht alle Dokumente kennen. Sie bekommt gezielt die Informationen, welche sie für die aktuelle Aufgabe benötigt.
Chunks: Warum Dokumente in kleine Abschnitte zerlegt werden
Bevor eine intelligente Suche funktionieren kann, müssen die Dokumente vorbereitet werden. Ein wichtiger Schritt ist das sogenannte Chunking. Ein Chunk ist ein kleiner Textabschnitt aus einem Dokument. Zum Beispiel bei einem Mietvertrag. Dieser enthält Informationen zu Mietdauer, Nebenkosten, Kündigungsfristen und Kaution. Würden wir den gesamten Vertrag als einen einzigen Abschnitt behandeln, wäre es schwierig, bei einer konkreten Frage genau die passende Passage zu finden.
Jetzt könnte man den Mietvertrag zum Beispiel in die folgenden Abschnitte aufteilen:
Chunk 1: Mietbeginn und Vertragsdauer
Chunk 2: Höhe der Miete und Nebenkosten
Chunk 3: Kündigungsfristen und Kündigungsbedingungen
Chunk 4: Kaution und Rückzahlung
Jeder Abschnitt bleibt mit seinem Ursprungsdokument verknüpft. So kann das System später nicht nur den passenden Inhalt finden, sondern auch nachvollziehen, aus welchem Dokument er stammt.
Wichtig ist dabei, dass die Aufteilung sinnvoll erfolgt. Ein Chunk muss genug Informationen enthalten, damit seinen Inhalt verständlich ist. Gleichzeitig aber auch klein genug sein, so dass er nach Möglichkeit nur für die Frage relevante Informationen beinhaltet. Wird ein Abschnitt zu klein gewählt, kann der Zusammenhang verloren gehen. Wird er zu groß, enthält er möglicherweise zu viel unnötigen Text.
Deshalb gibt es nicht die eine perfekte Chunk-Größe für alle Anwendungsfälle. Technische Dokumentationen, Verträge und persönliche Notizen können unterschiedliche Anforderungen haben. Manchmal ist es außerdem sinnvoll, benachbarte Abschnitte leicht überlappen zu lassen. So gehen Informationen, die über eine Abschnittsgrenze hinweg zusammengehören, nicht so leicht verloren.
Vektoren: Wie Text eine Bedeutung bekommt, mit der sich rechnen lässt
Computer können Texte direkt nach Wörtern durchsuchen. Eine klassische Volltextsuche findet beispielsweise einen Vertrag, in dem ausdrücklich das Wort „Kündigungsfrist“ vorkommt. Aber was passiert, wenn du stattdessen fragst: „Wie lange vorher muss ich meinen Vertrag beenden?“
Die passenden Informationen könnten vorhanden sein, obwohl dein Suchbegriff im Dokument gar nicht vorkommt. Hier hilft die semantische Suche. So wird versucht, nicht nur einzelne Wörter, sondern die inhaltliche Bedeutung der Textstelle zu berücksichtigen.
Dafür wird Text in einen sogenannten Vektor umgewandelt.
Ein Vektor ist eine Folge von Zahlen, die ein Textmodell aus einem Text erzeugt. Man spricht in diesem Zusammenhang auch von einem Embedding. Im Prinzip wie eine Landkarte vorstellen: Jeder Text bekommt durch seine Bedeutung eine Position in einem sehr großen, mehrdimensionalen Raum. Texte mit ähnlicher Bedeutung liegen nahe beieinander. Texte mit ganz anderen Inhalten liegen weiter auseinander. Das bedeutet nicht, dass der Computer den Text wie ein Mensch versteht. Vielmehr lernt das zugrunde liegende Modell, bestimmte sprachliche und inhaltliche Muster in Zahlen abzubilden.
Ein vereinfachtes Beispiel:
| Text | Inhaltliche Nähe zur Frage |
|---|---|
| „Die Kündigungsfrist beträgt drei Monate.“ | Sehr hoch |
| „Der Vertrag muss mit einer Frist von 90 Tagen beendet werden.“ | Sehr hoch |
| „Die jährliche Wartung erfolgt im Frühjahr.“ | Niedrig |
Die ersten beiden Sätze verwenden unterschiedliche Wörter, beschreiben aber einen ähnlichen Sachverhalt. Eine gut funktionierende semantische Suche kann diese Ähnlichkeit erkennen, obwohl die Formulierungen nicht identisch sind.
Was passiert bei einer Suche?
Wenn du eine Frage stellst, wird auch diese Frage in einen Vektor umgewandelt. Das System vergleicht ihn mit den Vektoren deiner Dokumentabschnitte. Dabei wird berechnet, welche Abschnitte dem Suchvektor besonders ähnlich sind.
Ein wichtiger Unterschied: Der Vektor ersetzt den Originaltext nicht. Er hilft beim Finden. Für die Antwort benötigt die KI weiterhin den eigentlichen Text des gefundenen Abschnitts.
Die wichtigsten RAG-Parameter
Eine gute RAG-Suche hängt nicht allein davon ab, ob eine Vektordatenbank vorhanden ist. Auch die Aufteilung der Texte, die Anzahl der Treffer und die Einstellungen des Suchalgorithmus beeinflussen das Ergebnis.
TopK: Wie viele Textabschnitte werden zurückgegeben?
TopK ist einer der wichtigsten Parameter. Er legt fest, wie viele Treffer die Suche zurückgeben soll.
Angenommen, du fragst wieder nach der Kündigungsfrist und die Suche findet folgende Abschnitte:
- Die konkrete Kündigungsfrist im Vertrag
- Eine allgemeine Erklärung zu Kündigungen
- Einen Abschnitt zur Vertragsverlängerung
- Einen Abschnitt zu den Zahlungsbedingungen
Bei TopK = 1 wird nur der beste gefundene Treffer ausgewählt.
Bei TopK = 3 erhält das System drei Treffer. Dadurch kann es mehr Kontext berücksichtigen, etwa wenn eine weitere Passage eine Ausnahme von der allgemeinen Regel enthält.
Bei TopK = 10 stehen bis zu zehn Abschnitte zur Verfügung. Das kann hilfreich sein, wenn eine Frage mehrere Dokumente oder komplexe Zusammenhänge betrifft. Es erhöht aber auch die Menge an Text, die anschließend verarbeitet werden muss.
Mehr Treffer sind deshalb nicht automatisch besser. Ein zu kleiner Wert kann wichtige Informationen übersehen. Ein zu großer Wert kann irrelevante Abschnitte in den Kontext bringen und die Antwort verwässern. Gerade bei kleinen KI Modellen spielt das eine große Rolle. Für Noxidox ist TopK deshalb ein wichtiger Stellhebel, um die Qualität der Antworten mit den begrenzten Ressourcen des Geräts in Einklang zu bringen. Deshalb kann dieser Parameter direkt in den Einstellungen der App gesetzt werden.
efSearch: Wie gründlich wird gesucht?
efSearch beeinflusst, wie viele Kandidaten während einer Suche berücksichtigt werden.
Ein höherer Wert ermöglicht eine gründlichere Suche und kann die Trefferqualität verbessern. Gleichzeitig kann die Suche mehr Zeit und Rechenleistung benötigen.
Ein niedrigerer Wert kann schneller sein, birgt aber ein höheres Risiko, passende Vektoren zu übersehen.
Dabei ist wichtig: efSearch ist nicht gleich TopK. TopK bestimmt, wie viele Ergebnisse zurückgegeben werden sollen. efSearch beeinflusst, wie gründlich der Algorithmus nach diesen Ergebnissen sucht.
Die besondere Herausforderung bei Apple Intelligence: 4.096 Tokens
Bei der Entwicklung meiner App Noxidox spielt noch eine weitere Einschränkung eine große Rolle: das Kontextfenster des On-Device-Sprachmodells von Apple Intelligence.
Apples Foundation Models Framework stellt für das On-Device-Modell ein Kontextfenster von 4.096 Tokens bereit. Das Kontextfenster ist der Textumfang, den das Modell innerhalb dieser Sitzung berücksichtigen kann. Ein Token ist dabei nicht unbedingt ein vollständiges Wort. Wörter können in mehrere Tokens zerfallen, und die genaue Anzahl hängt unter anderem von Sprache und Schreibweise ab.
Die Zahl 4.096 klingt zunächst nach viel. Für eine KI, die umfangreiche Dokumente verarbeiten soll, ist diese Zahl aber sehr schnell erreicht. Denn leider steht das gesamte Kontextfenster nicht allein für die gefundenen Dokumentabschnitte zur Verfügung.
Folgendes muss auch mit in den Kontext:
- Die Systemanweisungen, die das Verhalten der KI steuert
- Die eigentliche Frage des Nutzers
- Die aus der Suche übernommenen Textabschnitte
- Weitere Anweisungen und gegebenenfalls Tool-Definitionen
- Die von der KI erzeugte Antwort
- Der bereits vorhandene Gesprächsverlauf
Die Eingabe und die Ausgabe teilen sich also dasselbe begrenzte Budget.
Wie die einzelnen Bausteine in Noxidox zusammenspielen
Damit die Zusammenhänge greifbarer werden, schauen wir uns eine typische Suche in Noxidox an. Du importierst mehrere PDF-Dokumente und möchtest wissen: „Welche Fristen muss ich bei meinen laufenden Verträgen beachten?“ Hinter dieser scheinbar einfachen Frage laufen mehrere Schritte ab.
Schritt 1 – Dokumente vorbereiten
Die Dokumente werden ausgelesen. Bei gescannten PDFs ist zunächst eine Texterkennung OCR notwendig. Anschließend wird der Text in die kleinen Abschnitte, Chunks zerlegt.
Schritt 2 – Vektoren erstellen
Die Textabschnitte werden durch ein geeignetes Embedding-Verfahren in Vektoren umgewandelt. Die Vektoren werden zusammen mit den Zuordnungen zu ihren ursprünglichen Textabschnitten gespeichert.
Schritt 3 – Den Suchindex nutzen
Die Frage wird ebenfalls in einen Vektor umgewandelt. Der Index hilft dabei, die inhaltlich ähnlichen Textabschnitte effizient zu finden. Schritt 4 – Die besten Treffer auswählen
Die gefundenen Abschnitte werden entsprechend ihrer Relevanz ausgewählt. TopK und weitere Filter beeinflussen, welche Kandidaten in die nächste Phase gelangen.
Schritt 5 – Das Tokenbudget beachten
Bevor die Anfrage an Apple Intelligence geht, muss die Menge der ausgewählten Informationen in das verfügbare Kontextfenster passen. Dabei muss weiterhin auch die Anweisungen und die geplante Antwort berücksichtigt werden.
Schritt 6 – Eine Antwort erzeugen
Apple Intelligence erhält die Frage und die ausgewählten Textstellen. Das Sprachmodell formuliert daraus eine Antwort, die sich auf die bereitgestellten Informationen stützen kann.
So muss das Modell nicht alle importierten Dokumente gleichzeitig lesen. Es erhält gezielt die Textstellen, die für die aktuelle Frage relevant sind. Wichtig ist dabei: Auch ein gutes RAG-System kann falsche oder unvollständige Antworten erzeugen. Wenn die Suche eine wichtige Passage nicht findet oder ein Dokument missverständlich formuliert ist, kann die KI das nicht zuverlässig ausgleichen. Bei wichtigen Entscheidungen sollten die Originaldokumente deshalb weiterhin überprüft werden.
Warum ich bei Noxidox auf lokale Verarbeitung setze
Für mich ist RAG nicht nur eine Frage der Suchqualität. Es geht auch darum, wie persönliche Dokumente verarbeitet werden.
Verträge, Notizen und andere private Unterlagen enthalten häufig Informationen, die nicht unnötig an externe Dienste übertragen werden sollten. Deshalb verfolge ich bei Noxidox den Ansatz, die KI-Suche auf dem Apple-Gerät direkt auszuführen. Die Kombination aus der lokalen Verarbeitung und einer gezielten Suche hat allerdings ihren Preis: Speicher, Rechenleistung und das begrenzte Kontextfenster müssen sorgfältig genutzt werden.
Genau deshalb sind eine durchdachte Aufteilung der Dokumente, eine effiziente Vektorsuche und ein kontrolliertes Tokenbudget so wichtig.
RAG ist also nicht einfach ein Trick, um eine KI mit mehr Text zu füttern. Es ist eine Methode, um Wissen gezielt bereitzustellen und damit Sprachmodelle auch bei umfangreichen Dokumentensammlungen sinnvoll einzusetzen.
Weiterführende technische Informationen
Apple Developer Documentation: Managing the context window
Apple Technical Note: TN3193 – Managing the on-device foundation model’s context window
Kommentare
Noch keine Kommentare. Schreib den ersten!