1. Le fonctionnement du RAG (Retrieval-Augmented Generation) dans le cadre d'une utilisation avec des LLM locaux, incluant de la documentation, des exemples concrets en Python avec LangChain et LlamaIndex, ainsi que des cas d’usage industriels.
    
2. Les fonctionnalités complètes, cas d’usage, retours d’expérience et exemples de pipeline autour de la plateforme Ragflow.io.
    
3. L’organisation optimale de ton usage professionnel de Ragflow, avec recommandations sur l’organisation des KB (normes, essais, formules, etc.), l’utilisation de LLM vision, le chunking par type de document, l’intégration avec des agents, et une proposition d’architecture personnalisée.
    
# Systèmes RAG (Retrieval-Augmented Generation) avec LLM Locaux

Les systèmes de **Retrieval-Augmented Generation (RAG)** combinent la recherche d’information dans une base de connaissances avec la génération en langage naturel par un modèle de langage. L’objectif est de pallier les limites d’un LLM (Large Language Model) « pur » en lui fournissant du contexte **à jour et spécifique au domaine** lors de la génération des réponses ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=1,order%20to%20provide%20an%20answer)) ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=A%20different%20approach%20is%20to,as%20text%20and%2For%20image%20data)). Cela est particulièrement utile avec des **LLM locaux** (exécutés en interne sans appel à une API cloud), car ceux-ci peuvent être limités en connaissances entraînées ou nécessiter des données métier confidentielles non incluses dans leurs corpus d’entraînement.

## Fonctionnement du Pipeline RAG

Un pipeline RAG typique comporte deux grandes phases : **(1) Indexation** des connaissances et **(2) Récupération + Génération** lors des requêtes. Chaque phase comporte plusieurs étapes clés  ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=A%20different%20approach%20is%20to,as%20text%20and%2For%20image%20data)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=In%20conclusion%2C%20RAGFlow%20stands%20as,content%2C%20including%20charts%2C%20diagrams%2C%20and)) :

- **Chargement des documents sources** : On commence par collecter les données métier (textes, documents PDF, rapports, etc.). Des _loaders_ spécialisés sont utilisés pour extraire le texte de différents formats (fichiers locaux, pages web, bases de données…). Par exemple, LangChain propose des `DocumentLoader` pour lire des PDFs ou du texte brut, tandis que LlamaIndex (ex-GPT Index) offre `SimpleDirectoryReader` ou des loaders pour DataFrames Pandas, etc ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=Loaders%20are%20essential%20for%20loading,loaders%20for%20common%20document%20types)) ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=Code%20Example%3A%20Loading%20a%20Text,Document%20in%20LlamaIndex)).
    
- **Chunking (découpage en morceaux)** : Les documents sont ensuite découpés en segments de texte de taille gérable (appelés _chunks_), en veillant à ne pas briser le contexte pertinent. Cela permet de **respecter les limites de tokens** du LLM tout en conservant la cohérence sémantique ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=Splitters%20help%20break%20large%20documents,models%20like%20GPT%20or%20BERT)). Les frameworks proposent des _text splitters_ configurables. Par exemple, LangChain utilise des `TextSplitter` (taille fixe, découpage par phrases, par paragraphe, etc.), et LlamaIndex permet aussi de choisir la taille en tokens de chaque chunk ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=In%20LlamaIndex%2C%20you%20can%20specify,grained%20control%20over%20chunk%20size)). Une bonne stratégie de chunking est cruciale : des chunks trop grands risquent de dépasser la fenêtre du modèle, tandis que des chunks trop petits peuvent perdre le contexte ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=This%20can%20be%20manuals%2C%20online,as%20text%20and%2For%20image%20data)).
    
- **Encodage et Indexation** : Chaque chunk est converti en **vecteur d’embedding** (représentation numérique) grâce à un modèle d’embedding sémantique. Ces vecteurs sont stockés dans une **base vectorielle** qui permettra la recherche par similarité de cosinus. Par exemple, avec LangChain on peut créer un index FAISS ou Milvus en appelant `FAISS.from_documents(chunks, embedding_model)` ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=from%20langchain,openai%20import%20OpenAIEmbeddings)). LlamaIndex fournit des structures comme `GPTVectorIndex` ou `GPTTreeIndex` pour indexer les documents ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=LlamaIndex%20simplifies%20indexing%20through%20its,like%20structure%20for%20efficient%20retrieval)). L’indexation rend la recherche future très rapide, même sur des milliers de documents, en retrouvant les chunks les plus pertinents via leurs vecteurs ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=Indexing%20is%20the%20heart%20of,based%20on%20a%20user%20query)) ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=,OpenAIEmbeddings)).
    
- **Recherche de documents pertinents (Retrieval)** : Lorsqu’une question utilisateur est posée, le système convertit la requête elle-même en vecteur (via le même modèle d’embedding) puis effectue une **recherche de similarité** dans la base vectorielle. On obtient ainsi les _k_ meilleurs chunks correspondants (par ex. les 3–5 passages jugés les plus similaires à la question) ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=This%20can%20be%20manuals%2C%20online,as%20text%20and%2For%20image%20data)). Certains systèmes combinent plusieurs modes de recherche (_hybrid search_) : recherche vectorielle sémantique, recherche lexicale type BM25, etc., afin d’améliorer la pertinence – c’est ce qu’on appelle parfois **“multiple recall”** (rappel multiple) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=1,leads%20to%20the%20integration%20of)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=The%20two%20issues%20highlighted%20above,a%20broader%20audience%20of%20both)). L’objectif est de trouver les _“nouvelles connaissances”_ à fournir au modèle de langue.
    
