MMORE : faire rentrer 8 000 PDF, 2 000 vidéos et 500 tableurs dans la tête d’un LLM ?
Ou comment une pipeline open source apprivoise le chaos multimodal pour vos systèmes RAG.
Pourquoi ce papier est intriguant
Le rêve du RAG (Retrieval-Augmented Generation) est simple à énoncer : relier un modèle à toute votre connaissance et obtenir des réponses fiables, sourcées et à jour. La réalité, elle, ressemble davantage à une brocante : des PDF scannés, des DOCX pleins de tableaux, des e‑mails, des pages web, des vidéos de démo, de l’audio d’entretiens… et une pelle de métadonnées éparpillées. MMORE — pour Massive Multimodal Open RAG & Extraction — arrive avec une promesse pragmatique : une pipeline unifiée, distribuée et ouverte pour ingérer, transformer, indexer et interroger ces données hétérogènes à grande échelle. C’est intéressant parce que la plupart des stacks RAG bricolées meurent justement sur ces cailloux : la diversité des formats, le passage à l’échelle et l’évaluation.
« MMORE prend en charge plus de quinze types de fichiers […] et les transforme en un format unifié pour des applications LLM ».
Et si on arrêtait de bricoler des RAG?
MMORE se lit comme une chaîne de montage pour la connaissance : on y dépose des documents bruts (PDF, Office, e‑mails, HTML, images, audio, vidéo), la pipeline extrait et standardise le contenu (texte, tableaux, métadonnées, timecodes), puis indexe le tout dans une base hybride (dense + sparse). Ensuite, un service RAG expose le savoir via API/CLI, et l’on peut brancher le LLM de son choix.
Sur des benchmarks de traitement, MMORE annonce un accélérateur 3,8× par rapport à des bases mono‑nœud, et +40 % d’exactitude face à Docling sur des PDF scannés. Du côté usage, branché à un LLM biomédical sur PubMedQA, la précision grimpe avec la profondeur de récupération (plus on récupère de passages pertinents, mieux c’est — jusqu’à un point de saturation).
« L’architecture offre un traitement modulaire et distribué, permettant une parallélisation scalable sur CPU et GPU ».
Cerise open‑source : le code est disponible (installation pip install mmore, Dockerfile, scripts, exemples), avec une doc pratique, une CLI et une intégration LangChain côté RAG. L’index par défaut s’appuie sur Milvus et reste extensible.
Faire un RAG c'est pas l'usine, mais presque...
Imaginez une usine de tri sélectif pour vos données. À l’entrée, tout est mélangé ; à la sortie, tout est proprement étiqueté et rangé par taille, matière et destination.
-
Process : des « processeurs » spécialisés ouvrent chaque format et en tirent l’essence. Un PDF devient du texte + un maillage de blocs et d’images; une vidéo, une piste texte (ASR) alignée sur le temps + des vignettes clés; un tableur, des cellules structurées; un e‑mail, l’en‑tête et le corps. Certains types ont un mode rapide (accélérations GPU/CPU selon le type). Les sorties irriguent un schéma multimodal unifié (pensez « MultimodalSample » : un conteneur normalisé qui sait parler texte, image, audio, méta).
-
Post‑process : on nettoie (OCR, dé‑dupli, découpage en chunks cohérents, normalisation d’unités), on annote (titres, auteurs, dates, empreintes), on fabrique des embeddings adaptés au type (texte, image, parfois audio).
-
Index : on pousse le tout dans un index hybride combinant recherche dense (embeddings) et recherche sparse (BM25/TF‑IDF ou équivalent). Avantage : la robustesse du lexical + la sémantique du dense. Milvus sert de colonne vertébrale pour le vectoriel, avec un Index API HTTP pour ajouter des documents « à chaud ».
-
RAG : un service répond aux requêtes en récupérant les passages pertinents (top‑k, filtres sur métadonnées), en formant le contexte puis en interrogeant le LLM via une interface LangChain. Vous pouvez changer de LLM comme de paire de chaussures sans réécrire la boutique.
-
(Bientôt) Évaluation : intégration prévue avec Ragas pour chiffrer l’apport réel du RAG. Spoiler : l’évaluation est la boussole qui évite de confondre « ça marche sur mon laptop » et « ça tient en prod ».
Et côté perfs ?
Deux signaux notables :
- Vitesse : « 3,8× » de gain vs des bases mono‑nœud sur le pré‑traitement. Cela vient du pipelinage distribué qui exécute en parallèle des tronçons sur CPU/GPU (OCR, vision, ASR, parsers).
- Qualité d’extraction : +40 % d’exactitude vs Docling sur des PDF scannés. Le scan est l’ennemi naturel de l’OCR : texte irrégulier, colonnes, artefacts; MMORE revendique de meilleurs heuristiques/post‑process (et/ou modèles OCR) sur ce terrain.
Côté RAG, sur PubMedQA, la précision augmente avec la profondeur de récupération. Autrement dit, si votre base est propre et vos passages bien découpés, récupérer un peu plus (sans noyer le LLM) améliore la réponse — jusqu’à un optimum.
« Évalué sur PubMedQA, MMORE‑augmenté améliore la précision biomédicale au fur et à mesure qu’on augmente la profondeur de récupération ».
Un nouveau monde s'offre à vous
-
Pour les devs back/data : fini les scripts ad‑hoc différents pour chaque source. Vous gagnez une pipeline factorisée avec config YAML, Docker, CLI et API. L’index hybride donne le meilleur des deux mondes, et vous pouvez échanger Milvus ou brancher votre hébergeur de vecteurs si vous avez déjà une infra.
-
Pour les data scientists : vous récupérez un schéma multimodal stable et des features réplicables (chunks, embeddings, métadonnées), ce qui rend enfin possible une évaluation rigoureuse (Ragas, tâches QA fermées, exact match, F1…).
-
Pour le MLOps : scalabilité et déploiement comptent autant que l’idée. Ici, la parallélisation CPU/GPU + la modularité vous permettent d’augmenter la cadence quand le volume grimpe. D’autant que l’Index API autorise l’ingestion incrémentale sans recompiler l’univers.
-
Pour les créateurs de jeux : imaginez un compendium vivant qui indexe vos Game Design Docs, wikis, assets (captions d’images), lore bibles, journaux de production, retours joueurs. Un PNJ archiviste peut répondre aux questions des designers ou des joueurs (« Où trouve‑t‑on la clé de cuivre ? », « Quels sont les buffs actifs sur le set Éclipse ? ») en citant la source (lignes du GDD, commit notes, patch notes). Vous pouvez même alimenter des systèmes de quêtes dynamiques basés sur le lore extrait (et filtré par étiquette d’époque/lieu).
TLDR
Pensez MMORE comme un port de conteneurs : les cargos (vos documents) arrivent de partout, mal empilés et de tailles variées. Les grues (processeurs) déchargent, reconditionnent et étiquettent, les chariots (post‑process) redistribuent vers les hangars spécialisés (index dense/sparse). Lorsqu’un client (votre appli) passe commande, l’expéditeur RAG assemble rapidement la palette exacte d’articles (passages), l’emballe avec les références d’origine et l’envoie au chauffeur LLM. Pas de romance, mais ça tourne.
Détails saillants à connaître
- Formats supportés : documents texte (DOCX, MD, PPTX, XLSX, TXT, EML), PDF, médias (MP4, MOV, AVI, MKV, MP3, WAV, AAC), web (HTML). Certains ont un fast mode (PDF, vidéo/audio).
- Intégrations : LangChain pour la couche LLM, Milvus pour le vecteur, HTTP Index API pour ajouter des fichiers à la volée.
- Déploiement :
pip install mmore, Dockerfile, exemples, scripts, et CLI pour process/index/rag. - Ouverture : licence Apache‑2.0, contributions bienvenues.
Ce qui manque (encore) et les bonnes questions
Le papier est court (9 pages) et surtout orienté système. Quelques zones à éclaircir lors d’un prochain billet :
- Évaluation plus large : au‑delà de PubMedQA, que donnent des datasets « sales » (contrats scannés, plans d’architecte, captures de bugs) ? Quels gains nets end‑to‑end sur des tâches métiers (EM/F1, fidélité des citations, latency under load) ?
- Coûts : prix/Go d’ingestion selon format, empreinte GPU/CPU pour l’OCR/ASR, et coûts LLM par requête RAG (contexte vs tokens générés). La magie est là, mais le comptable veut les chiffres.
- Sécurité/Privé : chiffrement au repos/en transit, PII scrubbing dans le post‑process, contrôle d’accès au niveau chunk. Beaucoup d’orgas en ont besoin pour passer en prod.
Exemples concrets d’utilisation
- FAQ entreprise vivante : indexer toutes les politiques RH, les communications Slack exportées, les procédures IT (MD/HTML), les tickets PDF et les comptes‑rendus d’incident audio ; répondre en citant exactement le paragraphe.
- Recherche scientifique : absorber corpus PubMed + PDFs scannés de vieux journaux, extraire tableaux + graphiques, interroger en langage naturel avec références traçables.
- Studio de game dev : brancher le pipeline sur le dépôt Notion/Confluence + répertoires d’assets ; laisser un PNJ dev‑ops répondre sur l’ADA, les cooldowns, ou l’histoire des builds.
Citations choisies du papier
« MMORE prend en charge plus de quinze types de fichiers, […] pour permettre des applications LLM en aval. »
« Sur des benchmarks de traitement, MMORE démontre un gain de 3,8× […] et 40 % d’exactitude en plus que Docling sur des PDF scannés. »
« Évalué sur PubMedQA, des LLMs biomédicaux augmentés par MMORE améliorent l’exactitude avec la profondeur de récupération. »
(Les citations complètes, le PDF et la notice OpenReview sont accessibles sur arXiv/OpenReview.)
Conclusion : plus qu’un parseur, un passeur
MMORE n’est ni un LLM, ni « un extracteur magique ». C’est un orchestre qui permet à vos modèles de lire le monde tel qu’il est : hétérogène, bruyant, multimodal. Si vous avez déjà tenté d’aligner OCR, embeddings, index et citations sans perdre la raison, ce papier et ce repo vous feront gagner des semaines. Et si vous créez des jeux, imaginez vos PNJ bouquinistes capables de citer un commit de 2022 pour justifier un équilibrage : de quoi faire sourire l’équilibriste qui sommeille en vous.
La morale : le RAG n’est pas qu’un prompt avec un “search”. C’est de l’ingénierie de données — et MMORE offre une boîte à outils crédible pour la faire bien, vite et à grande échelle. Maintenant, à vous de jouer : testez, mesurez, et n’oubliez pas de citer vos sources… même quand c’est vous qui avez écrit la doc 😉
Références : arXiv (v1 soumis le 15 septembre 2025) et dépôt GitHub/documentation du projet.