Projet de Master 2 SISE – Data Science
Université Lumière Lyon 2 | Année 2025–2026
À propos • Architecture • Fonctionnalités • Technologies • Installation
- À propos
- Contexte & Problématiques
- Architecture du système
- Fonctionnalités principales
- Technologies utilisées
- Composants détaillés
- Dashboard Streamlit
- Installation locale
- Structure du projet
- Métriques & Performances
- Limites & Avertissements
- Équipe
- Licence
Emergency_Manager est un système intelligent d'aide à la décision pour les urgences hospitalières, développé dans le cadre du projet académique du Master SISE. Le système combine plusieurs technologies d'IA avancées pour répondre aux défis quotidiens des services d'urgences.
Créer un assistant personnel IA qui permet aux professionnels de santé (infirmiers et médecins) de :
- 🔍 Accéder instantanément aux protocoles médicaux pertinents (RAG)
- 🤖 Automatiser certaines tâches de gestion des flux patients (Agent)
- 🛡️ Sécuriser les interactions avec des guardrails anti-injection
- 💬 Interagir naturellement via un chatbot en langage naturel
- 📊 Monitorer l'impact écologique et financier (GreenOps/FinOps)
Les services d'urgences font face à trois défis majeurs :
« Nous n'arrivons pas à trier efficacement les patients selon leur besoin »
- Flux imprévisibles de patients
- Niveaux de gravité hétérogènes (ROUGE, JAUNE, VERT, GRIS)
- Priorisation complexe en situation de rush
« Dans le rush, on n'a pas le temps de chercher dans la littérature pour répondre à nos doutes... »
- Protocoles dispersés et difficiles d'accès
- Pas de temps pour consulter les référentiels
- Besoin de réponses contextualisées et rapides
« Et si seulement, on pouvait avoir une manière automatique d'organiser les patients aux urgences... »
- Gestion manuelle des salles d'attente
- Allocation inefficace du personnel
- Transports inter-services non optimisés
Le système repose sur une architecture modulaire en 5 couches :
flowchart TB
subgraph UI["🖥️ Interface Utilisateur"]
A[Dashboard Streamlit]
B[Onglet Principal]
C[Onglet Chatbot]
D[Onglet Métriques]
end
subgraph Backend["⚙️ Backend Core"]
E[EmergencyController]
F[Patient/Staff/Transport Services]
G[EmergencyState]
end
subgraph IA["🤖 Couche Intelligence Artificielle"]
H[EmergencyAgent<br/>Mistral AI]
I[RAG Engine<br/>FAISS + Embeddings]
J[ChatbotEngine<br/>+ Intent Parser]
end
subgraph Security["🛡️ Sécurité"]
K[Guardrails Multi-Couches<br/>Pattern + ML + Logic]
L[InjectionDetector]
end
subgraph Monitoring["📊 Observabilité"]
M[MetricsTracker<br/>EcoLogits]
N[RequestMetrics]
end
UI --> Backend
Backend --> IA
IA --> Security
IA --> Monitoring
H --> I
J --> I
I --> K
Backend --> G
- Interface utilisateur (Streamlit) → Actions utilisateur
- Controller → Orchestration des services (Patient, Staff, Transport)
- Agent/Chatbot → Analyse intelligente via RAG + Mistral
- Guardrails → Validation de sécurité (pré/post-LLM)
- Monitoring → Tracking GreenOps/FinOps
- Système d'état complet : Suivi en temps réel de tous les patients, personnel et salles
- Simulation temporelle : Avancement du temps avec gestion automatique des événements
- Priorisation automatique : Respect des règles de gravité (ROUGE > JAUNE > VERT > GRIS)
- Gestion des transports : Allocation intelligente du personnel pour les déplacements
- Orchestration automatique : L'agent analyse l'état et prend des décisions
- 10 outils MCP : Actions atomiques sur le système (ajouter patient, transporter, etc.)
- RAG intégré : Enrichissement des décisions avec protocoles médicaux
- Explicabilité : Chaque décision est tracée et justifiée
- Langage naturel : Commandes en français (ex: "Ajoute 3 patients rouges")
- Intent parsing : Analyse des intentions avec regex + Mistral fallback
- Exécution d'actions : Le chatbot peut manipuler le système
- Contexte RAG : Réponses enrichies avec protocoles médicaux
- 3 couches de guardrails :
- Détection par patterns (40+ regex)
- Classification ML (modèle entraîné sur prompt injections)
- Validation logique (pertinence médicale)
- Seuil de confiance : Rejet si similarité RAG < 0.7
- Audit trail : Tous les appels sont tracés
- Métriques environnementales (via EcoLogits) :
- Émissions CO2 (kg)
- Consommation énergétique (kWh)
- Équivalents parlants (recherches Google, ampoules)
- Métriques financières :
- Coût par requête ($)
- Coût total session
- Répartition par composant (Agent, Chatbot, RAG)
- Métriques techniques :
- Latence moyenne (ms)
- Nombre de tokens
- Nombre d'appels API
| Technologie | Usage | Justification |
|---|---|---|
| Python 3.11+ | Langage principal | Écosystème ML/IA riche |
| Streamlit | Interface utilisateur | Prototypage rapide, interactif |
| Pydantic | Validation données | Type safety, modèles structurés |
| Composant | Technologie | Justification |
|---|---|---|
| LLM | Mistral AI (Small/Medium) | Français natif, bon rapport qualité/prix |
| Embeddings | paraphrase-multilingual-MiniLM-L12-v2 |
Multilingue FR/EN, léger (384 dims) |
| Vector DB | FAISS (IndexFlatIP) | Recherche exhaustive rapide |
| LLM Gateway | LiteLLM | Standardisation des appels API |
| Composant | Modèle/Méthode | Performance |
|---|---|---|
| Guardrail ML | Histogram Gradient Boosting | F1-Score: 0.94 |
| Datasets | deepset/prompt-injections + MultiJail | ~25k exemples |
| Features | TF-IDF (5000 features) | Détection pattern + sémantique |
| Outil | Usage | Détails |
|---|---|---|
| EcoLogits | Impact environnemental | CO2, énergie (mix FR) |
| Custom Tracker | Métriques FinOps | Coûts Mistral AI |
| RequestMetrics | Historique requêtes | Top 100 dernières |
Architecture : rag/engine.py - HospitalRAGEngine
| Source | Contenu | Format | Taille |
|---|---|---|---|
| protocoles.json | Protocoles médicaux par pathologie | JSON | ~100 protocoles |
| regles.json | Règles de gestion hospitalière | JSON | ~50 règles |
# Workflow simplifié
1. Query utilisateur → Guardrails (sécurité)
2. Embedding de la query (MiniLM-L12)
3. Recherche FAISS (similarité cosinus)
4. Filtrage par seuil de confiance (> 0.7)
5. Récupération des règles applicables
6. Validation post-retrieval (guardrails)
7. Réponse enrichie (protocole + règles)- Pré-calcul d'embeddings : 15 symptômes fréquents en cache
- Index rapide :
protocoles_fast.indexpour mode simulation - Normalisation L2 : Garantit similarité cosinus
- Dual mode : "simulation" (rapide) vs "chatbot" (ML actif)
| Métrique | Valeur | Cible |
|---|---|---|
| Latence recherche FAISS | 0.3ms | < 1ms |
| Latence embedding | 95ms | < 100ms |
| Seuil de confiance | 0.7 | Équilibre précision/rappel |
| Taille index | 12.5 MB | Optimisé |
Architecture : mcp/agent.py - EmergencyAgent
L'agent fonctionne en cycles autonomes :
def cycle_orchestration(self) -> List[str]:
"""Cycle de décision autonome de l'agent."""
# 1. Analyse de l'état via RAG
situation = self._build_situation_prompt()
rag_response = self.rag_engine.query(situation)
# 2. Décision LLM enrichie
decision = self._call_llm(situation, rag_response)
# 3. Exécution via MCP tools
actions = self._execute_actions(decision)
return actions| Outil | Description | Paramètres |
|---|---|---|
ajouter_patient |
Admission nouveau patient | id, prenom, nom, gravite, symptomes, age |
assigner_salle_attente |
Affectation salle | patient_id, salle_id |
demarrer_transport_consultation |
Transport vers consultation | patient_id, staff_id |
finaliser_transport_consultation |
Fin transport | patient_id |
terminer_consultation |
Fin consultation + orientation | patient_id, unite_cible |
demarrer_transport_unite |
Transport vers unité cible | patient_id, staff_id |
finaliser_transport_unite |
Fin transport unité | patient_id |
sortir_patient |
Sortie (retour domicile) | patient_id |
assigner_surveillance |
Surveillance salle | staff_id, salle_id |
verifier_et_gerer_surveillance |
Gestion auto surveillance | - |
L'agent respecte strictement les priorités médicales :
- ROUGE (urgent vital) → Priorité absolue
- JAUNE (urgent non vital) → Haute priorité
- VERT attente > 360min → Passe avant JAUNE (règle spéciale)
- VERT attente < 360min → Priorité normale
- GRIS → Retour domicile différé
Architecture : rag/guardrails.py - RAGGuardrail + InjectionDetector
Input Query
↓
[Couche 1] Pattern Detection (Regex)
↓ (si suspect)
[Couche 2] ML Classification (HGB)
↓ (si safe)
[Couche 3] RAG Retrieval
↓
[Couche 4] Logic Validation
↓
Output (safe/blocked)
40+ patterns regex détectés :
# Exemples
- Injection classique: "ignore previous instructions"
- Jailbreak: "DAN mode", "Developer override"
- Template injection: {{...}}, {%...%}
- Command injection: ;ls, $(command), `backticks`
- SQL injection: DROP TABLE, DELETE FROMMots-clés sensibles bloqués :
- Credentials :
mot de passe,api key,token - Système :
database,config,secrets - Opérations :
dump,export,télécharge
Modèle : Histogram Gradient Boosting Classifier
Dataset d'entraînement :
deepset/prompt-injections(8 000 malveillants)DAMO-NLP-SG/MultiJail(12 000 multilingues)- Requêtes médicales sûres (3 200 générées)
Pipeline :
1. TF-IDF Vectorization (5000 features, n-grams 1-3)
2. Histogram Gradient Boosting (max_depth=10, learning_rate=0.1)
3. Seuil de décision : 0.5 (ajustable)Performance :
- Accuracy : 94.2%
- F1-Score : 0.94 (macro)
- Precision (malveillant) : 92.8%
- Recall (malveillant) : 95.3%
- Latence : < 50ms (CPU)
Après récupération RAG, validation de :
- Pertinence sémantique : Score FAISS > seuil
- Cohérence médicale : Gravité valide (ROUGE/JAUNE/VERT/GRIS)
- Temps d'attente : Vérification règles métier
- Disponibilité ressources : Personnel, salles disponibles
Architecture : chatbot/chatbot_engine.py - ChatbotEngine
graph LR
A[User Input] --> B[Guardrails]
B --> C[Intent Parser]
C --> D{Intent Type}
D -->|ADD_PATIENT| E[Action Executor]
D -->|ASK_PROTOCOL| F[RAG Engine]
D -->|GET_STATUS| G[State Query]
E --> H[Controller]
F --> I[Response Builder]
G --> I
H --> I
I --> J[Formatted Response]
Méthode : Regex-first avec fallback Mistral
Patterns supportés :
# Ajout de patients
"ajoute Jean Dupont gravité rouge"
"ajoute 5 patients jaunes avec fièvre"
"ajoute Martin rouge pour douleur thoracique"
# Transports
"transporte P001 en consultation"
"déplace patient P002 vers Unité A"
# Questions protocoles
"quel protocole pour douleur thoracique ?"
"que faire pour un AVC suspect ?"
# État système
"quel est l'état du système ?"
"liste les patients en attente"Exécute les actions via le EmergencyController :
class ActionExecutor:
def execute(self, action_plan) -> List[Dict]:
for action in action_plan.actions:
tool_name = action["tool"]
params = action["params"]
result = self._execute_single(tool_name, params)
return resultsGénère des réponses structurées :
@dataclass
class ChatbotResponse:
message: str
guardrail_status: str # "allowed" | "blocked"
rag_context: Optional[Dict]
actions_executed: Optional[List]
latency_ms: float
intent_type: strArchitecture : monitoring/monitoring.py - MetricsTracker
# Calcul automatique par EcoLogits
response = litellm.completion(model="mistral/mistral-small-latest", ...)
# Extraction
energy_kwh = response.impacts.energy.value.min
co2_kg = response.impacts.gwp.value.min # Mix électrique FR (55g CO2/kWh)Prix Mistral AI ($ / 1M tokens) :
| Modèle | Input | Output |
|---|---|---|
| mistral-small-latest | 0.2 | 0.6 |
| mistral-large-latest | 0.5 | 1.5 |
| ministral-3b-2512 | 0.1 | 0.1 |
| ministral-8b-latest | 0.1 | 0.1 |
cost = (input_tokens / 1_000_000) * input_price + \
(output_tokens / 1_000_000) * output_priceLe système track 3 sources distinctes :
| Source | Usage | Modèle par défaut |
|---|---|---|
| Agent | Décisions autonomes | mistral-small-latest |
| Chatbot | Interactions utilisateur | mistral-small-latest |
| RAG | (Pas de LLM direct) | - |
Affichage en temps réel :
- Coût total ($ cumulé)
- Énergie (kWh cumulé)
- CO2 (kg cumulé)
- Équivalents :
- Recherches Google (1 recherche ≈ 0.0003 kWh)
- Minutes d'ampoule 60W
- Latence moyenne (ms)
- Historique : Top 100 dernières requêtes
Point d'entrée : emergency_dashboard_premium.py
L'application est organisée en 3 onglets principaux :
Hero Zone (vue d'ensemble)
- Nombre de patients critiques en attente
- Nombre de patients sous gestion IA
- Statut global (SAFE / TENSION / CRITICAL)
- Temps de simulation
Zone critique (si alertes)
- Liste des alertes système
- Patients ROUGE en attente > seuil
- Situations d'urgence
KPIs secondaires
- Taux d'occupation salles
- Temps d'attente moyen par gravité
- Disponibilité personnel
Sections détaillées
- Personnel : État de chaque membre (disponible, occupé, en transport)
- Salles d'attente : Capacité, occupation, surveillance
- File d'attente : Liste des patients par priorité
- Timeline opérationnelle : Événements récents
Contrôles
▶️ Play / ⏸️ Pause simulation- ⚙️ Vitesse agent (0.5x → 3x)
- ➕ Ajout patients manuel (ROUGE/JAUNE/VERT/GRIS)
- 🔄 Reset système
Interface conversationnelle
- Historique de chat (messages utilisateur + assistant)
- Input texte pour commandes naturelles
- Affichage du statut guardrail (✅ autorisé /
⚠️ bloqué) - Contexte RAG affiché (protocoles utilisés)
- Actions exécutées listées
- Métriques de la requête (latence, coût, CO2)
Exemples de commandes
"Ajoute 3 patients rouges avec détresse respiratoire"
"Quel est le protocole pour douleur thoracique ?"
"Transporte le patient P001 en consultation"
"Quel est l'état du système ?"
"Explique ta dernière décision"
Vue d'ensemble
- Coût total session ($)
- Énergie totale (kWh)
- CO2 total (kg)
- Latence moyenne (ms)
- Nombre total de requêtes
Équivalents parlants
- 🔍 Recherches Google équivalentes
- 💡 Minutes d'ampoule 60W
- 🌳 Arbres à planter pour compenser
Répartition par source
- Agent : X% du coût, Y% de l'énergie
- Chatbot : X% du coût, Y% de l'énergie
- RAG : (pas de LLM direct)
Historique graphique
- Top 10 dernières requêtes
- Évolution du coût dans le temps
- Distribution de la latence
Le dashboard utilise un design futuriste avec :
- Dégradés de couleurs (bleu/violet)
- Animations CSS (pulse, fade-in)
- Typographie moderne (SF Pro Display)
- Cards avec glassmorphism
- KPIs visuellement distincts
- Statuts colorés (ROUGE/JAUNE/VERT/GRIS)
# 1. Cloner le repository
git clone https://github.com/votre-username/emergency-manager.git
cd emergency-manager
# 2. Créer l'environnement virtuel
python -m venv .venv
source .venv/bin/activate # Linux/Mac
# .venv\Scripts\activate # Windows
# 3. Installer les dépendances
pip install -r requirements.txt
# 4. Configurer les variables d'environnement
cp .env.example .env
# Éditer .env et ajouter votre MISTRAL_API_KEYFichier .env :
# API Keys
MISTRAL_API_KEY=your_mistral_api_key_here
# Modèles (optionnel, valeurs par défaut)
LLM_MODEL=mistral-small-latest
EMBEDDING_MODEL=paraphrase-multilingual-MiniLM-L12-v2
# Monitoring (optionnel)
ENABLE_ECOLOGITS=true# Construire l'index vectoriel FAISS à partir des protocoles
python rag/LLM/build_index.pyCe script va :
- Charger
data_regle/protocoles.json - Générer les embeddings avec MiniLM-L12
- Créer l'index FAISS
- Sauvegarder
data_regle/protocoles.index
# Télécharger les datasets et entraîner le modèle
python rag/LLM/train_guardrails.pyCe script va :
- Télécharger
deepset/prompt-injectionsetMultiJail - Générer des exemples médicaux sûrs
- Entraîner le classifieur HGB
- Sauvegarder
storage/guardrail.pkl
# Lancer le dashboard Streamlit
streamlit run emergency_dashboard_premium.pyL'application sera accessible à : http://localhost:8501
# Lancer les tests de vérification
python test_integration.pyLes tests vérifient :
- ✅ Imports Python
- ✅ Structure dossiers
- ✅ Fichiers de données
- ✅ Variables d'environnement
- ✅ Moteur RAG
- ✅ Guardrails
- ✅ Agent
- ✅ Intégration complète
emergency-manager/
│
├── 📄 README.md # Ce fichier
├── 📄 requirements.txt # Dépendances Python
├── 📄 .env.example # Template configuration
├── 📄 .gitignore # Fichiers à ignorer
│
├── 📄 emergency_dashboard_premium.py # 🎯 POINT D'ENTRÉE - Dashboard Streamlit
├── 📄 premium_styles.py # Styles CSS du dashboard
├── 📄 dashboard_components.py # Composants UI réutilisables
├── 📄 chatbot_component.py # Composant chatbot
├── 📄 test_integration.py # Tests d'intégration
│
├── 📂 rag/ # RAG Engine
│ ├── engine.py # HospitalRAGEngine (moteur principal)
│ ├── models.py # Modèles Pydantic (RAGResponse, Protocol, Rule)
│ ├── guardrails.py # Guardrails multi-couches
│ └── LLM/
│ ├── build_index.py # Construction index FAISS
│ ├── train_guardrails.py # Entraînement guardrail ML
│ └── compare_models.py # Benchmark modèles ML
│
├── 📂 mcp/ # Model Context Protocol
│ ├── state.py # Modèles d'état (EmergencyState, Patient, Staff)
│ ├── agent.py # EmergencyAgent autonome
│ ├── controllers/
│ │ └── emergency_controller.py # Contrôleur principal
│ └── services/
│ ├── patient_service.py # Service gestion patients
│ ├── staff_service.py # Service gestion personnel
│ └── transport_service.py # Service gestion transports
│
├── 📂 chatbot/ # Chatbot médical
│ ├── chatbot_engine.py # ChatbotEngine (orchestrateur)
│ ├── intent_parser.py # Parsing intentions NLP
│ ├── action_executor.py # Exécution actions MCP
│ └── response_builder.py # Construction réponses
│
├── 📂 monitoring/ # Monitoring GreenOps/FinOps
│ ├── monitoring.py # MetricsTracker
│ └── rag_augmented.py # Wrapper LiteLLM + EcoLogits
│
├── 📂 data_regle/ # Base de connaissances
│ ├── protocoles.json # ~100 protocoles médicaux
│ ├── regles.json # ~50 règles hospitalières
│ ├── protocoles.index # Index FAISS standard
│ └── protocoles_fast.index # Index FAISS optimisé (simulation)
│
├── 📂 storage/ # Stockage persistant
│ ├── guardrail.pkl # Modèle guardrail ML entraîné
│ └── logs/ # Logs système (si activés)
│
└── 📂 docs/ # Documentation
├── img/ # Logo et captures
└── notice_guardrail.md # Notice technique guardrails
Sur un ensemble de test de ~2,400 exemples :
| Métrique | Valeur | Objectif |
|---|---|---|
| Accuracy | 94.2% | > 90% ✅ |
| F1-Score (macro) | 0.94 | > 0.90 ✅ |
| Precision (malveillant) | 92.8% | > 90% ✅ |
| Recall (malveillant) | 95.3% | > 90% ✅ |
| FPR (faux positifs) | 3.2% | < 5% ✅ |
| FNR (faux négatifs) | 5.1% | < 10% ✅ |
| Latence inférence | < 50ms | < 100ms ✅ |
| Composant | Métrique | Valeur | Cible |
|---|---|---|---|
| Embedding | Latence | 95ms | < 100ms ✅ |
| FAISS Search | Latence | 0.3ms | < 1ms ✅ |
| Cache | Hit rate | ~40% | Optimiser 🔄 |
| Index | Taille | 12.5 MB | Compact ✅ |
| Seuil confiance | Valeur | 0.7 | Équilibré ✅ |
| Métrique | Valeur | Cible |
|---|---|---|
| Latence LLM | ~420ms | < 500ms ✅ |
| Tokens/requête | ~850 | < 1000 ✅ |
| Coût/requête | ~0.0012$ | Minimiser 🔄 |
| Décisions/min | ~3-5 | Mode auto ✅ |
Basé sur mistral-small-latest avec mix électrique France (55g CO2/kWh) :
| Métrique | Valeur | Équivalent |
|---|---|---|
| CO2 émis | ~0.28g | ~0.05 recherches Google |
| Énergie | ~0.005 kWh | ~5 min ampoule 60W |
| Coût | ~0.12$ | - |
💡 Sobriété : Le projet privilégie mistral-small-latest (léger) plutôt que les gros modèles.
Ce projet est un prototype pédagogique développé dans le cadre du Master SISE :
- ❌ Non validé cliniquement : Aucune validation médicale
- ❌ Non certifié : Pas de certification dispositif médical
- ❌ Usage éducatif uniquement : Ne pas utiliser en production réelle
- ❌ Pas de données patients réelles : Système isolé de tout SIH
- Protocoles simplifiés : Version allégée des référentiels SFMU
- Patients synthétiques : Génération aléatoire pour simulation
- Pas de connexion SIH : Aucune intégration hospitalière
- Scope limité : Focus sur l'admission et le triage
- Hallucinations possibles : Le LLM peut générer des informations incorrectes
- Biais de données : Dépend de la qualité du dataset d'entraînement
- Contexte limité : Fenêtre LLM ~8k tokens (Mistral Small)
- Langues : Optimisé pour le français uniquement
- Guardrails non exhaustifs : Aucun système n'est 100% sûr
- Pas de validation médicale : Les décisions doivent être supervisées
- Environnement contrôlé : Déploiement en environnement sécurisé uniquement
- Supervision humaine obligatoire : Toute décision doit être validée par un professionnel
Ce système est un outil d'aide à la décision et NON un système de décision autonome. Toute décision médicale doit être prise par des professionnels de santé qualifiés. Les auteurs déclinent toute responsabilité en cas d'usage inapproprié ou de décision médicale basée uniquement sur les sorties de ce système.
Projet réalisé par le Groupe 3 dans le cadre du Master 2 SISE - Data Science
Université Lumière Lyon 2 | Année universitaire 2024-2025
Membres de l'équipe :
- BUONO Romain
- CHENIOUR Yassine
- DENA Nico
- GORDIENT-PIQUET Miléna
- MBOUP Modou
Encadrement :
- Professeurs : Clovis VARANGOT-REILLE - Ricco RAKOTOMALALA
- Université : Lumière Lyon 2
- Formation : Master 2 SISE - Data Science
Ce projet est développé à des fins exclusivement académiques et pédagogiques.
- ✅ Usage éducatif : Autorisé pour l'apprentissage et la recherche
- ✅ Usage académique : Autorisé dans un cadre universitaire
- ❌ Usage commercial : Strictement interdit
- ❌ Usage médical en production : Strictement interdit
- ❌ Utilisation de données patients réelles : Strictement interdit
- Code source : Propriété des auteurs, licence académique
- Protocoles médicaux : Inspirés des référentiels SFMU (Société Française de Médecine d'Urgence)
- Données : Synthétiques, générées pour la simulation
- Modèles IA : Utilisation des APIs Mistral AI (licence commerciale)
Si vous utilisez ce projet dans un contexte académique, merci de citer :
Emergency_Manager - Système agentique IA pour les urgences hospitalières
Groupe 3, Master 2 SISE, Université Lyon 2, 2024-2025
- SFMU - Société Française de Médecine d'Urgence
- IOA - Infirmier d'Orientation et d'Accueil (Guidelines)
- Échelle de triage : ROUGE / JAUNE / VERT / GRIS
- Mistral AI Documentation
- Streamlit Documentation
- FAISS Documentation
- Sentence Transformers
- LiteLLM Documentation
- EcoLogits
- Pydantic
- deepset/prompt-injections - Détection d'injections
- DAMO-NLP-SG/MultiJail - Jailbreak multilingue
- RAG: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- FAISS: Billion-scale similarity search with GPUs
- Prompt Injection: Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection