全端 LLM 應用開發-Day22-Retrieval-Augmented Generation (RAG)

為什麼只有 embedding 是不夠的？

我們談了十幾天的 embedding 與向量資料庫，但其實在 LLM 應用開發中，光是只有 embedding 是不夠的。Embedding 最大的限制就是找的僅僅是相似度，是向量空間中問題和文本的相似度。

只找相似度，會有什麼問題呢？像我們這幾天的案例，問題是「工程師寫城市」，而搜索到最相似的答案是「而我，在這座城市遺失了你，順便遺失了自己，以為荒唐到底會有捷徑。而我，在這座城市失去了你，輸給慾望高漲的自己，不是你，過分的感情」。然而，這個問題和搜索到的答案，只是因為含有「城市」這個詞造成的。實際上，這個問題和答案根本是不相關的。

基於這個原因，僅依賴 embeddings 進行資訊檢索或問答等任務可能不是最佳的選擇。於是Retrieval-Augmented Generation (RAG) 被發明出來了。

RAG 的方法是首先使用 embeddings 這類的資訊檢索技術找出最相似的文本。然後，它將查詢與從向量資料庫中檢索到的文檔或句子一起作為上下文提供給生成模型。接著，它依賴先進的語言模型（例如 ChatGPT）來生成答案。現代的生成模型，如 GPT 或 BERT，可以理解複雜的語境。因此即使某些高相似度但與問題不相關的文本被檢索出來，現代的語言模型也能有機會辨識並忽略它，只從真正相關的部分生成答案。

通過這種方法，RAG 結合了 embeddings 的快速檢索能力和先進語言模型的語義理解能力，確保給使用者提供更加精確和語義豐富的答案。

為什麼不 fine tune 模型？

在做 computer vision 的年代，我們會用 fine tune 的技巧，把自己的資料餵給 CNN（Convolutional Neural Networks），fine tune 模型而得到一個新的模型。而且準確度往往很容易做得很高，細心調整的話，達到 90%以上往往不是一件難事。但是在 LLM 的時代就不太一樣了，如果我們使用 fine tune 的技巧來把自己想要的資料訓練進去，例如說員工手冊等，效果往往不盡人意。也因此才發展出使用 RAG 的手法。那麼在什麼情況下 fine tune 是會比較好的呢？Open AI 給出下列的情境，大家可以參考看看。

1. 提高可操控性： fine-tune 使模型更好地遵循指示，例如使輸出簡潔或始終以特定語言回應。舉例來說，開發人員可以使用 fine-tune 來確保模型在使用德語時總是以德語回應。

2. 可靠的輸出格式： fine-tune 改善了模型始終以一致的格式進行回應的能力，這對於需要特定響應格式的應用程式（例如幫忙寫程式碼，或構構 API 呼叫）至關重要。開發人員可以使用 fine-tune 更可靠地將用戶提示轉換為高品質的 JSON 片段，可與其自己的系統一起使用。

3. 自定義語氣： fine-tune 是用來調整模型輸出的質感，例如語氣，使其更符合企業品牌的聲音。有著可識別品牌聲音的企業可以使用 fine-tune 使模型的語氣更加一致。

如果你的需求是讀企業內部的文件來做問答，例如說員工手冊、請假規則等的，就不建議使用 fine tune 的方式來達成，而會使用 RAG 的方式來完成。

關於 fine tune 的方式，可以參考拙作《駕馭 ChatGPT 4: 探索 Azure OpenAI 與 Cognitive Service for Language 開發實踐 (使用. NET 與 Node. Js)》。裡面有 Azure Open AI 上 fine tune 模型的詳解。

明天開始我們來談 Langchain，一個可以讓你很方便做 RAG 、甚至是更多 LLM 應用的框架。