- **Génération de la réponse (Generation)** : Enfin, ces chunks de connaissances sont concaténés (généralement avec une invite/prompt gabarit) et fournis en **contexte additionnel** au LLM pour générer la réponse finale ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=This%20can%20be%20manuals%2C%20online,as%20text%20and%2For%20image%20data)). Le modèle intègre ces informations externes dans son raisonnement, ce qui permet d’obtenir des réponses précises et **actualisées**, tout en réduisant les hallucinations (puisque le LLM s’appuie sur du contenu factuel) ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=Instead%20an%20embedding%20is%20computed,LLM%20to%20formulate%20the%20answer)). On utilise souvent une _chaîne_ ou _pipeline_ qui combine le récupérateur et le LLM. Par exemple, LangChain propose la chaîne `RetrievalQA` qui prend un retriever (interface de l’index vectoriel) et un LLM pour retourner directement la réponse ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=from%20langchain,llms%20import%20OpenAI)). Avec LlamaIndex, on peut créer un objet `query_engine` à partir de l’index et simplement appeler `query_engine.query("...")` pour obtenir la réponse avec citations ([LangChain vs. LlamaIndex, A Comprehensive Comparison for Retrieval-Augmented Generation (RAG) | by Tamanna | Medium](https://medium.com/@tam.tamanna18/langchain-vs-llamaindex-a-comprehensive-comparison-for-retrieval-augmented-generation-rag-0adc119363fe#:~:text=LlamaIndex%20provides%20a%20similar%20approach,retrieval%20and%20language%20model%20generation)).
    

([RAG (Retrieval Augmented Generation) with LlamaIndex, Elasticsearch and Mistral - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/rag-with-llamaIndex-and-elasticsearch)) _Figure: Schéma simplifié d’un pipeline RAG. Durant la phase d’indexation (haut), les documents sont chargés, découpés en chunks, puis encodés et stockés dans une base vectorielle (ici Elasticsearch via LlamaIndex). Lors d’une requête (bas), le système retrouve les _Top K_ chunks les plus similaires, les envoie avec la question au LLM local (ex: Mistral 7B), qui produit alors une réponse en langage naturel ([RAG (Retrieval Augmented Generation) with LlamaIndex, Elasticsearch and Mistral - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/rag-with-llamaIndex-and-elasticsearch#:~:text=In%20this%20blog%20we%20will,a%20locally%20running%20Mistral%20LLM)) ([RAG (Retrieval Augmented Generation) with LlamaIndex, Elasticsearch and Mistral - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/rag-with-llamaIndex-and-elasticsearch#:~:text=Mistral%20provides%20both%20open,right%20API%20keys%20and%20packages))._

Chaque composant du pipeline RAG peut être ajusté en fonction des besoins industriels : choix du modèle d’embedding (généraliste vs spécialisé domaine), méthode de chunking (taille fixe ou basée sur la structure du document), type de vecteur store (FAISS en mémoire, ElasticSearch, ChromaDB, etc.), et bien sûr choix du LLM (en local, calibré selon le niveau de performance souhaité).

**Pourquoi RAG + LLM local ?** Un LLM local, hébergé sur site (on-premise), présente l’avantage de la **confidentialité** (les données sensibles ne quittent pas l’entreprise) et du contrôle des coûts une fois le modèle déployé. Cependant, il peut ne pas connaître les données spécifiques de l’entreprise si on ne l’a pas finement entraîné dessus. Le RAG vient combler ce manque de connaissance : on évite de réentraîner le modèle pour chaque mise à jour de documents, on injecte simplement les données à la volée dans le prompt ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=One%20approach%20to%20reduce%20these,approach%20is%20not%20commercially%20viable)). Cela **évite un fine-tuning coûteux** (en données, expertise et calcul) tout en maintenant les réponses à jour (puisque la base documentaire peut être enrichie en continu). En pratique, on observe que pour de nombreuses applications industrielles, un pipeline RAG bien conçu est plus **rapide à mettre en œuvre et à généraliser** qu’un entraînement sur-mesure d’un modèle de langage ([RAG vs. Fine-Tuning: Which is Better? - Stack AI](https://www.stack-ai.com/blog/fine-tuning-vs-rag#:~:text=RAG%20vs.%20Fine,tuning%20is%20better)) ([A New Study Compares RAG & Fine-Tuning For Knowledge Base ...](https://cobusgreyling.medium.com/a-new-study-compares-rag-fine-tuning-for-knowledge-base-use-cases-fa2383357fba#:~:text=A%20New%20Study%20Compares%20RAG,Tuned)). Par exemple, une étude récente sur la sécurité dans la construction a montré qu’un système RAG spécialisé améliorait la précision des réponses de **21,5%** par rapport à un LLM générique GPT-4, rivalisant ainsi avec un LLM finetuné sur le domaine (qui améliorait de 26%) ([Performance comparison of retrieval-augmented generation and ...](https://www.sciencedirect.com/science/article/abs/pii/S092658052400582X#:~:text=,The%20findings%20highlight)).

### Exemple de Pipeline RAG avec LangChain (Python)

Le code ci-dessous illustre sommairement comment mettre en place un pipeline RAG en Python à l’aide de **LangChain** et d’un modèle local (pour l’exemple on considère un modèle type Llama-2 déployé localement via HuggingFace Transformers) :

```python
# 1. Charger les documents (texte brut par ex.)
from langchain.document_loaders import TextLoader
loader = TextLoader("data/manuel_beton.txt", encoding='utf-8')
documents = loader.load()  # liste de Document

# 2. Chunking des documents en morceaux de 500 tokens max
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs_chunks = text_splitter.split_documents(documents)

# 3. Création des embeddings et de l’index vectoriel (FAISS ici)
from langchain.embeddings import HuggingFaceEmbeddings
embedding_model = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
from langchain.vectorstores import FAISS
vector_index = FAISS.from_documents(docs_chunks, embedding_model)

# 4. Initialisation du modèle de langage local (ex: Llama-2 13B en local)
from langchain.llms import HuggingFacePipeline
local_llm = HuggingFacePipeline.from_model_id(model_id="TheBloke/Llama-2-13B-chat-hf", task="text-generation")

# 5. Construction de la chaîne QA avec récupération
from langchain.chains import RetrievalQA
qa_chain = RetrievalQA(combine_documents_chain=None, retriever=vector_index.as_retriever(), llm=local_llm)

# 6. Pose d’une question
query = "Quelle est la résistance caractéristique du béton C30/37 ?"
result = qa_chain.run(query)
print(result)
```

Dans cet exemple, LangChain facilite chaque étape : chargement du fichier `manuel_beton.txt`, découpage en chunks de ~500 tokens avec chevauchement, création d’un index vectoriel FAISS à l’aide d’un modèle d’embedding (MiniLM dans l’exemple), puis configuration d’une chaîne de type Questions/Réponses (`RetrievalQA`) combinant cet index et un LLM local. La requête utilisateur (« Quelle est la résistance caractéristique du béton C30/37 ? ») est transformée en vecteur, les passages pertinents sont récupérés, et le LLM génère une réponse en français sur la base de ces passages.

> **Remarque :** On peut tout à fait utiliser des bases vectorielles industrielles plus robustes à la place de FAISS, par exemple Milvus, RedisVector, Elasticsearch, etc., via les connecteurs fournis dans LangChain. De même, pour le LLM local, on pourrait utiliser une interface `LLMChain` avec un pipeline custom HuggingFace (comme montré) ou une API locale comme **Ollama** ou **FastAPI**. L’important est que le LLM accepte en entrée le contexte (chunks concaténés + question) et produise la réponse augmentée.

### Exemple de Pipeline RAG avec LlamaIndex (Python)

LlamaIndex (anciennement GPT Index) offre une approche intégrée pour construire des applications RAG. Il gère la lecture, l’indexation et les requêtes de façon plus « haut niveau ». Voici un exemple d’utilisation de **LlamaIndex** (alias `llama_index` en Python) :

```python
# 1. Charger des documents d’un dossier
from llama_index import SimpleDirectoryReader, GPTVectorStoreIndex, LLMPredictor, PromptHelper
docs = SimpleDirectoryReader('./data/rapports_essais').load_data()

# 2. Initialiser l’index vectoriel avec un LLM local pour la synthèse
from llama_index import ServiceContext
from transformers import pipeline
local_model = pipeline('text-generation', model='NousResearch/LLaMA2-7b-hf')  # modèle local
llm_predictor = LLMPredictor(llm=local_model)
# Configurer éventuellement un prompt helper (longueur max, etc.)
service_context = ServiceContext.from_defaults(llm_predictor=llm_predictor, chunk_size_limit=512)

index = GPTVectorStoreIndex.from_documents(docs, service_context=service_context)

# 3. Construire un moteur de requête à partir de l’index
query_engine = index.as_query_engine(response_mode="compact")

# 4. Poser une question via le moteur de requête
response = query_engine.query("Donnez un résumé des résultats pour l'éprouvette 7J du test 2023-04.")
print(response.response)
print(response.get_sources())  # éventuellement afficher les sources utilisées
```

Ici, LlamaIndex prend en charge l’indexation vectorielle via `GPTVectorStoreIndex.from_documents`. On lui fournit la liste des documents bruts, ainsi qu’un `ServiceContext` qui peut inclure le LLM (ou un wrapper) à utiliser pour certaines opérations internes. Dans cet exemple, on configure un pipeline HuggingFace pour un modèle local LLaMA-2 7B afin que LlamaIndex l’utilise pour générer les réponses (**Note:** LlamaIndex peut en réalité utiliser un LLM différemment de LangChain – il peut même s’appuyer sur OpenAI ou autres en interne, mais on privilégie un usage local). L’appel `query_engine.query()` va automatiquement effectuer la recherche des passages pertinents et retourner la réponse formulée, que l’on peut obtenir via `response.response`. Si configuré, `response.get_sources()` fournit les références des documents utilisés, permettant d’afficher des citations ou des liens (ce qui est essentiel dans un contexte industriel pour **vérifier les sources** de la réponse générée).

### Cas d’usages concrets en milieu industriel

Les pipelines RAG avec LLM présentent un intérêt fort pour **diffuser la connaissance technique** dans l’entreprise de façon naturelle (chatbot, assistant virtuel) tout en garantissant que les réponses sont appuyées sur la documentation interne. Quelques exemples dans le secteur **BTP / matériaux (comme le béton)** :

- **Assistance aux ingénieurs et techniciens** : un assistant pourrait répondre aux questions sur les _normes_ de construction (Eurocodes, DTU…) ou sur des _procédures internes_. Par exemple, « Quelle est la durée de cure recommandée pour un béton haute performance selon la norme X ? » – le système ira chercher dans la norme PDF correspondante le passage adéquat et le LLM local formulera la réponse en citant la norme. De même, sur chantier, un contremaître pourrait demander « Quels sont les EPI requis pour le coulage d’une dalle selon notre protocole ? » et obtenir immédiatement une réponse fondée sur le manuel HSE de l’entreprise, à jour.
    
- **Recherche dans les rapports d’essais et données techniques** : Les entreprises de matériaux accumulent de nombreux rapports de laboratoire (essais de compression, de flexion, analyses chimiques, etc.). Un système RAG peut permettre de _questionner ces données historiques_. Par exemple : « Quel a été le taux de compression moyen à 28 jours pour la formule de béton XYZ utilisée sur le projet ABC ? ». Le RAG va retrouver le rapport d’essai correspondant dans la base documentaire et fournir la valeur avec la référence du rapport. Cela évite de parcourir manuellement des dizaines de rapports PDF. On peut aussi imaginer des résumés générés sur mesure, par ex. « Résume-moi les différences de performances entre la formule A et B ».
    
- **Support client et commercial** : Dans le cas d’un fournisseur de béton, un assistant client interne pourrait répondre aux questions techniques des clients ou de l’équipe commerciale. Par exemple « Quel béton recommandez-vous pour une résistance au gel/dégel extrême ? » – L’assistant pourrait rechercher dans des fiches techniques produit et fournir la recommandation (e.g. un béton spécifique additivé, en citant la fiche technique). Il pourrait aussi retrouver des cas d’application similaires dans la base de données projets de l’entreprise. Cela améliore la réactivité du support tout en garantissant la précision (réponses étayées par les documents).
    
- **Gestion des connaissances de chantier** : Sur les gros projets, on produit des _retours d’expérience_ (REX), des comptes-rendus, des plans avec annotations, etc. Un assistant RAG pourrait permettre aux nouveaux ingénieurs de consulter ces connaissances facilement en langage naturel. Ex: « Quelles ont été les principales difficultés rencontrées lors du coulage du pont XYZ et comment ont-elles été résolues ? ». L’assistant pourrait extraire la réponse depuis le rapport de fin de chantier correspondant.
    

Ces exemples illustrent comment RAG répond au besoin de **recherche précise dans un corpus documentaire volumineux et hétérogène**, tout en fournissant une réponse directe en langage naturel. On gagne en **productivité** (accès instantané à l’info) et en **fiabilité** (la source étant citée, l’utilisateur peut vérifier le document original).

Notons qu’en environnement industriel, la qualité des documents sources est variable (scans PDF, tableaux, formules…). Un bon système RAG devra donc s’appuyer sur des méthodes robustes de **compréhension de documents** (extraction de texte fiable, y compris OCR sur images, traitement des tableaux, etc.) et éventuellement de **nettoyage** avant l’indexation. En effet, _Garbage In, Garbage Out_ – si la donnée est mal indexée (par ex. texte désorganisé), le LLM produira des réponses erronées ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=along%20with%20a%20fancy%20UI%2C,%E2%80%9D)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=The%20two%20issues%20highlighted%20above,a%20broader%20audience%20of%20both)). C’est pourquoi des solutions apparaissent pour améliorer cette étape d’ingestion, comme nous allons le voir avec **RAGFlow**.

## Synthèse à jour sur RAGFlow.io (Mars 2025)

**RAGFlow** (site officiel : ragflow.io) est un moteur open-source de RAG lancé en 2024, qui propose une solution _clé en main_ pour créer des assistants type question-réponse basés sur des documents. Il se distingue par un accent mis sur la **compréhension profonde des documents** (Deep Document Understanding) et sur la facilité d’utilisation via une interface graphique (dashboard) complète. RAGFlow a été open-sourcé le 1ᵉʳ avril 2024 et a déjà été adopté par plusieurs entreprises, avec des mises à jour fréquentes jusqu’en 2025 ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=the%20original%20texts%20that%20the,depicted%20in%20the%20picture%20below)).

