Résumé de réunion

Source: 10_meeting_summary_service

Un serveur HTTP qui accepte des uploads audio bruts, les transcrit avec l’API ElevenLabs Scribe, génère un résumé structuré de réunion avec Claude Sonnet, et renvoie le résumé en streaming dans la réponse HTTP. Chaque requête est traitée dans sa propre track — le serveur gère plusieurs uploads simultanés sans aucune gestion explicite de threads.

Exécution

melodium run 10_meeting_summary_service/Compo.toml \
  --anthropic_key sk-ant-... \
  --elevenlabs_key el-...

$ curl -X POST http://127.0.0.1:8080/summarise \
       --data-binary @meeting.wav \
       -H "Content-Type: audio/wav"
## Résumé de réunion
 
**Vue d'ensemble :** …
 
**Décisions clés :**
- …
 
**Actions :**
- …

Fonctionnement

Trois modèles sont instanciés au démarrage :

model server: HttpServer(…)
model stt:    Stt(elevenlabs_key=elevenlabs_key)
model llm:    Llm(anthropic_key=anthropic_key)

Stt utilise le modèle ElevenLabs scribe_v1. Llm utilise Claude Sonnet avec un system prompt de résumé structuré et une température plus basse (0,4) pour produire une sortie concentrée et cohérente.

Pipeline par requête

Le sous-traitement summariseRequest gère tout pour une requête :

transcribe retourne un Block<string>. L’adaptateur stream<string>() le convertit en Stream<string> pour qu’il puisse s’écouler dans buildSummaryPrompt, qui enveloppe la transcription brute dans un template de prompt via entry + format.

chat retourne un Stream<string> de tokens de réponse, encodés et transmis directement dans connection.data — les tokens du résumé apparaissent dans la réponse HTTP au fur et à mesure de leur génération.

Explication vidéo

Dépendances

[dependencies]
std      = "0.10.1"  # flux de base, journalisation, structures de données
http     = "0.10.1"  # serveur et client HTTP
net      = "0.10.1"  # utilitaires d'adresses IP
encoding = "0.10.1"  # encodage / décodage UTF-8
ml       = "0.10.1"  # inférence LLM, STT, TTS et modèles locaux