Amsafis Wiki

Machine Learning · IA Générative (RAG-LLM) · Systèmes Experts

En quoi elles diffèrent, comment elles interagissent, et pourquoi les trois sont essentielles pour l’aide à la décision à enjeux élevés.

L’IA moderne n’est pas une technologie unique.

Chez amsafis, les systèmes d’aide à la décision combinent trois formes distinctes d’Intelligence Artificielle, chacune avec une logique différente, des forces différentes et des exigences opérationnelles différentes :

1. Machine Learning (ML) — apprend des modèles prédictifs à partir de données.
2. IA générative avec RAG (Retrieval-Augmented Generation) — interprète des documents non structurés et fournit un raisonnement en langage naturel fondé sur des preuves.
3. Systèmes Experts (SE) — mettent en œuvre des règles transparentes et auditables pour une logique critique ou réglementée.

Chacune d’elles est une IA à part entière. Aucune ne remplace les autres.

Ensemble, elles forment une boucle fermée :

données → prédiction → règles → preuves → décision

Le Machine Learning extrait des motifs, interactions et signaux à partir de jeux de données structurées — typiquement des tables de type tableur, et non des images, de l’audio ou de la vidéo.

amsafis est spécialisé précisément dans ce domaine : variables numériques ou bien codées, éventuellement clairsemées, bruyantes ou hétérogènes.

Le ML nécessite un jeu de données dont il peut apprendre. En pratique :

• lignes = cas (patients, actifs, événements, transactions)
• colonnes = variables (numériques, ordinales, catégorielles codées)
• dimension temporelle optionnelle = données fonctionnelles ou longitudinales

Chez amsafis, le ML n’implique pas :

• apprentissage d’images
• apprentissage audio
• vision par ordinateur
• traitement de texte brut sans structure

(Ces domaines appartiennent à des spécialisations deep learning en dehors du périmètre du cabinet.)

De nombreux workflows ML incluent des tests statistiques classiques :

• chi carré
• tests t, tests F
• test exact de Fisher
• tests de rapport de vraisemblance

Ces tests sont utiles pour la validation scientifique, mais pas strictement nécessaires pour intégrer de nouvelles connaissances dans :

• les systèmes d’IA générative (RAG-LLM)
• les Systèmes Experts

Pour ces deux piliers, des statistiques descriptives suffisent souvent :

• fréquences et tableaux croisés
• moyennes, écarts-types, quantiles
• associations simples

Si une organisation possède déjà des outils BI (Power BI, Tableau, SQL analytics, rapports ERP), ces résultats descriptifs peuvent être directement utilisés pour alimenter :

• un modèle basé sur des règles, ou
• un référentiel RAG

sans nécessiter un projet complet de modélisation inférentielle.

Cela évite des retards inutiles et rend l’adoption de l’IA pratique, même avec des ressources analytiques internes modestes.

Ils peuvent être calculés non seulement à partir de jeux de données complets, mais parfois à partir de statistiques récapitulatives (SSD) :

• nombre de cas
• moyennes et écarts-types
• corrélations
• matrice de covariance

Cela permet :

• régression linéaire
• médiation
• SEM (modèles d’équations structurelles)
• PLS (partial least squares)

Cela permet de modéliser sans partager les jeux de données bruts.

Mais les SSD ne peuvent coder que des relations linéaires — tout est résumé. Les SSD ne peuvent conserver :

• interactions non linéaires
• hétérogénéité
• seuils
• effets locaux
• clusters latents

Pour détecter ces phénomènes, il faut utiliser le jeu de données complet.

C’est là que le ML moderne excelle :

• modèles additifs
• modèles basés sur arbres
• méthodes à noyau
• analyse de données fonctionnelles
• modèles hybrides mécanistiques-statistiques

Les SSD ne peuvent pas exprimer la non-linéarité. Donc :

• linéaire ≠ suffisant
• linéaire ≠ réaliste pour des données biologiques, opérationnelles ou industrielles
• linéaire ≠ pérenne

Les résultats du ML sont des entrées pour d'autres composants :

• Systèmes Experts

Les règles peuvent incorporer des seuils, clusters ou catégories de risque dérivés du ML.

