RAG Anything a Transformé Mes PDFs Scannés en Connaissances Consultables

RAG Anything a Transformé Mes PDFs Scannés en Connaissances Consultables

J'avais un rapport financier de 47 pages sur mon bureau depuis trois semaines. PDF scanné. Graphiques à barres sur chaque autre page. Tableaux de revenus rendus sous forme d'images, pas de données réelles. Le genre de document qui fait hausser les épaules à chaque système RAG que j'ai jamais construit, en disant : « voici du charabia que j'ai trouvé entre les en-têtes. »

J'utilisais LightRAG depuis des mois -- ingestion de texte, construction de graphes de connaissances, récupération hybride. Il gérait mes fichiers markdown et mes documents en texte brut à merveille. Mais chaque fois que j'essayais de lui soumettre quelque chose avec des graphiques, des diagrammes ou des pages scannées, le résultat se situait quelque part entre inutile et comiquement faux. Une fois, j'ai demandé les tendances des revenus au Q3 et j'ai obtenu en retour un paragraphe sur le formatage de la table des matières. Le graphe de connaissances avait fidèlement indexé les déchets OCR des en-têtes de page et ignoré les données réelles dans le graphique à barres en dessous.

Ce rapport financier a été le point de rupture. J'avais besoin que mon système RAG comprenne les documents comme je les comprends -- pas seulement les mots sur la page, mais les graphiques, les images, les données visuelles qui portent la moitié du sens dans tout document d'entreprise sérieux. Et c'est alors que j'ai trouvé RAG Anything.

Développé par la même équipe HKUDS derrière LightRAG, RAG Anything est un wrapper qui greffe le traitement de documents multimodal sur votre configuration LightRAG existante. Il ne remplace pas LightRAG. Il l'étend. Et la façon dont il gère la séparation entre le contenu textuel et visuel est véritablement ingénieuse -- assez ingénieuse pour que j'aie reconstruit toute ma pipeline d'ingestion de documents autour de lui en un seul week-end.

Voici le détail complet de son fonctionnement, comment je l'ai configuré et ce qui s'est passé lorsque j'ai finalement passé ce rapport financier à travers.

Pourquoi le RAG Standard Échoue sur les Documents du Monde Réel

Le sale secret de la plupart des tutoriels RAG est qu'ils font des démonstrations avec des fichiers markdown impeccables et des PDFs en texte propre. Le genre de documents où chaque caractère est déjà lisible par machine, bien structuré et prêt pour le chunking. C'est peut-être 30% des documents avec lesquels je travaille réellement.

Les 70% restants ? Contrats scannés. Présentations exportées en PDF. Articles de recherche avec des équations LaTeX. Rapports financiers où les données les plus importantes se trouvent dans des graphiques à barres et circulaires. Mémos internes que quelqu'un a imprimés, signés à la main, puis scannés. Formulaires gouvernementaux. Factures avec des logos et des tableaux rendus sous forme d'images.

Les pipelines RAG standard -- y compris LightRAG vanilla -- traitent ces documents avec ce que j'appelle l'approche « plisser les yeux et espérer ». Ils effectuent une extraction de texte de base, obtiennent des déchets partiels de la couche OCR, découpent en chunks le texte trouvé, l'encodent et disent que c'est terminé. Les graphiques ? Invisibles. Les images ? Ignorées. L'écriture scannée à la main ? Une salade de caractères mal reconnus.

J'ai essayé des solutions de contournement. J'ai fait passer des documents par des outils OCR séparés avant de les soumettre à LightRAG. J'ai utilisé GPT-4o pour décrire des images et injecté ces descriptions comme texte. J'ai même construit une pipeline de prétraitement qui extrayait les images des PDFs, envoyait chacune à un modèle de vision, recevait des descriptions textuelles en retour, et fusionnait ces descriptions dans le flux de texte original avant le chunking.

Ça marchait. À peine. La surcharge de maintenance était brutale, le coût de traitement était élevé parce que chaque image passait par une API de vision dans le cloud, et le graphe de connaissances se retrouvait avec des déconnexions étranges entre les entités de texte « réelles » et les entités d'image « décrites ». Elles existaient dans des univers parallèles au sein de la même base de données.

RAG Anything résout cela d'une manière fondamentalement différente. Au lieu de traiter les images comme une réflexion après coup à convertir en texte, il les traite comme un type de données de première classe avec leur propre espace d'embedding et leur propre branche du graphe de connaissances -- puis fusionne tout dans une couche de récupération unifiée. La distinction est plus importante qu'il n'y paraît.

Mais avant d'expliquer l'architecture, vous devez comprendre le parseur de documents qui rend tout cela possible.

MinerU : Le Parseur de Documents qui Fait le Gros du Travail

Au cœur de RAG Anything se trouve MinerU, un parseur de documents open source de l'équipe OpenDataLab. Si vous ne l'avez pas encore rencontré, MinerU est ce qui arrive quand on construit un outil d'extraction PDF qui respecte vraiment la complexité des documents réels.

La plupart des parseurs PDF traitent une page comme un flux de texte plat. MinerU la traite comme une mise en page -- avec des en-têtes, des paragraphes, des tableaux, des images, des équations, des notes de bas de page et des barres latérales, chacun identifié et routé vers un modèle d'extraction spécialisé. Pensez-y comme un système de triage. Le document arrive dans MinerU, et MinerU dit : « Ce bloc est un titre. Ce bloc est du texte de corps. Ceci est un tableau. Ceci est une image de graphique. Ceci est une équation LaTeX. » Chaque composant est traité par le modèle le mieux adapté.

Pour le texte, MinerU utilise PaddleOCR -- le moteur OCR open source de Baidu qui prend en charge plus de 100 langues depuis PP-OCRv5. PaddleOCR n'est pas seulement de la reconnaissance de caractères. Il gère des mises en page complexes, du texte multi-colonnes, du texte rotatif et du texte intégré dans des images. Quand MinerU identifie un bloc de texte dans un PDF scanné, PaddleOCR extrait les caractères réels avec une précision étonnamment élevée.

Pour les éléments non textuels -- graphiques, diagrammes, photographies, schémas -- MinerU adopte une approche différente. Il les capture sous forme de captures d'écran. Des captures d'écran propres et recadrées qui préservent l'information visuelle exactement telle qu'elle apparaît sur la page.

