PBOT

PBOT — Fiches techniques

Documentation produit et architecture
Architecture centrale · LLM Router

API Centrale

API de routage et d’orchestration conçue pour centraliser les appels IA de plusieurs applications. Elle choisit dynamiquement le backend d’exécution, gère le mode web intelligent, enrichit les réponses avec des sources et fournit un socle technique réutilisable pour l’ensemble de l’écosystème.

Rôle principal

Servir de couche d’abstraction entre les applications clientes et les moteurs LLM locaux ou distants, avec une logique unifiée de décision, de fallback et de traçabilité.

Valeur ajoutée

  • Routage GPU / CPU
  • Déclenchement automatique du RAG web
  • Retour enrichi avec sources, mode utilisé et backend
  • Point d’entrée unique pour plusieurs applications

Vision du projet

L’API Centrale a été pensée comme un cerveau transversal capable de desservir plusieurs interfaces : chatbot généraliste, applications métier orientées data, futurs outils internes ou prototypes SaaS.

Rôle
Hub IA
Backends
GPU / CPU
Mode web
Auto
Usage
Multi-apps

Cas d’usage

  • Assistant conversationnel généraliste avec accès web conditionnel.
  • Applications métiers nécessitant des réponses local-first, avec recherche web seulement si utile.
  • Centralisation de la logique de fallback GPU → CPU.
  • Exposition d’un point d’entrée stable pour plusieurs interfaces clientes Flask.
  • Base d’un futur écosystème de produits IA partageant la même gouvernance technique.

Fonctionnalités principales

Routage intelligent

  • Détection de disponibilité du backend GPU via LM Studio.
  • Fallback vers backend CPU si le GPU est indisponible.
  • Sélection dynamique du modèle GPU par défaut ou d’un modèle demandé explicitement.

Mode web intelligent

  • Trois modes supportés : off, on, auto.
  • Décision automatique basée sur la nature de la requête : actualité, information locale, prix, recherche explicite, signaux de fraîcheur.
  • Construction d’un contexte web injecté dans le prompt uniquement lorsque cela apporte de la valeur.

Réponse enrichie

  • Retour du texte final, du backend utilisé, du modèle, du temps de réponse, du mode web et des sources.
  • Nettoyage défensif des sorties LLM pour neutraliser certains artefacts de tool calling.

Architecture

Applications clientes ↓ API Centrale / Router ↓ ┌───────────────────────┬───────────────────────┬──────────────────────┐ │ │ │ │ LM Studio (GPU) Ollama (CPU) Web RAG / Scraping Observabilité
Pattern Backend for frontend / orchestrateur central
Responsabilité Décider, router, enrichir, sécuriser, unifier les réponses
Clients cibles PBOT GPT, application Excel/BI, futures apps internes
Découplage Les apps clientes n’ont pas besoin de connaître LM Studio, Ollama ou la logique RAG

Stack technique

Python Flask Requests LM Studio Ollama GPT-OSS:20B Gunicorn

Composants techniques

  • LM Studio pour l’inférence GPU via API compatible OpenAI.
  • Ollama comme backend CPU de secours.
  • Service web_rag pour construire le contexte web à partir de résultats externes.
  • Gunicorn + systemd pour l’exécution en service local, lié à localhost uniquement.

Flux d’exécution

  1. Réception de la requête chat avec messages, modèle, mode web et format éventuel.
  2. Évaluation de la disponibilité des backends.
  3. Résolution de use_web selon off / on / auto.
  4. Si web activé : construction d’un contexte externe et enrichissement du prompt.
  5. Appel GPU si disponible, sinon CPU selon les règles de fallback.
  6. Retour d’un objet standardisé contenant la réponse et les métadonnées d’exécution.

Contrats API et endpoints

GET /health Vérification rapide de disponibilité du service
GET /backend-status État détaillé des backends CPU/GPU et du modèle actif
GET /models Catalogue de modèles disponibles par backend
POST /chat Point d’entrée principal pour l’inférence LLM

Valeur renvoyée

  • answer
  • backend_used
  • model
  • web_mode
  • sources
  • duration_ms

Résilience et robustesse

  • Détection proactive d’indisponibilité GPU.
  • Fallback CPU sur requêtes non web.
  • Blocage volontaire du mode web si seul le CPU est disponible.
  • Gestion des timeouts distincts entre GPU et CPU.
  • Messages d’erreur homogènes et exploitables côté applications clientes.

Sécurité

  • Écoute restreinte à localhost.
  • Clé d’API obligatoire pour authentifier les clients.
  • Aucune exposition directe des backends GPU/CPU aux applications tierces.
  • Centralisation des appels sensibles dans une couche unique plus simple à durcir.

Observabilité et pilotage

  • Suivi du backend réellement utilisé.
  • Mesure du temps de réponse.
  • Affichage du mode web dans les interfaces clientes.
  • Base idéale pour futur logging analytique par application, utilisateur, modèle et coût.

Évolutions possibles

  • Cache applicatif pour résultats web et prompts récurrents.
  • Classement des sources et scoring de confiance.
  • Décision web encore plus fine via classification ou micro-modèle spécialisé.
  • Streaming temps réel des réponses.
  • Ajout de spécialisations par application via modules ou profils de prompt.
Fiche technique générée pour présentation projet / portfolio / soutenance.