1. 為什么這8個問題成了LLM崗位的硬門檻面過LLM崗位的人大概都有這種體驗簡歷上寫著“熟悉Transformer”“做過RAG項目”“微調(diào)過開源模型”結(jié)果面試官第一個問題就把人問住了。不是問得多偏而是問得太基礎——基礎到很多人以為自己會實際上答不完整。我參與過不少輪大模型方向的技術面試也幫朋友做過模擬面。一個很明顯的規(guī)律是能把這8個問題答利索的人不一定做過最炫的項目但答不上來的人基本在初篩階段就被劃掉了。原因很簡單LLM崗位現(xiàn)在不缺“調(diào)包俠”缺的是真正理解模型內(nèi)部在發(fā)生什么、知道工程邊界在哪的人。面試官問這些問題不是考記憶力是在判斷你有沒有能力在模型出問題時定位到根因。這8個問題大致覆蓋了這幾個方向Transformer架構(gòu)的核心機制、Tokenization的實際影響、注意力計算的復雜度、位置編碼的演進、Function Calling的工程實現(xiàn)、模型幻覺的成因與緩解、上下文窗口的管理策略、以及微調(diào)與提示工程的取舍。每一個都不是孤立的知識點而是串起來構(gòu)成了一條“從輸入文本到模型輸出”的完整鏈路。你答得上一個說明你懂一個環(huán)節(jié)你能把幾個串起來講清楚面試官才會認為你真的做過端到端的事情。這篇文章我打算按面試的真實節(jié)奏來寫不是教科書式的知識點羅列而是把每個問題拆成“面試官到底想聽什么”“標準答案的骨架是什么”“哪些細節(jié)能加分”“哪些回答會直接減分”四個層面。中間會穿插我自己踩過的坑和帶人時發(fā)現(xiàn)的常見誤區(qū)。適合正在準備LLM崗位面試的人也適合已經(jīng)入行但想系統(tǒng)梳理一遍底層邏輯的工程師。2. Transformer架構(gòu)面試官真正想確認的三件事2.1 自注意力到底在算什么別只背公式幾乎每場LLM面試都會從Transformer切入但面試官問法差別很大。初級崗位可能直接問“Self-Attention的公式是什么”高級崗位則會問“為什么Self-Attention比RNN更適合長序列建?！?。這兩種問法背后考察的深度完全不同。先說公式層面。Self-Attention的核心計算是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V這個公式很多人能默寫但面試官真正想確認的是你理解每一步在干什么。Q和K的點積是在計算“當前token和其他token的相關性分數(shù)”除以sqrt(d_k)是為了防止點積結(jié)果過大導致softmax梯度消失softmax把分數(shù)歸一化成權重最后用這些權重對V做加權求和。關鍵點在于這個過程是并行的每個token的位置輸出可以同時計算不依賴前一個時間步的結(jié)果。這正是Transformer比RNN快的原因也是它能擴展到超長序列的基礎。面試官如果追問“為什么要除以sqrt(d_k)”你要能說出假設Q和K的每個分量都是獨立同分布、均值0方差1的隨機變量那么它們的點積的方差就是d_k。當d_k很大時點積的數(shù)值范圍會很大softmax的輸出會趨近于one-hot梯度會變得極小。除以sqrt(d_k)就是把方差拉回到1附近保持梯度的穩(wěn)定性。這個解釋比單純說“防止梯度消失”要具體得多面試官一聽就知道你是真理解而不是背的。2.2 多頭注意力不是簡單的并行而是子空間投影Multi-Head Attention經(jīng)常被誤解成“把Self-Attention跑幾遍然后拼起來”。這個理解不算錯但太淺了。面試官想聽的是多頭機制讓模型在不同的表示子空間里學習不同的注意力模式。具體來說假設模型維度是512頭數(shù)是8那么每個頭的維度就是64。輸入經(jīng)過線性變換后被拆成8組Q、K、V每組獨立做注意力計算最后把8個頭的輸出拼接起來再過一層線性變換。這樣做的好處是一個頭可能關注語法依賴關系另一個頭可能關注語義相似度還有一個頭可能關注位置鄰近性。如果只有一個頭這些模式會混在一起模型很難同時學好。我在實際調(diào)試模型時發(fā)現(xiàn)一個有意思的現(xiàn)象某些頭在訓練后會變得“幾乎不活躍”注意力權重接近均勻分布。這說明模型自己學會了某些頭不需要特別關注特定模式。面試時如果你能提到這一點說明你不僅看過論文還實際觀察過模型行為這是很強的加分項。2.3 殘差連接和LayerNorm的位置選擇有講究Transformer的每個子層后面都有殘差連接和LayerNorm但這兩者的順序在不同變體里是不一樣的。原始論文用的是Post-LN先做Attention/FFN再殘差LayerNorm后來很多模型改成了Pre-LN先LayerNorm再做Attention/FFN最后殘差。這個區(qū)別在面試中經(jīng)常被忽略但它直接影響訓練穩(wěn)定性。Post-LN在深層模型中容易出現(xiàn)梯度消失需要小心的學習率預熱Pre-LN則更穩(wěn)定但表達能力和最終性能可能略有差異。如果你面的是需要手寫Transformer的崗位面試官可能會讓你解釋為什么現(xiàn)在主流模型大多用Pre-LN或者RMSNorm。RMSNorm是LayerNorm的簡化版去掉了均值中心化只做方差歸一化計算更快且效果相當。這些細節(jié)能答上來說明你對架構(gòu)演進有跟蹤。3. Tokenization被低估的面試重災區(qū)3.1 BPE、WordPiece和SentencePiece的區(qū)別不只是算法Tokenization看起來是個預處理步驟但它在面試中的出現(xiàn)頻率遠超很多人的預期。原因很實際Tokenization直接決定了模型的輸入長度、詞表大小、多語言能力和對未登錄詞的處理方式。面試官問這個問題是在判斷你有沒有處理過真實數(shù)據(jù)。BPEByte Pair Encoding的核心思想是從字符級別開始不斷合并出現(xiàn)頻率最高的相鄰字符對直到達到預設的詞表大小。WordPiece和BPE類似但合并的標準不是頻率而是似然增益。SentencePiece則更進一步它把空格也當作普通字符處理不依賴預分詞因此對中文、日文等沒有明顯詞邊界的語言更友好。面試中常見的追問是“為什么GPT系列用BPE而BERT用WordPiece”這個問題沒有標準答案但你可以從工程角度回答B(yǎng)PE的實現(xiàn)更簡單合并規(guī)則更直觀適合大規(guī)模訓練WordPiece在相同詞表大小下可能產(chǎn)生更少的token對英文任務更高效。關鍵是要說明選擇取決于具體場景而不是哪個絕對更好。3.2 中文Tokenization的坑比英文多得多如果你面的是國內(nèi)團隊中文Tokenization幾乎必問。一個典型的坑是很多開源模型的中文詞表覆蓋不足導致一個常用漢字被拆成多個byte token。比如“你好”在某些模型里可能被編碼成3到4個token而英文的“hello”只有1個token。這直接導致中文輸入的有效上下文長度縮水推理成本上升。我在實際項目中遇到過這種情況同一個模型英文輸入2000 token能處理的內(nèi)容中文輸入需要3500 token才能表達同樣的信息量。解決辦法通常是在微調(diào)時擴充中文詞表或者選擇原生支持中文的模型。但擴充詞表會改變embedding層的維度需要重新訓練或至少做embedding對齊這是有成本的。面試時如果你能說出這個trade-off面試官會認為你真正處理過中文場景。另一個常見問題是特殊token的處理。比如padding token、CLS token、SEP token在不同模型里的定義和使用方式不同。如果你在面試中被問到“如何計算一個batch里不同長度序列的attention mask”你要能說清楚padding位置的mask要設為負無窮這樣softmax之后權重為0不會影響有效token的表示。3.3 詞表大小對模型性能的隱性影響詞表大小是一個需要權衡的參數(shù)。詞表太小常見詞被拆成多個token序列變長計算量增加詞表太大embedding矩陣參數(shù)量膨脹低頻詞訓練不充分而且softmax層的計算量也會增加。一般來說英文模型的詞表在3萬到5萬之間比較常見多語言模型可能到10萬以上。但詞表大小不是越大越好關鍵要看詞頻分布和語言覆蓋。面試時如果被問到“給你一個垂直領域的數(shù)據(jù)集你會怎么設計詞表”你可以從這幾個角度回答先統(tǒng)計領域內(nèi)的高頻詞和專有名詞確保它們不被拆碎保留通用詞表的基礎部分以維持泛化能力對領域特有詞做增量合并。這個回答既展示了技術理解也展示了工程思維。4. 位置編碼從正弦函數(shù)到RoPE的演進邏輯4.1 為什么Self-Attention本身不知道順序Transformer的Self-Attention有一個根本性的特點它對輸入序列的順序是不敏感的。也就是說如果把“貓追狗”和“狗追貓”的token打亂順序輸入在沒有位置編碼的情況下注意力計算的結(jié)果是一樣的。這顯然不符合語言理解的需求。位置編碼就是用來解決這個問題的。原始Transformer用的是正弦位置編碼通過不同頻率的sin和cos函數(shù)為每個位置生成一個唯一的向量然后直接加到token的embedding上。這種編碼的好處是不需要訓練可以外推到訓練時沒見過的長度缺點是外推能力有限而且在深層模型中位置信息容易衰減。面試中如果問“正弦位置編碼為什么能表示相對位置”你要能解釋對于任意固定的偏移量k位置pk的編碼可以表示為位置p編碼的線性變換。這個性質(zhì)使得模型能夠?qū)W習到相對位置關系而不僅僅是絕對位置。但實際中這種線性關系在訓練后是否被模型有效利用是有爭議的。4.2 可學習位置編碼的局限與RoPE的突破可學習位置編碼如BERT使用的把每個位置的embedding作為參數(shù)訓練優(yōu)點是靈活缺點是無法處理超過最大訓練長度的序列。如果訓練時最大長度是512推理時來了一個600長度的輸入后面88個位置沒有對應的embedding只能截斷或報錯。RoPERotary Position Embedding是目前主流大模型廣泛采用的位置編碼方案。它的核心思想不是“加”位置信息而是通過旋轉(zhuǎn)矩陣把位置信息“乘”進Q和K的表示里。具體來說對于位置m的query向量和位置n的key向量它們的點積會自然地包含一個與(m-n)相關的旋轉(zhuǎn)角度。這意味著RoPE天然編碼了相對位置信息而且理論上可以外推到更長的序列。我在實際使用中發(fā)現(xiàn)RoPE的外推能力也不是無限的。當推理長度遠超訓練長度時注意力分數(shù)會出現(xiàn)異常模型輸出質(zhì)量明顯下降。常見的緩解方法包括位置插值把長序列的位置映射回訓練時的范圍和NTK-aware縮放。面試時如果能提到這些工程技巧說明你不只是知道RoPE的概念還處理過實際的長文本問題。4.3 ALiBi和其他輕量方案的取舍ALiBiAttention with Linear Biases是另一種位置編碼方案它不修改embedding而是在注意力分數(shù)上直接加一個與距離成正比的偏置項。距離越遠偏置越負注意力權重越小。這種方案的優(yōu)點是實現(xiàn)極簡外推能力好缺點是它假設位置關系是單調(diào)遞減的對于某些需要長距離依賴的任務可能不夠靈活。面試中如果被問到“你會選哪種位置編碼”不要直接說“RoPE最好”。更好的回答是看任務需求。如果是標準的大模型預訓練RoPE是目前的主流選擇生態(tài)支持好如果推理時需要處理超長序列且不想做復雜的縮放ALiBi可能更省事如果是特定領域的短序列任務可學習位置編碼也夠用。展示出你根據(jù)場景做選擇的能力比給出一個絕對答案更重要。5. Function Calling從Prompt技巧到工程協(xié)議5.1 Function Calling不是簡單的JSON輸出Function Calling是LLM應用開發(fā)中的核心能力也是面試中區(qū)分“做過Demo”和“做過產(chǎn)品”的分水嶺。很多人以為Function Calling就是讓模型輸出一段JSON然后解析出來調(diào)用函數(shù)。這個理解太表面了。真正的Function Calling涉及幾個層面模型需要理解用戶的自然語言意圖判斷是否需要調(diào)用工具選擇合適的工具提取正確的參數(shù)處理參數(shù)缺失或格式錯誤的情況最后把工具返回的結(jié)果整合回自然語言回復。這是一個完整的閉環(huán)任何一個環(huán)節(jié)出問題都會導致體驗崩潰。面試中常見的問題是“如果模型輸出的JSON格式不對怎么辦”初級回答是“用正則表達式提取”或“重試”。更好的回答是在prompt中明確約束輸出格式使用JSON Schema做校驗如果校驗失敗則把錯誤信息反饋給模型讓它重新生成。更工程化的做法是在解碼階段做約束比如用語法引導的解碼grammar-constrained decoding強制模型只能輸出合法的JSON。這個回答能體現(xiàn)出你對生產(chǎn)環(huán)境可靠性的理解。5.2 工具描述的設計比模型能力更關鍵在實際項目中Function Calling的成功率很大程度上取決于工具描述的質(zhì)量。我見過太多團隊把工具描述寫得含糊不清然后抱怨模型“太笨”。其實問題出在描述上。一個好的工具描述應該包含工具的功能一句話概括、每個參數(shù)的類型和含義、參數(shù)的取值范圍或枚舉值、什么情況下應該調(diào)用這個工具、什么情況下不應該調(diào)用。這些信息要寫得像給一個新員工看的文檔而不是像給機器看的代碼注釋。模型對自然語言的理解能力很強但它不會猜你的意圖。舉個例子如果你有一個查詢天氣的工具描述里只寫“獲取天氣信息”模型可能在你問“今天適合穿什么”的時候不調(diào)用它。但如果你寫“當用戶詢問天氣、溫度、是否下雨、穿衣建議時調(diào)用此工具”模型的調(diào)用準確率會明顯提升。面試時如果你能舉出這種具體的優(yōu)化案例比空談“優(yōu)化prompt”有說服力得多。5.3 多工具場景下的選擇與編排當系統(tǒng)里有幾十個工具時Function Calling的難度會指數(shù)級上升。模型需要在眾多工具中選擇正確的那個還要處理工具之間的依賴關系。比如用戶說“幫我訂一張明天去北京的機票然后預約一個接機服務”這需要先調(diào)用航班查詢工具拿到結(jié)果后再調(diào)用接機預約工具而且接機時間要依賴航班到達時間。這種編排邏輯目前主要靠兩種方式實現(xiàn)一種是在prompt里寫清楚工具之間的依賴關系和調(diào)用順序另一種是用外部的編排引擎如狀態(tài)機或工作流引擎來管理。前者靈活但不可靠后者可靠但需要額外開發(fā)。面試時如果被問到“如何保證多步工具調(diào)用的正確性”你可以說對于關鍵業(yè)務流程不要完全依賴模型的自主編排而是用代碼定義好狀態(tài)轉(zhuǎn)移模型只負責在每一步做局部決策。這個回答體現(xiàn)了你對可靠性的重視。6. 幻覺問題面試官想聽的不是“用RAG”6.1 幻覺的根源在訓練目標和解碼策略“模型為什么會產(chǎn)生幻覺”是LLM面試的高頻問題。很多人第一反應是“因為訓練數(shù)據(jù)不夠”或“因為模型不夠大”。這些回答不算錯但沒有觸及本質(zhì)?；糜X的根本原因在于語言模型的訓練目標是最大化下一個token的似然概率而不是保證事實正確性。模型學到的是“什么樣的文本看起來合理”而不是“什么是真的”。當模型遇到訓練數(shù)據(jù)中少見或沒有的情況時它會根據(jù)學到的語言模式“編造”一個看起來合理的答案而不是說“我不知道”。另一個重要因素是解碼策略。貪心解碼每次選概率最高的token容易陷入重復和保守輸出束搜索Beam Search會探索多條路徑但可能選出整體概率高但事實錯誤的序列采樣Sampling增加了多樣性但也增加了隨機性帶來的錯誤。溫度參數(shù)調(diào)高幻覺概率通常上升調(diào)低輸出變得保守但可能更準確。面試時如果你能把這些因素串起來講說明你對生成過程有完整的理解。6.2 RAG不是萬能藥檢索質(zhì)量決定上限RAG檢索增強生成被很多人當成解決幻覺的銀彈。但實際上RAG的效果高度依賴檢索質(zhì)量。如果檢索到的文檔不相關或包含錯誤信息模型會基于錯誤信息生成更“自信”的錯誤答案這比沒有RAG更糟糕。我在實際項目中的經(jīng)驗是RAG系統(tǒng)的瓶頸通常在檢索環(huán)節(jié)而不是生成環(huán)節(jié)。向量檢索的召回率、chunk的切分策略、embedding模型的選擇、rerank的引入每一個環(huán)節(jié)都會影響最終效果。面試時如果被問到“如何設計一個RAG系統(tǒng)”不要只講“把文檔切塊、向量化、檢索、拼接prompt”這個流水線而要講清楚每個環(huán)節(jié)的取舍。比如chunk大小是固定長度還是按語義切分embedding模型是用通用的還是領域微調(diào)的檢索后要不要做rerank這些細節(jié)才是區(qū)分經(jīng)驗深淺的地方。6.3 讓模型說“不知道”比讓它答對更難一個反直覺的事實是訓練模型在不確定時輸出“我不知道”比訓練它答對問題更難。因為訓練數(shù)據(jù)里幾乎沒有“我不知道”這種表達模型沒有學過在什么情況下應該拒絕回答。常見的做法包括在prompt里明確指示“如果信息不足請回答不知道”用RLHF訓練模型校準置信度在系統(tǒng)層面加一個置信度閾值低于閾值時直接返回兜底話術。但這些方法都有局限。prompt指示容易被模型忽略RLHF需要大量標注數(shù)據(jù)置信度閾值很難設定得準確。面試時如果被問到這個問題你可以說完全消除幻覺目前不現(xiàn)實工程上的目標是“可控”。對于高風險場景不要讓模型直接輸出最終答案而是讓模型輸出結(jié)構(gòu)化的信息由外部系統(tǒng)做校驗和兜底。這個思路比追求“零幻覺”更務實。7. 上下文窗口不是越大越好而是越有效越好7.1 長上下文的“迷失中間”現(xiàn)象現(xiàn)在很多模型宣稱支持128K甚至更長的上下文但實際使用中你會發(fā)現(xiàn)模型對上下文中間部分的信息利用率明顯低于開頭和結(jié)尾。這就是所謂的“Lost in the Middle”現(xiàn)象。原因和注意力機制的特性有關。在長序列中注意力權重容易集中在開頭如系統(tǒng)prompt和結(jié)尾如最近的對話中間部分的信息被“淹沒”。這不是模型容量不夠而是注意力分配的問題。面試時如果被問到“如何處理長文檔問答”你可以說不要把所有內(nèi)容一股腦塞進上下文而是先用檢索或摘要的方式篩選出最相關的片段再送給模型。這比單純擴大上下文窗口更有效。7.2 上下文壓縮的幾種實用策略在實際工程中上下文管理是一個持續(xù)優(yōu)化的過程。常見的策略包括滑動窗口只保留最近N輪對話、摘要壓縮把歷史對話總結(jié)成一段話、關鍵信息提取只保留實體和意圖相關的信息、分層記憶短期記憶用完整對話長期記憶用向量檢索。每種策略都有代價?；瑒哟翱诤唵蔚珪G失早期信息摘要壓縮需要額外的模型調(diào)用增加延遲和成本關鍵信息提取需要設計抽取規(guī)則可能漏掉重要細節(jié)分層記憶架構(gòu)復雜調(diào)試難度高。面試時如果你能說出這些trade-off并給出一個你實際用過的方案和效果會非常有說服力。7.3 位置編碼外推與注意力稀疏化的工程取舍從模型層面看支持長上下文需要解決兩個問題位置編碼的外推和注意力計算的復雜度。RoPE的位置插值和NTK縮放是常見的解決方案但它們會改變注意力分布可能影響短序列的性能。注意力稀疏化如只計算局部窗口或固定模式的注意力可以降低計算量但會損失全局信息。目前沒有一個完美的方案工程上通常是根據(jù)業(yè)務場景做取舍。如果業(yè)務主要是短對話不需要折騰長上下文如果是文檔分析可能需要結(jié)合檢索和分塊策略如果是代碼生成長上下文的收益可能更明顯因為代碼的依賴關系跨度大。面試時展示出你根據(jù)場景做技術選型的能力比背誦某個方案的細節(jié)更重要。8. 微調(diào)與提示工程什么時候該動模型什么時候不該8.1 提示工程的邊界在哪里提示工程是成本最低的適配方式但它有明確的邊界。當任務需要模型掌握訓練數(shù)據(jù)中不存在的新知識、新格式或新風格時提示工程的天花板很快就到了。你可以通過few-shot示例讓模型學會一個簡單的分類任務但你很難通過提示讓模型學會一個它從未見過的專業(yè)術語體系。面試中常見的問題是“什么時候選擇微調(diào)而不是提示工程”一個實用的判斷標準是如果任務可以通過清晰的指令和少量示例描述清楚優(yōu)先用提示工程如果任務需要模型內(nèi)化大量領域知識、遵循復雜的輸出格式、或者對延遲和成本有嚴格要求微調(diào)后可以用更小的模型則考慮微調(diào)。8.2 LoRA和全量微調(diào)的選型邏輯LoRALow-Rank Adaptation是目前最流行的參數(shù)高效微調(diào)方法。它的核心思想是在預訓練模型的權重矩陣旁邊加一個低秩分解的旁路只訓練這個旁路凍結(jié)原始權重。這樣做的好處是顯存占用小、訓練速度快、可以快速切換不同任務的適配器。但LoRA不是萬能的。如果目標任務和預訓練任務差異很大或者需要模型學習全新的能力LoRA的低秩假設可能不夠用全量微調(diào)或至少更大的秩可能更合適。面試時如果被問到“LoRA的秩怎么選”你可以說從8或16開始試觀察驗證集效果如果欠擬合就增大秩如果過擬合就減小秩或增加dropout。關鍵是要有實驗設計的思路而不是給一個固定值。8.3 數(shù)據(jù)質(zhì)量比數(shù)據(jù)數(shù)量重要一個數(shù)量級無論是微調(diào)還是提示工程數(shù)據(jù)質(zhì)量都是決定效果的核心因素。我見過太多團隊花大量時間收集了幾萬條數(shù)據(jù)結(jié)果效果還不如精心構(gòu)造的幾百條。低質(zhì)量數(shù)據(jù)的典型特征包括標注不一致、格式混亂、包含錯誤信息、覆蓋不均衡。一個實用的做法是先人工構(gòu)造100到200條高質(zhì)量樣本用它們做few-shot或微調(diào)觀察效果。如果效果不錯再逐步擴充數(shù)據(jù)如果效果不好先檢查數(shù)據(jù)質(zhì)量而不是盲目增加數(shù)量。面試時如果你能分享這種“小步快跑”的數(shù)據(jù)迭代經(jīng)驗比空談“數(shù)據(jù)很重要”有說服力得多。9. 面試中的表達策略知道和講清楚是兩回事9.1 用“問題-方案-取舍”的結(jié)構(gòu)組織回答技術面試中面試官不僅看你知不知道答案更看你有沒有解決問題的思路。一個有效的表達結(jié)構(gòu)是先確認問題的邊界和約束再給出方案最后說明取舍和適用場景。比如被問到“如何優(yōu)化LLM的推理速度”不要直接說“用量化”。更好的回答是先問清楚場景——是延遲敏感還是吞吐敏感硬件是什么模型規(guī)模多大然后給出可能的方案量化INT8/INT4、蒸餾用小模型替代、KV Cache優(yōu)化、批處理、投機解碼等。最后說明每個方案的代價量化可能損失精度蒸餾需要訓練KV Cache增加顯存批處理增加延遲。這種回答展示的是工程判斷力而不是知識點記憶。9.2 不會的問題怎么處理面試中遇到不會的問題是正常的關鍵是怎么處理。最忌諱的是不懂裝懂編一個聽起來合理但錯誤的答案。面試官通常對這個領域很熟一眼就能看出來。更好的做法是坦誠說這個點我不太確定但我可以從相關的角度分析一下。然后把你確定知道的部分講清楚把不確定的部分標記出來。比如被問到“FlashAttention的具體實現(xiàn)”如果你沒看過論文可以說我知道它主要是通過分塊計算和重計算來減少顯存訪問具體的內(nèi)核實現(xiàn)我沒有深入研究但我理解它的目標是讓注意力計算更適配GPU的存儲層次。這種回答既誠實又展示了你的知識遷移能力。9.3 用實際案例替代抽象描述面試中最有說服力的永遠是具體案例。與其說“我熟悉RAG”不如說“我做過一個法律文檔問答系統(tǒng)用了BGE的embedding模型chunk大小設為512重疊128檢索后加了cross-encoder做rerank最終準確率從72%提升到89%”。具體的數(shù)字、工具名、參數(shù)和效果對比能讓面試官立刻判斷出你的經(jīng)驗深度。我在幫人做模擬面時經(jīng)常發(fā)現(xiàn)一個現(xiàn)象很多人明明做過不錯的項目但講出來平平無奇。問題通常出在只講了“做了什么”沒講“為什么這么做”和“遇到了什么問題”。面試官想聽的是你的決策過程和踩坑經(jīng)驗而不是項目說明書。10. 幾個容易被忽略但會直接減分的細節(jié)10.1 混淆概念比不知道更致命面試中有些錯誤是“不知道”有些錯誤是“搞混了”。后者更致命因為它說明你的知識體系有結(jié)構(gòu)性缺陷。常見的混淆包括把微調(diào)和RAG混為一談、把Tokenization和Embedding混為一談、把Transformer的Encoder和Decoder結(jié)構(gòu)混為一談、把模型幻覺和模型錯誤混為一談。避免這種錯誤的方法是在準備面試時畫一張知識圖譜把相關概念的關系理清楚。比如RAG是在推理時引入外部知識微調(diào)是在訓練時改變模型參數(shù)兩者解決的是不同層面的問題可以結(jié)合使用。這種清晰的概念邊界是面試官判斷你是否“科班”的重要依據(jù)。10.2 對最新進展一無所知LLM領域變化很快面試官通常會關注你有沒有跟蹤最新進展。不需要你讀遍所有論文但至少要知道主流模型的基本情況、常見工具鏈的更新、以及社區(qū)討論的熱點問題。比如如果面試官提到“MoE架構(gòu)”你要知道它是什么、為什么能降低推理成本、有哪些代表模型。如果提到“Agent”你要能說清楚Agent和普通Function Calling的區(qū)別、當前的主要挑戰(zhàn)是什么。這些不需要你成為專家但完全不知道會顯得你和行業(yè)脫節(jié)。10.3 忽視工程約束談方案很多候選人在面試時喜歡談“理想方案”但忽略了實際工程中的約束。比如被問到“如何部署一個LLM服務”有人會大談模型架構(gòu)和算法優(yōu)化卻不提顯存限制、并發(fā)處理、監(jiān)控告警、成本控制這些工程問題。在實際工作中工程約束往往比算法選擇更能決定方案是否可行。面試時如果你能主動提到“這個方案在A100上可能可行但在消費級顯卡上需要做量化”或者“這個方案的延遲在200ms左右如果業(yè)務要求100ms以內(nèi)需要換思路”面試官會認為你是一個有落地經(jīng)驗的人而不是只會紙上談兵。準備LLM面試本質(zhì)上不是背八股文而是系統(tǒng)梳理自己對整個技術棧的理解。這8個問題之所以成為必問是因為它們覆蓋了從模型原理到工程落地的關鍵節(jié)點。你不需要每個問題都答得完美但至少要能在每個方向上說出自己的思考和經(jīng)驗。面試官要找的不是全知全能的人而是遇到問題時知道從哪里入手、知道如何權衡、知道怎么驗證的人。把這一點傳遞出去比答對任何單個問題都重要。