以 RAG 進行基礎化：AI 系統如何在回答之前檢索佐證

大型語言模型之所以有用，是因為它們能用流暢的語言綜合、解釋和轉化資訊。但一旦我們要求它們處理即時的、私有的，或需要可驗證依據的資訊，它們就變得不可靠。模型在訓練期間可能看過類似的素材，但這不代表它能存取當前任務需要的那份飯店合約、無障礙稽核或客戶回饋紀錄。

這就是核心的基礎化（grounding）問題。模型參數是先前訓練資料壓縮後的統計記憶——既不是與你組織知識的即時連線，也不是可信賴的稽核軌跡。假設一位旅行社規劃師問：「我們的京都飯店合作夥伴中，哪些在四月有每晚 250 美元以下的無障礙客房可用，跟過往客戶回報的情況比起來如何？」光靠模型的答案是不夠的。相關佐證可能散落在私有的合作夥伴合約、即時空房動態、無障礙檢查紀錄和基礎模型從未看過的過往客戶評論中。就算模型產生了看似合理的回應，團隊仍然需要知道答案到底從哪來的。

檢索增強生成（RAG）就是用來解決這個問題的主要系統模式之一。核心概念很簡單：先檢索佐證，再生成。系統不是要求模型單靠參數來回答，而是先從外部知識來源搜尋相關素材，然後把佐證傳進生成步驟。模型不會因此被重新訓練，權重不變。改變的是它在推論時收到的上下文（context）。

這個區別很重要，因為它同時解釋了 RAG 的價值和限制。檢索能改善即時性、對私有資料的存取和來源追溯。但它不會讓模型變得全知，沒辦法保證答案正確地使用了佐證，也消除不了對權限、索引紀律或在佐證薄弱時選擇拒答的需求。

為何模型參數不夠

有三種反覆出現的情境，光靠模型的答案是站不住腳的。

第一是知識過時。訓練發生在某個時間點。就算模型是在廣泛的公開語料庫上訓練的，也不能假設它反映了最新的飯店空房、最近的無障礙翻新，或上週才更新的合約。

第二是私有知識。大多數組織關心的問題，答案存在於內部系統中：合作夥伴合約、訂房紀錄、無障礙稽核、客戶回饋表、供應商費率表和空房資料庫。這些材料通常不在公開模型的訓練範圍內，也不應被假定已嵌入模型中。

第三是缺乏來源追溯。在許多商業和營運場景中，「大概正確」是不夠的。團隊需要知道哪個來源支持某項宣稱、這個來源是否仍然有效，以及答案到底是在摘要佐證還是超出佐證在做推論。一段沒有佐證的流暢文字，在營運上往往毫無用處。

換句話說，基礎化是一個系統層級的問題，不只是提示撰寫的問題。如果答案依賴即時的或受控的資訊，系統就需要一條通往外部佐證的路徑。

RAG 到底是什麼

RAG 代表檢索增強生成（retrieval-augmented generation）。在 Lewis et al. 的原始提法中，系統結合了一個預訓練的語言模型（參數元件）與一個作為非參數記憶的文件索引。檢索機制本身具有參數，例如用於嵌入（embedding）查詢和段落的密集編碼器，但它搜尋的知識庫是非參數的——可以在不重新訓練模型的情況下更新、替換或擴展。從實務產品的角度來看，RAG 是一種模式，在這種模式下，系統會：

1. 以可搜尋的形式儲存外部知識，

2. 為給定查詢檢索最相關的片段，然後

3. 要求模型使用這些檢索到的片段作為佐證來回答。

這個定義有必要講清楚，因為 RAG 經常被描述得過於含糊。

RAG 不是線上學習。系統不會在每次檢索文件時永久更新模型的知識。

RAG 不等於網頁搜尋。搜尋可能是一個檢索來源，但許多 RAG 系統從內部語料庫、結構化紀錄或混合知識庫中檢索。

