RAG 檢索
讓 Claude 根據你的資料回答
RAG（Retrieval-Augmented Generation，檢索增強生成）解決一個大問題：Claude 再聰明，也不知道你公司內部的報價單、SOP、產品規格。RAG 的做法是把你的文件切成小塊、建立索引，使用者問問題時先「檢索」出最相關的幾段，再連同問題一起餵給 Claude 回答。這樣它就能像讀過你所有內部文件一樣，根據真實資料回答，而不是憑空亂編。
這一站重點
- Claude 不知道你的內部資料，硬問只會一本正經地編（幻覺）——RAG 就是先把對的資料塞給它再讓它答。
- 標準流程五步：切塊（chunking），做向量（embedding），存進向量資料庫，檢索相關段落，連同問題餵給 Claude。
- embedding（向量）把文字變成一串數字，意思相近的文字數字也相近，所以能用「語意」而不只是「關鍵字」找資料。
- 檢索有兩種：向量檢索（比語意，問法不同也找得到）與 BM25/關鍵字檢索（比字面，精確詞、料號、型號很強）；實務上常兩種併用。
- 什麼時候該用 RAG：資料量大、會變動、要出處引用時用；如果只是幾百字的固定規則，直接寫進 prompt 反而更簡單。
深入研讀 · 實作步驟
上面的重點讀完就夠用了；想真的搞懂原理、照著做，往下看完整說明與步驟。
先講這解決什麼生意問題。假設公司內有幾百份東西：報價原則、產品規格、常見客訴的標準回覆、公司政策。新人問「A 方案含不含後續維護？」，你希望有個機器人能秒答。但你不能把幾百份文件全部塞進每一次 prompt——太長、太貴，而且模型能一次讀的量（context window，上下文視窗）有上限。RAG 的聰明之處是：不要每次都給它全部，而是每次只找出跟這個問題最相關的那幾段，再交給 Claude。這樣又省又準，還能附上「這答案出自哪份文件第幾段」，讓人可以查證。
流程第一步是 chunking（切塊）：把長文件切成一段一段（例如每 300 到 500 字一塊，段落之間稍微重疊避免切斷語意）。為什麼要切？因為檢索與餵給模型都以「塊」為單位，塊太大會夾帶無關內容、太小又會斷章取義，切得好壞直接影響品質。第二步 embedding（做向量）：用一個 embedding 模型把每一塊文字轉成一長串數字（向量）。這串數字的魔法在於——意思接近的文字，數字也會接近。所以「維護費用」和「後續保養收費」就算用字不同，向量也會靠很近。把所有塊的向量存進向量資料庫（如 Pinecone、pgvector、Chroma），就完成了索引。
第三步是使用者提問時的檢索：把問題也轉成向量，去資料庫裡找「數字最接近」的前幾塊（例如取最相關的 3 到 5 塊）。這叫向量檢索，強在能跨越用詞差異抓語意。但它不是萬能——遇到精確的料號、型號、法條編號、人名，字面比對的 BM25/關鍵字檢索反而更準（你搜「A123」就是要一字不差的 A123，不是「語意接近」的東西）。所以成熟的系統常把兩種併用（稱為 hybrid search，混合檢索），再視需要加一層 rerank（重新排序）把最相關的往前挑。第四、五步就回到你熟悉的地方：把檢索到的幾塊文字，連同使用者問題，組成一個 prompt 餵給 Claude，並在 system prompt 交代「只根據我給你的資料回答，資料裡沒有就說不知道，並附出處」——這句話是壓制幻覺的關鍵。
最後也是最重要的判斷：不是每件事都需要 RAG。RAG 有它的建置與維護成本（要切塊、要跑 embedding、要顧向量資料庫）。判斷準則：資料量大（幾十份以上）、會經常變動、需要引用出處、或內容多到塞不進 prompt——這些情況用 RAG。反過來，如果你的「知識」只是一頁固定的公司規則、幾百字而已，直接寫進 system prompt 就好，硬套 RAG 是過度工程。中小企業常見的甜蜜點是：把「常被重複問、但答案就散在幾份內部文件裡」的東西做成 RAG 問答機器人——這正好呼應公司內部的 Majordomo 思路，用機器回答重複問題，人只處理例外。
實作步驟
- 盤點並清理要進庫的文件 先挑「會被重複問、答案在文件裡」的內容：SOP、報價原則、產品規格、客訴標準回覆。清掉過期版本——餵進去的是舊資料，答出來就是錯的。
- 把文件切塊（chunking） 把長文件切成 300 到 500 字的小塊，段落間稍微重疊避免語意被切斷。表格、條列這類結構盡量整塊保留，別攔腰切。
- 為每塊做 embedding 並存進向量資料庫 用 embedding 模型把每塊轉成向量，存進向量資料庫（如 pgvector、Chroma、Pinecone）。這一步做完就有了可被語意搜尋的索引。
- 提問時檢索最相關的段落 把使用者問題也轉成向量，取回最相近的 3 到 5 塊。若場景常出現料號、型號、精確名詞，加上 BM25 關鍵字檢索併用，準度更高。
- 把檢索結果連同問題餵給 Claude 將檢索到的段落與問題組成 prompt，在 system prompt 明講「只根據提供的資料回答，沒有就說不知道，並附出處」，壓制幻覺、方便查證。
- 驗證答案有引用、會拒答 用真實問題測試：答對的要能指出來源段落；資料裡沒有的，要能老實說「查無」，而不是硬編。做不到就回頭調切塊大小或檢索數量。
常見踩雷
- 塊切太大夾帶無關內容、或太小斷章取義——切塊品質直接決定檢索品質。
- 只用向量檢索卻要查精確料號/型號——這種場景關鍵字檢索（BM25）反而更準，該併用。
- 沒在 system prompt 交代「沒有就說不知道」——Claude 會用檢索到的殘料硬湊出看似合理的錯答案。
- 資料只有幾百字固定規則也硬上 RAG——直接寫進 prompt 更簡單，別過度工程。
- 文件更新了卻沒重建索引——庫裡還是舊版，答案就跟著錯。
深入來源：Anthropic 官方文件與 Building Effective Agents
挑幾份內部文件切塊、建索引，問一個問題並確認答案有附出處、查無時會老實說不知道。