# 策展 · X (Twitter) 🔥🔥

> 作者：Esha (@eshamanideep) · 平台：X (Twitter) · 日期：2026-05-08

> 原始來源：https://x.com/eshamanideep/status/2052389148435308854

## 中文摘要

# 即時且零延遲成本的幻覺修正

我們在生產環境中將語音 Agent 的幻覺率從 4-5% 降低至 1% 以下，且完全沒有增加延遲。LLM 生成文字的速度遠快於人類說話的速度，而這段速度差正是我們執行偵測的空間。

## 為什麼語音中的幻覺更危險

一位撥打電話的使用者詢問語音 Agent 關於自付額（copay）的問題。Agent 回答「0 美元」，但實際金額應為 40 美元。使用者預約了門診，開車橫跨整個城市，最後在櫃檯才得知真相。語音比文字更糟，原因有二：

你無法使用推理模型進行生成。語音要求大約一秒的 TTFB（Time To First Byte，首字延遲），否則對話會顯得卡頓。推理模型在回應前會先進行思考，幻覺較少，但它們輸出第一個 token 需要數秒——這對語音來說太慢了。這迫使語音系統必須使用非推理模型，雖然速度快，但幻覺較多。讓語音聽起來自然的限制，同時也是讓它準確度降低的限制。

口語錯誤會繞過驗證。在文字中，錯誤的答案會留在螢幕上，使用者可以重讀、質疑或檢查其他來源。在語音中，同樣的答案以自信的語氣傳達後隨即消失。聽者會根據說話者的語氣、節奏和強調來判斷其誠信度，而這些聲音線索會影響感知到的可靠性以及口語工作記憶（Goupil et al., Nature Communications, 2021）。使用者在驗證前就採取行動的可能性更高。

這些因素會疊加。模型因為無法推理而產生更多幻覺，而使用者因為它聽起來很自信而更信任它。

## 為什麼你不能在說話前先進行驗證

標準的修復方法是：在使用者聽到之前，用第二個模型驗證回應。在文字中這可行，但在語音中，這會讓每一輪對話增加 3 到 4 秒的延遲。TTFB 會變成 3 秒以上，使用者就會掛斷電話。

```
TTFB_verified = t_LLM + t_verify + t_TTS
≈ ~1000ms + ~3000ms + ~500ms
= ~4.5s → caller hangs up
```

你必須在每一輪對話中付出這個代價，即使在 96% 模型沒有產生幻覺的對話中也是如此。

## 核心洞察：吞吐量 > 說話速度

洞察：LLM 生成文字的速度遠快於語音模型說話的速度。

正確的比較方式不應僅僅是原始的每秒 token 數。語音系統首先要花費時間產生第一個 token，然後串流輸出剩餘內容。以粗略的規劃數據來看，一個近期的低延遲模型可能需要 600ms 輸出第一個 token，然後以每秒約 75 個 token 的速度串流。一段 30 個單字的回應大約是 40 個輸出 token，因此完整文字在大約一秒內即可取得。但說完這 30 個單字需要 10 到 12 秒。這段已生成內容與已聽到內容之間長達數秒的差距，就是我們執行偵測的空間。

這並非一個微小的視窗。即使計入初始延遲，完整文字通常在使用者聽完之前就已經存在好幾秒了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662452-diaHHr3D1a8AACgqdpng.png)

## 運作原理

一切皆為串流。當每個句子完成時，會同時發生兩件事：

路徑 1：音訊。該區塊會傳送至 TTS 並立即串流給使用者。

路徑 2：偵測。同一個區塊會傳送至推理模型。它會檢查：這是否與指令衝突？是否與先前說過的內容衝突？模型是否憑空捏造資訊？回應是否遵守所有嚴格的防護欄（guardrails）？

音訊絕不會等待偵測。它們在競賽，並產生兩種可能的結果：

結果 1：偵測器在幻覺音訊播放前完成

這是常見的情況，當幻覺內容出現在語音回應的較後段時。LLM 在大約一秒內提供完整文字，而 TTS 則在 10 到 12 秒內逐字說出。偵測器需要 3 秒。當使用者聽到「您專科門診的自付額是……」時，偵測器已經將「0 美元」標記為錯誤。系統會阻止幻覺音訊播放並替換為正確回應。使用者聽到的是：

使用者聽到 · 結果 01 「您專科門診的自付額在您目前的計畫下是四十美元。」

沒有中斷，沒有修正語句，沒有「讓我修正一下」。使用者從未聽到錯誤答案，也永遠不會知道偵測系統正在運作。這種體驗是無縫的。

結果 2：幻覺音訊在偵測器完成前播放

這發生在非常簡短的回應中。如果完整回應是「您的自付額是 0 美元」，且 TTS 在 2 秒內說完，那麼在 3 秒的偵測過程完成前，音訊就已經結束了。使用者聽到了錯誤答案。此時 Agent 需要明確地自我修正：

使用者聽到 · 結果 02 「您的自付額是 0 美元。……其實，讓我修正一下。您的自付額是四十美元。」

