coffreobsidian/inbox/DOC mistral.md

---

Analyse des modèles Mistral API et de Ragflow

Modèles disponibles via l'API Mistral

Voici un tour d’horizon des modèles accessibles via l’API Mistral, avec pour chacun sa description, son rôle, ses capacités, le prompt idéal, la langue supportée, l’utilisation optimale dans Ragflow, les cas d’usage adaptés (documents de normes, essais, formulations, schémas techniques, etc.), et la possibilité d’intégration via des agents Python.

codestral-latest (Codestral)

• Rôle et capacités : Codestral est le modèle de code haut de gamme de Mistral. Il s’agit d’un modèle spécialisé en génération de code (22 milliards de paramètres pour la version précédente, avec une version 25.01 améliorée début 2025) (Models Overview | Mistral AI Large Language Models) (Codestral 25.01 | Mistral AI). Il prend en charge plus de 80 langages de programmation et excelle dans des tâches de complétion de code (notamment fill-in-the-middle ou insertion en milieu de code), la correction de code et la génération de tests unitaires (Codestral 25.01 | Mistral AI) (Codestral 25.01 | Mistral AI). Il est optimisé pour une utilisation à faible latence et haute fréquence, avec un contexte très large (jusqu’à 256k tokens en entrée) permettant de traiter de longs fichiers de code (Codestral 25.01 | Mistral AI). C’est un assistant de développement très performant, capable d’augmenter considérablement la productivité des développeurs (Codestral 25.01 | Mistral AI).

• Prompt idéal et langue : Pour tirer le meilleur de Codestral, il est conseillé de formuler les requêtes en anglais technique ou dans les commentaires de code, en fournissant le contexte du code. Par exemple, on peut présenter un extrait de code avec une partie manquante ou un bug, et demander explicitement la complétion ou la correction. Codestral comprend les instructions en anglais naturel, mais l’essentiel du résultat sera du code. Il supporte les instructions en français également, mais comme pour la plupart des modèles de code, l’anglais est la langue privilégiée pour décrire les tâches de programmation. En prompt chat, il n’utilise pas nécessairement le format rôle “Assistant/User” car l’API code peut être appelée directement avec du code à compléter. Le format idéal peut être : fournir un commentaire dans le code indiquant la tâche, ou une instruction du style “Corrige les erreurs dans ce code et explique les changements”.

• Langues supportées : Ce modèle est orienté vers les langages informatiques plus que les langues humaines. Il comprend très bien l’anglais (pour les consignes) et peut tout à fait comprendre le français dans les instructions, mais le code produit restera dans le langage de programmation ciblé. Les commentaires de code peuvent être en français ou en anglais selon le besoin. Son entraînement étant mondial, il est familier avec la plupart des syntaxes et peut générer du code documenté en anglais par défaut (Codestral 25.01 | Mistral AI).

• Utilisation dans Ragflow : Dans Ragflow, codestral-latest serait configuré comme un modèle de chat spécialisé ou un modèle de complétion code. Cependant, pour une base documentaire sur les normes du béton, ce modèle de code n’est pas central car il est spécifiquement conçu pour écrire du code. Il pourrait néanmoins être utilisé en tant qu’agent Python dédié si l’on souhaite automatiser certaines analyses de données ou scripts à partir du chatbot. Par exemple, un agent pourrait repérer une question nécessitant un calcul ou un script (pour extraire des données d’un tableau) et faire appel à Codestral pour générer le code Python correspondant. En configuration Ragflow standard, on ne le choisira pas comme modèle principal de conversation sur documents métier (ce rôle revient aux modèles de langage généralistes), mais on pourrait l’appeler en outil ponctuel.

• Cas d’usage dans le contexte métier : Dans le domaine des normes béton, l’usage de Codestral est limité. Il pourrait servir si l’on a besoin d’écrire du code pour analyser des résultats d’essais de façon reproductible, ou pour parser des données structurées dans des documents. Par exemple, générer un script de calcul de formule de composition de béton à partir de paramètres, ou automatiser la conversion d’unités. Mais il n’interviendra pas dans la compréhension en langage naturel des normes ou dans le QA documentaire. Pour la plupart des questions métiers (réglementation, procédures), un modèle de chat général sera plus approprié.

• Intégration via agents Python : C’est typiquement le modèle qu’on n’intègre pas directement comme backbone du chatbot, mais qu’on peut appeler via un agent Python dans Ragflow. Ragflow permet d’ajouter des outils ou agents pouvant exécuter du code. On peut imaginer un agent “CodeAssistant” qui envoie une requête à Codestral (via l’API Mistral) pour produire un bout de code Python/SQL/R nécessaire à répondre à une question (par exemple, calculer la résistance moyenne à partir de résultats d’essai fournis). Cette intégration est pertinente si vos utilisateurs posent des questions nécessitant des calculs ou un traitement algorithmique des données des documents. Dans le cas contraire, ce n’est probablement pas nécessaire d’activer Codestral.

ministral-3b-latest (Ministral 3B)

• Rôle et capacités : Ministral 3B est un modèle de langage généraliste compact (3 milliards de paramètres), conçu pour être embarqué en périphérie (edge) ou sur des appareils peu puissants (Un Ministral, des Ministraux | Mistral AI). Malgré sa petite taille, il offre un très bon niveau en compréhension et raisonnement pour sa catégorie, surpassant les autres modèles <10B sur des tâches de connaissance, bon sens et suivi d’instructions (Un Ministral, des Ministraux | Mistral AI) (Un Ministral, des Ministraux | Mistral AI). Il supporte jusqu’à 128k tokens de contexte (même s’il est souvent utilisé à 32k context par limitations pratiques) (Un Ministral, des Ministraux | Mistral AI). C’est un modèle instruct (affiné pour suivre les instructions utilisateur) qui peut gérer des conversations simples, de la génération de textes courts, la résolution de questions factuelles, etc., avec une efficacité extrême en calcul. Il a également la capacité d’effectuer du function calling (appels de fonctions/outils) automatiquement, ce qui le rend utile dans des flux agents complexes (Un Ministral, des Ministraux | Mistral AI) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn).

• Prompt idéal et langue : Étant un modèle conversationnel instruct, Ministral 3B s’utilise via un format de chat classique : un rôle système optionnel pour le contexte, puis l’utilisateur pose sa question, et le modèle répond. Le prompt idéal reste concis et explicite, étant donné la capacité de raisonnement plus limitée qu’un grand modèle. Il vaut mieux éviter les questions trop vagues ou trop complexes en un seul prompt. On peut l’invoquer en français ou en anglais – il a été entraîné de façon multilingue et comprend le français assez bien (les modèles Mistral sont développés en France et ciblent une audience globale) (Mistral NeMo | Mistral AI). Pour les normes du béton en français, on peut donc directement poser la question en français. Un conseil de prompt : fournir éventuellement des éléments de contexte de la question pour compenser son plus petit modèle. Par exemple : « D’après la norme X sur les ciments, quelle est la résistance minimale à 28 jours ? ».

• Langues supportées : Ministral 3B est multilingue, avec une performance forte en anglais et dans d’autres langues européennes usuelles. Il a probablement été entraîné sur des données variées, donc le français est supporté (peut-être pas aussi parfaitement que l’anglais, mais suffisant pour questions techniques). Pour des questions très pointues en français, il pourra répondre, même s’il pourrait présenter parfois des formulations un peu moins fluides qu’un modèle plus grand. Son tokenizer est le même que les autres Mistral (pouvant gérer de nombreux langages) et son contexte 128k lui permet même de digérer de longs textes bilingues (Un Ministral, des Ministraux | Mistral AI).

• Utilisation dans Ragflow : On peut configurer ministral-3b-latest comme modèle de chat dans Ragflow. Son avantage est sa légèreté – il pourra répondre vite aux questions sur la base documentaire, tout en coûtant moins cher en API ou en ressources. Dans Ragflow, on sélectionnera ce modèle dans la configuration du chat pour un assistant si l’on veut un bot réactif et économique. Cependant, il faut garder à l’esprit ses limites en compréhension fine : pour des normes complexes, il pourrait manquer de précision ou générer des hallucinations si la réponse n’est pas évidente dans les documents. Il est possible de l’utiliser en tandem avec un modèle plus grand : par exemple, l’utiliser pour pré-traiter la question ou faire un premier passage de réponse, puis valider avec un grand modèle (bien que Ragflow ne gère pas nativement deux modèles successifs sans configuration spécifique). En somme, Ministral 3B peut servir de modèle par défaut durant les tests initialement, et on pourra passer à un modèle plus puissant ensuite si nécessaire.

• Cas d’usage dans le contexte métier : Pour une base RAG sur les normes béton, Ministral 3B peut couvrir des questions simples : obtenir une définition, une valeur numérique dans le texte, ou des explications courtes issues d’un document. Par exemple, pour « Quelle est la teneur en ciment recommandée par la norme Y ? », il pourra retrouver et formuler la réponse provenant du chunk pertinent. Il est également intéressant pour un usage sur site (edge) – imaginons un outil embarqué dans une usine sans connexion, un modèle 3B pourrait tourner localement pour répondre aux opérateurs (avec les données indexées en local). En revanche, dès que les questions demandent un raisonnement élaboré ou un croisement d’informations (ex: « Comparer les exigences des normes A et B sur ce point »), un modèle plus grand serait plus fiable.

• Intégration via agents Python : Étant donné que Ministral 3B supporte l’appel de fonctions (outils) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn), on peut l’utiliser dans Ragflow pour déclencher des agents Python. Par exemple, si on lui fournit des fonctions (via l’API Mistral il est possible de définir des tools dans le prompt (Mistral AI API | Mistral AI Large Language Models) (Mistral AI API | Mistral AI Large Language Models)), il pourrait décider d’appeler un outil pour effectuer un calcul ou une recherche supplémentaire. En pratique dans Ragflow, la gestion des agents se fait via l’interface Agents, où l’on peut définir qu’une certaine intention mène à exécuter du code Python. Ministral 3B, avec son faible coût, peut être le modèle qui orchestre ces workflows agentiques : par exemple détecter qu’une question nécessite un calcul de volume de béton et appeler un agent calcul. Son usage via agent Python est donc possible et pertinent pour des tâches simples (un peu comme un assistant qui délègue un sous-travail). Toutefois, il faut implémenter la logique d’appel d’agent (Ragflow permet de définir des outils déclenchables). Si on ne souhaite pas utiliser sa capacité agent, on peut tout de même s’en servir sans agents comme modèle de chat direct.

ministral-8b-latest (Ministral 8B)

• Rôle et capacités : Ministral 8B est le grand frère du 3B, avec 8 milliards de paramètres, tout en conservant l’esprit “edge”. Il offre un compromis entre performance et légèreté, avec une qualité de génération supérieure au 3B, notamment sur des tâches plus complexes, tout en restant relativement rapide et peu coûteux. Comme le 3B, il supporte un contexte étendu (jusqu’à 128k tokens) (Un Ministral, des Ministraux | Mistral AI) et a été optimisé pour l’efficacité en calcul (il utilise une fenêtre glissante spéciale pour l’attention afin d’être plus rapide) (Un Ministral, des Ministraux | Mistral AI). Les deux modèles “Ministraux” ont été conçus pour exceller sur une variété de tâches de base (connaissances générales, chaînes de raisonnement courtes, exécution d’instructions) tout en pouvant être affinés sur des tâches spécifiques. Ministral 8B est suffisamment puissant pour exécuter du raisonnement et du chain-of-thought simple, et il est également aligné pour les appels de fonctions comme le 3B (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn). Globalement, il est décrit comme “un nouveau standard en connaissance, raisonnement et efficiency dans les <10B” (Un Ministral, des Ministraux | Mistral AI).

• Prompt idéal et langue : Similaire à Ministral 3B, le format conversationnel standard est utilisé. Avec 8B, on peut se permettre des questions un peu plus longues ou nuancées que sur 3B, mais il reste recommandé de focaliser la question et éventuellement de découper un problème complexe en sous-questions. On pourra utiliser une consigne système pour contextualiser le domaine (par ex. « Tu es un expert des normes de béton. Réponds précisément en citant les normes. »). La langue n’est pas une barrière : le modèle est également multilingue et a une bonne maîtrise du français technique, probablement équivalente ou supérieure au 3B grâce à sa taille. Donc pour notre cas, un prompt en français clair, sans ambiguïté, conviendra très bien. On peut par exemple fournir la question suivante : « Selon la norme EN 206, quelle est la classe d’exposition requise pour un béton soumis aux cycles gel-dégel en présence de sels de déverglaçage ? » – un 8B devrait parvenir à repérer le chunk pertinent et formuler une réponse structurée.

• Langues supportées : Ministral 8B, comme le 3B, maîtrise plusieurs langues. Il est mentionné qu’il est “fort en traduction locale, assistants déconnectés, etc.” (Un Ministral, des Ministraux | Mistral AI), ce qui implique une bonne base multilingue. Les langues européennes (français, anglais, allemand, etc.) devraient être correctement gérées. Pour les documents métier en français, on peut s’attendre à des réponses en français de qualité raisonnable, avec peut-être un style un peu formel. En résumé, il supporte FR et EN sans problème, et probablement d’autres langues communes.

