RAG 讓大型語言模型先查公司資料再回答，避免亂編。本文以顧問視角深入拆解切塊、嵌入、向量檢索、混合檢索、重排序到上線評估的完整機制，佐以真實數據與工程判斷準則，並說明南台灣中小企業導入雲端或地端知識庫的步驟與常見坑。
先搞懂：RAG 是讓 AI「查」，不是讓它「背」
重排序是否有幫助，不能套別人的命中率。用自家問題集比較加入前後的 Recall@k、MRR、引用正確率與回答延遲；只有命中提升足以抵銷成本與延遲時，才值得放進正式流程。
RAG 換了個思路：不逼模型去背，而是在它開口回答之前，先幫它到你的知識庫「查」一遍，把最相關的幾段原文找出來，連同問題一起交給它，並下一道死命令：「只准照著以下資料回答。」這一步之所以關鍵，是因為它把模型從「憑記憶自由發揮」拉回到「照本宣科」。答案有了白紙黑字的依據，幻覺的空間自然被壓縮——多篇研究也一致指出，把外部檢索接進生成流程，是目前壓低幻覺、拉高事實正確率最有效的手段之一，而且運算成本遠低於把整批文件硬塞進超長對話視窗。
把管線拆開：四道關卡，每一道都能讓你前功盡棄
RAG 聽起來就一句「先查再答」，但真正決定它好不好用的，是中間這幾道工序。我照著資料在系統裡流動的順序，一關一關講給你聽，你會發現——選哪個模型，往往不是最重要的事。
第一關．切塊：切壞了，後面再強都白搭
文件不能整份丟進去檢索，得先切成一段一段的區塊（chunk）。切多大有講究：切太碎，一句話的上下文被攔腰砍斷，撈回來的片段缺頭缺尾；切太大，一段塞進太多不相干的內容，語意被稀釋，反而找不準。實務上的甜蜜點大約落在每塊 256 到 512 個 token（中文粗略換算約數百字）：偏事實型、料號查詢型的問答，用 128 到 256 的小塊命中更準；要做跨段落的分析、比較，才用 512 到 1024 的大塊。
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
第二關．嵌入與向量檢索：把語意變成座標，再找最近的鄰居
切好的每一塊，要先過一個「嵌入模型」，轉成一串幾百到上千維的數字，也就是「嵌入向量」。你可以把它想成：系統把每段文字的語意，標記成高維空間裡的一個座標點，意思相近的句子，座標就靠得近。使用者一發問，問題同樣被轉成一個座標，系統要做的，就是在成千上萬個點裡，找出離它最近的那幾個——這就是向量檢索。挑嵌入模型時，對中文與你產業術語的支援度，往往比模型名氣更該優先看。
第三關．混合檢索加重排序：救回向量搜尋會漏掉的那些料號
第四關．生成與引用：讓模型「只准照抄，查不到就說不知道」
前面把料備齊了，最後才輪到大家最熟的那個生成模型。這一關的工程重點不在模型多強，而在指令下得夠不夠死：明確要求它「只根據以下檢索到的內容作答，資料裡沒有的，就直說查不到」，並且逐句附上來源段落。附引用不是為了好看，而是給人一個能核對的把手——答案旁邊就掛著出處，承辦人員三秒鐘就能翻回原文對一眼，對不上的，一眼就抓得出來。這一層，是把 AI 從「聽起來很專業」推向「可以被稽核」的分水嶺。
真正的功夫在上線之後：你得會「量」它
很多導入案子死在同一個地方：demo 時問十題答十題，大家鼓掌收工，結果上線兩週就被使用者的刁鑽問題打回原形。原因是——沒有人在「量」它。RAG 不是裝好就一勞永逸的機器，它是一套需要持續體檢的系統。
好在現在業界已經有成熟的量測框架，幫你把「好不好」拆成幾個能打分的指標，其中最該盯的兩個是：
- 忠實度（faithfulness）：把模型答案拆成一句句陳述，逐句回頭檢查有沒有被檢索到的原文支撐。這一項直接對應「有沒有在唬爛」，是抓幻覺的照妖鏡。
- 脈絡召回率（context recall）：該撈回來的關鍵段落，到底撈齊了沒？這一項抓的是另一種常見死法——不是模型亂講，而是它壓根沒拿到對的資料。
再加上脈絡精準度、答案相關性，你就能分辨一次答錯到底是「檢索沒撈到」還是「模型沒讀好」，對症下藥，而不是瞎調參數。務實的做法，是先攢一批真實會被問到的問題當考卷，定期給系統做這張考卷；要更嚴謹，還能把這套檢查接進上線流程，分數掉到門檻以下就擋下，不讓退步的版本偷偷上線。這套紀律，比你多換三個模型都有用。
幾個一定要先講清楚的邊界與誤區
把醜話說在前頭，是顧問的本分。RAG 很好用，但它不是萬靈丹，以下這幾點，我每個客戶都會先講：
- 它壓得住幻覺，但杜絕不了。只要檢索撈錯段落、或文件本身就過期、自相矛盾，模型照樣會言之鑿鑿地答錯。RAG 把錯誤的來源從「模型腦補」轉移到「你的資料品質」——這其實是好事，因為資料你管得動。
- 七成的功夫在資料治理，不在選模型。很多人一開口就問「要用哪個模型」，但真正卡住成效的，幾乎都是那份沒人整理、版本打架、掃描檔還是圖片讀不出字的舊資料。前期的盤點清洗、上線後的持續評估，遠比糾結模型型號重要。
- 不是每個問題都該走 RAG。要做全公司文件的跨檔彙總、要跑嚴謹的多步推理，單靠檢索幾段就未必夠，這類場景得搭配其他設計。RAG 最擅長、投報率最高的，始終是「針對既有文件庫的事實型問答」。
- 別急著用超長視窗取代 RAG。把整批文件硬塞進模型的超長對話視窗看似省事，但成本高，而且在夾雜大量「看似相關其實無關」的干擾內容時，模型反而容易被帶偏。先檢索、只餵相關段落，通常又便宜又準。
給南台灣企業的務實建議
講了這麼多機制，回到最實際的一句：中小企業真的不必一步到位。我給客戶的起手式，永遠是先挑「一個痛點明確、文件又相對乾淨」的場景試水溫——客服常見問答、內部規章查詢、報價料號對照，都是很好的第一站。範圍小，才好在兩三週內跑出可信的數字，用數字說服老闆，再一塊一塊往外擴，遠比一開始就想蓋一座無所不知的知識庫來得穩。
至於要放雲端還是自己機房，得看你的資料敏感度。報價成本、客戶名單、製程 know-how 這類東西，很多老闆一聽到「要上雲」就皺眉——這完全合理，這種場景就適合走地端／私有部署，資料一步都不離開你的廠區。廷皓科技就在高雄楠梓，服務高雄、台南、屏東一帶的企業，我們可以先幫你把資料現況盤清楚，再依敏感度與預算，規劃雲端或地端的 RAG 知識庫，一關一關幫你調到堪用、可稽核。手上那份「只有三個人懂」的資料，別再讓它躺在硬碟裡生灰——找我們聊聊，看怎麼讓它開口，替你講出公司的真話。
