生成式人工智慧的出現使我們建構的應用程式具有新的功能成為可能。法學碩士可以以令人難以置信的技巧回答使用者的問題。那麼，為什麼不將它們用作我們系統的一部分呢？如果用戶需要協助使用該應用程式，我們可以加入聊天功能，法學碩士將回答用戶的所有問題。如果我們的應用程式有解釋重要概念的部落格文章，而不是讓用戶閱讀所有內容來獲取所需的知識，它可以只詢問並立即得到回應。
為什麼是拉格？
我們決定將法學碩士整合到我們的應用程式中，為我們的用戶帶來這些功能。然而，我們很快就發現該模型無法回答使用者的問題。它沒有任何關於我們的應用程式的資訊！如果需要回答的資訊不在LLM的訓練資料中，則無法回答。更糟的是，如果它不知道答案，它可能會產生一個完全錯誤的事實的幻覺！這很糟糕，那麼我們該如何解決這個問題呢？採用 Transformer 架構的法學碩士已展現出優異的情境學習能力。因此，我們只需在提示中傳遞它所需的所有事實以及問題即可！呃哦，每次提示都塞滿所有資料肯定會很貴。那麼，我們該怎麼做呢？
什麼是RAG？
RAG 代表檢索增強產生。 RAG與變形金剛一起誕生。最初，它被用來用額外的事實來增強法學碩士的預訓練資料。一旦 Transformers 的情境學習能力變得明顯，在推理過程中增強提示也成為一種常見做法。
基本的 RAG 管道由三個步驟組成：索引、檢索和產生。法學碩士需要回答的所有資訊都在向量資料庫中建立了索引。當使用者提出問題時，我們可以從該向量資料庫中檢索資訊的相關部分。最後，結合相關資訊和使用者的問題，我們可以提示法學碩士根據我們作為上下文提供的資訊給出答案。讓我們更詳細地看看如何實現這一目標。
索引
首先，我們從任何地方提取模型所需的資訊。生成模型使用純文字（某些模型也可以使用圖像或其他格式，這些格式也可以被索引，但這是另一個主題）。如果訊息已經是純文字形式，那麼我們很幸運。但它也可能存在於 PDF 文件、Word 文件、Excel、Markdown 等。
一旦資訊採用文字格式，我們就可以將其儲存在向量資料庫中。向量資料庫將儲存該文字的嵌入表示。這將使我們能夠搜尋與另一個文本具有相似嵌入表示的文本部分，因此它們涉及相似的概念。我們將整個文字分成更小的部分或區塊，計算每個部分的嵌入表示，最後將它們儲存在向量資料庫中。
恢復
當使用者問我們一個問題時，我們可以使用我們用於索引資料的相同嵌入模型將該問題轉換為向量表示。利用該向量表示，我們將計算問題與向量資料庫中儲存的每個區塊之間的相似度因子。我們將選擇與查詢最相似的前 K 個區塊，因此它們的內容與問題的概念相同（因此它們可能包含答案）。
世代
系統會建立一個提示，將使用者的問題和相關上下文放在一起，以幫助 LLM 回答。我們也可能包含用戶和人工智慧助理之間對話的先前訊息。 LLM 根據上下文而不是之前學習的預訓練資料為使用者產生答案。
例子
對於這個例子，我們將收錄一篇名為「蘭格語言模型的檢索增強生成：調查」的論文。我們將使用本文中包含的資訊查詢LLM，以便它可以回答使用者對其內容的疑問。您可以在本文提供的 Google Colab 筆記本中遵循此範例。
首先，我們將載入 PDF 文件並使用 LangChain 的 PyPDF 連接器對其進行解析。
一旦我們從文件中獲得文本，我們就必須將其分割成更小的區塊。我們可以使用 LangChain 的可用分割器，例如本例中的 RecursiveCharacterSplitter：
我們將使用 BGE-small，一種開源嵌入模型。我們將從 HuggingFace Hub 下載它並在所有區塊上執行它以計算它們的向量表示。
一旦我們有了所有區塊的向量表示，我們就可以建立一個記憶體向量資料庫並將所有向量儲存在其中。對於此範例，我們將使用 FAISS 資料庫。
資料庫現已建立。現在，我們將接受用戶對此資訊的查詢。在這種情況下，用戶詢問 Naive RAG 的缺點是什麼。我們使用與先前相同的嵌入模型對該查詢進行編碼。然後，我們檢索與該查詢最相似的前 5 個區塊。
檢索相關上下文後，我們使用此資訊和使用者的原始查詢來建立提示。在這個例子中，我們將使用克勞德的俳句作為法學碩士：
常見問題和陷阱
正如標題所暗示的，該解決方案是一個基本的或簡單的 RAG 實作。它將幫助您的申請充分利用其所使用的法學碩士和您的資料。但它並不適用於所有情況。這些只是 RAG 最常見的問題：
檢索不相關的資訊。如果檢索器從向量資料庫中獲取與問題無關的資料，它將混淆試圖回答問題的模型。這可能會導致不使用上下文來回答問題，或回答與所問內容不同的問題。
錯過重要資訊。也許回答問題所需的資訊不在資料庫中。也許檢索機制無法找到相關的區塊。我們必須找到方法來幫助檢索器輕鬆、更可靠地找到所需的資訊。
產生上下文不支援的回應。如果上下文有模型需要的訊息，但它不使用它而是依賴自己的預訓練資料，那麼這一切都是徒勞的。預訓練資料中的資訊可能已過時或錯誤。我們必須支持模型始終使用上下文來回答，或者如果它無法從上下文中回答，則回答「我不知道」。
對查詢的回應不相關。 LLM 可能會使用您提供的所有資訊來產生回應，但這並不意味著它回答了使用者的問題。重要的是，模型必須堅持使用者的原始問題，而不是迷失在大量資訊中。
相似上下文導致的冗餘響應。當我們攝取具有相似資訊的多個文件時，檢索器有可能會獲得多個幾乎相同的資訊區塊。這可能會導致法學碩士在其回復中多次重複相同的訊息。
如何避免這些問題呢？
為了避免這些問題，簡單的 RAG 管道可能還不夠。我們需要建立一個更先進、更複雜的RAG系統。存在經過測試的技術來解決我們提出的問題。我們可以將它們合併到 RAG 管道中，以提高 RAG 應用程式的效能。
另一個需要解決的重要問題是，為了改進您的 RAG 應用程式，您需要能夠測量和評估整個過程。你無法改進你無法衡量的東西。另外，當您進行評估時，您可能會發現基本的 RAG 設定足以滿足您的用例，並且不需要使其過於複雜。畢竟，即使是非常基本的 RAG 實施也可以極大地改進您的 LLM 支援的應用程式。
在以後的文章中，我將更詳細地解釋先進的 RAG 技術，這將幫助我們避免常見問題並將我們的 RAG 應用程式提升到新的水平。
原文出處：https://dev.to/rogiia/how-to-build-a-basic-rag-app-h9p
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式