關於構建基於檢索增強生成的聊天機械人的事實

許可證: 原創作品和翻譯作品採用CC BY 4.0許可證。

修改說明: 本頁面的文本已經過AI模型或眾包修改。可能存在錯誤或不準確的解釋。

作者： Rama Akkiraju, Anbang Xu, Deepak Bora, Tan Yu, Lu An, Vishal Seth, Aaditya Shukla, Pritam Gundecha, Hridhay Mehta, Ashwin Jha, Prithvi Raj, Abhinav Balasubramanian, Murali Maram, Guru Muthusamy, Shivakesh Reddy Annepally, Sidney Knowles, Min Du, Nick Burnett, Sean Javiya, Ashok Marannan, Mamta Kumari, Surbhi Jha, Ethan Dereszenski, Anupam Chakraborty, Subhash Ranjan, Amina Terfai, Anoop Surya, Tracey Mercer, Vinodh Kumar Thanigachalam, Tamar Bar, Sanjana Krishnan, Jasmine Jaksic, Nave Algarici, Jacob Liberman, Joey Conway, Sonu Nayyar, 和 Justin Boitano - NVIDIA - rakkiraju, anbangx, dbora@nvidia.com

ArXiv 連結： https://arxiv.org/abs/2407.07858v1

摘要

企業聊天機械人，由生成式人工智能驅動，正在迅速成為該技術在行業中最受關注的初始應用，旨在提高員工生產力。檢索增強生成（RAG）、大型語言模型（LLM）、Langchain/Llamaindex類型的LLM編排框架是構建生成式AI聊天機械人的關鍵技術組件。然而，構建成功的企業聊天機械人並不容易。它們需要對RAG管道進行精細的工程設計。這包括微調語義嵌入和LLM，從向量數據庫中提取相關文檔，重述查詢，重新排序結果，設計有效的提示，遵循文檔訪問控制，提供簡明的響應，包含相關參考，保護個人信息，並構建代理來協調所有這些活動。在本文中，我們基於在NVIDIA構建三個聊天機械人的第一手經驗，提出了一個構建有效RAG聊天機械人的框架：用於IT和HR福利、公司財務收益和一般企業內容的聊天機械人。我們的貢獻有三方面。首先，我們介紹了我們的FACTS框架，用於構建企業級RAG聊天機械人，以解決上述挑戰。FACTS助記符指的是RAG聊天機械人必須正確處理的五個維度——即內容新鮮度（F）、架構（A）、LLM的成本經濟性（C）、測試（T）和安全性（S）。其次，我們提出了RAG管道的十五個控制點以及在每個階段優化聊天機械人性能的技術。最後，我們展示了來自企業數據的實證結果，關於大型LLM與小型LLM之間的準確性-延遲權衡。據我們所知，這是第一篇提供全面視角的論文，涵蓋了構建安全企業級聊天機械人的因素及解決方案。

1 介紹

聊天機械人正日益成為公司中搜索工具的延伸，用於查找相關信息。無論是人力資源福利、IT幫助、銷售查詢還是工程問題，企業聊天機械人現在已成為首選的生產力工具。在OpenAI的Chat-GPT於2022年11月推出之前，公司依賴於基於對話流的內部開發聊天機械人。這些機械人需要廣泛的訓練以理解意圖，並需要精心編排以生成響應，但最多只能提供提取式答案。這些早期的機械人建立在對話管理系統之上，結合信息檢索和問答（IRQA）解決方案，功能脆弱且能力有限。雖然以前的語言模型和GPT模型已經存在，但它們缺乏廣泛企業使用所需的準確性、穩健性和可靠性。

