ThunderPhone 同時協調多個模型運作，讓它們互相修正錯誤。
快速大型語言模型只能讀取轉錄稿。
「你好，Brent——有甚麼可以幫你？」
快速及推理型大型語言模型交叉核對：3 條路徑中有 2 條結果一致。
「明白——即是說，你是租客。」
BBA 測試模型能否理解語音提示詞，並正確回答難題。我們最強的 Storm 配置目前保持該項紀錄：在我們的公開評估集上取得 99.4%。
0.6% 錯誤率
ThunderPhone 的結果來自上方連結的公開評估數據集；其他公開評分（來自 Artificial Analysis 排行榜）則列作參考。
Vapi、Retell、Pipecat 和 LiveKit 等語音 AI 平台，都要求你逐一決定大量設定細節，才能讓通話正常運作。ThunderPhone 深信，調校應由我們負責；你應只需投入最少工夫，便能讓通話流暢運作。
以上一切，ThunderPhone 都會為你調校妥當
Spark、Bolt 或 Storm。
精心挑選，並經真實通話測試。
行為、政策、工具——用日常語言直接設定。
只需作出三項選擇，設定即告完成——編排、後備機制及調校功能均已內置。
我們按工作需要配搭最合適的模型，讓它們協同運作。來自 OpenAI、Anthropic 及 Google 的前沿模型配合開源模型，經統一編排，為每次通話配出效能與價格皆最佳的組合——一切由我們處理，你毋須操心。
能力較弱的系統無法遵循複雜提示詞，才需要流程建構器。對話中的每一步都會變成一個節點，必須由你手動建立和維護。Storm 憑一個提示詞，便能遵循詳盡指示，讓你毋須再為節點與連線費心。
一個登記流程就要用上六個節點——每個節點均需各自設定提示詞、工具、流程轉換及失敗處理。
先向來電者問好，並收集對方的姓名及電話號碼。登記前，必須確認已取得對方同意。如對方查詢賬單事宜，請遵循下方的賬單政策。所有欄位確認無誤後，才可呼叫enroll()，並只可呼叫一次。如來電者要求與真人通話，請轉駁至真人客服。
只需一個提示詞，即可完成編寫、測試與反覆優化——分支邏輯也包括在內。
含糊不清的語音、背景交談聲、姓名與數字、多種語言夾雜——ThunderPhone 專為應對這些會令其他系統失靈的情況而設。
比對音訊與文字訊號，而非只依賴單一轉錄內容。
噪音識別及降噪模型可清理訊號，令語音更清晰。
及早識別旁人交談，避免干擾智能體應對。
交叉核對專有名詞、拼法、數字及更正內容。
按需要透過多語音訊及語音路徑處理。
當智能體的應對方式無法用單一規則概括時，採用更強的推理路徑。
語音 AI 必須快速回應——但只求速度而欠缺準確度，只會更快出錯。現今的 LLM 需要片刻思考，才能維持可靠表現，因此 ThunderPhone 在延遲與準確度之間取得平衡。
其他供應商聲稱在理想條件下延遲僅為500毫秒，但真實通話通常約為2秒。 我們按真實通話環境量度延遲。
AI 供應商的服務可能出現延遲急升，足以打亂整個通話流程。 遇到這種情況，ThunderPhone 經統一編排的技術架構會自動切換至速度更快的方案。
自動化通話一直令人頭痛……直到現在。每次技術革新都改善了體驗，卻始終未達真正流暢。ThunderPhone 正在改變這一切。
「銷售服務請按1字，客戶支援請按2字。」選單只能轉駁來電。
說出「銷售」或「賬務」，再寄望欄位解析器能正確識別。
先轉錄，再向單一高速 LLM 提問，最後以語音回應——每一步都依賴上一步的結果。
音訊、文字、推理、工具、聲線及防護機制，整合於同一套系統。