voyage-multimodal-3: All-in-One-Embedding-Modell für Text, Bilder und Screenshots

 (blog.voyageai.com)
4 Punkte von GN⁺ 2024-11-18 | 1 Kommentare | Auf WhatsApp teilen
  • Das von Voyage AI vorgestellte voyage-multimodal-3 ist ein Modell für RAG und semantische Suche, das gemischte Wissensdatenbanken aus Text und Bildern mit einem einzigen Embedding-Modell durchsuchbar machen soll
  • Der zentrale Unterschied ist, dass sich Materialien, bei denen Layout-Informationen wichtig sind – etwa PDFs, Folien, Tabellen, Abbildungen oder Dokument-Screenshots – ohne Dokument-Parsing vektorisieren lassen
  • Um die Grenzen gemischt-modaler Suche bei CLIP-basierten Modellen zu verringern, verarbeitet es Text- und visuelle Informationen im selben Transformer-Encoder und bewahrt die Kontextbeziehungen in Eingaben mit gemischten Modalitäten
  • Auf 20 multimodalen Such-Datensätzen zeigte es im Schnitt eine um 19,63 % höhere Suchgenauigkeit als das nächstbeste multimodale Embedding-Modell und übertraf auf 34 Text-Such-Datensätzen auch OpenAI v3 large
  • Während bei CLIP-basierten Modellen die Qualität mit steigendem Screenshot-Anteil sank, zeigte voyage-multimodal-3 über alle Bereiche hinweg nur geringe Leistungseinbußen und ist damit für suchbasierte Pipelines auf Basis von Bildschirmaufnahmen praktikabel

Einsatzbereiche, auf die voyage-multimodal-3 abzielt

  • voyage-multimodal-3 ist das erste multimodale Embedding-Modell von Voyage AI und zielt auf RAG und semantische Suche in Wissensdatenbanken mit vielen visuellen Inhalten und Texten
  • Zu den Eingaben zählen Text sowie inhaltsreiche Bilder; typische Beispiele sind:
    • Text-Screenshots
    • Abbildungen und Tabellen
    • PDF-Screenshots
    • Foliensätze
    • sonstige Dokumentbilder
  • Die erzeugten Vektoren bilden nicht nur die Textbedeutung ab, sondern auch visuelle Merkmale wie Schriftgröße, Textposition und Abstände
  • Bei Dokumenten mit komplexem Layout oder mit gemischten Abbildungen und Fotos kann heuristikbasiertes Parsing zu Genauigkeitsproblemen führen; das Modell verfolgt daher den Ansatz, den Originalbildschirm direkt in Suchvektoren umzuwandeln
  • Ein Funktionsbeispiel gibt es im sample notebook

Anderer Embedding-Ansatz als bei der CLIP-Familie

  • Bestehende multimodale Embedding-Modelle wie Amazon Titan Multimodal G1, Google Vertex AI multimodal und Cohere multimodal v3 verwenden eine auf OpenAI CLIP basierende Architektur
  • Architekturen der CLIP-Familie verarbeiten verschiedene Modalitäten in unabhängigen Netzwerken
    • Bilder werden über den Vision Tower vektorisiert
    • Text wird über den Text Tower vektorisiert
    • In dieser Struktur ist es schwierig, Eingaben mit gemischtem Text und Bild in einem Durchgang zu verarbeiten
  • voyage-multimodal-3 vektorisiert beide Modalitäten direkt innerhalb desselben Transformer-Encoders
    • Text- und visuelle Merkmale werden nicht als getrennte Komponenten, sondern als Teil einer integrierten Repräsentation behandelt
    • Es handelt sich um eine Anwendung der Architektur moderner Vision-Language-Modelle auf Vektorisierung statt auf Generierung
  • Dadurch lassen sich bei gemischtem Text und Bild, Dokument-Screenshots, komplexen PDFs und annotierten Bildern die Kontextbeziehungen zwischen visuellen und textuellen Informationen gemeinsam im Vektor erfassen