Chat-GPT 的發佈、向量數據庫的出現以及檢索增強生成（RAGs）的廣泛使用（8）標誌着聊天機械人領域新時代的開始。現在，大型語言模型（LLMs）可以通過自然語言中的簡單提示理解用戶意圖，消除了複雜意圖變體訓練的需求，能夠連貫地合成企業內容，從而賦予聊天機械人超越腳本化意圖識別的對話能力。雖然 LLMs 通過其生成能力構建連貫、真實和邏輯的用戶查詢響應，但由向量數據庫驅動的信息檢索（IR）系統增強了 LLMs 檢索新鮮內容的能力。像 LangChain（1）和 Llamaindex（9）這樣的工具促進了聊天機械人的構建，並協調包括記憶、代理、提示模板和整體流程在內的複雜工作流。向量搜索為基礎的 IR 系統、LLMs 和類似 LangChain 的框架共同構成了 RAG 管道的核心組件，並在後 Chat-GPT 時代推動了生成式 AI 聊天機械人的發展。

聊天機械人	領域	數據來源	數據類型	訪問控制	示例查詢	狀態
NVInfo Bot	企業內部知識	SharePoint, GoogleDrive, Slack, Confluence, ServiceNow, Jira 等	文檔, HTML, PDF, 幻燈片	是	我可以在總部停車場過夜嗎？	早期訪問測試
NVHelp Bot	IT 幫助, 人力資源福利	IT 幫助知識文章, 人力資源福利頁面	文本, PDF, 文檔	是	如何註冊員工股票購買計劃？	生產
Scout Bot	財務收益	公司新聞, 博客, SEC 文件, 收益相關採訪	HTML, PDF, 文檔	否	NVIDIA 過去三年的收入是多少？	生產

在NVIDIA，我們的主要動機是通過構建企業聊天機械人來提高員工的生產力。我們的初始熱情很快就遇到了許多挑戰的現實。我們了解到，即使在Chat-GPT時代之後，打造一個成功的企業聊天機械人雖然充滿希望，但並不容易。這個過程需要精心設計RAG管道、微調LLM和工程提示，確保企業知識的相關性和準確性，遵守文檔訪問控制權限，提供簡潔的回答，包括相關的參考資料，並保護個人信息。所有這些都需要精心設計、熟練執行和徹底評估，要求進行多次迭代。此外，在優化速度和成本效益的同時保持用戶參與度也是至關重要的。在我們的旅程中，我們了解到，打造一個完美的企業對話虛擬助手就像實現一場完美的交響樂，每一個音符都具有重要意義！

在本文中，我們分享了構建高效、安全且成本效益高的聊天機械人的經驗和策略。我們從實踐者的角度回答以下問題：

"在構建和部署企業級生成式AI聊天機械人時需要考慮的關鍵挑戰是什麼？" 我們展示了在嘗試提供新鮮內容（F）、靈活架構（A）、成本效益（C）、良好測試（T）和安全性（S）方面的發現——（FACTS）。

如何通過RAG系統在構建聊天機械人時實現用戶可接受的質量水平？我們介紹了RAG管道的十五個控制點，以及優化每個控制點和整體RAG管道的技術。

2 個案例研究

我們公司的內容領域包括權威知識和非權威內容。權威內容包括 IT 幫助文章、ServiceNow 等平台上的人力資源資源，以及 Confluence、SharePoint、Google Drive 和 NVBugs、GitHub 等工程工具上的項目文檔。員工生成的內容在 Slack 和 MS Teams 等平台上補充了這些來源。在本文中，我們介紹了 NVIDIA 使用 RAGs 和 LLMs 構建的三個機械人。以下是對這三個機械人的簡要介紹。所有三個機械人都基於我們內部構建的生成式 AI 聊天機械人平台 NVBot 平台構建。我們的機械人能夠回答的一些查詢顯示在表 1 中。

• NVInfo Bot 回答有關企業內容的問題（大約 5 億份文件，大小約為 7 TB），補充了內聯網搜索。它管理多種數據格式並實施文檔訪問控制。技術棧包括 LangChain、用於檢索和處理文檔訪問控制的供應商向量數據庫、LLM 模型（可以選擇多個 LLM 模型）以及自定義的 Web 用戶界面。