### Fonctionnalités principales de RAGFlow

- **Interface Web (Dashboard) intuitive** : RAGFlow offre un tableau de bord web pour gérer l’intégralité du workflow RAG. On peut créer des **Knowledge Bases** (bases de connaissances) distinctes, importer des fichiers, configurer les modèles de LLM et d’embedding, et tester des requêtes le tout via l’UI. La section _Knowledge Base_ permet de suivre l’état du parsing des documents et d’inspecter les chunks extraits, la section _Chat_ permet de configurer et lancer des sessions de chat IA, et on trouve aussi des pages de configuration et de monitoring.
    
- **Support de multiples formats de documents (hétérogénéité)** : RAGFlow peut ingérer des documents **bureautiques** (Word, PDF, PowerPoint, Excel, texte brut), des **images y compris scans** (documents scannés, schémas), des pages web, et même des données structurées (par ex CSV) ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=,data%2C%20web%20pages%2C%20and%20more)). Il intègre une chaîne d’analyse de documents (_DeepDoc_) basée sur la vision qui détecte la structure des fichiers PDF complexes, identifie les titres, paragraphes, tableaux, images, etc ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=1,details%20within%20these%20comprehensive%20numbers)). Pour les **tableaux**, RAGFlow reconnait la structure cellulaire et conserve les associations colonnes-lignes (ex : il peut relier la valeur d’une cellule à l’intitulé de colonne approprié), ce qui permet de poser des questions pointues sur des données tabulaires ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=processing%20system%3A%20When%20users%20upload,document%20processing%20system%20with%20diverse)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=elements%20like%20images%20and%20tables,For)). Cette compréhension fine évite d’insérer en base des textes désorganisés (ex: cellules de tableau concaténées n’importe comment), problème courant avec des parsers basiques ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=vector%20databases%20and%20RAG%20orchestration,%E2%80%9D)).
    
- **Chunking intelligent et template-based** : Contrairement à un découpage uniforme, RAGFlow propose des **profils de chunking adaptés au type de document ou au cas d’usage** ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=2,For%20instance)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=In%20this%20way%2C%20it%20is,processing%20tasks%20more%20readily%20accessible)). Par exemple, il existe des modes “Paper” (pour articles académiques), “Law” (pour des documents juridiques structurés), “Table” (pour forcer un traitement optimisé des tableaux), “Book”, “Manual”, “Q&A”, “Resume”, etc. Chacun ajuste la façon dont le document est découpé et quelles métadonnées sont extraites. Ce template-based chunking permet d’obtenir des chunks **pertinents et explicables**, et l’utilisateur peut choisir l’option la plus adaptée à ses données métier. Ce niveau de personnalisation est un point fort de RAGFlow pour répondre à des besoins sectoriels variés ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=In%20this%20way%2C%20it%20is,processing%20tasks%20more%20readily%20accessible)).
    
- **Intervention manuelle et transparence** : RAGFlow met l’accent sur l’**explicabilité** du traitement des documents. Via l’UI, après l’ingestion d’un fichier, on peut **visualiser chaque chunk extrait** (texte du chunk, éventuellement aperçu du rendu original) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=RAGFlow%20features%20visibility%20and%20explainability%2C,To%20do%20so)) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=2,quick%20view%20of%20each%20chunk)). L’utilisateur peut surligner un chunk pour voir où il se situe dans le document source, comparer le texte extrait à l’original, et même **éditer** le contenu du chunk ou ajouter des _mots-clés_ manuellement ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=2,quick%20view%20of%20each%20chunk)) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=containing%20those%20keywords,its%20position%20in%20search%20list)). Par exemple, si un terme important n’a pas été correctement inclus (ou au contraire si un chunk contient du bruit), l’expert métier peut intervenir avant la phase de question-réponse. On peut aussi assigner des mots-clés à un chunk pour booster sa pertinence lors des recherches (en augmentant son poids dans le ranking) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=NOTE)). Cette transparence et ce contrôle sont essentiels en contexte entreprise, où l’on veut garder la maîtrise sur ce que le LLM utilise comme base ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=3,We%20not%20only%20present%20the)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=deletions%2C%20and%20look%20up%20information%2C,shown%20in%20the%20pictures%20below)).
    
