LINE Bot 多模態輸入：為什麼我們先把媒體轉成文字

多模態聊天聽起來像是一個輸入格式問題：把文字換成照片、語音或位置，然後交給模型理解。但產品真正上線後，問題通常不在「模型看不看得懂」，而在既有的配額、工具選擇、對話記憶與錯誤處理能不能繼續成立。

我們在 Twinco 的 LINE 對話中採用一個看似保守、實際上很務實的原則：媒體先轉成文字，再進既有對話管線。 這篇文章整理這個決定背後的原因，以及實測後才看清楚的限制。

核心設計：媒體不是新的主管線

最初可以想像兩條路：一是讓每種媒體建立自己的處理流程，二是把媒體直接作為模型輸入的一部分。兩者都很直覺，卻會快速複製既有對話系統裡最難維護的部分。

我們選擇第三種做法：先把媒體轉成可保存、可檢查的文字，再交回同一條文字對話管線。

語音 → 轉錄 → 文字 → 對話管線
照片 → 選擇意圖 → 圖片轉述 → 單輪回覆或對話管線
位置 → 選擇意圖 → 地址與縣市文字 → 對話管線

這樣做的主要收益不是少寫幾個 handler，而是讓原本已經被測試覆蓋的能力繼續有效：

• 天氣與地點工具仍能從使用者文字中確認城市。
• 對話記憶可以保存實際語意，而不是一個無法重播的媒體物件。
• token 配額、工具限制與遙測都沿用同一套計算方式。
• 失敗時可以看見「轉錄失敗」或「工具失敗」，不會全部混成模型回答不佳。

每種輸入不該被當成同一件事

多模態不是單一功能。照片、語音與位置的成本、延遲和使用意圖都不一樣，因此路由策略也應該不同。

語音的意圖通常已經在語音內容裡，所以轉錄後可直接進主管線。照片和位置則不同：同一張海報可能是要擷取文字、了解內容，也可能要建立行程；同一個位置可能是要查天氣、餐廳或停車場。

不猜意圖，先讓使用者選

我們曾經讓位置訊息直接查天氣。流程很短，但產品替使用者做了決定。一旦猜錯，回覆即使技術上完全正確，體驗仍然像功能壞掉。

現在照片與位置都先回傳一組有限選項。這個選單有兩個作用：

1. 把高成本工作延後到使用者真的表達需求之後。
2. 將模糊意圖轉成系統可以可靠辨識的文字命令。

尤其照片不必在收到時立刻下載。若使用者沒有點選任何用途，系統只保存短時間有效的訊息識別資訊，不保存圖片內容。對記憶體有限的服務來說，這比把所有圖片先塞進快取合理得多。

好的多模態互動不一定是「完全沒有按鈕」，而是只在模型無法可靠知道下一步時，給出少量且明確的選擇。

對話記憶與待處理狀態要分開

加入媒體後，系統會同時出現兩種看似都是「上下文」的狀態：

• 對話記憶：提供給模型的短期文字歷史。
• 待處理狀態：提供給程式的訊息識別、座標與使用者尚未選擇的操作。

它們不應合併。對話記憶的目的是讓模型理解「那高雄呢？」接續上一輪；待處理狀態則是讓程式知道「附近餐廳」應該使用哪一組真實座標。若把座標放進模型可見的文字歷史，就增加了模型複述或改寫座標的機會。

兩者的有效期限也不同。照片通常只在剛傳送後的短時間內有意義，位置則可以在一段移動不大的期間重複用來查不同類型的地點。把所有狀態綁在同一個 TTL 上，只會讓產品方案設定與互動語意彼此牽制。

轉成文字也有代價

先轉文字不是免費的抽象。語音會多一次轉錄呼叫，照片轉述也可能成為額外的一輪模型工作。因此我們刻意讓轉錄階段保持很小：不帶對話歷史、不提供工具，也不套用完整助理提示詞。

實際量測後，一段短語音相較同長度的文字輸入，增加的 token 比最初估計低；真正容易把單輪成本推高的，通常是後續工具呼叫與工具結果整理，而不是音訊本身。這個結果也提醒我們：不要因為加入多模態，就替所有使用者等比提高額度。 應先觀察真正使用媒體的比例、長度與工具分布。

配額的前置估算也必須跟著調整。純文字可以用字元數當低成本近似，但語音在轉錄前沒有文字；若仍回報零，就會讓最昂貴的輸入繞過第一層防濫用。較合理的方法是用音訊秒數與圖片上界做保守估算，最終計費再以供應商回報的實際 token 為準。

讓工具只在能執行時出現

附近地點搜尋需要真實座標。沒有位置上下文時，即使模型選對工具也無法執行，所以我們只在位置狀態存在時把這個工具提供給模型。

條件式載入有三個好處：

• 減少每輪都要送出的工具描述。
• 降低模型誤選一個無法完成的能力。
• 讓「缺少位置」成為清楚的產品狀態，而不是一次工具例外。

重要的是，工具消失時提示詞也要說明原因，讓模型知道應該請使用者傳送位置。否則使用者會得到含糊的拒絕，工程端則看不到到底是模型不會選、還是系統根本沒提供工具。

上線前應該釘住的契約

多模態最危險的錯誤往往不會讓程式拋出例外。語音可以成功轉錄，卻因為城市文字沒有進到天氣判斷而被反覆追問；照片可以成功回答，卻沒有寫入記憶與遙測；重設對話可以顯示成功，待處理的位置卻仍在下一輪生效。

我們最後用測試固定幾項契約：

1. 轉錄階段不得攜帶工具與歷史。
2. 直接回覆的圖片流程仍要寫入文字記憶與觀測資料。
3. 重設對話必須同時清除記憶與待處理媒體狀態。
4. 沒有位置時，附近搜尋工具不得出現在工具集合。
5. 媒體預估不能是零，實際扣量仍採供應商回報。

可以帶走的原則

把媒體轉成文字不是所有多模態產品的唯一答案。如果需求需要精準比較多張圖片，或後續回合必須重新檢視原始畫面，文字轉述會遺失重要細節。但對一個已經有成熟文字工具鏈、短期記憶與用量治理的助理而言，它是一個風險可控的起點。

我們從這次實作得到的判斷很簡單：

• 先決定哪些媒體真的需要模型，不要把「支援格式」等同於「每次都呼叫模型」。
• 把模型需要的語意，和程式需要的結構化狀態分開。
• 不要讓模型填寫系統本來就知道的座標或識別資訊。
• 在加入新輸入前，先確認既有配額、記憶、工具與遙測契約是否仍成立。
• 用正式流量量測成本，不用最初估算替所有人調整產品限制。

多模態真正困難的地方，從來不是把檔案送進模型，而是讓新輸入在整個產品系統裡成為一等公民。