Cette séparation est l'insight clé qui fait fonctionner RAG Anything. Au lieu d'essayer de tout forcer en texte (ce qui perd de l'information) ou de tout traiter comme des images (ce qui est coûteux et lent), MinerU divise le document en deux seaux propres :

• Seau de texte : Tout ce qui est réellement du texte, extrait via OCR avec une haute fidélité
• Seau d'images : Tout ce qui est visuel, capturé sous forme de captures d'écran avec le contexte complet

Les deux seaux alimentent la prochaine étape de la pipeline. Et c'est là que l'architecture de RAG Anything devient intéressante -- car chaque seau obtient son propre track de traitement parallèle.

MinerU tourne entièrement en local. Pas d'appels API pour la phase de parsing. Pas de données quittant votre machine. Le compromis est qu'il est plus lourd qu'une simple bibliothèque PDF -- vous téléchargez de vrais modèles de ML pour la détection de mise en page, l'OCR et la classification de composants. Sur mon M2 MacBook Pro, le téléchargement initial du modèle était d'environ 2 Go. Après ça, le parsing d'un PDF scanné de 50 pages prend environ 45 secondes sur CPU. Passer au GPU (que je couvrirai dans la section de configuration) le réduit à environ 12 secondes.

Le traitement local mérite d'être souligné. Chaque page de votre document reste sur votre hardware pendant le parsing. Le seul moment où les données quittent votre machine, c'est dans la prochaine étape, quand le texte et les images extraits sont envoyés à un LLM pour l'extraction d'entités et la génération d'embeddings.

L'Architecture à Double Pipeline : Comment RAG Anything Fonctionne Vraiment

C'est là que l'ingénierie devient véritablement ingénieuse. Une fois que MinerU a divisé votre document en seaux de texte et d'images, RAG Anything exécute deux pipelines de traitement en parallèle -- une pour chaque seau. Les deux pipelines font les mêmes deux choses, mais de manière différente.

Pipeline 1 : Traitement du texte

Le seau de texte va à un LLM (GPT-4o mini par défaut, bien que vous puissiez en substituer un autre). Le LLM effectue deux opérations :

1. Extraction d'entités et de relations -- Il lit le texte et identifie les entités (personnes, entreprises, concepts, dates, chiffres financiers) et les relations entre elles. Celles-ci deviennent des nœuds et des arêtes dans un graphe de connaissances.
2. Génération d'embeddings -- Les chunks de texte sont convertis en embeddings vectoriels (en utilisant text-embedding-3-large par défaut) et stockés dans une base de données vectorielle.

C'est essentiellement ce que LightRAG vanilla fait déjà. Rien de nouveau ici.

Pipeline 2 : Traitement des images

Le seau d'images va au même LLM, mais l'interaction est différente. Chaque capture d'écran -- chaque graphique, diagramme, schéma et élément visuel que MinerU a extrait -- est envoyée aux capacités de vision du LLM. Le LLM analyse l'image et effectue les mêmes deux opérations :

1. Extraction d'entités et de relations du contenu visuel -- Le modèle regarde un graphique à barres et extrait des entités comme « Revenu Q1 : 2,4 M$ » et « Revenu Q3 : 3,1 M$ » et la relation « les revenus ont augmenté de 29% du Q1 au Q3 ». Celles-ci deviennent des nœuds et des arêtes dans un graphe de connaissances spécifique aux images.
2. Génération d'embeddings à partir de descriptions visuelles -- Le modèle génère de riches descriptions textuelles de chaque image, et ces descriptions sont converties en embeddings et stockées dans une base de données vectorielle spécifique aux images.

Vous avez maintenant quatre structures de données :

La Fusion

RAG Anything fusionne ensuite ces quatre structures en deux : une base de données vectorielle unifiée et un graphe de connaissances unifié. Les entités de texte et d'image coexistent dans le même graphe. Les embeddings de texte et d'image vivent dans le même espace vectoriel. Quand vous interrogez le système, la récupération se produit dans les deux modalités simultanément.

C'est la partie qui a résolu mon problème d'« univers parallèle ». Quand je faisais de la conversion image-vers-texte comme étape de prétraitement, les entités dérivées des images et les entités dérivées du texte étaient déconnectées. L'étape de fusion de RAG Anything s'assure qu'elles sont liées. Si le texte mentionne « revenus du Q3 » et qu'un graphique à barres montre des données de revenus du Q3, les deux entités existent dans le même graphe de connaissances avec des relations qui se chevauchent. La couche de récupération peut puiser dans les deux sources pour construire une réponse complète.

Et voici la partie que je n'avais pas anticipée : la base de données fusionnée de RAG Anything se combine ensuite avec votre base de données LightRAG existante. Si vous utilisiez déjà LightRAG avec des documents textuels, RAG Anything ne les écrase pas. Il y ajoute. Vous vous retrouvez avec une base de données vectorielle consolidée et un graphe de connaissances consolidé couvrant tout -- vos documents textuels originaux ET vos documents multimodaux nouvellement ingérés.

L'expérience de requête ne change pas du tout. Même API. Mêmes prompts en langage naturel. Mêmes modes de récupération. Le système gère la complexité de la récupération multi-sources et multi-modales en coulisses.

Cette fluidité est ce qui m'a convaincu de l'adopter. Je n'avais rien à reconstruire. Je n'avais pas à changer mes patterns de requête. J'ai simplement gagné la capacité d'ingérer une toute nouvelle catégorie de documents.

Comment j'ai Tout Configuré (Étape par Étape)

Je ne vais pas vous cacher la réalité : la configuration initiale est plus lourde que LightRAG vanilla. Vous ajoutez un parseur de documents avec des modèles de ML, un moteur OCR et des dépendances Python supplémentaires. Mais une fois configuré, l'expérience quotidienne est fluide.

Voici la configuration exacte que j'ai suivie.

Étape 1 : S'assurer que LightRAG fonctionne déjà.

Si vous n'avez pas encore configuré LightRAG, commencez par là. RAG Anything s'enroule autour de LightRAG -- il a besoin d'une installation fonctionnelle pour l'étendre. Le dépôt GitHub de LightRAG a des instructions claires. Je faisais tourner LightRAG avec l'interface basée sur Docker, qui vous donne une interface web pour télécharger des documents textuels et interroger le graphe de connaissances.

Étape 2 : Installer RAG Anything et ses dépendances.

RAG Anything est installable via pip :

pip install raganything

Cela installe le framework principal. Mais vous avez aussi besoin de MinerU pour le parsing de documents :

pip install mineru

La première fois que MinerU s'exécute, il télécharge ses modèles de détection de mise en page et de classification. Prévoyez environ 2 Go de téléchargements. PaddleOCR est inclus comme dépendance de MinerU, vous n'avez donc pas besoin de l'installer séparément.

Étape 3 : Utiliser le prompt de configuration one-shot de Claude Code.

C'est la partie qui m'a économisé des heures. Le dépôt de RAG Anything inclut un prompt Claude Code qui automatise la configuration :

• Met à jour les chemins de stockage pour correspondre à votre répertoire de données LightRAG existant
• Configure les modèles d'IA (GPT-4o mini pour l'extraction d'entités, text-embedding-3-large pour les embeddings par défaut)
• Corrige un bug connu où les embeddings sont doublement encapsulés lors de l'étape de fusion

J'ai exécuté le prompt dans Claude Code pointé vers mon répertoire de projet LightRAG, et il a géré la configuration en environ 90 secondes. Sans ça, j'aurais dû éditer manuellement les fichiers de configuration et probablement lutter contre le bug du double-wrap pendant une heure avant de trouver l'issue GitHub à ce sujet.

Étape 4 : Configurer vos clés API.

RAG Anything a besoin d'accès à un LLM avec des capacités de vision pour le traitement des images. J'ai utilisé GPT-4o mini parce que le coût est faible et la qualité de vision est solide pour l'interprétation de graphiques et de diagrammes. Vous aurez besoin de votre clé API OpenAI configurée dans l'environnement ou le fichier de configuration.

Pour les embeddings, le défaut est text-embedding-3-large. La même clé API couvre ça.

Étape 5 : Tester avec un document simple.

Avant de lui lancer des PDFs scannés complexes, j'ai testé avec un document d'une page contenant un paragraphe de texte et un graphique à barres. Cela valide que MinerU parse correctement, que PaddleOCR extrait le texte, que le modèle de vision interprète le graphique et que l'étape de fusion produit une base de données unifiée.

from raganything import RAGAnything

rag = RAGAnything(
    working_dir="./rag_storage",
    llm_model="gpt-4o-mini",
    embedding_model="text-embedding-3-large"
)

# Ingérer un document multimodal
rag.insert("./test_document.pdf")

# Interroger sur le contenu textuel et visuel
result = rag.query("Que montre le graphique à barres sur les revenus ?")
print(result)

Quand ça a renvoyé des données numériques réelles du graphique -- pas une description du graphique, mais les valeurs spécifiques qu'il contenait -- j'ai su que la pipeline fonctionnait.

Étape 6 : Ingérer vos vrais documents.

Voici un détail opérationnel important : l'ingestion de documents non textuels ne peut pas se faire via l'interface web de LightRAG. L'interface ne connaît pas MinerU ou l'architecture à double pipeline. Vous devez exécuter l'ingestion via le script Python (ou une skill Claude Code qui l'enrobe).

