開(kāi)頭先講一個(gè)矛盾同一個(gè)大語(yǔ)言模型LLM有些任務(wù)讓人驚喜有些任務(wù)讓人想砸鍵盤(pán)。問(wèn)題往往不在模型本身而在我們讓它“做”的事不對(duì)。很多資料會(huì)把模型能力列成一張很長(zhǎng)的清單能寫(xiě)代碼、能翻譯、能總結(jié)、能當(dāng)Agent到了真實(shí)業(yè)務(wù)里我們?nèi)钡牟皇恰澳懿荒茏觥钡那鍐味恰霸摬辉撟觥钡呐袛喾椒?。What LLMs Should Do表面是能力問(wèn)題實(shí)際是任務(wù)邊界問(wèn)題。1. 先放下“能不能做”回答“該不該做”1.1 能力邊界不等于使用邊界很多人評(píng)估一個(gè)模型能否用于業(yè)務(wù)方式是拿幾條問(wèn)題去跑一遍看回答像不像。這是體驗(yàn)不是評(píng)估。真實(shí)業(yè)務(wù)里一個(gè)任務(wù)需要的是重復(fù)跑、穩(wěn)定輸出、在無(wú)人盯情況下不出事。你讓模型寫(xiě)一首詩(shī)寫(xiě)得一般也能接受你讓模型批量處理用戶留言錯(cuò)一條就需要解釋。同一個(gè)模型在不同任務(wù)約束下使用價(jià)值完全不同。比如模型能“做”會(huì)議紀(jì)要也能“做”訂單金額匯總。但會(huì)議紀(jì)要只要要點(diǎn)齊全人可以容忍部分措辭不完美訂單金額只要錯(cuò)一位數(shù)后面所有流程都會(huì)被帶偏。所以不能因?yàn)槟Ｐ汀罢J(rèn)識(shí)這些詞”就斷定它適合這個(gè)任務(wù)。能力邊界回答的是“模型能輸出什么”使用邊界回答的是“我們?cè)撟屗?fù)責(zé)什么”。1.2 LLM 真正適合的任務(wù)通常具備四個(gè)特征我一般用四個(gè)特征做初步篩選輸入和輸出都以文本/自然語(yǔ)言為主。結(jié)果可以被人工或程序快速校驗(yàn)。任務(wù)本質(zhì)是生成、總結(jié)、改寫(xiě)、抽取、分類(lèi)或格式轉(zhuǎn)換。不要求絕對(duì)確定性、不依賴實(shí)時(shí)狀態(tài)、不直接執(zhí)行外部動(dòng)作。以“把一段會(huì)議記錄整理成待辦事項(xiàng)”為例輸入是文本輸出是文本人可以幾秒內(nèi)判斷待辦是否合理模型可以抽取“負(fù)責(zé)人、時(shí)間、事項(xiàng)”這條任務(wù)適合交給LLM。反過(guò)來(lái)“統(tǒng)計(jì)訂單總金額并生成報(bào)表”雖然輸入輸出也是文本但數(shù)字必須精確一旦出錯(cuò)影響很大。它不滿足第4條不適合讓模型直接輸出最終數(shù)字更合適的方式是讓模型從非結(jié)構(gòu)化描述里抽取訂單號(hào)、金額和日期再由代碼完成計(jì)算。1.3 為什么先跑通再優(yōu)化在任務(wù)邊界判斷上也成立很多團(tuán)隊(duì)選型時(shí)先比參數(shù)量、看跑分、看榜單然后才到業(yè)務(wù)里試。這里的成本很高。更實(shí)用的順序是先拿20條真實(shí)業(yè)務(wù)樣本用同一個(gè)提示詞、同一個(gè)溫度參數(shù)跑一遍人工看結(jié)果。如果方向不對(duì)先調(diào)整任務(wù)分解而不是急著換大模型。因?yàn)楹芏唷澳Ｐ筒恍小钡慕Y(jié)論其實(shí)是任務(wù)定義不清晰或提示詞沒(méi)有圍繞任務(wù)結(jié)構(gòu)寫(xiě)。比如只告訴模型“幫我把評(píng)論分類(lèi)”不如告訴它“存在這三個(gè)分類(lèi)每個(gè)分類(lèi)定義是什么輸出格式是JSON如果無(wú)法判斷就返回unknown”。先在小樣本上把任務(wù)邊界說(shuō)清楚再評(píng)估模型水平才是有意義的比較。2. 不該交給 LLM 的任務(wù)往往就壞在“看起來(lái)能做”2.1 幻覺(jué)不是模型故意騙人而是概率生成的下界要理解為什么有些任務(wù)不該交給LLM需要接受一個(gè)底層事實(shí)LLM是在做下一個(gè)token的概率預(yù)測(cè)。它擅長(zhǎng)的是“在給定上下文中生成最自然的延續(xù)”而不是“在數(shù)據(jù)庫(kù)中查詢并返回唯一真理”。所以當(dāng)模型缺少某個(gè)事實(shí)時(shí)它不會(huì)像搜索引擎一樣說(shuō)“查無(wú)此條”而是會(huì)用一個(gè)看起來(lái)合理的回答填補(bǔ)空白。這就是幻覺(jué)?？梢园袻LM想象成一位經(jīng)驗(yàn)豐富但偶爾會(huì)自信出錯(cuò)的助手。你讓它起草一份方案它很高效你讓它直接對(duì)外發(fā)布最終版本就需要有人校對(duì)。這不是它能力低而是它的工作機(jī)制決定了它適合“生成草稿”不適合“終審發(fā)布”。凡是要求100%忠實(shí)于事實(shí)的任務(wù)都必須給模型提供可信來(lái)源或者把事實(shí)核對(duì)邏輯放到模型外面。2.2 用“錯(cuò)誤代價(jià)”給任務(wù)分級(jí)在做任何決定前先評(píng)估“如果輸出是錯(cuò)的會(huì)帶來(lái)什么后果”低風(fēng)險(xiǎn)內(nèi)容可以被人工快速修改例如營(yíng)銷(xiāo)文案、代碼注釋、會(huì)議紀(jì)要、非正式郵件草稿。中風(fēng)險(xiǎn)內(nèi)容涉及結(jié)構(gòu)化數(shù)據(jù)或下游流程但可以在執(zhí)行前被程序攔截例如提取字段后由正則校驗(yàn)、生成SQL后在沙箱執(zhí)行。高風(fēng)險(xiǎn)內(nèi)容直接影響資金、權(quán)限、人身安全、法律條款或?qū)ν獬兄Z例如自動(dòng)退款、自動(dòng)發(fā)版、自動(dòng)發(fā)送合同。低風(fēng)險(xiǎn)任務(wù)可以直接交給LLM。中風(fēng)險(xiǎn)任務(wù)需要給LLM套一層“只生成、不執(zhí)行”的護(hù)欄。高風(fēng)險(xiǎn)任務(wù)里L(fēng)LM能做的只是提供參考決策權(quán)必須留給人。判斷標(biāo)準(zhǔn)不是“模型能不能做到”而是“錯(cuò)了之后補(bǔ)救成本高不高”。2.3 很多人忽略的信號(hào)任務(wù)描述里有沒(méi)有“總是”“所有”“一定”如果你的任務(wù)描述是“所有郵件都分類(lèi)正確”“接口每次都返回相同格式”那么LLM不一定是最優(yōu)選。它擅長(zhǎng)處理模糊性和多樣性而不是維持硬性約束。這時(shí)需要把任務(wù)拆成兩個(gè)部分讓LLM處理語(yǔ)義部分比如識(shí)別意圖、抽取要素用代碼處理規(guī)則部分比如字段校驗(yàn)、格式校驗(yàn)、唯一性檢查。這個(gè)思路比逼模型變得更精確更可靠。一個(gè)常見(jiàn)教訓(xùn)不要因?yàn)榭蚣茏詭?Agent 能力就把一個(gè)本來(lái)可以用固定 prompt 完成的分類(lèi)任務(wù)拆成多輪自省。Agent 每多一步都意味著更高的延遲、更大的出錯(cuò)概率和更難的日志排查。3. 用 LLM 框架把“該做的事”固化下來(lái)3.1 框架不是在包裝模型而是在維護(hù)任務(wù)的上下文現(xiàn)在提到 LLM 框架很多人會(huì)想到 LangChain、LlamaIndex 這類(lèi)常見(jiàn)選擇。最初我也覺(jué)得框架是在簡(jiǎn)化模型調(diào)用后來(lái)才發(fā)現(xiàn)框架真正解決的是上下文維護(hù)問(wèn)題。在一次真實(shí)任務(wù)里模型需要知道的不是一句“幫我分類(lèi)”而是背景信息、任務(wù)目標(biāo)、字段定義、示例、輸出格式、邊界條件。如果每次都在業(yè)務(wù)代碼里臨時(shí)拼一個(gè)prompt遲早會(huì)混亂?？蚣馨堰@些內(nèi)容模板化并把模型調(diào)用、日志、重試、結(jié)構(gòu)化輸出等固定成可復(fù)用組件。但要注意框架本身不解決“該不該做”的問(wèn)題。如果任務(wù)方向錯(cuò)了框架只是更快地跑到錯(cuò)誤地方。所以不要一上來(lái)就搭一套完整的 Agent、RAG、記憶、工具調(diào)用系統(tǒng)先想清楚任務(wù)是否需要這些組件。3.2 提示詞管理是框架的第一層回報(bào)提示詞也是代碼需要版本管理和測(cè)試。用框架可以把 system prompt、user prompt、示例放到獨(dú)立目錄或配置中心再用測(cè)試集做一個(gè)評(píng)估樣板。例如一個(gè)分類(lèi)任務(wù)先準(zhǔn)備20條標(biāo)注過(guò)的文本每次修改提示詞后都跑一遍看準(zhǔn)確率是上升還是下降。這樣提示詞就不再是某個(gè)開(kāi)發(fā)者本地的“咒語(yǔ)”而是整個(gè)團(tuán)隊(duì)可以迭代的資產(chǎn)。這是 LLM 落地中最容易忽略也最值得投入的部分。很多人把精力放在選模型和調(diào)參數(shù)上忽略了 prompt 模板本身會(huì)隨著業(yè)務(wù)變化而過(guò)期。一個(gè)穩(wěn)定的評(píng)測(cè)集比換一個(gè)大模型更能保證長(zhǎng)期效果。3.3 檢索增強(qiáng)和工具調(diào)用本質(zhì)是給 LLM 縮小責(zé)任半徑很多復(fù)雜任務(wù)不適合直接交給LLM因?yàn)樗鼈円竽Ｐ椭捞嗤獠渴聦?shí)。一個(gè)典型解法是檢索增強(qiáng)RAG把私有文檔切成片段用向量庫(kù)做相似度檢索再把命中片段和用戶問(wèn)題一起交給LLM生成答案。這樣一來(lái)LLM不用靠記憶回答它只需要基于“給定的片段”做總結(jié)和表達(dá)。這是 What LLMs Should Do 的一個(gè)正面案例讓LLM負(fù)責(zé)它擅長(zhǎng)的語(yǔ)言組織讓檢索系統(tǒng)負(fù)責(zé)事實(shí)召回。工具調(diào)用也一樣。別讓LLM直接完成“給用戶發(fā)通知”這個(gè)動(dòng)作而是讓LLM決定“應(yīng)該調(diào)用哪個(gè)工具并傳什么參數(shù)”再由代碼執(zhí)行工具并校驗(yàn)結(jié)果。這樣即使模型判斷錯(cuò)了工具層還可以做權(quán)限校驗(yàn)和審批?？蚣艿囊饬x就是把這種“模型只做決策、代碼負(fù)責(zé)執(zhí)行”的分工固化下來(lái)。4. 部署形態(tài)先于任務(wù)判斷本地還是 API和“是否同機(jī)”不是一回事4.1 一個(gè)常見(jiàn)問(wèn)題的拆解ComfyUI 與 LLM 必須在同一臺(tái)電腦上么在社區(qū)里看到過(guò)一個(gè)高頻問(wèn)題ComfyUI 與 LLM 必須在同一臺(tái)電腦上么這個(gè)問(wèn)題的背后不是兩款軟件怎么連而是對(duì) LLM 部署形態(tài)的誤解。直接回答不必需。ComfyUI 本身處理的是圖像生成與圖像處理對(duì)顯卡和 CUDA 環(huán)境要求較高。如果只是想用它調(diào)用LLM來(lái)生成提示詞、總結(jié)標(biāo)簽或做畫(huà)質(zhì)評(píng)估LLM完全可以部署在另一臺(tái)機(jī)器上通過(guò) HTTP API 或局域網(wǎng)端口調(diào)用。反過(guò)來(lái)如果非要讓兩個(gè)服務(wù)共享同一塊 GPU才需要關(guān)心顯存是否夠大、是否會(huì)互相搶占、會(huì)不會(huì)頻繁 OOM。所以正確的提問(wèn)方式不是“必須同機(jī)嗎”而是“我的資源約束和服務(wù)調(diào)用關(guān)系是什么”。4.2 三種部署形態(tài)分別適合什么場(chǎng)景全遠(yuǎn)程 API本地只發(fā)請(qǐng)求。適合快速驗(yàn)證、低頻調(diào)用、不想維護(hù)模型服務(wù)。缺點(diǎn)是有網(wǎng)絡(luò)依賴、數(shù)據(jù)要經(jīng)過(guò)外部服務(wù)、按量付費(fèi)。本地模型服務(wù)在一臺(tái)機(jī)器上部署一個(gè)模型服務(wù)例如通過(guò) ollama、vLLM 這類(lèi)工具然后把 API 暴露給局域網(wǎng)或其他應(yīng)用。適合對(duì)隱私有要求、需要高頻內(nèi)網(wǎng)調(diào)用、或者要控制成本。同進(jìn)程內(nèi)嵌加載在同一個(gè)應(yīng)用里把模型加載進(jìn)來(lái)不走網(wǎng)絡(luò)。適合完全離線的小型任務(wù)但資源耦合度高多項(xiàng)目共用時(shí)容易互相影響。在“ComfyUI 與 LLM 是否同機(jī)”這個(gè)具體場(chǎng)景里最常見(jiàn)的是第二種LLM 作為獨(dú)立服務(wù)運(yùn)行ComfyUI 通過(guò) HTTP 調(diào)用。這也是更合理的架構(gòu)因?yàn)閳D像生成和文本生成的時(shí)間、顯存需求不一樣拆開(kāi)后可以單獨(dú)擴(kuò)容出問(wèn)題時(shí)也更好排查。4.3 本地部署時(shí)真正要盯的是資源約束和生效質(zhì)量本地跑LLM不等于把模型文件下載下來(lái)就萬(wàn)事大吉。顯存和內(nèi)存決定了你最多能跑多大參數(shù)量、多少并發(fā)上下文長(zhǎng)度決定了單次任務(wù)可以喂多少材料量化精度會(huì)影響占用和生成質(zhì)量溫度參數(shù)則影響穩(wěn)定性和創(chuàng)造性。如果業(yè)務(wù)任務(wù)是分類(lèi)、抽取這類(lèi)低隨機(jī)性任務(wù)temperature 一般直接設(shè)為0如果是在做文案生成可以適當(dāng)調(diào)高。這里最容易踩坑的是“模型能加載但效果達(dá)不到預(yù)期”。本地7B模型在一些簡(jiǎn)單分類(lèi)上可能夠用但如果要做復(fù)雜的邏輯推理或多文檔總結(jié)效果就會(huì)明顯下滑。此時(shí)別急著調(diào)提示詞先確認(rèn)是不是模型能力上限的問(wèn)題再考慮升級(jí)模型或切回 API。判斷方法還是一樣固定一批小測(cè)試集對(duì)比不同模型在相同提示詞下的輸出質(zhì)量。5. 判斷任務(wù)該不該交給 LLM 的一套最小流程5.1 五步評(píng)估法把前面的內(nèi)容收斂成一個(gè)可復(fù)用流程寫(xiě)下任務(wù)描述標(biāo)出輸入是什么、輸出是什么。判斷輸出是否以文本/自然語(yǔ)言為主如果不是考慮拆解讓 LLM 只做語(yǔ)義部分。評(píng)估錯(cuò)誤代價(jià)如果錯(cuò)了能否在低成本的條件下被人或程序發(fā)現(xiàn)并修復(fù)。確認(rèn)是否需要外部事實(shí)或?qū)崟r(shí)狀態(tài)如果需要先規(guī)劃?rùn)z索或工具調(diào)用而不是讓模型硬記。準(zhǔn)備20條真實(shí)樣本作為驗(yàn)收集用固定提示詞和固定參數(shù)跑一遍人工判斷通過(guò)率。如果第2、3、4步都提示“不適合”就不要硬上。如果通過(guò)了再用最小流程驗(yàn)證。5.2 一個(gè)示例從客戶評(píng)論分類(lèi)到摘要生成假設(shè)要處理“客戶評(píng)論分類(lèi)并生成摘要”。輸入是文本評(píng)論輸出是“分類(lèi)摘要”這是典型的文本任務(wù)。錯(cuò)誤代價(jià)分類(lèi)錯(cuò)誤或摘要不準(zhǔn)確運(yùn)營(yíng)人員可以在發(fā)送反饋前人工抽查問(wèn)題不大。外部事實(shí)不需要實(shí)時(shí)狀態(tài)只需要模型自身語(yǔ)義理解能力。驗(yàn)收樣本從歷史評(píng)論里隨機(jī)抽20條先人工標(biāo)好分類(lèi)標(biāo)簽和期望摘要。然后開(kāi)始第一次測(cè)試。提示詞里寫(xiě)清楚分類(lèi)定義、輸出格式最好加一兩個(gè)示例。temperature 設(shè)為0。跑完20條后人工判斷通過(guò)率。如果通過(guò)率達(dá)到90%就可以逐步擴(kuò)大到一個(gè)更大的驗(yàn)證集如果沒(méi)達(dá)到先看失敗樣本判斷是分類(lèi)定義模糊、輸出格式不穩(wěn)定還是評(píng)論本身太復(fù)雜再針對(duì)性調(diào)整提示詞或模型。示例結(jié)構(gòu)可以這樣# 示例結(jié)構(gòu)用統(tǒng)一函數(shù)調(diào)用本地或遠(yuǎn)程 LLM 服務(wù) def run_llm(system_prompt: str, user_prompt: str, temperature: float 0.0): # 內(nèi)部實(shí)現(xiàn)負(fù)責(zé)調(diào) API、超時(shí)、日志記錄 response call_llm_service( messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperaturetemperature, ) return response注意這是示例結(jié)構(gòu)不是某個(gè)框架的官方 API。真實(shí)項(xiàng)目里還要在這里加上版本號(hào)和輸出校驗(yàn)。5.3 從最小流程到批量化最后才是工程化單次跑通并不等于能穩(wěn)定批量使用。一個(gè)任務(wù)驗(yàn)證通過(guò)后還需要做三件事給每次調(diào)用加日志記錄模型版本、prompt版本、耗時(shí)、輸出結(jié)果和校驗(yàn)結(jié)果。加失敗重試和降級(jí)策略。例如網(wǎng)絡(luò)超時(shí)重試兩次仍然失敗就寫(xiě)入待人工處理隊(duì)列。把輸入輸出放到固定的目錄或表結(jié)構(gòu)里方便審計(jì)和回溯。如果后續(xù)要長(zhǎng)期使用還要關(guān)注 prompt 測(cè)試集維護(hù)。隨著業(yè)務(wù)變化初始的20條樣本會(huì)過(guò)期需要定期補(bǔ)充新樣本。這個(gè)部分看起來(lái)瑣碎但在生產(chǎn)環(huán)境里它的價(jià)值比“換一個(gè)更強(qiáng)模型”更大。5.4 輸出不穩(wěn)定的前四個(gè)檢查點(diǎn)如果已經(jīng)把一個(gè)任務(wù)交給 LLM但輸出時(shí)好時(shí)壞建議按順序排查輸入端檢查消息結(jié)構(gòu)、編碼、上下文長(zhǎng)度和權(quán)限設(shè)置。很多空輸出或報(bào)錯(cuò)來(lái)自請(qǐng)求格式不對(duì)。提示詞看是否給了足夠的示例和明確的輸出格式。如果只是加一句“要準(zhǔn)確”效果通常有限。采樣參數(shù)分類(lèi)/抽取任務(wù)先確認(rèn) temperature 是否設(shè)為0同時(shí)檢查 top_p、max_tokens 是否限制了輸出長(zhǎng)度。模型與框架版本同一個(gè)模型在不同兼容層下可能有差異改了 prompt 模板或升級(jí)了框架版本也會(huì)影響結(jié)果。這個(gè)排查順序已經(jīng)能解決大部分“模型不穩(wěn)定”的困惑。如果還沒(méi)有解決再往業(yè)務(wù)數(shù)據(jù)觀察看是不是輸入分布超出了預(yù)期。回到開(kāi)頭的那個(gè)問(wèn)題What LLMs Should Do。我的答案是LLM 應(yīng)該承擔(dān)那些“由語(yǔ)言驅(qū)動(dòng)、允許校驗(yàn)、錯(cuò)誤成本可控”的任務(wù)而不是成為一個(gè)被強(qiáng)塞一切需求的萬(wàn)能盒子。能力邊界會(huì)隨著模型迭代快速變化但任務(wù)邊界判斷方法基本不會(huì)變。以后遇到一個(gè)“能不能用 LLM 做”的問(wèn)題先別急著上框架、調(diào)參數(shù)拿20條真實(shí)樣本跑一遍算一下錯(cuò)誤代價(jià)再?zèng)Q定讓它做什么。這一步想清楚了后面的工程化才有意義。