RAG 不是事實正確性的保證。檢索改善了系統把答案建立在可用佐證上的能力，但如果檢索到錯誤的佐證、關鍵佐證缺失，或模型誤讀了提供的內容，最終答案仍然可能是錯的。

簡單說，RAG 最好被理解為一種基礎化策略——它在回答時給予模型存取佐證的能力。

基礎檢索流程

最簡單的 RAG 流程（pipeline）不需要你具備向量資料庫或檢索研究的先備知識。把它想成一系列準備和執行時步驟就好。

1. 建立語料庫

系統從語料庫開始：它被允許使用的文件或紀錄集合。在 OptiVerse Travel 旅遊 Copilot 中，這可能包括飯店合作夥伴合約、即時空房動態、無障礙檢查報告、過往客戶行程、評論摘要和供應商費率表。

這個步驟比聽起來重要得多。如果相關的來源缺失，後面不管用什麼檢索方法都救不回來。一個語料庫不完整的基礎化系統，往往看起來很有信心，卻默默錯過了決定性的佐證。

2. 準備文件

原始文件很少能直接拿來檢索。PDF 可能需要擷取文字。表格可能需要正規化。來源類型、日期、訂單參考、物件 ID、無障礙評等和存取權限等元資料可能都要附加上去。這個準備步驟往往決定了正式系統是好用還是脆弱。

文件準備也決定了系統之後能引用或篩選什麼。如果一份無障礙報告在接收時沒有附上對應飯店合作夥伴的合約 ID，檢索器可能永遠無法把使用者的問題連結到相關紀錄。

3. 將內容切成區塊

大多數系統不會一次檢索整份合約或完整的檢查報告。它們會把內容切分成區塊：可以高效索引和比較的較小段落。

切分是一個實務設計選擇，不是無關緊要的前處理步驟。區塊太小，系統可能檢索到上下文不夠的片段。區塊太大，檢索可能變得很雜，無關的文字把關鍵段落擠掉了。好的切分會盡量遵循文件結構，例如章節、段落、表格區域或合約條款邊界。

4. 建立 embedding 並建索引

嵌入（embedding）是一段文字或其他物件的數值表示。簡單來說，嵌入會把語意相似的內容放在高維空間中彼此鄰近的位置。這讓系統能按語意來比較使用者的問題和已儲存的區塊，而不是只靠精確的關鍵字比對。

區塊被嵌入之後，系統把這些向量存進支援相似性搜尋的索引裡。這就是許多人說的「向量搜尋」。對第一次接觸系統觀點的讀者來說，重點不是資料庫品牌或索引演算法，而是系統已經把語料庫轉換成一種可以快速檢索語意相關段落的形式。

5. 為查詢檢索候選內容

當使用者提出問題時，系統通常也會把問題轉換成嵌入，然後在索引中搜尋最相關的區塊。有些系統在檢索前後還會套用元資料篩選，例如只看特定區域的飯店合約，或只看當前使用者有權存取的紀錄。

值得留意的是，這個階段通常回傳的是候選段落，不是最終佐證。目標是收集一組有潛力的結果，而不是假設第一個檢索到的區塊就是對的。

6. 對佐證重新排序或過濾

許多實務系統在初步檢索之後會加一個重新排序步驟。快速檢索器先撒大網，然後用第二個模型或評分方法，根據與確切問題的相關性來重新排列候選結果。這通常能改善答案品質，因為生成步驟看到的是一組更精煉、更相關的佐證。

簡單來說，重新排序解決的問題是：第一次搜尋高效但不完美，所以系統再用更仔細的一輪篩選來改善候選名單。

7. 從檢索到的上下文生成答案

檢索完成之後，模型才生成回應。提示通常包含使用者的問題、關於如何使用佐證的指示，以及檢索到的段落或紀錄。這就是檢索增強生成中「增強」的部分。

如果系統設計得好，當佐證缺失時，就不會要求模型從一般知識中回答，而是要求它根據所檢索到的內容進行摘要、比較、擷取或綜合。

8. 回傳答案，附上來源追溯、警示或棄權