- **Réduction des hallucinations et citations** : Chaque réponse fournie par le chat de RAGFlow est accompagnée de **citations** des documents sources (avec des liens vers le texte original) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=In%20conclusion%2C%20RAGFlow%20stands%20as,content%2C%20including%20charts%2C%20diagrams%2C%20and)). L’interface permet de cliquer sur la référence pour ouvrir le document à l’endroit exact du chunk ayant servi à la réponse. Cette approche _“closed-loop”_ aide à **valider l’exactitude** des réponses et à instaurer la confiance : l’utilisateur peut à tout moment vérifier d’où vient l’information. RAGFlow implémente également des techniques pour limiter les hallucinations, par exemple en donnant une réponse vide ou générique si rien de pertinent n’a été trouvé dans la base (plutôt que de forcer le LLM à inventer) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=,as%20is%20for%20the%20beginning)). On peut configurer un message par défaut (« Désolé, je n’ai pas d’information à ce sujet ») pour ces cas-là afin de garder le LLM _grounded_ dans la connaissance disponible.
    
- **Orchestration RAG complète et modulaire** : RAGFlow intègre tous les composants nécessaires dans une architecture prête à l’emploi. En backend, il s’appuie sur Elasticsearch (moteur de recherche capable de faire à la fois du vectoriel et du textuel) couplé à un module maison appelé **Infinity** pour le stockage vectoriel optimisé ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=introduced%20Infinity%2C%20a%20dedicated%20database,behind%20the%20launch%20of%20RAGFlow)). Il utilise également MinIO (stockage objet type S3) pour conserver les documents et outputs, et une base SQL (MySQL) pour les métadonnées. L’architecture comprend aussi un **moteur d’agents** capable d’exécuter des actions (par ex, effectuer plusieurs requêtes ou combiner des sous-réponses) et un scheduler de tâches asynchrones pour les traitements lourds (OCR, etc.), le tout orchestré via une API FastAPI + workers Python (Celery/Redis) pour traiter en arrière-plan sans bloquer l’UI ([Posts by Category | Chaoran’s Data Story](https://www.ichaoran.com/categories/#:~:text=In%20this%20post%2C%20I%20explore,periodically%20updated%20on%20the%20frontend)). Malgré cette complexité interne, l’utilisateur final n’a pas à se soucier de cela : le déploiement se fait via Docker et l’utilisation via l’UI ou des appels HTTP/REST.
    
- **Configuration flexible des modèles** : On peut utiliser RAGFlow avec un LLM en ligne (OpenAI API) ou **intégrer des modèles locaux**. Par défaut (v0.17 début 2025), l’interface permet de renseigner une clé API (OpenAI, Azure, etc.) ([Configure model API key - RAGFlow](https://ragflow.io/docs/dev/llm_api_key_setup#:~:text=Configure%20model%20API%20key%20,model%20API%20key%20in%20RAGFlow)) ([FAQs - RAGFlow](https://ragflow.io/docs/dev/faq#:~:text=FAQs,apart%20from%20other%20RAG%20products%3F%E2%80%8B)). Mais RAGFlow supporte aussi nativement l’intégration de serveurs de modèles locaux comme **Ollama**, **Xinference**, ou encore Jina et Intel IPEX-LLM ([Deploy LLM locally | RAGFlow](https://ragflow.io/docs/dev/deploy_local_llm#:~:text=RAGFlow%20supports%20deploying%20models%20locally,interacting%20with%20your%20local%20models)). Ces solutions permettent d’héberger des modèles open-source (Llama 2, Mistral, Falcon, etc.) sur ses propres machines, éventuellement en tirant parti du GPU. RAGFlow peut s’y connecter en configurant l’URL du serveur local. En pratique, cela signifie que l’on peut faire tourner l’ensemble du système **100% en local**, sans dépendance à un service cloud, ce qui est crucial pour des entreprises aux données sensibles. (Un guide détaillé existe pour brancher un LLM custom sur RAGFlow ([Private LLM Integration with RAGFlow: A Step-by-Step Guide | Chaoran’s Data Story](https://www.ichaoran.com/posts/2024-11-08-ragflow-with-own-llm/#:~:text=As%20of%20now%20,with%20your%20custom%20LLM%20setup)) ([Private LLM Integration with RAGFlow: A Step-by-Step Guide | Chaoran’s Data Story](https://www.ichaoran.com/posts/2024-11-08-ragflow-with-own-llm/#:~:text=and%20,with%20your%20custom%20LLM%20setup)) ; en novembre 2024 il fallait encore ajuster le code manuellement, mais les mises à jour de décembre 2024 ont apporté un support intégré pour Ollama et co).
    
- **Recherche multi-stratégie (Multiple Recall)** : RAGFlow ne se contente pas d’une simple similarité cosinus. Il utilise un **double rappel** (vectoriel + lexical) avec re-ranking fusionné pour améliorer la pertinence des documents retrouvés ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=,for%20seamless%20integration%20with%20business)) ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=Automated%20and%20effortless%20RAG%20workflow)). Concrètement, pour chaque requête, il peut effectuer une recherche par vecteur **et** par mots-clés (via Elasticsearch par ex.), puis fusionner les résultats (pondérés par des scores) afin d’attraper aussi bien des correspondances sémantiques que des exact match de termes. L’UI de “Retrieval testing” montre d’ailleurs les contributions _Hybrid Similarity_, _Term Similarity_ et _Vector Similarity_ pour chaque résultat. Cette approche hybride permet de mieux gérer les questions pointues où un mot technique rare doit être retrouvé tel quel, ou à l’inverse des reformulations.
    
- **Évolutivité et Monitoring** : Pensé pour une utilisation en entreprise, RAGFlow supporte la gestion **multi-utilisateurs/équipes** (avec contrôle d’accès aux différentes bases de connaissances), et fournit des outils de supervision. Par exemple, on peut monitorer les performances via Kibana (puisque Elasticsearch est dans la boucle) et la consommation de ressources. Un module _Monitoring_ permet de voir les requêtes passées, les temps de réponse, etc. De plus, étant open-source, toute l’architecture peut être déployée sur les serveurs de l’entreprise (Docker compose fourni) et adaptée si besoin.
    

En résumé, RAGFlow se positionne comme une **solution de bout en bout** pour le RAG, avec un souci de **qualité des données en entrée** (“Quality in, quality out” est leur slogan ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=))) et de **fiabilité des réponses en sortie** (citations, réduction d’hallucinations). Il vise à démocratiser le RAG en entreprise, même pour des documents complexes, sans exiger de l’utilisateur de construire lui-même l’orchestration avec LangChain ou autre.

### Exemples de pipelines configurables avec RAGFlow

Dans RAGFlow, on ne code pas le pipeline, on le **configure**. Voici comment se déroule typiquement la configuration d’un pipeline complet via l’interface :

1. **Création d’une base de connaissance** : L’utilisateur crée une nouvelle _Knowledge Base_ via l’UI, par exemple “Normes_Béton”.
    
2. **Upload des documents** : Il importe ses fichiers (par glisser-déposer ou via le sélecteur). Mettons qu’il importe 5 PDF de normes (Eurocode 2, normes NF pour béton…). Chaque document apparaît dans la liste avec un statut _“Uploaded”_. On peut grouper les documents en _Dataset_ au sein de la base.
    