Les documents textuels peuvent toujours passer par l'interface LightRAG comme d'habitude. Seuls les documents multimodaux ont besoin de l'approche basée sur le script.

Après l'ingestion, j'ai trouvé que redémarrer le container Docker exécutant l'interface LightRAG était parfois nécessaire pour qu'il reconnaisse la base de données nouvellement fusionnée. Pas à chaque fois, mais assez souvent pour que j'aie ajouté un redémarrage de container à mon script d'ingestion.

Si vous préférez que quelqu'un construise ce genre de pipeline de zéro pour votre flux de travail de documents spécifique, je prends des projets d'intégration d'IA. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Conseil pro : Passer MinerU au traitement GPU. Sur CPU, MinerU est fonctionnel mais lent pour les grands documents. Si vous avez un GPU NVIDIA (ou un Mac série M avec support Metal), configurer MinerU pour utiliser l'accélération GPU fait une différence dramatique. Mon PDF scanné de 50 pages est passé de 45 secondes à 12 secondes. Claude Code peut vous aider à modifier la configuration de MinerU pour activer le GPU -- c'est un changement de flag de configuration, pas une réinstallation.

Ce Que J'ai Vraiment Fait Passer (Et Ce Qui Est Revenu)

Le vrai test était ce rapport financier. 47 pages. Scanné depuis un document imprimé. Graphiques à barres montrant les revenus mensuels de janvier à septembre 2025. Tableaux rendus sous forme d'images. Logos d'entreprises. Notes de bas de page en petits caractères. Le genre de document qui représente le pire cas pour le RAG traditionnel.

