今天主要介紹RAG當中的最基礎版本，在使用者問題或檢索的過程中都是使用之前所提到的最初概念，文字切段並且向量化；利用cosine similarity來查詢相關資訊；同步傳遞相關資料給LLM去進行回答使用者問題。

圖片來源

1. 使用者的提供的提示詞（可能是對於LLM的角色定義)以及使用者想要解決的問題敘述。在這裡我們的做法是將Prompt包裝成System Prompt的格式去利用API傳送給LLM，主要進行檢索的部分只有Query也就是使用者在輸入框輸入的問題描述。
2. 將Query透過Embedding model之後得到問題的向量表示法，將此向量到知識庫（向量資料庫）當中去搜索出來相關參考資訊。這裡我們使用的是MongoDB。
3. 將相關資訊去包裝好（可能是一串list格式的儲存結構），以利後續融合在System Prompt當中去提供給LLM思考和回答。
4. 這裡的重點就是要將查詢到的資訊內容重新統整好一並傳遞給LLM去做回答。整理的內容包含System Prompt與相關chunks的融合，以及使用者問題設定成User Prompt。
5. LLM閱讀完System+ User Prompt之後，就會回覆一串答覆給聊天機器人。

• 這邊要注意的是如果使用者問題包含程式碼，LLM可能會回傳不是文章形式，其中可能會有程式碼或者包含其他符號的回覆。這算是使用API呼叫LLM的特色，平時我們與ChatGPT的畫面就是已經將非文字的部分通過畫面渲染的結果。

這整個流程算是最初代的RAG，這版RAG看似邏輯完美，但是其實在檢索和提供給LLM的參考資訊都存在一點問題。

例如：

1. 檢索的時候直接將問題的向量去和知識庫中的相關資訊向量去比對？我們能確保問題敘述的語意能直接反映在知識庫中的答案嗎？
2. 在檢索出來的結果中，如果參考資料有時效性，我們能確保參考資料的都是最新的嗎？
3. 我們能確定LLM在閱讀我們提供的參考資料都是完整的閱讀嗎？他會不會只有閱讀一部分資料就去回答使用者的問題？

以上這些問題都是各專家在進行實驗時發現的問題，所以Naive RAG基本上只能說是RAG的Prototype，如果要進行客製化的使用可能會遇到一些問題。因此後續就有Advanced RAG的提出，嘗試去解決這些方面的問題。關於Advanced RAG的解決方案之後也會介紹一些，如果有興趣的同學可以繼續關注。

總結一下今天的內容，主要分享RAG的基礎版本。結合之前的分享，現在我們可以知道為什麼前面分享了MongoDB Atlas的功能和設定。明天將會分享如何使用LangChain模組迅速搭建出結合RAG的聊天機器人後端架構。