• NVHelp Bot 專注於IT幫助和人力資源福利（大約2000個多模態文檔，包含文本、表格、圖像、PDF和HTML頁面），使用與NVInfo bot相似的技術棧，但數據量較小。

• Scout Bot 處理來自公共來源的財務收益問題，管理結構化和非結構化數據（大約 4K 多模態文檔，包含文本、表格、PDF 和 HTML 頁面）。技術棧包括開源向量數據庫、LangChain、Ragas 評估、可選擇的 LLM 模型和自定義網頁用戶界面。

在本文的其餘部分中，我們將介紹我們的FACTS框架，該框架總結了在構建上述三個聊天機械人過程中遇到的挑戰和獲得的經驗。我們首先從處理在每個聊天機械人中提供最新企業內容的挑戰開始。

圖1. 構建聊天機械人時典型RAG管道中的控制點。

3 確保 LLM 驅動的聊天機械人中的企業數據新鮮度 (F)

確保企業數據在基於LLM的聊天機械人中保持新鮮性面臨諸多挑戰。儘管基礎模型功能強大，但由於缺乏特定領域和企業特定的知識，它們往往顯得不足。一旦訓練完成，這些模型基本上就被凍結在某個時間點，可能會出現幻覺，在使用未經過訓練的企業內容時提供不需要或不準確的信息。

檢索增強生成（RAG）是一種通過語義匹配從向量數據庫中檢索相關信息，然後將其提供給大型語言模型（LLM）以生成響應的過程。在RAG管道中，向量數據庫和LLM協作確保提供最新的企業知識。然而，RAG管道有許多控制點，如果調校不當，可能導致聊天機械人準確性下降、幻覺和不相關的響應。此外，文檔訪問控制權限使搜索和檢索過程複雜化，需要仔細管理以確保數據安全性和相關性。此外，多模態內容需要使用多模態檢索器來處理結構化、非結構化和半結構化數據，包括演示文稿、圖表、視頻和會議記錄。解決這些挑戰對於保持企業聊天機械人的準確性和可靠性至關重要。受（3）的啟發，我們從案例研究中識別出RAG的十五個控制點，如圖1所示。每個控制點都標有一個編號。在本節的其餘部分，我們將介紹我們在解決RAG控制點方面的見解和經驗。

3.1 學習心得

在圖4中，我們展示了RAG管道的十五個控制點的概要描述、每個控制點相關的挑戰以及我們建議的優化方法。每個控制點分別標記為RAG-C[num]和RAG-Op[num]，用於RAG和RAGOps流程。下面，我們介紹了一些管理新企業內容的關鍵學習和見解。

元數據增強、分塊、查詢重述、查詢重排序：我們注意到，RAG管道中的元數據增強、分塊、查詢重述和查詢重排序階段對聊天機械人響應的質量影響最大。LLM響應生成質量高度依賴於檢索相關性。而檢索相關性又高度依賴於文檔元數據增強、分塊和查詢重述。我們實施了基於網格搜索的自動機器學習功能，以找到合適的分塊令牌大小配置，嘗試了各種提示變體，並探索了不同的分塊重排序策略，以找到每個階段的最佳設置。雖然我們在檢索相關性和答案質量及準確性方面取得了顯著的改進，但我們相信，仍需進一步優化整個管道。

"混合搜索"：我們注意到，向量數據庫在處理匹配實體（例如人名、地名、公司名稱等）方面表現不佳。結合詞彙搜索（例如，彈性搜索）和向量搜索可以提供更好的檢索相關性和更廣的覆蓋範圍。建立支持混合搜索功能的基礎設施，結合詞彙和向量搜索的優勢，可以提高檢索過程的準確性和速度。

圖2. 處理複雜查詢的代理架構

「代理架構」：諸如「比較NVIDIA在2024財年第一季度至第四季度的收入，並對導致此期間收入變化的關鍵因素進行分析評論」這樣的問題，需要能夠進行查詢分解和協調的複雜代理。圖2展示了我們在Scout機械人中實施的一種機制，用於處理此類問題。通過構建這三個機械人的經驗，我們意識到信息檢索系統和大型語言模型不足以回答覆雜查詢。需要複雜的代理和多代理架構來處理複雜查詢。