Je l'ai fait passer par le script d'ingestion et j'ai regardé les logs. MinerU a traité chaque page, classifié les composants et les a divisés dans les deux seaux. PaddleOCR a extrait le texte des paragraphes principaux et des en-têtes. Les graphiques à barres, tableaux et logos sont allés dans le seau d'images. Le LLM a traité les deux seaux, extrait les entités et relations, généré des embeddings et fusionné tout dans la base de données unifiée.

Temps de traitement total : environ 3 minutes pour les 47 pages sur GPU. Coût API pour les appels au LLM : environ 0,08 $. Le traitement local (MinerU + PaddleOCR) était gratuit.

Puis je l'ai interrogé.

« Quelles étaient les tendances des revenus mensuels de janvier à septembre 2025 ? »

La réponse est arrivée avec des chiffres spécifiques. Janvier : 1,2 M$. Février : 1,4 M$. Mars : 1,3 M$. Jusqu'à septembre : 2,1 M$. Il a identifié la tendance générale à la hausse, noté la baisse en mars et référencé l'accélération du Q3. Ces données n'existaient que dans un graphique à barres. Il n'y avait pas de texte dans le document qui listait ces chiffres. Le modèle de vision avait lu le graphique, extrait les valeurs, créé des entités pour chaque point de données et construit des relations entre eux dans le graphe de connaissances.

J'ai exécuté une deuxième requête : « Quels départements ont montré la plus forte croissance ? »

Celle-ci a puisé dans les deux modalités. Les sections textuelles du rapport discutaient des performances départementales en prose. Les graphiques montraient les chiffres. La réponse a combiné les deux -- citant des pourcentages de croissance spécifiques des graphiques et une analyse contextuelle du texte. Récupération unifiée, fonctionnant exactement comme prévu.

Pour comparaison, j'ai fait passer le même document par mon ancienne pipeline -- LightRAG vanilla avec extraction de texte basique. La première requête n'a rien retourné d'utile. La deuxième requête a retourné un vague paragraphe du résumé exécutif qui mentionnait « de bonnes performances départementales » sans aucun chiffre. Nuit et jour.

Les Compromis Honnêtes Que Personne ne Mentionne