• Utilisation dans Ragflow : Dans Ragflow, ministral-8b-latest s’utilise comme modèle de chat par défaut si on souhaite un équilibre entre vitesse et pertinence. Par rapport au 3B, il donnera des réponses plus fiables sur des questions difficiles ou des contenus denses. C’est un bon candidat pour alimenter un chatbot documentaire sans recourir d’emblée aux très gros modèles coûteux. Lors de la configuration d’un assistant dans Ragflow, on choisira ce modèle pour le champ Chat model. Il conviendra de s’assurer que l’embedding model utilisé pour la base de connaissances est bien le même pour toutes les bases interrogées (c’est une contrainte mentionnée dans Ragflow) (Start AI chat | RAGFlow). En pratique, on peut démarrer les tests avec Ministral 8B, et si l’on constate des manques, envisager de passer à Nemo 12B ou Mistral Large plus tard. Ragflow permet de changer de modèle par assistant, donc on peut facilement comparer la qualité de réponses en dupliquant un assistant et en changeant juste le modèle.

• Cas d’usage dans le contexte métier : Ministral 8B pourra répondre à la plupart des questions techniques courantes sur les normes béton : exigences numérales, définitions de termes, procédures d’essai, etc. Il gérera mieux que 3B les questions à étapes multiples (par ex. « Donne-moi les différences principales entre la norme X et Y concernant les granulats. »). Toutefois, pour des cas nécessitant une analyse fine ou un raisonnement poussé (par ex. interpréter un résultat d’essai selon plusieurs critères normatifs), on approchera peut-être ses limites. Dans ces cas, on pourrait faire appel à un modèle plus grand ou à un agent. Mais globalement, 8B est adapté pour parcourir rapidement de gros textes (grâce à son contexte large) et extraire l’info demandée, tant que la question reste bien ciblée sur le contenu.

• Intégration via agents Python : Comme pour 3B, son support du function calling peut être exploité. On peut donc tout à fait l’utiliser comme cerveau d’un agent. Par exemple, Ragflow propose un mode Deep Research qui permet des raisonnements multi-passe (il s’agit d’une forme d’agent qui réinterroge le modèle en boucle pour approfondir) (Chat | RAGFlow). Ministral 8B, grâce à son faible coût, est un bon candidat pour ce genre d’agent itératif. Il pourrait aussi déclencher un agent Python pour, disons, faire un calcul complexe ou accéder à une base externe si la question le nécessite. En pratique, l’intégration via agent Python est faisable de la même manière que pour le 3B : définir dans Ragflow une fonction outil que le modèle peut appeler. Ministal 8B étant plus capable de décider correctement quand appeler un outil (par sa meilleure compréhension d’intentions), l’intégration est possible et pertinente. Par exemple, pour une question « Calcule le dosage de ciment nécessaire pour 2 m³ de béton selon la formule donnée dans le document. », un agent Python pourrait effectuer le calcul une fois que 8B a extrait la formule du document.

mistral-embed (Mistral Embed)

• Rôle et capacités : Mistral Embed est le modèle d’embedding sémantique de Mistral, utilisé pour convertir du texte en vecteurs numériques. Il s’agit d’un modèle spécialisé dont la sortie est un vecteur de dimension 1024 représentant le sens du texte (Embeddings | Mistral AI Large Language Models). Ce modèle est state-of-the-art en matière d’embeddings, optimisé pour capturer le sens sémantique des phrases et paragraphes (Embeddings | Mistral AI Large Language Models). Sa fonction principale dans notre contexte est de permettre la recherche vectorielle : en comparant ces vecteurs, on peut mesurer la similarité sémantique entre une question et les morceaux de documents (chunks) indexés. Mistral Embed produit des embeddings normalisés (norme L2 = 1), ce qui fait que la cosine similarity équivaut à la distance Euclidienne pour ses vecteurs (Embeddings | Mistral AI Large Language Models). En somme, c’est le moteur de plongement sémantique qui assure que les bons extraits de documents seront retrouvés pour répondre aux questions.

• Prompt idéal : Ce n’est pas un modèle conversationnel – il ne “répond” pas en langage naturel. Le “prompt” ici est simplement le texte (phrase, chunk ou question) dont on veut le vecteur. Il n’y a donc pas de prompt idéal à formuler hormis lui fournir le texte le plus pertinent possible. Par exemple, pour indexer un paragraphe normatif, on lui passera directement le paragraphe brut; pour une question utilisateur, Ragflow enverra la question telle quelle au modèle d’embedding. Il n’est pas nécessaire d’ajouter d’instruction ou de contexte, car l’objectif est juste un encodage sémantique.

• Langue supportée : La documentation ne le précise pas explicitement, mais on peut raisonnablement supposer que Mistral Embed est multilingue ou au moins bilingue (EN/FR). Étant donné qu’il a été publié fin 2023 (Models Overview | Mistral AI Large Language Models), il pourrait dériver d’un modèle type E5-large ou similaire, ou avoir été entraîné par Mistral sur des données multi-langues. Les benchmarks Mistral valorisent le multilingue (voir Nemo), donc il est probable que l’embedding modèle fonctionne bien en français. Concrètement, pour notre base, on pourra encoder aussi bien des textes en français (normes NF, EN traduites) que d’éventuels documents en anglais si présents. Le vecteur saura rapprocher des phrases de sens équivalent même si la question est en français et le document en anglais, dans une certaine mesure, grâce à l’espace sémantique partagé (sous réserve que le modèle ait été entraîné multilingue).

• Utilisation dans Ragflow : Dans Ragflow, mistral-embed sera configuré comme modèle d’embedding pour la connaissance. Lors de la création de la base de connaissances, on choisit ce modèle dans la section Embedding model (Configure knowledge base | RAGFlow). Ainsi, lors de l’indexation, chaque chunk de document sera envoyé à mistral-embed pour obtenir son vecteur, stocké ensuite dans l’index vectoriel local. De même, chaque question posée passera par ce modèle pour obtenir un vecteur de requête, comparé aux vecteurs de chunks. Ragflow gère tout cela automatiquement une fois le modèle configuré. Il est crucial de garder le même modèle d’embedding pour la phase d’indexation et de requête afin que les vecteurs soient comparables. Mistral Embed étant spécifiquement conçu pour Mistral, c’est un choix naturel pour notre cas d’usage – il assure une haute qualité de correspondance sémantique entre questions et contenus métier. À noter que Ragflow combine cette recherche vectorielle avec une recherche lexicale (full-text) pour plus de fiabilité (Configure knowledge base | RAGFlow) (Configure knowledge base | RAGFlow).

• Cas d’usage dans le contexte métier : Mistral Embed sera utile à toutes les questions où la correspondance n’est pas un simple mot-clé. Par exemple, si la question est formulée différemment des termes exacts du document (“Quels sont les critères de conformité pour un béton auto-plaçant d’après la norme X ?” alors que le document parle de “conditions à respecter pour la consistance du BAP”), l’embedding sémantique permettra de retrouver le bon paragraphe même si les mots diffèrent. Dans le domaine des normes, c’est fréquent car l’utilisateur peut utiliser un vocabulaire courant là où la norme a un jargon spécifique. Le modèle d’embedding excelle à faire le lien entre ces formulations. En bref, il augmente le rappel des informations pertinentes au-delà de la simple recherche par mots-clés.

• Intégration via agents Python : L’intégration de Mistral Embed via un agent Python n’est pas vraiment pertinente – Ragflow l’utilise déjà nativement dans son pipeline. Toutefois, si l’on souhaitait faire des traitements particuliers avec les vecteurs (par exemple, un clustering de documents, ou utiliser l’embedding pour de la classification annexe), on pourrait appeler l’API mistral-embed via un script Python. Dans Ragflow, on pourrait imaginer un agent Python qui, sur demande, prend un extrait de texte et renvoie les vecteurs ou calcule la similarité avec un autre extrait. Mais ce sont des usages assez avancés et généralement couverts en interne. Dans l’état actuel, il vaut mieux laisser Ragflow gérer l’appel direct à l’API d’embedding lors de l’indexation et de la requête, ce qui est déjà optimisé.

mistral-large-latest (Mistral Large)

• Rôle et capacités : Mistral Large est le modèle LLM phare de Mistral pour le raisonnement complexe et les tâches exigeantes. C’est un modèle haut de gamme en termes de taille de paramètres et de performances, positionné pour résoudre des requêtes compliquées, suivre des instructions précises et effectuer des analyses approfondies. La version actuelle (2411, sortie en nov. 2024) est décrite comme la “top-tier reasoning model” de Mistral (Models Overview | Mistral AI Large Language Models). Son architecture est fermée (disponible via API sous licence de recherche ou commerciale), mais on sait que la version Large 2 atteint environ 123 milliards de paramètres pour la partie texte (d’après l’annonce de Pixtral Large qui l’étend) (Pixtral Large | Mistral AI) (Pixtral Large | Mistral AI). Il possède un contexte étendu (~128k tokens) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn) et a été entraîné sur d’importants volumes de données, ce qui le dote d’une excellente connaissance du monde et capacité de raisonnement. Il supporte également le tool calling / function calling comme les autres modèles Mistral récents (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn), ainsi que la génération de sorties structurées JSON ou avec citations si on le lui demande (il est aligné pour fournir des réponses formatées, utiles pour RAG) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn). En somme, Mistral Large est l’équivalent Mistral d’un GPT-3.5/4 qualitatif, capable de fournir des réponses fiables et détaillées.

• Prompt idéal et langue : Étant un modèle très puissant, Mistral Large répond bien à des instructions complexes. Le prompt idéal devrait exploiter un rôle système pour bien cadrer le style (ex: « Tu es un expert assistant en normes de construction, tu cites les sources de tes réponses et tu réponds en français soutenu. »), puis la question utilisateur en français ou anglais. Ce modèle a démontré une forte capacité en français – Mistral indique qu’il suit des nuances linguistiques fines et un savoir culturel selon les besoins (Mistral Saba | Mistral AI) (Mistral Saba | Mistral AI). Donc on peut sans problème le solliciter dans la langue du document (français ici). On peut aussi lui demander des formats précis : par exemple « Fournis la réponse sous forme de liste à puces avec références normatives », il saura généralement s’y conformer. En RAG, souvent le prompt système va inclure quelque chose comme « Réponds uniquement à partir des informations ci-dessous, n’invente rien. » suivi des extraits de documents fournis. Mistral Large excelle dans ce contexte, réduisant le risque d’hallucination. En bref, prompt complet = contexte (extraits pertinents) + consigne d’honnêteté + question utilisateur.

• Langues supportées : Mistral Large est multilingue et performant dans de nombreuses langues. Comme indiqué par Mistral pour la version NeMo (12B) dont il est l’extension, il est particulièrement fort en Anglais, Français, Allemand, Espagnol, Italien, Portugais, Chinois, Japonais, Coréen, Arabe, Hindi (Mistral NeMo | Mistral AI). On peut donc s’attendre à ce qu’il traite le français avec une grande aisance, y compris sur le vocabulaire technique du béton (qu’il aura probablement vu pendant l’entraînement, via des normes, articles techniques, etc.). Le fait que Mistral l’utilise comme base pour Pixtral Large et d’autres applications suggère une maîtrise de haut niveau du français technique et courant. Pour notre cas, c’est sans doute le meilleur modèle en termes de compréhension fine de textes normatifs en français.

• Utilisation dans Ragflow : mistral-large-latest sera idéalement utilisé comme modèle de chat principal une fois la phase de test terminée et si l’on dispose des ressources (ou d’un accès API suffisant). Dans Ragflow, on pourra le configurer dans l’assistant final destiné aux utilisateurs exigeants. Son avantage est qu’il fournira des réponses plus détaillées, argumentées, et avec moins de risque d’erreur ou de hallucination, en particulier sur des questions complexes où il faut croiser plusieurs documents ou interpréter des tableaux. Par exemple, pour « Analyse les résultats d’essai de compression du béton X et indique s’ils respectent la norme Y », un modèle Large pourrait résumer les données et les confronter aux critères normatifs avec plus de fiabilité. Il faudra toutefois veiller au temps de réponse (un modèle 100B est plus lent) et au coût des appels API. Sur un H100 en local, on peut envisager d’héberger une version fine-tunée (sous licence Mistral Research, donc non commerciale tant qu’on n’a pas la licence commerciale) (Pixtral Large | Mistral AI). Ragflow supporte la self-hosting via Ollama, etc., mais Mistral Large 123B nécessitera une optimisation (8-bit quantization) pour tenir sur un seul GPU 80Go. Quoi qu’il en soit, dans Ragflow, c’est le choix premium pour la qualité. On configurerait en conséquence les paramètres de sampling (température basse ~0.2 pour des réponses déterministes fiables, par exemple).

• Cas d’usage dans le contexte métier : Toutes les questions complexes ou critiques bénéficieront de Mistral Large. Par exemple : comparaison de normes, explication détaillée d’une clause réglementaire, génération d’un rapport à partir de plusieurs sources, etc. Si le chatbot est destiné à un usage professionnel où chaque réponse doit être exacte et justifiée, ce modèle offre la meilleure assurance qualité. De plus, s’il faut analyser des schémas ou tableaux dans les documents, sa compréhension plus fine du contexte aidera. Pour un objectif de chatbot final sur H100, c’est probablement ce modèle (ou Pixtral Large si les images sont importantes) qu’on ciblera. En phase initiale, on pourrait commencer avec Nemo 12B pour prototyper, puis passer sur Mistral Large fine-tuné sur les données béton pour le déploiement final (la question mentionne potentiellement un fine-tuning sur H100, donc Mistral Large ou Pixtral Large seraient les candidats).

