
---
# Recommandations :

#### 1. Documents textuels structurés (normes, manuels) :
- Limitation à 200-300 mots pour les normes
- Sur des textes techniques un modèle LegalBERT au pire embedding général SBERT
#### 2. Tableaux de résultats : Est-ce qu'on chunk par ligne de tableau, par cellule, ou un tabelau entier peut êtr utile pour que le contexte de toutes les valeurs soit présent.
- S'il s'agit de peits tableaux avec peu de lignes, chunker le tableau entier peut être utile
- Pour de grands tableaux mieux vaut chunk par ligne ou groupe de lignes.
	- Attention de s'assurer que les en-têtes de colonnes sont bien répétés dans chaque chunk
	- Un modèle d'embedding éventuellement spécialisé pour données tabulaires n'est pars courrant
	- On peut utiliser des embeddings standard qui traitent le texte des chiffres
	- On peut aussi indexer des versions unitaires (convertir toutes les unités en une seule convention) pour homogénéiser les match
#### 3. 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 (relation linéaire)
	- Pour les schémas s'ils contiennent du texte (légendes), RAGFLOW devrait en extraire les légendes via OCR.
	- L'assistant pourrait répondre en se basant sur la description disponible. Mais pour exploiter réellement le contenu visuel, il faudrait un LLM vision
## Intégration de LLM vision pour des chémas et formules

Les LLM vision sont des modèles capables de traiter des images en entrée. Dans notre contexte ils pourraient être utiles pour deux tâches principales :
- OCR et description d'images:
	- Bien de 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 "Shéma: courbe contrainte-défromation 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émas le système a du texte à se mettre sous la dent.
	- 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.

Une statégie réaliste pour notre entreprise: 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 du RAGFLOW (texte)

Si l'on souhaite aller plus loin, on pourrait intégrer un agent qui, quand une question mentionne "voir image X" ou "selon le schéma Y", va chercher l'image correspondante via métadonnées du chunk) la passe à 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 ne parralèle.

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 de 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 :
	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
	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 orchestrteur de multiples RAG -- donc créer un "RAG de RAGFlow" est une couche additionnelle un peu complexe.

En pratique, je suggérerais de commencer snas classe custom et de voir. Si lors des tests on constate des confusions, 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 éventuellment faire ce tri s'il est bien guidé.

## Proposition d'architecure intégrant RAGFLOW, LLM locaux, Agents et Vector Stores

#### 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.

---

## ✅ **Plan de configuration de Ragflow avec les bons LLM selon les types de documents**

> 📁 Objectif : Optimiser la qualité des réponses en adaptant le **LLM, l'embedding, le chunking et la logique de récupération** à la **nature de chaque base documentaire** (normes, essais, formules, schémas…).

---

### 🧠 1. **Cartographie des types de documents + traitement cible**

| Type de documents            | Caractéristiques                         | Besoin IA principal                   | Approche                               |
| ---------------------------- | ---------------------------------------- | ------------------------------------- | -------------------------------------- |
| **Normes (AFNOR, Eurocode)** | Textes formels, structurés (articles)    | Précision lexicale, citations exactes | LLM texte + chunking juridique         |
| **Essais (labo)**            | Données tabulaires, mesures              | Extraction de valeurs, corrélation    | LLM texte + chunking tabulaire         |
| **Formules / méthodes**      | Formules math, descriptions procédurales | Compréhension mathématique            | LLM texte + support vision (optionnel) |
| **Schémas / plans**          | Images annotées, figures                 | Description, interprétation           | LLM vision + OCR + metadata            |
| **Docs logiciels (BRG-LAB)** | Tech + interface logiciel                | QA contextuelle                       | LLM standard + QA                      |

---

### ⚙️ 2. **Choix des LLM par catégorie**

