AI-ProduktnewsEnterprise Retrieval Bericht

NeoMME 260M stellt Retrieval in den Vordergrund: Ein Single-Transformer-Multimodal-Encoder, der die Seiten-Durchsatzrate verdoppelt

Der 260M-Parameter-Encoder von NeoMME verarbeitet Text-Tokens und rohe 32×32 Bildausschnitte in einem einzigen bidirektionalen Transformer und liefert dichte sowie Late-Interaction-Embeddings in einem Durchgang. Das Ergebnis: Wettbewerbsfähige ViDoRe-Retrieval-Qualität und etwa doppelt so hoher Seiten-Durchsatz im Vergleich zu gängigen Baselines – was visuelle Dokumentensuche und RAG kostengünstiger, einfacher und skalierbarer macht.

NexusAI Redaktion4. Sept. 20262.4K Aufrufe9 Min. Lesedauer

NeoMME 260M stellt Retrieval in den Vordergrund: Ein Single-Transformer-Multimodal-Encoder, der die Seiten-Durchsatzrate verdoppelt

AI-Briefing

NeoMME definiert Enterprise-Retrieval neu: Statt einen Vision-Tower an ein Sprachmodell anzuhängen, verarbeitet es Text und Bilder durch einen einzigen Langzeit-Kontext-Encoder und erzeugt gleichzeitig dichte und Late-Interaction-Embeddings. Das 260M-Modell liegt auf der ViDoRe-Pareto-Grenze für Qualität vs. Größe und kodiert hochauflösende Seiten mit etwa doppeltem Durchsatz gängiger Baselines. Late-Interaction führt normalerweise zu hohem Speicherbedarf, aber hierarchisches Token-Pooling plus asymmetrische Quantisierung reduzieren den Speicherbedarf auf Kilobyte pro Seite bei minimalem Qualitätsverlust. Für Entwickler bedeutet das schnellere Indexierung, einfacheren Betrieb und praktisches visuelles RAG, das Layout, Diagramme und Tabellen bewahrt, ohne auf fragile OCR-Ketten angewiesen zu sein. Verwenden Sie dichte Embeddings für schnelles Recall und Late-Interaction für präzises Re-Ranking – ohne zwei Modelle betreiben zu müssen.

Die Kernidee von NeoMME ist architektonische Zurückhaltung zugunsten des Retrievals. Ein einziger bidirektionaler Transformer verarbeitet mehrsprachige Text-Tokens zusammen mit rohen 32×32 Bildausschnitten und verzichtet auf den separaten Vision-Tower und den kausalen Decoder, die bei VLM-ähnlichen Architekturen üblich sind. Der von Grund auf mit einem maskierten Denoising-Ziel trainierte 260M-Variante liefert dichte und Late-Interaction-Embeddings in einem Durchgang. In der Praxis bedeutet das weniger Komponenten bei der Inferenz, engere Latenzbudgets und einfacheres Skalieren. Bei angepassten 2048×2048 Eingaben kodiert das Modell etwa 51 Seiten pro Sekunde auf einer L40S – ungefähr doppelt so schnell wie weit verbreitete visuelle Dokumenten-Retriever – und hält dabei die Retrieval-Qualität für reale Such- und RAG-Pipelines wettbewerbsfähig.

Warum ist das für die Unternehmenssuche wichtig? Die meisten Dokumenten-Pipelines verlassen sich noch auf OCR, um Textabschnitte zu extrahieren, und versuchen dann, die Seitenlayout-Semantik nachträglich zu rekonstruieren. NeoMME kehrt das um: Es sucht direkt auf Seitenbildern und bewahrt Tabellen, Diagramme und typografische Hinweise, die OCR oft nivelliert. Das Dual-Head-Design bietet Workflow-Flexibilität: Verwenden Sie dichte Vektoren für schnelles Recall via ANN und wenden Sie Late-Interaction an, um Token-zu-Region-Übereinstimmungen zu erfassen, ohne ein zweites Modell laden zu müssen. Mit einem 16k-Kontextfenster, dynamischer Bildauflösung und modernen Encoder-Features konzentriert NeoMME das Parameterbudget dort, wo Retrieval am meisten profitiert: langer Kontext, hochauflösende Dokumente und mehrsprachige Anfragen.

Die Genauigkeit von Late-Interaction war historisch mit hohen Speicheranforderungen verbunden. Hochauflösende Seiten können tausende Vektoren pro Dokument erzeugen und Megabytes pro Seitenindex beanspruchen. NeoMME mildert das durch die Kombination von hierarchischem Token-Pooling (zur Reduzierung der Vektoranzahl) und asymmetrischer Quantisierung (zur stärkeren Kompression von Dokumentvektoren im Vergleich zu Anfragen). Bei gemessenen Konfigurationen sinkt der Speicherbedarf von Megabytes pro Seite auf einige zehn Kilobyte – in aggressiveren Einstellungen sogar auf etwa 6 kB pro Seite – bei gleichzeitigem Erhalt der überwiegenden Mehrheit der Basis-Retrieval-Qualität. Fazit: Late-Interaction ist dort, wo es zählt, auch in großem Maßstab erschwinglich, ohne das Speicherbudget zu sprengen.

