向量資料庫

為什麼 RAG 可以不使用向量資料庫？

向量資料庫不是 RAG 的必要條件，它只是其中一種把資料餵給 AI 的方式。當資料本來是混亂的、缺乏清楚邊界的，向量化可以幫助模型從大量文字中猜測語意相關性，這種做法有它的價值。但如果內容本來就有秩序，問題就不再是「怎麼從混亂中硬算相關」，而是「怎麼讓 AI 先看到最重要的判讀線索」。真正有效的 RAG，不一定是先把全文切碎、壓成向量再回頭猜答案；也可以是先把內容整理成 AI 能逐層理解的路徑，先降低上下文的不確定性，再展開細節。

而 WordPress，正是「本來就有秩序」的那種網站架構。你經營網站時所做的分類、標題與摘要，早就把內容整理成清楚的層級；再把它打碎、壓成向量、用相似度拼回去，只是把做完的整理再用數學的方式重做一遍。但事實上你不需要為了讓 AI 讀懂網站而去建一座向量資料庫，你需要的，只是讓 AI 看見你早就建好的那一座圖書館。

以 RAG Sitemap 為藍圖的立體圖書館

RAG Agent 不必讀完整個圖書館，也不必把藏書打碎成碎片再比對相似度。他循著招牌往下走，先看藏書區域的吊牌找出目標所在的大分類，再看櫃側的標籤分辨小分類，接著掃過架上每一本書的書名與描述，最後才抽出真正需要的那一本。這條漸進式披露的路徑就是 RAG Sitemap，連小模型都走得通。

RAG Sitemap · Progressive Disclosure
MASTER SITEMAP Read the zone signs. Tell the major sections apart. ZONE A ZONE B ZONE C ZONE D descend into B CATEGORY Inside Zone B, read each unit's side label. CAT B-01 CAT B-02 CAT B-03 open shelf B-02 SUB-CATEGORY On the shelf, read every book's title (title + description). Title 01 Title 02 Title 03 Title 04 Title 05 pull out Title 03 POST TXT Open that one book. Read the full content. Title 03 Content No vectors. No embeddings. Just the path. A small model walks it like a librarian.

向量資料庫的做法，是把每一本書撕成紙片，丟進一個沒有方位的空間，再用 cosine similarity 把紙片拼回去。而一座分類良好的網站本來就有分區、有書櫃、有書名，這套人類早就排好的層級本身就是檢索路徑。RAG Sitemap 沒有發明這座圖書館，它只是把圖書館的分類一鍵轉檔成 AI 讀得懂的目錄。

A box of torn slips. No aisles, no shelves, no titles. Only similarity, after the fact.

向量資料庫多做了一件事

市面上多數 WordPress AI Chatbot 外掛走的是同一條路：把全站內容打碎、做成向量存進資料庫，提問時用相似度撈回幾段，再丟給模型。這條路能運作，相似度也確實找得回相關段落，但向量資料庫一開始就做了一件多餘的事，把你早就整理好的東西打碎重做。

向量檢索擅長在混亂中計算相關性，但如果一個網站本來就有清楚的標題、摘要與主題分群，卻還要先拆成碎片、壓成向量、再用相似度拼回來，等於把原本可直接利用的編輯成果繞遠路重做。RAG Sitemap 不打碎內容，它照你排好的書架走過去，直接拿那本書。你不是在把網站丟給 AI 碰運氣，而是把它整理成一張專為機器理解設計的知識地圖，讓 AI 先看懂，再回答。

AI 需要的是目錄，不是另一團謎霧

AI 與人類一樣，讀漸進式披露的標題、描述與層級路徑，比讀全文更容易判斷「這篇值不值得讀」。即便 LLM 能在單一任務裡容納百萬 token，先給最小、最有判斷力的資訊、再依需求往下讀，仍然讓模型少走彎路、少吃噪音。RAG Sitemap 把網站既有的分類、標籤、階層與摘要，直接轉譯成 AI 可讀的純文字地圖，讓模型先看懂目錄與路徑，而不是先掉進全文的資訊謎霧。

沒有相似度計算，檢索就成了一道選擇題：模型讀懂目錄，判斷問題屬於哪一類、該往哪條路徑走，再走到該讀的那一篇。它不是在算哪段最像，而是讀懂目錄之後做選擇。你經營網站時本來就在做的分類與描述，就是它的索引，不必再去煩惱向量資料庫那一套，chunk 要切多大、挑哪個 embedding 模型、相似度門檻設多少。

WordPress 的熵，早已在網站經營的同時逐步降低了

一份未經整理的純文字，對 LLM 而言熵極高。而 WordPress 每發佈一篇文章，作者選分類、下標題、寫摘要、發佈到階層式 URL，這四個 SEO 動作就是四次微型的熵減。一個經營五年的 WordPress 站，就是這四個動作重複了幾千次，留下一份早已整理過的低熵語料庫。

Vector DB 的存在邏輯是「我面對的是高熵的非結構化文本，我必須用 embedding 重算秩序」；RAG Sitemap 的存在邏輯則是「這個語料庫的熵，早就為了 SEO 降到很低，我只需要揭示已分類的文本與描述，不需要重算」。同一份內容，Vector DB 選擇重算，RAG Sitemap 選擇揭示。

相關文章

AI 熵減工程是所有讓 LLM 動起來的設計的總稱，從 prompt、context、agent 到 harness 都是在收窄預測的可能性、降低回答的不確定性，只是影響範圍的大小不同。這是因為 LLM 運作在天然高熵的語言介質上，而 AI 應用的核心工程，就是透過結構化輸入與外部知識來執行熵減，以降低不確定性、提升輸出品質。

小模型 Llama 3.2 3B，是一個僅有 3B 參數，小到不能再小的語言模型。你問它問題，它只能根據 3B 的訓練資料回答你。它不知道你的網站寫了什麼，不知道你發了哪篇文章，對你近期累積的內容一無所知。用它來跑網頁問答，原本是天方夜譚。

RAG Harness Engineering 讓訪客的每個提問背後不只是單純的一次 AI 提示詞呼叫，而是看圖、檢索、回答三段獨立的 AI API。多個 Sub Agent 接力最怕一站污染一站，Harness 架構讓每一站都拿著訪客的原始提問、清楚知道最初的任務目標，從根本上就對污染免疫，累積的雜訊被擋在每一次 hop 的入口之外。