Aufbau eines multimodalen RAG-Systems mit Elasticsearch: Die Geschichte von Gotham City

Elasticsearch verfügt über native Integrationen mit den branchenführenden Gen-AI-Tools und -Anbietern. Sehen Sie sich unsere Webinare zu den Themen „RAG-Grundlagen“ oder zum „Erstellen produktionsreifer Apps“ mit der Elastic-Vektordatenbank an.

Um die besten Suchlösungen für Ihren Anwendungsfall zu entwickeln, starten Sie jetzt eine kostenlose Cloud-Testversion oder testen Sie Elastic auf Ihrem lokalen Rechner.

In diesem Blog erfahren Sie, wie Sie mit Elasticsearch eine multimodale RAG-Pipeline (Retrieval-Augmented Generation) erstellen. Wir werden untersuchen, wie Sie ImageBind nutzen können, um Einbettungen für verschiedene Datentypen zu generieren, darunter Text, Bilder, Audio und Tiefenkarten. Sie erfahren auch, wie Sie diese Einbettungen mithilfe von dense_vector und k-NN-Suche effizient in Elasticsearch speichern und abrufen können. Abschließend integrieren wir ein großes Sprachmodell (LLM), um die abgerufenen Beweise zu analysieren und einen umfassenden Abschlussbericht zu erstellen.

Wie funktioniert die multimodale RAG-Pipeline?

1. Hinweise sammeln → Bilder, Audio, Texte und Tiefenkarten vom Tatort in Gotham.
2. Einbettungen generieren → Jede Datei wird mithilfe des multimodalen Modells ImageBind in einen Vektor konvertiert.
3. Indizierung in Elasticsearch → Die Vektoren werden für einen effizienten Abruf gespeichert.
4. Suche nach Ähnlichkeit → Bei einem neuen Hinweis werden die ähnlichsten Vektoren abgerufen.
5. Das LLM analysiert die Beweise → Ein GPT-4-Modell synthetisiert die Antwort und identifiziert den Verdächtigen!

Eingesetzte Technologien

• ImageBind → Generiert einheitliche Einbettungen für verschiedene Modalitäten.
• Elasticsearch → Ermöglicht eine schnelle und effiziente Vektorsuche.
• LLM (GPT-4, OpenAI) → Analysiert die Beweise und erstellt einen Abschlussbericht.

Für wen ist dieser Blog?

• Elastic-Benutzer, die an der multimodalen Vektorsuche interessiert sind.
• Entwickler, die multimodales RAG in der Praxis verstehen möchten.
• Jeder, der nach skalierbaren Lösungen zur Analyse von Daten aus mehreren Quellen sucht.

Voraussetzungen für multimodale RAG: Aufbau der Umgebung

Um das Verbrechen in Gotham City aufzuklären, müssen Sie Ihre Technologieumgebung einrichten. Folgen Sie dieser Schritt-für-Schritt-Anleitung:

1. Technische Voraussetzungen

2. Einrichten des Projekts

Alle Ermittlungsmaterialien sind auf GitHub verfügbar und wir werden für dieses interaktive Erlebnis zur Aufklärung von Verbrechen Jupyter Notebook (Google Colab) verwenden. Befolgen Sie diese Schritte, um zu beginnen:

Einrichten mit Jupyter Notebook (Google Colab)

1. Zugriff auf das Notebook

• Öffnen Sie unser gebrauchsfertiges Google Colab-Notizbuch: Multimodales RAG mit Elasticsearch.
• Dieses Notizbuch enthält den gesamten Code und alle Erklärungen, die Sie zum Mitmachen benötigen.

2. Klonen Sie das Repository

3. Abhängigkeiten installieren

4. Anmeldeinformationen konfigurieren

Hinweis: Das ImageBind-Modell (~2 GB) wird beim ersten Ausführen automatisch heruntergeladen.

Nachdem nun alles eingerichtet ist, können wir in die Details eintauchen und das Verbrechen aufklären!

