提升 Airbnb 房源列表: GPT-4o Mini 與 Anthropic 的 3.5 Sonnet 在代理 RAG 中

探索 GPT-4o Mini 與 Anthropic 3.5 Sonnet 在為 Airbnb 房源描述創建代理人方面的表現。了解如何設置實用的數據集、嵌入和使用 Llama Index 和 VectorDB 的代理 RAG 管道。在這個全面的比較中,發現每個模型的優勢和局限性。

2025年2月15日

party-gif

探索 OpenAI 最新的 GPT-4o Mini 模型在為 Agentic RAG(一種強大的信息檢索技術)創建代理方面的表現。本博客文章提供了與 Anthropic Cloud 3.5 Sonnet 模型的實際比較,使用真實世界的 Airbnb 數據集來展示每個模型在代理工作流程中的功能和局限性。

介紹 GPT-4o Mini:一個具成本效益的代理 RAG 模型

GPT-4o Mini是OpenAI最新推出的最具成本效益的模型,也是其價格範圍內表現最佳的模型之一。然而,問題仍然存在:這個模型在創建代理人,特別是代理性檢索增強生成(RAG)方面的表現如何?

在這一部分,我們將探討GPT-4o Mini的表現,並與Anthropic Cloud 3.5 Sonnet模型進行比較,後者是代理性RAG的熱門選擇。我們將使用實際數據集 - MongoDB上的Airbnb嵌入數據集,來測試這些模型的功能。

該數據集包含各種元數據列,我們將對數據進行預處理,以創建適合RAG管道的輸入。我們將使用Llama Index來設置RAG實現,利用其代理功能。

對於LLM或代理人,我們將使用GPT-4o Mini和Cloud 3.5 Sonnet,對於VectorDB,我們將依賴ChromaDB。我們將介紹設置過程,包括安裝所需的庫、設置環境變量以及配置LLM和嵌入模型。

設置環境後,我們將深入研究數據加載和處理步驟,在此過程中,我們將創建RAG管道所需的數據結構。這包括將數據轉換為pandas DataFrame,刪除現有的文本嵌入,並創建元數據模板以用於嵌入過程。

最後,我們將使用ChromaDB設置向量存儲,並定義可供代理使用的查詢引擎工具。然後,我們將創建代理工作者,並使用聊天功能與之交互,比較GPT-4o Mini和Cloud 3.5 Sonnet在代理性RAG任務中的表現。

通過本節的學習,您將更好地了解GPT-4o Mini在代理性RAG背景下的功能,以及它與更強大的Cloud 3.5 Sonnet模型的比較。

設置環境和數據

要開始,我們首先需要設置所需的庫和環境變量。我們將安裝必要的軟件包,包括Llama Index、OpenAI和ChromaDB。

接下來,我們將配置環境變量,包括OpenAI API密鑰和Hugging Face令牌(如果需要)。

然後,我們將設置LLM(語言模型)和嵌入模型。對於LLM,我們將使用GPT-4 OM Mini模型。對於嵌入,我們將使用OpenAI TextEmbedding3 small模型,它允許我們自定義嵌入大小,以減少計算和存儲成本。

設置模型後,我們將轉移到數據加載和處理。我們將使用來自MongoDB的Airbnb嵌入數據集,專注於前2,000個數據點,以保持處理時間和成本可控。

我們將刪除現有的文本嵌入,並使用OpenAI嵌入創建自己的嵌入向量。我們還將從數據集中提取相關的元數據,如列表名稱、摘要、房屋規則、房產類型、房間類型以及臥室和床的數量。這些元數據將用於豐富LLM在檢索過程中看到的文本。

為了準備數據以供向量存儲使用,我們將文本分割為5,000個字符的塊,並創建包含文本、嵌入向量和元數據的節點。最後,我們將設置ChromaDB向量存儲來存儲這些節點,這將用作代理性RAG(檢索增強生成)工作流的知識庫。

嵌入 Airbnb 數據集

要嵌入Airbnb數據集,我們首先將數據集轉換為JSON文檔列表。然後,我們創建一個元數據模板,包括重要信息,如Airbnb列表的名稱、摘要、房屋規則、房產類型、房間類型、臥室類型、臥室數量和床位數。這些元數據將添加到要嵌入的文本中。

接下來,我們將文本分割為5,000個字符的塊,以確保每個嵌入向量都可以捕捉相關信息。然後,我們使用OpenAI TextEmbedding3 small模型計算嵌入,該模型允許我們自定義嵌入大小,以減少計算和存儲成本。

計算嵌入後,我們將它們存儲在ChromaDB向量存儲中,該存儲將作為我們代理的知識庫。我們創建了一個QueryEngineToolClass,它將為代理提供對向量存儲的訪問權限,允許它根據用戶的查詢檢索最相關的文本塊。

通過對數據進行預處理、創建元數據模板和設置向量存儲,我們已經為使用Llama Index代理做好了準備。這個過程確保了代理可以訪問必要的信息,以向用戶提供準確和有意義的響應。

創建向量存儲和查詢引擎工具

要開始,我們首先需要設置所需的庫和環境變量。我們將安裝必要的軟件包,包括Llama Index、ChromaDB和OpenAI模型。

