電話音訊品質不穩定
背景噪音、音量差異與連線品質，都會影響語音辨識結果。
技術與研發
把語音 AI 放進真實營運流程，而不是停在展示。
AnyTaxi 的研發重心，是讓語音處理、訂單流程與派遣系統在同一個營運情境中被驗證。我們先定義問題與失敗情境，再選擇可測試的技術方案。
技術問題
語音接單的難點，通常不在單一模型。
電話音訊、口語地址、營運流程與既有系統彼此牽連。任何一段處理不穩定，都會反映在訂單品質與人工負擔上。
地址口語變體多
同音、簡稱、分段描述與在地名稱，讓地址無法只靠字面比對。
延遲與覆核的平衡
過度自動化會放大錯誤，過多人工則失去流程改善的意義。
既有系統的整合成本
派遣系統、資料格式與權限模型各異，介面邊界必須先定義。
概念架構
分層，讓每一段都能獨立測試與替換。
語音入口、語音處理、營運核心與資料觀測之間以明確介面連接。這讓我們能替換語音服務、調整擷取規則，或先以人工覆核補上尚未穩定的環節。
公開資訊邊界
本網站不公開伺服器位址、帳密、金鑰、內部管理網址、客戶個資或敏感部署細節。
語音入口
電話進線語音流程
語音處理
語音轉文字意圖與欄位擷取
營運核心
訂單服務派遣介面人工覆核
資料與觀測
營運資料事件紀錄測試樣本
橫向能力：權限控制 · 日誌 · 監控 · 資料最小化
工程方法
先讓系統可被檢查，再談規模化。
我們以測試、紀錄與人工覆核建立回饋循環。沒有可比較的基準，就很難判斷調整是否真的改善流程。
固定測試集
以人工標註的通話樣本建立可重複的評估基準。
事件紀錄
記錄每個處理階段的結果與失敗原因，支援追蹤與除錯。
人工覆核
低信心或衝突資訊進入人工確認，而不是直接產生訂單。
資料最小化
只保留流程所需資料，並以權限與保存期限控制存取。
評估方法
先定義怎麼量，再談改善。
我們不公布未經確認的辨識率或客戶成效。以下指標用於建立可重複的評估基準；數值需在固定測試集與場域條件下確認後才會公開。
欄位正確性
上車地點、時間、人數與備註的分欄正確性，以人工標註比對。
人工覆核率
低信心與衝突資訊的比例、原因與覆核後修正。
端到端延遲
從通話結束到可派遣訂單的時間；SLA 需由場域定義。
訂單與派遣對帳
語音、訂單、派遣與完成狀態的一致性。
風險與緩解
把失敗模式放進設計。
電話音訊、口語地址、延遲與系統整合都可能失敗。我們以人工覆核、事件紀錄與分階段驗證降低風險，而不是假設模型一定正確。
音訊與口音
前處理、固定測試集、分情境觀察。
地址變體
正規化、候選比對、低信心追問與人工覆核。
延遲與容量
分階段導入、量測端到端延遲與失敗率。
系統整合
介面邊界、沙箱驗證、事件紀錄與回滾。
研發進度
已完成、驗證中與研發中分開陳述。
以下依 2026-10 內部稽核與場域證據整理。狀態描述的是可檢查的工作，不是官網測試成績；原始證據與敏感資料不公開。
-
電話鏈路與車隊後台已完成
正式電話、人工轉接、通話紀錄與車隊後台已有營運使用紀錄。
驗證方式：營運紀錄與內部能力稽核
已完成 -
語音與地址場域驗證驗證中
場域使用與低信心追問並行；不公布分語言辨識率或建單成功率。
驗證方式：固定測試集、人工標註、場域回饋
驗證中 -
派遣與端到端對帳驗證中
派遣引擎與後台已有場域使用；語音到訂單到派遣的對帳仍在驗證。
驗證方式：事件紀錄與場域對帳
驗證中 -
語音學習平台研發中
觀測與人工標註持續進行；自動候選尚未正式啟用。
驗證方式：版本化資料與人工標註流程
研發中 -
多車隊與白牌研發中
多租戶隔離與第二車隊導入仍需測試與場域證據。
驗證方式：隔離測試與第二車隊導入紀錄
研發中 -
跨語言語音流程規劃中
依場域需求評估語言與情境優先順序，尚未進入正式實作。
驗證方式：場域需求與語言優先順序
規劃中
研發藍圖
近期驗證、中期產品化、長期研究。
以下為研究方向與工作順序，不是已承諾的交付日期或營收目標。
近期
- 地址覆蓋與低信心追問
- 人工覆核與例外處理
- 端到端對帳
- 多車隊隔離測試
中期
- 語音學習候選與版本治理
- 跨語言與白牌流程
- 營運資料產品化
長期
- 多代理治理與自動化營運
- 產業合作與生態整合