Einleitung: Die Kriminalität in Gotham City

In einer regnerischen Nacht erschüttert ein schockierendes Verbrechen die Stadt Gotham City. Commissioner Gordon braucht Ihre Hilfe, um das Geheimnis zu lüften. Hinweise sind über verschiedene Formate verstreut: verschwommene Bilder, mysteriöse Audiodaten, verschlüsselte Texte und sogar Tiefenkarten. Sind Sie bereit, die fortschrittlichste KI-Technologie zur Lösung des Falls einzusetzen?

In diesem Blog werden Sie Schritt für Schritt durch den Aufbau eines multimodalen RAG-Systems (Retrieval-Augmented Generation) geführt, das verschiedene Datentypen (Bilder, Audio, Texte und Tiefenkarten) in einem einzigen Suchraum vereint. Wir werden ImageBind verwenden, um multimodale Einbettungen zu generieren, Elasticsearch , um diese Einbettungen zu speichern und abzurufen, und ein Large Language Model (LLM), um die Beweise zu analysieren und einen Abschlussbericht zu erstellen.

Grundlagen: Multimodale RAG-Architektur

Was ist ein multimodaler RAG?

Der Aufstieg von Retrieval-Augmented Generation (RAG) Multimodal revolutioniert die Art und Weise, wie wir mit KI-Modellen interagieren. Traditionell arbeiten RAG-Systeme ausschließlich mit Text und rufen relevante Informationen aus Datenbanken ab, bevor sie Antworten generieren. Die Welt beschränkt sich jedoch nicht nur auf Text– auch Bilder, Videos und Audiodateien enthalten wertvolles Wissen. Aus diesem Grund gewinnen multimodale Architekturen an Bedeutung, die es KI-Systemen ermöglichen, Informationen aus verschiedenen Formaten zu kombinieren, um umfassendere und präzisere Antworten zu erhalten.

Drei Hauptansätze für multimodale RAG

Zur Implementierung eines multimodalen RAG werden üblicherweise drei Strategien verwendet. Jeder Ansatz hat seine eigenen Vorteile und Einschränkungen, abhängig vom Anwendungsfall:

1. Gemeinsamer Vektorraum

Daten aus verschiedenen Modalitäten werden mithilfe multimodaler Modelle wie ImageBind in einen gemeinsamen Vektorraum abgebildet. Dadurch können Textabfragen Bilder, Videos und Audiodateien ohne explizite Formatkonvertierung abrufen.

Vorteile:

• Ermöglicht modalübergreifenden Abruf ohne explizite Formatkonvertierung.
• Bietet eine reibungslose Integration zwischen verschiedenen Modalitäten und ermöglicht den direkten Abruf von Text, Bild, Audio und Video.
• Skalierbar für verschiedene Datentypen, daher nützlich für groß angelegte Abrufanwendungen.

Nachteile:

• Für das Training sind große multimodale Datensätze erforderlich, die möglicherweise nicht immer verfügbar sind.
• Der gemeinsame Einbettungsraum kann zu einer semantischen Drift führen, bei der die Beziehungen zwischen Modalitäten nicht perfekt erhalten bleiben.
• Je nach Datensatzverteilung kann eine Verzerrung in multimodalen Modellen die Abrufgenauigkeit beeinträchtigen.

2. Einzelne geerdete Modalität

Alle Modalitäten werden vor dem Abruf in ein einziges Format, normalerweise Text, konvertiert. Beispielsweise werden Bilder durch automatisch generierte Bildunterschriften beschrieben und Audiodaten in Text transkribiert.

Vorteile:

• Vereinfacht das Auffinden, da alles in eine einheitliche Textdarstellung umgewandelt wird.
• Funktioniert gut mit vorhandenen textbasierten Suchmaschinen, sodass keine spezielle multimodale Infrastruktur erforderlich ist.
• Kann die Interpretierbarkeit verbessern, da die abgerufenen Ergebnisse in einem für Menschen lesbaren Format vorliegen.

