準備 AI 應用或 AI 產品職位的面試，RAG 很難只答到「先檢索、再生成」。面試官一追問，就會碰到細節。這篇挑四題：使用者的問題要不要先改寫？好幾路檢索的結果怎麼合併、誰來排序？什麼情況用 RAG、什麼情況該微調？文件要怎麼切？
這四題都沒有唯一標準答案。比較穩的答法，是每題講清楚四件事：這是什麼、為什麼需要、你怎麼取捨、舉一個例子。下面每一節先說這題在確認什麼，再給答案骨架和一手出處，最後標出常說錯或該保留的地方。
圖解：KeepInAI。一次 RAG 查詢的示意流程，不是實測系統。
Query 改寫：先分清哪些是論文做法，哪些是工程經驗
這題多半是想確認你知道：使用者打進來的那句話，不一定是最好的檢索條件。口語、太短、指代不清的問題，直接拿去搜，容易找回不相干的段落。
答案骨架可以這樣排：改寫是在檢索之前，先把原始問題轉成更適合搜尋的形式；目的是讓檢索找得到該找的文件；做法有輕有重，取捨在成本、延遲和可控性。
能拿出來當依據的研究有兩篇。Ma 等人 2023 年發表、收錄於 EMNLP 2023 的 Rewrite-Retrieve-Read，把一般的「先檢索、再閱讀」改成先讓 LLM 產生查詢，再拿去檢索。論文另外提出一種做法：用一個小型語言模型當可訓練的改寫器，依後面 LLM 讀者的回饋，以強化學習調校。
另一篇是 Gao 等人 2022 年 12 月的 HyDE。它不直接改寫問題，而是讓指令型模型先為這個問題寫一份「假想文件」，再把這份文件轉成向量，去找真實文件。作者自己說得很清楚：假想文件抓得到相關性的樣態，但內容不是真的，可能含有錯誤細節。所以它只是找文件的媒介，不能當答案用。
實務上常聽到另一種說法：先用規則處理，處理不了再交給輕量模型，最後才動用大模型。這是常見的工程分層，用意多半是控制成本與延遲，但它是經驗做法。上面兩篇論文支撐的是「用 LLM 改寫」和「用小模型當改寫器」兩種做法，並沒有證明「規則改寫最穩」。面試時可以講這套分層，只是要說成你或業界的經驗，不要說成研究結論。
多路檢索怎麼合併：比的是名次，不是分數
這題在確認你知不知道一路檢索不夠，以及多路結果放在一起時會遇到什麼麻煩。
答案骨架分三層：召回、融合、重排。召回階段，關鍵字檢索（BM25）和向量檢索各自去找；融合階段把兩邊結果合併去重；重排階段再用 reranker 從候選裡挑出最相關的。
Anthropic 在 2024 年 9 月 19 日發表的 Contextual Retrieval 描述的就是這樣的流程：BM25 和 embedding 各自檢索，以 rank fusion 合併去重，再交給 reranker 過濾。它也說明了為什麼要兩路並用：BM25 能抓到識別碼這類需要精確比對的字詞，embedding 抓的是語意。原文的結論是「Embeddings+BM25 is better than embeddings on their own」。
融合這一步最值得講細。常見做法是 RRF（Reciprocal Rank Fusion）。依 Azure AI Search 的文件，每一路的結果按各自的名次以 1/(rank + k) 計分，再把各路分數相加；k 是常數，文件說設成 60 這類數值時表現較好。
為什麼不直接把原始分數加起來？因為各方法的分數範圍不同。照 Azure 文件的說明，BM25 的分數沒有上限，向量相似度則落在 0.333 到 1 或 0 到 1 之間（依相似度指標而定）。直接相加，等於讓分數範圍大的那一路說了算。改用名次，就只看「這份文件在每一路排第幾」。舉個算例：某段文件在 BM25 排第 1、在向量檢索排第 3，k 取 60 時，它的 RRF 分數是 1/61 加 1/63；另一段只在向量檢索排第 1、BM25 沒找到，分數就只有 1/61。在這個例子裡，兩路都找到的那段排在前面。Azure 的文件也寫明，語意重排是在 RRF 合併之後才做。
如果被問「這些做法實際有多少幫助」，可以引 Anthropic 那篇的數字，但要說清楚這是 Anthropic 自己的測試，而且量的是「脈絡化＋BM25＋重排」這組做法，不是只有融合這一層。它以 top-20 檢索失敗率衡量，基線是 5.7%。相對基線，加上 Contextual Embeddings 後降 35%（到 3.7%），再加 Contextual BM25 合計降 49%（到 2.9%），再加 reranking 合計降 67%（到 1.9%）。這組數字顯示的是在它的資料與設定下，這幾步的效果可以疊加；換一份資料、換一個模型，幅度不一定一樣。
常見的說錯有兩種。一是把 BM25 和向量分數直接相加或取平均，沒意識到兩者的尺度不同。二是把 reranker 說成另一種檢索：它處理的是已經找回來的候選，召回階段漏掉的文件，重排救不回來。
RAG 和微調不是二選一，微調也不等於強化學習
這題在確認你知不知道兩者各自解決什麼問題，以及能不能說出取捨的依據。
先講 RAG 為什麼存在。Lewis 等人 2020 年發表於 NeurIPS 2020 的 RAG 原論文指出，預訓練模型在三件事上仍有限：存取並精確操作知識、提供決策的出處、更新世界知識。RAG 的做法是接上一個可微分的非參數記憶，讓模型回答時去查外部資料。換句話說，資料常變、回答需要附出處的場景，RAG 比較對症。
再講兩者的關係。Microsoft 等人 2024 年 1 月的農業案例研究裡，微調帶來超過 6 個百分點的準確率提升，RAG 在微調之上再累加 5 個百分點。這說明兩者可以疊加，不必二選一。但這是單一領域的案例，面試時引用要說明它的範圍，不能推成「所有情況都是微調加 RAG 最好」。
至於大家常說的「RAG 見效快、成本低，微調慢又貴」，這是一般工程經驗，我們沒有查到對應的一手數據。可以這樣講，但要接上情境：例如資料每週都在更新、團隊沒有標註資料，那先做 RAG 比較實際；不要講成已被證實的比例或數字。
這一節最值得特別注意的說錯處，是把微調說成「就是強化學習」。微調有好幾種做法，不能一概而論：
- SFT 是監督式微調，用標註好的輸入與輸出訓練，不是強化學習。
- RLHF 的最後一步才是強化學習。DPO 原論文的作者就以此為對照：DPO 只用一個簡單的分類損失解決同一個問題，微調過程中也不需要從模型取樣。
所以「SFT、DPO 都是強化學習」不成立。比較準確的說法是：微調是一大類方法，有監督式的 SFT，有在最後一步用到強化學習的 RLHF，也有 DPO 這種刻意拿掉強化學習步驟的做法。前面 Query 改寫那一節提到的可訓練改寫器用了強化學習，那是那篇論文選的訓練方式，不代表微調等於強化學習。
切片沒有標準答案，要答出你怎麼取捨
這題在確認你知道切片會直接影響檢索，而且你處理過真實文件，不只是照教學把文字按固定長度切。
我們找到的一手依據不多，Anthropic 那篇是其中之一。它提到 chunk 通常不超過幾百個 token，而 chunk 的大小、邊界和重疊都會影響檢索表現。前一節那組數字裡，前兩步也是在 chunk 上動手：Contextual Retrieval 會在每個 chunk 前面加上一段簡短、專屬於這個 chunk 的脈絡，再拿去做 embedding 和 BM25 索引。光這兩步，在它的測試裡就讓失敗率降了 49%。
答案骨架可以這樣排：切多大、在哪裡切、要不要重疊，取決於文件長什麼樣子；判斷標準是切出來的那一塊單獨拿出來，還讀不讀得懂。
舉例時，可以講處理 PDF 的常見做法：先拆成單頁，判斷每頁的清晰度，再把表格、圖、段落等元素切開，做版面分析；圖表和它的標題一起切，格式雜亂的內容先清洗。也有人不建議只按固定長度一刀切，因為容易把表頭和內容、條件和例外切散。這些都是工程經驗，沒有統一的一手出處，面試時當成「我會這樣做，原因是……」來講，比當成標準答案更站得住。
常見的說錯，是把某個 chunk 大小或某套切法講成通用最佳值。Anthropic 給的也只是「通常不超過幾百 token」這種範圍，沒有給一個放諸四海皆準的數字。
先拿自己的專案對一遍
讀完之後，最實際的下一步是拿你做過的 RAG 專案，把四題各寫下四行：你做了什麼、為什麼這樣做、放棄了什麼、有沒有一個具體例子或數字。寫不出來的那一題，就是面試最可能被追問卡住的地方。
如果你的專案遇過「資料明明在知識庫裡，回答還是錯」的情況，站上另一篇〈RAG 有資料卻答錯：FDE 該從哪裡查起？〉從解析、切塊到 trace 逐層追錯，可以拿來補切片和檢索兩題的例子。