正式系統不應止步於生成的文字。它還要決定如何呈現支持依據——可能是連結的來源段落、文件標題、合約 ID、訂單參考或信心度警告。也可能是在佐證太薄弱、矛盾或不完整時拒絕回答。

最後這個分支也是基礎化的一部分。一個有用的基礎化系統有時會說：「我沒有足夠可靠的佐證來回答這個問題。」

檢索解決了什麼

檢索能很好地解決一類特定的問題。

它有助於解決即時性問題，因為答案可以使用在模型訓練之後才新增的素材。

它有助於解決私有知識問題，因為語料庫可以包含基礎模型從未存取過的內部文件。

它有助於解決來源追溯問題，因為系統可以將來源參照附加到答案上，讓使用者更容易檢視支持佐證。

它也有助於治理。因為檢索取用的是明確的語料庫，團隊可以針對範圍、權限、索引排程和可稽核性進行推理——而當大家籠統地說答案只是來自「模型」時，這些推理就困難得多了。

以 OptiVerse Travel 旅遊 Copilot 為例，這就是泛泛的京都飯店答案與建立在實際佐證上的基礎化答案之間的差異。系統可以檢索合約 KYO-H12 以顯示合作夥伴房間費率和無障礙功能，與最新的四月空房動態交叉比對，從先前的檢查中擷取無障礙照片集 ACC-09，並呈現曾在該物件預訂無障礙客房的家庭客戶評論。這比一段缺乏基礎的一般旅遊知識摘要有用得多。

檢索無法解決的問題

RAG 經常被只看過正常路徑 demo 的人過度吹捧。檢索改善了產生好答案的條件，但消除不了系統設計的其他問題。

它無法保證檢索到的佐證就是正確的佐證。薄弱的檢索器可能漏掉關鍵的合約條款、回傳表面相似但無關的飯店列表，或過度偏重熱門物件而非真正符合無障礙標準的物件。

它無法保證引用被忠實地使用。回應可能有連結或腳註，但仍然誇大了來源所說的內容。來源標注有價值，但標注不等於對來源做了忠實的推理。

它無法單獨解決存取控制。如果檢索層不具備權限感知能力，它洩漏敏感內容的效率和檢索有用內容一樣高。

它解決不了語料庫品質問題。如果知識庫不完整、過時、重複或正規化不良，模型就會從有缺陷的佐證集生成。

它也取代不了領域判斷。在旅遊規劃中，正確答案可能取決於對季節性空房、跨區域無障礙標準或矛盾客戶偏好的解讀。檢索可以組合佐證，但它本身無法定義衝突該如何處理的政策。

這裡的重點是，「RAG 減少幻覺」應該被視為一個不完整的說法。當佐證層夠強健、生成策略有紀律時，檢索確實可以減少無根據的回答。但當檢索薄弱、系統又不懂得拒答時，它也可以產生非常有說服力的錯誤。

有佐證支持的答案與僅靠模型的回覆

理解 RAG 最簡單的方式是比較不同的回答模式。

僅靠模型的回覆是從模型的參數和使用者的提示生成的。它可能流暢、甚至方向上是對的，但使用者通常無法檢視佐證路徑。如果答案是錯的，你很難分辨模型是知識過時了、被措辭混淆了，還是在捏造支持依據。

有佐證支持的答案有不同的契約。系統檢索外部素材、把答案限制在該素材的範圍內，並揭示支持依據的來源。這改變了輸出的操作意義——答案變得可檢視。

可檢視不代表萬無一失。系統可能摘要不正確，或跨文件做了無根據的推論。但可檢視性之所以重要，是因為它讓使用者和評估者有具體的東西可以驗證。實務上，「模型說的」跟「系統找到了這些紀錄，然後做了如下摘要」之間的差異，是現代 AI 產品中最重大的架構轉變之一。

對工程師和決策者來說，這個轉變有實際的後果：

1. 評估可以包含檢索準確率、引用忠實度和拒答行為，不只是最終答案的風格；

2. 失敗變得可診斷，因為通常可以追溯到接收、索引、權限、排序或生成策略；