「其實，讓我修正一下」這座橋樑只存在於結果 2 中，因為使用者已經聽到了錯誤資訊，需要知道它正在被修正。在結果 1 中，從使用者的角度來看，沒有任何需要修正的地方。

結果 3：偵測器完全漏掉

沒有任何偵測系統是 100% 準確的。在大約 1% 的對話輪次中，偵測器完全沒有標記出幻覺。這不是時間問題，而是偵測器單純判斷錯誤。幻覺就這樣未經修正地傳遞出去。降低這個殘餘率是提升偵測器準確度的問題，而非架構問題。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662664-iaHHr6lI1bIAAKixkjpg.jpg)

## 不同模型作為偵測器的比較

並非所有偵測器都一樣。我們針對自身使用場景建立了一個內部基準測試，並評估了三類模型在對 Agent 可靠性最重要的幻覺類型上的表現：指令衝突（Agent 執行了被禁止的操作）、上下文衝突（Agent 在對話中途自相矛盾）以及憑空捏造（Agent 發明資訊）。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662558-iaHHr3S3JbgAAJL1Lpng.png)

在指令衝突和上下文衝突方面的差距最大。這些是造成損害最大的幻覺，因為使用者無法獨立驗證它們。基於 BERT 的分類器在指令和回應中看到「退款」這個詞，就會認為它們相符。而推理模型能理解「絕不提供退款」與「我可以處理退款」是衝突的，而非一致。

## 修正提示必須是暫時的

當偵測器捕捉到幻覺時，它會建立一個修正提示：哪一段內容是錯的，以及需要變更什麼。該提示對於修復當前的音訊很有用，但不應成為正常對話歷史的一部分。

根據時間點，系統會以兩種方式之一使用該提示：

```python
def on_hallucination_detected(audio_stream, detection):
  correction_hint = detection.span

if audio_stream.has_played(detection.span):
  # 結果 2：使用者已經聽到了錯誤的部分
  # 需要明確修正
  audio_stream.inject("Actually, let me correct that.")
else:
  # 結果 1：錯誤部分尚未播放
  # 靜默封鎖錯誤音訊，替換為修正內容
  audio_stream.block(detection.span)

corrected = llm.generate(
  system_prompt=S,
  context=C,
  correction_hint=correction_hint
)

audio_stream.resume(corrected)

correction_hint = None  # 關鍵：不要帶入下一輪對話
```

最後一行是最重要的。我們是透過慘痛的教訓才發現這一點。

在早期的實驗中，我們將修正元資料保留在跨輪次的對話狀態中。效果是立即且一致的：模型開始對所有事情都採取保留態度。「我相信……」、「如果我沒記錯的話……」。它將自己的修正歷史解讀為一個訊號，要求對所有事情都表現得不那麼自信。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662359-iaHHuAcTFbEAANSYUpng.png)

暫時性的修正提示解決了這個問題。提示只告訴模型在單次修復中哪裡出了錯，然後就消失了。後續的對話輪次會看到乾淨的上下文。Agent 修正了一個錯誤，並以完全的自信繼續對話。

## 生產環境成果

在 120 萬次即時對話輪次中測量，而非基準測試。

在 120 萬次輪次中，幻覺率下降了超過 70%，從 4–5% 的基準降至 1% 以下，誤報率低於 0.3%。測量於即時流量 · 30 天滾動平均。

在 96% 的輪次中，模型是正確的，偵測系統不採取任何行動。在 3-4% 的輪次中，偵測系統捕捉到幻覺並進行修正（第 4 節中的結果 1 或 2）。剩下的 1% 是偵測器漏掉的幻覺。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662465-iaHHr3hB6boAAaT6cpng.png)

## FaithEval 上的棄權評估

我們使用一個經過精心迭代、針對幻覺偵測優化的系統提示的推理模型，在 FaithEval 的「無法回答（Unanswerable）」分割集上進行了評估。此資料集捕捉了答案未出現在提供上下文中的情況，使其對於衡量模型是否能避免幻覺並在證據不足時選擇棄權特別有用。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778208662458-diaHHr3oRaAAAGPnMpng.png)

## 限制

1% 是底線，而非零。剩下的 1% 包含知識庫未涵蓋的新穎問題、兩種解釋皆合理的模糊指令，以及偵測器誤判的情況。

長對話會降低偵測效果。偵測器需要指令、近期對話以及當前區塊。對於 20 分鐘的通話，較早的對話輪次會被摘要，導致通話初期的一些關鍵事實可能會遺失。

我們的 1% 是一個下限。我們是從捕捉到的幻覺加上 QA 審核來測量的。完全漏掉的幻覺是不可見的，我們不知道該類別的規模。

## 進行中的研究

偵測器捕捉到的每一個幻覺，都是關於哪裡出錯以及為什麼出錯的標記範例。我們正致力於將這些資料回饋到上游：當同一類型的幻覺重複發生時，自動建議指令重寫；在 Agent 接聽電話前審核知識庫中的衝突與缺口；並利用偵測資料進行 RL（強化學習）以持續改善偵測器。目標是一個閉環系統，讓偵測、指令品質與模型品質互相提升。

如需引用與參考資料，請造訪：giga.ai/hallucinations

## 標籤

Agent, AIGC, TTS, LLM