RAG 與 LLM：定義、差異與使用案例

LLM 會利用從訓練資料中的模式學得的參數來生成回應。由於這些參數可能無法反映最新或完整資訊，RAG（即檢索增強生成）會在過程中加入來自外部來源的資料到 LLM 的輸入上下文中，從而補充這個流程。AI 工具會檢索外部資訊，以增強 LLM 的生成流程。

實際上，你的選擇不是 RAG 或 LLM 之間二選一，而是在混合式方法與僅使用 LLM 的方法之間做選擇。

當 LLM 需要存取公司文件、資料庫或快速變動的資訊時，RAG 是必要的。若所有輸入都可由使用者提供，則僅使用 LLM 的方式適合某些管理、資料處理和內容創作任務。

RAG 與 LLM 是互補的系統。你可以在不使用 RAG 的情況下使用 AI 模型（此時它完全依賴既有參數），但你不能在沒有模型的情況下使用 RAG 系統。
RAG 的引入是為了解決 LLM 的三個關鍵問題：資訊過時、幻覺式回應，以及缺乏對第三方來源的驗證。
RAG 讓 AI 在真實商業情境中更有效，因為它將 LLM 與已驗證的內部文件、資料庫和 API 端點連接起來。
RAG 的主要使用案例包括客服聊天機器人、基於快速變動資料的查詢（例如產業新聞），以及醫學與法律等專業領域，在這些情境中，準確性與來源事實查核都很重要。
RAG 主要有三種類型：簡單 RAG、模組化 RAG，以及進階 RAG。簡單 RAG 最容易理解為直接的資訊檢索，而模組化與進階 RAG 則會加入查詢改寫和區塊最佳化等額外功能。

LLM，或大型語言模型，是一種使用微調後參數來生成內容的系統。這些參數決定了分配給 LLM 詞彙表中所有 token 的機率，指出在特定序列中最有可能接續出現的 token。

若要更好地理解 RAG 的運作方式（以及它與 LLM 有何不同），先從生成式 AI 的基本層面來看會很有幫助：

分詞：使用者的提示詞會被切分成 token，這些 token 可以是詞語、詞的一部分，或單一字元。
嵌入： token 會被轉換成嵌入向量，也就是神經網路（包含解碼器）可以處理的數值表示，也就是向量。
解碼：解碼器的各層（它們構成 LLM 神經網路的重要部分）會操控這些向量，並使用稱為 attention 的程序來擷取意義。這個過程決定每個 token 應與序列中的其他 token 具有多強的關聯。
評分： 模型會為其既有詞彙表中的每個 token 指派相容性機率，並為該序列選出最可能的下一個 token。

重點在於，LLM 只能根據其既有參數和上下文視窗中的 token 產生輸出。在訓練期間，LLM 會在數十億次中被要求補全文字片段，而其參數會不斷調整，直到能可靠地為 token 分配機率（也就是可靠地完成文字）。

例如，想像你問 AI 模型這個問題：「我們公司的 2026 退款政策怎麼寫？」LLM 只能根據其既有參數預測下一個 token，而這些參數並未使用你的支援文件進行微調。如果你在沒有任何額外上下文的情況下問它這個問題，它要嘛根本無法以有意義的方式回答，要嘛就會幻覺出錯誤答案。

RAG（檢索增強生成）是將外部系統中的資訊納入 LLM 提示詞的過程。

底層的 LLM 流程，包括嵌入與機率式 token 比對，仍然相同。RAG 會在前面加入一個預備步驟，將使用者提示詞擴充額外資料。

以下是 RAG 運作方式的概覽：

知識準備： 先準備一個知識來源。它可以是文件集合、向量資料庫、知識圖譜，或即時索引（例如用於 AI 搜尋）。
提示：使用者輸入一個提示詞，例如：「我今天應該去倫敦散步嗎？」
檢索： AI 工具的檢索器會向外部資訊來源查詢。它可能會將提示詞轉換成向量，然後查詢向量資料庫。或者，它也可以使用其他方法，例如 API 呼叫、關鍵字比對或知識圖譜遍歷。
插入： 這些資訊會被加入使用者的原始提示詞中。在倫敦散步問題的例子中，這可能包含倫敦的天氣資訊，以及熱門散步路線目前的可通行狀況。
答案生成： LLM 會以一般方式，使用擴充後的提示詞來生成回應。

