首頁  >  文章  >  web前端  >  在 Fastly 上使用 AI 建立「為您」推薦!

在 Fastly 上使用 AI 建立「為您」推薦!

王林
王林原創
2024-08-07 21:54:53993瀏覽

忘掉炒作吧;人工智慧在哪裡創造真正的價值?讓我們利用邊緣運算來運用人工智慧的力量,打造快速、安全、可靠的智慧型使用者體驗。

推薦無所不在,每個人都知道,讓網路體驗更加個人化可以使其更具吸引力和成功。 我的亞馬遜首頁知道我喜歡家居用品、廚具,現在還喜歡夏季服裝:

Build

如今,大多數平台都讓您在快速或個人化之間做出選擇。在 Fastly,我們認為您和您的用戶應該同時擁有兩者。 如果您的網頁伺服器每次產生頁面時,它只適合一個最終用戶,您就無法從快取中受益,而這正是像 Fastly 這樣的邊緣網路所擅長的。

那麼如何從邊緣快取中受益,同時使內容個人化? 我們之前寫過很多關於如何將複雜的客戶端請求分解為多個較小的、可緩存的後端請求的文章,您可以在我們的開發人員中心的個性化主題中找到教程、程式碼範例和演示。

但是如果您想更進一步並在邊緣產生個人化資料怎麼辦? 「邊緣」-處理您網站流量的 Fastly 伺服器,是距離最終用戶最近的點,且仍在您的控制範圍內。一個製作特定於某個使用者的內容的好地方。

「為你」用例

產品推薦本質上是短暫的,特定於單一用戶,並且可能會經常變化。 但它們也不需要持續存在——我們通常不需要知道我們向每個人推薦了什麼,只需要知道特定演算法是否比其他演算法實現了更好的轉換。 一些推薦演算法需要存取大量狀態數據,例如哪些用戶與您最相似以及他們的購買或評分歷史記錄,但通常這些數據很容易批量預生成。

基本上,產生推薦通常不會建立事務,不需要在資料儲存中加任何鎖,並且會利用目前使用者工作階段中立即可用的輸入資料或在離線建置過程中建立的輸入資料。

聽起來我們可以在邊緣產生推薦!

一個現實世界的例子

我們來看看紐約大都會藝術博物館的網站:

Build

大都會博物館收藏的 50 萬件左右的藏品中,每一件都有一個包含圖片和相關資訊的頁面。 它還具有相關對象的列表:

Build

這似乎使用了相當簡單的分面系統來產生這些關係,向我展示同一藝術家的其他藝術品,或博物館同一翼中的其他物體,或者也是由紙製成或源自同一翼的其他物體時間段。

這個系統的好處(從開發人員的角度來看!)是,由於它僅基於一個輸入對象,因此可以預先生成到頁面中。

如果我們想透過基於最終用戶瀏覽大都會網站時的個人瀏覽歷史記錄(而不僅僅是基於這個物件)的一系列推薦來增強這一點,該怎麼辦?

添加個人化推薦

我們可以透過很多方法來做到這一點,但我想嘗試使用語言模型,因為人工智慧正在正在發生,而且它與大都會現有的相關藝術品機制似乎非常不同工作。 計劃如下:

  1. 下載大都會博物館的開放取用收藏資料集。
  2. 透過語言模型運行它以建立向量嵌入 - 適合機器學習任務的數字清單。
  3. 為生成的 50 萬個向量(代表大都會藝術博物館的藝術品)建立一個高性能相似性搜尋引擎,並將其加載到 KV 儲存中,以便我們可以從 Fastly Compute 中使用它。

完成所有這些後,當您瀏覽大都會博物館的網站時,我們應該能夠:

  1. 在 cookie 中追蹤您造訪過的藝術品。
  2. 找出這些藝術品對應的向量。
  3. 計算代表您的瀏覽興趣的平均向量。
  4. 將其插入我們的相似性搜尋引擎以找到最相似的藝術品。
  5. 從 Met 的物件 API 加載有關這些藝術品的詳細信息,並透過個人化推薦來增強頁面。

瞧,個人化推薦:

Build

好的,讓我們來分解一下。

建立資料集

Met 的原始資料集是一個包含很多列的 CSV,如下所示:

