向量資料庫

為什麼 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 選擇揭示。

相關文章

llms.txt 是一份專為 AI 閱讀設計的 sitemap，但它的局限在於只有一層，對有組織、有架構的網站不夠用。這份檔案的標準格式是網站名稱當 H1、一段摘要，底下每一列是一個 [標題](連結)：描述，指向網站裡的一個頁面。但它分不出這一列是分類頁、單一頁面、文章還是商品頁，每一列都被當成同一種東西。初衷沒有錯，目標是讓 AI 更容易地讀懂你的網站。但是問題不在描述，而是在於它把網站壓平成一層，破壞了網站原本的敘事能力與內容脈絡。

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

你以為 RAG 是訓練 AI Chatbot 讀懂網站？其實是在反向校準你的網站 SEO 體質。RAG Sitemap 捨棄黑箱向量庫，直接讀取 WordPress 裡面，你早已寫好的標題、分類與描述，生成 TXT 網站地圖給 AI。當 AI 找不到答案時，問題往往就出在某篇文章的標題、摘要或分類歸屬上，你只需要用平常做 SEO 的方式進後台修正，不需要學新工具，也不需要通靈演算法。