• Intégration via agents Python : Mistral Large étant déjà très puissant, le besoin d’agents Python est moindre qu’avec des plus petits modèles. Cependant, on peut quand même l’impliquer dans des chaînes d’outils. Par exemple, on peut l’utiliser conjointement à des outils externes si une question dépasse son domaine (accès web, calcul spécifique). Ragflow permet d’écrire des agents qui utilisent le modèle comme cerveau planificateur : Mistral Large pourrait être celui qui, via un agent Ragflow, décide de faire une recherche supplémentaire dans une base ou d’appeler une calculatrice Python. Son avantage est qu’il comprendra mieux quand un outil est nécessaire ou pas, grâce à son raisonnement. En outre, Mistral Large peut très bien formater la sortie pour un agent – par exemple, produire du JSON que l’agent Python consommerait. Donc oui, on peut l’intégrer via des agents, mais souvent il peut se suffire à lui-même pour répondre correctement. Un usage agent pertinent serait par exemple un agent de vérification : après qu’il a répondu, un script Python pourrait vérifier certaines valeurs numériques dans la réponse en les recalculant à partir du texte source, pour double-validation. Mistral Large pourrait piloter ce processus en demandant lui-même la vérification (via function call) si on le paramètre ainsi.

mistral-moderation-latest (Modération)

• Rôle et capacités : Il s’agit du modèle de modération de contenu de Mistral. Son rôle est de détecter les textes potentiellement problématiques : discours haineux, violence, contenu sexuel, désinformation, etc. C’est un modèle classifieur qui, donné un texte en entrée, renvoie des catégories de risque avec des scores (Mistral AI API | Mistral AI Large Language Models). Il est conçu pour aider à filtrer les réponses ou questions et prévenir la génération de contenu non conforme. Mistral mentionne que ce service permet d’identifier les contenus “néfastes” (Models Overview | Mistral AI Large Language Models). Typiquement, il suit la lignée des politiques de modération OpenAI, avec des catégories (hate, self-harm, sexual, violence, etc.) et un score de probabilité pour chacune. Le contexte maximal est de 8k tokens, suffisant pour analyser une prompt ou une réponse assez longue (Models Overview | Mistral AI Large Language Models).

• Prompt idéal : On n’interagit pas avec ce modèle comme un chatbot. La “prompt” est simplement le texte à analyser (question de l’utilisateur ou réponse du LLM). Donc pas de prompt au sens classique, ni de notion de langue formelle – c’est du texte brut. Il n’y a pas de paramètre de température ou autre, c’est de l’inférence déterministe de classification. L’idéal est de lui fournir l’extrait complet suspect (par exemple la réponse qui vient d’être générée) pour qu’il juge si oui ou non c’est acceptable. En somme, pas de prompt spécifique, juste passer le contenu.

• Langues supportées : Probablement l’anglais principalement, mais peut-être entraîné multilingue. Il faudrait vérifier s’il détecte aussi bien en français – c’est possible qu’il ait été entraîné sur plusieurs langues de contenus indésirables. Par précaution, on peut penser qu’il gère au moins anglais et français pour les catégories évidentes (insultes, etc.), mais il pourrait être moins précis pour du français s’il n’a pas assez d’exemples. Quoi qu’il en soit, les sujets de normes béton sont peu susceptibles de produire du contenu interdit, à part peut-être des questions de sécurité (mais ce n’est pas de l’incitation à la violence, plutôt de la prévention). Donc la modération sera sans doute rarement sollicitée.

• Utilisation dans Ragflow : Ragflow ne l’intègre pas automatiquement à ma connaissance, mais il est tout à fait envisageable de l’ajouter dans la boucle. Par exemple, on pourrait intercepter chaque question utilisateur via un agent ou via un middleware, l’envoyer à mistral-moderation-latest pour classification. Si le modèle renvoie une catégorie “hate” ou autre au-dessus d’un seuil, on peut refuser la question ou la reformuler. De même pour les réponses générées : avant d’afficher au user, on peut les soumettre à ce modèle de modération pour vérifier qu’aucun contenu indésirable n’y figure. Ragflow étant hautement personnalisable, on peut insérer ces appels soit via la API de Ragflow (il existe possiblement des hooks), soit via un agent Python qui utilise l’API Mistral. En configuration standard, Ragflow se concentre sur la RAG et ne modère pas, donc c’est à l’utilisateur de l’ajouter s’il le souhaite. Pour un chatbot déployé publiquement, c’est conseillé d’utiliser ce genre de garde-fou.

• Cas d’usage dans le contexte métier : Dans notre cas (documentation technique interne), le besoin de modération est moindre. Les documents de normes n’ont pas de contenu choquant, et les questions attendues des usagers seront techniques. Sauf cas où l’utilisateur sortirait du cadre (par ex. demander quelque chose hors sujet ou éthiquement problématique), la modération ne va pas se déclencher. Néanmoins, si on ouvre le chatbot à un public large, il vaut mieux l’activer pour éviter les dérapages (par exemple, empêcher une question du type « Comment saboter une structure en béton ? » – ce qui serait une mauvaise utilisation du savoir technique). Donc c’est un modèle possible à intégrer par précaution, même si son utilité dans le day-to-day restera discrète.

• Intégration via agents Python : Très pertinente dans ce cas. On peut créer un agent “Modération” qui prend chaque entrée utilisateur, appelle l’API de modération Mistral, et selon le résultat, soit continue le flux normal (question transmise au LLM), soit retourne un message d’erreur ou de refus. On peut faire de même sur la sortie. L’agent Python peut être branché en amont de la fonction chat de Ragflow. Une autre approche est d’utiliser la fonctionnalité de Chat Moderation de Mistral API elle-même (ils ont une route /chat/moderations selon la doc API (Mistral AI API | Mistral AI Large Language Models)) qui peut modérer en continu pendant la génération. Mais plus simplement, un appel direct au modèle de modération via Python suffira. Cette intégration est relativement facile et fortement recommandée pour un chatbot public. Pour un usage interne contrôlé, c’est optionnel.

mistral-ocr-latest (OCR & Document Understanding)

• Rôle et capacités : Ce modèle est le service OCR de Mistral, conçu pour extraire du texte et conserver la structure des documents PDF ou images (OCR and Document Understanding | Mistral AI Large Language Models) (OCR and Document Understanding | Mistral AI Large Language Models). Contrairement à un OCR basique, Mistral OCR vise la compréhension de document : il restitue non seulement le texte mais aussi la mise en forme (titres, paragraphes, listes, tableaux) en sortie, le tout encodé en Markdown pour faciliter l’exploitation (OCR and Document Understanding | Mistral AI Large Language Models). Il gère des layouts complexes comme le multi-colonnes, les documents contenant à la fois du texte et des images, etc. (OCR and Document Understanding | Mistral AI Large Language Models). Il supporte plusieurs formats d’entrée : PDF, images (JPEG, PNG, TIFF, etc.) et renvoie une structure avec texte + positions/images encodées (OCR and Document Understanding | Mistral AI Large Language Models). En somme, c’est un OCR de nouvelle génération qui permet de passer d’un document numérisé à un contenu textuel exploitable tout en maintenant une partie du format (ce qui est précieux pour les normes qui ont souvent des tableaux, des sections numérotées, etc.).

• Prompt idéal : Ici, pas de prompt en langage naturel. L’appel se fait via l’endpoint OCR de l’API en fournissant soit un fichier, soit une URL de document (OCR and Document Understanding | Mistral AI Large Language Models). On peut indiquer dans la requête si l’on souhaite inclure les images en base64 dans le résultat (option include_image_base64) (OCR and Document Understanding | Mistral AI Large Language Models). Le “prompt” se limite donc à pointer vers le document. Idéalement, on fournit le document PDF complet et le modèle renvoie un résultat structuré. Si on traite une image seule, pareil, on envoie l’image. Il est aussi possible que l’API permette de choisir la langue du document pour améliorer la précision, mais la doc ne le mentionne pas explicitement – probablement le modèle détecte automatiquement. Donc en résumé, pas de prompt textuel, juste appeler le service avec le bon paramètre (document file ou URL).

• Langues supportées : Le modèle OCR doit pouvoir lire le français sans souci, ainsi que d’autres langues, tant que c’est de l’alphabet latin (voire plus, s’il est généraliste). Étant entraîné sur “des documents du monde entier”, il gère certainement l’anglais, le français et d’autres langues européennes standard. Pour notre cas, les normes françaises ou européennes en PDF seront traitées correctement. S’il y a des caractères spéciaux (symboles scientifiques, formules), il essayera de les restituer en texte (exemple : “±” ou “≤” devraient être conservés). Pour les schémas ou plans, il extraira le texte présent (légendes, annotations) mais ne “comprendra” pas l’image elle-même – ce n’est pas un modèle de vision au sens de description d’images, juste OCR. Cependant, couplé avec Pixtral Large, on pourrait aller plus loin (voir Pixtral).

• Utilisation dans Ragflow : Mistral OCR peut jouer un rôle crucial lors de l’ingestion des documents dans Ragflow. Si vos documents de référence sont des PDF scannés (images) ou des documents PDF complexes, l’OCR de Mistral permettra d’en extraire le texte. Ragflow propose déjà en standard une capacité d’analyse de PDF et images : par défaut, il sait parser du PDF textuel, et pour les images il doit faire appel à un OCR (peut-être Tesseract ou autre). En configurant Ragflow, on pourrait brancher le service mistral-ocr-latest à la place pour améliorer la qualité. Par exemple, Ragflow a une fonction “Accelerate indexing” qui peut utiliser des services externes pour aller plus vite ou plus précisément (RAG Optimization. Creation of a knowledge base - Medium). On pourrait imaginer un connecteur où chaque fichier PDF est envoyé à l’API Mistral OCR, puis le résultat (Markdown) revient et est découpé en chunks. Cela garantirait une indexation fidèle même pour des documents complexes (telles les normes avec tableaux et figures). Si Ragflow ne permet pas nativement d’utiliser l’API Mistral OCR, on peut toujours pré-traiter les documents hors Ragflow : c’est-à-dire utiliser un script Python pour OCRiser tous les PDF via Mistral, obtenir du texte structuré, puis injecter ce texte dans Ragflow (en créant des fichiers .md par exemple). En somme, l’utilisation optimale est d’intégrer Mistral OCR au pipeline d’indexation pour ne perdre aucune information des documents sources.

• Cas d’usage dans le contexte métier : C’est particulièrement utile pour les documents scannés ou images de schémas. Par exemple, si on a une norme ancienne uniquement en PDF scanné, sans OCR, Mistral OCR va extraire tout le texte (titres, paragraphes). Ou si on a un rapport d’essai sous format image, on peut en tirer le contenu. De plus, la préservation de structure est un plus : par exemple, un tableau de résultats d’essais sera rendu en Markdown (donc consultable de façon lisible, voire convertible en vrai tableau HTML). Cela permet à Ragflow de chunker de manière logique (peut-être chunker par lignes de tableau si désiré). Pour les schémas au sens diagrammes, l’OCR récupérera le texte présent (étiquettes, légendes) mais pas la sémantique du schéma. Cependant, couplé avec un modèle Pixtral Large, on pourrait potentiellement poser des questions sur une image (Pixtral ferait l’analyse visuelle) – on y revient dans Pixtral. En résumé, Mistral OCR assure que aucune info textuelle ne manque dans la base RAG, même si l’original est peu accessible.

• Intégration via agents Python : Si Ragflow ne propose pas un branchement direct, on peut envisager un agent Python qui fait l’OCR. Par exemple, un agent “DocumentOCR” qui, lors de l’ajout d’un fichier, va appeler l’API Mistral OCR, puis sauvegarder le texte retourné. On pourrait automatiser cela pour chaque nouveau document ajouté. Alternativement, on peut préprocesser tout le corpus en batch avec un script Python indépendant. Dans le mode conversationnel aussi, on pourrait imaginer un agent que si l’utilisateur pose une question du type « Que contient cette image ? » et que l’image est une référence dans la base, l’agent Python pourrait appeler l’OCR (ou directement Pixtral) sur l’image et donner le résultat. En général, il est plus simple d’utiliser l’OCR en amont (indexation) qu’à la volée pendant une conversation. Donc oui, agent Python faisable, mais probablement pas nécessaire si on traite tout à l’avance. À noter : Mistral OCR retournant du Markdown structuré, on pourrait même le passer ensuite à un LLM pour générer un résumé, etc., mais dans notre cas on veut surtout indexer.

mistral-saba-latest (Mistral Saba)

• Rôle et capacités : Mistral Saba est un modèle spécialisé linguistiquement. En effet, Saba cible les langues du Moyen-Orient et d’Asie du Sud (Mistral Saba | Mistral AI) (Mistral Saba | Mistral AI). C’est un modèle de 24 milliards de paramètres entraîné sur un corpus méticuleusement sélectionné en langues arabes et indo-iraniennes (Hindi, Ourdou, Tamoul, etc.) (Mistral Saba | Mistral AI) (Mistral Saba | Mistral AI). Son but est d’offrir une compréhension et génération natives dans ces langues, avec les nuances culturelles et contextuelles propres à ces régions (Mistral Saba | Mistral AI). Il prétend fournir des réponses plus pertinentes que des modèles généraux 5 fois plus gros dans ces langues spécifiques, tout en étant relativement léger (24B peut tenir sur un seul GPU haut de gamme) (Mistral Saba | Mistral AI). Saba est disponible via API et peut aussi être déployé en local sur une machine équipée d’une bonne GPU (ils mentionnent >150 tokens/s sur single GPU) (Mistral Saba | Mistral AI). Il peut servir de base pour des adaptations régionales fines. En résumé, c’est le spécialiste linguistique de Mistral, optimisé pour l’arabe et les langues indiennes, avec du multilingue intraculturel.