• RAG-LLM

Les résultats ML peuvent être documentés et intégrés au référentiel de preuves.

• Optimisation (non IA)

Si nécessaire, les sorties ML peuvent être utilisées dans une optimisation mathématique (ex. programmation linéaire). Un Système Expert peut aussi appeler une logique d’optimisation en interne.

L’IA générative est le paradigme d’IA le plus récent, devenu largement connu depuis la sortie de ChatGPT. Contrairement au ML et aux SE, elle utilise la modélisation du langage plutôt que des données structurées ou des règles explicites.

Mais les LLM ne sont pas intrinsèquement fiables. Ils nécessitent un ancrage.

C’est pourquoi amsafis utilise RAG comme architecture obligatoire :

• récupérer des documents ou fragments
• les fournir au modèle
• générer des réponses explicitement liées aux preuves

• Utilise des LLM dans le cloud (OpenAI, Anthropic, etc.)
• Coût faible
• Infrastructure minimale
• Adapté aux chatbots d’information publique, manuels, informations produit, etc.

Nécessaire lorsque les documents ne peuvent pas quitter les locaux (santé, industrie réglementée, R&D).

Cela requiert :

• matériel local (GPU)
• modèle LLM local (Mistral-7B, Llama-3 8B…)
• index de recherche local
• base de connaissances locale

Le modèle :

• n’a pas besoin de connaissances universelles
• ne contacte aucun serveur externe
• peut fonctionner hors ligne
• n’a besoin que d’assez de capacité pour interpréter les documents de l’entreprise

Si une entreprise n’est pas dans l’aérospatial, le modèle n’a jamais besoin de connaître quoi que ce soit sur le système solaire. Sa valeur réside dans RAG, pas dans la connaissance encyclopédique.

Un bon système RAG dépend de deux composants délicats :

1. Les prompts utilisateurs — comment l’utilisateur formule la question
2. La connaissance écrite — comment l’organisation rédige et structure ses documents

Ces deux éléments doivent *correspondre*.

Chez amsafis, la base de connaissances est révisée manuellement avant l’indexation pour éviter :

• définitions ambiguës
• règles qui se chevauchent
• interprétations involontaires
• pièges lexicaux qui produisent des hallucinations

C’est l’équivalent d’un *prompt engineering côté données*.

Les Systèmes Experts sont la première branche de l’IA formalisée en tant que telle et demeurent irremplaçables dans les environnements critiques pour la sécurité.

Ils exécutent une logique explicite, sans inférence statistique ni raisonnement neuronal linguistique.

Ils peuvent gérer :

• des centaines de règles
• une logique en plusieurs étapes
• des exceptions
• des conditions de sécurité
• l’exécution de protocoles
• un raisonnement qui dépasserait la capacité humaine

Un clinicien, ingénieur ou opérateur peut soupçonner un chemin d’inférence spécifique. Un Système Expert peut être programmé pour fournir :

• confirmation
• contre-exemples
• explications traçables

Cela fournit une traçabilité qu’un RAG-LLM ne peut garantir.

Les Systèmes Experts peuvent :

• lire de grands jeux de données (milliers de lignes)
• appliquer des règles à chaque cas
• générer des drapeaux, alertes, catégories

Ces enregistrements ne sont pas des règles. Elles sont évaluées par les règles.

• Le ML produit des motifs quantitatifs → les SE peuvent les incorporer comme seuils ou nœuds décisionnels.
• Le RAG produit une connaissance narrative → les SE peuvent l’utiliser comme descriptions de domaine ou contraintes contextuelles.
• Les SE produisent une logique systématisée → le RAG peut la citer ; le ML peut servir à la tester.

Cela boucle la boucle entre les trois IA.

Amsafis a développé une couche de connaissance exécutable permettant de consulter des modèles experts de manière directe et opérationnelle.

Ce n’est ni un chatbot ni une application d’IA générative. C’est un service qui expose une connaissance formalisée afin qu’elle puisse être utilisée par :

• des personnes (usage manuel)
• des scripts et des intégrations
• des logiciels d’entreprise
• de futurs systèmes d’automatisation ou agents

