Aktualisiert am 8. September 2026. NeoMME wurde am 3. September veröffentlicht; Leistung und Integrationen können sich schnell ändern.
NeoMME ist eine neue Familie multimodaler und mehrsprachiger Encoder für die Suche in Texten, Bildern und vollständigen Dokumentseiten. H Company veröffentlichte Modelle mit 260 und 800 Millionen Parametern, Checkpoints unter Apache 2.0 und unmittelbare Unterstützung in Hugging Face Transformers. Besonders relevant ist Visual RAG: Die passende Seite wird anhand ihres Bildes gefunden, statt jedes Dokument ausschließlich auf extrahierten Text zu reduzieren.
Das Modell ist kein Chatbot und erzeugt die endgültige Antwort nicht selbst. NeoMME wandelt Fragen und Dokumente in vergleichbare numerische Repräsentationen um. Eine Anwendung ruft die relevantesten Seiten ab und gibt sie anschließend an ein generatives Modell weiter. Ein Retriever verbessert den Kontext, ersetzt aber nicht den Generator.
Wie NeoMME funktioniert
Laut der technischen Einführung von H Company nutzt NeoMME einen einzigen bidirektionalen Transformer für Text-Token und Bild-Patches. Viele multimodale Systeme verbinden einen separat vortrainierten Bild-Encoder mit einem Sprachmodell. Diese Architektur wird dagegen von Grund auf mit einem Masked-Discrete-Diffusion-Ziel trainiert.
Das Ergebnis ist ein Encoder und kein autoregressiver Decoder. Er kann eine geschriebene Frage, Dokumenttext oder den Screenshot einer vollständigen Seite darstellen. Tabellen, räumliche Anordnung, Fotos und andere visuelle Signale bleiben für die Suche erhalten, statt in einer reinen OCR-Pipeline zu verschwinden.
Die Familie umfasst eine kompakte und eine größere Variante. Die Model Card von NeoMME-260M-Retriever nennt 263 Millionen Parameter, 16.384 Kontext-Token und standardmäßig Bilder bis 2.048 Pixel an der längsten Seite. Diese Größe ist vergleichsweise handhabbar, bedeutet aber nicht, dass jeder Rechner Millionen Seiten ohne Kapazitätsplanung indexiert.
Dense Retrieval und Late Interaction in einem Durchlauf
NeoMME-Retriever erzeugt in einer Inferenz zwei Embedding-Arten. Ein Dense-Vektor fasst das gesamte Element kompakt zusammen und ermöglicht eine schnelle erste Suche. Multi-Vektoren bewahren feinere Darstellungen von Token und Patches, sodass eine präzisere Late Interaction zwischen Frage und Seitenbereichen möglich wird.
Eine Pipeline kann per Dense Retrieval das Archiv verkleinern und die aufwendigere Bewertung nur auf die besten Kandidaten anwenden. Das eignet sich für technische PDFs, Kataloge, Verträge, Folien, Handbücher und Archive, in denen die visuelle Position Bedeutung trägt.
| Merkmal | NeoMME-260M-Retriever |
|---|---|
| Parameter | 263 Millionen |
| Kontext | 16.384 Token |
| Eingabe | Text oder Seitenbild |
| Retrieval-Ausgabe | Dense und Multi-Vektor |
| Lizenz | Apache 2.0 |
| Haupteinsatz | Dokumentsuche und Visual RAG |
Leistung: veröffentlichte Zahlen richtig lesen
Der Bericht platziert die Versionen 260M und 800M auf der ViDoRe-v3-Paretofront für nDCG@10 und Modellgröße. In einem Test mit 2.048 mal 2.048 Pixeln auf einer NVIDIA L40S codiert das 260M-Modell ungefähr 51 Seiten pro Sekunde, etwa doppelt so viele wie ColModernVBERT unter vergleichbaren Bedingungen.
Hierarchisches Pooling und asymmetrische Quantisierung sollen den Late-Interaction-Index von rund 1,5 MB auf 6 kB pro Seite reduzieren und mehr als 95 Prozent des ursprünglichen nDCG@10 bewahren. Das muss auf eigenen Daten reproduziert werden: Auflösung, Batchgröße, GPU, Sprache und Seitentyp beeinflussen Tempo und Qualität.
Das NeoMME-Paper meldet 0,523 nDCG@10 für den 260M-Retriever und 0,556 für 800M auf ViDoRe v3. Diese Werte bewerten die Reihenfolge relevanter Treffer. Sie messen nicht direkt die Richtigkeit generierter Antworten, Halluzinationen oder OCR-Qualität.
Sinnvolle Einsatzbereiche
Der erste Einsatz ist ein Archiv, in dem Textextraktion Struktur verliert: Rechnungen mit Tabellen, Berichte mit Diagrammen, Produktblätter, Scans, Präsentationen und illustrierte Handbücher. Die Indexierung als Seitenbild hilft, wenn Layout und visuelle Inhalte für die Antwort entscheidend sind.
Der zweite Bereich ist mehrsprachige Suche. Eine Architektur verarbeitet mehrere Sprachen und Modalitäten und kann getrennte Encoder ersetzen. Trotzdem muss die Qualität für tatsächlich verwendete Sprachen geprüft werden, besonders bei schlechten Scans, kleiner Schrift und Fachbegriffen.
Unser Beitrag zu Qwen 3.8-27B für lokale Nutzung behandelt ein generatives Modell, das schreibt und schlussfolgert. NeoMME sitzt an einer anderen Stelle: Es wählt visuelle Quellen für den Generator aus. Beide Modelltypen können zusammenarbeiten.
Grenzen und Praxistest
NeoMME beseitigt nicht automatisch den Bedarf an OCR, Metadaten und Zugriffsregeln. Text kann für genaue Zitate, Filter, Markierungen und Audits nötig bleiben. Jedes Embedding muss mit seiner Ursprungsseite verbunden sein, und die Suche darf keine unberechtigten Dokumente offenlegen.
Ein Multi-Vektor-Index kann bei Millionen Seiten trotz Kompression groß werden. Zu messen sind Indexierungsdauer, Arbeitsspeicher, Speicherplatz, Suchlatenz und Qualität nach Quantisierung. Ein sinnvoller Test verwendet reale Fragen und bewertet den Recall unter den ersten Treffern.
Für einen ersten Prototyp empfiehlt sich ein begrenzter, repräsentativer Dokumentbestand. Teams sollten Seitenbilder und Textvarianten getrennt indexieren, schwierige Anfragen markieren und falsche Treffer manuell kategorisieren. Erst danach lässt sich entscheiden, ob Dense Retrieval allein genügt oder die präzisere Late Interaction ihren zusätzlichen Speicher- und Rechenaufwand rechtfertigt.
Auch Aktualisierungen brauchen einen definierten Ablauf. Wird eine Dokumentseite ersetzt, müssen alte Vektoren entfernt und neue Versionen mit stabilen Kennungen gespeichert werden. Ohne Versionskontrolle kann ein RAG-System eine veraltete Seite zitieren, obwohl im Quellsystem längst eine korrigierte Fassung existiert.
Der Vergleich GPT-6 Astra oder GPT-5.6 Sol zeigt, warum auch der abschließende Generator nach Kosten und Latenz gewählt werden muss. Ein guter Retriever reduziert teuren Kontext, doch ein stärkeres LLM kann eine nie gefundene Seite nicht zuverlässig reparieren.
NeoMME ist ein ganz neuer Suchbegriff, löst aber ein konkretes Problem: Visual RAG kompakter und leichter integrierbar zu machen. Der dauerhafte Wert zeigt sich, wenn unabhängige Entwickler die Ergebnisse auf anderen Dokumentbeständen wiederholen. Heute ist es ein glaubwürdiger Testkandidat, kein universeller Ersatz für jede Dokumentenpipeline.
