2、沒錯，最頂層的還是數據

很明顯，LLM技術棧中最重要的是數據。在a16z的圖中，這是最頂層。「嵌入模型」是LLM的用武之地——你可以從OpenAI、Cohere、Hugging Face或其他幾十種LLM選項中進行選擇，包括越來越流行的開源LLM。

但即使在使用LLM之前，還需要建立一個「數據管道」——它將Databricks和Airflow列為兩個示例，或者可以對數據進行「非結構化」處理。這也適合數據周期，可以幫助企業在將數據輸入自定義LLM之前「清理」或簡單地整理數據。像Alation這樣的「數據智能」公司，就提供這種類型的服務——聽起來，有點像IT技術棧中更為人知的「商業智能」等工具。

數據層的最後一部分則是近期名聲大噪的向量資料庫，來存儲和處理LLM數據。根據微軟的定義，這是「一種將數據存儲為高維向量的資料庫，高維向量是特徵或屬性的數學表示。」數據通過一種名為「embedding」的技術存儲為向量。

領先的向量資料庫供應商Pinecone在一次媒體交談時指出，Pinecone的工具經常與數據管道工具（如Databricks）一起使用。在這種情況下，數據通常位於其他地方（例如，數據湖），然後通過機器學習模型將其轉換為嵌入。在對數據進行處理和分塊後，生成的向量被發送到Pinecone。

3、提示和查詢

接下來的兩層可以概括為提示和查詢——這是人工智慧應用程式與LLM和（可選）其他數據工具接口的地方。A16z將LangChain和LlamaIndex定位為「編排框架」，這意味著開發人員一旦知道自己使用的是哪種LLM，就可以使用這些工具。

根據a16z的說法，像LangChain和LlamaIndex這樣的編排框架「抽象掉了提示連結的許多細節」，這意味著在應用程式和LLM之間查詢和管理數據。這個編排過程包括與外部API接口，從矢量資料庫檢索上下文數據，以及在多個LLM調用中維護內存。a16z圖表中最有趣的方框是「遊樂場」，其中包括OpenAI、nat.dev和Humanloop。

A16z在博客文章中沒有確切定義，但我們可以推斷，「遊樂場」工具可以幫助開發人員施展A16z所說的「提示柔術」。在這些地方，開發人員可以嘗試各種提示技術。

Humanloop是一家英國公司，其平台的一個功能是「協作提示工作區」。它進一步將自己描述為「用於生產LLM功能的完整開發工具包」。因此，基本上，它允許您嘗試LLM的東西，然後將其部署到應用程式中（如果它有效的話）。

4、流水線作業：LLMOps

大模型生產的流水線目前正在逐漸清晰。編排框的右側是許多操作框，包括LLM緩存和驗證。還有一系列與LLM相關的雲和API服務，包括Hugging Face等開放的API存儲庫，以及OpenAI等專有的API提供商。

這可能是我們在「雲原生」時代習慣的開發人員技術棧中最相似的地方，許多DevOps公司將人工智慧添加到了他們的產品列表中，這絕非巧合。5月，我與Harness執行長Jyoti Bansal進行了交談。Harness運行一個「軟體交付平台」，專注於CI/CD流程的「CD」部分。

Bansai告訴我，人工智慧可以減輕軟體交付生命周期中涉及的繁瑣和重複的任務，從基於現有功能生成規範到編寫代碼。此外，他還表示，人工智慧可以自動化代碼審查、漏洞測試、錯誤修復，甚至為構建和部署創建CI/CD管道。根據我在五月份的另一次對話，人工智慧也在改變開發人員的生產力。來自構建自動化工具Gradle的Trisha Gee告訴我，人工智慧可以通過減少重複任務（如編寫樣板代碼）的時間來加速開發，並使開發人員能夠專注於大局，如確保代碼滿足業務需求。

5、Web3涼了，大模型開發棧來了

在新興的LLM開發技術棧中，我們看到了一系列新的產品類型，例如編排框架（LangChain和LlamaIndex）、向量資料庫和Humanloop等「遊樂場」平台。所有這些都擴展和/或補充了這個時代的底層核心技術：大型語言模型。

一如前幾年Spring Cloud、Kubernetes等雲原生時代工具的興起。只不過當下，幾乎所有雲原生時代的大、小、頂流企業都在極力將其工具適應AI工程化，這就會對LLM技術棧的未來發展非常有利。

沒錯，這一次的大模型儼然「站在巨人的肩膀上」，計算機技術中最好的創新總是建立在以前的基礎上。也許這就是「Web3」革命失敗的原因——與其說它是建立在上一代的基礎上，不如說它試圖篡奪它。

很明顯，LLM技術棧似乎做到了，它是從雲開發時代到更新的、基於AI的開發者生態系統的橋樑。

參考連結：https://thenewstack.io/llm-app-ecosystem-whats-new-and-how-cloud-native-is-adapting/