Nachteile:

• Informationsverlust: Bestimmte Details (z. B. räumliche Beziehungen in Bildern, Ton in Audio) werden in Textbeschreibungen möglicherweise nicht vollständig erfasst.
• Abhängig von der Untertitel-/Transkriptionsqualität: Fehler in automatischen Anmerkungen können die Abrufeffektivität verringern.
• Nicht optimal für rein visuelle oder akustische Abfragen, da beim Konvertierungsprozess möglicherweise wichtiger Kontext entfernt wird.

3. Getrennte Abholung

Behält für jede Modalität unterschiedliche Modelle bei. Das System führt für jeden Datentyp eine separate Suche durch und führt die Ergebnisse später zusammen.

Vorteile:

• Ermöglicht eine benutzerdefinierte Optimierung pro Modalität und verbessert so die Abrufgenauigkeit für jeden Datentyp.
• Geringere Abhängigkeit von komplexen multimodalen Modellen, wodurch die Integration vorhandener Abrufsysteme erleichtert wird.
• Bietet eine detaillierte Kontrolle über die Rangfolge und Neubewertung, da Ergebnisse aus verschiedenen Modalitäten dynamisch kombiniert werden können.

Nachteile:

• Erfordert eine Zusammenführung der Ergebnisse, wodurch der Abruf- und Rankingprozess komplexer wird.
• Kann zu inkonsistenten Antworten führen, wenn unterschiedliche Modalitäten widersprüchliche Informationen zurückgeben.
• Höherer Rechenaufwand , da für jede Modalität unabhängige Suchvorgänge durchgeführt werden, was die Verarbeitungszeit verlängert.

Unsere Wahl: Gemeinsamer Vektorraum mit ImageBind

Unter diesen Ansätzen haben wir uns für den Shared Vector Space entschieden, eine Strategie, die perfekt auf die Anforderungen effizienter multimodaler Suchen abgestimmt ist. Unsere Implementierung basiert auf ImageBind, einem Modell, das mehrere Modalitäten (Text, Bild, Audio und Video) in einem gemeinsamen Vektorraum darstellen kann. Dies ermöglicht uns:

• Führen Sie modalübergreifende Suchen zwischen verschiedenen Medienformaten durch, ohne alles in Text konvertieren zu müssen.
• Verwenden Sie ausdrucksstarke Einbettungen , um Beziehungen zwischen verschiedenen Modalitäten zu erfassen.
• Sorgen Sie für Skalierbarkeit und Effizienz, indem Sie optimierte Einbettungen für einen schnellen Abruf in Elasticsearch speichern.

Durch die Übernahme dieses Ansatzes haben wir eine robuste multimodale Suchpipeline erstellt, bei der eine Textabfrage ohne zusätzliche Vorverarbeitung direkt Bilder oder Audio abrufen kann. Diese Methode erweitert die praktischen Anwendungen von der intelligenten Suche in großen Repositorien bis hin zu fortschrittlichen multimodalen Empfehlungssystemen.

Die folgende Abbildung veranschaulicht den Datenfluss innerhalb der multimodalen RAG-Pipeline und hebt den Indexierungs-, Abruf- und Antwortgenerierungsprozess basierend auf multimodalen Daten hervor:

Wie funktioniert der Einbettungsraum?

Traditionell stammen Texteinbettungen aus Sprachmodellen (z. B. BERT, GPT). Mit nativen multimodalen Modellen wie ImageBind von Meta AI verfügen wir nun über ein Grundgerüst, das Vektoren für mehrere Modalitäten generiert:

• Text: Sätze und Absätze werden in Vektoren derselben Dimension umgewandelt.
• Bilder (Sehen): Pixel werden in denselben dimensionalen Raum abgebildet, der für Text verwendet wird.
• Audio: Tonsignale werden in Einbettungen umgewandelt, die mit Bildern und Text vergleichbar sind.
• Tiefenkarten: Tiefendaten werden verarbeitet und führen ebenfalls zu Vektoren.

