healthai-vision

Service d'analyse nutritionnelle par photo de repas et moteur de conseil personnalisé.

• Image : ghcr.io/healthai-corpo/healthai-vision
• Port : 8001
• Swagger : http://localhost:8001/docs

Rôle

Identifie les aliments dans une photo de repas via YOLOv8, calcule les macronutriments en interrogeant la table aliment de PostgreSQL, et génère des conseils et astuces de rééquilibrage personnalisés en comparant les besoins théoriques de l'utilisateur (profil_sante PostgreSQL) avec sa consommation réelle du jour stockée dans MongoDB via des requêtes asynchrones adressées au conteneur partagé Ollama.

Stack IA & Données

Composant	Technologie
Détection d'objets	Ultralytics YOLOv8 (yolov8n.pt) isolé via ThreadPoolExecutor
Traitement d'image	Pillow + OpenCV (headless)
IA Générative (LLM)	Client HTTP Async (HTTPX) → Conteneur centralisé healthai-ollama
Persistance Relationnelle	SQLAlchemy async → utilisateur, profil_sante, aliment (PostgreSQL)
Persistance Document	Motor (Pilote Async MongoDB) → collection consumptions

Schéma flux de données & Architecture

Flux de données

Client (image + user_id) → POST /analyze → Inférence YOLOv8 isolée dans un ThreadPool (non-bloquant pour l'event loop, confiance > 0.5) → Mapping intelligent (Labels anglais / Contenants → table aliment PostgreSQL) → Extraction asynchrone du Profil Santé (Postgres) et des consommations journalières (MongoDB) → Requête textuelle au conteneur Ollama (Prompt combinant Objectifs + Données du repas actuel et du jour) → Génération de l'astuce de rééquilibrage nutritionnel qualitatif (JSON strict) → Sauvegarde du rapport dans MongoDB et retour de la charge utile enrichie

Structure

src/
├── api/             # Endpoints POST /analyze/meal et GET /health
├── core/            # Config (modèles HuggingFace, variables d'env, clients externes)
├── models/          # Modèles SQLAlchemy calqués sur l'Infra (aliment, utilisateur, profilsante)
├── services/        # Logique métier (ai_service (YOLO), nutrition_service, recommandation_service)
├── database.py      # Connexion PostgreSQL asynchrone (moteur avec pool_pre_ping)
├── database_mongo.py # Connexion MongoDB asynchrone (MotorClient)
└── main.py          # Serveur (port 8001)

Points d'attention

Cache du modèle

Le fichier .pt est stocké dans le conteneur. Utiliser un volume pour éviter le re-téléchargement au reboot :

volumes:
  - ./.hf_cache:/app/.hf_cache

::: L'inférence de vision par ordinateur est déportée dans un exécuteur de threads dédié pour garantir la fluidité de la boucle d'événements asynchrone lors des requêtes d'I/O simultanées (Postgres, Mongo, Ollama).

Dépendances système

Le Dockerfile utilise une image Linux Slim optimisée via le gestionnaire uv. Il inclut obligatoirement les paquets système libgl1 et libglib2.0-0 indispensables au bon fonctionnement d'OpenCV headless.

Sérialisation & Compatibilité Infra

Les types Numeric/Decimal de PostgreSQL sont convertis en float automatiquement pour assurer la compatibilité avec la sérialisation JSON standard. L'ensemble des modèles de données utilise le nommage strict de l'infrastructure globale (id_utilisateur, id_aliment, etc.).

Lancement isolé

cd healthai-vision
uv sync
docker compose up --build healthai-vision

État d'implémentation

• [x] Chargement asynchrone de YOLOv8 au démarrage (Singleton).
• [x] Endpoint POST /analyze — Détection d'objets non-bloquante via pool de threads (Seuil de confiance > 0.5).
• [x] Mapping logique des labels anglais YOLO et des contenants (bowl, bottle) → table PostgreSQL aliment.
• [x] Connexions et requêtes asynchrones PostgreSQL + MongoDB (Calcul des macronutriments et cumuls journaliers).
• [ ] Externalisation et intégration asynchrone du service partagé healthai-ollama pour la génération de conseils qualitatifs individualisés.