RAG Anything est impressionnant. Il a véritablement résolu un problème avec lequel je me débattais depuis des mois. Mais il n'est pas sans friction, et je vous rendrai un mauvais service si je n'expose pas clairement les inconvénients.

La configuration est plus lourde que LightRAG vanilla. Vous faites tourner les modèles de ML de MinerU localement, ce qui signifie télécharger ~2 Go de poids de modèles, gérer des dépendances Python supplémentaires et faire face à des conflits de version occasionnels entre PaddleOCR et d'autres packages. Ma première tentative d'installation a échoué à cause d'une incompatibilité de version numpy entre MinerU et une autre bibliothèque dans mon environnement. Un environnement virtuel propre a réglé ça, mais le débogage m'a coûté 30 minutes.

L'ingestion non textuelle nécessite la ligne de commande. Vous ne pouvez pas faire glisser-déposer un PDF scanné dans l'interface web de LightRAG et le faire traiter par la pipeline multimodale. Vous devez exécuter le script Python. Pour un développeur, c'est un inconvénient mineur. Pour quelqu'un qui espérait un flux de travail purement basé sur une GUI, c'est une limitation.

Les redémarrages du container Docker après l'ingestion sont pénibles. L'interface LightRAG ne détecte pas toujours immédiatement la base de données fusionnée. Redémarrer le container est une solution de 10 secondes, mais elle interrompt toute session active. J'ai vu cela se produire environ 60% du temps après l'ingestion multimodale.

La précision du modèle de vision varie. GPT-4o mini fait un bon travail pour interpréter les graphiques à barres standard, les graphiques en courbes et les tableaux simples. Mais il peine avec les nuages de points denses, les diagrammes de flux complexes et les graphiques avec des étiquettes qui se chevauchent. J'avais une infographie avec une matrice codée par couleurs où le modèle a mal identifié deux des six catégories. Pour les données financières critiques, je recommande de vérifier par sondage les entités extraites par rapport au document source.

Le coût s'échelonne avec le nombre d'images, pas la longueur du document. Chaque image dans le seau d'images fait un appel API séparé au modèle de vision. Un document de 10 pages avec 2 graphiques coûte à peu près autant qu'un document de 100 pages en texte seul. Mais un document de 10 pages avec 30 images intégrées ? Ce sont 30 appels à l'API de vision. Le coût par appel est faible (des fractions de centime avec GPT-4o mini), mais ça s'accumule si vous traitez des documents riches en images à grande échelle. Surveillez votre utilisation pour les premiers lots.

La classification de MinerU n'est pas parfaite. Environ 5% du temps dans mes tests, MinerU a mal classifié un bloc de texte comme image ou vice versa. Un paragraphe rendu dans une police inhabituelle a été capturé comme capture d'écran au lieu d'être traité par OCR. Une image d'en-tête décorative a été envoyée à la pipeline OCR au lieu de la pipeline de vision. Ces cas particuliers ne cassent pas le système -- ils signifient simplement que certains contenus sont traités par le chemin moins optimal.

Malgré ces compromis, le résultat net est écrasantement positif. Je suis passé d'un système RAG qui pouvait gérer peut-être 30% de mes documents réels à un qui en gère 90%+. Ce bond de couverture a changé le type de questions que je pouvais poser et le type de flux de travail que je pouvais construire.

Vers Où Ça Va (Et Ce Que Je Surveille)

RAG Anything a été lancé début 2026 et il est déjà à un point où je le considère comme prêt pour la production pour la plupart des cas d'usage. Mais il y a quelques développements que je surveille.

MinerU-Diffusion, un article de recherche de l'équipe MinerU publié en 2026, propose de traiter l'OCR de documents comme un « rendu inverse » en utilisant des modèles de diffusion. Si cela arrive dans MinerU en production, le bond de qualité de l'OCR pourrait être significatif -- particulièrement pour les scans dégradés et les annotations manuscrites.

Support multi-parseur. RAG Anything prend déjà en charge MinerU et Docling comme parseurs de documents, sélectionnant automatiquement le meilleur en fonction du type de document. À mesure que d'autres parseurs seront ajoutés, la couverture des formats de documents de cas particuliers continuera à s'élargir.

Intégration de LLM local. Pour l'instant, les étapes d'extraction d'entités et de description d'images nécessitent un LLM en cloud avec des capacités de vision. Mais la communauté Ollama expérimente déjà avec RAG Anything contre des modèles de vision locaux comme LLaVA. Si les modèles de vision locaux atteignent la qualité de GPT-4o mini pour l'interprétation de graphiques, toute la pipeline pourrait fonctionner sans aucun appel API cloud. Zéro donnée quittant votre machine. Zéro coût par document après la configuration initiale.

La propre évolution de LightRAG. LightRAG a dépassé les 28 000 étoiles GitHub début 2026 et a été accepté à EMNLP 2025. Le projet est activement maintenu avec des mises à jour incrémentielles qui ne perturbent pas la structure du graphe -- ce qui signifie que l'étape de fusion de RAG Anything devrait rester compatible au fur et à mesure que LightRAG évolue.

La tendance plus large est claire : les systèmes RAG passent du texte seul au véritablement multimodal. La question n'est pas de savoir si votre pipeline RAG devra gérer des images et des graphiques. C'est de savoir si vous serez prêt quand le prochain document important arrivera sur votre bureau sous forme de PDF scanné plein de données visuelles.

La Configuration Qui Fonctionne Pour Moi En Ce Moment

Après deux semaines d'utilisation quotidienne, voici la configuration sur laquelle je me suis stabilisé :

• Parseur de documents : MinerU avec accélération GPU activée
• Moteur OCR : PaddleOCR (inclus avec MinerU) -- gère mes documents en anglais et bengali sans problèmes
• LLM pour l'extraction d'entités : GPT-4o mini -- rapide, bon marché et suffisamment bon pour l'interprétation de graphiques
• Modèle d'embedding : text-embedding-3-large -- la différence de qualité par rapport aux modèles plus petits est notable dans la précision de récupération
• Stockage : Système de fichiers local avec volumes Docker pour l'interface LightRAG
• Flux d'ingestion : Skill Claude Code qui enrobe le script d'ingestion Python, gère le redémarrage du container et journalise les statistiques de traitement
• Interface de requête : Interface web LightRAG pour les requêtes ad-hoc, API Python pour l'accès programmatique

Le coût mensuel total pour faire tourner cette configuration sur ma bibliothèque de documents est d'environ 3 à 5 $ en appels API. La majeure partie de ça concerne l'ingestion initiale de documents riches en images. Une fois les documents ingérés, les requêtes frappent d'abord le graphe de connaissances local et la base de données vectorielle -- le LLM n'est appelé que pour la génération de réponses, pas pour la récupération.

Pour contexte, mon approche précédente -- faire passer chaque image par l'API de vision de GPT-4o comme étape de prétraitement -- me coûtait 15 à 20 $ par mois pour une bibliothèque de documents plus petite. Le parsing local-first de RAG Anything avec un traitement cloud sélectif a réduit mes coûts d'environ 75%.

Ce Qui Vient Ensuite Si Vous Voulez Construire Ça

Voici ce que je ferais si je repartais de zéro aujourd'hui.

Premièrement, faites fonctionner LightRAG vanilla. Ingérez quelques documents textuels. Exécutez quelques requêtes. Comprenez comment fonctionne le graphe de connaissances, comment les entités et les relations sont extraites et comment se comporte la récupération à deux niveaux (niveau bas pour les faits spécifiques, niveau haut pour les thèmes conceptuels). Mon article précédent sur la construction de systèmes de recherche en IA couvre les patterns de gestion des connaissances qui s'appliquent ici.

