大型玩家的擴展技巧正變得越來越重要，這導致了架構反轉的激增。

譯自Architecture Inversion: Scale by Moving Computation, Not Data，作者 Jon Bratseth。

你是否曾經想過，世界上最大的互聯網和社交媒體公司是如何如此快速地向如此多的用戶提供算法內容的？

想想像 TikTok 這樣的公司需要做些什么才能為人們提供源源不斷的個性化視頻片段。他們擁有某個模型來代表用戶，他們需要使用這個模型從數十億個備選視頻中找到最適合向特定用戶展示的視頻片段。而且，由于他們也有數十億用戶，他們需要每秒進行數百萬次這樣的操作。

傳統解決方案

解決 TikTok 問題的簡單方法是將用戶模型與每個視頻片段進行比較，以確定每個視頻片段與該用戶的匹配程度。眾所周知，這種蠻力方法無法擴展——對于十億個視頻和每秒一百萬個請求，這將變成每秒一千萬億次比較！

對此的明顯解決方案是索引：維護一個數據結構，使之能夠從用戶模型中找到合適的視頻片段，而無需考慮每個片段。例如，如果用戶模型注意到對英語視頻的偏好，則可以將視頻與 B 樹索引，該 B 樹直接指向英語視頻，以便可以忽略其余視頻。或者，如果用戶表示為興趣向量嵌入，則可以使用向量索引（如分層可導航小世界 (HNSW) 算法）來查找具有相似向量的視頻，而無需考慮其余視頻。

實際系統將使用這些索引的組合。現在，索引只提供關于哪些視頻可能適合用戶的粗略指示。為了真正呈現用戶發現最有趣或最有用的內容，你需要在用戶模型和每個候選項目之間進行更準確的比較——如今通常使用神經網絡來完成。這就是事情變得有趣的地方。

不影響質量的擴展

重新評分的常見方法是將從索引中檢索到的候選項目傳遞給架構中的另一個組件，該組件執行每個項目的詳細評分。應該以這種方式重新評分多少個項目？這應該是所有候選項目的一定比例。

要了解這一點，請考慮索引檢索加上重新評分是對所有候選項目的蠻力評分的近似值，我們需要考慮的是這種優化帶來的質量損失。這可以用給定視頻（如果使用蠻力評估將顯示給用戶）出現在要重新排序的集合中的概率來表示。

隨著該集合相對于候選項目完整集合的大小變小，該概率趨于零。隨著要重新評分的比例減小，質量損失會變大，并且隨著完整評分算法的改進，質量損失也會變大，因為有更多東西要失去。

讓我們具體一點，假設我們想要重新評分 1% 的候選項目，并且每個項目包含 2kb 的對最終評分有用的數據（大約一個向量和一百個屬性）。對于十億個項目，這意味著每個請求需要重新評分 1000 萬個項目，而對于每秒一百萬個請求，這意味著我們需要每秒移動 20 PB 的數據進行重新排序！即使是這個小比例也顯然離可行性很遠，那么大型公司在做什么呢？

答案是他們沒有將數據移動到評分計算節點，而是將評分計算移動到索引中，以便在數據所在的位置本地執行，從而繞過了整個問題。

架構反轉即將到來

現在，為什么我們其他人應該關心這個問題，因為我們很幸運地沒有像 TikTok、Google 等公司那樣擁有數十億用戶？許多因素變得越來越重要：

• ML 算法正在改進，本地計算能力也在提高，這意味著完全評分項目比以前更能提高質量和最終利潤。
• 隨著向量嵌入的出現，此類算法消耗的信號數量增加了 1 到 2 個數量級，使得網絡瓶頸更加嚴重。
• 使用越來越多的數據來解決問題越來越具有成本效益，這意味著需要重新評分更多數據以保持恒定的質量損失。
• 隨著此類系統數據的消費者從主要為人類轉變為主要為 LLM，RAG 解決方案，它在比以前更多的應用程序中更快地提供大量評分數據方面變得有利。這將最終導致大多數應用程序都與向 LLM 提供高質量數據以進行長鏈推理有關，從而以非人速度做出高質量的業務決策。

出于這些原因，最大玩家的擴展技巧對于我們其他人來說變得越來越重要，這導致了當前的架構反轉的激增，從傳統的兩層系統（其中數據從搜索引擎或數據庫中查找并發送到無狀態計算層）轉變為將該計算插入數據本身。

現在，要真正做到這一點，您還需要一個能夠實際管理您的數據的平臺，以這種方式對數據進行索引和計算。這導致了Vespa.ai的普及，該平臺最初是雅虎在還是大型玩家之一時用于架構反轉的解決方案。該技術后來開源了。

Vespa.ai 允許您將結構化數據、向量/張量和全文一起存儲和索引在任意數量的機器上，并在數據存儲的本地執行任何類型的張量計算和機器學習推理。