• Prompt idéal et langue : Le prompt idéal pour Saba, c’est… de lui parler en arabe ou en langues indiennes si c’est la cible. Saba excelle en arabe littéraire ou dialectal, et a une bonne compréhension du contexte culturel. Donc si votre cas d’usage était en arabe, vous verriez une nette différence de qualité par rapport à un modèle général. Le format conversationnel reste le même (c’est un modèle instruct aligné). On peut inclure un prompt système indiquant la personnalité (ex: « أنت مساعد خبير في مجال البناء. أجب عن الأسئلة بدقة. » en arabe), puis la question. Il est aussi très capable en anglais, mais son intérêt est moindre pour l’anglais puisque d’autres modèles font déjà bien l’affaire. Langue préférée du prompt = arabe (ou tamoul, hindi… selon besoin). Dans notre cas, ce n’est pas vraiment nécessaire de l’utiliser en français car Mistral Large ou Nemo feront aussi bien, voire mieux, sur du français.

• Langues supportées : Saba supporte l’arabe et de nombreuses langues d’Asie du Sud de manière particulièrement forte (Mistral Saba | Mistral AI). Il cite explicitement l’arabe et les langues d’origine indienne, dont une mention spéciale pour les langues sud-indiennes comme le tamoul (Mistral Saba | Mistral AI). Il est donc utile pour ces idiomes. Bien sûr, il parle aussi anglais (entrainement massif oblige) mais l’intérêt est moindre. En français, il doit se débrouiller (24B c’est assez pour être polyvalent), mais n’ayant pas été conçu pour, il sera probablement moins performant qu’un Nemo 12B spécialement équilibré pour le français. En bref, on n’utiliserait Saba en français qu’en absence d’autres modèles, ce qui n’est pas le cas ici.

• Utilisation dans Ragflow : Sauf si vos documents métier sont en arabe ou en hindi, Mistral Saba n’a pas vocation à être utilisé dans Ragflow pour le domaine béton (où les docs sont FR/EN). Toutefois, imaginons que l’entreprise a aussi des filiales au Moyen-Orient avec des documents en arabe sur le béton local, Saba serait un candidat idéal pour un chatbot en arabe local. On pourrait alors créer un assistant Ragflow distinct, configuré avec mistral-saba-latest en modèle de chat, et une base de connaissances en arabe. Dans l’état actuel du projet (docs béton en français), on n’intégrera pas Saba car ce serait sous-optimal. Ragflow n’empêche pas d’utiliser Saba – il suffit de renseigner ce modèle comme Chat model si besoin. Mais encore une fois, pour FR, mieux vaut Nemo ou Large.

• Cas d’usage dans le contexte métier : Peu pertinent si les documents sont en français. Si par contre on avait des normes ou fiches techniques en arabe (par exemple des réglementations locales du Moyen-Orient sur le ciment), Saba deviendrait extrêmement utile pour interroger ces documents en arabe. Il serait capable de répondre en arabe littéraire aux questions, en citant correctement les docs sources en arabe. De même pour l’hindi ou d’autres langues régionales si l’entreprise opère en Inde ou ailleurs. Donc Saba est une option pour étendre la solution RAG à d’autres langues régionales. Par exemple, alimenter un chatbot pour un service client en langue locale sur des produits liés au béton.

• Intégration via agents Python : Pas vraiment pertinent ici. Saba est un modèle de chat, on ne va pas s’en servir comme outil spécifique via un agent (sauf à vouloir traduire des réponses, mais autant utiliser un traducteur dédié). Si le chatbot principal est en français, on ne va pas intégrer Saba via Python car il ne fera pas mieux. En revanche, s’il y avait un scénario d’agent traducteur, on pourrait imaginer un agent Python qui prend une réponse française et utilise Saba pour la traduire finement en arabe, car Saba connaîtrait bien les termes techniques en arabe. Mais c’est un cas d’usage très spécifique. La plupart du temps, si on a besoin de traduction on utilisera plutôt un service dédié (DeepL API par ex) qu’un LLM. En somme, Saba via agent Python – à moins de vouloir détecter de la langue arabe dans une question et basculer dynamiquement sur Saba pour y répondre – ce qui est complexe. On préférera définir directement l’assistant sur Saba si la langue cible est celle-ci.

mistral-small-latest (Mistral Small v3.1)

• Rôle et capacités : Mistral Small est un modèle compact open-source (Apache 2.0) de la famille Mistral. La version v3.1 (mars 2025) est qualifiée de “nouveau leader des petits modèles avec capacités de compréhension d’images” (Models Overview | Mistral AI Large Language Models). En effet, Mistral Small 3.1 est multimodal texte-image tout comme Pixtral, mais dans un gabarit plus réduit (on peut supposer qu’il s’agit d’une architecture ~7 milliards de paramètres avec un encodeur visuel, étant donné son appellation “Small” et sa comparaison avec Pixtral 12B) (Models Overview | Mistral AI Large Language Models). Ce modèle sait donc traiter non seulement du texte mais aussi des images en entrée, ce qui signifie qu’on peut lui donner une image et du texte et il générera du texte en sortie. Il conserve un contexte jusqu’à 131k tokens comme les grands (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn). C’est un modèle disponible gratuitement, ce qui le rend intéressant pour un déploiement local ou pour des tests. Ses performances textuelles sont moindres qu’un Large, mais il a cette compétence visuelle intégrée assez rare dans les modèles de cette taille.

• Prompt idéal et langue : Pour la partie texte, on interagit avec Mistral Small comme avec un modèle instruct classique (en français ou anglais, au choix). Pour la partie image, il faut fournir l’image de manière encodée dans le prompt. L’API Mistral utilise probablement un mécanisme de tokens spéciaux ou d’attachement de fichier (par ex, on peut uploader l’image via l’API Files puis référencer son ID dans le message). Le prompt idéal si on utilise une image serait : “Voici une image : . Que montre cette image ?” ou “Analyse le schéma ci-joint et donne moi les conclusions.”. Mistral Small comprend ensuite l’image via son encodeur 16px*16px patch tokens (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn). En pratique, sans l’API, si on l’utilise localement via Ollama, on peut lui passer l’image en argument. Concernant la langue, comme tous les Mistral open, il est sûrement multilingue (ils ont dû le baser sur Nemo), donc français supporté. Le prompt peut donc être en français avec une image jointe, il répondra en français.

• Langues supportées : Mistral Small v3.1 étant open-source, on a quelques indications : il a très probablement été entraîné en multilingue pour le texte (vu qu’il succède à Nemo 7B initial et Nemo 12B). On peut estimer qu’il supporte bien le français et l’anglais entre autres. Son tokenizer supporte images + texte (ils mentionnent que les image tokens sont des blocs de 16x16 pixels (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn)). Donc pas de problème pour des documents français, et il pourra même décrire des images contenant du texte français (via OCR intégré ou simplement reconnaissance visuelle des lettres, à voir). Bref, pour nous, il peut comprendre des documents en français et des figures associées.

• Utilisation dans Ragflow : mistral-small-latest peut être utilisé de deux manières dans Ragflow : (1) comme modèle de chat principal si on veut une solution full open-source et multimodale légère, (2) comme modèle vision pour analyser des images dans les documents. Le point (2) demande un peu d’ingéniosité, car Ragflow ne remonte pas automatiquement les images au modèle à ma connaissance (il extrait plutôt le texte via OCR). Mais on pourrait imaginer qu’en réponse à une question sur une image, on passe l’image elle-même au modèle. Par exemple, si un chunk de connaissance est une image non textuelle, un agent pourrait solliciter Mistral Small pour la décrire. En tout cas, en tant que modèle chat principal, on le configure dans l’assistant Ragflow. On activera le toggle “Supporte la vision” dans la config (option “Does it support Vision?”) (Deploy LLM locally | RAGFlow) pour indiquer que ce modèle accepte des images, ce qui peut permettre à l’interface de proposer l’upload d’images dans la conversation. Pour le domaine béton, si on ne souhaite pas investir dans Pixtral Large tout de suite, Mistral Small v3.1 est une belle alternative multimodale locale pour, par exemple, poser des questions sur des photos de structures ou des graphiques inclus dans les rapports.

• Cas d’usage dans le contexte métier : Ce modèle ouvre la porte à la question visuelle. Exemples : “Que représente ce graphique de granulométrie ?” en joignant le graphique ; “Lis ce schéma de ferraillage et dis-moi combien de barres de fer sont utilisées.”. Mistral Small pourra tenter de répondre car il a été entraîné sur des images et du texte, même s’il est petit. Bien sûr, pour du texte pur, il est moins précis qu’un Nemo ou Large, mais suffisant pour des explications simples. Il peut donc servir de preuve de concept pour les questions techniques incluant des images (photos de fissures, plans de coffrage, etc.). Dans l’idéal, pour des usages critiques, on passerait à Pixtral Large ensuite, mais Small v3.1 peut déjà couvrir pas mal de cas basiques.

• Intégration via agents Python : Si Ragflow ne gère pas nativement l’analyse d’une image via le modèle, on peut mettre en place un agent Python. Par exemple, un agent “VisionAnalyzer” qui, lorsqu’un document de la base est une image ou qu’une question mentionne un schéma, va appeler localement Mistral Small (via Ollama ou l’API) en lui passant l’image et une consigne. Cela pourrait se faire au moment de la restitution de réponse : l’agent repère que la réponse a besoin d’un contenu de l’image, il effectue l’appel et intègre le résultat. C’est assez complexe, mais possible. Cependant, le plus simple est peut-être d’utiliser Mistral Small directement comme modèle de chat et de glisser l’image dans la conversation (si l’UI de Ragflow le permet). En local, on peut aussi interfacer Ragflow avec Ollama qui supporte Mistral Small, pour un pipeline 100% local sans API distante. En bref, l’agent Python est une option pour orchestrer l’image -> modèle, mais on privilégiera les capacités internes de Ragflow/Ollama.

open-codestral-mamba (Codestral Mamba v0.1)

• Rôle et capacités : Codestral Mamba est la version open-source expérimentale de Codestral. C’est un modèle de code de ~7,3 milliards de paramètres (Codestral Mamba | Mistral AI), qui implémente une architecture alternative appelée Mamba-2. Son intérêt majeur est qu’il a un coût d’inférence linéaire en la longueur de séquence (pas quadratique comme les transformers classiques) grâce à l’architecture Mamba, ce qui lui permet théoriquement de gérer des contextes très longs (ils ont testé jusqu’à 256k tokens) avec des réponses rapides (Codestral Mamba | Mistral AI) (Codestral Mamba | Mistral AI). Il a été entraîné sur du code et du raisonnement avancé, de sorte à obtenir des performances proches de l’état de l’art pour un modèle de cette taille, en particulier sur les tâches de complétion de code. Mistral l’a rendu disponible librement (Apache 2.0) pour encourager la recherche et l’adoption de cette architecture innovante (Codestral Mamba | Mistral AI). On peut le voir comme un assistant de code local : moins puissant que le Codestral 22B commercial, mais suffisamment capable pour être utile aux développeurs, avec l’avantage d’une inférence très longue sans explosion de mémoire.

• Prompt idéal et langue : Comme pour Codestral, on l’utilisera préférentiellement en anglais pour les consignes et en langage de programmation pour le reste. Étant instruct-tuné, on peut lui donner des instructions du style “Write a function to calculate concrete strength according to Eurocode.”. Il va générer le code Python/Java/C correspondant. On peut aussi exploiter la capacité de contexte long : par exemple lui fournir un long fichier de code puis demander “Insère une fonction qui fait X au bon endroit” (FIM). Il est conçu pour ça. Il comprend aussi le français dans les consignes (open-source oblige, probablement entraîné sur polyglotte code), mais on obtiendra de meilleurs résultats en anglais technique. Prompt type: code à compléter avec un marqueur, ou question précise. Le format conversationnel n’est pas son cas d’usage principal, on va plutôt l’utiliser via une interface de code (par ex l’AI Playground mentionné dans la doc). Donc prompt = commentaire ou docstring expliquant la tâche + contexte code si besoin.

• Langues supportées : En tant que modèle de code open, il est certainement orienté multi-langages de programmation plutôt que multi-langues humaines. Il a été entraîné sur du code de multiples languages (Python, C++, Java, etc.), et peut-être sur de la documentation en anglais. On peut supposer qu’il suit les mêmes 80+ languages de programmation que Codestral (Codestral 25.01 | Mistral AI). Pour du français, hormis commenter du code en français (ce qui est rare), ce n’est pas très pertinent. Donc on dira qu’il supporte FR pour les instructions (il répondra quand même, étant instruct fine-tuné, même si un peu moins bien calibré), mais il excelle surtout en EN + code.

