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