2.0 KiB
title, area, horizon, tags, flag, src
| title | area | horizon | tags | flag | src |
|---|---|---|---|---|---|
| Live API Gemini — audio natif bidirectionnel | backend visitapp | v2 | 3 repos | warn | V2 — spike d'abord | voice-latency-plan.md §3.2 |
Supprimerait les trois maillons Whisper → LLM → Gemini TTS au profit d'un WebSocket permanent : flux micro brut en entrée (PCM 16 kHz), flux audio en sortie (24 kHz), sans jamais passer par du texte. Débloque trois choses que l'architecture actuelle ne peut structurellement pas faire : le barge-in (couper la parole à l'assistant), le VAD côté serveur (fin du timeout: 5 secondes en dur de _listenForFollowUp) et une latence de l'ordre de la seconde. Les voix prébuilt sont de la même famille — Viva/Marco survivraient.
Le point dur n'est pas l'audio, c'est le tool calling. Les outils (GetSectionDetail, RAG) vivent dans manager-service. Deux options : l'app parle directement à Gemini (latence minimale, mais logique métier déplacée dans le client et jetons éphémères obligatoires — on ne met pas une clé Gemini dans un APK de visiteurs), ou manager-service proxifie le WebSocket (clé au chaud, prompt et stats gardés, mais relais audio temps réel en C# avec sessions, reconnexions et backpressure). C'est l'option B qui a du sens, et c'est elle qui coûte cher.
⚠️ Le modèle de coût change de nature : plus à la requête mais à la session ouverte, avec des jetons audio bien plus chers. 80 visiteurs simultanés = 80 sessions. À chiffrer, les tarifs ne sont pas connus ici. ⚠️ Sessions à durée limitée, reprise à gérer sur réseau mobile en bâtiment de pierre. ⛔ Modèles en preview — après l'historique ElevenLabs → Gemini, y accrocher une fonction vendue serait imprudent. Verdict : spike chiffré d'une journée avant toute décision.