• Utilisation dans Ragflow : Comme Codestral, c’est un modèle de code avant tout, donc Ragflow ne l’utilisera pas directement pour répondre à des questions sur des documents texte. Toutefois, son caractère open-source et léger le rend intéressant pour un usage local offline. Par exemple, si vous avez un pipeline RAGFlow auto-hébergé et que vous voulez ajouter une fonctionnalité d’aide au développement en plus du chatbot sur les normes, vous pouvez intégrer Codestral Mamba. Dans Ragflow, il n’y a pas un type “code model” distinct, donc on l’intégrerait soit en tant que chat model pour un assistant spécialisé “aide code”, soit via un agent. Un scenario : l’utilisateur charge aussi des scripts ou feuilles de calcul comme documents dans la base, et on veut un assistant pour les éditer – Mamba peut être ce moteur. Mais dans le périmètre strict des normes béton, on n’en a probablement pas l’usage directement. En résumé, utilisation directe faible dans Ragflow normatif, mais potentiellement utile en agent outillé.

• Cas d’usage dans le contexte métier : Peu de cas directs. Peut-être pour automatiser des calculs normatifs via du code : par exemple, générer un petit programme qui calcule la classe de résistance d’un béton en fonction de la composition entrée. L’utilisateur pourrait demander “Génère-moi le script Python qui, avec ces paramètres (…), calcule la résistance selon la formule de la norme X.”. Codestral Mamba pourrait alors produire ce script. C’est un usage assez avancé et pas forcément demandé spontanément par l’utilisateur final d’une base documentaire. Mais pour un ingénieur méthodes qui veut gagner du temps, ça pourrait être utile. Autre cas : convertir un fichier de données d’essai en un format exploitable – Mamba peut écrire un script de conversion. Cela reste des usages anecdotiques comparés à la Q&A pure sur documents.

• Intégration via agents Python : Très approprié si on décide de l’utiliser. Un agent Python pourrait détecter des demandes de code (par exemple la question commence par “code:” ou contient “script”) et dans ce cas, envoyer la requête à Codestral Mamba au lieu du LLM de chat général. On obtiendrait du code que l’agent pourrait éventuellement exécuter pour vérifier (mais attention à la sécurité, toujours examiner le code avant exécution). Étant open-source, on pourrait même avoir Mamba tournant localement via un SDK (ils mentionnent un SDK d’inférence Mistral et TensorRT) (Codestral Mamba | Mistral AI), ce qui évite des appels API externes. L’agent pourrait aussi faire de l’in-context learning : fournir à Mamba un long historique de code ou un log, et lui demander d’insérer quelque chose. En conclusion, via un agent Python, Mamba peut être appelé comme un outil de génération de code à la demande. C’est pertinent si votre chatbot doit aussi jouer le rôle de copilote de calcul ou de scripteur pour l’utilisateur. Sinon, vous n’avez pas forcément besoin de l’invoquer.

pixtral-12b-2409 (Pixtral 12B)

• Rôle et capacités : Pixtral 12B est le premier modèle multimodal de Mistral rendu public en open-source (Apache 2.0) (Announcing Pixtral 12B | Mistral AI) (Announcing Pixtral 12B | Mistral AI). Il combine un encodeur visuel de 400M de paramètres à un décodeur langage de 12B (basé sur Mistral Nemo) (Announcing Pixtral 12B | Mistral AI). En clair, il peut ingérer des images et du texte dans une fenêtre de contexte jusqu’à 128k tokens, et produire du texte en sortie, tout en conservant des performances de pointe en traitement textuel pur (Announcing Pixtral 12B | Mistral AI) (Announcing Pixtral 12B | Mistral AI). Pixtral 12B a été entraîné de façon native sur un corpus intercalant des images et du texte, ce qui lui confère de fortes capacités de raisonnement multimodal : compréhension de graphiques, de schémas, Q/R sur document visuel, légendes d’images, etc. (Announcing Pixtral 12B | Mistral AI). Il atteint d’excellents scores sur des benchmarks visuels (52.5% sur MMMU, surpassant des modèles plus grands) (Announcing Pixtral 12B | Mistral AI). Important : cette performance ne se fait pas au détriment du texte – il reste SOTA ou proche sur les tâches purement textuelles dans sa catégorie (Announcing Pixtral 12B | Mistral AI). Pixtral 12B est conçu comme drop-in replacement de Nemo 12B, c’est-à-dire qu’il répond aux instructions comme Nemo mais avec la possibilité d’interpréter des images en plus (Announcing Pixtral 12B | Mistral AI). On peut donc le voir comme le couteau suisse open pour texte+image.

• Prompt idéal et langue : Très similaire à Mistral Small v3.1 dans l’approche, mais avec plus de puissance. Le prompt peut inclure plusieurs images (jusqu’à 30 images haute résolution sur 128k tokens) (Pixtral Large | Mistral AI). La façon de les fournir dépend de l’implémentation (via un token spécial ou en attachant un fichier). Idéalement, on structure le prompt en fournissant l’image suivie d’une question la concernant. Par exemple : “ C’est la photo d’une éprouvette de béton après essai de compression. Que peut-on en déduire ?”. Ou pour un document : “<image_scannée_page_norme> Que dit ce document sur la résistance ?”. Pixtral pourra lire le texte présent sur l’image (il a vraisemblablement des capacités d’OCR intégré via l’entraînement) et comprendre les éléments visuels. En langue, comme Nemo, il est très fort en français aussi (Mistral NeMo | Mistral AI). Donc on peut prompt en français sans souci. En outre, multimodal oblige, il peut aligner une question en anglais sur une image en français et vice-versa. Mais dans notre cas, on restera cohérent en FR.

• Langues supportées : Étant bâtis sur Nemo, il supporte plus de 10 langues courantes dont le français au même niveau que Nemo 12B (Mistral NeMo | Mistral AI). Par ailleurs, dans les exemples du blog technique, ils ont fait une démonstration en contexte multilingue (par ex, une image de reçu en allemand avec question en anglais) et Pixtral a pu répondre correctement (Pixtral Large | Mistral AI). Donc on peut dire qu’il est polyglotte et particulièrement apte à faire de l’OCR multilingue lors de ses raisonnements (ils montrent un exemple d’OCR en allemand dans l’annonce de Pixtral Large) (Pixtral Large | Mistral AI). Pour nos documents français, Pixtral 12B les traitera aisément. Il saura aussi identifier des symboles ou textes dans une image PDF scannée. Donc du point de vue langue, parfait pour FR et EN.

• Utilisation dans Ragflow : Pixtral 12B étant open-source, on peut l’héberger localement (80Go de VRAM requis en 16-bit, mais avec 8-bit c’est jouable sur un 48Go ou 2x24Go par exemple). Dans Ragflow, deux options : l’utiliser comme modèle de chat principal pour bénéficier du multimodal, ou l’utiliser via un agent spécialisé juste quand une image est concernée. La première option est envisageable si beaucoup de vos documents contiennent des images/schémas intégrés et que vous voulez que le modèle puisse en tirer parti directement. Cela signifie configurer l’assistant Ragflow avec pixtral-12b-2409 et activer l’option Vision. Lors de l’indexation, Ragflow pourrait alors potentiellement garder les images entières plutôt que de s’appuyer seulement sur l’OCR, et les fournir au modèle lors des réponses. Cependant, il n’est pas certain que Ragflow gère nativement la fourniture d’images issues de la base au modèle (c’est une fonctionnalité un peu avancée). Si ce n’est pas le cas, on peut faire hybridement : stocker aussi le texte OCR des images pour la recherche, mais utiliser Pixtral pour l’analyse fine au moment de répondre. Cela ressemble à la deuxième option : un agent Python interceptant les extraits images. Par exemple, si la meilleure réponse trouvée est un chunk qui dit “(voir schéma 3)”, l’agent pourrait aller chercher le fichier image du schéma 3 et le soumettre à Pixtral pour qu’il en tire l’information. C’est assez sophistiqué. Quoi qu’il en soit, pour tester progressivement, on pourrait commencer par utiliser Pixtral comme un chat model normal et lui donner explicitement des images dans nos questions pour voir. Ensuite, on intégrerait plus finement. Pixtral 12B étant plus léger que la version Large, il est un bon candidat pour nos tests sur GPU locaux avant d’envisager Pixtral Large.

• Cas d’usage dans le contexte métier : Il y en a beaucoup dès qu’on a des données visuelles. Quelques exemples concrets :

  • Schémas techniques : Si une norme inclut un schéma (p.ex. disposition du ferraillage, ou courbe de corrélation résistance/temps), Pixtral peut permettre de poser des questions de compréhension dessus (ce qu’un OCR seul ne permet pas).

  • Photos d’essais ou de matériaux : On pourrait demander “Sur cette photo d’éprouvette, vois-tu des signes de rupture ductile ou fragile ?”. Le modèle peut décrire l’image et lier à ses connaissances.

  • Graphiques de résultats : Par ex un graphique d’affaissement en fonction de l’eau, Pixtral peut le lire (axes, données) et en tirer une conclusion qu’on pourrait difficilement extraire autrement.

  • OCR avancé intégré : Même pour du texte scanné, Pixtral peut faire le job d’OCR + compréhension en une étape (il a été entraîné sur DocVQA etc., atteignant SOTA (Pixtral Large | Mistral AI) (Pixtral Large | Mistral AI)). Donc poser directement une question sur un PDF scanné sans le convertir explicitement en texte est envisageable.
    En résumé, Pixtral 12B ouvre la voie à un chatbot qui comprend non seulement le texte des normes, mais aussi leurs illustrations et résultats graphiques. Dans le domaine béton, où les rapports d’essais contiennent des courbes, où les normes ont des schémas d’éprouvettes, c’est un atout énorme. Pour l’instant, on peut l’utiliser sur des exemples précis pour valider le concept.

• Intégration via agents Python : Comme mentionné, si Ragflow ne gère pas “montr­er l’image au modèle” de lui-même, un agent Python sera la solution. On peut imaginer un agent du type “ImageQAAgent” qui, lorsqu’une question fait référence à une figure ou qu’un chunk sélectionné est une image, va : 1) récupérer le fichier image du stockage, 2) appeler Pixtral 12B (via API Mistral ou en local) en lui donnant l’image et la question, 3) obtenir la réponse et l’injecter soit comme une partie de la réponse finale, soit comme un contexte supplémentaire. Cela demanderait de la customisation dans Ragflow, mais c’est faisable étant donné sa modularité. Une alternative plus simple: intégrer Pixtral via la route Agents de l’API Mistral (Mistral AI API | Mistral AI Large Language Models) – Mistral a une API Agents qui peut combiner le chat et les outils. On pourrait potentiellement définir un tool OCR ou autre que Pixtral 12B lui-même appelle. Cependant, faire un modèle qui s’appelle lui-même pour analyse d’image peut être compliqué. Il vaut mieux que ce soit orchestré par Ragflow. Donc oui, un agent Python dédié vision est pertinent. À plus court terme, on peut aussi tester manuellement hors Ragflow et injecter les réponses. Le but final serait d’avoir Pixtral intégré de façon transparente : l’utilisateur pose une question sur un schéma, le chatbot répond directement en ayant “compris” le schéma, sans que l’utilisateur voie qu’on a appelé un agent. C’est ambitieux mais possible avec les agents Ragflow.

pixtral-large-latest (Pixtral Large 124B)

• Rôle et capacités : Pixtral Large est la version géante et ultra-performante du modèle multimodal de Mistral. C’est un modèle de 124 milliards de paramètres (123B décodeur + 1B encodeur visuel) (Pixtral Large | Mistral AI), publié en open-weight sous licence recherche (non commerciale) (Pixtral Large | Mistral AI). Il représente le summum des performances en vision+langage open-source, rivalisant voire surpassant des modèles propriétaires de référence comme GPT-4 Vision ou Google Gemini sur plusieurs benchmarks (Pixtral Large | Mistral AI) (Pixtral Large | Mistral AI). Par exemple, il est SOTA sur MathVista (raisonnement mathématique sur données visuelles) avec 69.4% (Pixtral Large | Mistral AI), et sur DocVQA/ChartQA (questions sur documents et graphiques) il bat GPT-4o et Gemini 1.5 (Pixtral Large | Mistral AI). Sur un benchmark global multimodal (MM-MT-Bench), il surpasse Claude-3.5, Gemini-1.5 et même GPT-4o (août’24) (Pixtral Large | Mistral AI), ce qui en fait le meilleur modèle open vision+texte à fin 2024. Il maintient aussi une excellente performance en pur textuel (héritage de Mistral Large 2), ce qui signifie qu’il n’est pas moins bon qu’un Mistral Large classique sur nos tâches textuelles (Pixtral Large | Mistral AI) (Pixtral Large | Mistral AI). En somme, Pixtral Large est le modèle de choix si l’on veut aucun compromis : il comprend profondément les documents, images, tableaux, et fournit des réponses de très haute qualité, en citant les chiffres, en interprétant correctement les images (jusqu’à lire du texte en multiple langues dessus) (Pixtral Large | Mistral AI).