是否微調大型語言模型（LLMs）？這是一個關鍵決策，涉及在使用基礎模型與領域特定定製之間的平衡。對於LLMs來說，沒有一種通用的解決方案。一些用例可能適合使用基礎模型，而另一些則需要定製。在考慮定製時，有多種選擇，包括提示工程、P-tuning、參數高效微調（PEFT）和完全微調（FT）。微調需要在數據標註、訓練和評估方面進行大量投資，這些過程都可能耗時且成本高昂。自動化測試和質量評估過程對於確保在定製LLMs時的效率和準確性至關重要。圖3展示了我們在NVHelp bot領域的約245個查詢中，比較OpenAI的GPT-4模型與一些開源模型的準確性與延遲權衡評估。我們的結果顯示，Llama3-70B模型在保持可接受延遲的同時，在多個方面的答案質量上表現出色。

圖3. NVHelp答案質量和延遲指標在不同模型中的比較

處理多模態數據：企業數據是多模態的。處理結構化、非結構化和多模態數據對於多功能的RAG管道至關重要。根據我們的經驗，如果文檔的結構是一致且已知的（例如在金融收益領域中Scout bot處理的SEC文件數據的EDGAR數據庫中找到的那些），實施基於章節的分割，使用章節標題和副標題，並將其納入塊的上下文中，可以提高檢索的相關性。我們還發現像Unstructured.io這樣的解決方案在從PDF中提取和結構化內容方面很有幫助，這對於解析和分塊具有上下文的非結構化文檔非常有用。

RAGOps：一旦 RAG 管道部署後，進行有效的健康監測至關重要。當答案質量較差時，需要進行徹底的錯誤分析，以確定問題是出在檢索相關性還是 LLM 響應生成上。為了調試檢索相關性，開發人員需要詳細了解哪些數據塊存儲在向量數據庫中及其相關元數據，查詢是如何被重新措辭的，哪些數據塊被檢索到，以及這些數據塊是如何被排序的。同樣地，如果 LLM 響應不正確，審查用於生成答案的最終提示至關重要。對於引用問題，開發人員必須追溯到原始文檔連結及其對應的數據塊。RAGOps/LLMOps 和評估框架（如 Ragas）對於提供必要的自動化至關重要，以便在 RAG 管道的準確性改進周期中實現快速迭代。

有關每個控制點的更多詳細信息，請參見圖 4。總之，儘管前景可期，但在聊天機械人中實施RAG系統需要精心規劃和持續評估，以確保數據檢索的安全性和準確性。

圖4. RAG控制點、挑戰和補救措施

圖5. 偵察機械人：多部分查詢

圖6. NVHelp Bot：回答有關人力資源福利的問題

為生成式AI聊天機械人構建靈活架構 (A)

跟上人工智能的快速進展就像在快速流動的河流中航行。從向量數據庫和嵌入模型到大型語言模型（LLM）、代理架構、低代碼/無代碼平台、RAG評估框架和提示技術，每個方面都在迅速發展。同時，公司內部的各個部門正在通過構建自己的聊天機械人和AI助手來探索生成式人工智能。

在這個動態環境中，構建通用、靈活和適應性強的平台至關重要。在NVIDIA，我們的聊天機械人生態系統顯著增長，這反映了許多公司可能看到的趨勢。從最初構建三個聊天機械人開始，我們意識到建立一個通用平台的重要性，以避免在安全性、防護措施、身份驗證、提示、用戶界面、反饋機制、使用報告、監控和評估方面的重複工作。

為了解決這個問題，我們開發了 NVBot 平台（圖 7），這是一個具有可插拔架構的模塊化平台。它允許開發人員選擇最適合其用例的 LLM、向量數據庫、嵌入模型、代理和 RAG 評估框架。它還提供了安全性、護欄、身份驗證、授權、用戶體驗和監控等基本功能的通用組件。此外，該平台支持公民開發，允許多個團隊貢獻他們經過測試的提示、工作流程、護欄和微調模型以供集體使用。

