前言

經過我們這幾天的努力，我們終於完成了 RAG 系統啦╰(°▽°)╯
雖然這只是一個簡單的 RAG 應用，但我想可能還是有幫助大家更認識 RAG 一點點點吧！

那麼，就讓我們來快速回憶一下這幾天所做的內容吧：

1. 我們在稍微熟悉 RAG 後，開始了資料的準備，這裡要注意的是資料的準備非常重要，掌握了整個 RAG 的成敗！正所謂：**「Garbage in, garbage out.」**所以乾淨的資料是必備良藥！
2. 在準備完資料後我們開始了向量資料庫的準備，向量資料庫是專門存放向量化的資料，提供我們進行儲存和管理。據我所知，比較大的向量資料庫像是：Qdrant 和 FAISS 等等，在我們進行檢索時效果是差不多的～（歡迎大家一起討論）
3. 在準備完向量資料庫後，我們進行了詞嵌入模型的設置，詞嵌入模型是幫助我們將資料進行向量化的模型。不同的詞嵌入模型是會大大影響我們的檢索結果哦！
4. 在準備完詞嵌入模型與向量資料庫後，我們就開始我們的檢索啦～由於我們資料較少且較單純，所以檢索的結果相對理想，這樣就能提供給 LLM 正確的參考資料了
5. 在確認好檢索的效果後，我們就設置了 LLM，並且學習了 Prompt 等內容，還學到了什麼是 Ollama
6. 我們透過 LangChain 串接了所有東西，將檢索的結果與 Prompt 一起傳給了 LLM 後，順利地接到了 LLM 的回覆，最重要的是，LLM 的回覆是正確的！
7. 最後我們將整個 RAG 問答系統透過 Dockerfile 包成了 image，並且推上了 Docker Hub 後，部署上了 Kubernetes～

RAG 的限制

RAG 雖然能夠快速地找到我們要的資料，但還是有很多限制：

1. 繁體中文的困擾：在現在開源的模型中，不管是詞嵌入模型還是 LLM，對於繁體中文都不是很友善，因為他們在訓練模型的時候，都沒有參考太多的繁體中文，大部分都是英文或是簡體中文居多
2. 檢索質量依賴性高：RAG 的生成質量很大程度上依賴於檢索的質量。如果檢索時，無法找到與問題高度相關或正確的信息，即使 LLM 再強，也可能會生成無效或不準確的答案。因此，如何建立高效、精準的檢索系統是挑戰之一
3. 推理能力的局限：RAG 在處理需要高層次推理或複雜邏輯的問題時，可能會遇到瓶頸。雖然它能夠檢索相關信息，但如果問題需要跨多個領域、資料源或需要推理才能得出結論，RAG 的生成部分可能無法充分滿足這些需求。
4. 檢索的範圍：在我們投入大量的資料時，如果詢問整體性的問題，例如：這份資料中總共有幾種 theme？在檢索時，如果只檢索了 5 筆資料，那麼對於 LLM 來說，只會有 5 種 theme 在這份資料中

未來肯定是會有辦法解決上述這些 RAG 限制的方法，甚至是提出更加有效的新方法。
但如果各位有任何想法的話都歡迎討論哦～～～

註:如果有人知道如何用免費的開源工具來讀取檔案表格的方法的話，都可以跟我分享哦(☞ﾟヮﾟ)☞