RAG 與 LLM：定義、差異與使用情境

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

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

當 LLM 需要存取公司文件、資料庫或快速變動的資訊時，就必須使用 RAG。對於某些行政、資料處理和內容創作任務，只要使用者能提供所有輸入，僅使用 LLM 的做法就很合適。

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

LLM，或大型語言模型，是一種使用微調參數生成內容的系統。這些參數決定會套用到 LLM 詞彙表中所有 token 的機率，指出在給定序列中下一個最可能出現的 token 是哪一個。

若要更好地理解 RAG 的運作方式（以及它與 LLM 的差異），可以先看看生成式 AI 在基本層面上如何運作：

分詞： 使用者的提示詞會被拆分為 token，這些 token 可以是單字、詞的一部分，或單一字元。
嵌入： token 會被轉換為嵌入向量，也就是數值表示（數字字串），稱為向量，供包含解碼器在內的神經網路處理。
解碼： 解碼器的各層（它們構成 LLM 神經網路的大部分）會操作這些向量，並使用一種稱為注意力 的程序來擷取意義。此程序決定每個 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、agentic AI 和依據性。

長上下文 LLM 有時可以用來取代啟用 RAG 的系統，而 agentic AI 與依據性則可能與其同義，或與其並行運作。

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

如果相關資料可以放進模型的上下文視窗，而且可用文字格式提供，那麼只使用 LLM 的做法有一些好處。它可以降低檢索錯誤的機會，提供更完整的上下文，並免去建立龐大 RAG 架構的需求。

Agent 是一種會運用多種工具的系統，包括利用 RAG 功能來執行複雜任務。RAG 是 agentic AI 的一個組成部分，而 agent 往往會根據提示詞內容使用不同類型的檢索方法（例如網頁搜尋與向量搜尋）。

依據性是指利用證據或資料來提升 LLM 回應準確性的更廣泛過程。RAG 是依據性的一種形式，但將技術文件加入上下文視窗也算是依據性。

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

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

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

把這與 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 和 agentic AI 持續發展，支援它們的 RAG 系統也會持續進化。

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

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

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

RAG 與 LLM：使用情境概覽

RAG 使用情境

LLM 使用情境

RAG 與長上下文 LLM、agentic AI 及依據性

長上下文 LLM

Agentic AI

依據性

RAG 與 LLM：真實世界範例

RAG 與 LLM：簡單提示詞範例

RAG 與具備企業向量資料庫的 LLM

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

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

何時使用已啟用 RAG 的 LLM

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