1. 為什么RAG成了面試的“必考題”如果你最近一年面過AI應用崗不管是做大模型應用開發(fā)、算法工程還是AI產品經(jīng)理大概率會被問到RAG。原因很直接大模型本身的知識有截止日期企業(yè)內部文檔又不可能全部拿去重新訓練RAGRetrieval-Augmented Generation檢索增強生成就成了讓模型“開卷考試”的最實用方案。它不改變模型參數(shù)而是在生成之前先檢索一批相關資料塞進上下文讓模型基于這些資料回答。我面過也面過別人發(fā)現(xiàn)一個規(guī)律很多人能把RAG流程背出來——文檔切塊、向量化、檢索、拼prompt、生成但一旦追問“切塊大小怎么定”“召回不準怎么辦”“檢索和生成誰背鍋”就開始含糊。這篇文章我打算把RAG面試里最常被連環(huán)追問的六個方向拆開講透從原理到優(yōu)化每個問題都給出我自己的理解和實操經(jīng)驗。適合準備面試的開發(fā)者、正在搭RAG系統(tǒng)的工程師以及想搞清楚RAG到底難在哪的產品同學。先給一個整體認知RAG的難點從來不是“能不能跑通”而是“跑通之后效果不好你知不知道問題出在哪個環(huán)節(jié)”。面試官真正想考的是你有沒有一套定位和優(yōu)化的方法論。2. 第一問RAG的基本鏈路到底在解決什么問題2.1 把RAG拆成兩個階段來看很多人一上來就背“檢索增強生成”但面試官更想聽你把鏈路拆清楚。我習慣把它分成離線索引階段和在線查詢階段。離線索引階段做三件事文檔解析、切塊chunking、向量化入庫。文檔解析要把PDF、Word、HTML這些格式統(tǒng)一轉成純文本這一步的坑最多表格、頁眉頁腳、多欄排版經(jīng)常被解析得亂七八糟。切塊是把長文本切成適合檢索的小段。向量化是用embedding模型把每段文本轉成一個高維向量存進向量數(shù)據(jù)庫。在線查詢階段做四件事把用戶問題向量化、在向量庫里做相似度檢索、把召回的內容和問題拼成prompt、交給大模型生成答案。有些系統(tǒng)還會加一步重排序rerank放在檢索之后、生成之前。面試時如果只答“檢索然后生成”基本會被判定為沒做過。把離線和在線分開講立刻顯得你理解系統(tǒng)的全貌。2.2 為什么是“檢索增強”而不是“微調”這是高頻追問。我的回答邏輯是微調改變的是模型的“內在知識”成本高、更新慢而且容易災難性遺忘RAG改變的是模型的“輸入上下文”知識更新只需要更新文檔庫成本低、可追溯。企業(yè)場景里文檔每天都在變用微調去追這個變化不現(xiàn)實。但要注意RAG和微調不是對立的。如果任務是讓模型學會一種特定的回答風格或輸出格式微調更合適如果是讓模型回答特定知識庫里的問題RAG更合適。實際項目里兩者經(jīng)常結合先微調讓模型學會“基于給定資料回答”再用RAG喂資料。2.3 一個容易被忽略的前提檢索質量決定上限我經(jīng)常跟團隊里新人說一句話RAG的效果上限由檢索決定生成模型只是把檢索到的東西組織成話。如果檢索階段沒把正確資料撈出來再強的生成模型也只能瞎編或者拒答。所以面試里凡是問到優(yōu)化優(yōu)先談檢索側的優(yōu)化而不是一上來就說換更大的模型。3. 第二問文檔切塊到底怎么切才合理3.1 切塊大小沒有標準答案但有判斷依據(jù)“chunk size設多少”是RAG面試的經(jīng)典問題。我的經(jīng)驗是沒有萬能值取決于文檔類型和問題類型。常見起點是256到512個token但這只是起點。判斷依據(jù)有三條。第一看問題的粒度。如果用戶問的是“某條款的具體規(guī)定”需要小chunk保證精度如果問的是“某事件的整體經(jīng)過”需要大chunk保證上下文完整。第二看embedding模型的最佳輸入長度。很多模型在512token左右表現(xiàn)最好超過之后語義會被稀釋。第三看生成階段能塞多少上下文。chunk太大召回幾個就撐爆上下文窗口。我一般會做一組對比實驗同一批問題分別用256、512、1024的chunk跑一遍看召回率和最終答案質量。實測下來技術文檔512比較穩(wěn)法律合同256更準敘事類內容1024反而更好。3.2 重疊overlap不是越大越好切塊時通常會讓相鄰塊有重疊防止一句話被切斷導致語義丟失。常見做法是重疊10%到20%。但我踩過一個坑重疊設太大檢索時會召回一堆高度相似的塊浪費上下文還干擾生成。后來我把重疊控制在50到100個token效果反而更干凈。3.3 比固定切塊更好的幾種策略固定長度切塊最省事但經(jīng)常把語義切碎。我在項目里試過幾種改進方案按語義切塊用句子邊界、段落邊界切保證每塊語義完整?？梢杂煤唵蔚囊?guī)則按句號、換行也可以用模型判斷語義轉折點。按結構切塊Markdown按標題層級切代碼按函數(shù)切HTML按標簽切。這種切法保留了文檔的天然結構檢索時命中率明顯更高。父子塊small-to-big檢索時用小chunk保證精度但送給生成模型時把它所在的父級大塊一起帶上兼顧精度和上下文。這個策略我在實際項目里用得最多效果提升明顯。面試時如果能說出“小chunk檢索、大chunk生成”這個思路基本能證明你真正調過系統(tǒng)而不是只看過流程圖。4. 第三問向量檢索召回不準問題出在哪4.1 先分清是“沒召回”還是“召回錯了”召回不準分兩種。一種是正確資料根本沒被檢索出來叫召回失敗另一種是正確資料在里面但排得太靠后叫排序問題。這兩種的解法完全不同面試時先做這個區(qū)分會顯得你思路清晰。召回失敗常見原因embedding模型和領域不匹配、切塊把關鍵信息切碎了、query和文檔的表述差異太大比如用戶說“報銷流程”文檔寫“費用核銷指引”。排序問題常見原因相似度算法單一、沒有重排序、噪聲塊太多。4.2 混合檢索向量加關鍵詞純向量檢索對語義相似但字面不同的情況好但對專有名詞、編號、代碼這類精確匹配反而弱。我的做法是向量檢索加BM25關鍵詞檢索兩路結果融合。融合算法常用RRFReciprocal Rank Fusion它不依賴分數(shù)歸一化直接按排名融合實現(xiàn)簡單還穩(wěn)。實測下來混合檢索在技術文檔和客服知識庫場景里召回率比純向量能提升一截。代價是要維護兩套索引查詢延遲也會增加需要權衡。4.3 重排序Rerank是性價比最高的優(yōu)化檢索召回一批候選比如top 50再用一個交叉編碼器cross-encoder對每個候選和query做精細打分重新排序取top 5。這一步能顯著提升送入生成模型的資料質量。我一般把rerank當作RAG優(yōu)化的第一優(yōu)先級因為它改動小、收益大。embedding模型是雙塔結構query和文檔分開編碼快但粗cross-encoder把query和文檔拼在一起編碼慢但準。用粗排召回、精排重排是工業(yè)界的標準做法。4.4 查詢改寫讓用戶的問題更好檢索用戶的問題往往口語化、有指代、缺上下文。直接拿去做檢索效果差。常見改寫手段指代消解把“它”“這個”替換成具體對象需要結合對話歷史。查詢擴展用大模型把原問題改寫成多個相關查詢分別檢索再合并。HyDE讓模型先“幻想”一個答案再用這個答案去檢索。因為答案和文檔的表述風格更接近檢索效果有時更好。這幾種我在項目里都用過HyDE在冷啟動、文檔表述和問題表述差異大時特別有用但會增加一次模型調用延遲要算進去。5. 第四問檢索做好了生成還是胡編怎么辦5.1 先確認是不是“檢索背鍋”生成胡編第一反應不該是怪模型而是回去看檢索到的資料里到底有沒有答案。我見過太多情況是檢索沒召回正確內容模型只能硬編。所以排查順序永遠是先看召回內容再看prompt最后才懷疑模型。5.2 Prompt里的約束怎么寫才有效讓模型“基于以下資料回答”這句話太弱了。我一般會加幾條硬約束明確要求“只使用提供的資料回答資料中沒有的信息不要編造”。要求“如果資料不足以回答直接說不知道”。要求“回答時標注依據(jù)來自哪段資料”。但光靠prompt約束不夠模型該編還是編。更可靠的做法是讓模型輸出引用然后做后置校驗如果答案里的關鍵信息在召回資料里找不到對應就標記為可疑或觸發(fā)兜底。5.3 用“不知道”兜底比硬答更重要企業(yè)場景里答錯比不答代價大得多。我在系統(tǒng)里加了一個置信度判斷如果檢索到的資料和query的相似度都低于某個閾值直接返回“暫時沒有找到相關信息”而不是讓模型硬答。這個閾值需要根據(jù)業(yè)務容忍度調寧可多拒答幾次也別放錯誤答案出去。5.4 上下文塞太多反而變差有個反直覺的現(xiàn)象召回資料塞得越多生成質量不一定越好。噪聲多了模型會被干擾還可能“迷失在中間”lost in the middle——只關注開頭和結尾的資料中間的被忽略。所以召回數(shù)量要控制配合rerank取最相關的幾條通常3到5條就夠。6. 第五問RAG系統(tǒng)怎么評估不能只靠感覺6.1 檢索和生成要分開評RAG評估最大的誤區(qū)是只看最終答案好不好。答案不好你根本不知道是檢索的鍋還是生成的鍋。所以要拆成兩塊評。檢索側指標召回率正確資料有沒有被召回、命中率top k里有沒有正確資料、MRR正確資料的排名。生成側指標忠實度答案是否忠于資料、相關性答案是否切題、完整性。6.2 沒有標注數(shù)據(jù)怎么辦真實項目里往往沒有現(xiàn)成的標注。我的做法是先用大模型自動生成一批“問題-答案-依據(jù)”三元組作為評測集人工抽檢修正。然后用這套集子跑評估。雖然自動生成的集子有噪聲但用來做版本對比足夠了——你不需要絕對分數(shù)只需要知道新版本比舊版本好還是差。6.3 用LLM當裁判的注意事項用大模型給答案打分LLM-as-a-judge現(xiàn)在很流行但有幾個坑模型有位置偏好傾向給靠前的答案高分、有長度偏好傾向給長答案高分。我的應對是打分時交換答案順序取平均控制答案長度相近并且用明確的評分標準而不是讓模型自由發(fā)揮。評估這件事面試時能說出“檢索生成分開評”和“用LLM當裁判的偏差”基本就超過大多數(shù)候選人了。7. 第六問線上RAG系統(tǒng)的性能與成本怎么平衡7.1 延遲都花在哪了一個RAG請求的延遲大致分四塊query向量化、向量檢索、rerank、生成。生成通常是大頭尤其是長答案。檢索和rerank相對快但如果候選集大、rerank模型重也會拖慢。優(yōu)化延遲的常見手段向量檢索用近似最近鄰ANN索引而不是暴力搜索rerank只對top候選做生成用流式輸出讓用戶先看到部分內容。我一般會先測出各階段耗時占比再決定優(yōu)化哪塊而不是盲目換模型。7.2 成本控制的實際做法成本主要來自embedding調用、向量庫存儲、rerank調用、生成token。幾個實用做法緩存高頻問題直接緩存答案命中就不走全鏈路。分級檢索先用便宜的檢索召回再用貴的rerank精排別一上來就全用重模型。控制上下文長度召回資料精簡生成token自然少。embedding批處理離線索引時批量調用比逐條便宜也快。7.3 一個我踩過的坑索引更新文檔庫是動態(tài)的新增、修改、刪除都要同步到向量庫。我早期沒設計好更新機制導致檢索到已刪除的舊文檔答案過時。后來改成給每個塊打上文檔ID和版本號更新時按文檔ID批量替換刪除時同步清理。這塊在面試里如果主動提到會顯得你有工程落地經(jīng)驗而不是只搭過demo。8. 面試里那些“送分”和“送命”的細節(jié)8.1 主動說出權衡比背標準答案加分RAG沒有銀彈每個選擇都是權衡。面試時如果你能說“我選512的chunk是因為……但代價是……”比直接報一個數(shù)字強得多。面試官想招的是能做決策的人不是背參數(shù)的人。8.2 別把RAG說成萬能有人一被問就吹RAG能解決所有知識問題。實際上RAG對結構化數(shù)據(jù)查詢、多跳推理、需要全局統(tǒng)計的問題都不擅長。承認邊界反而顯得你理解深。比如問“一共有多少條記錄”這種RAG不如直接查數(shù)據(jù)庫。8.3 準備一個你真正調過的案例面試最怕空談。準備一個你實際做過的RAG項目能說清楚原始效果多少、問題出在哪、你做了什么優(yōu)化、優(yōu)化后提升多少。哪怕數(shù)據(jù)不精確有具體的排查過程就足夠有說服力。我自己面人時最看重的就是候選人能不能講出一個“從壞到好”的完整故事。最后分享一個我自己的習慣每次做完一個RAG項目我都會把“哪個環(huán)節(jié)最容易出問題、當時怎么定位的”記下來。攢多了你會發(fā)現(xiàn)RAG的坑其實就那么幾類面試時隨手就能舉出例子。這比臨時背八股文管用得多。