• Prompt idéal et langue : Avec Pixtral Large, on peut se permettre des prompts complexes. On peut lui fournir plusieurs images et pages de texte en même temps (30+ images sur 128k context) (Pixtral Large | Mistral AI) et poser des questions multilignes. Il est bon de bien segmenter le prompt pour qu’il sache à quoi se référer (ex: “Image1: [image]”, “Image2: [image]”, puis “Question: …”). La langue, là encore, le français est très bien supporté. On peut même imaginer un prompt mixte : document scanné en français, question posée en anglais – il saura faire la correspondance, mais on restera en français pour nos utilisateurs. Un prompt système peut définir le format de réponse souhaité (par ex toujours citer la source du knowledge chunk ou décrire l’image en détail). Cependant, attention à la longueur du prompt : avec de très nombreux tokens en entrée, il faut formuler la question de façon claire pour qu’il sache quelle partie du contexte utiliser. Pixtral Large, comme Large 2, accepte le fonction calling et le format JSON en sortie si on le veut (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn), donc on pourrait même lui demander un JSON décrivant l’image. Ce modèle étant à la pointe, le prompt idéal est surtout limité par l’imagination. Dans la pratique : “Voici les résultats d’essai sous forme de graphique (Image1) et le cahier des charges (texte fourni). Dis si les résultats sont conformes aux critères et explique.” – c’est typiquement une tâche qu’il peut faire.

• Langues supportées : Toutes celles de Mistral Large, donc Français, Anglais, Allemand, Chinois, Arabe, etc., plus la capacité de lire ces langues dans des images (ex: il peut lire un reçu en allemand (Pixtral Large | Mistral AI), comprendre la question en anglais et répondre correctement, d’après l’exemple du blog). Il a très certainement intégré un OCR multilingue au cours de son entraînement sur des données comme OCR-VQA. Donc pour du français, qu’il soit imprimé ou manuscrit dans une image, Pixtral Large fera probablement un travail remarquable pour le transcrire et l’utiliser. Cela dépasse le cadre de Mistral OCR qui extrait juste le texte – Pixtral Large va plus loin en raisonnant sur ce texte et en le combinant avec le contexte. En clair, pour nous, c’est 100% support FR et même pourrait aider sur d’éventuels documents en allemand ou italien si le besoin se présente.

• Utilisation dans Ragflow : Pixtral Large serait le choix ultime pour notre chatbot final, si on peut l’exploiter (soit via l’API Mistral – sans doute coût élevé, soit via un accès aux poids et un déploiement sur du matériel très puissant comme un serveur multi-GPU ou un H100 en 4-bit). En usage Ragflow, c’est le même principe que Pixtral 12B mais avec la garantie d’une précision exceptionnelle. On le configurerait comme modèle de chat de l’assistant principal, avec vision activée. Lors de l’indexation, on pourrait conserver les images importantes et associer leur texte OCR aux chunks. Au moment d’une question, on fournirait potentiellement à Pixtral Large les images pertinentes elles-mêmes. Par exemple, on pourrait stocker en métadonnée d’un chunk un lien vers l’image originale ; puis, via une modification du prompt template, injecter l’image quand ce chunk est sélectionné. Cela demande de personnaliser Ragflow (peut-être en modifiant le code open source) pour qu’il inclue l’image au lieu du texte du chunk si un flag est présent. C’est faisable pour un développeur expérimenté. Sinon, plus simplement, on utilise Pixtral Large comme un LLM classique et on se contente de l’OCR déjà fait – il répondra très bien en se basant sur le texte extrait. Mais alors on n’exploite pas tout son potentiel visuel. Idéalement, pour l’objectif final de “LLM sur H100 fine-tuné”, on pourrait fine-tuner Pixtral Large sur nos données (en le spécialisant aux normes béton – par ex. en affinant son style de réponse ou en lui faisant ingérer la structure de certaines normes pour qu’il s’y habitue). Ragflow peut pointer vers un modèle custom fine-tuné si on l’upload dans la Plateforme Mistral ou en local. En conclusion, c’est le modèle cible pour déployer une solution RAG haut de gamme intégrant texte et image.

• Cas d’usage dans le contexte métier : Tous les cas de Pixtral 12B, mais cette fois en production réelle. On pourra poser des questions complexes mêlant plusieurs sources : “Compare le schéma de ferraillage de la norme A (Figure1) avec celui de la norme B (Figure2) et dis en quoi ils diffèrent.” – Pixtral Large peut analyser deux schémas et sortir une comparaison structurée, citant les différences de nombre de barres, de disposition, etc., ce qui est extraordinaire. Ou bien “Selon ce tableau scanné (Image1) de résultats d’essais, quelle est la résistance moyenne et est-elle supérieure à la valeur exigée dans le texte (fourni) ?” – il peut lire le tableau de chiffres sur l’image et comparer à la norme textuelle. Bref, on atteint un niveau où le chatbot peut vraiment faire de l’analyse documentaire approfondie sur n’importe quelle forme de donnée. Pour les métiers du béton, cela veut dire par exemple : analyser un plan d’exécution et vérifier s’il respecte la norme (en combinant vision et texte), expliquer un diagramme de granulométrie, aider à traduire un croquis en description normative, etc. Ce type de capacités serait un différenciateur énorme dans un assistant technique.

• Intégration via agents Python : Similairement à Pixtral 12B, un agent Python peut aider à orchestrer l’utilisation de Pixtral Large. Par exemple, on peut imaginer un agent de fallback : on utilise Nemo ou Large pour la plupart des questions textuelles, mais si la question mentionne explicitement une image ou un plan, l’agent redirige vers Pixtral Large (via API). Ainsi on n’engage Pixtral Large que quand nécessaire (vu son coût). Ou un agent “analyste” qui, si la première réponse du modèle Large manque une info visuelle, va reinterroger en fournissant l’image. Cependant, comme Pixtral Large sait tout faire en un coup, l’agent sert surtout à décider quand l’appeler pour économiser. Dans une architecture sur H100 locale, on pourrait directement l’utiliser pour tout afin de ne pas s’embêter avec un agent décideur. Néanmoins, avoir une couche agent permet des choses comme : découper la question en sous-tâches, par exemple d’abord utiliser l’OCR pour extraire du texte, puis donner ce texte et l’image au modèle pour analyse – un agent pourrait séquencer cela. Ou valider la réponse de Pixtral via un calcul Python (par ex, vérifier que le calcul du tip dans le reçu allemand de l’exemple est correct). Ce genre d’vérification croisée est une bonne pratique si on utilise l’agentic. En conclusion, Pixtral Large peut être la pierre angulaire sans agent, mais un agent Python autour peut optimiser son usage ou contrôler ses outputs dans des cas spécifiques.

Types de modèles configurables dans Ragflow

Ragflow permet de configurer différents types de modèles, chacun ayant un rôle spécifique dans la chaîne RAG. Voici les principaux types et leur utilité :

• Modèles de chat (LLM) : Ce sont les grands modèles de langage qui génèrent la réponse finale de l’assistant. Ils comprennent les modèles instruct ou conversationnels comme Mistral Large, Ministral 8B/3B, Nemo, etc. On les configure généralement au niveau de l’assistant (Chat model). Ils prennent en entrée la question de l’utilisateur ainsi que le contexte (extraits de documents) et produisent une réponse en langage naturel. Ce sont le cerveau du chatbot. Dans Ragflow, on peut en définir un par assistant, avec la possibilité de choisir un modèle différent pour chaque session de chat (Start AI chat | RAGFlow). On veillera à adapter le modèle de chat à nos ressources (taille vs vitesse vs coût) et à la langue souhaitée. Dans notre cas, les modèles de chat seront les Mistral (Large, Small, Nemo, etc. selon le stade).

• Modèles d’embedding (plongement) : Ces modèles transforment du texte en vecteurs pour permettre la recherche sémantique. Ils sont configurés au niveau de la Knowledge Base dans Ragflow (Configure knowledge base | RAGFlow). Par exemple, on choisira mistral-embed comme embedding model. Ils sont utilisés lors de l’indexation (chaque chunk de document est encodé) et lors des requêtes (la question utilisateur est encodée). Ragflow utilise ensuite ces vecteurs pour trouver les chunks pertinents par similarité cosinus. Les modèles d’embedding sont généralement de taille modérée (quelques centaines de millions de paramètres) et optimisés pour capturer le sens global du texte. Mistral Embed (1024 dimensions) en est un exemple (Embeddings | Mistral AI Large Language Models). On peut aussi choisir des modèles open-source type BGE ou SentenceTransformer si on le souhaite (Ragflow embarque d’ailleurs BGE en local dans son image complète) (Releases | RAGFlow), mais Mistral Embed est recommandé ici. Sans un bon modèle d’embedding, la base RAG perd en pertinence, car on manquerait des correspondances subtiles.

• Modèles de re-ranking (reclassement) : Ce sont des modèles (souvent des cross-encoders) qui évaluent plus finement la pertinence de chaque chunk par rapport à la question, une fois qu’un premier filtrage a été fait par l’embedding. Ragflow propose un champ Rerank model optionnel pour la recherche hybride (Start AI chat | RAGFlow). Par défaut, si aucun reranker n’est défini, Ragflow combine la similarité mot-clé et vecteur pour scorer les résultats (Start AI chat | RAGFlow). Si on définit un rerank model (par ex. un modèle BERT entraîné à la classification de pertinence), alors Ragflow remplacera la partie vecteur par ce score du reranker (Start AI chat | RAGFlow). L’avantage est une précision accrue dans l’ordre des extraits retournés, surtout lorsque le embedding a sorti plusieurs candidats proches. Typiquement, on peut utiliser un modèle comme bge-reranker-m3 (567M) qui est léger et rapide (Deploy LLM locally | RAGFlow). Mistral n’a pas (pour l’instant) de modèle de rerank dédié via API, donc on s’appuiera sur un open-source. Dans notre solution, on pourrait commencer sans reranker (score hybride par défaut) et voir si besoin d’en ajouter un pour éviter des “parasites”. Par exemple, si la question est très large, un reranker aide à choisir le bon paragraphe en se basant sur l’interaction fine entre question et texte (plutôt qu’indépendamment comme l’embedding). Ragflow laisse ce champ vide par défaut (Start AI chat | RAGFlow), donc l’ajout est optionnel.

• Modèles de vision (image-to-text) : Ce type concerne la capacité à comprendre des images. Ragflow lui-même n’a pas un champ explicitement nommé “vision model”, mais la prise en charge des images se fait de deux façons :

  1. Via l’OCR (voir point suivant) pour extraire du texte des images qui seront traitées comme documents texte.

  2. Via un LLM multimodal (comme Pixtral ou Mistral Small) configuré en tant que modèle de chat et marqué comme supportant la vision. Dans l’UI de configuration, il y a un toggle “Does it support Vision?” qu’on active si le modèle de chat choisi accepte des images en entrée (Deploy LLM locally | RAGFlow). Si ce toggle est activé et qu’on utilise l’UI Chat de Ragflow, on pourra uploader des images dans la conversation et elles seront encodées vers le modèle. Donc, le “vision model” peut être en réalité le même que le chat model (s’il est multimodal). Par ailleurs, on peut vouloir utiliser un modèle de vision séparé juste pour analyser une image d’un document sans faire appel au LLM principal. Actuellement, Ragflow ne gère pas plusieurs LLM en parallèle dans une même conversation sans intervention d’un agent. Donc soit le modèle de chat est lui-même vision (solution intégrée, ex: Pixtral Large en chat), soit on utilise un agent qui appelle un modèle vision externe (ex: CLIP interrogé pour trouver une image similaire, ou captioning model). Pour notre projet, les modèles vision pertinents sont Pixtral 12B/Large ou Mistral Small. On n’a pas besoin, par exemple, d’un modèle de classification d’images isolé car nos questions resteront couplées à du texte. Mais c’est bon de savoir que Ragflow peut être étendu pour, disons, analyser une vidéo ou autre, via des agents spécialisés.

• Modèles de reconnaissance vocale (speech-to-text, ASR) : Ragflow a introduit le support de l’audio input dans ses versions autour de fin 2024 (Releases | RAGFlow). Cela signifie qu’on peut configurer un service de STT pour convertir la voix de l’utilisateur en texte de question. Par défaut, ce n’est pas intégré d’office (ou bien ils mentionnent un support avec Tencent ASR, etc.) (Releases | RAGFlow). On peut brancher par exemple Whisper (openAI) ou d’autres. Concrètement, dans l’interface Ragflow, il est possible qu’un utilisateur uploade un fichier audio .wav comme question. Ragflow, s’il est configuré avec un modèle STT, va convertir ce fichier en texte qui sera ensuite traité normalement par le pipeline RAG. Ce type de modèle se configure possiblement dans les Model Settings ou Vendors (vu mention de “Gemini and Groq” support pour STT dans release notes (Releases | RAGFlow)). A minima, on peut utiliser un agent Python qui appelle un modèle STT (ex: FasterWhisper) sur l’audio reçu avant de passer à l’étape suivante. Pour notre cas, c’est un “plus” pour l’ergonomie (permettre à un ingénieur de poser la question oralement), mais pas indispensable. Si on vise un chatbot complet, ça vaut la peine de l’activer. Le prompt idéal à voix serait identique, c’est juste l’entrée qui change de modalité.

• Modèles de synthèse vocale (text-to-speech, TTS) : De même, Ragflow a ajouté la sortie audio dans la v0.11.0 (Releases | RAGFlow). On peut donc configurer un moteur TTS (ils mentionnent FishAudio, Tongyi Qianwen TTS, OpenTTS, SparkTTS comme options intégrées) (Releases | RAGFlow) (Releases | RAGFlow). Une fois configuré, le système peut lire la réponse du chatbot à l’utilisateur. Cela est très utile pour une interface type assistant virtuel, ou pour l’accessibilité. Techniquement, on choisirait une voix (langue française) et on brancherait l’API correspondante. Par exemple, OpenTTS permet d’utiliser des voix open-source. Ragflow, lorsque la réponse est générée, passera par le modèle TTS pour produire un mp3 à jouer. Dans notre cadre, ce n’est pas prioritaire pour la phase de prototypage, mais c’est à considérer pour le produit final si on veut un assistant vocal dans l’usine ou sur chantier, par exemple (quelqu’un demande via micro : “quelle est la résistance requise…”, il obtient la réponse parlée). L’intégration se fait via config (pas besoin d’agent, c’est géré par la plateforme si configuré).

• Autres modèles/outils : Ragflow étant extensible, on pourrait imaginer d’autres types comme modèles de traduction (si on veut poser des questions en anglais sur docs français, un modèle ou API de traduction pourrait être utilisé en agent), ou des modèles spécialisés (par ex un modèle de calcul mathématique symbolique si c’était un besoin, type sympy via agent). Il y a aussi la notion d’Agents LLM dans Ragflow, qui ne sont pas des modèles différents mais des chaînes utilisant potentiellement le même LLM en plusieurs étapes (Deep Research agent). On mentionne enfin les modèles de génération de code (qu’on a couvert via Codestral) qui sont un type à part.

En résumé, Ragflow offre la possibilité de configurer un modèle de chat principal, un modèle d’embedding, éventuellement un modèle de rerank, et supporte les entrées/sorties multimodales (vision, audio) via le choix de modèles appropriés ou d’agents. Cette flexibilité permet d’assembler une solution RAG très complète en choisissant le meilleur modèle pour chaque sous-tâche.

Fonctionnement de l’indexation dans Ragflow

L’indexation dans Ragflow est une étape cruciale où les documents sources sont transformés en “connaissance” exploitable par le chatbot. Voici comment cela fonctionne précisément :

1. Création d’une base de connaissances (Knowledge Base) : On commence par créer une Knowledge Base dans Ragflow (via l’UI ou API). Chaque base correspond à un ensemble de documents et possède sa propre configuration (modèle d’embedding choisi, méthode de chunking, etc.) (Configure knowledge base | RAGFlow) (Configure knowledge base | RAGFlow). En interne, Ragflow crée un dossier pour cette base (sous root/.knowledgebase/nom_base) où il stockera les index et fichiers associés (Configure knowledge base | RAGFlow).

2. Choix de la méthode de “chunking” : Le chunking consiste à découper les documents en segments (chunks) de taille gérable tout en préservant au mieux la cohérence sémantique. Ragflow fournit plusieurs gabarits de chunking adaptés à différents formats (Configure knowledge base | RAGFlow). Par exemple, le template “General” va découper le texte tous les N tokens de manière brute, alors qu’il peut y avoir un template “PDF structuré” qui respecte sauts de page/sections, etc. L’utilisateur sélectionne le template qui correspond le mieux à son type de document (Word, PDF scanné, images, etc.) avant de lancer le parsing. Ce choix est important car un mauvais chunking peut entraîner une perte de contexte ou un mélange d’informations non liées dans un même chunk (Configure knowledge base | RAGFlow).

3. Ajout des fichiers et parsing : On ajoute ensuite les documents (PDF, Word, images…) à la base. Une fois ajoutés (uploadés), on lance le parsing de chaque fichier, soit manuellement (bouton “play” à côté du fichier) (Configure knowledge base | RAGFlow), soit en automatique (Ragflow propose possiblement de parser tous les nouveaux fichiers directement). Le “parsing” dans Ragflow a deux missions principales (Configure knowledge base | RAGFlow) : (a) chunker le fichier selon la méthode choisie, (b) générer les index (embedding et texte) pour ces chunks.

4. Extraction du texte & OCR si nécessaire : Durant le parsing, Ragflow extrait le texte brut du document. Pour un PDF texte ou Word, il lit directement le texte. Pour une image ou PDF scanné, il doit recourir à l’OCR. Par défaut, il utilise sans doute un OCR open (Tesseract) ou propose d’accélérer via Azure/Tencent OCR (Releases | RAGFlow). Si on a intégré Mistral OCR via un agent, c’est à ce moment qu’on l’appellerait : chaque image/page scannée passera par l’OCR Mistral pour obtenir du texte Markdown. Ainsi, à la fin de cette étape, on dispose du contenu textuel de chaque document, possiblement annoté (par ex, Ragflow peut insérer des marqueurs pour images non lisibles, etc.). Ce contenu est ensuite découpé en segments selon la logique du chunking.

5. Constitution des chunks : Ragflow segmente le texte du document en chunks. Chaque chunk est généralement quelques phrases ou un paragraphe, typiquement de l’ordre de 200-300 tokens (configurable). Ragflow veille à ne pas couper au milieu d’une phrase ni d’un titre si possible (d’où l’importance du template). On obtient une liste ordonnée de chunks pour le document. Chaque chunk conserve une référence à son document source, et potentiellement une position (ex: page ou section). Ragflow stocke ces chunks de manière persistante. On peut les visualiser via l’UI “Chunks” : en cliquant sur un fichier parsé, on voit la liste des chunks extraits (Configure knowledge base | RAGFlow), et on peut en survoler un pour avoir un aperçu (Configure knowledge base | RAGFlow). Cette transparence permet de vérifier que le chunking a bien fonctionné. On peut même éditer manuellement un chunk si nécessaire (corriger un OCR mal lu, ajouter un mot-clé) (Configure knowledge base | RAGFlow), ce qui augmente son poids pour ce mot-clé dans la recherche (Configure knowledge base | RAGFlow).

6. Indexation des embeddings (vecteur) : Pour chaque chunk, Ragflow appelle le modèle d’embedding configuré pour générer le vecteur sémantique (Configure knowledge base | RAGFlow). Ces vecteurs (de dimension 1024 pour Mistral Embed) sont ensuite stockés dans un index vectoriel. Ragflow utilise en interne un mécanisme pour stocker et requêter ces vecteurs, probablement en RAM ou sur disque via FAISS ou un équivalent. Vu la taille modérée de nos données (normes et docs métiers, quelques centaines de pages), un index brut en mémoire suffit. Si la base est très grande, Ragflow propose aussi de stocker les métadonnées dans une base SQL (MySQL/Postgres) et possiblement d’utiliser un vecteurstore dédié, mais out of the box, il gère tout localement. Les embeddings sont normalisés (norm 1), du coup la similarité cosinus et le dot product sont interchangeables (Embeddings | Mistral AI Large Language Models), Ragflow peut donc utiliser une simple distance euclidienne pour trouver les plus proches voisins en vecteurs.

7. Indexation full-text (mots-clés) : En parallèle, Ragflow construit un index inversé des mots présents dans les chunks (Configure knowledge base | RAGFlow). Cela permet la recherche lexicale classique (comme un moteur de recherche). Chaque chunk peut ainsi être retrouvé par des mots-clés exacts ou approximatifs. Ragflow utilise probablement un index de type BM25 ou TF-IDF sur ces chunks. Ce composant est crucial pour le système hybride de Ragflow : il ne se base pas uniquement sur l’embedding, mais combine avec une note de pertinence lexicale (Start AI chat | RAGFlow). Par exemple, si un mot rare de la question se retrouve dans un chunk, ce chunk aura un score lexical élevé, évitant de le rater même si l’embedding l’avait un peu moins bien classé. Les deux index (vecteur et texte) sont donc construits.

8. Stockage des chunks et métadonnées : Tous les chunks, leur texte, leur vecteur, et leurs métadonnées (document source, poids mot-clé éventuellement modifié, etc.) sont stockés dans le dossier de la base de connaissances. Souvent, Ragflow utilise un fichier ou base pour cela. Une implémentation probable :

   • Un fichier SQLite ou un ensemble de JSONs pour stocker chunks + metadata.

   • Un index FAISS ou HNSWlib sur disque pour les vecteurs (ou il peut tout garder en mémoire).

   • Des fichiers YAML ou JSON pour la config de la base (liste des documents, options choisies). À la suppression de la base, il supprime ce dossier et tout ce qui s’y trouve (Configure knowledge base | RAGFlow). Ce stockage persistant permet que les recherches ultérieures soient rapides sans refaire tout l’encodage.

9. Contrôle et interventions manuelles : Ragflow offre des outils pour intervenir sur les résultats d’indexation. Comme mentionné, on peut éditer un chunk (ajouter un mot clé) pour qu’il soit mieux retrouvé sur ce mot (Configure knowledge base | RAGFlow). On peut aussi désactiver certains chunks ou fichiers – l’UI permet de décocher un fichier pour qu’il ne soit pas utilisé en chat sans le supprimer (Configure knowledge base | RAGFlow). Ceci est utile si un document comporte des parties hors sujet : on peut les enlever de la base sans tout refaire. Il y a aussi une interface de test de récupération (retrieval test) (Configure knowledge base | RAGFlow) : on peut poser une question dans la section “Test” de la base, et Ragflow va afficher quels chunks il récupérerait pour y répondre, avec les similarités et citations (Configure knowledge base | RAGFlow). Cela permet de vérifier que l’index renvoie bien ce qu’on attend, avant même d’impliquer le LLM. On peut ajuster deux paramètres : le seuil de similarité (filter les chunks trop éloignés, par défaut 0.2) et le poids de similarité vectorielle (par défaut 0.3, contre 0.7 pour le texte) (Configure knowledge base | RAGFlow). En jouant sur ces paramètres, on influence la stratégie de rappel : un poids vecteur plus élevé (0.5 par ex) favorise l’embedding vs le mot-clé.