在幕後，檢索到的文字會被加入輸入上下文，進行分詞，並轉換為嵌入向量。接著模型透過解碼器處理這段額外上下文，進而改變輸出 token 的機率。

廣義來說，RAG 可分為三種子類型。簡單 RAG遵循基本的 RAG 流程，檢索資訊並將其餵入提示詞。進階 RAG增加了查詢改寫和多次查詢等功能。模組化 RAG則指一種架構，其中不同的進階功能可視為元件，並依需要組合。

RAG 讓使用者能存取最新資料。這會使 LLM 輸出較不容易出現幻覺和資訊缺口。如果你需要查看輸出中所用資訊的來源，RAG 也很重要，因為未依據來源的 LLM 回答不會附上引用。

RAG 與 LLM 的使用案例。RAG：即時性資訊查詢、公司文件、客服支援，以及醫學、法律和金融等專業領域。LLM：管理任務、創意任務、推理與資料型任務，以及一般程式撰寫。

對即時性資訊的請求： 任何關於很快就會過時的資訊的查詢，不論是像天氣預報這樣簡單，還是像對突發新聞深入分析這樣複雜，都需要建立在已驗證的第三方來源之上。
公司文件：使用者會就公司或產品文件提出問題的內部或面向客戶的 AI 聊天機器人，應該啟用 RAG，尤其當文件經常更新時更是如此。
客服支援： 客戶聊天機器人需要能存取最新且詳細的支援文件，才能提供準確答案。
專業領域（醫學、法律、金融等）： 未經特定領域語料訓練的 LLM（尤其是主流模型）通常難以掌握專業提示詞的細微差異。

管理任務： LLM 可以以最低延遲完成基本任務。對於不需要外部資訊的基本寫作與管理任務，例如拼字檢查或摘要，RAG 並非必要。
創意任務： 有些創意任務，例如生成短篇故事或圖片，只需要原始提示詞中提供的資訊。
推理與資料型任務： 如果你處理的是大型資料集，LLM 不需要存取外部資訊也能套用推理與分析功能。
一般程式撰寫： 雖然程式撰寫工作流程可能需要存取私有程式碼庫或文件，但 LLM 在執行一般程式任務方面非常有能力，例如修正錯誤與建立函式，而無需借助外部來源。

與 RAG 和 LLM 之間的區別相關，有三個概念值得注意：長上下文 LLM、代理式 AI，以及基礎依據。

長上下文 LLM 有時可取代啟用 RAG 的系統，而代理式 AI 與基礎依據則可視為同義，或與其並行運作。

這些都是具有大型上下文視窗的模型，其中一些廣泛可用的商用模型可支援高達一百萬個 token。

如果相關資料能放入模型的上下文視窗，且可用文字格式取得，那麼採用僅使用 LLM 的方式會有一些優點。它可以降低檢索錯誤的機率，提供更完整的上下文，並免去繁複的 RAG 架構設定需求。

代理程式是一種會運用多種工具的系統，其中也包含 RAG 功能，用來執行複雜任務。RAG 是代理式 AI 的一個組成部分，而代理程式通常會依提示詞的內容使用不同類型的檢索方法（例如網路搜尋與向量搜尋）。

基礎依據是指使用證據或資料來提升 LLM 回應準確度（或為其建立依據）的更廣義過程。RAG 是基礎依據的一種形式，但將技術文件加入上下文視窗也同樣可視為基礎依據。

若要更好地理解 RAG 與不使用 RAG 的 LLM 相比如何運作，我們可以看看一個使用 Perplexity 的簡單真實案例，以及一個查詢向量資料庫的假設企業案例。

以下是當向 Perplexity 詢問「我今天應該去倫敦散步嗎？」且關閉 AI 網頁搜尋（RAG 的一種形式）時，所得到的輸出（限制為兩句）：

是——如果天氣相對乾燥，而且你有時間，今天在倫敦散步會是一次令人耳目一新的換景之旅。你可以選擇沿著南岸、攝政運河，或穿過海德公園的路線，並以防萬一帶件輕便防水外套。

