Category: life

實施生成式人工智慧:兼顧速度與安全

本文來自 Mckinsey Implementing generative AI with speed and safety 的讀後筆記,這是我家的 MA 幫忙找到並介紹給我的,這篇其實出版時間早於金融服務的未來:生成式人工智慧與其運營模式革新

大意: 生成式人工智慧(gen AI)已成為推動企業創新、成長與提升生產力的關鍵動力。麥肯錫的研究指出,gen AI 不僅有機會為全球經濟增加高達 4.4 兆美元的經濟價值,更能提升所有 AI 技術的影響力 15% 至 40%。然而,如此巨大的潛力自然伴隨著不小的風險,從資料偏差、AI 幻覺、到可能引起的大規模錯誤資訊及對政治和個人福祉的惡意影響,gen AI 的挑戰不容小覷。

這篇文章深入探討了企業如何在迅速採用 gen AI 的同時,確保安全與負責任地進行。文章建議企業採取四個具體步驟來應對與 gen AI 相關的風險,從了解內部風險暴露(inbound),發展各方面的人工智慧風險觀點,到建立治理結構和運營模型,每一步都旨在為企業提供清晰的路線圖,幫助它們在尚不確定的法規環境中穩健前行。

註:inbound 在這裡指的是即使不部署 gen AI,也可能影響組織的風險

主文摘要:

  1. 生成式 AI 的轉型潛力與經濟價值
    • 生成式 AI 為企業提供轉型機會,能夠在創新、成長和生產力提升等方面產生顯著影響。
    • 麥肯錫估計gen AI可能為全球經濟帶來高達 4.4 兆美元的經濟價值,提高所有AI技術影響的 15% 至 40%。
  2. 風險認識與準備不足
    • 許多組織體認到 gen AI 的未來發展機會也正躍躍欲試(63%);但因伴隨重大風險,仍感到自己對於負責任的部署準備不足(91%)。
    • 風險包括不準確輸出(含幻覺)、訓練數據偏見,以及對政治和個人福祉的潛在負面影響。
  3. 負責任與有效風險管理策略
    • 文章提議四步驟策略:了解內部的風險暴露、發展全面風險觀點、建立治理結構、嵌入運營模型(這就是上一篇有提到的)。
    • 這些策略有助於組織在 AI 監管環境演變時,負責任且有效地捕捉 gen AI 的價值。
  4. 風險類別與管理
    • 將 gen AI 相關風險分為八大類別,包括四個同時也是內部風險源 (inbound) 的安全威脅、第三方風險、惡意使用和侵犯智財權等。
    • 強調組織需定期評估風險暴露和更新風險管理策略以適應技術演進。
  5. 通過 AI 治理在速度與風險管理之間取得平衡 (參考圖五)
    • 一個跨職能、負責 gen AI 發展的小組,至少每月一次會議。
    • AI 指導原則和政策:組織應該開發一套由執行團隊和董事會同意的 AI 指導原則和政策。
    • AI 人才和文化:對負責任的 AI 的承諾不能僅僅停留在執行層面。相反,它需要貫穿整個組織,將責任、能力建設和意識調整到相關角色對技術的暴露程度。應該開發並推出基本的全組織負責任的 AI 培訓,以促進對內部風險動態的廣泛理解,以及如何安全地與技術互動。
  6. 實施 gen AI 的關鍵角色與責任
    • 四個關鍵角色:設計師、工程師、管理員、和使用者,各自承擔不同職責,推進負責任 AI 使用。
    • 建立適當治理結構和人才管理是成功利用 gen AI 的關鍵,幫助組織管理風險並充分掌握技術好處。

圖示:

gen-AI-related risks can be captured in eight main categories
Exhibit 1: 八種 gen AI 風險,其中四種是不論導入與否都會需要考量的
Exhibit 2: 不同的 gen AI 使用情境有不同的風險需要考量
Exhibit 3: 組織可以做 heat map 來衡量各方面的風險重要性
Exhibit 4: gen AI 風險可以在不同的地方做緩解,這裡以 HR 聊天機器人為例
Exhibit 5: 通過 AI 治理在速度與風險管理之間取得平衡

結論: 在擁抱gen AI帶來的巨大潛力時,企業必須同時面對與之相伴的風險。麥肯錫的建議提供了一個實用且系統的框架,幫助企業在探索 gen AI 的無限可能性時,仍能保持負責任與謹慎的態度。考慮到潛在的生產力提升,努力可持續且負責任地擴大 gen AI 的規模對於充分發揮其全部好處至關重要。

Linode VPS 漲價