L’objectif est de transformer la connaissance experte en un outil exécutable, traçable et réutilisable.

En plus de l’utilisation manuelle disponible depuis le site web, le service peut être testé en exécutant des commandes depuis des outils gratuits tels que :

• Git Bash
• Visual Studio Code (terminal intégré)

(D’autres consoles peuvent fonctionner, mais la syntaxe peut varier.)

Ces outils permettent d’envoyer des requêtes directes au moteur de connaissance.

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"diagnose\",\"payload\":{\"symptoms\":[\"Myopia\"]}}"

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"intersect\",\"payload\":{\"disease_a\":\"biotinidase_deficiency\",\"disease_b\":\"holocarboxylase_synthetase_deficiency\"}}"

curl -X POST https://diseases-non-interactive.amsafis.com/mcp/dispatch \
 -H "Content-Type: application/json" \
 -d "{\"task\":\"review\",\"payload\":{\"disease\":\"biotinidase_deficiency\"}}"

La requête suivante demande si une adresse IP est une donnée personnelle au sens du RGPD et si des obligations de compliance s'appliquent:

curl -s -X POST https://agent-gdpr.amsafis.com/mcp/dispatch \
  -H "Content-Type: application/json" \
  -d "{\"connector\": \"gdpr_check\", \"params\": {\"data\": \"ip_address\"}}"

La base de connaissances encode les règles de classification des données personnelles issues du CNIL Developer's Guide, Sheet 1, source faisant autorité pour l'identification des données personnelles en Europe.

Cinq connecteurs disponibles :

• gdpr_check — ce type de donnée est-il une donnée personnelle ? Le RGPD s'applique-t-il ?
• gdpr_consent — nécessite-t-il un consentement explicite ?
• gdpr_anonymous — est-il véritablement anonyme ?
• gdpr_pseudonym — est-il pseudonymisé et quelles en sont les implications ?
• gdpr_query — avancé : envoyer directement toute requête Prolog

Liste complète des connecteurs et schéma des paramètres:

curl https://agent-gdpr.amsafis.com/mcp/connectors

Cet environnement constitue un Knowledge Tool Provider : un composant réutilisable pouvant être intégré dans des architectures plus complexes sans perdre la transparence du modèle ni la gouvernance de la connaissance.

La section précédente montre comment un service de connaissance peut être accessible de manière programmatique à l’aide d’une simple requête curl basée sur le Model Context Protocol (MCP).

Il ne s’agit pas seulement d’un détail technique. Cela définit comment différents composants d’IA peuvent être connectés et exécutés comme des services interopérables.

Un Agent s’appuie sur cette capacité.

Plutôt que d’appeler un seul service, un Agent :

• interprète une requête,
• sélectionne les composants appropriés,
• et coordonne leur exécution au moyen d’interactions structurées telles que les appels MCP.

Dans ce contexte, le Model Context Protocol (MCP) fournit un moyen standardisé d’échanger des entrées et sorties structurées entre composants, permettant :

• une exécution reproductible,
• des interactions traçables,
• et une intégration entre systèmes hétérogènes.

Un Agent peut combiner :

• des systèmes experts (raisonnement basé sur des règles),
• des modèles d’apprentissage automatique (prédiction),
• et des LLM (interprétation et génération),

en utilisant MCP comme couche de communication entre eux.

Cela transforme des capacités isolées en un flux d’exécution cohérent, où chaque composant contribue au résultat final.

Par exemple:

• un LLM peut interpréter une description clinique,
• la mapper vers des concepts structurés,
• déclencher un service de connaissance via une requête MCP,
• et intégrer la réponse dans un résultat final.

Il ne s’agit pas d’un nouveau pilier de l’IA.

C’est une manière d’opérationnaliser l’intégration décrite dans les sections précédentes.

En pratique, chaque Agent est conçu pour un cas d’usage spécifique, avec différents niveaux de complexité :

• des pipelines simples avec une orchestration minimale,
• ou des processus en plusieurs étapes combinant raisonnement, prédiction et récupération de connaissances.

Cette approche permet la transition de :

• outils isolés

à

• systèmes de décision intégrés et exécutables.