Object Number,Is Highlight,Is Timeline Work,Is Public Domain,Object ID,Gallery Number,Department,AccessionYear,Object Name,Title,Culture,Period,Dynasty,Reign,Portfolio,Constituent ID,Artist Role,Artist Prefix,Artist Display Name,Artist Display Bio,Artist Suffix,Artist Alpha Sort,Artist Nationality,Artist Begin Date,Artist End Date,Artist Gender,Artist ULAN URL,Artist Wikidata URL,Object Date,Object Begin Date,Object End Date,Medium,Dimensions,Credit Line,Geography Type,City,State,County,Country,Region,Subregion,Locale,Locus,Excavation,River,Classification,Rights and Reproduction,Link Resource,Object Wikidata URL,Metadata Date,Repository,Tags,Tags AAT URL,Tags Wikidata URL
1979.486.1,False,False,False,1,,The American Wing,1979,Coin,One-dollar Liberty Head Coin,,,,,,16429,Maker," ",James Barton Longacre,"American, Delaware County, Pennsylvania 1794–1869 Philadelphia, Pennsylvania"," ","Longacre, James Barton",American,1794      ,1869      ,,http://vocab.getty.edu/page/ulan/500011409,https://www.wikidata.org/wiki/Q3806459,1853,1853,1853,Gold,Dimensions unavailable,"Gift of Heinz L. Stoppelmann, 1979",,,,,,,,,,,,,,http://www.metmuseum.org/art/collection/search/1,,,"Metropolitan Museum of Art, New York, NY",,,
1980.264.5,False,False,False,2,,The American Wing,1980,Coin,Ten-dollar Liberty Head Coin,,,,,,107,Maker," ",Christian Gobrecht,1785–1844," ","Gobrecht, Christian",American,1785      ,1844      ,,http://vocab.getty.edu/page/ulan/500077295,https://www.wikidata.org/wiki/Q5109648,1901,1901,1901,Gold,Dimensions unavailable,"Gift of Heinz L. Stoppelmann, 1980",,,,,,,,,,,,,,http://www.metmuseum.org/art/collection/search/2,,,"Metropolitan Museum of Art, New York, NY",,,

很簡單,可以轉換為兩列,一個 ID 和一個字串:

id,description
1,"One-dollar Liberty Head Coin; Type: Coin; Artist: James Barton Longacre; Medium: Gold; Date: 1853; Credit: Gift of Heinz L. Stoppelmann, 1979"
2,"Ten-dollar Liberty Head Coin; Type: Coin; Artist: Christian Gobrecht; Medium: Gold; Date: 1901; Credit: Gift of Heinz L. Stoppelmann, 1980"
3,"Two-and-a-Half Dollar Coin; Type: Coin; Medium: Gold; Date: 1927; Credit: Gift of C. Ruxton Love Jr., 1967"

現在我們可以使用 Hugging Face AI 工具集中的 Transformer 包,並產生每個描述的嵌入。 我們使用sentence-transformers/all-MiniLM-L12-v2模型,並使用主成分分析(PCA)將結果向量減少到5維度。 這會給你類似的東西:

[
  {
    "id": 1,
    "vector": [ -0.005544120445847511, -0.030924081802368164, 0.008597176522016525, 0.20186401903629303, 0.0578165128827095 ]
  },
  {
    "id": 2,
    "vector": [ -0.005544120445847511, -0.030924081802368164, 0.008597176522016525, 0.20186401903629303, 0.0578165128827095 ]
  },
  …
]

我們有 50 萬個這樣的資料集,因此不可能將整個資料集儲存在邊緣應用程式的記憶體中。 我們希望對這些資料進行自訂類型的相似性搜索,這是傳統鍵值儲存所不提供的。由於我們正在建立即時體驗,因此我們也確實希望避免一次搜尋 50 萬個向量。

那麼,讓我們對資料進行分區。 我們可以使用 KMeans 聚類對彼此相似的向量進行分組。 我們將資料分成 500 個不同大小的簇,並為每個簇計算一個稱為「質心向量」的中心點。 如果您以二維方式繪製此向量空間並放大,它可能看起來有點像這樣:

Build

