16種RAG技術排開才看清：難的不是原理，是「什麼時候該用哪個」

10月19日，掘金出現一篇標題寫著「感覺終於把複雜的 RAG 技術整理明白了」的長文。作者從公司要搭 AI 知識庫的需求出發，把 Naive RAG、Multi-Query、HyDE、Hybrid Search、Reranking、GraphRAG、Agentic RAG 等十六項技術一次梳理。文首特別聲明：上線情境、用戶回饋與檢索排名都是教學模擬，不代表實際部署結果。

這種「先把免責聲明寫在前面」的寫法，加上一個貫穿全文的虛構案例，讓這篇文章在工程師社羣裡有了被轉發的理由。

學RAG的第一道牆，是不知道技術之間的關係

作者在文中最誠實的一段自白，是描述剛入門時的困惑：單看每一種技術都不算難懂，真正的問題是不知道它們之間是什麼關係。有些功能看起來差不多，有些可以組合，有些又像整個架構的全面升級。

於是他換了一種學習路線：不按技術名稱逐個背，而是先問每種技術到底解決了什麼問題。沿著這條線，十六項技術被他歸到幾個方向。

這個分類方式本身就是文章的核心主張：這些技術並非從低級到高級的升級路線，而是圍繞不同問題形成的一組解方。Hybrid Search 和 Reranking 是對基礎流程某個環節的補強，Agentic RAG 則改變了整個系統的運行方式。

一家虛構公司，替所有問題排好了出場順序

文章的展開方式相當有畫面感。假設一家技術團隊要做人知識助手，讓員工直接向 AI 提問，就能查到開發規範、架構設計、部署手冊和歷史故障紀錄裡的答案。

接著問題按現實順序登場：一開始只是希望 AI 能用內部知識；然後發現相關文件檢索不到、排序不合理、回傳內容缺少上下文；這些解掉之後，又冒出資料不足、複雜問題需要多次檢索、跨文件關係分析這類新挑戰。

每一個問題都走同一套流程：發現問題、分析原因、找解方、理解原理、比較效果與代價。這種「讓問題推著技術出場」的寫法，讓讀者不需要先記住任何名詞。

作者也提醒，這十六項並非都是獨立的 RAG 架構，其中混有檢索、分塊、資料庫查詢與生成優化等技術，重點在理解各自的價值與適用邊界。

「不是用得越多越好」為什麼打中工程師

文章結尾的體悟，很可能才是它在社羣裡被收藏的原因：技術用得越多，系統效果未必越好。真正需要掌握的不只是原理，而是判斷什麼時候需要它、為什麼需要它、它是否真的解決了問題。

這句話對應的是當前 AI 應用開發的普遍焦慮。框架與名詞每季都在增加，教學文多半按技術名稱逐一開講，讀完往往記住了一堆縮寫，卻不知道自己的場景該從哪一步開始加東西。這篇長文反過來以問題為軸，把技術當成問題的答案而非主角，恰好補上這個缺口。

類似的社羣現象近來並不孤例。先前掘金也有一篇把「沙箱」這個被 Agent 時代重新炒熱的老詞一次講清楚的長文，同樣走「把基本概念講明白」的路線，整理成沙箱與虛擬機、Docker 差別的問答解析後引來不少圍觀。當 術語膨脹速度快過消化速度，把關係講清楚的文章，永遠比介紹又一套新框架的文章更容易被轉發。

當然，這篇文章的侷限也和它的優點一體兩面：案例與數據都是教學模擬，實際部署中各技術的取捨仍需動手驗證。作者把這點寫在文首而非藏在文末，算是給讀者留下了正確的期待。