Funk-lab/progress/2026-06-22.md

2026-06-22 — STT : transcription live + veille/réveil vocal ; relevé cluster (la veille)

STT — streaming partiel & contrôle vocal veille/réveil (client 0.13.0 → 0.14.0)

Deux fonctionnalités demandées sur l'assistant vocal Asa.

Transcription partielle live dans le HUD

En éveil, pendant qu'on parle, le buffer audio en cours est re-transcrit périodiquement (partial_interval_sec, défaut 0,5 s) et poussé au HUD via un événement partial → le texte se forme en direct dans une bulle dédiée (italique + curseur clignotant), puis la bulle « user » finale la remplace.

• Auto-activée seulement avec l'ASR onnx (Parakeet ~11× temps réel en CPU) ; whisper large-v3 CPU est trop lent → laissé off (forçable via [voice].partial_transcription).
• Bornée : partial_min_sec (anti-bruit) … partial_max_sec (coût ; au-delà, seul le final suit).
• Transcription inline dans la boucle audio (thread unique → pas d'accès concurrent au modèle ASR).

Veille / réveil vocal (« Asa stop » / « Asa »)

Refonte de la boucle en machine à états explicite veille (asleep) ↔ éveil :

• Veille : Asa transcrit chaque énoncé uniquement pour repérer le wake word ; ne répond à rien d'autre. HUD : portrait atténué/désaturé, label « SOMMEIL ».
• « Asa » (mot entier, alias ASR tolérés) → réveil. « Asa, » exécute la question.
• « Asa stop » (ou stop/dors/au revoir… = sleep_words) → retour veille (+ « Je me mets en veille »). Timeout d'inactivité aussi.
• Wake word par défaut asa (était hermes) ; wake_word/wake_aliases/sleep_words config.
• Détection wake durcie : mot entier (plus de sous-chaîne — « asa » est court et matchait « casa », « phrase »…).

Validé : tests unitaires (wake/sleep/alias) + Playwright (rendu asleep, bulle partielle mise à jour en place puis remplacée par le final, nettoyage du partiel au changement d'état). Bump client 0.14.0. Doc : admin/ia/stt.md (section « Interaction vocale »).

🐛 Trouvaille ASR (test sur poste) : Parakeet FR ne transcrit pas « Asa » comme un mot — il l'entend « a so » / « à ça » / « ah ça » (deux tokens). La détection mot-entier ne matchait donc jamais → « rien ne se passe ». Corrigé : on joint les 1-2 premiers mots (déaccentués, sans espace) et on compare en égalité exacte à des alias compacts (aso, aca, ahca…). Faux positifs évités (« à cause » → acause ≠ alias). Ajout d'un log diagnostic [stt.voice] (journalctl, STT_VOICE_LOG=0 pour couper) qui montre la transcription réelle. Validé en live : « Asa » réveille, « Asa stop » endort.

---

(Rappel) Relevé d'état réel + RAG re-ingéré — fait la veille (2026-06-21, PR #44)

Pour mémoire, cette même journée de travail a aussi produit (PR #44, mergée) : alignement de la doc sur l'état réel du cluster (admin/ops/etat-cluster.md), re-ingestion du RAG 436/436 chunks et le fix du batch embed (llama-embed ubatch 512 → 2048). Détail : progress/2026-06-21.md.

---

Réconciliation make apply-gpu + durcissement IaC (soir)

• ✅ Drop-in llama-embed réconcilié. Apply ciblé --tags llama_server (commit llama.cpp pinné → zéro rebuild, seul llama-embed redémarre) : l'unit rendu par le rôle porte maintenant --batch-size/--ubatch-size 2048. Drop-in temporaire batch.conf supprimé. ubatch 2048 effectif sur le process, rag-query OK → RAG intact.
• 🐛 Repo amdgpu cassé sur gpu-01 (cause du blocage make apply-gpu complet) : le dnf upgrade du rôle common avait bumpé l'hôte en AlmaLinux 9.8, mais radeon.com ne publie pas de rhel/9.8 (ni 9.5) — seulement 9.4/9.6/9.7. Le repo package-shipped ($amdgpudistro) tombait en 404. Soigné en live (/etc/dnf/vars/amdgpudistro=9.7 → dnf repolist propre) et durci en IaC : rocm_rhel_version 9.4 → 9.7, llama_server_commit pinné, pièges documentés dans les README de rôle. (PR fix/gpu-apply-amdgpu-repo-and-commit-pin.)

Asa agentique — boucle d'outils / function calling (Phase 1)

Asa ne répondait qu'à partir d'un contexte figé (RAG doc ou blocs live pré-câblés, à présélectionner) → « gpu-01 tourne bien ? » tombait sur « la doc ne le précise pas » (état live absent de la doc). Bascule vers une boucle de function-calling : le modèle décide quels outils appeler, puis répond à partir des résultats.

• Validé empiriquement avant de coder : Qwen3-8B via llama.cpp fait du tool-calling natif (pas besoin de --jinja), LiteLLM transmet bien les tools, et le tool-calling survit au /no_think. → 100 % local, pas d'escalade Claude (choix utilisateur).
• Nouveau contexte asa (STT_DEFAULT_CONTEXT=asa, défaut prod) + tools.py (registre schémas + exécuteurs) + brain.ask_with_tools (boucle bornée STT_TOOL_MAX_ITERS=4, réponse forcée au-delà). Outils Phase 1, lecture seule : search_docs, host_health, cluster_status, prometheus_query. Trace des outils → visualiseur HUD.
• PromQL validés contre le vrai Prometheus in-cluster (labels gpu-01-node/storage-01/ llama-server-gpu confirmés ; up/load/mem renvoient des données réelles). 3 tests unitaires de la boucle (hors-ligne). (PR feat/asa-tool-loop.)
• Choix : web search = SearXNG in-cluster (Phase 2) ; modèle = local uniquement.

Prochaines étapes

• Phase 2 — outil web_search (SearXNG self-host in-cluster, namespace ai, ArgoCD).
• Phase 3 — outil admin_action (écriture) : brancher hermes-exec comme outil piloté par le LLM, avec le handshake de confirmation vocale existant.
• Enrichir host_health/cluster_status (GPU via rocm_scraper, fs, températures) si utile.
• Si le wake word « asa » génère des faux positifs/négatifs, ajuster wake_aliases.
• 1er test d'action vocale (#43, contexte 🤖 Agent → hermes-exec).