測試結論

• 決定使用Vertex，主要考量如下

  • 當前主機即是在Google上，考慮到未來的串接與使用，可能會比較方便
  • 考量到之後可能的應用，「影片辨識」應該是必須的，而目前有這個能力的LLM只有Vertex或Azure，經比較過後，認為Vertex會比較適合

• 基礎的設置，足以滿足目前的主要需求

  • 主要需求是能一部作品辨識「發表形式」、「產業別」、「作品風格」，這三類標籤 當前使用gemini flash與預設的參數，在測試28部不同形式的作品後，三類標籤並沒有辨識有離譜錯誤或是突兀的部分。
  • 經測試，可以吐出符合excel格式的文字。
  • 「作品元素」需要討論，後續說明

• 當前使用的模型，只能滿足分類(標籤)影片的需求，進階應用尚不確定

  • **協助使用者上傳作品標籤：**理論上可行，若要融入在上傳流程內，需要研究
  • **自然語言搜尋：**需將資料向量化，且可能會需要使用其他模型或自己訓練，需要研究。
  • **推薦系統：**可能可行，但需討論出推薦邏輯，才能判斷能不能使用此模型

• 目前已經有預約相關服務的廠商來諮詢，若有任何變更或異動，會於群組通知

待討論事項

• 使用圖片 or 影片當作Input?

  • 推薦使用圖片，主要原因是比較便宜(看秒數比例)，且「主要需求」的效果沒有明顯差異，但
    • 比較長的作品「可能」會需要使用影片來做，因為有發生數次過一次太多圖片，而導致crash的狀況，需要再多嘗試幾部長作品。

• 是否要將「作品元素」作為這次的重點?

  • 推薦「要」，因為收費是按input的量來收錢，能一次做完是最好，但需要再一些時間嘗試比較能「辨識出重點物件的prompt」

• 當前tag是否要順便調整為樹狀結構?

  • 考量到時間，先建議以目前的tag邏輯來做即可
    • 目前的tag其實是堪用的，未來理論上會重新調整一次，若之後再調整，AI的跑出tag流程會需要再跑一次，費用也是在跑一次，但目前的理解上，這個費用其實是非常便宜的。 而如果要調整，可能會需要1~1.5月的時間來確認tag內容、重新調整Prompt、重新調整前後端等調整。

應用pipeline(粗估7月看能否先在測試站上實驗完畢)

1. 請RD寫工具，能抓取三個平台的作品/縮圖，並放在google storage上(可能會有一小筆儲存費用)
2. 確認好prompt與指定格式，並串接其程式碼
3. 吐出來的內容，可能需要先清洗過一次，不符合的規格的資料則需要回到步驟1
4. 將清洗完畢的資料放回至DB

可以先用小規模(1~200部)的方式，在測試站來測試1~4的步驟，並先人工抽樣確認正確性，如果沒問題再跑所有的作品

接下來的步驟

• 跟相關廠商與RD確認上述的可行性與價格
• 研讀google的prompt說明書