2023 re:Invent 用 PartyRock 10 分鐘構建你的 AI 應用

發表於2024-02-26

前言

一年一度的亞馬遜雲科技的 re:Invent 可謂是全球雲端計算、科技圈的狂歡,每次都能帶來一些最前沿的方向標,這次也不例外。在看完一些 keynote 和介紹之後,我也去親自體驗了一些最近釋出的內容。其中讓我感受最深刻的無疑是 PartyRock 了。PartyRock 真的算是做到了:能讓任何人快速的構建一個屬於自己的 AI 應用。當然,本文最後也分享我對於其他在 re:Invent 上提到的一些看法和思考。

那麼,不多說,先來看看今天的主角 PartyRock。

亞馬遜雲科技開發者社群為開發者們提供全球的開發技術資源。這裡有技術文件、開發案例、技術專欄、培訓影片、活動與競賽等。幫助中國開發者對接世界最前沿技術,觀點,和專案,並將中國優秀開發者或技術推薦給全球雲社群。如果你還沒有關注/收藏,看到這裡請一定不要匆匆劃過,點這裡讓它成為你的技術寶庫!

PartyRock 簡介

Everyone can build AI apps.

去年到今年 AI 相關的應用層出不窮,GEN AI 已經太多了。到目前為止,其實我本人已經有點審美疲勞了,因為該看的都看的差不多了,所以說實話體驗之前,我並沒有對 PartyRock 帶有很大期望,最多是體驗完了之後厚臉皮來一句 “不過如此”。結果體驗完成之後發現我說的是:

image.png

使用體驗

下面我就用我自己製作的兩個應用和一個官方的應用來說明一下它的使用體驗。

構建第一個應用 - 選詞填空

製作的過程其實非常簡單,幾乎 10 分鐘就搞定了。

步驟 1
點選建立應用之後,在它給出的輸入框裡面輸入你想要做的應用的功能描述,比如說,我最近在學英語,我第一想法就是做個選詞填空的應用出來,於是我就在 App builder 的輸入框裡面輸入如下的內容,然後點選 Generate app 就開始生成了。

image.png

步驟 2
根據生成的內容,你自己按需求修改一下描述和內容,這裡最後下方的答案輸入部分我做了一些提示詞的修改,其他我也就沒動了。

image.png

步驟 3
然後就可以測試一下了,在第一個框 ( Words to choose from ) 輸入一些單詞,在右邊 ( Sentences ) 就會生成對應的題目。

image.png

然後你可以在下面 ( Answer ) 作答並驗證答案是否正確。

image.png

整個過程,需要我動腦的地方就是在想我應該如何描述我的應用,實際生成的效果很不錯,我很滿意。

構建第二個應用 - 擴寫生成圖片

第一個應用我們是依賴的 AI 直接幫我們生成的,雖然很簡單,但是對於我們開發者來說,與其去想描述,不如直接動手來的快。於是這次我們從零開始(選擇 “ Start from an empty app ” 選項),自己搭建一個應用試試看。這次我想試試有關於圖片生成的能力,對於 AI 生成圖片來說最麻煩的是寫描述詞,於是我想讓 AI 先幫我擴寫,然後再利用擴寫的內容去生成圖片。

步驟 1
第一步新增 widget ,其實我們在上面看到的一個輸入框就是一個 widget ,目前 PartyRock 提供了下面幾種可以使用的 widget 。

image.png

我們需要 3 個 widget,一個使用者輸入 ( User Input ) ,一個文字生成 ( Text Generation ) ,一個圖片生成 ( Image Generation ) 。

image.png

步驟 2
然後,我們就需要編寫 AI 生成的提示詞了,點選每個 widget 右上角的編輯,就可以輸入對應的提示詞,還可以選擇不同的模型。其中最重要的是,你可以使用 @ 符合直接引用其他 widget 生成的內容,比如,我需要根據使用者輸入的內容進行擴寫,那麼我在提示詞裡面就可以直接引用使用者輸入的部分;比如,我想根據擴寫的內容生成圖片,我就可以利用 “ @Description ” 引用擴寫的內容。如下圖 Prompt 中高亮的部分。

image.png

步驟 3
測試一下,下圖就是我輸入的一句描述,經過擴寫最後生成了圖片,當然模型不同最後效果也不一樣。

image.png

此時你就可以釋出你的應用了。

ChatRPG

讓我覺得最巧妙的一個應用,是官方給出的 ChatRPG 。這個應用利用了 AI 對話的功能來完成了一個對話形式的 RPG 遊戲,你可以透過對話的形式選擇不同的路徑 ( A B C ) 來獲得不同的結局,並且最為巧妙的是,它利用了幾個 AI 的聯動,整個 RPG 的過程會生成不同的場景圖片,讓整個遊戲的過程更加有了帶入感覺。

image.png

精妙的地方

說完了體驗,來說說 PartyRock 精妙的地方。

  1. AI build AI : 第一點我覺得妙的地方是自舉,也就是自己構建自己,利用 AI 的能力去構建 AI 應用本身。一方面體現 AI 本身的能力強大,另一方面讓也大大降低了入門的門檻,讓小白使用者也能快速上手。
  2. remix:PartyRock 提供了 remix 的功能,你可以直接複製( remix )一個別人已經發布的應用,直接修改裡面的引數或者提示詞來完成你的應用。這無疑是最快的建立應用的一種方式了。
  3. 引用變數:這我覺得是 PartyRock 的靈魂,透過@引用其他 AI 完成的工作,從而實現不同 AI 之間的聯動。你甚至可以透過這樣的方式構建一個自己的工作流,讓 AI 進行協作,讓需要來回對話好幾次的事情一步到位。現在提供的 widget 還比較少,我覺得隨著後面的更新,當 widget 有很多的時候會碰撞出更多的火花。同時,這也給我們提供了一個不同 AI 之間協作的一個不錯思路,我覺得這樣的思路帶給我的思考比產品本身還有意思。