Unterschiede bei Suche mit gemischten Screenshots

  • CLIP-ähnliche Modelle können wegen der Modality Gap bei gemischt-modaler Suche schlechtere Leistung zeigen
  • Im Beispiel war der dem Textfragment „I address you, members of the Seventy-Seventh Congress…“ nächstgelegene Vektor nicht der zugehörige Screenshot, sondern ein anderer Text
  • Dieses Phänomen führt zu einem Such-Bias, bei dem Textvektoren näher an irrelevanten Einträgen derselben Modalität liegen als an passenden Bildern
  • Voyage AI führte dazu ein quantitatives Experiment mit PyTorch-Dokumentation durch
    • Es wurde ein Dokumentensatz mit identischem Inhalt jeweils als normale Textzeichenfolgen und als Screenshots erstellt
    • Anschließend wurde ein gemischt-modaler Datensatz aufgebaut, der einen Teil textbasierter Dokumente mit Screenshots der übrigen Dokumente mischte
    • Der Screenshot-Anteil wurde von 0 % bis 100 % variiert
    • Jedes Modell suchte per Kosinus-Ähnlichkeit die Top-10-Ergebnisse; bewertet wurde mit NDCG@10
  • Bei CLIP-basierten Modellen sank die Suchqualität, je weiter der Screenshot-Anteil bis auf 90 % anstieg; auch wenn sämtlicher Text in Bilder umgewandelt wurde, blieb die Leistung niedrig
  • voyage-multimodal-3 zeigte bei allen Anteilen die beste Leistung und nahezu keinen allgemeinen Leistungsabfall
  • Das Ergebnis zeigt sowohl die Fähigkeit, semantische Informationen aus Screenshots in Vektoren abzubilden, als auch die Robustheit eines Ansatzes, der alle Eingabemodalitäten mit demselben Backbone verarbeitet

Evaluationsdatensätze und Vergleichsmodelle

  • Die multimodale Evaluation wurde über 3 Aufgaben mit insgesamt 20 Datensätzen durchgeführt
    • Tabellen-/Abbildungssuche: charxiv, mmtab-test, ChartQA, Chartve, FintabnetQA, PlotQA
    • Suche in Dokument-Screenshots: Energy, Healthcare Industry, Artificial Intelligence, Government Report, InfoVQA, DocVQA, ArxivQA, TabFQuad, TAT-DQA, Shift Project aus dem ViDoRe benchmark
    • Text-Foto-Suche: meme-cap, mm-imdb, winoground, docci
  • Die Standardbewertung für Textsuche wurde über 34 Datensätze in 6 Domänen durchgeführt, darunter Recht, Finanzen, Dialog, Code, Web und Technik
  • In allen Datensätzen sind die Queries Text; die Dokumente können Abbildungen, Fotos, Text, Dokument-Screenshots oder eine Kombination daraus sein
  • Vergleichsmodelle für die multimodalen Aufgaben waren:
  • Bei der Standard-Textsuche wurde mit OpenAI v3 large (text-embeddings-3-large), Cohere multimodal/English 1 v3 und voyage-3 verglichen
  • Da Cohere multimodal v3 für reinen Text Cohere English v3 (embed-english-v3.0) als Text Tower verwendet, wird in den Diagrammen zur Vermeidung von Verwechslungen nur das Label „Cohere multimodal v3“ verwendet

Ergebnisse zur Suchgenauigkeit

  • voyage-multimodal-3 erzielte über alle 20 multimodalen Such-Datensätze hinweg im Schnitt eine um 19,63 % höhere Suchgenauigkeit als das nächstbeste multimodale Embedding-Modell
  • Bei der Tabellen-/Abbildungssuche lag es vor OpenAI CLIP large, Amazon Titan Multimodal G1, Cohere multimodal v3, SigLIP So400M und ColQwen2 v0.1 jeweils um 41,44 %, 45,00 %, 43,37 %, 20,66 % und 6,14 %
  • Bei der Suche in Dokument-Screenshots lag die Leistung gegenüber denselben Vergleichsmodellen jeweils um 26,54 %, 37,68 %, 25,84 %, 35,62 % und 0,98 % höher
  • Bei der Text-Foto-Suche lag es gegenüber denselben Modellen jeweils um 6,55 %, 5,16 %, 5,86 %, 3,42 % und 10,34 % vorn
  • Bei der Standard-Textsuche war die Leistung gegenüber OpenAI v3 large um 5,13 % und gegenüber Cohere multimodal/English 1 v3 um 13,70 % höher
  • Die Genauigkeit bei der Suche in reinen Textdokumenten lag um 0,05 % über voyage-3, sodass beide Modelle nahezu gleichauf sind
  • Die vollständigen Evaluationsergebnisse sind in dieser Tabelle veröffentlicht

