前幾天分別完成了 STT、TTS 和 Voice Cloning，但目前都還是各自獨立運作。

所以今天的目標很單純：

把 STT、LLM、TTS 串起來，完成第一版完整的語音對話流程。

第一版 Conversation Pipeline

目前流程是：

Microphone
↓
VAD
↓
Speech End
↓
Final STT
↓
Groq LLM
↓
Kokoro
↓
Playback

也就是使用者說完一句話後，系統先把語音轉成文字，再交給 LLM 產生回答，最後透過 TTS 轉成語音播放。

到這裡，AI Companion 第一次完成：

聽到我說話
↓
理解內容
↓
產生回答
↓
用聲音回答我

今天先使用 Kokoro 的固定中文聲線，Day 04 完成的 Voice Cloning 之後再依不同情境接進來。

為什麼還是使用 Final STT？

Day 02 做 Rolling Transcription 時，說話過程中會每隔一段時間更新 Partial 字幕。

但最後一次 Partial 不一定包含完整句尾，因此目前仍然維持：

Rolling STT
→ 顯示即時字幕

VAD 判斷 Speech End
↓
重新辨識完整一句
↓
Final STT
↓
送進 LLM

也就是 Rolling 主要負責「快」，真正送進 LLM 的則是完整的 Final Text。

這樣可以避免句尾還沒進入最後一次 Rolling 辨識，就直接把不完整內容交給 LLM。

LLM 怎麼選？

語音對話除了 STT 和 TTS，LLM 的回應速度也會直接影響使用者感受到的延遲。

這次使用 Groq，並實際比較幾個候選模型：

其中 llama-3.1-8b-instant 的 First Token 最快，而且這次繁體中文輸出也比較乾淨，因此先選它作為目前的即時對話模型。

在完整 Pipeline 中，LLM 從收到 Final STT 到完整回覆生成完成，大約需要：

0.48 ～ 0.71 秒

目前架構是：

STT
→ Mac 本機

LLM
→ Groq Cloud

TTS
→ Mac 本機

這也代表對話文字目前會送到雲端。

如果未來應用在高齡智慧健康照護情境，對話中可能包含生活或健康資訊，因此隱私會是一個需要特別處理的問題。後續會再評估本機 LLM、資料去識別化或送出前的資訊過濾。

實測：使用者說完後，要等多久 AI 才開口？

今天最想觀察的指標是：

Speech End → First Audio

也就是：

使用者說完
↓
AI 真正開始出聲

中間到底需要多久。

這次先使用既有 WAV 音訊注入完整 Pipeline，測試三輪：

Turn 1：1.61 s
Turn 2：0.99 s
Turn 3：1.14 s

平均約為：

1.25 秒

各階段大約是：

目前大約在使用者講完後 1 秒左右，就可以開始聽到 AI 的回答。

不過這組數據目前還是使用 WAV 測試，還不是實際對著麥克風進行多輪對話的結果，因此之後還需要再做真人語音測試。

現在的流程還不是 Streaming

目前的 Pipeline 仍然是：

等 Final STT 完成
↓
等 LLM 產生完整回答
↓
等 TTS 完整生成
↓
開始播放

雖然現在已經能完成完整語音對話，但如果想讓互動更接近真人，還需要繼續縮短等待時間。

之後會進一步把 LLM 和 TTS 改成 Streaming，讓 AI 不必等完整回答全部生成完，就可以先開始說第一段內容。

今天完成了什麼？

Day 05 完成：

Microphone
↓
VAD
↓
Final STT
↓
LLM
↓
TTS
↓
Playback

前幾天完成的單一語音模組，今天第一次真正串成一套可以對話的 AI Companion。

下一步，我想先回答一個問題：

現在這 1 秒多的等待時間，到底花在哪裡？

接下來會開始拆解整條 Conversation Pipeline 的延遲，找出目前最大的 Bottleneck，再準備進一步做 Streaming 優化。