LLM雲端服務導入試驗

最近嘗試將LLM雲端服務導入遊戲專案作為即時生成內容應用

這次用了Chat GPT與Gemini來測試，應用是實時產生遊戲中的關卡題目與提示，並且判斷玩家回答是否正確

以下是這次試驗遇到的難點：

這次試用的兩個服務都偏向要開發者使用"自然語言"對AI下指令，也就是理想上人跟人對話的方式來叫AI做事

然越"自然"越是容易模糊，比如下令讓AI"愛上一個人"，那是要他"愛上"一個人呢？還是愛"上一個"人呢？愛上"一個人"呢？

這個例子也牽扯到不同語言的特性，如果上面的指令是用英文來下的話顯然不會出現這樣的問題，然不同語言也會有類似的問題，例如英文的"I’m fine"、日文的"すみません"等，都是很經典的例子

所以，要靠"自然"對話讓AI準確理解，背後其實需要很多其他條件支撐(例如背景設定、前後文、對話情境等等...)，這也是為什麼網路上能看到那麼多分享跟AI溝通的技巧、甚至有"提示詞工程師"、"AI溝通師"這種職位的原因

上述提到的"其他條件"放在這次試驗的服務中，則是以declaration、function calling、tool use等方式來實現

這種情況對開發者來說是矛盾的，你要我"自然"的給你下指令，但要讓你產生我期望的結果又不能只那麼"自然"，這樣有意思嗎？我是什麼很賤的人嗎？

在這次試驗中有個很難解的情況，就是不論事前再怎麼叮囑、再怎麼要求條件給限制，使用者都有一定機會可以用提示詞讓AI回答出非預想的內容

例如我讓AI出題，並且要求玩家的所有對話都視為一次回答、只要跟答案不同就算錯，然而只要玩家給的對話是詢問或指令式的內容，AI就有機會脫離設定、變回那個乖巧的對話機器人

由此可見這些服務的指令權重區分並不理想，即使是設定在declaration或tool裡的指令也一樣。AI會聽開發者的指令、但也會聽使用者的指令，你說這到底算聽話還是不聽話呢？

這次用的服務計費方式，不論是送出去的訊息還是回應的訊息都需要計費，此為持續性的消耗，若產品為買斷式則非常不建議使用三方LLM雲端服務。

而如先前所言，要讓輸出結果達到理想會需要額外的設置，那些設置也會算成本；甚至有些廠商的方案不直接提供記憶，比如Gemini API需要你自己記錄歷程並送給他，而這些歷程內容也是要算錢，也就是同組對話成本會隨筆數成滾雪球式累加

也因此，每組對話的字數與次數也是需要考量的，實作時也要搞相應的機制來處理

雖然沒有投入市場，但試算下來要能夠回本還真不是件容易的事

以上，大該就是這次試驗遇到的難點

當然也非只有難點，這些LLM產出的文本內容是動態的、豐富的，AI對於業務的判斷也沒出什麼毛病，是能省下一定造輪子的成本

現在要讓遊戲內容接入雲端LLM是可以的，只是上述的那些難點會讓質量比較陽春、不穩定，需要花更多心力來處理衍伸問題，就我目前運行的模式來說是不划算的

不過AI發展是顯著的趨勢，相信這些難點遲早會被更好的方案或模式克服，期待那天的到來！

最新文章