1. 為什么“會(huì)調(diào) API”和“懂原理”之間隔著一道鴻溝1.1 從一次線上事故說起去年冬天我接手了一個(gè)基于大模型 API 的智能問答項(xiàng)目。項(xiàng)目本身不復(fù)雜用戶提問后端拼裝提示詞調(diào)用模型接口返回答案。團(tuán)隊(duì)里兩個(gè)剛畢業(yè)的同學(xué)負(fù)責(zé)維護(hù)代碼跑了大半年一直沒出過大問題。直到有一天運(yùn)營側(cè)反饋說某些用戶的問題回答質(zhì)量突然斷崖式下跌原本能準(zhǔn)確回答的問題現(xiàn)在要么答非所問要么直接胡編亂造。兩個(gè)同學(xué)排查了一整天把提示詞改了又改溫度參數(shù)調(diào)了又調(diào)甚至懷疑是模型服務(wù)端出了問題。最后我過去看了一眼發(fā)現(xiàn)問題的根源根本不在提示詞也不在模型本身而在于他們處理上下文的方式對(duì)話歷史被無腦拼接長度超過模型窗口后他們直接截?cái)嗔俗钤绲南?dǎo)致系統(tǒng)提示詞和關(guān)鍵上下文丟失。模型失去了角色設(shè)定和任務(wù)約束自然就開始“放飛自我”。這件事讓我意識(shí)到一個(gè)很普遍的現(xiàn)象會(huì)調(diào) API 的人很多懂原理的人極少。調(diào)用一個(gè) HTTP 接口傳幾個(gè)參數(shù)拿回一段文本這確實(shí)沒什么門檻。但當(dāng)你需要控制輸出質(zhì)量、處理長上下文、優(yōu)化推理成本、排查詭異問題時(shí)光會(huì)調(diào)接口是遠(yuǎn)遠(yuǎn)不夠的。你得知道模型內(nèi)部大致在干什么得理解那些參數(shù)背后的數(shù)學(xué)含義得清楚數(shù)據(jù)在進(jìn)入模型之前經(jīng)歷了什么。這篇文章不打算講什么高深的理論也不會(huì)堆砌公式。我想做的是把大模型工程實(shí)踐中那些“看起來能用但不知道為什么能用”的環(huán)節(jié)拆開把“調(diào) API”和“懂原理”之間的那道鴻溝填一填。如果你已經(jīng)能熟練調(diào)用各種大模型接口但遇到問題只能靠玄學(xué)調(diào)參那這篇內(nèi)容就是寫給你的。1.2 一個(gè)核心認(rèn)知API 只是冰山一角很多人對(duì)大模型的理解停留在“輸入文本輸出文本”這個(gè)層面。這沒錯(cuò)但太粗糙了。一個(gè)完整的大模型應(yīng)用從用戶輸入到最終輸出中間至少經(jīng)過以下幾個(gè)階段文本預(yù)處理分詞、截?cái)?、填充、特殊?biāo)記插入向量化將 token 序列轉(zhuǎn)換為 embedding 向量前向推理經(jīng)過數(shù)十層注意力機(jī)制和前饋網(wǎng)絡(luò)解碼策略根據(jù) logits 分布選擇下一個(gè) token后處理去特殊標(biāo)記、拼接、格式化你調(diào)用的那個(gè) API實(shí)際上把中間所有步驟都封裝了。封裝是好事降低了使用門檻但代價(jià)是當(dāng)輸出不符合預(yù)期時(shí)你很難定位問題出在哪個(gè)環(huán)節(jié)。就像開車自動(dòng)擋確實(shí)方便但發(fā)動(dòng)機(jī)故障燈亮了你連機(jī)油尺在哪都不知道那就只能叫拖車。我見過太多項(xiàng)目提示詞寫了上千字參數(shù)調(diào)了幾十輪效果還是不穩(wěn)定。根本原因在于開發(fā)者對(duì)模型的行為邏輯沒有建立起正確的心理模型。他們以為模型是一個(gè)“更聰明的搜索引擎”實(shí)際上它更像一個(gè)“基于概率的文本續(xù)寫器”。這個(gè)認(rèn)知差異直接決定了你能否寫出穩(wěn)定可靠的提示詞能否設(shè)計(jì)出合理的上下文管理策略能否在成本和質(zhì)量之間找到平衡點(diǎn)。提示如果你現(xiàn)在維護(hù)的大模型應(yīng)用超過三個(gè)月且從未遇到過輸出質(zhì)量突然下降、響應(yīng)時(shí)間變長、成本超預(yù)期等問題要么是你的應(yīng)用太簡單要么是你還沒發(fā)現(xiàn)問題的根源。2. 從 Token 說起理解模型眼中的世界2.1 Token 不是字符也不是單詞大模型處理文本的最小單位是 token。這個(gè)詞被說爛了但很多人對(duì)它的理解仍然模糊。有人以為一個(gè) token 就是一個(gè)字有人以為一個(gè) token 就是一個(gè)單詞都不準(zhǔn)確。以英文為例“unbelievable” 這個(gè)詞在不同模型的分詞器下可能被切成 “un”、“believ”、“able” 三個(gè) token也可能被切成 “unbel”、“iev”、“able”甚至可能整體作為一個(gè) token。中文更復(fù)雜“人工智能” 可能是兩個(gè) token“人工”“智能”也可能是四個(gè) token“人”“工”“智”“能”取決于分詞器的訓(xùn)練方式和詞表大小。為什么要在意這個(gè)因?yàn)?token 數(shù)量直接關(guān)系到三件事成本、速度和上下文窗口。大多數(shù) API 按 token 計(jì)費(fèi)輸入輸出都算錢。token 切分方式不同同樣一段文本的費(fèi)用可能差出百分之二三十。速度方面模型生成每個(gè) token 都需要一次前向計(jì)算token 越多響應(yīng)越慢。上下文窗口更是硬約束超出窗口的內(nèi)容會(huì)被截?cái)嗷驁?bào)錯(cuò)。我做過一個(gè)實(shí)測(cè)拿一段 500 字左右的中文技術(shù)文檔分別用兩種常見分詞器處理。一種切出來 680 個(gè) token另一種切出來 920 個(gè) token差了 35%。如果你的應(yīng)用每天處理百萬級(jí)請(qǐng)求這個(gè)差異帶來的成本差距相當(dāng)可觀。2.2 分詞器背后的權(quán)衡分詞器的設(shè)計(jì)本質(zhì)上是在“詞表大小”和“序列長度”之間做權(quán)衡。詞表越大單個(gè) token 能覆蓋的字符越多序列越短但 embedding 矩陣和輸出層參數(shù)越多模型體積越大。詞表越小序列越長計(jì)算量越大但模型參數(shù)效率更高。常見的分詞算法有 BPEByte Pair Encoding、WordPiece、SentencePiece 等。BPE 的思路很直觀從字符開始不斷合并出現(xiàn)頻率最高的相鄰字符對(duì)直到達(dá)到預(yù)設(shè)的詞表大小。這個(gè)過程是數(shù)據(jù)驅(qū)動(dòng)的不需要語言學(xué)知識(shí)所以對(duì)各種語言都適用。理解這一點(diǎn)有什么用至少有兩個(gè)實(shí)際價(jià)值。第一當(dāng)你發(fā)現(xiàn)某個(gè)特定領(lǐng)域的文本比如醫(yī)療、法律、代碼token 消耗異常高時(shí)你可以考慮對(duì)分詞器進(jìn)行領(lǐng)域適配或者調(diào)整文本預(yù)處理方式。第二當(dāng)你需要精確控制輸入長度時(shí)不能簡單地按字符數(shù)估算必須用實(shí)際的分詞器來計(jì)算。# 以 HuggingFace tokenizers 為例計(jì)算 token 數(shù)量 from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(模型名稱) text 你的輸入文本 tokens tokenizer.encode(text) print(fToken 數(shù)量: {len(tokens)}) print(fToken 列表: {tokens}) print(f還原文本: {tokenizer.decode(tokens)})這段代碼很簡單但建議你在項(xiàng)目初期就把它集成到日志系統(tǒng)里。每次請(qǐng)求記錄輸入輸出 token 數(shù)跑一段時(shí)間后你會(huì)對(duì)應(yīng)用的 token 消耗有非常直觀的認(rèn)識(shí)。哪些請(qǐng)求消耗高哪些提示詞效率低一目了然。2.3 特殊標(biāo)記模型的控制信號(hào)除了普通文本 token分詞器還會(huì)引入一些特殊標(biāo)記比如s、/s、pad、|im_start|、|im_end|等。這些標(biāo)記不對(duì)應(yīng)任何實(shí)際文本而是用來告訴模型“序列開始”“序列結(jié)束”“填充位置”“對(duì)話輪次分隔”等信息。很多 API 封裝層會(huì)自動(dòng)處理這些特殊標(biāo)記開發(fā)者不需要關(guān)心。但如果你要自己拼接對(duì)話歷史或者做更精細(xì)的控制就必須了解它們的作用。比如某些模型用|im_start|和|im_end|來標(biāo)識(shí)每輪對(duì)話的邊界如果你手動(dòng)拼接時(shí)漏掉了這些標(biāo)記模型可能無法正確區(qū)分系統(tǒng)提示、用戶輸入和助手回復(fù)導(dǎo)致行為異常。我遇到過這樣一個(gè)案例某團(tuán)隊(duì)為了節(jié)省 token在拼接多輪對(duì)話時(shí)把每輪之間的特殊標(biāo)記去掉了只保留純文本。結(jié)果模型經(jīng)常把用戶的問題和之前的助手回復(fù)混在一起回答時(shí)出現(xiàn)“自我對(duì)話”的現(xiàn)象。加上特殊標(biāo)記后問題立刻消失。這就是“懂原理”的價(jià)值——你知道那個(gè)看似多余的標(biāo)記實(shí)際上是模型理解對(duì)話結(jié)構(gòu)的關(guān)鍵。3. 注意力機(jī)制模型如何“看懂”上下文3.1 從加權(quán)平均說起注意力機(jī)制的核心思想其實(shí)不復(fù)雜用一句話概括就是在處理當(dāng)前位置的信息時(shí)根據(jù)相關(guān)性對(duì)其他位置的信息進(jìn)行加權(quán)平均。想象你在讀一句話“小明把書放在了桌子上因?yàn)樗苤??！碑?dāng)你讀到“它”的時(shí)候你需要判斷“它”指代的是“書”還是“桌子”。你的大腦會(huì)自動(dòng)把注意力更多地放在“書”上因?yàn)椤爸亍边@個(gè)形容詞和“書”的關(guān)聯(lián)更強(qiáng)。注意力機(jī)制做的就是類似的事情只不過它是通過向量點(diǎn)積來計(jì)算相關(guān)性的。具體來說每個(gè) token 會(huì)生成三個(gè)向量Query查詢、Key鍵、Value值。當(dāng)前 token 的 Query 和其他所有 token 的 Key 做點(diǎn)積得到注意力分?jǐn)?shù)經(jīng)過 softmax 歸一化后作為權(quán)重對(duì) Value 進(jìn)行加權(quán)求和。這個(gè)過程可以并行計(jì)算所以 Transformer 的訓(xùn)練效率遠(yuǎn)高于 RNN。為什么要理解這個(gè)因?yàn)楹芏唷靶W(xué)”問題都能從這里找到解釋。比如為什么模型在處理長文本時(shí)中間部分的信息容易被忽略因?yàn)樽⒁饬Ψ謹(jǐn)?shù)經(jīng)過 softmax 后容易出現(xiàn)“贏者通吃”的現(xiàn)象少數(shù)幾個(gè) token 占據(jù)了大部分權(quán)重其他 token 的貢獻(xiàn)被稀釋。這就是所謂的“注意力稀釋”問題。3.2 多頭注意力多視角看問題單個(gè)注意力頭只能捕捉一種相關(guān)性模式。為了讓模型能從不同角度理解上下文Transformer 引入了多頭注意力機(jī)制。每個(gè)頭有自己獨(dú)立的 Q、K、V 變換矩陣可以關(guān)注不同的位置和不同的語義關(guān)系。有的頭可能關(guān)注語法結(jié)構(gòu)有的頭可能關(guān)注語義相似性有的頭可能關(guān)注位置鄰近性。這給我們的啟示是模型對(duì)上下文的理解是多維度的不是簡單的關(guān)鍵詞匹配。當(dāng)你寫提示詞時(shí)不要指望模型像搜索引擎一樣精確匹配你寫的每個(gè)詞。它更擅長捕捉整體語義和模式。所以提示詞的質(zhì)量不在于關(guān)鍵詞密度而在于語義清晰度和結(jié)構(gòu)合理性。我個(gè)人的經(jīng)驗(yàn)是寫提示詞時(shí)遵循“總-分-總”結(jié)構(gòu)效果比較好先說明任務(wù)目標(biāo)和角色設(shè)定再分點(diǎn)列出具體要求最后給出輸出格式示例。這種結(jié)構(gòu)符合模型處理信息的層次性能讓注意力機(jī)制更有效地分配權(quán)重。3.3 位置編碼模型如何知道順序注意力機(jī)制本身是位置無關(guān)的打亂輸入順序計(jì)算結(jié)果不變。但語言是有順序的所以需要額外注入位置信息。早期 Transformer 使用正弦余弦位置編碼后來出現(xiàn)了可學(xué)習(xí)的位置編碼、相對(duì)位置編碼、旋轉(zhuǎn)位置編碼RoPE等多種方案。位置編碼的設(shè)計(jì)直接影響模型處理長文本的能力。有些模型在訓(xùn)練時(shí)只見過較短序列推理時(shí)如果輸入遠(yuǎn)超訓(xùn)練長度位置編碼會(huì)“外推”到未見過的區(qū)域?qū)е滦阅芟陆?。這就是為什么有些模型標(biāo)稱支持 8K 上下文但實(shí)際用到 6K 以上時(shí)效果就開始變差。注意不要盲目相信模型標(biāo)稱的上下文長度。在實(shí)際項(xiàng)目中建議通過實(shí)驗(yàn)確定“有效上下文長度”。方法很簡單構(gòu)造一組需要長距離依賴的測(cè)試用例逐步增加輸入長度觀察準(zhǔn)確率變化。當(dāng)準(zhǔn)確率開始明顯下降時(shí)那個(gè)長度就是你的實(shí)際可用上限。4. 解碼策略模型如何“選詞”4.1 貪心搜索與束搜索模型輸出的是一個(gè)概率分布表示詞表中每個(gè) token 作為下一個(gè) token 的概率。解碼策略決定了如何從這個(gè)分布中選擇最終的輸出。最簡單的策略是貪心搜索每次選概率最高的 token。優(yōu)點(diǎn)是速度快、結(jié)果確定缺點(diǎn)是容易陷入局部最優(yōu)生成的內(nèi)容可能重復(fù)、單調(diào)。束搜索Beam Search保留 top-k 個(gè)候選序列每一步擴(kuò)展后重新排序最終選整體概率最高的序列。束搜索質(zhì)量通常更好但計(jì)算量是貪心搜索的 k 倍。在實(shí)際應(yīng)用中束搜索更適合翻譯、摘要等對(duì)準(zhǔn)確性要求高的任務(wù)而貪心搜索或采樣策略更適合對(duì)話、創(chuàng)作等需要多樣性的任務(wù)。很多 API 默認(rèn)使用采樣策略但允許你通過參數(shù)控制。4.2 溫度、Top-k 與 Top-p這三個(gè)參數(shù)是調(diào) API 時(shí)最常見的但很多人只是憑感覺調(diào)不知道背后的邏輯。溫度Temperature作用于 softmax 之前對(duì) logits 進(jìn)行縮放。溫度趨近于 0 時(shí)分布變得尖銳概率最高的 token 幾乎必然被選中輸出確定性強(qiáng)但缺乏多樣性。溫度大于 1 時(shí)分布變得平坦低概率 token 也有機(jī)會(huì)被選中輸出更多樣但可能不連貫。溫度等于 1 時(shí)保持原始分布。Top-k限制候選集為概率最高的 k 個(gè) token其余置零后重新歸一化。這可以避免選中概率極低的“離譜” token但 k 值固定不適應(yīng)分布形狀的變化。Top-p核采樣動(dòng)態(tài)選擇候選集按概率從高到低累加直到累積概率超過 p只保留這些 token。這樣當(dāng)分布集中時(shí)候選集小分布分散時(shí)候選集大。相比 Top-kTop-p 更靈活。參數(shù)作用典型值適用場景溫度控制分布尖銳程度0.1~0.3確定任務(wù)代碼生成、數(shù)學(xué)計(jì)算溫度控制分布尖銳程度0.7~1.0創(chuàng)意任務(wù)文案創(chuàng)作、頭腦風(fēng)暴Top-k限制候選數(shù)量20~50通用場景Top-p動(dòng)態(tài)限制候選0.9~0.95通用場景我個(gè)人的習(xí)慣是先固定 Top-p 為 0.9然后根據(jù)任務(wù)類型調(diào)溫度。需要精確答案時(shí)溫度設(shè) 0.1~0.2需要多樣性時(shí)設(shè) 0.8~1.0。Top-k 一般不動(dòng)除非發(fā)現(xiàn)輸出中有明顯不合理的 token。4.3 重復(fù)懲罰與頻率懲罰模型有時(shí)會(huì)陷入重復(fù)循環(huán)反復(fù)輸出相同的短語或句子。這是因?yàn)榻獯a過程中已經(jīng)生成的 token 會(huì)提高后續(xù)相同 token 的概率自回歸特性。重復(fù)懲罰Repetition Penalty通過對(duì)已出現(xiàn)的 token 施加懲罰來緩解這個(gè)問題。頻率懲罰Frequency Penalty則根據(jù) token 出現(xiàn)的次數(shù)進(jìn)行懲罰出現(xiàn)越多懲罰越重。這兩個(gè)參數(shù)需要謹(jǐn)慎使用。懲罰過重會(huì)導(dǎo)致模型回避常用詞輸出變得生硬奇怪。我一般只在明確出現(xiàn)重復(fù)問題時(shí)才調(diào)整且從較小的值開始嘗試。5. 上下文管理長對(duì)話的核心挑戰(zhàn)5.1 上下文窗口的硬約束每個(gè)模型都有最大上下文長度比如 4K、8K、32K、128K token。這個(gè)窗口包括輸入和輸出。如果你的對(duì)話歷史加上當(dāng)前問題超過了窗口限制就必須做取舍。常見的處理策略有幾種截?cái)嘀苯觼G棄最早的消息。簡單粗暴但可能丟失關(guān)鍵信息?；瑒?dòng)窗口保留最近 N 輪對(duì)話。比截?cái)嗌院玫杂行畔G失。摘要壓縮用模型對(duì)早期對(duì)話生成摘要保留摘要而非原文。節(jié)省 token但摘要本身可能丟失細(xì)節(jié)。向量檢索將歷史對(duì)話存入向量數(shù)據(jù)庫根據(jù)當(dāng)前問題檢索相關(guān)片段。適合超長對(duì)話但實(shí)現(xiàn)復(fù)雜。選擇哪種策略取決于你的應(yīng)用場景?？头C(jī)器人可能需要保留完整的對(duì)話歷史而創(chuàng)意寫作助手可能只需要最近幾輪交互。沒有萬能方案只有適合當(dāng)前場景的權(quán)衡。5.2 系統(tǒng)提示詞的穩(wěn)定性系統(tǒng)提示詞定義了模型的角色、任務(wù)和約束。在多輪對(duì)話中系統(tǒng)提示詞通常需要始終保留在上下文中否則模型會(huì)“忘記”自己的設(shè)定。但系統(tǒng)提示詞往往很長占用大量 token。一個(gè)優(yōu)化思路是將系統(tǒng)提示詞拆分為“核心約束”和“補(bǔ)充說明”。核心約束始終保留補(bǔ)充說明只在相關(guān)輪次注入。比如一個(gè)法律咨詢助手核心約束是“你是一名法律顧問回答需嚴(yán)謹(jǐn)”補(bǔ)充說明可能是“當(dāng)前用戶咨詢的是勞動(dòng)合同問題相關(guān)法條包括……”。后者只在特定輪次需要。另一個(gè)技巧是使用“提示詞壓縮”用更簡潔的語言表達(dá)同樣的約束。這需要反復(fù)實(shí)驗(yàn)找到既能被模型理解又最省 token 的表述方式。5.3 對(duì)話狀態(tài)的顯式維護(hù)不要指望模型能完美記住所有歷史信息。更可靠的做法是在應(yīng)用層顯式維護(hù)對(duì)話狀態(tài)。比如用一個(gè)結(jié)構(gòu)化對(duì)象記錄用戶意圖、已確認(rèn)信息、待辦事項(xiàng)等。每次請(qǐng)求時(shí)將這個(gè)狀態(tài)序列化后注入提示詞。這樣做的好處是狀態(tài)可控、可調(diào)試、可持久化。模型只負(fù)責(zé)當(dāng)前輪次的推理不依賴它記住所有東西。我參與過的一個(gè)項(xiàng)目就是通過顯式狀態(tài)管理將多輪對(duì)話的準(zhǔn)確率從 70% 提升到了 92%。改動(dòng)并不復(fù)雜只是把“讓模型記住”變成了“我們幫模型記住”。6. 成本與性能的平衡術(shù)6.1 Token 成本的精打細(xì)算大模型 API 的計(jì)費(fèi)方式通常是按輸入 token 和輸出 token 分別計(jì)價(jià)輸出 token 往往更貴?？刂瞥杀镜暮诵乃悸肥菧p少不必要的輸入控制輸出長度。減少輸入方面可以做的有精簡系統(tǒng)提示詞、壓縮對(duì)話歷史、去除冗余格式標(biāo)記、使用更高效的分詞器?？刂戚敵龇矫婵梢栽O(shè)置 max_tokens 上限、在提示詞中明確要求簡潔回答、使用停止序列stop sequences在合適位置終止生成。我做過一個(gè)對(duì)比同一個(gè)問答任務(wù)優(yōu)化前平均每次請(qǐng)求消耗 1200 輸入 token 300 輸出 token優(yōu)化后降到 700 輸入 150 輸出。按每天 10 萬次請(qǐng)求計(jì)算一個(gè)月能省下相當(dāng)可觀的費(fèi)用。優(yōu)化手段并不復(fù)雜主要是精簡了系統(tǒng)提示詞并對(duì)歷史對(duì)話做了摘要壓縮。6.2 緩存策略的妙用很多場景下不同用戶的請(qǐng)求包含大量相同的系統(tǒng)提示詞或背景知識(shí)。如果每次請(qǐng)求都重新傳輸這些內(nèi)容既浪費(fèi)帶寬又浪費(fèi) token。一些 API 提供了提示詞緩存功能對(duì)相同的前綴部分只計(jì)費(fèi)一次。即使 API 不支持緩存你也可以在應(yīng)用層做緩存將常見的問答對(duì)緩存起來新請(qǐng)求先查緩存命中則直接返回未命中再調(diào)模型。對(duì)于知識(shí)庫問答這類場景緩存命中率可以做到很高。提示緩存的關(guān)鍵是設(shè)計(jì)好緩存鍵。簡單的文本哈希可能不夠因?yàn)檎Z義相同但表述不同的請(qǐng)求應(yīng)該命中同一緩存?？梢钥紤]用 embedding 相似度做語義緩存但要注意設(shè)置合理的相似度閾值避免返回不相關(guān)的答案。6.3 流式輸出的體驗(yàn)優(yōu)化流式輸出Streaming讓用戶可以在模型生成的同時(shí)看到部分結(jié)果顯著提升感知速度。實(shí)現(xiàn)上API 會(huì)返回一個(gè)事件流每個(gè)事件包含一小段生成的文本。前端逐段渲染即可。但流式輸出也帶來一些挑戰(zhàn)。比如如果你需要在輸出完成后做后處理如格式化、敏感詞過濾流式模式下就需要邊生成邊處理復(fù)雜度更高。另外流式輸出的錯(cuò)誤處理也更麻煩因?yàn)檫B接可能在生成中途斷開。我的建議是面向用戶的交互場景盡量用流式后臺(tái)批處理任務(wù)用非流式。流式模式下前端要做好增量渲染和錯(cuò)誤重試后端要做好超時(shí)控制和日志記錄。7. 常見問題與排查技巧實(shí)錄7.1 輸出質(zhì)量突然下降這是最常見的問題可能的原因和排查思路如下現(xiàn)象可能原因排查方法回答變短、變敷衍系統(tǒng)提示詞被截?cái)鄼z查上下文拼接邏輯答非所問對(duì)話歷史混亂檢查特殊標(biāo)記是否正確重復(fù)輸出溫度過低或重復(fù)懲罰不足調(diào)整解碼參數(shù)胡編亂造上下文丟失或沖突檢查上下文長度和內(nèi)容格式錯(cuò)誤輸出解析邏輯問題檢查后處理代碼我的經(jīng)驗(yàn)是遇到這類問題第一步永遠(yuǎn)是打印完整的輸入提示詞。很多時(shí)候問題就明明白白地?cái)[在那里只是被忽略了。7.2 響應(yīng)時(shí)間波動(dòng)大大模型推理時(shí)間受多種因素影響輸入長度、輸出長度、模型負(fù)載、網(wǎng)絡(luò)狀況。如果響應(yīng)時(shí)間波動(dòng)大可以從以下幾個(gè)方面排查輸入 token 數(shù)是否穩(wěn)定長輸入必然導(dǎo)致慢響應(yīng)。輸出是否設(shè)置了 max_tokens不設(shè)上限可能導(dǎo)致生成過長。是否使用了流式流式首 token 時(shí)間更重要。API 服務(wù)端是否有負(fù)載波動(dòng)可以記錄不同時(shí)間段的響應(yīng)時(shí)間分布。我一般會(huì)在日志中記錄每次請(qǐng)求的輸入 token 數(shù)、輸出 token 數(shù)、首 token 時(shí)間、總時(shí)間。跑一段時(shí)間后就能看出規(guī)律。如果發(fā)現(xiàn)某些請(qǐng)求異常慢可以針對(duì)性優(yōu)化。7.3 模型“不聽話”怎么辦模型不遵循指令通常有幾個(gè)原因指令不夠明確、指令之間存在沖突、模型能力不足、上下文中有干擾信息。解決思路是把模型當(dāng)成一個(gè)理解力不錯(cuò)但非常死板的實(shí)習(xí)生。你需要把要求拆解得非常具體避免模糊表述。比如不要說“回答要簡潔”而要說“回答不超過三句話”。不要說“語氣友好”而要說“使用‘您好’開頭使用‘請(qǐng)問’結(jié)尾”。另外指令的優(yōu)先級(jí)也很重要。如果系統(tǒng)提示詞和用戶輸入有沖突模型可能無所適從。明確告訴模型“當(dāng)用戶要求與系統(tǒng)設(shè)定沖突時(shí)以系統(tǒng)設(shè)定為準(zhǔn)”能減少很多問題。7.4 獨(dú)家避坑技巧最后分享幾個(gè)我在實(shí)踐中總結(jié)的小技巧提示詞版本管理把提示詞當(dāng)成代碼來管理每次修改都記錄版本和效果。不要憑記憶回滾。A/B 測(cè)試常態(tài)化任何提示詞或參數(shù)改動(dòng)都先在小流量上做 A/B 測(cè)試確認(rèn)效果后再全量。建立回歸測(cè)試集收集一批典型問題和期望答案每次改動(dòng)后跑一遍防止“修好一個(gè)壞掉三個(gè)”。監(jiān)控 token 消耗設(shè)置告警閾值當(dāng) token 消耗異常增長時(shí)及時(shí)排查。保留原始日志記錄完整的請(qǐng)求和響應(yīng)出問題時(shí)可以復(fù)現(xiàn)和分析。這些做法看起來繁瑣但能幫你省下大量排查問題的時(shí)間。我在實(shí)際項(xiàng)目中堅(jiān)持了半年后線上事故率下降了八成以上。8. 從“會(huì)用”到“懂行”的進(jìn)階路徑8.1 建立正確的心理模型從“會(huì)調(diào) API”到“懂原理”最關(guān)鍵的一步是建立正確的心理模型。你需要理解模型不是數(shù)據(jù)庫不是搜索引擎不是邏輯推理機(jī)。它是一個(gè)基于統(tǒng)計(jì)的文本生成器擅長模式匹配和概率續(xù)寫不擅長精確計(jì)算和事實(shí)核查。這個(gè)認(rèn)知會(huì)改變你使用模型的方式。你不會(huì)再問“模型為什么不知道這個(gè)事實(shí)”而是會(huì)想“我該怎么把事實(shí)信息放進(jìn)上下文”。你不會(huì)再抱怨“模型不按格式輸出”而是會(huì)設(shè)計(jì)更明確的格式約束和解析邏輯。8.2 動(dòng)手做小實(shí)驗(yàn)光看文章是不夠的建議你動(dòng)手做一些小實(shí)驗(yàn)。比如用同一個(gè)問題測(cè)試不同溫度下的輸出差異。構(gòu)造一段長文本測(cè)試模型在不同位置的信息召回率。對(duì)比不同分詞器對(duì)同一段中文的 token 消耗。嘗試不同的上下文截?cái)嗖呗杂^察對(duì)多輪對(duì)話的影響。這些實(shí)驗(yàn)不需要復(fù)雜的代碼用現(xiàn)成的 API 和幾行 Python 就能完成。但做過和沒做過理解深度完全不同。8.3 持續(xù)跟進(jìn)但不盲目追新大模型領(lǐng)域發(fā)展很快新模型、新技術(shù)層出不窮。保持關(guān)注是必要的但不要盲目追新。很多“新特性”在實(shí)際項(xiàng)目中可能并不成熟或者與你的場景不匹配。我的做法是關(guān)注核心原理的演進(jìn)比如注意力機(jī)制的改進(jìn)、位置編碼的優(yōu)化、解碼策略的創(chuàng)新。這些底層變化會(huì)影響所有上層應(yīng)用。至于具體的模型版本和 API 參數(shù)按需了解即可不必每個(gè)都深入研究。8.4 在項(xiàng)目中刻意練習(xí)最后也是最有效的進(jìn)階方式在真實(shí)項(xiàng)目中刻意練習(xí)。每次遇到問題不要滿足于“換個(gè)參數(shù)試試”而是追問“為什么會(huì)這樣”。每次優(yōu)化效果不要滿足于“好像好了一點(diǎn)”而是量化“好了多少為什么好了”。我在帶團(tuán)隊(duì)時(shí)要求每個(gè)成員在解決線上問題后寫一份簡短的分析報(bào)告說明問題的根本原因和解決方案的原理。這個(gè)習(xí)慣堅(jiān)持下來團(tuán)隊(duì)整體的技術(shù)水平提升非常明顯。會(huì)調(diào) API 的人很多但愿意花時(shí)間搞懂原理的人永遠(yuǎn)稀缺。