接下來,我們將設置LLM和嵌入模型。對於LLM,我們將使用GPT-4 OM Mini模型,對於嵌入,我們將使用OpenAI TextEmbedding3 small模型。

然後,我們將加載和預處理Airbnb數據集,刪除現有的文本嵌入,並創建自己的包含元數據的文本塊。這些塊將被嵌入並存儲在ChromaDB向量存儲中。

為了創建查詢引擎工具,我們將使用Llama Index的QueryEngine工具類,它將提供對向量存儲的訪問,並允許我們檢索給定查詢的前k個最相似的塊。我們將將此工具定義為代理知識庫的一部分。

最後,我們將創建代理工作者,它將LLM和查詢引擎工具結合在一起,使我們能夠與代理互動並檢索最佳的Airbnb列表。

這個過程的關鍵步驟是:

  1. 設置所需的庫和環境變量。
  2. 配置LLM和嵌入模型。
  3. 加載和預處理Airbnb數據集。
  4. 使用ChromaDB創建向量存儲。
  5. 定義查詢引擎工具並將其添加到代理的知識庫中。
  6. 通過結合LLM和查詢引擎工具創建代理工作者。

通過這些步驟,我們已經建立了必要的基礎設施,可以使用GPT-4 OM Mini模型進行代理性RAG任務,並應用於Airbnb數據集。

實現代理工作者

要創建代理工作者,我們首先定義可供代理使用的工具。在本例中,我們使用Llama Index的QueryEngineToolV2類,它提供對我們之前創建的向量存儲的訪問。

query_engine_tool = QueryEngineToolV2(
    "Knowledge base",
    "Provides information about Airbnb listings and reviews, use a detailed plain text question as input to the tool.",
    self.vector_store
)
tools = [query_engine_tool]

接下來,我們使用Llama Index的FunctionCallingAgentWorker類創建代理工作者。我們為代理工作者提供工具列表和語言模型(在本例中為GPT-4 Mini)。

agent_worker = FunctionCallingAgentWorker(
    tools,
    self.llm,
    verbose=True
)
self.agent = agent_worker

現在,我們可以使用代理的chat函數與之交互。我們可以為代理提供提示,它將使用工具生成響應。

prompt = "Tell me the best listing for a place in New York."
result = self.agent.chat(prompt)
print(result)

代理的響應將包括思考過程和最終答案。在本例中,GPT-4 Mini代理的響應不如Anthropic 3.5 Sonnet代理的響應詳細或有洞見。

為了進行比較,我們也可以嘗試不同的提示,如"What is the worst Airbnb listing in Miami?"。Anthropic 3.5 Sonnet代理提供了更周到和細緻的響應,承認了知識庫的局限性,並提供了關於紐約和邁阿密度假租賃差異的一般見解。

總的來說,使用Llama Index實現代理工作者是straightforward的,但代理的性能取決於底層語言模型的功能。Anthropic 3.5 Sonnet模型似乎更適合代理工作流,而GPT-4 Mini模型則不太適合。

比較 GPT-4o Mini 和 Cloud 3.5 Sonnet 作為代理

在這一部分,我們比較了GPT-4o Mini和Cloud 3.5 Sonnet作為代理在使用Airbnb嵌入數據集的實際代理性RAG(檢索增強生成)工作流中的表現。

主要發現如下:

  1. GPT-4o Mini作為代理: 儘管GPT-4o Mini是一個強大的模型,但它在代理工作流中表現不佳。該模型的思維過程表達不清,響應也缺乏預期的詳細程度和準確性。

  2. Cloud 3.5 Sonnet作為代理: 相比之下,Cloud 3.5 Sonnet在代理角色中表現出色。它能有效地重寫提示,使用知識庫工具收集相關信息,並提供詳細和準確的響應,即使知識庫沒有關於所請求主題的具體信息。

  3. 強大LLM對代理工作流的重要性: 這一比較突出了使用更強大和更能勝任的LLM(如Cloud 3.5 Sonnet)進行代理工作流的重要性。代理理解上下文、重寫提示和生成高質量響應的能力對於有效完成任務和與用戶互動至關重要。

總之,雖然GPT-4o Mini是一個具有成本效益的模型,但它可能不是代理工作流的最佳選擇。相反,Cloud 3.5 Sonnet在這種用例中表現出色,展示了在基於代理的應用程序中使用更強大LLM的好處。

結論

GPT-4o Mini和Anthropic的Cloud 3.5 Sonnet在代理性RAG(檢索增強生成)任務中的比較突出了模型功能在代理工作流中的重要性。雖然GPT-4o Mini是一個強大且具有成本效益的模型,但它在代理方面的表現不佳,這從其簡單的提示重寫和較少詳細的響應中可以看出。

相比之下,Anthropic Cloud 3.5 Sonnet模型展示了更強大和更複雜的代理行為。它能夠有效地重寫提示,從知識庫中收集相關信息,並提供詳細和有洞見的響應,即使面對的是數據集中不存在的位置的查詢。

這一比較突出了在設計基於代理的工作流時,仔細考慮模型功能的必要性。雖然GPT-4o Mini可能適用於某些任務,但更複雜的代理應用可能需要使用更強大和專門的模型,如Anthropic Cloud 3.5 Sonnet,才能達到所需的性能和用戶體驗水平。

常問問題