LLM 這東西剛接觸的人容易走兩個(gè)極端要么把它當(dāng)成萬能問答機(jī)器隨便丟個(gè)問題就指望它給出能直接落地的方案要么被各種術(shù)語嚇住覺得非得懂 Transformer 架構(gòu)、會(huì)調(diào)參、有 GPU 集群才能用。我?guī)Я藥讉€(gè)剛?cè)胄械耐轮蟀l(fā)現(xiàn)真正卡住大多數(shù)人的不是模型本身而是“不知道在什么場(chǎng)景下該用哪種調(diào)用方式、參數(shù)怎么設(shè)、結(jié)果怎么驗(yàn)證”。這篇就圍繞 LLM 的實(shí)際使用方法展開從最基礎(chǔ)的對(duì)話調(diào)用到結(jié)構(gòu)化輸出、本地部署、精調(diào)、評(píng)測(cè)把每個(gè)環(huán)節(jié)里我踩過的坑和驗(yàn)證過的做法都攤開講。不管你是剛拿到 API Key 的新手還是已經(jīng)在項(xiàng)目里集成過 LLM 但效果不穩(wěn)定的開發(fā)者都能從中找到可以直接抄的配置和思路。1. 先把 LLM 當(dāng)成一個(gè)“概率補(bǔ)全引擎”來理解1.1 它到底在做什么從 token 預(yù)測(cè)說起很多人第一次用 LLM 時(shí)腦子里默認(rèn)它像數(shù)據(jù)庫查詢——輸入問題取出答案。實(shí)際完全不是。LLM 的本質(zhì)是自回歸的 token 預(yù)測(cè)器給它一段文本它計(jì)算下一個(gè) token 在詞表上的概率分布選一個(gè)出來拼回輸入再預(yù)測(cè)下一個(gè)如此循環(huán)。你看到的“回答”是這一步步采樣拼出來的結(jié)果。這個(gè)認(rèn)知直接決定了使用方法。比如你問“中國(guó)的首都是哪里”它輸出“北京”不是因?yàn)椴榱吮矶且驗(yàn)樵谒膮?shù)里“中國(guó)的首都”后面接“北京”的概率遠(yuǎn)高于其他詞。理解了這一點(diǎn)你就能明白為什么同樣的 prompt 多次調(diào)用結(jié)果可能不同——采樣有隨機(jī)性它可能“一本正經(jīng)地胡說”——概率高不等于事實(shí)正確上下文里給的信息會(huì)強(qiáng)烈影響輸出——因?yàn)槟切?token 直接參與了后續(xù)概率計(jì)算。我一般會(huì)跟新人打個(gè)比方LLM 像一個(gè)讀過海量文本、但記性不太精確的實(shí)習(xí)生。你給的任務(wù)描述越清楚、參考資料越具體它干得越靠譜你含糊其辭它就自由發(fā)揮。1.2 三個(gè)必須記住的參數(shù)temperature、top_p、max_tokens調(diào)用任何 LLM API繞不開這幾個(gè)采樣參數(shù)。它們不是玄學(xué)每個(gè)都有明確的物理含義。參數(shù)作用典型取值什么時(shí)候調(diào)temperature縮放 logits控制分布陡峭程度0~2常用 0~1要確定性輸出調(diào)低要?jiǎng)?chuàng)意調(diào)高top_p核采樣只從累積概率前 p 的 token 里選0.1~1和 temperature 二選一調(diào)別同時(shí)大改max_tokens限制輸出長(zhǎng)度按任務(wù)設(shè)防止無限輸出燒錢temperature 的機(jī)制值得多說一句。模型輸出的是每個(gè) token 的原始分?jǐn)?shù)logitstemperature 做的是logits / T。T 趨近 0 時(shí)分布變得極尖銳幾乎總是選概率最高的那個(gè) token輸出就穩(wěn)定、可復(fù)現(xiàn)T 變大分布被壓平低概率 token 也有機(jī)會(huì)被選中輸出就多樣甚至跑偏。我的經(jīng)驗(yàn)是做信息抽取、分類、代碼生成這類任務(wù)temperature 設(shè) 0 到 0.3寫文案、頭腦風(fēng)暴設(shè) 0.7 到 1.0。top_p 我通常保持默認(rèn)很多 API 是 1只在需要精細(xì)控制多樣性時(shí)才動(dòng)而且不同時(shí)大幅調(diào) temperature 和 top_p否則兩個(gè)隨機(jī)源疊加結(jié)果很難復(fù)現(xiàn)。注意temperature0 也不保證 100% 可復(fù)現(xiàn)。浮點(diǎn)運(yùn)算順序、并行計(jì)算、服務(wù)端批處理都可能導(dǎo)致微小差異。要嚴(yán)格復(fù)現(xiàn)得靠固定 seed如果 API 支持加緩存。1.3 上下文窗口不是越大越好現(xiàn)在動(dòng)輒 128K、200K 上下文窗口很多人恨不得把整個(gè)知識(shí)庫塞進(jìn)去。我實(shí)測(cè)下來長(zhǎng)上下文有兩個(gè)隱形成本一是費(fèi)用按 token 算塞得越多越貴二是“中間遺忘”現(xiàn)象——模型對(duì)上下文開頭和結(jié)尾的信息利用得好中間大段內(nèi)容容易被忽略。所以正確做法不是無腦堆上下文而是做檢索增強(qiáng)RAG先用向量檢索或關(guān)鍵詞檢索從知識(shí)庫里撈出最相關(guān)的幾段再拼進(jìn) prompt。這樣既省 token又提高準(zhǔn)確率。我做過對(duì)比同樣一個(gè)問題把 50 頁文檔全塞進(jìn)去 vs 檢索出最相關(guān)的 3 段后者的回答準(zhǔn)確率反而更高。2. 對(duì)話調(diào)用的工程化從能跑到穩(wěn)定2.1 消息角色的分工system、user、assistant主流對(duì)話 API 用消息數(shù)組組織輸入每條消息有 role。三個(gè)角色各司其職system設(shè)定全局行為比如“你是一個(gè)嚴(yán)謹(jǐn)?shù)募夹g(shù)助手回答必須給出依據(jù)”。它優(yōu)先級(jí)最高但也不是絕對(duì)服從。user用戶輸入。assistant模型的歷史回復(fù)多輪對(duì)話時(shí)要把之前的回復(fù)也帶上模型才知道上下文。新手常犯的錯(cuò)是把所有指令都塞進(jìn) user 消息。我建議把穩(wěn)定的行為約束放 system把當(dāng)次任務(wù)放 user。比如 system 寫“輸出必須是 JSON不要有多余文字”user 寫具體要抽取的內(nèi)容。這樣多輪對(duì)話時(shí)行為約束不會(huì)丟。多輪對(duì)話還有個(gè)坑歷史消息會(huì)不斷累積token 越用越多。我的做法是保留最近 N 輪或者對(duì)早期對(duì)話做摘要壓縮。摘要可以用 LLM 自己生成比如“把以下對(duì)話壓縮成 100 字以內(nèi)的要點(diǎn)”。2.2 結(jié)構(gòu)化輸出讓 LLM 返回能直接解析的數(shù)據(jù)LLM 返回自然語言但程序需要結(jié)構(gòu)化數(shù)據(jù)。最樸素的做法是在 prompt 里寫“請(qǐng)返回 JSON”然后手動(dòng)解析。問題是模型經(jīng)常在 JSON 外面加解釋文字或者字段名對(duì)不上解析直接崩。我踩過最慘的一次是線上服務(wù)因?yàn)槟Ｐ投噍敵隽艘痪洹昂玫囊韵率墙Y(jié)果”JSON 解析失敗整個(gè)請(qǐng)求鏈路報(bào)錯(cuò)。后來我總結(jié)了幾層防護(hù)優(yōu)先用 API 原生的結(jié)構(gòu)化輸出能力?，F(xiàn)在很多平臺(tái)支持 JSON mode 或 function calling / tool use模型被約束只能輸出合法 JSON這是最穩(wěn)的。如果只能用 prompt 約束就在 system 里明確“只輸出 JSON第一個(gè)字符是 {最后一個(gè)字符是 }不要任何解釋”。解析時(shí)做容錯(cuò)用正則先提取第一個(gè){到最后一個(gè)}之間的內(nèi)容再解析解析失敗就重試一次重試時(shí)把錯(cuò)誤信息也帶上讓模型自己修。下面是一個(gè)帶容錯(cuò)的解析示例import json import re def parse_llm_json(text): # 先嘗試直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取花括號(hào)內(nèi)容再試 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass return None配合重試邏輯結(jié)構(gòu)化輸出的成功率能從 80% 出頭提到 99% 以上。2.3 重試與超時(shí)別讓一次失敗拖垮整個(gè)請(qǐng)求LLM 調(diào)用是網(wǎng)絡(luò)請(qǐng)求會(huì)超時(shí)、會(huì)限流、會(huì)返回 5xx。我見過不少項(xiàng)目直接裸調(diào)一次失敗就拋異常給用戶。正確做法是指數(shù)退避重試失敗后等 1 秒、2 秒、4 秒再試最多試 3 到 5 次。但要注意不是所有錯(cuò)誤都值得重試。限流429和服務(wù)器錯(cuò)誤5xx可以重試參數(shù)錯(cuò)誤400、鑒權(quán)失敗401重試多少次都沒用應(yīng)該直接報(bào)錯(cuò)。另外如果請(qǐng)求已經(jīng)產(chǎn)生了費(fèi)用但響應(yīng)超時(shí)重試可能導(dǎo)致重復(fù)計(jì)費(fèi)這個(gè)要在業(yè)務(wù)層做冪等處理。超時(shí)時(shí)間也要設(shè)合理。生成類任務(wù)寫長(zhǎng)文可能幾十秒抽取類任務(wù)幾秒就夠。我一般設(shè) 30 秒超時(shí)超過就放棄重試避免用戶等太久。3. 本地部署與模型選擇什么時(shí)候該自己跑3.1 云端 API 和本地部署的取舍不是所有場(chǎng)景都適合調(diào)云端 API。我整理了一個(gè)決策表維度云端 API本地部署成本按 token 付費(fèi)量大貴一次性硬件投入長(zhǎng)期便宜數(shù)據(jù)隱私數(shù)據(jù)出本地?cái)?shù)據(jù)不出本地延遲受網(wǎng)絡(luò)影響局域網(wǎng)內(nèi)低延遲模型能力通常是最強(qiáng)模型受硬件限制多為中小模型運(yùn)維無需運(yùn)維要管顯存、并發(fā)、升級(jí)我的判斷標(biāo)準(zhǔn)很簡(jiǎn)單數(shù)據(jù)敏感、調(diào)用量大、對(duì)延遲敏感三者占一個(gè)就考慮本地部署。比如處理內(nèi)部合同、醫(yī)療記錄數(shù)據(jù)不能出內(nèi)網(wǎng)那就本地跑。如果只是偶爾用用、要最強(qiáng)能力云端 API 更劃算。3.2 GGUF 格式與量化讓模型跑在消費(fèi)級(jí)硬件上本地部署繞不開量化。原始模型動(dòng)輒幾十 GB消費(fèi)級(jí)顯卡裝不下。量化就是把模型權(quán)重從 16 位浮點(diǎn)壓到 8 位、4 位甚至更低犧牲一點(diǎn)精度換顯存和速度。GGUF 是目前流行的格式配合 llama.cpp 這類推理引擎能在 CPU 和 GPU 混合環(huán)境下跑。量化等級(jí)常見的有 Q4_K_M、Q5_K_M、Q8_0 等。我的經(jīng)驗(yàn)Q4_K_M性價(jià)比最高4 位量化里質(zhì)量損失小7B 模型大概 4~5GB普通顯卡能跑。Q5_K_M質(zhì)量更好顯存多花一點(diǎn)推薦。Q8_0接近原始精度但顯存占用大除非硬件充裕否則沒必要。選量化等級(jí)時(shí)先看顯存再在能裝下的等級(jí)里選最高的。別為了省一點(diǎn)顯存選 Q2、Q3質(zhì)量掉得厲害得不償失。3.3 安卓端本地運(yùn)行可行但有邊界現(xiàn)在確實(shí)有能在安卓上跑 GGUF 模型的軟件支持較老的安卓版本。但要說清楚邊界手機(jī)端跑的是小參數(shù)模型1B~7B能力有限適合離線問答、簡(jiǎn)單文本處理別指望它做復(fù)雜推理。實(shí)際使用中內(nèi)存是最大瓶頸。7B 模型 Q4 量化也要 4GB 以上內(nèi)存加上系統(tǒng)占用8GB 內(nèi)存的手機(jī)跑起來很吃力。我的建議是手機(jī)端優(yōu)先選 1B~3B 的小模型響應(yīng)快、內(nèi)存壓力小做本地化的簡(jiǎn)單任務(wù)足夠。真要復(fù)雜任務(wù)還是走云端或桌面端。4. 精調(diào)與評(píng)測(cè)讓模型貼合你的場(chǎng)景4.1 什么時(shí)候該精調(diào)什么時(shí)候不該很多人一上來就想精調(diào)覺得這樣模型才“懂”自己的業(yè)務(wù)。我的觀點(diǎn)是精調(diào)是最后手段不是第一選擇。優(yōu)先級(jí)應(yīng)該是優(yōu)化 prompt把指令寫清楚、給例子few-shot能解決大部分問題。RAG知識(shí)類問題用檢索增強(qiáng)比精調(diào)更靈活知識(shí)更新也方便。精調(diào)當(dāng)任務(wù)有固定格式、固定風(fēng)格且 prompt 怎么調(diào)都達(dá)不到要求時(shí)才考慮。精調(diào)的成本不只是訓(xùn)練還有數(shù)據(jù)準(zhǔn)備、評(píng)測(cè)、后續(xù)維護(hù)。而且精調(diào)后的模型可能在其他任務(wù)上能力下降災(zāi)難性遺忘。所以先窮盡 prompt 和 RAG 的手段再上精調(diào)。4.2 用聊天記錄精調(diào)數(shù)據(jù)清洗比訓(xùn)練更重要用聊天記錄精調(diào)是個(gè)常見思路因?yàn)閿?shù)據(jù)現(xiàn)成。但原始聊天記錄直接拿來訓(xùn)練效果往往很差。問題在于噪聲大閑聊、表情、錯(cuò)別字混在一起格式亂沒有統(tǒng)一的消息角色標(biāo)注質(zhì)量參差有些對(duì)話本身就沒營(yíng)養(yǎng)。我的處理流程是先按對(duì)話輪次切分過濾掉太短、無意義的對(duì)話然后統(tǒng)一成 system/user/assistant 的格式再人工抽檢一批把明顯有問題的剔除。數(shù)據(jù)質(zhì)量決定精調(diào)上限寧可數(shù)據(jù)少一點(diǎn)、干凈一點(diǎn)也別用一堆垃圾數(shù)據(jù)硬訓(xùn)。訓(xùn)練時(shí)學(xué)習(xí)率要設(shè)小比如 1e-5 到 2e-5epoch 別太多1 到 3 輪否則容易過擬合。訓(xùn)完一定要在留出的驗(yàn)證集上測(cè)別只看訓(xùn)練 loss。4.3 LLM as Judge用模型評(píng)測(cè)模型模型輸出好不好人工評(píng)太慢?，F(xiàn)在流行用 LLM 當(dāng)裁判LLM as Judge讓一個(gè)強(qiáng)模型給另一個(gè)模型的輸出打分。做法是給裁判模型一個(gè)評(píng)分標(biāo)準(zhǔn)比如“從準(zhǔn)確性、完整性、格式規(guī)范三個(gè)維度各打 1~5 分”然后讓它輸出分?jǐn)?shù)和理由。這方法好用但有幾個(gè)坑位置偏見裁判可能偏向第一個(gè)出現(xiàn)的答案。解決辦法是交換順序評(píng)兩次取平均。長(zhǎng)度偏見長(zhǎng)答案容易被認(rèn)為更詳細(xì)。要在評(píng)分標(biāo)準(zhǔn)里明確“簡(jiǎn)潔性也計(jì)入”。裁判模型能力用弱模型當(dāng)裁判評(píng)不準(zhǔn)。盡量用比被測(cè)模型更強(qiáng)的模型當(dāng)裁判。我一般會(huì)把 LLM as Judge 和少量人工評(píng)測(cè)結(jié)合先用 LLM 批量打分篩出低分和分?jǐn)?shù)異常的樣本再人工復(fù)核。這樣效率和質(zhì)量兼顧。5. 智能體與容錯(cuò)構(gòu)建可靠系統(tǒng)的關(guān)鍵5.1 智能體的自主容錯(cuò)控制LLM 智能體Agent能自主調(diào)用工具、多步推理但可靠性是最大挑戰(zhàn)。一個(gè)環(huán)節(jié)出錯(cuò)后面全崩。自主容錯(cuò)控制的核心思路是讓智能體自己檢測(cè)異常并恢復(fù)。具體做法包括結(jié)果校驗(yàn)工具返回后讓模型判斷結(jié)果是否合理。比如查天氣返回“-999 度”明顯異常觸發(fā)重試或換工具。步驟回滾多步任務(wù)中某步失敗回到上一個(gè)穩(wěn)定狀態(tài)重新規(guī)劃而不是從頭再來。超時(shí)與預(yù)算控制給智能體設(shè)最大步數(shù)和最大 token 預(yù)算防止無限循環(huán)燒錢。我做過一個(gè)多步信息查詢的智能體最初沒設(shè)步數(shù)上限遇到一個(gè)查不到的信息就反復(fù)換關(guān)鍵詞重試燒了不少 token。后來加了“同一子任務(wù)最多重試 2 次超了就報(bào)告失敗并繼續(xù)下一步”穩(wěn)定性大幅提升。5.2 記憶與知識(shí)庫投毒的風(fēng)險(xiǎn)智能體如果有長(zhǎng)期記憶或外部知識(shí)庫就存在被污染的風(fēng)險(xiǎn)。攻擊者可能往知識(shí)庫里注入惡意內(nèi)容誘導(dǎo)智能體做出錯(cuò)誤決策。這不是危言聳聽是實(shí)際存在的安全議題。防護(hù)思路知識(shí)庫寫入做審核不是誰都能往記憶里寫東西加權(quán)限和內(nèi)容過濾。檢索結(jié)果做可信度排序優(yōu)先用高可信來源的內(nèi)容。關(guān)鍵決策加人工確認(rèn)涉及資金、權(quán)限變更等敏感操作智能體只能建議不能直接執(zhí)行。這些措施會(huì)增加一些復(fù)雜度但對(duì)于要上生產(chǎn)的智能體系統(tǒng)是必須的。5.3 請(qǐng)求失敗的常見原因排查“LLM request failed: provider rejected the request schema or tool payload” 這類報(bào)錯(cuò)很常見通常是請(qǐng)求格式不符合 API 規(guī)范。排查順序檢查消息格式role 是否是 API 支持的值content 是否是字符串或正確的多模態(tài)結(jié)構(gòu)。檢查工具定義function calling 的 schema 是否符合 JSON Schema 規(guī)范必填字段有沒有漏。檢查 token 數(shù)輸入是否超過模型上下文上限。檢查參數(shù)范圍temperature、top_p 是否在合法區(qū)間。我遇到最多的是工具 schema 里參數(shù)類型寫錯(cuò)比如該是 string 寫成了 numberAPI 直接拒絕。把 schema 打印出來對(duì)照文檔逐字段核對(duì)基本都能定位。6. 一些零散但實(shí)用的經(jīng)驗(yàn)6.1 基于 LLM 的單元測(cè)試用 LLM 生成單元測(cè)試是個(gè)提效手段但別直接信它生成的測(cè)試。我的做法是讓 LLM 生成測(cè)試用例然后人工審查邊界條件是否覆蓋、斷言是否合理。LLM 容易生成“看起來對(duì)但沒測(cè)到關(guān)鍵邏輯”的測(cè)試。把它當(dāng)草稿生成器不是最終答案。6.2 空間 LLM 與多模態(tài)Spatial LLM 這類涉及空間理解的多模態(tài)模型使用方法上和純文本 LLM 有區(qū)別輸入要帶圖像或 3D 數(shù)據(jù)prompt 要描述空間關(guān)系。目前這類模型在專業(yè)領(lǐng)域機(jī)器人、自動(dòng)駕駛用得多通用場(chǎng)景還不成熟。如果你的任務(wù)涉及空間推理先確認(rèn)模型是否真的支持別拿純文本模型硬套。6.3 關(guān)于內(nèi)容安全的邊界不管用什么 LLM輸出內(nèi)容都要過一遍安全過濾。尤其是面向用戶的產(chǎn)品模型可能生成不當(dāng)內(nèi)容。我的做法是在輸出后加一層規(guī)則過濾或分類模型把明顯有問題的內(nèi)容攔下來。這不是可選項(xiàng)是必選項(xiàng)。6.4 成本控制的幾個(gè)習(xí)慣緩存相同或相似的請(qǐng)求結(jié)果緩存起來別重復(fù)調(diào)用。分級(jí)簡(jiǎn)單任務(wù)用小模型復(fù)雜任務(wù)才用大模型。監(jiān)控記錄每次調(diào)用的 token 數(shù)和費(fèi)用設(shè)預(yù)算告警。壓縮 prompt定期審查 prompt去掉冗余描述。我見過一個(gè)項(xiàng)目因?yàn)?prompt 里塞了大量重復(fù)的示例每月費(fèi)用翻了好幾倍。精簡(jiǎn) prompt 之后效果沒降費(fèi)用降了一半多。6.5 模型選型的現(xiàn)實(shí)考量選模型不是越強(qiáng)越好要看任務(wù)需求、成本、延遲、數(shù)據(jù)合規(guī)。我的經(jīng)驗(yàn)是先用最強(qiáng)模型跑通流程、確定效果上限再逐步替換成更便宜的小模型看效果能接受就換。這樣既知道天花板在哪又能控制成本。別一上來就用小模型效果不好你都不知道是模型不行還是 prompt 不行。LLM 的使用方法說到底是一套工程實(shí)踐核心是理解它的概率本質(zhì)、用工程手段約束它的不確定性、用評(píng)測(cè)和監(jiān)控保證效果穩(wěn)定。上面這些是我在實(shí)際項(xiàng)目里反復(fù)驗(yàn)證過的做法你可以根據(jù)自己的場(chǎng)景調(diào)整參數(shù)和流程。真正上手跑幾個(gè)任務(wù)比看十篇教程都管用。