Somit kann jeder Hinweis (Text, Bild, Audio, Tiefe) mithilfe von Vektorähnlichkeitsmetriken wie der Kosinusähnlichkeit mit jedem anderen verglichen werden. Wenn eine lachende Audioprobe und ein Bild des Gesichts eines Verdächtigen in diesem Raum „nahe beieinander“ liegen, können wir auf eine gewisse Korrelation schließen (z. B. dieselbe Identität).

Phase 1 – Hinweise am Tatort sammeln

Bevor wir die Beweise analysieren, müssen wir sie sammeln. Das Verbrechen in Gotham hat Spuren hinterlassen, die in Bildern, Audiodateien, Texten und sogar Tiefendaten verborgen sein könnten. Lassen Sie uns diese Hinweise organisieren, um sie in unser System einzuspeisen.

Was haben wir?

Commissioner Gordon hat uns die folgenden Akten mit Beweismaterial geschickt, das in vier verschiedenen Modalitäten am Tatort gesammelt wurde:

Streckenbeschreibung und Modalität

a) Bilder (2 Fotos)

• crime_scene1.jpg, crime_scene2.jpg → Fotos vom Tatort. Zeigt verdächtige Spuren auf dem Boden.
• suspect_spotted.jpg → Bild einer Überwachungskamera, das eine Silhouette zeigt, die vom Tatort wegläuft.

b) Audio (1 Aufnahme)

• joker_laugh.wav → Ein Mikrofon in der Nähe des Tatorts fing ein unheimliches Lachen ein.

c) Text (1 Nachricht)

• Riddle.txt, note2.txt → Am Tatort wurden einige mysteriöse Notizen gefunden, die möglicherweise vom Verbrecher hinterlassen wurden.

d) Tiefe (1 Tiefenkarte)

• depth_suspect.png → Eine Überwachungskamera mit Tiefensensor hat einen Verdächtigen in einer nahegelegenen Gasse erfasst.
• jdancing-depth.png → Eine Überwachungskamera mit Tiefensensor hat einen Verdächtigen aufgenommen, der die U-Bahn-Station entlangging.

Diese Beweisstücke liegen in unterschiedlichen Formaten vor und können nicht direkt auf die gleiche Weise analysiert werden. Wir müssen sie in Einbettungen umwandeln – numerische Vektoren, die einen kreuzmodalen Vergleich ermöglichen.

Dateiorganisation

Bevor wir mit der Verarbeitung beginnen, müssen wir sicherstellen, dass alle Hinweise im Datenverzeichnis ordnungsgemäß organisiert sind, damit die Pipeline reibungslos läuft.

Erwartete Verzeichnisstruktur:

Code zur Überprüfung der Hinweisorganisation

Bevor wir fortfahren, stellen wir sicher, dass sich alle erforderlichen Dateien am richtigen Speicherort befinden.

Ausführen der Datei

Erwartete Ausgabe (wenn alle Dateien korrekt sind):

Erwartete Ausgabe (falls eine Datei fehlt):

Dieses Skript hilft, Fehler zu vermeiden, bevor wir mit der Generierung von Einbettungen und deren Indizierung in Elasticsearch beginnen.

Phase 2 – Organisieren der Beweise

Einbettungen mit ImageBind generieren

Um die Hinweise zu vereinheitlichen, müssen wir sie in Einbettungen umwandeln – Vektordarstellungen, die die Bedeutung jeder Modalität erfassen. Wir verwenden ImageBind, ein Modell von Meta AI, das Einbettungen für verschiedene Datentypen (Bilder, Audio, Text und Tiefenkarten) innerhalb eines gemeinsamen Vektorraums generiert.

Wie funktioniert ImageBind?

Um verschiedene Arten von Beweisen (Bilder, Audio, Text und Tiefenkarten) zu vergleichen, müssen wir sie mithilfe von ImageBind in numerische Vektoren umwandeln. Dieses Modell ermöglicht die Konvertierung aller Eingabetypen in dasselbe Einbettungsformat und ermöglicht so modalitätsübergreifende Suchen .