其他產品

當然,這次 re:Invent 提到了其他很多的產品和思考,這裡就對其中幾個我非常感興趣的產品談談我的拙見。

Serverless

我關注最多的一定是 serverless ,我一直都覺得 serverless 一直一種對開發友好也對運維友好的結局方案。而這次 re:Invent 釋出的 Amazon ElastiCache Serverless 讓我也有了新的思考。Amazon ElastiCache Serverless 是根據應用程式流量模式自動的擴充套件容量的快取服務,而對於快取這樣的熱點資料來說,有過實際業務場景的同學都知道如果 Redis 突然記憶體滿了是一種什麼樣的體驗。而 ElastiCache 的自適應壓力的工作負載模式可以很好的解決這個問題,而且相容 Redis。

產品本身的意義很大,而帶給我的思考是,在未來是否當 serverless 足夠成熟之後是否會出現一直資料來源的集合產品,自動會根據資料的訪問情況來自動路由到對應合理的儲存模式中呢?比如,熱點資料會自動路由到 cache 而平常資料路由到 mysql,而冷資料當到達 “冰點” 時自動歸檔以減少消耗?而對於上層應用來說使用完全透明?當然裡面的問題很多,不過我覺得隨著 serverless 的發展或許這也是可以想象的。

AI

Amazon Bedrock 、Amazon CodeWhisperer 和 Amazon Q 是這次 re:Invent 提到有關 AI 的一些產品。比如本文提到的 PartyRock 應該就是建立在 Amazon Bedrock 之上的。當然,我也第一時間去試用了一下 Amazon CodeWhisperer 和 Amazon Q ,不過給我的感覺還沒有那麼的驚豔,或許是還在 beta 階段,智慧程度一般,相信體驗過的小夥伴感受也差不多。而且由於目前支援的開發語言還不多(我常用的 golang 還沒有)。

不過,re:Invent 上一直強調了另一個有關 AI 的關鍵點就是,安全。“ 生成式 AI 一定應該是安全的 ”。這裡的安全有兩個方面,一方面是生成的內容一定應該是安全的,不能出現違法的內容;另一方面是作為模型基礎的訓練資料應該是安全的。比如,企業內部基於自己內部程式碼和資料來建立的模型,進行使用,對應的資料不應該被公開或者出現在別的人生成內容中。所以,安全應該是未來 AI 前進的基石。

我在體驗 PartyRock 的時候也發現了下面的提示,如果出現不安全的單詞,圖片是不會生成的:

image.png

THE FRUGAL ARCHITECT

亞馬遜 CTO Werner Vogels 博士今年在 re:Invent 上的主題演講提到了 THE FRUGAL ARCHITECT(節儉/節制架構)。提到了成本應該在架構設計之初就應該被考慮進去,並且一直作為一個考量指標。

去年到今年一個詞在國內大廠一直被提及 “降本增效”,結果最近演變成為了 “降本增笑”。是的,由於成本的縮減,往往帶來的就是服務的不穩定,這是所有工程師都不想見到的。我就想到之前聽到一個說法是,如果一個併發問題能透過加伺服器來解決,那麼領導會更願意透過加伺服器來解決而不是重構程式碼,因為養開發的成本往往高於伺服器。而我也經歷過一次 k8s 的降本,雖然有時候確實是因為 request 設定的不合理導致的成本超標,但實際改起來的時候真的是心驚肉跳,因為你真的不知道這個服務的併發明天會不會就坐火箭。所以,成本、安全、效能 一直都是一種權衡(trade off),用流行的話說就是 “並不是我不知道兩地三中心安全,而是單中心更有價效比😭”。

其實,有時候並不是不考慮,而是無法預估流量的大小,誰都也無法預測你的應用什麼時候會火。所以亞馬遜雲科技提供的 Lambda,ElastiCache 都是那種按成本去設計的。而對於上雲來說最大的一個問題就是成本不可控,隨著服務的型別越來越多,並且很多服務都是按量付費,預算與實際往往會有比較大的差異。所以,最讓我感興趣的是,這次 Werner Vogels 提到的 Management Console 內可以展示應用級別的成本,之前我們可能只能知道某個使用的服務成本很貴,而現在我們能知道具體那個應用在使用的成本最大。這種觀測能力對於使用者來說是更加友好的,我能最大程度的去觀測我的應用成本的佔比,從而精準的控制我的成本,而不是盲目的去找壓力。

總之,在我認為 THE FRUGAL ARCHITECT ,給我的思考是你必須有能力去時刻關注成本,無法觀測的系統將導致無法估量的成本

總結

最後總結一下,這次 re:Invent 不僅給我們展示了一些最新的應用和服務,更多的給我們帶來了一些亞馬遜雲科技對於最新技術方向的一些思考,接觸這些前沿技術給我的架構解決方案又多了一些積累,相信明年的大會也會一樣精彩。

文章來源:https://dev.amazoncloud.cn/column/article/658965055d096603bb1...

相關文章