33800 Docs

← Retour

Resultats Test — Ulias-Org v0.8.0

Date : 13/02/2026 Duree : ~3h Plan : propositions/13-02-2026-14-00-plan-test-ulias-org.md

Resume executif

Le core flow fonctionne (message → routing → agent → tools → result → traduction FR) mais est severement limite par la performance LLM (Ollama qwen3:8b sur RTX 3090). Chaque appel LLM prend 30-60s et Ollama deadlock regulierement sous charge, bloquant tout le systeme.

Corrections appliquees pendant les tests

Fix 1: PostgREST UPDATE sans WHERE clause (CRITIQUE)

Fix 2: Nettoyage 142 objectives zombies

Fix 3: Scheduler desactive temporairement

Phase 1 : Diagnostic — DONE

Problem Cause Fix
142 objectives en "pending" dbUpdate sans WHERE + LLM timeout + scheduler flood Fix code + nettoyage DB
PostgREST UPDATE sans WHERE (code 21000) connectors-api ignore query params pour non-GET Inline params dans path
Ollama deadlock Jobs accumules, VRAM saturee Restart Ollama
Scheduler flood 3+ LLM calls/5min sans throttling Desactive temporairement

Phase 2 : Endpoints REST — 6 PASS / 3 FAIL

API Key : ck_live_nu6kdBCw9uF6lLevRHMArCxaSpskioDi1fh2uSSK-fPE_ghB (cle connectors-api)

Test Endpoint Resultat Note
2.1 GET /health PASS v0.8.0, healthy
2.2 GET /api/status PASS 31 agents, 8 teams
2.3 GET /api/teams PASS 8 teams
2.4 GET /api/agents PASS 31 agents
2.5 GET /api/capabilities PASS Reponse complete
2.6 GET /api/objectives PASS 50+ objectives
2.7 GET /api/objectives/:id PASS Detail complet
2.8 GET /api/objectives/active PASS Filtre ok
2.9 GET /api/decisions PASS Vide (normal)
2.10 GET /api/profile PASS Profil vide
2.11 PUT /api/profile FAIL Colonne preferences inexistante dans ceo_profile
2.12 GET /api/suggestions PASS Vide (profil vide)
2.13 GET /api/scheduler/jobs PASS 3 jobs
2.14 GET /api/feedback/:agent PASS Stats vides
2.15 POST /api/feedback FAIL user_id = "cklive" (tronque, pas UUID valide)
2.16 GET /api/agents/:name FAIL 404 - endpoint non implemente
2.17 PATCH /api/agents/:name/prompt NON TESTE Endpoint probablement absent
2.18 DELETE /api/agents/:name/prompt NON TESTE Endpoint probablement absent

Bugs identifies Phase 2

  1. Profile PUT (2.11) : Table ceo_profile Supabase n'a pas de colonne preferences. Le PUT tente d'ecrire un champ inexistant.
  2. Feedback POST (2.15) : Le user_id est derive de apiKey.slice(0, 8) = "ck_live_" qui n'est pas un UUID valide. L'INSERT echoue avec invalid input syntax for type uuid.
  3. Agent GET (2.16) : L'endpoint GET /api/agents/:name retourne 404. Non implemente.

Phase 3 : WebSocket & Flow principal — PASS (avec lenteur)

Test 3.1-3.2 : Connexion + Auth

Test 3.3 : Message simple (docker ps)

Timings detailles

Etape Temps Note
Auth 0s OK
Objective created 0.2s OK
Routing 30.7s LLM routing timeout 30s → fallback keywords
Thinking iter 1 33.4s Agent demarre
Tool call (dockerPs) 62.9s ~30s pour 1er appel LLM agent
Tool result 63.9s Docker PS execute en 1s
Thinking iter 2 63.9s OK
Complete (output) 120.9s ~57s pour 2eme appel LLM
Translation ~170s ~50s pour traduire en FR
Objective completed ~210s Total

Problemes constates

  1. LLM routing TOUJOURS en fallback : Le timeout de 30s est trop court pour la premiere inference (model loading). Meme avec le modele charge, le routing LLM prend souvent >30s.
  2. Chaque appel LLM agent : 30-60s : qwen3:8b avec tools+context prend 30-60s par iteration sur RTX 3090.
  3. Traduction ajoute ~50s : Un 3eme appel LLM pour traduire.
  4. Total ~3.5 min pour une question simple : Trop lent pour un usage interactif.

Phase 4 : Test par agent — 3 PASS / 2 FAIL

Test Agent demande Agent route Resultat Temps
4.1 monitor monitor monitor PASS ~210s
4.2 explorer explorer explorer PASS 113s
4.4 infra infra explorer PASS 91s
4.5 coder coder gitlab-dev FAIL 80s
4.6 auditor auditor explorer FAIL 128s (timeout)

Observations Phase 4

  1. Keyword routing imprecis : Presque tout est route vers explorer/research. Le fallback par mots-cles ne distingue pas bien les agents.
  2. gitlab-dev agent : Erreur sur tentative d'acces au bare repo git.
  3. Timeouts frequents : La 2eme ou 3eme iteration LLM timeout souvent.

Phase 5 : Scheduler — DESACTIVE (non teste)

Le scheduler a ete desactive pour permettre les tests. A reactiver apres ameliorations LLM.

Constat initial : Le scheduler creait des objectives toutes les 5 min (health_check) et 1h (disk_usage) qui generaient chacune 3+ appels LLM, saturant la queue et causant des deadlocks Ollama.

Phases 6-8 : NON TESTEES

Non testees faute de temps et a cause des problemes de performance LLM qui rendent les tests interactifs tres lents.

Problemes racines identifies

1. Performance LLM insuffisante (CRITIQUE)

2. Routing LLM timeout trop court (30s)

3. userId invalide

4. Schema DB incomplet

5. Ollama instabilite

Recommandations (par priorite)

HAUTE - Performance LLM

  1. Desactiver ollama-gpu1 dans l'orchestrateur (RTX 2070S trop petite pour qwen3:8b)
  2. Reduire OLLAMA_NUM_PARALLEL a 1-2 pour eviter les deadlocks
  3. Augmenter le routing timeout a 90s ou pre-charger le modele
  4. Envisager un modele plus petit pour le routing (qwen3:4b suffirait)
  5. Ajouter un circuit breaker dans ulias-org pour ne pas accumuler les jobs LLM

HAUTE - Bugs code

  1. Fixer le userId : utiliser l'UUID user de connectors-api au lieu de apiKey.slice(0,8)
  2. Ajouter colonne preferences dans ceo_profile Supabase
  3. Implementer les endpoints prompts (GET/PATCH/DELETE agent prompt)

MOYENNE - Scheduler

  1. Ajouter un guard "skip if busy" : ne pas creer de nouvel objectif si le precedent du meme job est encore in_progress
  2. Augmenter l'intervalle health_check de 5min a 15-30min
  3. Reactiver une fois les problemes LLM resolus

BASSE - UX

  1. Optimiser les appels LLM : skip la traduction si le profil est en anglais ou si la reponse est deja en FR
  2. Streaming : renvoyer les events plus granulaires (tokens) pour feedback utilisateur
  3. Cache LLM : cache le routing pour les questions similaires

Ce qui fonctionne bien

Actions a ne pas oublier