Nachfolgend finden Sie einen optimierten Code (src/embedding_generator.py), um Einbettungen für alle Eingabetypen unter Verwendung der entsprechenden Prozessoren für jede Modalität zu generieren:

Ein Tensor ist eine grundlegende Datenstruktur im maschinellen Lernen und Deep Learning, insbesondere bei der Arbeit mit Modellen wie ImageBind. In unserem Kontext:

Hier stellt der Tensor die Eingabedaten (Bild, Audio oder Text) dar, die in ein mathematisches Format konvertiert werden, das das Modell verarbeiten kann. Speziell:

• Für Bilder: Der Tensor stellt das Bild als mehrdimensionale Matrix numerischer Werte dar (Pixel, organisiert nach Höhe, Breite und Farbkanälen).
• Für Audio: Der Tensor stellt Schallwellen als eine Abfolge von Amplituden über die Zeit dar.
• Für Text: Der Tensor stellt Wörter oder Token als numerische Vektoren dar.

Testen der Einbettungsgenerierung:

Testen wir unsere Einbettungsgenerierung mit dem folgenden Code. Speichern Sie es in 02-stage/test_embedding_generation.py und führen Sie es mit diesem Befehl aus:

Erwartete Ausgabe:

Nun wurde das Bild in einen 1024-dimensionalen Vektor umgewandelt.

Phase 3 – Speicherung und Suche in Elasticsearch

Nachdem wir nun die Einbettungen für die Beweise generiert haben, müssen wir sie in einer Vektordatenbank speichern, um effiziente Suchvorgänge zu ermöglichen. Hierzu verwenden wir Elasticsearch, das dichte Vektoren (dense_vector) unterstützt und Ähnlichkeitssuchen ermöglicht.

Dieser Schritt besteht aus zwei Hauptprozessen:

• Indizierung der Einbettungen → Speichert die generierten Vektoren in Elasticsearch.
• Ähnlichkeitssuche → Ruft die ähnlichsten Datensätze zu einem neuen Beweisstück ab.

Indizierung der Beweise in Elasticsearch

Jedes von ImageBind verarbeitete Beweisstück (Bild, Audio, Text oder Tiefe) wird in einen 1024-dimensionalen Vektor umgewandelt. Wir müssen diese Vektoren in Elasticsearch speichern, um zukünftige Suchen zu ermöglichen.

Der folgende Code (src/elastic_manager.py) erstellt einen Index in Elasticsearch und konfiguriert die Zuordnung zum Speichern der Einbettungen.

Ausführen der Indizierung

Lassen Sie uns nun ein Beweisstück indizieren, um den Prozess zu testen.

Erwartete Ausgabe in Elasticsearch (Zusammenfassung des indizierten Dokuments):

Um alle multimodalen Beweise zu indizieren, führen Sie bitte den folgenden Python-Befehl aus:

Jetzt werden die Beweise in Elasticsearch gespeichert und können bei Bedarf abgerufen werden.

Überprüfen des Indizierungsprozesses

Nachdem wir das Indexierungsskript ausgeführt haben, überprüfen wir, ob alle unsere Beweise korrekt in Elasticsearch gespeichert wurden. Sie können die Dev Tools von Kibana verwenden, um einige Überprüfungsabfragen auszuführen:

1. Überprüfen Sie zunächst, ob der Index erstellt wurde:

2. Überprüfen Sie dann die Anzahl der Dokumente pro Modalität:

3. Untersuchen Sie abschließend die indizierte Dokumentstruktur:

Erwartete Ergebnisse:

• Ein Index mit dem Namen „multimodal_content“ sollte vorhanden sein.
• Etwa 7 Dokumente, verteilt auf verschiedene Modalitäten (Bild, Audio, Text, Tiefe).
• Jedes Dokument sollte die Felder „Einbettung“, „Modalität“, „Beschreibung“, „Metadaten“ und „content_path“ enthalten.

Dieser Überprüfungsschritt stellt sicher, dass unsere Beweisdatenbank ordnungsgemäß eingerichtet ist, bevor wir mit der Ähnlichkeitssuche fortfahren.

Suche nach ähnlichen Beweisen in Elasticsearch

Nachdem die Beweise nun indiziert wurden, können wir Suchen durchführen, um die Datensätze zu finden, die einem neuen Hinweis am ähnlichsten sind. Diese Suche verwendet Vektorähnlichkeit , um die ähnlichsten Datensätze im Einbettungsraum zurückzugeben.

Der folgende Code führt diese Suche durch.

Testen der Suche – Verwenden von Audio als Abfrage für multimodale Ergebnisse

Testen wir nun die Beweissuche anhand einer verdächtigen Audiodatei. Wir müssen auf die gleiche Weise eine Einbettung für die Datei generieren und nach ähnlichen Einbettungen suchen:

Erwartete Ausgabe im Terminal:

Jetzt können wir die gefundenen Beweise analysieren und ihre Relevanz für den Fall bestimmen.

Mehr als Audio – Multimodale Suchen erkunden

Rollentausch: Jede Modalität kann eine „Frage“ sein

In unserem multimodalen RAG- System ist jede Modalität eine potenzielle Suchanfrage. Lassen Sie uns über das Audiobeispiel hinausgehen und untersuchen, wie andere Datentypen Untersuchungen einleiten können.

1. Suche nach Text (Entzifferung der Notiz des Täters)

Szenario: Sie haben eine verschlüsselte Textnachricht gefunden und möchten entsprechende Beweise finden.

Erwartete Ergebnisse:

2. Bildersuche (Verfolgung des verdächtigen Tatorts)

Szenario: Ein neuer Tatort (crime_scene2.jpg) muss mit anderen Beweisen verglichen werden.

Ausgabe:

3. Tiefenkartensuche (3D-Verfolgung)

Szenario: Eine Tiefenkarte (jdancing-depth.png) deckt Bildfluchtmuster auf.

Ausgabe

Warum ist das wichtig?

Jede Modalität weist einzigartige Verbindungen auf:

• Text → Sprachliche Muster des Verdächtigen.
• Bilder → Erkennung von Orten und Objekten.
• Tiefe → 3D- Szenenrekonstruktion.

Jetzt verfügen wir in Elasticsearch über eine strukturierte Beweisdatenbank, die es uns ermöglicht,multimodale Beweise effizient zu speichern und abzurufen.

Zusammenfassung unserer Aktivitäten:

• Gespeicherte multimodale Einbettungen in Elasticsearch.
• Führte Ähnlichkeitssuchen durch und fand Beweise im Zusammenhang mit neuen Hinweisen.
• Die Suche wurde mit einer verdächtigen Audiodatei getestet, um sicherzustellen, dass das System ordnungsgemäß funktioniert.

Nächster Schritt: Wir werden ein LLM (Large Language Model) verwenden, um die abgerufenen Beweise zu analysieren und einen Abschlussbericht zu erstellen.

Stufe 4 – Die Punkte mit dem LLM verbinden

Nachdem die Beweise nun in Elasticsearch indiziert wurden und anhand der Ähnlichkeit abgerufen werden können, benötigen wir ein LLM (Large Language Model), um sie zu analysieren und einen Abschlussbericht zu erstellen, den wir an Kommissar Gordon senden können. Der LLM ist dafür verantwortlich , Muster zu erkennen, Hinweise zu verknüpfen und auf Grundlage der gefundenen Beweise einen möglichen Verdächtigen vorzuschlagen .

Für diese Aufgabe verwenden wir GPT-4 Turbo und formulieren eine detaillierte Eingabeaufforderung , damit das Modell die Ergebnisse effizient interpretieren kann.

LLM-Integration