3. **Parsing et chunking** : L’utilisateur clique sur _“Parse”_ pour lancer le traitement. RAGFlow va analyser chaque fichier (OCR si image scannée, extraction de texte, découpage). On peut choisir un **template de chunking** avant de lancer le parse : par ex. le mode “Law” pourrait convenir pour des normes (découpe par articles/aléas), ou “Manual”. Une fois le parsing terminé, le statut passe à _SUCCESS_, et on peut cliquer sur le document pour voir les chunks ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=RAGFlow%20features%20visibility%20and%20explainability%2C,To%20do%20so)). Supposons qu’une norme PDF de 50 pages a été découpée en 120 chunks de ~200 mots chacun.
    
4. **Vérification/édition (optionnel)** : En examinant les chunks, l’utilisateur voit que certains titres n’ont pas été correctement rattachés. Il peut éditer ces chunks pour ajouter le titre manquant, ou fusionner/séparer des chunks si nécessaire. Il peut aussi ajouter des mots-clés métiers (p. ex. “fibre”, “sulfate”) sur certains chunks pour améliorer la recherche ultérieure ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=NOTE)). Par exemple, tagguer un chunk parlant de “durabilité sulfate” avec mot-clé “XS exposé” si c’est un terme de requête fréquent.
    
5. **Configuration des modèles** : Dans _Configuration_, on s’assure que le **LLM** choisi est bien paramétré. Pour une utilisation purement locale, on aurait paramétré un LLM hébergé via Ollama ou autre, disons un modèle “LLM Maison 20B” qui a été branché. De même, on vérifie le **modèle d’embedding** utilisé pour indexer (par défaut, RAGFlow inclut un modèle d’embedding – peut-être basé sur SBERT – mais on pourrait en changer).
    
6. **Test de récupération** : RAGFlow propose un onglet _Retrieval testing_ où on peut taper une question de test et voir quels chunks seraient retrouvés. Par exemple : “Quelle est la résistance minimale en compression à 28j pour un béton XC4 ?”. Le système va afficher les top résultats de chunk avec les scores hybride/terme/vecteur. On peut ainsi ajuster le **seuil de similarité** ou le paramètre de pondération sémantique vs lexical (deux curseurs sont présents) pour affiner le comportement. Si les résultats ne sont pas satisfaisants, on peut revenir en arrière ajouter un mot-clé ou ajuster le chunking.
    
7. **Création de l’assistant (pipeline de chat)** : Une fois la base prête, on crée un **Assistant** dans l’onglet _Chat_. On donne un nom (par ex. “Assistant Normes Béton”), on sélectionne la ou les bases de connaissance sur lesquelles il devra s’appuyer (on pourrait cocher plusieurs bases si on veut qu’il puise dans plusieurs à la fois) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=Conversations%20in%20RAGFlow%20are%20based,and%20start%20an%20AI%20conversation)) ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=2)). On choisit le modèle de chat (si on en a plusieurs configurés) et on peut personnaliser le _prompt système_ (RAGFlow permet d’éditer le prompt d’amorce, appelé _Prompt Engine_). On peut par exemple insister “Tu es l’assistant des normes béton, tu fournis des réponses précises en citant les références normatives.”.
    
8. **Lancement du chat et configuration fine** : On démarre une session de chat avec cet assistant. A chaque question posée, RAGFlow va : interroger l’index vectoriel de la base, récupérer les passages pertinents, formuler la réponse avec citations. Si la base ne contient rien de pertinent et qu’on a renseigné un message d’absence (« _Désolé..._ »), il l’utilisera. Sinon, on obtient une réponse avec par ex. “Selon NF EN 206, la résistance caractéristique en compression à 28 jours pour un béton de classe C30/37 est de 37 MPa 【source: Norme NF EN206 p.15】”. On peut alors interagir en langage naturel avec l’assistant.
    

Le “pipeline” RAGFlow est donc **configurable via l’UI** plutôt que codé à la main. Chaque assistant créé est en quelque sorte un pipeline instancié (liaison d’une ou plusieurs bases de connaissances avec un LLM + paramètres de récupération). RAGFlow stocke ces configurations, et il serait possible via l’API Python ou HTTP de les appeler ensuite dans une application externe.

### Cas d’usage réels de RAGFlow et retours d’utilisateurs

- **Support juridique et conformité** : RAGFlow a été utilisé par des entreprises pour créer des assistants capables de parcourir des documents juridiques complexes (contrats, réglementations). Grâce au mode _Law_ et à la vérifiabilité des réponses, ces assistants servent d’outils d’aide pour les équipes légales, en retrouvant rapidement des clauses ou des références précises. Un utilisateur rapporte sur Reddit que _« l’UI est conviviale et la capacité à gérer des PDF complexes est excellente, ce qui nous a permis de déployer un chatbot interne pour la compliance »_. Le fait de pouvoir tout héberger en interne (docker + modèles privés) a levé les barrières de confidentialité dans ce contexte.
    
- **Documentation technique et SAV** : Une PME du secteur électronique mentionne avoir adopté RAGFlow pour centraliser des manuels techniques, fiches produits et tickets support. Leur assistant répond aux techniciens SAV sur des procédures de réparation et aux clients sur des caractéristiques produits. Ils soulignent la **fusion recherche sémantique + mots-clés** de RAGFlow qui permet de trouver la réponse même lorsque la question utilise d’autres termes que le document (synonymes) tout en gardant la précision sur des références de modèle.
    
- **Industrie manufacturière** : D’après un article de Renumics, RAGFlow (ou un système similaire) s’intègre bien pour aider les opérateurs machines ou ingénieurs à naviguer dans les manuels de maintenance et historiques de pannes ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=AI,specific%20assistants)) ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=really%20hard,and%20enable%20matchmaking%20with%20experts)). Un cas cité est un assistant pour une ligne de production qui guide l’opérateur dans le diagnostic en croisant le manuel et les logs de maintenance passés. RAGFlow, via son extraction intelligente, pourrait extraire d’un PDF de manuel machine les différentes étapes de calibration, les mettre en chunks, et l’agent conversationnel peut ensuite y faire référence pour guider pas à pas.
    
- **Environnements multilingues** : RAGFlow supportant la traduction lors de la phase de chunking (via le LLM lui-même si besoin), des entreprises l’emploient pour unifier la recherche sur des documents en plusieurs langues. Par exemple un assistant RH pour une multinationale peut répondre en français en s’appuyant sur des documents internes anglais ou chinois, car le système a indexé en langue source mais le LLM peut traduire la question ou la réponse à la volée. Cela exploite les capacités de **traduction** et de **résumé** du LLM couplées à RAG ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=%2A%20LLM,issues)).
    

En termes de **retours utilisateurs**, RAGFlow est souvent salué pour sa **complétude** : pas besoin de combiner X outils, tout est dans la suite. L’interface de chunk preview est un vrai plus pour la confiance dans le système. La contrepartie est que c’est une solution relativement **lourde** à déployer : certains ont noté que la stack Docker inclut Elastic, a des besoins en RAM/CPU non négligeables, etc. (prérequis : ~16GB RAM, 4 CPU minimum ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=Prerequisites))). Une personne sur un forum a exprimé que _« l’architecture veut tout faire, j’ai peur qu’elle peine à scaler en conditions réelles enterprise »_, soulignant que la multiplication des composants (Elastic, MySQL, MinIO, Kibana…) peut complexifier la maintenance. Néanmoins, pour une entreprise qui a les ressources nécessaires, cette architecture modulaire est un avantage car **chacun des composants est remplaçable ou ajustable** (par ex, on pourrait brancher un autre vecteur store à la place d’Elastic/Infinity si on le souhaite, en adaptant le code).

Côté performance, il n’existe pas encore de **benchmark public** comparant RAGFlow à d’autres solutions de RAG. Cependant, on peut comparer par concept : par rapport à un pipeline LangChain “maison”, RAGFlow apporte des optimisations comme le multi-recall et la compréhension de document qui pourraient donner de **meilleures réponses sur des PDF complexes**. En revanche, il ajoute un léger overhead (la requête passe par l’API RAGFlow, qui interroge Elastic, etc., donc latence un peu plus élevée que des appels directs en mémoire). Pour des bases de connaissance de taille modérée (< quelques milliers de documents), cette latence reste faible (quelques centaines de ms pour la recherche). RAGFlow utilise aussi des **agents** pour éventuellement décomposer des questions ou effectuer des requêtes additionnelles si nécessaire (d’après la roadmap, ils ont ajouté la génération de questions liées pour améliorer le rappel ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=%2A%202024,to%20SQL%20statements%20through%20RAG))). Cela pourrait être utile pour des requêtes complexes nécessitant plusieurs étapes.