3. 信任成為由佐證處理所塑造的系統特性，而非對模型智慧的模糊信念。

實務系統觀點

最簡單的 demo 讓 RAG 看起來像是「搜尋一下，然後把幾段文字貼進提示」。但正式系統的結構要嚴謹得多。

在接收時，系統擷取文字、盡可能保留結構、附加元資料，並維護索引。

在查詢時，系統強制執行存取控制、檢索候選結果、重新排序、決定要包含多少上下文，並指示模型保守地使用佐證。

在生成之後，系統通常附加參照、紀錄佐證路徑，並評估是否該選擇拒答。

從這個角度來看，RAG 不是單一元件。它是一條流程，有許多個可能失敗或改進的環節。檢索器很重要。語料庫很重要。切分很重要。元資料很重要。提示指示很重要。回答策略也很重要。

這也是為什麼更強的基礎模型省不了檢索工程的功夫。一個能力很強的模型，如果被傳入錯誤的佐證、關鍵佐證被省略，或上下文視窗被雜訊段落塞滿，仍然可能嚴重失敗。答案品質往往取決於檢索品質。

實例演練：無障礙飯店查詢

先看這個問題：「我們的京都飯店合作夥伴中，哪些在四月有每晚 250 美元以下的無障礙客房可用，與過往客戶回報的情況相比如何？」

一個有基礎化設計的 OptiVerse Travel 旅遊 Copilot 可能這樣處理。

它先從使用者的請求中識別行程上下文——訂單 JPN-2026-0417，一趟為四口之家規劃的十天無障礙日本行程，預算為 13,000 至 15,000 美元。然後檢索京都物件的合作夥伴合約（例如合約 KYO-H12）、四月日期的即時空房動態、包含照片集 ACC-09 的無障礙檢查紀錄，以及曾預訂類似住宿的家庭過往客戶評論。接著篩選或重新排序結果，讓與特定無障礙需求和每晚費率門檻最相關的段落排在最前面。

到了這一步，模型才綜合出答案。一個審慎的回應可能會說，兩家京都合作飯店在所請求的日期有每晚 250 美元以下的無障礙客房可用，但其中一家物件收到了先前客戶對無障礙設施的評價不一——該客戶指出儘管飯店有等同 ADA 的認證，浴室門寬仍然偏窄。答案可以引用合約 ID、空房動態時間戳，以及用於比較的特定客戶評論。

這個答案之所以有用，是因為它建立在佐證上、範圍限定在實際問題內，而且對比較的邊界交代得很清楚。光靠模型的答案很難可靠地做到其中任何一點，因為決定性的佐證是私有且特定的。

同樣重要的是，系統應知道什麼時候不該回答。如果合約條款模糊、空房動態過時，或相關的無障礙報告尚未被接收，正確的行為可能是回傳帶有警告的部分答案，或在取得更多佐證之前完全拒答。

本文不涵蓋的內容

本文不是關於進階檢索替代方案的文章，例如快取增強生成、混合基礎化或長上下文策略。那些屬於第七篇文章的範疇。本文也不是記憶架構的文章；檢索與對話記憶、任務狀態、工作記憶和持久知識的分離會在第四篇文章中討論。本文也不是文件智慧的文章；當表格、版面和頁面結構影響檢索品質時，那就成為在第八篇文章中處理的獨立系統問題。

本文涵蓋的是作為基礎化策略的基準 RAG。其他一切都建立在此之上。

常見誤解

第一個常見誤解是 RAG 代表模型已經學會了檢索到的素材。其實並非如此。檢索改變的是當前的提示上下文，不是模型的長期參數。

第二個誤解是只要附帶引用的答案就算是基礎化的。引用格式很容易模仿。真正的關鍵在於被引用的來源是否真的支持那個宣稱，以及系統能不能清楚展示這個連結。

第三個誤解是檢索只是疊加在能力強大模型之上的便利功能。在許多領域中，檢索是最小可行架構的一部分，因為答案依賴即時的或受控的佐證。