Für Entwickler ändert sich die Berechnung bei der Bereitstellung. Indexierungsgeschwindigkeiten von etwa 51 Seiten pro Sekunde und GPU verkürzen die Suchzeit für große Archive drastisch und senken die laufenden Kosten für die Aktualisierung des Korpus. Ein einziger Vorwärtsdurchlauf liefert sowohl dichte als auch Late-Interaction-Embeddings, sodass Sie Ihre Pipeline standardisieren und Kompromisse auf die Indexebene verschieben können. Feinabstimmung mit Sentence Transformers für domänenspezifische dichte oder Late-Interaction-Köpfe ist möglich, oder Sie behalten den Generalisten-Checkpoint und nutzen Kompression, um Kosten und Relevanz auszubalancieren. Im visuellen RAG rufen Sie zuerst Seitenbilder ab und übergeben die Top-k-Seiten nur zur Antwortgenerierung an ein VLM – wodurch der Großteil der Arbeit an einen schlanken, retrieval-nativen Encoder verlagert wird.

Wichtigste Erkenntnisse

Ein Durchgang, zwei Embeddings

NeoMME liefert dichte und Late-Interaction-Vektoren zusammen, sodass Sie schnelles ANN-Recall und präzises Re-Ranking ohne zwei verschiedene Modelle durchführen können.

Durchsatz bedeutet Kosteneinsparungen

Etwa doppelt so schnelles Seiten-Encoding führt zu kürzeren Indexierungsfenstern, weniger GPU-Stunden und häufigeren Korpus-Aktualisierungen für regulierte oder zeitkritische Archive.

Late-Interaction ist jetzt speicherfreundlich

Hierarchisches Pooling plus asymmetrische Quantisierung komprimieren Multi-Vektor-Seiten auf Kilobyte, während die meisten wichtigen Retrieval-Qualitätsmerkmale erhalten bleiben.

Was sich geändert hat: Ein Single-Tower-Multimodal-Encoder

NeoMME ersetzt das Dual-Tower- oder VLM-plus-Projektor-Muster durch einen einzigen bidirektionalen Transformer für Text und Bilder. Die Eingaben sind mehrsprachige BPE-Tokens und nicht überlappende 32×32 Patches. Der Stack nutzt Sliding-Window-Attention mit periodischen globalen Schichten, gruppierte Query-Attention, QK-Norm, 2D-Rotary-Embeddings und einen langen 16.384-Token-Kontext. Da Bilder und Text denselben Pfad teilen, sind Pretraining, Feinabstimmung und Bereitstellung einfacher und besser parallelisierbar. Für Teams, die Retrieval-Funktionen statt Generierung bereitstellen wollen, konzentriert sich die Kapazität auf das Wesentliche – schnelle, präzise Embeddings über Modalitäten hinweg – ohne Decoder-Overhead.

Durchsatz und Qualität: Praktische Verbesserungen für die Indexierung

Bei einer angepassten Eingangsgröße von 2048×2048 auf einer einzelnen L40S kodiert der 260M-Retriever etwa 51 Seiten pro Sekunde – ungefähr doppelt so schnell wie gängige Baselines unter ähnlichen Bedingungen. Im ViDoRe v3 Benchmark liegt das 260M-Modell auf der Qualität-Größe-Pareto-Grenze und liefert starke nDCG@10-Werte im Verhältnis zu seiner kompakten Parameteranzahl. Das bedeutet: Sie können mehr Seiten schneller mit weniger GPUs indexieren und dennoch mit größeren Modellen bei der Relevanz konkurrieren. Größere Vorteile sind bei bildlastigen Korpora zu erwarten, bei denen Layout, Bildunterschriften und Tabellenstruktur die Retrieval-Genauigkeit maßgeblich beeinflussen.

Late-Interaction ohne Speicherbelastung

Hochauflösende Seiten können tausende Token-/Patch-Vektoren erzeugen, was Indizes zu Speicherfressern macht. Der Late-Interaction-Kopf von NeoMME lässt sich gut mit zwei Kompressionshebeln kombinieren: hierarchisches Token-Pooling zur Reduzierung der Vektoranzahl pro Seite und asymmetrische Quantisierung, um Dokumente mit geringerer Präzision als Anfragen zu speichern. In Tests sank der Speicherbedarf von Megabytes auf Kilobytes pro Seite, während der Großteil des Basis-nDCG erhalten blieb. Wählen Sie konservatives Pooling mit int8 für qualitätssensible Archive oder aggressives Pooling mit binären Dokumenten, wenn das Budget dominiert und Sie dennoch starkes Re-Ranking wünschen.