En termes de **documentation et ressources** : on trouve la doc officielle sur ragflow.io (bien détaillée avec des guides de configuration ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=This%20quick%20start%20guide%20describes,a%20general%20process%20from)), déploiement local ([Deploy LLM locally | RAGFlow](https://ragflow.io/docs/dev/deploy_local_llm#:~:text=Run%20models%20locally%20using%20Ollama%2C,Xinference%2C%20or%20other%20frameworks)), etc.), le code source sur GitHub (infiniflow/ragflow) ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=What%20is%20RAGFlow%3F)), une communauté Discord active, et quelques articles de blog comme celui publié sur Medium par l’équipe InfiniFlow ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=In%20conclusion%2C%20RAGFlow%20stands%20as,content%2C%20including%20charts%2C%20diagrams%2C%20and)) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=the%20original%20texts%20that%20the,depicted%20in%20the%20picture%20below)). Pour se faire la main, un **demo en ligne** est proposé ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=Demo)) (demo.ragflow.io) permettant de tester avec des documents factices.

## Utilisation optimisée de RAGFlow en contexte professionnel (secteur béton)

Enfin, penchons-nous sur un scénario concret : une entreprise spécialisée dans le **béton** (par exemple un fabricant de matériaux ou un bureau d’études béton), possédant des **données critiques** (rapports d’essais, formules de mélange, normes internes) et servant des **clients sensibles** (chantier d’envergure, infrastructure). Comment mettre en place et optimiser RAGFlow pour ce contexte ?

### Organisation des bases de connaissances par type de document

Il est judicieux de **segmenter la connaissance en plusieurs bases** en fonction des types de documents et d’usage, plutôt que de tout mélanger. Par exemple, on pourrait créer les Knowledge Bases suivantes :

- **Base “Normes & Réglementation”** : contiendra les documents normatifs (Eurocodes, normes NF EN, guides CSTB, DTU…). Ces documents ont souvent une structure très formalisée (titres, sections, articles). On pourra appliquer le template de chunking _“Law”_ ou _“Manual”_ de RAGFlow, afin de s’assurer que chaque chunk correspond à une clause ou section cohérente d’une norme. Cela permettra à l’assistant de citer précisément “Article X.Y de la norme Z” dans ses réponses. On veillera à inclure dans les métadonnées de chunk le **titre de la norme** et éventuellement les numéros de section, pour faciliter le traçage dans les citations.
    
- **Base “Rapports d’essais”** : regroupera les rapports de laboratoire (essais de compression, de traction, etc. sur éprouvettes de béton) et peut-être des _feuilles de mesure_ ou bases de données de résultats. Ces documents contiennent souvent des tableaux, graphiques et du texte descriptif. On pourra utiliser le template _“Table”_ de RAGFlow pour optimiser l’extraction des données tabulaires : RAGFlow va reconnaître les tableaux, en extraire chaque ligne comme chunk ou intégrer les valeurs avec leurs en-têtes ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=processing%20system%3A%20When%20users%20upload,details%20within%20these%20comprehensive%20numbers)). Il est important ici d’avoir des embeddings qui capturent bien les **données numériques** et unités, afin qu’une requête du type “résistance à 7 jours de l’échantillon 12B” retrouve effectivement la bonne valeur. On pourrait envisager d’enrichir les chunks de tableau avec des libellés supplémentaires (ex: ajouter “fcm7=xxx MPa” comme mot-clé si la table a une colonne résistance à 7j). Par ailleurs, on pourrait stocker ces résultats aussi dans une base de données structurée annexe et faire du RAG “text-to-SQL” (RAGFlow a introduit une fonction text-to-SQL ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=%2A%202024,to%20SQL%20statements%20through%20RAG))) mais cela complexifie – rester sur pure QA doc peut suffire.
    
- **Base “Formules et méthodes”** : ici on mettrait des documents liés aux formules de mélange (par ex. fiches de composition de béton, notes de calcul) et aux méthodes de calcul (par ex. formules empiriques utilisées en interne, ou guides techniques). Ces docs peuvent contenir des **formules mathématiques** (ex: formules de dosage, calcul de module d’élasticité, etc.) et des **schémas** explicatifs (par ex. diagramme de Granulométrie, schéma de poutre chargée). Pour le chunking, le template “Paper” ou “Manual” pourrait convenir, mais il faudra s’assurer que les formules ne sont pas _perdues_ lors de l’OCR. RAGFlow va essayer de détecter les formules soit comme images, soit comme texte (si PDF texte). Si ce sont des images (ex: formule écrite en LaTeX rendue en PDF), on pourrait avoir RAGFlow les traiter comme des images – il reconnait qu’il y a un objet, mais pas sûr qu’il en déduise le contenu mathématique. **Idée** : pour chaque formule importante, on pourrait ajouter manuellement dans le chunk une version textuelle (en LaTeX ou en description). Par exemple, après ingestion, éditer le chunk contenant _“voir équation (5)”_ et y insérer la formule en clair si on la connaît. Cela permettra au LLM de disposer de la formule pour raisonner. On peut aussi attacher en _metadata_ que tel chunk contient une formule nommée “(5)” pour s’y référer. Cette base “Formules” sera très utile pour des questions du genre « Quelle formule interne utilise-t-on pour estimer la résistance à l’avancement ? ».
    

En séparant ainsi les bases, on obtient une **gestion différenciée** et plus maintenable. Chaque base peut avoir ses propres réglages : par ex, pour “Normes” on pourrait mettre un **poids plus fort sur la recherche lexicale** (car les termes exacts sont importants, e.g. XC4, XA, etc.), tandis que pour “Rapports” on peut favoriser la **similarité sémantique** (car la question pourrait être formulée différemment de la manière dont le rapport est rédigé). RAGFlow permettant de choisir plusieurs bases dans une requête, on pourra toujours créer un assistant global qui interroge toutes les bases si besoin, mais c’est bien d’avoir la modularité.

### Adaptation du chunking et des embeddings par type de document

Comme évoqué, chaque type de document bénéficie d’un traitement sur mesure :

- **Documents textuels structurés (normes, manuels)** : Utiliser chunking par section/titre. RAGFlow excelle ici avec la reconnaissance de structure (titre, paragraphes) ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=1,details%20within%20these%20comprehensive%20numbers)). On limitera la taille des chunks à, disons, 200-300 mots pour les normes, afin qu’une clause = un chunk. Pour l’embedding, un modèle type **LegalBERT** ou un modèle finetuné sur des textes techniques pourrait améliorer la représentation, mais si non disponible, un embedding général comme SBERT fera l’affaire. On veillera à inclure dans l’embedding tout texte pertinent (ne pas laisser de côté d’éventuels annexes si elles peuvent contenir des réponses).
    