還有一種傾向是把 RAG 等同於通用的「搜尋」。搜尋是許多 RAG 系統的一部分，但 RAG 涵蓋從佐證準備、檢索、答案調節到具來源追溯意識的輸出的端對端模式。

最後，有些團隊以為一個基礎化的系統應該總是產出些什麼。其實，懂得拒答往往是成熟的標誌。如果佐證薄弱，一個信心滿滿的答案可能比沒有答案更糟。

需要注意的失敗模式

不好的切分可能毀掉支持依據。一個關鍵的合約條款可能和限定它的附加條款被切開，導致檢索呈現出具誤導性的片段。

薄弱的召回率可能埋沒真相。如果檢索器漏掉了那份決定性的無障礙報告，生成步驟就無從補救。

嘈雜的上下文可能稀釋好的佐證。塞更多區塊進去不一定更好。太多只是鬆散相關的素材，反而讓模型更難專注在重要的內容上。

不完整的語料庫造成靜默失敗。團隊以為建了一個基礎化的系統，但其實只是在部分文件集上建了一個搜尋介面。

過時的索引損害即時性。如果接收或索引落後於營運現實，新文件也無濟於事。

權限錯誤會同時造成風險和不良答案。如果檢索忽略存取邊界，系統可能洩漏敏感資訊。如果篩選太嚴，可能漏掉使用者有權查看的佐證。

不忠實的綜合仍然是一個現實問題。即使上下文中有正確的段落，模型仍可能過度概括、合併不同的案例，或把推論呈現為直接陳述。

這些是系統失敗，不只是模型失敗。它們需要系統層級的評估。

工程師與決策者的設計指引

從定義佐證契約開始。系統被允許使用哪些來源？使用者應能在答案中檢視什麼？

把語料庫準備視為產品工作，而非基礎建設。RAG 系統的實用性往往在第一次檢索呼叫之前就已決定，取決於擷取、元資料設計和權限處理。

把檢索與生成分開評估。如果你只對最終答案評分，可能會看不出系統究竟是沒檢索到正確的佐證，還是沒正確使用好的佐證。

明確設計拒答機制。決定當佐證缺失、矛盾或信心度低時系統該做什麼。「無論如何都回答」在營運場景中很少是嚴肅的策略。

把來源追溯作為產品功能。來源連結、文件名稱、時間戳和合約 ID 不是裝飾——它們是基礎化系統價值主張的一部分。

保持檢索流程的可理解性。當檢索被當成黑箱基礎設施時，團隊會做出糟糕的架構決策。工程師和產品負責人應該能用淺白的語言解釋從語料庫到答案的流程。

接下來的內容

RAG 賦予系統在回答時檢索佐證的能力。不過，這跟記住先前的對話回合、追蹤工作流程進度或維護持久的組織紀錄並不相同。一個系統可能同時做到這些事情，但它們是不同的職責，各有不同的儲存、更新和權威性規則。

隨著系統變得更具互動性，這個區別愈發重要。下一篇文章會區分對話記憶、任務狀態、工作記憶和持久知識，以維持架構的清晰。在那之後，佐證問題會再次擴展：一旦表格、圖表、圖說和頁面結構開始變得重要，檢索就成為文件智慧問題；再之後，就進入多模態佐證處理的領域。

來源附註

本文參考以下主要與實務來源：

• Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." RAG 作為基於檢索非參數記憶進行生成的主要參考。arxiv.org/abs/2005.11401

• Karpukhin, V., Oguz, B., Min, S., et al. "Dense Passage Retrieval for Open-Domain Question Answering." 關於嵌入段落上密集檢索的參考。arxiv.org/abs/2004.04906

• Asai, A., Wu, Z., Wang, Y., et al. "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." 關於自適應檢索與證據批判的進階 RAG 參考。arxiv.org/abs/2310.11511

• BAIR. "The Shift from Models to Compound AI Systems." 將檢索視為模型周邊系統元件之一的系統層級參考。bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." Grounded output 的來源脈絡、評估與風險管理語言參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence