[AI 觀點整理] RAG沒死，重點是場景選型

 [AI 觀點整理] RAG沒死，重點是場景選型

摘要 : RAG並未淘汰，向量庫、Markdown、LLM Wiki各有適用場景，關鍵在於依資料型態與規模做選擇。

內容:

近來不少人認為傳統RAG已經過時，原因在於它的實作流程相對繁重。從文件解析、資料切片、向量化，到部署與維護向量資料庫，每個環節都需要投入不少時間與成本。也因此，市場上開始出現更輕量的替代方案，例如以Markdown為核心的檢索方式，以及先摘要再問答的LLM Wiki模式。

傳統向量資料庫型RAG的最大優勢，在於它具備語意搜尋能力。當面對的是海量且多樣化的資料，例如企業財報、制度文件、產品資訊等，向量檢索能更有效地處理模糊、口語化的提問，完成高品質召回。不過，它的缺點也相當明顯，像是切片品質若處理不佳，容易造成上下文斷裂；此外，整體建置與運維成本也較高。

第二種是基於Markdown儲存，加上關鍵詞檢索的方式，例如Cloud Code所採用的思路。這類方案不依賴切片、embedding或向量資料庫，幾乎可以做到零運維，開發成本也非常低。它特別適合程式碼庫、API文件、專有名詞密集的小型知識庫場景，因為這些內容通常更依賴精確匹配而不是語意理解。但它的限制也很明顯：高度依賴關鍵詞，無法真正理解語意，而且在檢索時往往需要將整份Markdown內容交給大模型，token消耗較大。

第三種則是LLM Wiki方案，也就是在資料上傳時，先透過大模型將原始內容整理成結構化筆記或摘要。它的優點在於先用算力換取結構，把知識預先整理好，後續不但方便模型讀取，也方便人直接閱讀，特別適合個人知識庫、經驗整理與高頻閱讀場景。不過，這種方式本質上是一種摘要壓縮，如果在前處理階段遺漏了某些細節，後續提問時就可能永遠無法找回原始資訊。

若回到實務選型問題，這三種方案並不是互相取代，而是分別對應不同需求。如果你的資料規模不大，內容以程式碼、API文件、技術術語為主，且需要強邏輯推理，那麼使用Markdown搭配關鍵詞檢索即可，沒必要額外承擔向量資料庫的複雜度。如果你經營的是個人知識庫，重視閱讀體驗與內容整理，那LLM Wiki會是更自然的方案。

但若你的場景是企業級知識庫，資料量巨大、來源複雜，使用者提問又充滿口語化與模糊表達，那精確匹配往往會失效。這時候，傳統RAG搭配Embedding與向量資料庫，仍然是最可靠且必要的方案。換句話說，RAG並沒有死，而是演化出了更多輕量化變體；最重要的不是追逐流行，而是根據實際場景做出合理架構選擇。

若要真正落地企業級RAG，還會面臨許多實戰痛點，例如分片策略怎麼設計、TopK限制如何處理、跨向量聚合查詢怎麼做、如何做來源追溯、文件更新怎麼同步、表格與圖片如何解析、怎麼降低模型幻覺、如何提升召回率、查詢改寫怎麼設計，以及Rerank與後處理機制應如何使用。這些都是企業在面試與專案中非常常見的核心問題。

最後，內容也補充了向量檢索的基本概念。所謂向量，本質上是把詞語、句子或更複雜的內容，轉換成可供電腦理解的數值表示。語意相近的內容，在向量空間中的距離也會更近，因此系統便能透過相似性比較，找出與查詢最相關的語料。這也是為什麼向量模型與向量資料庫，至今仍是大型語意檢索系統中的關鍵基礎設施。