- **Tableaux de résultats** : RAGFlow va extraire intelligemment, mais on peut décider de la granularité : est-ce qu’on chunk par ligne de tableau, par cellule, ou un tableau entier comme chunk ? S’il s’agit de petits tableaux avec peu de lignes, chunker le tableau entier peut être utile pour que le contexte de toutes les valeurs soit présent. Pour de grands tableaux, mieux vaut chunk par ligne ou groupe de lignes. On s’assurera que les **en-têtes de colonnes** sont bien répétées dans chaque chunk (RAGFlow le fait en combinant header + cellule ([RAGFlow: Customizable, Credible, Explainable RAG engine based on document structure recognition models | by InfiniFlow | Medium](https://medium.com/@infiniflowai/ragflow-customizable-credible-explainable-rag-engine-based-on-document-structure-recognition-6a2a2369bd2a#:~:text=elements%20like%20images%20and%20tables,details%20within%20these%20comprehensive%20numbers))). Par exemple, un chunk pourrait devenir “Échantillon 12B – Résistance 7j : 25 MPa; 28j : 40 MPa; Module E: 34 GPa”. Ainsi une requête “résistance 28j échantillon 12B” matchera ce chunk. Un modèle d’embedding éventuellement spécialisé pour données tabulaires n’est pas courant, mais on peut utiliser des embeddings standard qui traitent le texte des chiffres (en le considérant comme tokens, ce qui marche si la requête contient aussi des chiffres). On peut aussi indexer des versions unitaires (par ex. convertit toutes les unités en une seule convention) pour homogénéiser les match – mais c’est du détail.
    
- **Formules mathématiques et schémas** : C’est le plus délicat. Pour les formules, idéalement on aimerait un **embedding capable de comprendre du LaTeX ou des expressions math**. Il existe des travaux de recherche sur des embeddings de formules (par ex. TangentCFT pour la recherche de similarité de formules), mais ce n’est pas intégré nativement. Une approche pragmatique : convertir les formules en une description textuelle lorsque c’est possible. Ex: $f_cm = \alpha \cdot f_{c28}$ pourrait être stocké comme “fcm = alpha * fc28 (relation linéaire entre fcm et fc28)”. Ce texte sera indexé et peut-être retrouvé si la question parle de “relation fcm et fc28”. Pour les schémas, s’ils contiennent du texte (légendes), RAGFlow devrait en extraire les légendes via OCR. On peut alors avoir un chunk avec “Figure 2: Schéma du cycle gel-dégel” etc. Si la question porte sur “voir schéma cycle gel-dégel”, l’assistant pourrait répondre en se basant sur la description disponible. Mais pour **exploiter réellement le contenu visuel** (ex: interpréter un diagramme), il faudrait un **LLM vision**.
    

### Intégration de LLM _vision_ pour schémas et formules

Les _LLM vision_ sont des modèles capables de traiter des images en entrée (ex : GPT-4 Vision, ou des modèles open-source comme LLaVA, BLIP-2, etc.). Dans notre contexte, ils pourraient être utiles pour deux tâches principales :

1. **OCR et description d’images** : Bien que RAGFlow effectue de l’OCR de base, un LLM vision avancé pourrait **décrire un schéma complexe** ou **traduire une formule manuscrite** mieux qu’un OCR classique. Par exemple, un schéma de principe sans beaucoup de texte – un LLM vision pourrait produire une légende du type “Schéma: courbe contrainte-déformation montrant une zone élastique suivie d’une rupture brutale”. Cette description textuelle pourrait enrichir la base de connaissances. On pourrait imaginer un _workflow_ où, pour chaque image détectée dans un PDF, on fait appel à un modèle vision pour générer une description textuelle stockée en note annexe ou metadata du chunk. Ainsi, même si la question porte sur “le schéma de la courbe contrainte-déformation”, le système a du texte à se mettre sous la dent pour trouver la réponse.
    
2. **Interprétation dynamique lors des questions** : Plus complexe, on pourrait intégrer un LLM vision **au moment de la requête** si celle-ci demande directement une analyse d’image. Par ex, si l’utilisateur dit “Voici la photo de la fissure, que montre-t-elle ?” (upload d’image en live), un LLM vision pourrait analyser l’image de fissure. Cependant, c’est un cas à part du RAG textuel. Dans la plupart des cas, l’assistant n’aura à manipuler que du texte, car on aura pre-indexé toute l’info nécessaire via du texte.
    

Une stratégie réaliste pour notre entreprise béton : **enrichir autant que possible les documents avant indexation** en extrayant le maximum d’informations textuelles des schémas et formules. Par exemple, utiliser un outil comme **Mathpix** (OCR spécialisé math) sur les documents scientifiques pour convertir les formules en LaTeX textuel, que l’on insère en petit en dessous de l’image dans un PDF avant ingestion par RAGFlow. Ou utiliser un modèle vision style BLIP pour générer des descriptions d’images et attacher ces descriptions dans un fichier annexe à ingérer. Ainsi, on reste dans le flux standard de RAGFlow (basé sur texte) tout en tirant parti de l’IA vision pour améliorer le texte disponible.

Si l’on souhaite aller plus loin, on pourrait imaginer intégrer un _agent_ qui, quand une question mentionne “voir image X” ou “selon le schéma Y”, va chercher l’image correspondante (via les métadonnées du chunk, on sait quelle page du PDF par ex), la passer à un modèle vision externe, puis intégrer la sortie comme contexte supplémentaire avant la réponse du LLM texte. Ce genre d’**agent multi-modal** n’est pas natif dans RAGFlow, mais on peut le concevoir en parallèle (voir section architecture ci-dessous).

### Faut-il une classe RAG dédiée avec gestion différenciée des KB ?

Dans une implémentation custom, on pourrait coder une classe Python qui gère plusieurs vecteurs stores et route les requêtes en fonction du type. Cependant, avec RAGFlow ce n’est pas forcément nécessaire car le produit gère déjà le **multi-KB** de manière native. On peut configurer un assistant RAGFlow pour qu’il utilise _plusieurs_ bases en même temps (il va alors récupérer dans toutes). Mais on ne peut pas (actuellement) définir des règles conditionnelles par type de question.

Dans notre cas, la segmentation des bases vise surtout la maintenance et la précision. L’utilisateur final pourrait très bien poser des questions couvrant plusieurs domaines – dans ce cas, on peut associer toutes les bases à l’assistant, et RAGFlow rapatriera des chunks pertinents de chacune. Si on veut vraiment spécialiser les réponses (par exemple garantir que si la question est normative on ne répond que via la base Normes), on pourrait créer **plusieurs assistants spécialisés** : un “Assistant Normes”, un “Assistant Essais”, etc., que l’utilisateur choisirait.

Une autre approche est d’implémenter un **agent superviseur** qui route la question : par exemple, un petit modèle de classification de question (ou un LLM qui dans un prompt réfléchi décide “Est-ce une question de norme, de test ou de formule ?”). Sur cette base, il pourrait interroger uniquement la KB concernée via l’API de RAGFlow. Ce serait le rôle d’une application externe venant se greffer. On pourrait effectivement coder une classe `EnterpriseRAGManager` qui contient plusieurs clients RAGFlow (un par KB) et une méthode `answer(question)` qui :

1. classifie la question ou teste des mots-clés,
    
2. choisit l’KB/assistant approprié,
    
3. fait la requête via l’API Python de RAGFlow ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=NOTE)),
    
4. retourne la réponse.
    

C’est une solution maison pour vraiment cloisonner. Toutefois, ce niveau n’est peut-être pas nécessaire si les chunks sont bien taggés et si le LLM est prompté pour prioriser la source adéquate. En outre, RAGFlow en lui-même est un moteur RAG, pas un orchestrateur de multiples RAG — donc créer un “RAG de RAGFlow” est une couche additionnelle un peu complexe.

En pratique, je suggérerais de **commencer sans classe custom** et de voir. Si lors des tests on constate des confusions (ex: l’assistant prend un chunk d’un rapport d’essai alors que la question portait sur une norme parce que des termes se chevauchent), on pourra affiner. Peut-être en réglant la pondération lexical vs sémantique par base. Ou en incluant dans le prompt système du LLM des instructions du type “Si la question semble réglementaire, ne cite que des normes”, etc. Un LLM pourrait éventuellement faire ce tri s’il est bien guidé.

### Proposition d’architecture personnalisée intégrant RAGFlow, LLM locaux, agents et vector stores

Pour notre entreprise béton, voici une architecture cible qui maximise **sécurité, performance et extensibilité** :

**1. Ingestion & Indexing Layer (RAGFlow)**:  
Toutes les données documentaires (normes, rapports, etc.) sont ingérées via RAGFlow, qui joue le rôle de **backend RAG**. On déploie RAGFlow on-premise (Docker sur un serveur dédié). On configure ElasticSearch (ou Infinity) pour stocker les embeddings, relié à RAGFlow. MinIO stocke les fichiers importés. On choisit un modèle d’embedding performant polyvalent (par ex. all-MiniLM ou mpnet) qui sera utilisé par RAGFlow. Cette couche ingestion est utilisée par les experts documentaire pour mettre à jour la base (via l’UI ou via l’API Python de RAGFlow lorsqu’un nouveau doc est ajouté, on peut automatiser l’appel pour parser). On bénéficie des capacités de **DeepDoc** de RAGFlow pour l’OCR et la structuration.

**2. Base de Connaissances structurée**:  
Les Knowledge Bases sont configurées comme discuté (Normes, Rapports, Formules…). Chacune dans RAGFlow correspond à un index vectoriel séparé dans Elastic. On garde la possibilité d’en interroger plusieurs à la fois. On s’assure que tout le contenu important (y compris images décrites) est bien intégré. Cette base peut être versionnée / sauvegardée (via des snapshots Elastic et backup des fichiers).

**3. Modèles LLM Locaux**:  
On déploie un ou plusieurs LLM en local. Par exemple, un LLM principal type **Llama-2 70B** quantizé 4-bit pour réponses complexes en français, hébergé sur une machine GPU via **Ollama** (ou texte-generation-webui). On peut aussi avoir un modèle plus petit pour certaines tâches si besoin (ex: un 13B si on a beaucoup de requêtes simultanées et qu’on veut gérer plus de charge). RAGFlow permet de brancher Ollama, donc on utilise ce connecteur ([Deploy LLM locally | RAGFlow](https://ragflow.io/docs/dev/deploy_local_llm#:~:text=RAGFlow%20supports%20deploying%20models%20locally,interacting%20with%20your%20local%20models)). Ainsi, RAGFlow enverra les prompts au LLM local au lieu d’appeler une API distante. Pour la partie vision, on pourrait héberger séparément un modèle comme **BLIP-2** ou **LLaVA** sur un serveur accessible. Ce modèle ne sera pas appelé par RAGFlow directement, mais via un agent externe si besoin (point suivant).

**4. Agent de coordination (optionnel)**:  
On peut développer un petit service Python (hors RAGFlow) qui agit comme **orchestrateur intelligent**. Ce service reçoit la question utilisateur (par exemple via une interface chat custom ou via l’API de RAGFlow). Il peut alors :

- Si la question contient une image ou formule non-textuelle, appeler le modèle vision pour l’analyser. Par ex, si l’utilisateur a uploadé un schéma de fissure, le passer à un modèle vision qui sort “une fissure de 0.3 mm de largeur sur 10 cm de long sur l’échantillon en traction”. Cette info peut être ajoutée comme contexte textuel.
    
- Poser la question augmentée (contenant éventuellement le résultat vision ou autres métadonnées) à RAGFlow via l’**API Python** fournie ([Get started | RAGFlow](https://ragflow.io/docs/dev/#:~:text=NOTE)). En effet, RAGFlow offre des endpoints API pour lancer des requêtes sur un assistant donné. On utilise l’assistant correspondant (spécifique ou global).
    
- Récupérer la réponse de RAGFlow (qui inclut le texte + sources).
    
- Eventuellement, post-traiter la réponse si besoin (formatage, etc.), puis la renvoyer à l’utilisateur.
    

Cet agent peut aussi implémenter la logique de routage évoquée plus haut (décider quelle KB interroger). Mais il peut aussi déléguer ça à RAGFlow en posant la question sur toutes les bases, puis éventuellement filtrer les sources dans la réponse finale (par ex, ne garder que les sources normatives si on voulait épurer).

**5. Application front-end**:  
Les utilisateurs (ingénieurs, techniciens) accéderont à l’assistant via soit l’UI de RAGFlow (onglet Chat) en sélectionnant l’assistant voulu, soit via une interface dédiée (ex: un chatbot intégré à l’intranet de l’entreprise). Pour une intégration plus poussée, l’API de RAGFlow peut être utilisée dans un chatbot custom (par ex., une UI web style chat moderne, qui derrière envoie les requêtes au service orchestrateur ou directement à RAGFlow).

**6. Sécurité & Données sensibles**:  
Puisque tout est local, les données critiques restent sur nos serveurs. On peut cloisonner l’accès aux bases : RAGFlow gère des espaces de travail, on pourrait imaginer que seules certaines personnes peuvent accéder à “Rapports d’essais” car c’est très confidentiel, etc. Si besoin, on peut anonymiser ou masquer certaines données sensibles dans les chunks lors de l’ingestion (par exemple, RAGFlow pourrait permettre un pré-traitement pour flouter des noms de projet – sinon on pourrait le faire avant ingestion dans les documents).

**7. Maintenance & Evolution**:  
L’architecture est modulaire. Si demain on veut remplacer le vecteur store Elastic par un autre (par ex. Pinecone géré en interne), on pourrait modifier la couche RAGFlow (RAGFlow est open-source, l’équipe a son _roadmap_ où ils prévoient d’intégrer d’autres backends, etc.). Si on veut intégrer un nouveau type de document (par ex. images de microstructure béton sans texte), on pourrait entraîner un modèle vision spécifique et adapter l’agent orchestrateur pour ces cas. RAGFlow lui-même est en évolution constante (ils ajoutent par ex. du **Knowledge graph** extraction ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=%2A%202025,improve%20the%20accuracy%20of%20retrieval)), ce qui pourrait un jour aider à lier les infos entre documents, pratique pour faire du raisonnement plus poussé).

En schéma, l’architecture ressemblerait à ceci :

```
[Utilisateurs] -- (Interface Web/Chatbot) --> [Agent Orchestrateur] --> [RAGFlow API] --> [Vector DB Elastic/Infinity + Knowledge Bases] 
                                                |                                         |
                                                |--------> [LLM local via Ollama] <-------|
                                                \--------> [Modèle Vision] (si besoin) ----/
```

- Le **Vector DB** stocke les embeddings de chaque KB; RAGFlow s’en sert pour la recherche.
    
- Le **LLM local** (ou plusieurs) génère les réponses; intégré via Ollama/Xinference, appelé par RAGFlow.
    
- Le **Modèle Vision** est appelé en parallèle par l’agent quand requis (pas par RAGFlow directement).
    
- L’**Agent Orchestrateur** est optionnel mais utile pour loger la logique métier supplémentaire (multi-modal, choix de KB…); il utilise l’API de RAGFlow pour toutes les opérations RAG classiques.
    
- Les utilisateurs, eux, ne voient que le résultat final sous forme de chat avec citations.
    

Cette architecture garantit que l’entreprise **maîtrise ses données et ses modèles** (rien ne sort, tout est dockerisé sur site), tout en offrant aux utilisateurs finaux une **expérience interactive fluide** (un chatbot qui répond précisément et cite les documents internes). La modularité permet de brancher différentes briques IA selon les besoins (on pourrait imaginer plus tard intégrer un module d’**analyse de requête** qui détecte l’intention: calcul, définition, comparatif, et ajuste le prompt du LLM en conséquence, etc.).

En conclusion, pour une entreprise du béton, l’alliance de RAGFlow et de LLM locaux offre une solution puissante pour valoriser le capital documentaire technique. En répartissant les connaissances par type, en paramétrant finement le chunking/embedding, et en intégrant au besoin des capacités visuelles, on obtient un assistant virtuel capable de fournir rapidement des réponses fiables aux équipes, tout en respectant les contraintes de confidentialité et de précision propres à ce domaine industriel. Ce genre d’architecture sera un atout pour la **transformation numérique** de l’entreprise, en rendant la connaissance accessible de façon naturelle et immédiate, du bureau d’études jusqu’au chantier. ([How to build RAG-based assistants for industrial applications | Renumics GmbH](https://renumics.com/blog/industrial-ai-canvas-rag#:~:text=This%20can%20be%20manuals%2C%20online,as%20text%20and%2For%20image%20data)) ([GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.](https://github.com/infiniflow/ragflow#:~:text=,citations%20to%20support%20grounded%20answers))