隨着我們的機械人生態系統不斷擴展，我們面臨一個關鍵問題：組織應該構建多個特定領域的機械人、一個企業級機械人，還是採用混合方法？特定領域的聊天機械人在定製環境中表現出色，而企業級聊天機械人則作為通才，為所有員工提供一個集中的知識庫。通過我們的經驗，我們意識到不需要在兩者之間做出選擇。

新型的架構模式正在出現，其中企業範圍內的聊天機械人充當「交換機」的角色，將查詢引導至調校有特定領域數據的專業機械人。這種多機械人架構允許專業聊天機械人的並行開發，同時為用戶提供統一的界面。我們的NVBot平台支持企業內多個聊天機械人的共存和協調。關於單一機械人還是多個專業機械人的爭論仍在繼續。我們設想一個領域特定機械人與集中信息機械人共存的場景，並由「副駕駛」支持——將生成式AI能力集成到編程IDE和協作工具等工作環境中。在NVIDIA，我們正在積極探索這三種聊天機械人變體——領域特定、企業範圍和副駕駛，因為生成式AI正在重塑工作場所的效率和信息獲取方式。

圖7. NVBot平台架構，多個聊天機械人正在其上構建。

5 聊天機械人部署的成本經濟學 (C)

了解生成式人工智能聊天機械人的成本經濟學涉及多個關鍵因素。主要和商業大型語言模型（LLM）的高成本可能難以維持，因為在多個使用案例中費用會顯著增加。此外，隨着團隊測試各種LLM以滿足特定需求，未見的費用往往會累積。此外，在使用商業LLM供應商API時，保護敏感企業數據需要設置防護措施，以檢測和防止敏感數據泄漏，並設置審計和法律允許的學習網關。還需要考慮成本與延遲的權衡，因為具有長上下文長度的大型LLM通常響應時間較慢，影響整體效率。

《大模型與小模型》：大型商業LLM和小型開源LLM在許多用例中越來越具有可行性，從而為公司提供了具有成本效益的替代方案。隨着開源模型逐漸趕上大型商業模型，它們在準確性上越來越接近，如我們在NVHelp機械人實證評估中的圖3所示，並且通常在延遲性能上優於大型模型。此外，GPU優化的推理模型可以進一步加快處理時間。例如，使用NVIDIA的Tensor RT-LLM推理庫優化的開源模型，性能比未優化的模型更快。這些策略有助於在保持高性能和安全標準的同時，平衡成本效益的需求。

LLM 網關: 如果您必須使用供應商的 LLM API，最好在公司內部實施一個 LLM 網關，以便在整個公司進行審計、訂閱和成本管理。實施內部公司 LLM 網關可以簡化 LLM 的使用、訂閱和數據跟蹤，以便進行安全審計。這個中央樞紐簡化了管理，並確保了資源的高效分配。在 NVIDIA IT，我們實施了一個 LLM 網關，用於記錄入站和出站的負載以進行審計，並通過訪問控制權限保護這些數據。我們的 LLM 網關有助於管理 LLM API 調用的訂閱和成本。

總之，制定混合且平衡的LLM策略對於管理成本和推動創新至關重要。這涉及使用較小且定製化的LLM來控制開支，同時通過LLM網關進行負責任的大型LLM探索。通過跟蹤LLM訂閱和成本，以及評估生成式AI功能的使用和生產力提升，來衡量和監控投資回報率至關重要。確保在雲端使用LLM時企業敏感數據的安全，需要實施防護措施以防止數據泄漏，並建立LLM網關以進行審計和法律允許的學習。最後，要注意成本、準確性和延遲之間的權衡，通過定製較小的LLM來匹配較大模型的準確性，同時注意到具有長上下文長度的大型LLM往往響應時間較長。

6 測試基於RAG的聊天機械人 (T)