| Catégorie    | LLM principal (texte)                          | LLM secondaire (vision / rerank)                   |
| ------------ | ---------------------------------------------- | -------------------------------------------------- |
| **Normes**   | `deepseek-r1:70b-llama-distill-q8_0`           | `EraX-multilingual-Rerank-3B-V2.0` pour rerank     |
| **Essais**   | `mistral:latest` ou `llama3.3:70b-instruct`    | `bge-reranker-v2-m3` pour précision résultats      |
| **Formules** | `cline_qwen_128k_Q8` (fenêtre large pour math) | `llava:34b-v1.6-fp16` pour interprétation visuelle |
| **Schémas**  | `llama3.2-vision:90b-instruct-q8_0`            | BLIP/CLIP (optionnel)                              |
| **BRG-LAB**  | `mistral:latest`                               | -                                                  |

---

### 🧩 3. **Stratégie de chunking optimisé**

| Type             | Chunking Template Ragflow | Ajustements recommandés                     |
| ---------------- | ------------------------- | ------------------------------------------- |
| Normes           | `law`, `manual`           | Chunk ≈ 200–300 tokens, + numéros articles  |
| Rapports d’essai | `table`                   | Chunk par ligne ou bloc + colonnes en clair |
| Formules         | `manual`, `paper`         | Formules = texte dans chunk ; OCR si image  |
| Schémas          | `custom`                  | Ajouter une légende générée par LLM Vision  |
| BRG-LAB          | `qa`, `manual`            | Chunk logique par écran/fonction            |

---

### 🧬 4. **Organisation des KB dans Ragflow**

|KB|Documents|Configuration recommandée|
|---|---|---|
|`Normes`|PDF AFNOR/EN|Chunking `law`, reranker ON, LLM `deepseek`|
|`Essais`|Rapports PDF/Excel|Chunking `table`, LLM `mistral`, reranker `bge`|
|`Formules`|Fiches internes|OCR/Mathpix → chunk texte + LLM `cline`|
|`Schémas`|PDF avec images|OCR + tag image + annotation LLM vision `llava`|
|`BRG-LAB`|Doc logiciel|Chunk `manual`, LLM `mistral`|

---

### 🛠️ 5. **Étapes de configuration dans Ragflow**

1. **Créer les 5 KB distinctes** (Normes, Essais, Formules, Schémas, BRG-LAB)
    
2. **Uploader les documents** correspondants dans chaque KB
    
3. Pour chaque KB :
    
    - Sélectionner le template de chunking adapté
        
    - Vérifier les chunks → corriger manuellement si besoin
        
    - Ajouter **tags métiers** dans les chunks si possible (ex: `XC4`, `C35/45`, `durabilité`)
        
    - Activer le **reranker** (ex: EraX ou BGE) pour Normes & Essais
        
    - Affecter le **LLM Ollama** via interface (LLM texte ou vision selon KB)
        
4. **Créer des assistants par KB** (ou un assistant multi-KB avec priorisation)
    
5. Tester → ajuster chunking / scoring / prompt selon la qualité de la réponse
    

---

### 🤖 6. **Prompt système par assistant (exemples)**

**Normes** :

```text
Tu es un expert des normes AFNOR. Réponds uniquement si tu trouves une référence précise. Cite toujours l'article ou la page source. 
```

**Essais** :

```text
Tu es un assistant laboratoire. Donne les valeurs exactes trouvées dans les rapports. Si plusieurs essais existent, fais un tableau comparatif.
```

**Formules** :

```text
Tu aides à comprendre les méthodes de formulation béton. Si une formule mathématique est présente, explicite-la. Appuie-toi sur les définitions internes.
```

**Schémas** :

```text
Tu décris et expliques les figures techniques. Si une image est citée, donne son interprétation en te basant sur sa légende ou description extraite.
```

---

### 🚀 7. **Évolution future possible**

- Ajouter une couche d’orchestration (agent Python qui choisit le LLM selon la question)
    
- Centraliser la base vectorielle pour mutualiser les KB
    
- Finetuner un modèle spécifique béton
    
- Générer une **FAQ dynamique** à partir des questions les plus fréquentes
    

---