最近,我收到了 Linode VPS 服務下個月開始的漲價通知,這不是個好消息。上次 lke cluster 升級多收費的事件後,我就決定縮編我的服務,以節省一些開銷。這次剛好又是一個觸發點,不如就降到沒有漲價的 1GB 版本,當然另一方面也是這麼久了發現我似乎也用不到多大的。

以超過複數台 node 的使用量來說,都使用 1GB 的方案看來是省了很多(就是省了漲幅啦)。我仍然繼續使用 Linode 的 VPS 服務,但現在我更加關注資源的使用情況,並更加珍惜每一分每一秒的資源。也不知道哪天什麼火又燒過來,做好一點點準備總是好事。

Helper module to generate JWT for LINE OAuth2 v2.1

LINE Messaging API 最近一個比較重大的變更是 access token 新版的發放方式(v2.1),同時也配合 OAuth2 。比較不同的點是它是用 JSON Web Token (JWT) 去取 access token,這樣的好處是如果今天 Provider 本身(也就是付錢的人)請開發商開發 bot ,他並不需要把 channel secret/access token 都給開發商(這通常也暗示你要把開發人員加到 bot admin 去,當然也可以不這麼做,就是麻煩了點)。

改用 JWT 的好處在於開發商只需要知道 channel ID 以及 Provider 幫他申請的一組 Assertion Signing Key (RSA 加密的),對 Provider 來說資訊的保護層級就提高了,終止合作只要把這組 Assertion Signing Key 砍掉就好,不必重新申請 channel access token 且/或 channel secret。

但相反地,開發商沒有 long-lived channel access token,新版的 OAuth2 認證方式使用 JWT 產生的 access token 最長只有 30 天的限期,期限到了之前要再生,某種程度造成程式開發上的困難(安全與方便通常不是站在同一邊的),原本的邏輯上要多加處理 token expiry 。

對於 API 變動來說,可以分為兩部份來看。其一,是 JWT 的取得;其二,是 access token 的取得。前者並沒有直接呼叫到 LINE Messaging API server ,所以在開發 SDK 的時候,可以先著重在已有 JWT 的情況下與 server 端做申請/列出/撤銷 access token 的行為。這部份也提出了 pull request (PR) 在等待官方團隊的審核。

Web interface for generating JWT

而 JWT 的生成就比較麻煩了,在看官網的介紹時發現做 JWT 沒有想像中那麼容易。(中間省略一段心路歷程)最後就是決定自己開發工具來幫助生成 JWT 。

clsung/line-oauth2-helper 名字有 “OAuth2” ,實則沒有關係,是用來生 JWT 的,但因為這生出來的 JWT 也只能讓 LINE OAuth2 v2.1+ 使用,所以才取這個名子。

執行的方式看 README 即可,若是一般 go 開發者使用,那 go get github.com/clsung/line-oauth2-helper/cmd/line_jwt 最快,若是系統沒有 go 的,可以考慮用 docker 的版本(若是都沒有的,請按上一頁離開):docker pull clsung/line-oauth2-helper:stable

用 line_jwt 執行的話,預設生出來的 JWT 需要在 30 分鐘內去 access LINE server ,而生出來的 access token 會在 30 天後過期,要細部調整的則建議就使用 docker / web 的版本。若是要接在程式碼當 API 呼叫的,也可以參考 cmd/ 下的程式自行開發。

20190628 Chatbots Meetup 10

Evan Lin 邀請,6/28 參與演講了 Chatbots Meetup 10 的第二場,分享如何在 Google Cloud Run 上部署 LINE Bot 的經驗談。(好像拖稿很久了)

因為時間的關係,到天瓏書局時已經開場講到一半啦。就錯過了 Evan LinWrite Image Proxy Server for LINE Bot in Go。就座的時候,LINE API ExpertCaesar Chi 正在介紹 LINE@ 2.0 offline to online ,分享如何透過 LIFF + Push 機制,讓廠商能更有效率的省錢轉換,並且也跟會眾們分享在官方帳號 2.0 轉換後的衍生想法。

接著就是我上台分享 LINE Bot on Cloud Run: 使用 line/line-bot-sdk-go ,本來是想介紹 LINE Bot on GKE ,不過準備的時候發現會需要花點時間講 K8S ,就不好講 LINE Bot 開發了,所以選了一個我也沒用過的 Cloud Run 來試看看。詳情就直接看投影片吧,然後順便把 source code 整理一下放上來

最後閃電講,直接貼共筆的圖好了 :Q 我覺得 Evan Lin講解比較詳細,哈哈,偷懶一下。

重整 Exif 資料

多想幾天,可以不用重新發明輪子。 :p
Read More