Aller au contenu principal

Optimisations pour les Services IA

Ce document décrit les optimisations mises en place pour gérer la charge des services IA et les recommandations pour la scalabilité.

🛡️ Protections Actuelles​

1. Rate Limiting​

Tous les endpoints IA sont protégés par du rate limiting pour éviter la surcharge :

  • POST /api/search/ai/process : 20 requêtes/minute
  • POST /api/search/ai/filters : 20 requêtes/minute
  • POST /api/search/ai/answer : 15 requêtes/minute
  • POST /api/search/ai/create-view : 10 requêtes/minute
  • POST /api/search/ai/generate-action : 10 requêtes/minute

Implémentation : Utilise RateLimitingGuard avec Redis pour partager les compteurs entre instances.

2. Caching des Réponses IA​

Les réponses OpenAI sont mises en cache pour réduire les appels API :

  • Intent classification (processQuery) : Cache de 5 minutes
  • Filter generation (generateFilters) : Cache de 10 minutes (plus stable)
  • Question answering (answerQuestion) : Cache de 5 minutes
  • Action generation (generateAction) : Cache de 5 minutes

Clé de cache : Hash SHA256 de userId:query:type pour éviter les collisions et limiter la taille des clés.

Bénéfices :

  • Réduction des coûts OpenAI (moins d'appels API)
  • Amélioration de la latence (réponses instantanées depuis le cache)
  • Réduction de la charge serveur

3. Architecture Actuelle​

Frontend → Backend NestJS → OpenAI API
         ↓
      Redis Cache
         ↓
    Rate Limiting

📊 Impact sur les Performances​

Scénario : 100 utilisateurs simultanés​

Sans optimisations :

  • 100 appels OpenAI simultanés = ~10-30 secondes de latence par requête
  • Coût : ~$0.01-0.03 par requête
  • Risque de timeout et surcharge serveur

Avec optimisations :

  • Rate limiting : Max 20 requêtes/minute par utilisateur = 2000 requêtes/minute max
  • Cache hit rate estimé : 30-50% (requêtes similaires)
  • Réduction des appels OpenAI : ~40-60%
  • Latence moyenne : <2 secondes (cache) vs 10-30 secondes (OpenAI)

🚀 Optimisations Futures (Recommandées)​

1. Queue System (Priorité Haute)​

Pour gérer les pics de charge, implémenter une queue avec Bull/BullMQ :

// Exemple d'architecture avec queue
Frontend → Backend → Queue (Redis) → Worker → OpenAI API
                    ↓
                 Status Updates (WebSocket)

Avantages :

  • Découplage des requêtes lourdes
  • Traitement asynchrone
  • Meilleure scalabilité horizontale
  • Gestion des retries automatiques

Implémentation suggérée :

  • Utiliser @nestjs/bull pour l'intégration
  • Worker séparé pour les appels OpenAI
  • WebSocket pour les mises à jour de statut en temps réel

2. Batch Processing​

Grouper les requêtes similaires pour réduire les appels OpenAI :

// Au lieu de 10 appels séparés
// Grouper les requêtes similaires en un seul appel batch
const batch = [
  { query: "sessions mariage", userId: "user1" },
  { query: "sessions mariage", userId: "user2" },
  // ...
];

3. Modèle Local (Optionnel)​

Pour réduire les coûts et la latence, considérer un modèle local (Ollama, LM Studio) :

  • Avantages : Pas de coût par requête, latence réduite
  • Inconvénients : Qualité potentiellement inférieure, ressources serveur nécessaires

4. Timeout et Retry Logic​

Ajouter des timeouts et retry logic pour les appels OpenAI :

const response = await openai.chat.completions.create({
  // ... config
  timeout: 30000, // 30 secondes max
  maxRetries: 2,
});

5. Monitoring et Alerting​

Surveiller :

  • Taux de cache hit/miss
  • Nombre de requêtes rate-limited
  • Latence moyenne des appels OpenAI
  • Coûts OpenAI par utilisateur

📈 Recommandations par Taille d'Utilisateur​

< 100 utilisateurs actifs​

✅ Configuration actuelle suffisante

  • Rate limiting + cache
  • Monitoring basique

100-1000 utilisateurs actifs​

⚠️ Considérer queue system

  • Implémenter Bull/BullMQ
  • Worker séparé pour OpenAI
  • Monitoring avancé

> 1000 utilisateurs actifs​

🚀 Architecture distribuée recommandée

  • Queue system obligatoire
  • Multiple workers
  • Load balancing
  • CDN pour le cache
  • Modèle local optionnel

🔧 Configuration Recommandée​

Variables d'Environnement​

# Rate limiting
AI_RATE_LIMIT_PROCESS=20      # requêtes/minute pour processQuery
AI_RATE_LIMIT_FILTERS=20      # requêtes/minute pour generateFilters
AI_RATE_LIMIT_ANSWER=15       # requêtes/minute pour answerQuestion
AI_RATE_LIMIT_ACTION=10       # requêtes/minute pour generateAction

# Cache TTL (en secondes)
AI_CACHE_TTL_PROCESS=300      # 5 minutes
AI_CACHE_TTL_FILTERS=600      # 10 minutes
AI_CACHE_TTL_ANSWER=300       # 5 minutes
AI_CACHE_TTL_ACTION=300       # 5 minutes

# OpenAI
OPENAI_TIMEOUT=30000          # 30 secondes
OPENAI_MAX_RETRIES=2

📝 Notes Importantes​

  1. Coûts OpenAI : Surveiller les coûts mensuels. Avec le cache, on peut réduire de 40-60% les appels.

  2. Redis : Essentiel pour le rate limiting et le cache. S'assurer que Redis est bien configuré et monitoré.

  3. Graceful Degradation : Si Redis est indisponible, le rate limiting est désactivé mais l'application continue de fonctionner.

  4. User Experience : Le rate limiting peut frustrer les utilisateurs. Considérer des messages clairs et des limites raisonnables.

🔍 Monitoring​

Métriques à surveiller :

  • Cache hit rate : cache:hits / (cache:hits + cache:misses)
  • Rate limit hits : Nombre de requêtes bloquées par minute
  • OpenAI latency : P50, P95, P99
  • OpenAI errors : Taux d'erreur par type
  • Coûts : Coût par utilisateur, coût par type de requête