Um das LLM in unser System zu integrieren, haben wir die LLMAnalyzer- Klasse (src/llm_analyzer.py) erstellt, die die abgerufenen Beweise von Elasticsearch empfängt und einen forensischen Bericht erstellt, der diese Beweise als Eingabekontext verwendet.

Temperatureinstellung in der LLM-Analyse:

Für unser forensisches Analysesystem verwenden wir eine moderate Temperatur von 0,5. Diese ausgewogene Einstellung wurde gewählt, weil:

• Es stellt einen Mittelweg zwischen deterministischen (zu starren) und stark zufälligen Ergebnissen dar;
• Bei 0,5 behält das Modell genügend Struktur bei, um logische und vertretbare forensische Schlussfolgerungen zu liefern;
• Diese Einstellung ermöglicht es dem Modell, Muster zu erkennen und Verbindungen herzustellen, während es gleichzeitig innerhalb angemessener forensischer Analyseparameter bleibt.
• Es gleicht den Bedarf an konsistenten, zuverlässigen Ergebnissen mit der Fähigkeit aus, aufschlussreiche Analysen zu erstellen.

Diese moderate Temperatureinstellung trägt dazu bei, dass unsere forensische Analyse sowohl zuverlässig als auch aufschlussreich ist und sowohl zu starre als auch zu spekulative Schlussfolgerungen vermieden werden.

Ausführen der Beweisanalyse

Nachdem wir nun über die LLM-Integration verfügen, benötigen wir ein Skript , das alle Systemkomponenten verbindet. Dieses Skript wird:

• Suchen Sie in Elasticsearch nach ähnlichen Beweisen .
• Analysieren Sie die abgerufenen Beweise mithilfe des LLM , um einen Abschlussbericht zu erstellen.

Code: Skript zur Beweisanalyse

Erwartete LLM-Ausgabe

Fazit: Fall gelöst

Nachdem alle Hinweise gesammelt und analysiert wurden, hat das multimodale RAG-System einen Verdächtigen identifiziert: den Joker.

Durch die Kombination von Bildern, Audio, Text und Tiefenkarten in einem gemeinsamen Vektorraum mithilfe von ImageBind konnte das System Verbindungen erkennen , die manuell nicht hätten identifiziert werden können. Elasticsearch sorgte für schnelle und effiziente Suchvorgänge, während LLM die Beweise in einem klaren und schlüssigen Bericht zusammenfasste.

Die wahre Macht dieses Systems geht jedoch über Gotham City hinaus. Die multimodale RAG-Architektur öffnet Türen zu zahlreichen realen Anwendungen:

• Urbane Überwachung: Identifizierung von Verdächtigen anhand von Bild-, Audio- und Sensordaten.
• Forensische Analyse: Korrelieren von Beweisen aus mehreren Quellen zur Aufklärung komplexer Verbrechen.
• Multimedia-Empfehlung: Erstellen von Empfehlungssystemen , die multimodale Kontexte verstehen (z. B. Musikvorschläge basierend auf Bildern oder Text).
• Social-Media-Trends: Erkennen von Trendthemen in verschiedenen Datenformaten.

Nachdem Sie nun gelernt haben, wie man ein multimodales RAG-System erstellt, warum testen Sie es nicht mit Ihren eigenen Hinweisen?

Teilen Sie Ihre Entdeckungen mit uns und helfen Sie der Community , im Bereich der multimodalen KI voranzukommen!

Besonderer Dank

Ich möchte Adrian Cole für seinen wertvollen Beitrag und seine Überprüfung während des Prozesses der Definition der Bereitstellungsarchitektur dieses Codes danken.

Referenzen

• Erstellen Sie ein multimodales Bildabrufsystem mithilfe der KNN-Suche und CLIP-Einbettungen
• k-Nearest-Neighbor (kNN)-Suche
• Offizielle PyTorch-Dokumentation zu Tensoren
• ImageBind: eine neue Möglichkeit, KI über alle Sinne hinweg zu „vernetzen“

Häufige Fragen