由於需要人工響應驗證，測試生成式人工智能解決方案可能是一個漫長的過程。越來越多地使用「LLM-as-a-judge」方法來應用大型語言模型。然而，建議在將大型語言模型作為人類代理時要謹慎，因為將大型語言模型作為評判者可能導致自我實現預言類型的情景，從而在評估中強化其固有的偏見。

• 安全測試： 自動化安全測試對於在不影響安全性的情況下保持開發速度至關重要。一個強大的安全框架和回歸測試數據集確保聊天機械人能夠抵禦潛在威脅。我們正在與內部的 RED 安全團隊合作，準備一套數據集，以便在聊天機械人的每次重大迭代中進行測試。

• 提示更改測試：生成式AI模型對提示更改非常敏感。為了保持準確性，每次提示更改都需要進行全面的回歸測試。

• 反饋循環： 結合收集到的反饋和RLHF循環對於持續改進至關重要。它使得LLM模型能夠隨着時間的推移不斷優化我們的解決方案和語言模型，確保聊天機械人變得越來越熟練。然而，如果所選擇的基礎模型不提供定製化，那麼就很難將模型與人類反饋對齊。如果反饋在多個領域中顯著且廣泛，那麼模型定製可能是一個選項。目前，我們已經開始收集用戶反饋，但尚未使用RLHF構建我們的持續學習管道。擁有能夠實現自動化的工具對於這些聊天機械人的後期生產生命周期管理至關重要。

6.1 學習心得

"長測試周期計劃"：有效測試基於RAG的聊天機械人需要預見到漫長的測試周期。首先，專注於自動化測試和提高準確性評估，以簡化這一關鍵階段。

構建代表性真實數據集：構建全面的真實數據集至關重要，這些數據集反映了目標解決方案強度的全方位。這確保了聊天機械人在實際使用中會遇到的場景中得到測試。

自動化評估：雖然利用大型語言模型（LLM）作為評估者可以提供可擴展的測試選項，但請記住，人類評估的質量是無可比擬的。自動化工具應在可行的情況下用於補充，而不是取代人類的監督。

結合人類反饋和持續學習：建立允許人類反饋和系統性錯誤分析的機制。優先根據這些反饋進行迭代改進，以不斷優化聊天機械人的性能和適應性。

7 基於RAG的聊天機械人安全性 (S)

在部署生成式 AI 聊天機械人時，建立信任至關重要。為了降低風險，防止幻覺、毒性、公平性、透明性和安全性等問題的防護措施是關鍵。強大的基礎模型在這些防護措施上越來越好。然而，仍然存在許多越獄、對抗性攻擊和其他安全問題的可能性。除了這些安全風險之外，基於生成式 AI 的聊天機械人還容易受到衍生風險（如下所述）的影響。由於我們的機械人都是內部企業聊天機械人，我們更關注企業內容安全和敏感數據的防護。以下是我們基於經驗總結的關於保護基於 RAG 的聊天機械人的學習和見解。解決這些挑戰對於維護企業環境中基於 RAG 的聊天機械人的完整性和安全性至關重要。

7.1 學習心得

企業內容訪問控制：企業文檔受到訪問控制的保護，要求基於RAG的聊天機械人在生成響應時遵循訪問控制列表（ACL）。為了確保這種合規性，我們特別選擇了一款以有效遵循這些文檔ACL而聞名的IR產品。

生成式人工智能的衍生風險：聊天機械人可能會生成缺乏原始數據來源上下文的響應，從而可能導致誤解。此外，如果企業內容未得到適當保護，增強的搜索方法可能會無意中增加暴露敏感數據的風險。作為我們NVInfo機械人旅程的一部分，我們除了利用我們使用的向量搜索解決方案提供的敏感數據過濾和分類功能來在檢索過程中自動過濾掉敏感數據外，還實施了敏感數據防護措施。

數據治理和內容安全：高效的知識訪問可能會增加敏感數據泄露的風險。因此，在部署之前優先考慮數據治理，以防止未經授權的訪問和數據泄露是至關重要的。在NVIDIA，我們啟動了一項企業內容安全計劃，用於文檔敏感性分類和從聊天機械人中排除敏感內容。

企業護欄：實施與特定企業政策和規則相一致的護欄對於生成式AI響應至關重要。這些護欄通過確保聊天機械人生成的內容遵循既定的規範和道德準則來幫助降低風險，從而防止潛在的法律和聲譽損害。在NVInfo機械人中，我們最初在LLM提示中實施了許多護欄。然而，後來意識到並非所有LLM都能始終如一地遵循這些提示。因此，我們在查詢和響應的前後處理中分別使用Nemo Guardrails（13）實施了這些護欄。

8 相關工作

我們的工作可以與RAG論文進行比較，這些論文涉及我們所提出的所有FACTS維度（新鮮度、架構、成本、測試和安全性）的RAG質量。由於篇幅限制，我們選擇性地對比了一些工作。Barnett等人（3）在工程RAG系統時提出了七個失敗點。在他們的工作中，他們通過展示構建三個聊天機械人的經驗，強調了正確實現檢索增強生成的挑戰。Wenqi Glantz（6）詳細闡述了12個RAG痛點並提出了解決方案。在構建我們的聊天機械人時，我們也親身經歷了類似的挑戰。然而，這些工作都沒有討論複雜查詢、測試、處理文檔安全性以及靈活架構需求的挑戰。在我們的工作中，我們不僅基於上述RAG的失敗/痛點，還提出了RAG管道中的15個控制點，並為每個階段提供了具體的解決方案。此外，我們擴展了我們的見解，提出了處理複雜查詢、測試和安全性的實用技術。我們為複雜查詢處理的代理架構實現之一提供了參考架構，提出了測試和評估主觀查詢響應的策略，並提高了處理文檔ACL和安全性的意識。此外，我們還為基於生成式AI的靈活聊天機械人平台提供了參考架構。

ChipNemo（10）提供了使用領域適應語言模型來提高RAG在特定領域問題上的表現的證據。他們對e5-small-unsupervised模型進行了微調，使用了3,000個領域特定的自動生成樣本。我們嘗試在Scout Bot中微調e5-large嵌入模型。我們的結果沒有顯示出顯著的改進。目前，我們正在收集高質量的人類注釋數據以重複實驗。這可能是我們未來工作中值得探索的重要方向。Setty et. al.（15）提出了另一種有趣的技術，即使用假設文檔嵌入（HYDE）技術來提高RAG性能。HyDE在響應查詢時使用LLM生成理論文檔，然後對原始問題和假設答案進行相似性搜索。這是一種有前途的方法，但可能會使架構變得複雜。

主動檢索增強生成（FLARE）（7）迭代合成假設的下一句。如果生成的句子包含低概率的詞彙，FLARE將使用該句子作為新的檢索查詢並重新生成句子。Mialon et al.（12）回顧了語言模型中高級增強生成方法的相關工作。Self-refine（11）構建了一個代理，通過迭代反饋和改進來提升RAG的初始答案。ReAct（16）代理被廣泛用於以遞歸方式處理複雜查詢。在RAG評估方面，RAGAS（4）和ARES（14）利用LLM作為評判者，並建立自動RAG基準來評估RAG系統。Zhu et al.（17）概述了LLM在RAG流程中的密集使用，包括檢索器、數據生成、重寫器和閱讀器。我們相信，通過我們的FACTS框架，我們的工作為構建安全的企業級聊天機械人提供了獨特的視角。

9 結論

在本文中，我們介紹了開發有效的基於RAG的聊天機械人的方法，重點介紹了我們在NVIDIA構建三個聊天機械人的經驗。我們概述了我們的FACTS框架，強調了內容新鮮度（F）、架構（A）、LLM成本（C）管理、測試計劃（T）和安全性（S）在創建穩健、安全和企業級聊天機械人中的重要性。我們還識別並詳細說明了RAG管道中的十五個關鍵控制點，提供了在每個階段增強聊天機械人性能的策略。此外，我們的實證分析揭示了在比較大型和小型LLM時準確性和延遲之間的權衡。本文提供了關於構建安全高效的企業級聊天機械人的基本因素和實用解決方案的整體視角，為該領域做出了獨特貢獻。在多個領域仍需進行更多工作以構建有效的基於RAG的聊天機械人。這包括開發用於處理複雜、多部分和分析查詢的代理架構；高效總結大量頻繁更新的企業數據；結合自動機器學習功能以自動優化各種RAG控制點；以及創建更穩健的評估框架以評估主觀響應和對話。

參考文獻

• (1) Langchain. https://github.com/langchain-ai.
• (2) Achiam, J., Adler, S., Agarwal, S., Ahmad, L., Akkaya, I., Aleman, F. L., Almeida, D., Altenschmidt, J., Altman, S., Anadkat, S., et al. GPT-4 technical report. arXiv preprint arXiv:2303.08774 (2023).
• (3) Barnett, S., Kurniawan, S., Thudumu, S., Brannelly, Z., and Abdelrazek, M. Seven failure points when engineering a retrieval augmented generation system. arXiv preprint arXiv:2401.05856 (2024).
• (4) Es, S., James, J., Espinosa-Anke, L., and Schockaert, S. Ragas: Automated evaluation of retrieval augmented generation. arXiv preprint arXiv:2309.15217 (2023).
• (5) Galitsky, B. Developing enterprise chatbots. Springer, 2019.
• (6) Glantz, W. 12 rag pain points and proposed solutions.
• (7) Jiang, Z., Xu, F. F., Gao, L., Sun, Z., Liu, Q., Dwivedi-Yu, J., Yang, Y., Callan, J., and Neubig, G. Active retrieval augmented generation. arXiv preprint arXiv:2305.06983 (2023).
• (8) Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-t., Rocktäschel, T., et al. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in Neural Information Processing Systems 33 (2020), 9459–9474.
• (9) Liu, J. LlamaIndex. https://github.com/jerryjliu/llama_index(2022).
• (10) Liu, M., Ene, T.-D., Kirby, R., Cheng, C., Pinckney, N., Liang, R., Alben, J., Anand, H., Banerjee, S., Bayraktaroglu, I., et al. Chipnemo: Domain-adapted llms for chip design. arXiv preprint arXiv:2311.00176 (2023).
• (11) Madaan, A., Tandon, N., Gupta, P., Hallinan, S., Gao, L., Wiegreffe, S., Alon, U., Dziri, N., Prabhumoye, S., Yang, Y., et al. Self-refine: Iterative refinement with self-feedback. Advances in Neural Information Processing Systems 36 (2024).
• (12) Mialon, G., Dessì, R., Lomeli, M., Nalmpantis, C., Pasunuru, R., Raileanu, R., Rozière, B., Schick, T., Dwivedi-Yu, J., Celikyilmaz, A., et al. Augmented language models: a survey. arXiv preprint arXiv:2302.07842 (2023).
• (13) Rebedea, T., Dinu, R., Sreedhar, M., Parisien, C., and Cohen, J. Nemo guardrails: A toolkit for controllable and safe llm applications with programmable rails. arXiv preprint arXiv:2310.10501 (2023).
• (14) Saad-Falcon, J., Khattab, O., Potts, C., and Zaharia, M. Ares: An automated evaluation framework for retrieval-augmented generation systems. arXiv preprint arXiv:2311.09476 (2023).
• (15) Setty, S., Jijo, K., Chung, E., and Vidra, N. Improving retrieval for rag based question answering models on financial documents. arXiv preprint arXiv:2404.07221 (2024).
• (16) Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. React: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629 (2022).
• (17) Zhu, Y., Yuan, H., Wang, S., Liu, J., Liu, W., Deng, C., Dou, Z., and Wen, J.-R. Large language models for information retrieval: A survey. arXiv preprint arXiv:2308.07107 (2023).