Implementierungsleitfaden: Suche und visuelles RAG

Beginnen Sie damit, PDFs in Seitenbilder umzuwandeln und mit NeoMME-Retriever zu indexieren: Speichern Sie dichte Vektoren für schnelles ANN-Recall und Late-Interaction-Vektoren für Re-Ranking. Nutzen Sie dynamische Bildauflösung, um Details auf informationsreichen Seiten zu bewahren. Kalibrieren Sie die Kompression entsprechend Ihrem Speicherbudget (z. B. Pooling 8–10, int8-Anfragen, binäre Dokumente für aggressive Einsparungen). Für visuelles RAG holen Sie die Top-k-Seiten ab und fügen sie als Bilder Ihrem VLM-Prompt voran. Bei sehr großen Korpora führen Sie zuerst ein dichtes Recall auf dem gesamten Index durch und re-ranken dann eine enge Kandidatenmenge mit Late-Interaction. Feinabstimmung von Domänenköpfen via Sentence Transformers ist möglich, wenn Ihre Anfragen eine konsistente Struktur aufweisen.

Risiken, Kosten und Passung

Der Durchsatz hängt von vorverarbeiteten Tensoren, I/O und Batch-Kalibrierung ab; planen Sie Puffer für reale Pipelines ein. Langzeit-Kontext-Encoder können bei sehr hohen Auflösungen den Aktivierungsspeicherbedarf erhöhen. Bildbasiertes Retrieval sollte Datenschutz- und Sicherheitsrichtlinien beachten, insbesondere bei gescannten Ausweisen oder Unterschriften. NeoMME ist nicht generativ – kombinieren Sie es mit einem VLM für Antwortentwürfe im RAG. Schließlich können Kompressionsentscheidungen subtil beeinflussen, welche Seitenbereiche die Ähnlichkeit dominieren; validieren Sie Einstellungen anhand Ihrer tatsächlichen Aufgaben, bevor Sie sich auf ein Indexformat festlegen.

Häufig gestellte Fragen

Wann sollte ich dichte versus Late-Interaction-Embeddings mit NeoMME verwenden?

Verwenden Sie dichte Vektoren für schnelles, kostengünstiges Recall über den gesamten Korpus. Rufen Sie eine kleine Kandidatenmenge (z. B. Top 200–1.000) mit ANN ab und wenden Sie dann Late-Interaction für das finale Ranking an, um Token-zu-Region-Übereinstimmungen zu erfassen. Für kleine Korpora oder wichtige Anfragen können Sie direkt mit Late-Interaction suchen, sofern der Speicher dies zulässt.

Welchen Hardware-Footprint sollte ich für großflächige Indexierung einplanen?

Als Referenz kodiert das 260M-Modell etwa 51 Seiten/Sekunde pro L40S bei 2048×2048 mit optimiertem Batchen. Das entspricht etwa 1 Million Seiten in rund 5–6 Stunden reiner Modellzeit pro GPU. Reale Pipelines haben I/O- und Vorverarbeitungs-Overhead; planen Sie 2–3× Wandzeit ein. Skalieren Sie linear mit mehr GPUs oder reduzieren Sie die Bildauflösung, wo akzeptabel.

Wie kombiniere ich Bild-Seiten-Retrieval mit rein textbasierten Inhalten?

Indexieren Sie Seitenbilder mit NeoMME und behalten Sie Ihre Text-Embeddings für Inhalte ohne verlässliche Bilddaten. Leiten Sie Anfragen über denselben Retriever für gemischte Modalitätsbewertung. Für PDFs mit schwachen Scans speichern Sie sowohl Late-Interaction-Seitenvektoren als auch dichte Text-Chunk-Vektoren; rufen Sie dicht ab und re-ranken Sie mit Late-Interaction, wenn ein Seiten-Screenshot vorhanden ist.

#Feinabstimmung von Einbettungen#Modellkomprimierung#Modellquantisierung#Quantisierungstechniken#Recheneffizienz#Modelle mit offenem Gewicht#Apache 2.0 Lizenz#Open-Source KI-Frameworks#Langzeit-Kontext-Modelle#Langkontext RAG#Token pro Sekunde#Kostenbewusste Inferenz#Modellkarten & Bewertung#Enterprise-Content-Systeme#Multimodale Suche#Späte Interaktion#Dokumenten-RAG#ANN-Indizierung#Hierarchische Token-Poolbildung#Asymmetrische Quantisierung#Visuelle Dokumentensuche#ViDoRe Benchmark#Sentence Transformers v6#Neuordnung des Vektor-Speichers