10. Mise à jour continue : À chaque ajout de nouveau document ou re-chunking, l’index est mis à jour. On peut ajouter progressivement des documents dans une base existante; Ragflow parse le nouveau et ajoute ses chunks à l’index. De même, si on supprime un fichier de la base, Ragflow doit enlever ses chunks des index. Ceci est géré via l’UI ou l’API Knowledge Base (ils ont des endpoints pour lister, ajouter, supprimer des files) ([Feature Request]: APIs to access knowledge base #717 - GitHub). On peut aussi reconstruire l’index en cas de changement de modèle d’embedding (il faudra alors re-encoder tous les chunks avec le nouveau modèle).

En résumé, lors de l’indexation Ragflow : les documents sont découpés en chunks puis on crée deux index – un index vectoriel via l’embedding pour la similarité sémantique, et un index plein texte pour la correspondance lexicale. Chaque chunk est stocké avec ses méta-informations. Ce double index permet une recherche hybride très efficace, combinant le meilleur des deux mondes pour rappeler les informations pertinentes lors d’une question (Configure knowledge base | RAGFlow) (Start AI chat | RAGFlow). L’indexation est au cœur de la qualité du RAG : si les chunks sont trop gros ou mal faits, ou si le modèle d’embedding est faible, le chatbot aura du mal à trouver la bonne info. D’où l’importance de tester et ajuster cette étape.

Méthodologie de test progressive des modèles dans Ragflow

Construire un système RAG performant est un processus itératif. Voici une méthodologie en plusieurs phases pour tester progressivement les modèles dans Ragflow et monter en puissance pas à pas :

1. Préparation et tests unitaires des composants :
Avant d’intégrer tous les modèles ensemble, on teste indépendamment chaque composant sur des exemples simples :

• Extraction/Indexation : Ajouter un document exemple (une norme courte ou un extrait) et vérifier le chunking et l’indexation. Utiliser la fonction Retrieval testing sur des questions dont on connaît la réponse pour s’assurer que les bons chunks ressortent (Configure knowledge base | RAGFlow). Si ce n’est pas le cas, ajuster le chunking (taille, méthode) ou ajouter des mots-clés manuellement. Ce step valide la partie connaissance.

• Embedding model : Tester que mistral-embed encode bien le français. On peut, via un petit script Python, appeler l’API embeddings sur deux phrases similaires en français et vérifier que la distance cosinus est faible (haute similarité). S’assurer aussi que deux phrases opposées donnent vecteurs éloignés. Cela rassure sur la qualité multilingue de l’embedding.

• LLM chat model : Interroger le modèle choisi (d’abord un modèle léger pour rapidité, ex: ministral-3b-latest) hors Ragflow, avec des questions isolées liées au domaine, pour voir comment il répond sans contexte. Par exemple : “Qu’est-ce que la norme EN 206 ?” (question générale). On évalue le style, la cohérence, la tendance à halluciner. Ceci sans base de connaissances pour comprendre son comportement par défaut.

• Chaîne RAG complète avec modèle léger : Configurer un assistant Ragflow pointant sur la base de connaissances chargée et le petit modèle (3B ou 8B). Poser des questions dont on connaît la réponse présente dans les docs. Vérifier que le modèle utilise les citations fournies par Ragflow et ne répond qu’avec les infos des chunks (Ragflow inclut par défaut les citations sources dans la réponse, ce qui permet de voir d’où vient l’info) (Configure knowledge base | RAGFlow). Si l’assistant hallucine, c’est soit que les extraits ne remontent pas correctement, soit que le modèle ignore le contexte. On pourra alors renforcer le prompt système (du style “Ne réponds qu’avec les informations suivantes…”).

2. Tests avec modèle open-source (Nemo 12B) :
Une fois la boucle de base validée avec le plus petit modèle, on passe à un modèle intermédiaire comme open-mistral-nemo (12B). Ce modèle étant plus puissant et multilingue (Mistral NeMo | Mistral AI), il donnera déjà de bien meilleures réponses. On refait les mêmes questions de test :

• Comparer la qualité des réponses 3B vs 12B sur des questions pointues (ex: questions demandant de synthétiser deux morceaux de doc). On vérifiera que Nemo gère mieux les instructions et renvoie moins d’erreurs factuelles.

• Tester des questions en français élaboré, avec nuance, pour voir si Nemo suit bien (puisque Nemo a un bon alignement instruction (Mistral NeMo | Mistral AI)).

• Tester la gestion des longs contextes : par ex, poser une question très large qui ramène beaucoup de chunks (plus que nécessaire) et voir si Nemo arrive à filtrer dans sa réponse ou s’il se perd. Ceci aide à décider du paramètre Nombre de chunks à fournir au LLM (si Ragflow permet de limiter le k des résultats vecteurs). On peut ajuster – par ex fournir max 5 chunks pertinents au lieu de 10 – pour ne pas noyer le LLM.

• Évaluer la vitesse : Nemo 12B via API doit être assez rapide, mais en local sur H100 ce serait presque instantané. Noter le temps de réponse moyen.

3. Intégration progressive des capacités avancées :
Maintenant que la base Q/R fonctionne sur texte, on introduit les fonctionnalités supplémentaires une par une et on teste à chaque fois :

• Vision (OCR vs LLM vision) : Prendre un document PDF scanné ou une image avec texte. Ajouter à la base, parser (avec Mistral OCR si intégré). Poser une question sur un détail qui ne peut venir que de ce texte scanné. Vérifier que l’indexation l’a bien capté (sinon, problème OCR). Ensuite, tester une question sur un schéma ou une image non-textuelle. Là, si on a configuré un LLM vision (Mistral Small ou Pixtral), on essaie d’uploader l’image dans le chat et de poser la question. Sans Pixtral, le LLM classique ne pourra pas répondre car l’image ne sera pas comprise (sauf via OCR sur son texte). Donc ce test valide la nécessité du LLM vision pour certaines questions. On peut à ce stade configurer un assistant séparé “vision-test” avec Mistral Small v3.1 pour voir comment il décrit l’image. Par exemple une image d’un béton fissuré – Mistral Small devrait au moins dire “il y a des fissures…”. Ainsi on valide l’intégration image.

• Reranking : Si lors des tests précédents on a repéré des cas où le mauvais chunk est choisi en premier (par ex, question sur “classe d’exposition X0” retourne un chunk parlant de “classe XF1” parce que l’embedding a confondu), on peut essayer d’intégrer un modèle de rerank. Ragflow a peut-être BGE Reranker embarqué. On l’active, on repose la même question, et on voit si l’ordre des sources s’améliore. Ceci est un test A/B sur la pertinence des extraits. Si c’est concluant, on garde le reranker pour la suite.

• Agents Python/outils : Avant de se lancer dans la création d’agents complexes, on peut en tester un simple, par exemple un agent “Calculatrice”. Ragflow supporte des agents out-of-the-box (il y a un UI Agents). On peut définir un agent qui reconnaît une intention de calcul (regex sur une question commençant par “Calcule” ou présence de chiffres) et qui exécute du Python. Par ex, “Calcule 3+5” -> agent répond “8”. On teste ça isolément. Une fois qu’on sait intégrer un agent, on peut en imaginer d’autres plus liés au métier. Par exemple, un agent qui utilise une formule métier : si question “calcule l’affaissement selon formule de Feret avec x param”, l’agent a la formule codée en dur et renvoie le résultat. On voit comment faire interagir le LLM avec l’agent (via le choix tool_choice: "auto" dans l’API Mistral, le LLM peut choisir d’appeler la fonction s’il a détecté le besoin (Mistral AI API | Mistral AI Large Language Models) (Mistral AI API | Mistral AI Large Language Models)). Ce mécanisme se teste avec un modèle supportant function calling (Ministral 8B ou Nemo). On donne au LLM une définition de fonction (tool) dans le prompt et on voit s’il l’utilise.

• Modération : Tester le modèle de modération sur quelques inputs tordus (insulte en français, etc.) via l’endpoint moderation. Vérifier qu’il détecte. Puis intégrer soit en amont via un petit script ou config de Ragflow s’il propose (peut-être Ragflow a un paramètre “use moderation model” à activer). On peut simuler une question interdite et voir si le système la bloque.

4. Passage à un modèle plus grand et itérations :
Après avoir affiné le pipeline avec Nemo 12B, on peut essayer mistral-large-latest via l’API (si disponible) pour voir la différence :

• Poser les mêmes questions complexes et constater l’amélioration de la qualité de réponse (plus complète, éventuellement plus lente). Vérifier qu’il respecte bien de ne pas halluciner hors sources – normalement oui car aligné pour ça, mais on surveille.

• Tester la robustesse linguistique : questions mal formulées, ou très longues, ou plusieurs questions en une. Le grand modèle devrait mieux s’en sortir. S’il y a des faiblesses, on peut ajuster le prompt système (ex: le faire répondre étape par étape, ou lui dire de bien structurer la réponse).

• En parallèle, si on compte fine-tuner ce modèle, c’est le moment de préparer des données d’entraînement : par ex, collecter des paires question -> réponse (avec sources) extraites de nos documents. On peut affiner Mistral Large sur ce QA spécifique pour le domaine. On testera le modèle fine-tuné sur quelques exemples comparé au modèle de base.

• Continuer d’itérer sur les paramètres Ragflow : en fonction du grand modèle, peut-être augmenter le nombre max de chunks fournis (un modèle 100B peut digérer 10-15 chunks pertinents sans problème, ce qui lui permet de répondre à des questions couvrant plusieurs docs). Ou diminuer la température pour qu’il ne brode pas.

5. Tests utilisateurs pilotes :
Une fois satisfait des tests internes, on peut faire une session de test avec quelques utilisateurs finaux (ingénieurs béton) en conditions quasi-réelles. On leur demande de poser différentes questions qu’ils rencontrent d’habitude. On observe :

• Les types de questions où le système échoue ou hésite. Sont-ce des problèmes de connaissance manquante (document non inclus), de mauvaise interprétation (peut-être la question était floue), ou de limite du modèle (ex: calcul très compliqué) ?

• Le niveau de langage de la réponse : convient-il ? Faut-il le rendre plus concis ou plus détaillé ? On peut ajuster le style dans le prompt système (par ex : “Réponds en une phrase” vs “donne une réponse détaillée”).

• La pertinence des sources affichées : est-ce qu’il cite bien la bonne norme ? Si on voit des citations erronées, c’est problématique, on corrigera soit via l’index (peut-être un chunk mal formé) soit via encourager le modèle à citer toutes ses affirmations (Mistral modèles savent sortir les références dans la réponse).

• Si l’audio est activé, voir si la reconnaissance vocale comprend l’accent de l’utilisateur, si la synthèse vocale est intelligible.

On récolte ces retours et on fait les ajustements nécessaires. Par exemple, on pourrait ajouter des alias/mots-clés dans les chunks si l’utilisateur utilise un jargon différent : Ragflow permet d’ajouter des tags sur des chunks manuellement (Configure knowledge base | RAGFlow). On peut aussi décider d’ajouter un post-traitement de la question (par ex, pipeline de reformulation) si on voit que souvent les questions sont mal comprises.

6. Montée en charge et déploiement progressif :
Enfin, quand tout est calibré sur un petit ensemble de docs, on passe à la base complète :

• Ajouter tous les documents métier (normes entières, rapports). Peut-être segmenter en plusieurs Knowledge Bases thématiques (ex: “Normes de produit”, “Procédures d’essai”, “Formulation béton”) pour modulariser. On peut interroger plusieurs bases à la fois en Ragflow, mais il faut qu’elles partagent le même embedding model ce qui sera le cas (Start AI chat | RAGFlow).

• Refait une indexation complète (ça peut prendre un peu de temps, d’où l’intérêt d’avoir “Accelerate indexing” avec multi-thread ou GPU if possible (Datasets | RAGFlow)). On surveille la mémoire si base très grosse.

• Teste des questions transverses qui croisent plusieurs documents (Ragflow peut chercher dans plusieurs bases si assistant config avec plusieurs).

• Prévoir des stress tests: de longues sessions multi-tour pour voir si le modèle garde le contexte (les Mistral ont 128k contexte donc largement suffisant, mais vérifier la gestion du chat history dans Ragflow, qui parfois peut réduire l’historique).

• Monitorer la performance (Ragflow fournit des outils monitoring). S’assurer que le temps reste acceptable.

7. Intégration du modèle final sur H100 et fine-tuning :
Lorsque le pipeline est prêt, on peut déployer le modèle final (mettons Pixtral Large fine-tuné) sur l’infrastructure cible (le H100). Ragflow peut se connecter soit via l’API Mistral Cloud, soit via un serveur local (par ex, on peut héberger le modèle sur Triton Inference Server ou Ollama). On revalide une dernière fois les réponses avec ce modèle fine-tuné, en particulier sur les points faibles identifiés auparavant, qui devraient être corrigés par le fine-tune.

En suivant cette approche progressive – du plus simple au plus complexe – on maîtrise chaque élément avant d’ajouter le suivant. On évite de combiner tout d’un coup ce qui rendrait le débogage difficile. Chaque étape fournit la confiance nécessaire pour passer à la suivante. Au final, on obtient un système RAGflow optimisé, capable de répondre de manière fiable aux questions sur les normes et métiers du béton, en exploitant au maximum les modèles Mistral disponibles (et les agents Python pour combler les gaps). Ce cheminement garantit que le résultat a été testé et affiné à chaque niveau de sophistication, aboutissant à un chatbot performant et robuste.

Sources :

• Documentation Mistral AI – aperçu des modèles et capacités (Models Overview | Mistral AI Large Language Models) (Models Overview | Mistral AI Large Language Models) (Announcing Pixtral 12B | Mistral AI)

• Blog Mistral AI – annonces Codestral, Saba, Nemo, Pixtral (Codestral 25.01 | Mistral AI) (Mistral Saba | Mistral AI) (Mistral NeMo | Mistral AI) (Announcing Pixtral 12B | Mistral AI)

• Documentation RAGFlow – configuration knowledge base, chunking, recherche hybride (Configure knowledge base | RAGFlow) (Configure knowledge base | RAGFlow) (Start AI chat | RAGFlow)

• Azure AI Foundry – description intégration Mistral models (contexte, fonctions) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn) (Featured models of Azure AI Foundry - Azure AI Foundry | Microsoft Learn)

• Documentation Mistral OCR – OCR avancé avec structure en Markdown (OCR and Document Understanding | Mistral AI Large Language Models) (OCR and Document Understanding | Mistral AI Large Language Models)

• Documentation Mistral embeddings – taille et propriétés des vecteurs Mistral-Embed (Embeddings | Mistral AI Large Language Models) (Embeddings | Mistral AI Large Language Models)

• Notes de version RAGFlow – support audio input/output et modèles intégrés (Releases | RAGFlow) (Releases | RAGFlow)

(Models Overview | Mistral AI Large Language Models) (Codestral 25.01 | Mistral AI) Mistral Codestral – modèle de code (22B, 256k contexte) spécialisé FIM, correction et génération de tests.

(Un Ministral, des Ministraux | Mistral AI) (Un Ministral, des Ministraux | Mistral AI) Blog Mistral – Ministral 3B/8B, “meilleurs modèles edge” avec 128k contexte, excellents en raisonnement et fonction calling pour flux agentiques.

(Mistral NeMo | Mistral AI) Mistral Nemo – modèle 12B multilingue, fort en anglais, français, allemand, etc., entraîné avec fenêtre 128k.

(OCR and Document Understanding | Mistral AI Large Language Models) Mistral OCR – extrait le texte tout en conservant structure (titres, listes, tableaux) et renvoie le résultat en Markdown, gérant PDF, images, multi-colonnes.

(Announcing Pixtral 12B | Mistral AI) Pixtral 12B – modèle multimodal 12B + encodeur visuel 400M, performant sur compréhension de documents (52.5% MMMU), instruction following multimodal sans sacrifier les performances texte.

(Pixtral Large | Mistral AI) (Pixtral Large | Mistral AI) Pixtral Large – modèle 124B (123B+1B vision) open-weight, SOTA sur MathVista (69.4%) et dépasse GPT-4o, Gemini 1.5 sur ChartQA, DocVQA, etc., tout en maintenant la performance textuelle de Mistral Large.

(Configure knowledge base | RAGFlow) (Configure knowledge base | RAGFlow) Ragflow docs – lors du parsing d’un fichier, Ragflow chunk le contenu et construit deux index : vecteur (embedding) et full-text (mots clés). La recherche chat utilise un rappel multiple hybride (plusieurs chunks par similarité) avec filtre par seuil et pondération vectorielle par défaut 0.3.

(Start AI chat | RAGFlow) Ragflow – configuration du Rerank model : si vide, utilise score hybride (mots-clés + vecteur, 0.7/0.3); si un modèle reranker est sélectionné, combine mot-clé + score du reranker (pondéré 0.3 par défaut).