在前一篇裡提到這套工具系統的第一個階段，是把業務的客戶提案會議的錄音或錄影檔，轉換成可被系統進一步分析的逐字稿。

一開始真的覺得這件事情應該不難，但實際開始測試之後，才發現事情沒有這麼簡單。
業務團隊在不同市場的會議使用不同的語言，甚至可能有多種語言夾雜的情況（例如：台灣的提案會議就常有中英夾雜的情形），不同語言本身就會帶來不同的文字轉錄挑戰。除了要確認文字有沒有被正確辨識之外，我們還需要反覆測試不同的model，以及不同的 thinking level，去確認到底什麼樣的組合，才能讓不同語言的逐字稿品質都相對精準，而且穩定。畢竟是要長期被使用的系統，單次產出精準遠遠不夠，還需要有持續的穩定性。

接著，我們很快又發現，逐字稿不只是把會議內容都精準轉錄成文字就好了，我們還需要知道每句話的說話者到底是誰？是業務還是客戶？因為我們要review的是「業務」的提案表現，所以自然需要知道講話的是哪一方，後續階段的評分才能夠精準。例如，客戶提出了一個問題，業務有沒有完整回答？業務的回答是否真的對應到客戶的疑問？業務有沒有主動提出好的exploration questions？有沒有挖掘到客戶真正的痛點、商務問題、KPI目標？

如果逐字稿沒有辦法清楚辨識講者，後面的評分就可能從一開始就判斷錯對象。

所以準確來說，我們對逐字稿的要求不僅是「把聲音準確地轉成文字」，而是要「把一場會議的內容轉換成一份可以後續被AI正確理解分析的有效資料。」我們後來對 transcript 的要求，已經不只是：

也因此，這一段來回測試花掉的時間，比我原本想像中多很多。我們不斷測試、比對、調整，再請不同母語的同事協助確認產出結果，最後才逐漸找到比較穩定的model和thinking level設定。

而且，這些設定也不是一次確認完之後就一勞永逸，即使找到一組目前看起來最適合的設定，系統正式開始使用之後，我發現還是得持續監測逐字稿的轉錄品質。不同類型的會議（線上線下）、不同的收音環境、相異的錄音品質，都可能讓實際產出結果發生變化。如果運行一段時間之後發現平均轉錄品質有下降的趨勢，我們就需要重新檢視，是不是需要調整到更新的model，或者是我們對逐字稿轉錄的prompt寫法需要再做調校。這體現了這個專案一直在重複做的：測試 → 驗證 → 監測品質 → 調整，下一個階段的評分機制更是如此，需要更加縝密的測試驗證過程，確認我們定義的規則確實讓AI能夠判斷，一場好的提案會議該是什麼樣子。