將這點與 LLM 能夠檢查外部來源時的提示詞相比：

是的，今天在倫敦很適合散步：預報顯示氣溫溫和，約 19–21°C，間歇晴朗，降雨機率極低。天空局部多雲，微風徐徐，無論是在公園還是沿著南岸等河畔路線漫步，體感都相當舒適。

兩者之間有相似之處，因為 LLM 使用的是相同的底層 token 評分流程。不過，第二個例子包含詳細的天氣資訊，因此實用得多。

想像有一位使用者向某銀行 App 內的聊天機器人提出以下問題：「我可以在哪裡下載最新的對帳單？」

管理該 App 的銀行建立了一個資料庫，其中包含其最新產品文件的嵌入向量，並將其連接到聊天機器人的 RAG 管線。這些文件約有 1,000 份來源文件，會被切分為較小的區塊，並轉換為向量以供檢索。

使用者的查詢會傳送至嵌入模型，而應用程式會將該向量傳送到資料庫，資料庫再回傳相關區塊。

嵌入模型會接收到如下請求：

json

{
  "input": "Where can I download my most recent statement?"
}

嵌入模型會回傳以下向量嵌入：

json

{
  "embedding": [0.12, -0.44, 0.87, 0.31]
}

接著，向量資料庫會收到如下請求：

json

{
  "vector": [0.12, -0.44, 0.87, 0.31],
  "top_k": 5
}

在這個（大幅簡化的）例子中，資料庫會回傳與使用者查詢最相關的五個區塊，這些區塊會傳送給應用程式，並納入 LLM 提示詞中。

LLM 與 RAG 是互補的系統。因此，「我應該何時選擇 LLM、何時選擇 RAG？」這個問題其實不太恰當。更合適的問法是：「何時只用 LLM 就足夠，何時 RAG 才是最佳選擇？」

你所選擇的 AI 模型具有很大的上下文視窗： 如果在提示詞中更容易加入所有完成準確答案所需的資訊或資料，例如上傳文件，那麼這樣做可以降低延遲並避免與檢索相關的問題。
推理與資料分析工作流程： 只參考提示詞中所提供資料的分析與推理工作流程，不需要 RAG 功能。
程式碼生成： 一般程式撰寫工作通常不需要 RAG，不過它通常會用於特定專案任務，例如擷取先前的修正內容或供應商 API 與文件。

你需要存取最新資訊： 如果 AI 應用程式需要存取外部的最新資訊來源，才能生成準確答案，請務必啟用 RAG 功能。
你正在專業領域工作： 對於醫學、法律、教育等領域而言，若準確性、細節與來源查核很重要，僅使用 LLM 往往會不足。
輸出應該引用公司內部檔案： 如果你使用 AI，不論是內部用途還是面向客戶的應用程式，用來根據公司內部文件、資料、品牌套件、文件或檔案生成內容，RAG 都能提供對該資訊的存取。

RAG 標誌著 AI 演進中的重大創新。它解決了三個主要問題：資訊過時、模型記憶有限，以及因缺乏相關訓練資料而導致的資訊缺口，這些問題往往會造成幻覺。當然，LLM 並未完全克服這些問題，但自從 RAG 出現後，這些情況的發生頻率已大幅降低。

RAG 並不是靜態技術。預期它會在多個面向持續改進，包括重新排序、檢索與 token 使用期間的延遲、對危險資料來源的安全防護、整合來自多個來源的檢索資料等等。隨著 LLM 與代理式 AI 持續發展，支援它們的 RAG 系統也會一同演進。

RAG 與 LLM：關鍵差異是什麼？

什麼是大型語言模型（LLM）？

什麼是檢索增強生成（RAG）？

RAG 與 LLM：使用案例概覽

RAG 使用案例

LLM 使用案例

RAG 與長上下文 LLM、代理式 AI 及基礎依據

長上下文 LLM

代理式 AI

基礎依據

RAG 與 LLM：真實案例

RAG 與簡單提示詞的 LLM

RAG 與企業向量資料庫中的 LLM

何時選擇 RAG 與 LLM，以及何時結合使用

何時在未啟用 RAG 的情況下使用 LLM

何時在啟用 RAG 的情況下使用 LLM

RAG 與 LLM 是互補且持續演進的技術