紅十字是每個向量簇的數學中心點,稱為質心。它們可以像我們 50 萬向量空間的尋路器一樣運作。例如,如果我們想找到與給定向量A 最相似的10 個向量,我們可以先尋找最近的質心(在500 個質心中),然後僅在其相應的簇內進行搜索——這是一個更易於管理的區域!

現在我們有 500 個小資料集和一個將質心點對應到相關資料集的索引。 接下來,為了實現即時效能,我們想要預先編譯搜尋圖,這樣我們就不需要在執行時間初始化和建構它們,並且可以使用盡可能少的CPU時間。 一種非常快速的最近鄰演算法是分層可導航小世界(HNSW),它有一個純 Rust 實現,我們用它來編寫我們的邊緣應用程式。 因此,我們編寫了一個小型獨立 Rust 應用程式來為每個資料集建立 HNSW 圖結構,然後使用 bincode 將實例化結構的記憶體匯出到二進位 blob。

現在,這些二進位 blob 可以載入到 KV 儲存中,針對叢集索引進行鍵控,並且叢集索引可以包含在我們的邊緣應用程式中。

這種架構允許我們按需將部分搜尋索引載入到記憶體中。而且由於我們永遠不需要一次搜尋超過幾千個向量,因此我們的搜尋將始終廉價且快速。

建立邊緣應用程式

我們在邊緣運行的應用程式需要處理多種類型的請求:

  • HTML 頁面: 我們從 metmuseum.org 獲取這些頁面並轉換回應以添加額外的前端 <script>和<風格>標籤,這樣我們就可以注入一些我們自己的前端處理和內容</script>
  • 這些額外標籤引用的 Fastly 腳本和樣式資源,我們可以直接從邊緣應用程式的二進位提供這些資源。
  • 推薦端點,產生並回傳推薦 ** 所有其他(非 HTML)請求: 圖片以及大都會藝術博物館自己的腳本和樣式表,我們直接從其網域代理,無需更改。

我們最初用 JavaScript 建立了這個應用程序,但最終將推薦部分移植到 Rust,因為我們喜歡即時距離的 HNSW 實現。

客戶端 JavaScript 做了一些有趣的事:

  1. 使用 IntersectionObserver,當使用者將頁面向下捲動到相關物件部分時,我們會觸發一個事件。這是一個超級有效率的 API,比使用 onscroll 等舊方法要好得多。
  2. 取得我們的特別推薦 API 端點(然後我們可以在邊緣處理並傳回物件資訊)
  3. 使用客戶端函數內建的範本來寫一些 HTML
  4. 將該 HTML 附加到頁面並將交叉觀察器移至新元素,以便當您捲動建議時,我們會不斷加載更多內容。

這樣,我們可以在不調用我們的推薦演算法的情況下提供主要的HTML 有效負載,但推薦的提供速度足夠快,我們可以在您滾動時加載它們,並且當您到達它們時它們幾乎肯定會在那裡。

我喜歡以這種方式做事,因為盡快向使用者提供第一個首屏視圖絕對是最重要的。 除非滾動才能看到的任何內容都可以稍後加載,特別是如果它是複雜的個性化內容 - 如果用戶不打算滾動,則生成它是沒有意義的。

結束語

因此,現在您擁有兩全其美的優勢:能夠提供高度個人化的內容,幾乎不需要對來源進行任何阻塞提取,並且經過優化的HTML 有效負載的渲染速度非常快,使您的應用程式能夠有效地享受無限的可擴展性和近乎完美的性能。完美的恢復能力。

這不是一個完美的解決方案。 如果Fastly 提供更多更高級別的功能來透過查詢機製而不是簡單的鍵查找來公開邊緣資料(讓我們知道這是否對您有幫助!),並且這種特定機制有明顯的缺陷- 如果我對以下方面有單獨的興趣兩個或更多非常不同的東西(比如19 世紀的油畫和古羅馬雙耳瓶)我會得到建議,這將是這些之間的理論語義“中間點”,而不是一個非常有用的結果。

不過,希望這證明了一個原則,即弄清楚如何在邊緣進行工作通常會在可擴展性、性能和彈性方面帶來巨大的好處。

讓我們知道您在community.fastly.com 上建立了什麼!

以上是在 Fastly 上使用 AI 建立「為您」推薦!的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn