RAG對于大型語言模型應用至關重要，它通過檢索相關信息并傳遞給LLM來提高準確性和減少幻覺。大規模RAG面臨擴展挑戰，需要關注可搜索單元定義、檢索策略選擇、排序策略定義以及多個用例的影響，AI搜索平臺需支持自動分塊、高查詢量處理和靈活的索引管道。

譯自：A Blueprint for Implementing RAG at Scale^[1]

作者：Kai Borgen

檢索增強生成（RAG）^[2]對于大多數大型語言模型（LLM）^[3]應用至關重要，因為它將公司特定的信息帶入生成過程中。如果您計劃在您的組織中部署生成式AI^[4]，您幾乎肯定需要RAG。如果做得好，它可以提高準確性，減少幻覺，并讓LLM基于您自己的專有數據進行推理。這個概念聽起來很簡單：找到與用戶查詢相關的信息，并將其傳遞給LLM，以便它可以生成更好的答案。但與往常一樣，細節決定成敗。

生成式AI的興起，尤其是Agentic AI^[5]，正在推動RAG進入更苛刻的企業用例，大型組織面臨著嚴峻的擴展挑戰。大規模的RAG意味著在海量、多樣化的數據集上進行機器速度的檢索，以及檢索和生成之間快速、高效的協調。隨著數據量的增長，保持結果的相關性、新鮮性和速度變得越來越困難（而且成本高昂）。當您同時為大量用戶提供服務，或支持需要執行深度、多步驟研究的多輪代理交互時，更是如此。

解決相關性問題

當您擁有數百萬（如果不是數十億）個文檔，并且需要在十分之一秒內為數千（如果不是數百萬）個用戶提供服務時，您究竟該如何找到最相關的信息？這個任務可以通過逐步細化來簡化：

步驟 1：定義您的可搜索單元

您的可搜索單元（通常稱為“塊”）在RAG中至關重要。它是您將傳遞給LLM的信息單元。您將搜索這些單元，以找到提供給LLM的最佳信息。正確地進行設置會影響檢索準確性、延遲以及最終的LLM響應質量。

這不僅僅是關于token限制；而是關于使塊的大小和結構與用戶將提出的問題類型對齊。例如，事實層面的查詢可能受益于更小、更精確的塊，而更廣泛的或基于推理的查詢可能需要更長的文本跨度來保持上下文。塊應尊重語義邊界，如段落或列表項，并且重疊的窗口可以幫助維持跨中斷的連續性。添加元數據（如來源、章節、日期）也有助于在管道中進行更好的過濾和排序。沒有一刀切的規則——有效的分塊取決于您的內容、查詢模式和規模——因此請將其視為值得測試和調整的設計決策。

步驟 2：選擇您的檢索策略

您的檢索策略決定了您如何找到相關的塊來傳遞給LLM。它是使RAG工作的核心。您應該使用語義、關鍵詞還是混合方法來找到最佳的文檔或塊？哪種嵌入模型適合您的領域？這些決策決定了您的系統理解和呈現相關信息的方式。

語義檢索（使用向量嵌入）擅長捕捉意義，但當精確的術語或領域特定的短語很重要時，像BM25（最佳匹配25）這樣的關鍵詞方法可以在精度上勝過語義檢索。混合搜索——結合兩者——通常可以提供兩全其美的效果。您選擇的嵌入模型也很重要：輕量級模型速度更快，但可能會丟失細微差別，而更大的模型提供更豐富的語義，但成本和延遲更高。檢索不僅僅是找到相關內容——而是以您的應用程序要求的速度和規模這樣做。平衡準確性、吞吐量和成本是關鍵，尤其是當您的用戶（或代理）依賴于跨數十億文檔的快速、可靠的答案時。

步驟 3：定義您的排序策略

排序決定了哪些檢索到的塊被傳遞給LLM以及以什么順序傳遞。這是您在模型開始生成之前提高相關性的第二次機會。一個像樣的RAG解決方案將檢索許多可能有用的文檔，但并非所有文檔都應該顯示給LLM。為了做出這個決定，您需要一種方法來組合不同的評分信號：關鍵詞匹配、語義相似度、元數據過濾器等等。弄清楚如何手動權衡這些信號幾乎是不可能的，尤其是在大規模的情況下。這就是為什么大多數生產就緒的RAG系統使用機器學習排序來根據真實用戶行為或反饋優化質量。多階段排序管道可以通過連續的過濾器和評分器來優化結果，但即使是一個簡單的學習模型也可以顯著改善哪些內容進入提示以及LLM的響應效果。

步驟 4：解決多個用例的影響

RAG系統很少只服務于一種類型的用戶或工作流程。一些查詢來自需要快速、可讀答案的人類用戶；另一些查詢來自AI代理或編排層，它們可以容忍更多的延遲，以換取更深入、更上下文豐富的結果。Agentic 檢索——其中LLM自主執行搜索——具有與人工搜索不同的特征。LLM可以處理更多的上下文，不介意較慢的響應，并且可以按順序發出許多查詢來解決單個任務。設計一個從同一后端為人類和機器提供服務的系統需要在延遲、排序深度和檢索量方面進行權衡。關鍵是要認識到并非所有查詢——或用戶——都是相同的，并且您的架構應該足夠靈活，以便根據調用的用例進行調整。

AI搜索平臺支持

為了支持大規模的復雜RAG工作負載，AI搜索平臺必須做的遠不止基本的關鍵詞或向量匹配。它需要智能地處理海量的、不斷增長的文檔語料庫，包括無法批量傳遞給LLM的非常大的或非結構化的文檔。這意味著支持自動分塊，將大型文檔分解為有意義的、可檢索的單元，并對這些塊以及整個文檔進行排序，以確保僅返回最相關的內容。

該平臺還必須水平擴展以處理高查詢量，即使在負載下也能支持低延遲檢索，并允許頻繁更新內容和排序邏輯，而無需重新索引整個數據集。索引管道應該足夠靈活，可以集成元數據、嵌入和自定義特征，并且速度足夠快，以最小的延遲保持系統的新鮮度。

最終，該平臺必須在性能、準確性和適應性之間取得謹慎的平衡，以便它可以從同一基礎設施為實時、面向用戶的體驗和復雜的agentic工作流程提供服務。

Vespa創建了RAG藍圖^[6]，這是基于我們從大規模部署RAG中學到的經驗。它以免費的Python notebook和示例應用程序的形式提供，更深入地介紹了這些要點的實現，提供了一個動手、模塊化的配方，涵蓋了關鍵的設計決策——如分塊、檢索、機器學習排序和性能調整——這些決策都基于真實的經驗。無論您是剛開始還是正在優化現有的系統，該藍圖都為構建生產就緒、可擴展的RAG應用程序提供了堅實的基礎。

引用鏈接

[1] A Blueprint for Implementing RAG at Scale:https://thenewstack.io/a-blueprint-for-implementing-rag-at-scale/

[2]檢索增強生成（RAG）:https://thenewstack.io/freshen-up-llms-with-retrieval-augmented-generation/

[3]大型語言模型（LLM）:https://thenewstack.io/what-is-a-large-language-model/

[4]生成式AI:https://thenewstack.io/generative-ai-is-just-the-beginning-heres-why-autonomous-ai-is-next/

[5]Agentic AI:https://thenewstack.io/the-architects-guide-to-understanding-agentic-ai/

[6]RAG藍圖:https://vespa.ai/solutions/enterprise-retrieval-augmented-generation/the-rag-blueprint/