Deuxièmement, installez RAG Anything et MinerU dans un environnement virtuel propre. Ne le mélangez pas avec d'autres projets de ML -- l'arbre de dépendances est assez profond pour que les conflits de version soient probables si vous partagez un environnement.

Troisièmement, testez avec un seul document, modérément complexe. Pas votre cas le plus difficile. Quelque chose avec un mélange de texte et quelques graphiques. Vérifiez que les quatre structures de données sont générées et fusionnées correctement.

Quatrièmement, élargissez progressivement. Ajoutez plus de documents. Essayez différents types -- PDFs scannés, présentations, rapports riches en images. Notez où la qualité de classification ou d'extraction baisse et si ça a de l'importance pour vos requêtes.

Cinquièmement, mettez en place l'automatisation de l'ingestion. Que ce soit une skill Claude Code, un cron job ou un script manuel que vous exécutez chaque semaine -- ayez un processus fiable pour introduire de nouveaux documents dans la pipeline.

L'écart entre « j'ai des documents » et « je peux interroger mes documents intelligemment » était autrefois énorme pour tout ce qui dépasse le texte propre. RAG Anything réduit cet écart à quelque chose de gérable. Pas à zéro -- la configuration est un vrai travail. Mais gérable.

Ce rapport financier qui est resté trois semaines sur mon bureau ? Je l'interroge quotidiennement maintenant. Mardi dernier, un client a demandé les schémas saisonniers des revenus et j'avais la réponse -- avec des chiffres mensuels spécifiques extraits de graphiques à barres scannés -- en moins de dix secondes. Pas parce que j'avais mémorisé les données. Parce que j'ai construit un système qui comprend vraiment les documents que je lui donne, données visuelles et tout.

Le PDF scanné a cessé d'être un fichier mort au moment où j'ai cessé de traiter les images comme des citoyens de seconde classe dans ma pipeline RAG.

Questions Fréquemment Posées

RAG Anything peut-il traiter des documents sans aucun appel API cloud ?

La phase de parsing de documents (MinerU + PaddleOCR) tourne entièrement en local sans aucun appel cloud. L'extraction d'entités et la génération d'embeddings nécessitent actuellement un LLM cloud avec des capacités de vision, bien que des alternatives locales utilisant Ollama et LLaVA soient en développement actif par la communauté.

Quels formats de documents RAG Anything prend-il en charge ?

RAG Anything gère les PDFs (natifs et scannés), DOCX, PPTX, XLSX et les formats d'image courants. MinerU identifie les composants de mise en page dans tous ceux-ci, routant automatiquement le texte vers l'OCR et les éléments visuels vers la capture d'écran.

Combien coûte l'exécution de RAG Anything par document ?

Les documents en texte seul coûtent des fractions de centime. Pour les documents riches en images, chaque élément visuel fait un appel API de vision LLM -- environ 0,001 à 0,003 $ par image avec GPT-4o mini. Un PDF scanné de 50 pages avec 20 graphiques coûte environ 0,04 à 0,08 $ au total. Pour le détail complet des coûts, voir la section de configuration ci-dessus.

RAG Anything remplace-t-il LightRAG ?

Non. RAG Anything est un wrapper qui étend LightRAG avec des capacités multimodales. Votre base de données LightRAG existante, le graphe de connaissances et l'interface de requête restent inchangés. RAG Anything y ajoute en fusionnant des données multimodales dans les mêmes structures unifiées.

Quelle est la précision de l'extraction des données de graphiques et de diagrammes ?

Pour les graphiques à barres standard, les graphiques en courbes et les tableaux simples, la précision est élevée -- GPT-4o mini identifie correctement les valeurs et les tendances dans la grande majorité des cas. La précision baisse avec les nuages de points denses, les étiquettes qui se chevauchent et les graphiques complexes à axes multiples. Vérifiez les données financières critiques par rapport aux documents sources.

Travaillons Ensemble

Vous voulez construire des systèmes d'IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? J'adorerais vous aider.

• Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io