Einstieg und verfügbare Materialien

  • voyage-multimodal-3 ist ab dem Tag der Veröffentlichung verfügbar
  • Die ersten 200 Millionen Token sind kostenlos
  • Einstiegsmaterialien gibt es im sample notebook und in der docs
  • Wer sich für feinabgestimmte Embedding-Modelle interessiert, kann contact@voyageai.com kontaktieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-18
Meinungen auf Hacker News

  • Die zentrale Beobachtung ist einfach und intuitiv: Alle CLIP-artigen Modelle schneiden bei gemischt-modaler Suche wegen des Modality Gap zwischen den Modalitäten schlecht ab.
    So kann etwa der Vektor, der dem Satz „I address you, members of the Seventy-Seventh Congress…“ am nächsten liegt, nicht der entsprechende Screenshot sein, sondern ein anderer Text. Dadurch liegen Textvektoren im Embedding-Raum näher an irrelevanten Texten als an relevanten Bildern, und die Suchergebnisse kippen zur gleichen Modalität hin

    • Dieses Zitat ist wichtig, aber für sich genommen ist nicht klar, ob sie behaupten, dieses Problem gelöst zu haben. Es klingt so, als würden sie sagen, das neue Modell voyage-multimodal-3 identifiziere zusammenhängende Konzepte über Modalitäten hinweg.
      Wenn es einen latenten Raum gibt, der dieselbe Idee clustern kann, egal ob sie visuell oder als Text dargestellt ist, wäre das ziemlich cool. Allerdings halte ich diesen Benchmark für eine ziemlich enge Sicht auf multimodale Embeddings. Dass verwandte Textbilder und Text-Embeddings nahe beieinander liegen, ist praktisch, aber es ist schwer zu sagen, ob sich das auch auf die Relevanz anderer visueller Darstellungen ausweitet, etwa „rabbit“ und ein Foto eines Kaninchens. Für das engere Ziel, Dokumentbilder zu indexieren, könnten auch andere Verfahren ziemlich gut funktionieren. Das wirkt wie eine gute Gelegenheit für einen neuen Benchmark-Datensatz zu multimodalen Konzeptrepräsentationen jenseits des Textmediums
    • Dieses Problem könnte durch multimodal mixup gelöst werden, das verhindert, dass eine große Lücke im latenten Raum zwischen den beiden Modalitäten entsteht: https://arxiv.org/abs/2203.03897

  • Wenn euch dieses Feld interessiert, könnte auch unser Projekt eine Option sein, das intern transparent ColPali nutzt.
    https://github.com/tjmlabs/ColiVara
    Der wichtigste Benchmark in diesem Bereich ist das Vidore-Leaderboard, und ich würde gern sehen, wie VoyageAI im Vergleich zu offeneren Open-Source-Implementierungen abschneidet

  • Ich habe das Gefühl, etwas zu übersehen. Ein „nativ multimodales“ LLM müsste doch auf irgendeine Weise multimodale Embeddings enthalten.
    Zum Beispiel erklärt Googles Blogpost zu Gemini, dass bisherige multimodale Modelle Komponenten für unterschiedliche Modalitäten separat trainierten und anschließend zusammensetzten, während Gemini von Anfang an mit mehreren Modalitäten vortrainiert und mit zusätzlichen multimodalen Daten feinabgestimmt wurde. Daher, so die Behauptung, könne es alle Arten von Eingaben von Beginn an natürlich verstehen und darüber schlussfolgern

    • LLMs wie Gemini, allgemeiner kausale Sprachmodelle, werden auf Next-Token-Prediction trainiert. Deshalb sind Vektoren, die durch Pooling der Output-Token-Embeddings entstehen, für RAG oder semantische Suche nicht besonders nützlich im Vergleich zu dem, was man aus echten Embedding-Modellen erhält.
      Wichtig ist hier die Unterscheidung: Token-Embeddings und die Vektoren/Embeddings, die ein Embedding-Modell ausgibt, sind verwandte, aber unterschiedliche Konzepte. Die vielen Token-Embeddings, eines pro Token, werden im Transformer kontextualisiert, während ein Embedding-Modell pro Eingabedatum – etwa einem langen Text, einem Foto oder einem Dokument-Screenshot – einen Vektor ausgibt
    • In LLM-Embeddings stecken überlagerte Repräsentationen vieler Konzepte, sodass sie das nächste Token vorhersagen können, aber sie sind nicht so leistungsfähig wie Embedding-Modelle, die mit kontrastivem Lernen vortrainiert wurden
    • Falls die anderen Antworten nicht klar waren: Man kann „Embedding“ hier ungefähr als „eine Liste, die irgendeine Schicht meines KI-Modells erzeugt“ verstehen.
      Genau genommen ist es etwas spezifischer, aber in diesem Kontext passt das. Auch LLMs, einschließlich multimodaler LLMs, haben Embeddings, aber das sind nicht Embeddings, die darauf trainiert wurden, ähnliche Dokumente zu finden, sondern Embeddings, die über Textgenerierung trainiert wurden

  • Sieht ziemlich beeindruckend aus. Mich würde eine kritische Sicht auf die vorgestellte Evaluation interessieren.
    Außerdem frage ich mich, wie es mit nicht-englischem Text aussieht. Verstehe ich richtig, dass es wie andere kommerzielle Modelle nur per API verfügbar ist?

    • Ja, Voyage-Modelle sind nur per API verfügbar.
      Ich hatte etwas zur Mehrsprachigkeit geschrieben, das aber falsch war, und habe es daher gelöscht. Nebenbei hat Voyage auch separate Modelle für law, code und finance. Siehe [1].
      Die Ergebnisse sind jedenfalls wirklich interessant.
      [1]: https://docs.voyageai.com/docs/embeddings

  • Schade, dass das Modell kommerziell proprietär und nur per API verfügbar ist

    • Ist es traurig, dass man Mitarbeitende bezahlen muss?

  • Bei einem API-only-Modell bin ich raus. Trotzdem Glückwunsch

    • Ich stimme beiden Teilen zu. Natürlich gibt es abgesehen davon, Geld von Leuten zu verlangen, gute Gründe, sich nur auf die API zu konzentrieren. Aber allein die Tatsache, dass keine anderen Optionen angeboten werden, würde es für mich persönlich wohl ausschließen

  • Sieht ziemlich interessant aus. Ich habe an AnyModal gearbeitet, einem Framework zur Integration verschiedener Datentypen wie Bilder und Audio in LLMs: https://github.com/ritabratamaiti/AnyModal
    voyage-multimodal-3 wirkt für die Entwicklung multimodaler LLMs ziemlich vielversprechend, aber ich bin mir nicht sicher, ob das der beabsichtigte Anwendungsfall ist

  • In der traditionellen Python-API tokenisiert die Voyage-Engine Textblöcke und gibt Strings aus. Dieses Modell scheint das Gleiche zu tun, indem es Bilder innerhalb eines Raums vektorisiert.
    Wörter wie you oder apple werden zu einem Token, während komplexere Begriffe wie pikachu in etwas wie pik-a-chu aufgeteilt werden können.
    [1]: https://docs.voyageai.com/docs/tokenization

  • Interessant, wie hier multimodale Embeddings betrachtet werden. Gemessen wird die Leistungsänderung abhängig davon, in welchem Verhältnis sich die Eingabe allmählich von einer Modalität zur anderen verschiebt.
    https://i0.wp.com/blog.voyageai.com/wp-content/uploads/2024/...

  • Im Colab werden Skalarprodukt-Werte von 0,428 und 0,498 gemessen und als „ziemlich hohe Ähnlichkeitswerte“ beschrieben. Ich frage mich, ob das wirklich hohe Werte sind.
    Könnte man ein System entwerfen, das Daten mit einem Schwellenwert von 0,4 zuverlässig labelt?

    • Die rohen Ähnlichkeitswerte sind zwar auch wichtig, aber normalerweise zählt stärker der relative Score im Vergleich zu anderen Dokumenten.
      In den Notebook-Beispielen waren diese Werte relativ gesehen die höchsten. Ich verstehe, warum das unklar oder verwirrend sein kann, und werde es ändern
    • Der rohe Ausgabewert selbst ist im Allgemeinen nicht wichtig. Entscheidend ist seine Position innerhalb der Ausgabeverteilung
    • Eine Cosine Similarity von 0,4 ist nicht dasselbe wie ein Sigmoid-Schwellenwert von 0,4.
      Bei echten Daten, die nicht aus nahezu identischen Duplikaten bestehen, ist eine Cosine Similarity von 0,4 ein ziemlich ordentlicher Wert