Ein Tutorial beschreibt detailliert den Aufbau einer multimodalen Retrieval-Augmented Generation (RAG)-Pipeline in Python, die sowohl in Texten als auch in Bildern aus komplexen Dokumenten suchen und darüber schlussfolgern kann. Das Prinzip zielt auf PDFs ab, die Prosa, Tabellen und Grafiken mischen – Formate, in denen ein klassischer RAG laut dem Text an seine Grenzen stößt.
RAG besteht darin, Auszüge aus einem Dokument abzurufen und sie an ein Sprachmodell zu übergeben, bevor es seine Antwort formuliert. Auf reinen Text angewendet, liefert das Verfahren gute Ergebnisse. Eine nur auf Text basierende Aufteilung zerstört jedoch das Tabellenlayout und lässt Bilder außen vor, sodass das System aus einer unvollständigen Sicht des Dokuments antwortet. Die beschriebene Pipeline behandelt Bilder stattdessen wie Text als abfragbare Objekte.
Die Umsetzung stützt sich auf LangChain, die Bibliothek unstructured und die OpenAI-API. Das Tutorial beschreibt vier Schritte: das Dokument analysieren, die Bilder zusammenfassen, alles speichern und das System abfragen. Das Systempaket poppler-utils, eine Systemabhängigkeit, wird von unstructured benötigt, um Bilder aus PDFs zu extrahieren.
Text und Bilder trennen
Die Funktion partition_pdf() von unstructured liest das Dokument und klassifiziert jedes Element nach Typ: Absätze, Tabellen und eingebettete Bilder. Die Bilder werden in einem eigenen Ordner gespeichert, während die Textblöcke nach Überschriften zu Fragmenten von maximal 4.000 Zeichen zusammengefasst werden. Eine Schleife trennt anschließend die Textfragmente von den Bildpfaden.
Eine klassische Vektordatenbank kann ein Bild nicht direkt indizieren. Daher wird jedes Bild an GPT-4o übergeben, mit der Anweisung „Describe this image in detail for use in a search system », um eine detaillierte Beschreibung zu erhalten, die als abfragbarer Ersatz dient. Das Tutorial weist auf Kosten in diesem Schritt hin: Jedes Bild löst einen API-Aufruf aus. Für Dokumente mit vielen Logos oder Icons schlägt es vor, die kleinsten Bilder vor dieser Behandlung herauszufiltern.
Eine zweistufige Speicherung
Die Architektur basiert auf einem MultiVectorRetriever, der zwei Speicherbereiche verwaltet. Der erste, eine Chroma-Vektordatenbank, enthält die Textfragmente und Bildbeschreibungen, die mit dem Embedding-Modell text-embedding-3-small in Vektoren umgewandelt wurden. Der zweite, ein Dokumentenspeicher im Arbeitsspeicher, behält den Rohinhalt. Jeder Eintrag ist über eine eindeutige ID mit seinem Pendant verknüpft. Nachdem die Suche in den Beschreibungen durchgeführt wurde, findet das System so das ursprüngliche Textfragment oder die Bilddatei.
Bei einer Abfrage wird die Frage selbst vektorisiert und mit den indizierten Elementen verglichen. Die Textfragmente werden unverändert übergeben, während die gefundenen Bilder geöffnet und dann in Base64 kodiert werden – ein Textformat, das es ermöglicht, sie der Anfrage beizufügen. Das Ganze wird an GPT-4o gesendet, das eine Antwort auf Basis beider Inhaltstypen erzeugt. Das Tutorial veranschaulicht den Ansatz mit der Frage „What does the revenue chart show for Q3? », die daher direkt als Beispiel verwendet werden kann.
Weiterentwicklungsmöglichkeiten
Der Autor erwähnt mehrere mögliche Erweiterungen: einen Re-Ranking-Schritt hinzufügen, um die Suchgenauigkeit zu verbessern, die Chroma-Datenbank für den Produktionseinsatz auf der Festplatte zu speichern oder Vision-Sprach-Modelle wie ColPali zu erkunden, die Dokumentseiten direkt als Bilder integrieren und so den Analyseschritt überflüssig machen.
