戰(zhàn)指南)
大模型用了一年多我發(fā)現(xiàn)身邊不少朋友對 Prompt 工程的理解還停留在把話說清楚這個(gè)層面。話是沒錯(cuò)但遠(yuǎn)遠(yuǎn)不夠。同一個(gè)模型同一件事有人寫三行字就能拿到能直接用的結(jié)果有人來回改十幾輪還是差點(diǎn)意思——差距往往不在文筆而在有沒有用對提示范式。Zero-shot、Few-shot、CoT 思維鏈這三個(gè)詞你可能天天在熱搜上刷到但真正能把它們用對場景、用出效果的人并不多。這篇就把這三套基礎(chǔ)范式拆開講透它們各自解決什么問題、底層為什么有效、什么場景該用哪個(gè)、實(shí)際寫的時(shí)候有哪些坑。不管你是剛接觸 Prompt 的新手還是已經(jīng)寫過一堆提示詞但效果時(shí)好時(shí)壞的老手都能從里面找到能直接抄作業(yè)的東西。1. 先把三個(gè)范式擺到同一張桌子上很多人學(xué)這三個(gè)概念是分開學(xué)的結(jié)果腦子里是三個(gè)孤立的定義。我更建議先把它們放在一條連續(xù)的軸上理解這樣你才知道什么時(shí)候該往哪邊挪。1.1 它們本質(zhì)上是給模型多少信息的三個(gè)檔位把大模型想象成一個(gè)剛?cè)肼?、能力很?qiáng)但完全不了解你公司業(yè)務(wù)的同事。Zero-shot 就是你直接甩一句幫我寫個(gè)周報(bào)他憑常識給你寫Few-shot 是你先給他看兩份以前的周報(bào)當(dāng)樣例他照著格式和風(fēng)格寫CoT 則是你不僅給樣例還要求他先列這周做了啥再歸類再總結(jié)成三條把思考過程顯式地走一遍。所以這三者不是互斥的三選一而是可以疊加的Few-shot CoT 就是既給樣例又要求分步推理這在復(fù)雜任務(wù)里是最常見的組合。理解這一點(diǎn)后面所有的選型判斷都會(huì)順很多。1.2 一張表看清三者的適用邊界范式給模型的信息量典型適用場景主要成本Zero-shot只有任務(wù)指令通用任務(wù)、模型已充分訓(xùn)練的能力結(jié)果不穩(wěn)定格式難控Few-shot指令 若干輸入輸出樣例格式固定、風(fēng)格特定、分類任務(wù)消耗上下文長度樣例選擇敏感CoT指令 分步推理要求可疊加樣例數(shù)學(xué)、邏輯、多步推理、復(fù)雜決策輸出變長簡單任務(wù)反而變差這張表建議你存下來。實(shí)際工作中遇到一個(gè)新任務(wù)先問自己兩個(gè)問題模型對這個(gè)任務(wù)熟不熟任務(wù)需不需要多步推理兩個(gè)問題的答案基本就能定位你該從哪個(gè)檔位起步。1.3 為什么檔位這個(gè)視角比定義更有用因?yàn)檎鎸?shí)項(xiàng)目里你幾乎不會(huì)只用一種。比如做一個(gè)合同信息抽取你可能會(huì)先用 Few-shot 固定輸出格式再對其中判斷條款是否對己方不利這種需要推理的子任務(wù)加 CoT。如果只記定義你會(huì)糾結(jié)這到底算 Few-shot 還是 CoT用檔位視角你只會(huì)關(guān)心這一步我需要給模型補(bǔ)什么信息。我見過太多人卡在概念分類上反而耽誤了真正該做的調(diào)優(yōu)。記住范式是工具不是考試題。2. Zero-shot別小看什么都不給的難度Zero-shot 看起來最簡單其實(shí)最考驗(yàn)?zāi)銓θ蝿?wù)描述的精準(zhǔn)度。因?yàn)槟Ｐ蜎]有任何參照全靠你的指令去對齊它的理解。2.1 Zero-shot 真正難在哪難在你以為說清楚了其實(shí)沒有。比如總結(jié)一下這篇文章模型不知道你要多長、給誰看、要不要保留數(shù)據(jù)、要不要帶觀點(diǎn)。它只能猜而猜的結(jié)果十有八九不是你要的。我自己的經(jīng)驗(yàn)是Zero-shot 的提示詞里至少要交代清楚四件事任務(wù)是什么、輸出給誰看、輸出什么格式、有什么約束。這四件事缺一件結(jié)果就會(huì)飄。舉個(gè)具體的請把下面這段產(chǎn)品介紹改寫成給非技術(shù)用戶看的版本。 要求 - 面向完全沒有技術(shù)背景的普通消費(fèi)者 - 控制在 150 字以內(nèi) - 不使用任何專業(yè)術(shù)語如果必須用要加一句大白話解釋 - 語氣親切不要用感嘆號對比一下幫我改寫得更通俗一點(diǎn)你會(huì)發(fā)現(xiàn)前者幾乎不需要二次修改后者你得來回好幾輪。差別就在于約束是否顯式。2.2 指令的顆粒度怎么把握顆粒度太粗模型自由發(fā)揮太細(xì)又容易把模型框死反而寫出機(jī)械的答案。我的判斷標(biāo)準(zhǔn)是凡是結(jié)果對不對取決于它的必須寫死凡是風(fēng)格好不好的給方向就行。比如做數(shù)據(jù)清洗輸出必須是合法 JSON這個(gè)必須寫死甚至要給字段名和類型。但如果是寫營銷文案你只需要說活潑一點(diǎn)、面向年輕人具體怎么活潑交給模型它往往比你規(guī)定得更自然。2.3 一個(gè)常被忽略的技巧用角色 任務(wù) 約束三段式這是 Zero-shot 里最穩(wěn)的結(jié)構(gòu)我?guī)缀踉谒泻唵稳蝿?wù)里都用角色你是一位有十年經(jīng)驗(yàn)的財(cái)務(wù)分析師任務(wù)請分析下面這份利潤表指出三個(gè)最值得關(guān)注的問題約束每個(gè)問題用一句話說明并給出對應(yīng)的數(shù)據(jù)支撐不要泛泛而談角色不是玄學(xué)它的作用是幫模型快速定位到某個(gè)知識分布和表達(dá)風(fēng)格。你讓它當(dāng)財(cái)務(wù)分析師它調(diào)用的就是財(cái)務(wù)領(lǐng)域的表達(dá)習(xí)慣和關(guān)注點(diǎn)比你不給角色要準(zhǔn)得多。提示角色要具體到領(lǐng)域 經(jīng)驗(yàn)層級你是一個(gè)助手這種等于沒寫。3. Few-shot樣例給對了效果翻倍給錯(cuò)了全盤皆輸Few-shot 是我在工程里用得最多的范式因?yàn)榇蟛糠謽I(yè)務(wù)任務(wù)都需要固定格式和特定風(fēng)格而這些靠文字描述很難說清給兩個(gè)樣例模型立刻就懂了。3.1 樣例數(shù)量不是越多越好很多人一上來就給十個(gè)樣例覺得越多越準(zhǔn)。實(shí)測下來3 到 5 個(gè)高質(zhì)量樣例通常就夠了再多邊際收益很低還白白吃掉上下文長度。更重要的是樣例的覆蓋度而不是數(shù)量。什么叫覆蓋度就是你的樣例要覆蓋任務(wù)里可能出現(xiàn)的各種情況。比如做情感分類你不能五個(gè)樣例全是正面和負(fù)面得有一個(gè)中性或者模棱兩可的否則模型遇到邊界情況就懵。3.2 樣例的順序會(huì)悄悄影響結(jié)果這一點(diǎn)很多人不知道。模型對樣例順序是有敏感性的尤其是分類任務(wù)。如果你把某一類的樣例都放在前面模型可能會(huì)輕微偏向這一類。我的做法是打散順序讓各類樣例交替出現(xiàn)減少位置偏差。另外最后一個(gè)樣例的影響往往最大因?yàn)樗x你的真實(shí)輸入最近。所以如果你有特別想強(qiáng)調(diào)的格式或風(fēng)格把它放在最后一個(gè)樣例里。3.3 樣例的格式必須和真實(shí)輸入完全一致這是踩過坑才知道的。有一次我做信息抽取樣例里的輸入是規(guī)整的短句結(jié)果真實(shí)數(shù)據(jù)里全是帶各種符號和換行的長文本模型直接崩了輸出格式全亂。后來我把樣例換成和真實(shí)數(shù)據(jù)同分布的長文本問題立刻解決。所以給樣例前先看一眼你的真實(shí)輸入長什么樣樣例必須長得像它。格式、長度、噪聲程度都要接近模型才能泛化過去。3.4 Few-shot 和 Zero-shot 的取舍判斷什么時(shí)候該上 Few-shot我的經(jīng)驗(yàn)是三條里中一條就該上輸出格式有嚴(yán)格要求JSON、表格、特定模板任務(wù)風(fēng)格很特殊文字描述說不清比如某種品牌調(diào)性Zero-shot 試了兩三次還是不穩(wěn)定反過來如果任務(wù)很通用、格式隨意、模型本來就擅長那就別浪費(fèi)上下文Zero-shot 直接上。4. CoT 思維鏈讓模型想出來而不是猜出來CoT 是這三個(gè)里最容易被神化也最容易被誤用的。它的核心思想很簡單讓模型把推理過程寫出來而不是直接給答案。但什么時(shí)候用、怎么用講究很多。4.1 CoT 為什么有效把隱式計(jì)算變成顯式步驟大模型本質(zhì)上是逐 token 生成的它沒有真正的思考過程。當(dāng)你直接問一個(gè)多步問題它必須在一次前向計(jì)算里把答案蹦出來中間步驟全被壓縮了容易出錯(cuò)。CoT 的做法是強(qiáng)制它把中間步驟一個(gè)個(gè)寫出來。每寫一步這一步的結(jié)果就變成了下一步的輸入條件相當(dāng)于把一個(gè)大計(jì)算拆成了多個(gè)小計(jì)算。這就是為什么在數(shù)學(xué)、邏輯、多步推理任務(wù)上加了 CoT 之后準(zhǔn)確率能明顯提升。用個(gè)類比你讓一個(gè)人心算 37 乘 24他可能算錯(cuò)但你讓他拿紙筆一步步寫正確率立刻上去。CoT 就是給模型遞了張紙。4.2 最簡 CoT一句話觸發(fā)最簡單的 CoT 甚至不需要樣例只要在提示詞末尾加一句請一步一步思考并展示你的推理過程最后再給出結(jié)論。這一句話在很多任務(wù)上就能帶來明顯提升。但要注意展示推理過程和給出答案要分開要求否則模型可能把推理和答案混在一起你提取結(jié)果時(shí)很麻煩。4.3 Zero-shot CoT 和 Few-shot CoT 的區(qū)別Zero-shot CoT只加一步步思考的指令不給推理樣例。適合模型本身就會(huì)推理、只是沒被激發(fā)的情況。Few-shot CoT給幾個(gè)帶完整推理過程的樣例讓模型模仿推理的格式和深度。適合推理路徑比較特殊、或者你希望推理風(fēng)格統(tǒng)一的情況。Few-shot CoT 的樣例里推理過程要寫得像人話不要跳步。我見過有人樣例里推理寫得太簡略結(jié)果模型也學(xué)著跳步最后還是錯(cuò)。4.4 CoT 的適用邊界不是所有任務(wù)都該用這是最重要的一點(diǎn)。CoT 在需要多步推理的任務(wù)上有效但在簡單任務(wù)上反而可能變差。原因有兩個(gè)一是簡單任務(wù)本來一步就能出結(jié)果強(qiáng)行分步反而引入噪聲二是輸出變長模型有更多機(jī)會(huì)想多了跑偏。所以判斷標(biāo)準(zhǔn)是這個(gè)任務(wù)人需不需要打草稿需要打草稿的數(shù)學(xué)、邏輯、規(guī)劃、復(fù)雜判斷上 CoT不需要的翻譯、改寫、簡單分類別上。任務(wù)類型是否建議 CoT原因數(shù)學(xué)應(yīng)用題強(qiáng)烈建議多步計(jì)算中間易錯(cuò)邏輯推理強(qiáng)烈建議需要逐步排除情感分類不建議一步判斷加了反而飄文本翻譯不建議直接映射無需推理復(fù)雜決策分析建議需要權(quán)衡多個(gè)因素5. 三者組合真實(shí)項(xiàng)目里沒人只用一種講完三個(gè)單獨(dú)的范式該說說組合了。真實(shí)項(xiàng)目里尤其是稍微復(fù)雜一點(diǎn)的任務(wù)幾乎都是組合使用。5.1 Few-shot CoT復(fù)雜任務(wù)的標(biāo)準(zhǔn)配置這是最常用的組合。樣例里既包含輸入輸出又包含推理過程。模型既學(xué)到了格式又學(xué)到了推理路徑。寫這種樣例時(shí)有個(gè)技巧推理過程要寫得比實(shí)際需要稍微詳細(xì)一點(diǎn)給模型留出模仿空間。但也不能太啰嗦否則模型會(huì)學(xué)得又臭又長。我的經(jīng)驗(yàn)是推理步驟控制在 3 到 6 步之間比較合適。5.2 分層使用不同子任務(wù)用不同范式一個(gè)復(fù)雜任務(wù)往往可以拆成幾個(gè)子任務(wù)每個(gè)子任務(wù)用最適合它的范式。比如做一個(gè)從用戶反饋里提取問題并判斷優(yōu)先級的任務(wù)第一步提取問題用 Few-shot 固定輸出格式第二步判斷優(yōu)先級用 CoT因?yàn)樾枰獧?quán)衡影響范圍和緊急程度第三步生成回復(fù)建議用 Zero-shot因?yàn)楦袷诫S意、模型擅長這樣拆開之后每一段都更可控出問題也容易定位是哪一步的鍋。5.3 組合時(shí)的上下文預(yù)算管理組合用得多上下文消耗就快。這時(shí)候要有預(yù)算意識樣例不是越多越好推理不是越細(xì)越好。我一般會(huì)先跑一版看哪部分對結(jié)果影響最大把預(yù)算往那部分傾斜其他部分能省則省。注意上下文塞太滿模型對中間部分的注意力會(huì)下降反而影響效果。寧可精簡不要堆砌。6. 那些文檔里不會(huì)寫的實(shí)操坑前面講的都是方法論這一節(jié)講點(diǎn)真金白銀踩出來的經(jīng)驗(yàn)。6.1 樣例里的錯(cuò)誤會(huì)被模型完美復(fù)制這是最坑的一點(diǎn)。你樣例里但凡有個(gè)錯(cuò)別字、格式不一致、邏輯小錯(cuò)誤模型會(huì)一絲不茍地學(xué)過去。所以樣例給出去之前一定要逐字檢查。我現(xiàn)在的習(xí)慣是樣例寫完先自己當(dāng)模型跑一遍看有沒有歧義。6.2 指令和樣例沖突時(shí)模型往往聽樣例的如果你文字里說輸出用中文但樣例全是英文模型大概率跟著樣例走。所以指令和樣例必須一致不能打架。這個(gè)坑我在做多語言任務(wù)時(shí)踩過改了半天指令沒用最后發(fā)現(xiàn)是樣例語言不對。6.3 CoT 的推理過程可能看起來很對但結(jié)論錯(cuò)模型寫出來的推理過程是它生成的不是它真實(shí)計(jì)算的。所以它可能寫出一段邏輯通順但結(jié)論錯(cuò)誤的推理。這時(shí)候不能只看推理像不像樣必須驗(yàn)證結(jié)論。我的做法是讓模型給出結(jié)論后再單獨(dú)問一遍這個(gè)結(jié)論對嗎請檢查相當(dāng)于讓它自查一次。6.4 溫度參數(shù)和范式要匹配Zero-shot 想要穩(wěn)定輸出溫度調(diào)低CoT 想要多樣推理溫度可以稍高。但很多人調(diào)范式的時(shí)候忘了調(diào)溫度結(jié)果效果忽好忽壞。這兩個(gè)是要一起調(diào)的。6.5 別指望一次寫對迭代才是常態(tài)我寫過的提示詞幾乎沒有一次成型的。都是先寫一版跑一批測試數(shù)據(jù)看哪類錯(cuò)得多針對性改再跑。這個(gè)過程通常要三到五輪。所以別追求一次寫出完美提示詞追求快速迭代到能用。7. 從零搭一套自己的提示詞測試流程光會(huì)寫還不夠你得能驗(yàn)證寫得好不好。這一節(jié)講怎么搭一個(gè)簡單的測試流程。7.1 準(zhǔn)備一批有代表性的測試樣本不用多20 到 50 條就夠但必須覆蓋各種情況典型的、邊界的、容易出錯(cuò)的。這批樣本是你判斷提示詞好壞的唯一依據(jù)比拍腦袋感覺靠譜得多。7.2 定義清楚的評判標(biāo)準(zhǔn)什么叫好是格式對、內(nèi)容準(zhǔn)、還是風(fēng)格像不同任務(wù)標(biāo)準(zhǔn)不同。我一般會(huì)列三到五條硬標(biāo)準(zhǔn)比如輸出必須是合法 JSON關(guān)鍵字段不能漏語氣符合要求逐條打分。7.3 記錄每次改動(dòng)和結(jié)果這一步很多人省了但特別重要。你改了哪句話、效果變好還是變差記下來。不然改到后面你自己都忘了哪版最好。我用一個(gè)簡單的表格記版本改動(dòng)內(nèi)容通過率主要問題v1初始版本60%格式偶爾錯(cuò)v2加了一個(gè)格式樣例85%邊界情況漏字段v3補(bǔ)了邊界樣例95%基本可用有了這個(gè)表你一眼就能看出哪次改動(dòng)有效哪次是白費(fèi)功夫。7.4 什么時(shí)候算夠用不要追求 100% 通過率那通常意味著你過擬合到測試集了。我的標(biāo)準(zhǔn)是核心場景全過邊界場景大部分過錯(cuò)誤可接受且可兜底。剩下的交給后處理或者人工兜底比無限調(diào)提示詞劃算得多。8. 幾個(gè)真實(shí)場景的完整提示詞拆解理論講完來看幾個(gè)能直接抄的例子。8.1 場景一結(jié)構(gòu)化信息抽取Few-shot你是一位專業(yè)的信息抽取助手。請從下面的文本中抽取指定字段輸出 JSON。 字段說明 - name: 人名字符串 - company: 公司名字符串沒有則填 null - role: 職位字符串沒有則填 null 示例1 輸入張三在字節(jié)跳動(dòng)擔(dān)任產(chǎn)品經(jīng)理。 輸出{name: 張三, company: 字節(jié)跳動(dòng), role: 產(chǎn)品經(jīng)理} 示例2 輸入李四最近離職了暫時(shí)沒有新東家。 輸出{name: 李四, company: null, role: null} 現(xiàn)在請?zhí)幚?輸入王五加入了美團(tuán)負(fù)責(zé)騎手運(yùn)營。這個(gè)例子的關(guān)鍵點(diǎn)字段說明寫清楚、樣例覆蓋了有值和null兩種情況、格式嚴(yán)格一致。8.2 場景二多步推理判斷CoT你是一位資深運(yùn)營分析師。請判斷下面這條用戶反饋的緊急程度高/中/低并說明理由。 請按以下步驟思考 1. 這條反饋涉及的問題影響多少用戶 2. 問題是否影響核心功能 3. 是否有替代方案 4. 綜合以上給出緊急程度。 反饋內(nèi)容今天下午開始所有用戶都無法登錄提示密碼錯(cuò)誤但我們后臺看密碼沒問題。這個(gè)例子里步驟是顯式給出的模型會(huì)照著走。對于判斷類任務(wù)把判斷維度列出來比讓它自由發(fā)揮穩(wěn)定得多。8.3 場景三風(fēng)格化改寫Zero-shot 角色你是一位有十年經(jīng)驗(yàn)的科技媒體編輯擅長把技術(shù)內(nèi)容寫得讓普通人也能看懂。 請把下面這段技術(shù)說明改寫成面向普通讀者的版本 - 控制在 200 字以內(nèi) - 不使用專業(yè)術(shù)語 - 用一個(gè)生活化的類比幫助理解 - 語氣平實(shí)不夸張 技術(shù)說明本系統(tǒng)采用分布式架構(gòu)通過一致性哈希算法實(shí)現(xiàn)數(shù)據(jù)分片并利用多副本機(jī)制保證高可用性。這個(gè)例子沒有樣例全靠角色和約束把方向定死。對于改寫類任務(wù)角色 約束的組合往往比給樣例更靈活。9. 關(guān)于提示詞工程會(huì)不會(huì)過時(shí)這件事最后聊個(gè)大家常問的問題。總有人說模型越來越強(qiáng)提示詞工程遲早沒用。我的看法是基礎(chǔ)范式不會(huì)過時(shí)但具體技巧會(huì)不斷更新。Zero-shot、Few-shot、CoT 這三個(gè)東西本質(zhì)上是在解決如何把任務(wù)信息有效地傳達(dá)給模型這個(gè)根本問題。只要模型還是通過上下文來理解任務(wù)這個(gè)問題的解法就不會(huì)消失。變的只是形式——以前要手寫 CoT現(xiàn)在有些模型內(nèi)置了推理能力你只需要觸發(fā)它。所以與其焦慮會(huì)不會(huì)過時(shí)不如把這三個(gè)范式的底層邏輯吃透。你理解了為什么要給樣例為什么要分步無論模型怎么迭代你都能快速找到對應(yīng)的用法。這才是真正值錢的東西。我自己現(xiàn)在的習(xí)慣是每換一個(gè)新模型都會(huì)拿這三個(gè)范式各跑一遍手頭的典型任務(wù)看看新模型在哪方面變強(qiáng)了、哪方面還需要提示詞補(bǔ)。這個(gè)習(xí)慣幫我省了很多瞎調(diào)的時(shí)間。 Prompt工程三大范式：Zero-shot、Few-shot、CoT思維鏈實(shí)戰(zhàn)指南
大模型用了一年多我發(fā)現(xiàn)身邊不少朋友對 Prompt 工程的理解還停留在把話說清楚這個(gè)層面。話是沒錯(cuò)但遠(yuǎn)遠(yuǎn)不夠。同一個(gè)模型同一件事有人寫三行字就能拿到能直接用的結(jié)果有人來回改十幾輪還是差點(diǎn)意思——差距往往不在文筆而在有沒有用對提示范式。Zero-shot、Few-shot、CoT 思維鏈這三個(gè)詞你可能天天在熱搜上刷到但真正能把它們用對場景、用出效果的人并不多。這篇就把這三套基礎(chǔ)范式拆開講透它們各自解決什么問題、底層為什么有效、什么場景該用哪個(gè)、實(shí)際寫的時(shí)候有哪些坑。不管你是剛接觸 Prompt 的新手還是已經(jīng)寫過一堆提示詞但效果時(shí)好時(shí)壞的老手都能從里面找到能直接抄作業(yè)的東西。1. 先把三個(gè)范式擺到同一張桌子上很多人學(xué)這三個(gè)概念是分開學(xué)的結(jié)果腦子里是三個(gè)孤立的定義。我更建議先把它們放在一條連續(xù)的軸上理解這樣你才知道什么時(shí)候該往哪邊挪。1.1 它們本質(zhì)上是給模型多少信息的三個(gè)檔位把大模型想象成一個(gè)剛?cè)肼?、能力很?qiáng)但完全不了解你公司業(yè)務(wù)的同事。Zero-shot 就是你直接甩一句幫我寫個(gè)周報(bào)他憑常識給你寫Few-shot 是你先給他看兩份以前的周報(bào)當(dāng)樣例他照著格式和風(fēng)格寫CoT 則是你不僅給樣例還要求他先列這周做了啥再歸類再總結(jié)成三條把思考過程顯式地走一遍。所以這三者不是互斥的三選一而是可以疊加的Few-shot CoT 就是既給樣例又要求分步推理這在復(fù)雜任務(wù)里是最常見的組合。理解這一點(diǎn)后面所有的選型判斷都會(huì)順很多。1.2 一張表看清三者的適用邊界范式給模型的信息量典型適用場景主要成本Zero-shot只有任務(wù)指令通用任務(wù)、模型已充分訓(xùn)練的能力結(jié)果不穩(wěn)定格式難控Few-shot指令 若干輸入輸出樣例格式固定、風(fēng)格特定、分類任務(wù)消耗上下文長度樣例選擇敏感CoT指令 分步推理要求可疊加樣例數(shù)學(xué)、邏輯、多步推理、復(fù)雜決策輸出變長簡單任務(wù)反而變差這張表建議你存下來。實(shí)際工作中遇到一個(gè)新任務(wù)先問自己兩個(gè)問題模型對這個(gè)任務(wù)熟不熟任務(wù)需不需要多步推理兩個(gè)問題的答案基本就能定位你該從哪個(gè)檔位起步。1.3 為什么檔位這個(gè)視角比定義更有用因?yàn)檎鎸?shí)項(xiàng)目里你幾乎不會(huì)只用一種。比如做一個(gè)合同信息抽取你可能會(huì)先用 Few-shot 固定輸出格式再對其中判斷條款是否對己方不利這種需要推理的子任務(wù)加 CoT。如果只記定義你會(huì)糾結(jié)這到底算 Few-shot 還是 CoT用檔位視角你只會(huì)關(guān)心這一步我需要給模型補(bǔ)什么信息。我見過太多人卡在概念分類上反而耽誤了真正該做的調(diào)優(yōu)。記住范式是工具不是考試題。2. Zero-shot別小看什么都不給的難度Zero-shot 看起來最簡單其實(shí)最考驗(yàn)?zāi)銓θ蝿?wù)描述的精準(zhǔn)度。因?yàn)槟Ｐ蜎]有任何參照全靠你的指令去對齊它的理解。2.1 Zero-shot 真正難在哪難在你以為說清楚了其實(shí)沒有。比如總結(jié)一下這篇文章模型不知道你要多長、給誰看、要不要保留數(shù)據(jù)、要不要帶觀點(diǎn)。它只能猜而猜的結(jié)果十有八九不是你要的。我自己的經(jīng)驗(yàn)是Zero-shot 的提示詞里至少要交代清楚四件事任務(wù)是什么、輸出給誰看、輸出什么格式、有什么約束。這四件事缺一件結(jié)果就會(huì)飄。舉個(gè)具體的請把下面這段產(chǎn)品介紹改寫成給非技術(shù)用戶看的版本。 要求 - 面向完全沒有技術(shù)背景的普通消費(fèi)者 - 控制在 150 字以內(nèi) - 不使用任何專業(yè)術(shù)語如果必須用要加一句大白話解釋 - 語氣親切不要用感嘆號對比一下幫我改寫得更通俗一點(diǎn)你會(huì)發(fā)現(xiàn)前者幾乎不需要二次修改后者你得來回好幾輪。差別就在于約束是否顯式。2.2 指令的顆粒度怎么把握顆粒度太粗模型自由發(fā)揮太細(xì)又容易把模型框死反而寫出機(jī)械的答案。我的判斷標(biāo)準(zhǔn)是凡是結(jié)果對不對取決于它的必須寫死凡是風(fēng)格好不好的給方向就行。比如做數(shù)據(jù)清洗輸出必須是合法 JSON這個(gè)必須寫死甚至要給字段名和類型。但如果是寫營銷文案你只需要說活潑一點(diǎn)、面向年輕人具體怎么活潑交給模型它往往比你規(guī)定得更自然。2.3 一個(gè)常被忽略的技巧用角色 任務(wù) 約束三段式這是 Zero-shot 里最穩(wěn)的結(jié)構(gòu)我?guī)缀踉谒泻唵稳蝿?wù)里都用角色你是一位有十年經(jīng)驗(yàn)的財(cái)務(wù)分析師任務(wù)請分析下面這份利潤表指出三個(gè)最值得關(guān)注的問題約束每個(gè)問題用一句話說明并給出對應(yīng)的數(shù)據(jù)支撐不要泛泛而談角色不是玄學(xué)它的作用是幫模型快速定位到某個(gè)知識分布和表達(dá)風(fēng)格。你讓它當(dāng)財(cái)務(wù)分析師它調(diào)用的就是財(cái)務(wù)領(lǐng)域的表達(dá)習(xí)慣和關(guān)注點(diǎn)比你不給角色要準(zhǔn)得多。提示角色要具體到領(lǐng)域 經(jīng)驗(yàn)層級你是一個(gè)助手這種等于沒寫。3. Few-shot樣例給對了效果翻倍給錯(cuò)了全盤皆輸Few-shot 是我在工程里用得最多的范式因?yàn)榇蟛糠謽I(yè)務(wù)任務(wù)都需要固定格式和特定風(fēng)格而這些靠文字描述很難說清給兩個(gè)樣例模型立刻就懂了。3.1 樣例數(shù)量不是越多越好很多人一上來就給十個(gè)樣例覺得越多越準(zhǔn)。實(shí)測下來3 到 5 個(gè)高質(zhì)量樣例通常就夠了再多邊際收益很低還白白吃掉上下文長度。更重要的是樣例的覆蓋度而不是數(shù)量。什么叫覆蓋度就是你的樣例要覆蓋任務(wù)里可能出現(xiàn)的各種情況。比如做情感分類你不能五個(gè)樣例全是正面和負(fù)面得有一個(gè)中性或者模棱兩可的否則模型遇到邊界情況就懵。3.2 樣例的順序會(huì)悄悄影響結(jié)果這一點(diǎn)很多人不知道。模型對樣例順序是有敏感性的尤其是分類任務(wù)。如果你把某一類的樣例都放在前面模型可能會(huì)輕微偏向這一類。我的做法是打散順序讓各類樣例交替出現(xiàn)減少位置偏差。另外最后一個(gè)樣例的影響往往最大因?yàn)樗x你的真實(shí)輸入最近。所以如果你有特別想強(qiáng)調(diào)的格式或風(fēng)格把它放在最后一個(gè)樣例里。3.3 樣例的格式必須和真實(shí)輸入完全一致這是踩過坑才知道的。有一次我做信息抽取樣例里的輸入是規(guī)整的短句結(jié)果真實(shí)數(shù)據(jù)里全是帶各種符號和換行的長文本模型直接崩了輸出格式全亂。后來我把樣例換成和真實(shí)數(shù)據(jù)同分布的長文本問題立刻解決。所以給樣例前先看一眼你的真實(shí)輸入長什么樣樣例必須長得像它。格式、長度、噪聲程度都要接近模型才能泛化過去。3.4 Few-shot 和 Zero-shot 的取舍判斷什么時(shí)候該上 Few-shot我的經(jīng)驗(yàn)是三條里中一條就該上輸出格式有嚴(yán)格要求JSON、表格、特定模板任務(wù)風(fēng)格很特殊文字描述說不清比如某種品牌調(diào)性Zero-shot 試了兩三次還是不穩(wěn)定反過來如果任務(wù)很通用、格式隨意、模型本來就擅長那就別浪費(fèi)上下文Zero-shot 直接上。4. CoT 思維鏈讓模型想出來而不是猜出來CoT 是這三個(gè)里最容易被神化也最容易被誤用的。它的核心思想很簡單讓模型把推理過程寫出來而不是直接給答案。但什么時(shí)候用、怎么用講究很多。4.1 CoT 為什么有效把隱式計(jì)算變成顯式步驟大模型本質(zhì)上是逐 token 生成的它沒有真正的思考過程。當(dāng)你直接問一個(gè)多步問題它必須在一次前向計(jì)算里把答案蹦出來中間步驟全被壓縮了容易出錯(cuò)。CoT 的做法是強(qiáng)制它把中間步驟一個(gè)個(gè)寫出來。每寫一步這一步的結(jié)果就變成了下一步的輸入條件相當(dāng)于把一個(gè)大計(jì)算拆成了多個(gè)小計(jì)算。這就是為什么在數(shù)學(xué)、邏輯、多步推理任務(wù)上加了 CoT 之后準(zhǔn)確率能明顯提升。用個(gè)類比你讓一個(gè)人心算 37 乘 24他可能算錯(cuò)但你讓他拿紙筆一步步寫正確率立刻上去。CoT 就是給模型遞了張紙。4.2 最簡 CoT一句話觸發(fā)最簡單的 CoT 甚至不需要樣例只要在提示詞末尾加一句請一步一步思考并展示你的推理過程最后再給出結(jié)論。這一句話在很多任務(wù)上就能帶來明顯提升。但要注意展示推理過程和給出答案要分開要求否則模型可能把推理和答案混在一起你提取結(jié)果時(shí)很麻煩。4.3 Zero-shot CoT 和 Few-shot CoT 的區(qū)別Zero-shot CoT只加一步步思考的指令不給推理樣例。適合模型本身就會(huì)推理、只是沒被激發(fā)的情況。Few-shot CoT給幾個(gè)帶完整推理過程的樣例讓模型模仿推理的格式和深度。適合推理路徑比較特殊、或者你希望推理風(fēng)格統(tǒng)一的情況。Few-shot CoT 的樣例里推理過程要寫得像人話不要跳步。我見過有人樣例里推理寫得太簡略結(jié)果模型也學(xué)著跳步最后還是錯(cuò)。4.4 CoT 的適用邊界不是所有任務(wù)都該用這是最重要的一點(diǎn)。CoT 在需要多步推理的任務(wù)上有效但在簡單任務(wù)上反而可能變差。原因有兩個(gè)一是簡單任務(wù)本來一步就能出結(jié)果強(qiáng)行分步反而引入噪聲二是輸出變長模型有更多機(jī)會(huì)想多了跑偏。所以判斷標(biāo)準(zhǔn)是這個(gè)任務(wù)人需不需要打草稿需要打草稿的數(shù)學(xué)、邏輯、規(guī)劃、復(fù)雜判斷上 CoT不需要的翻譯、改寫、簡單分類別上。任務(wù)類型是否建議 CoT原因數(shù)學(xué)應(yīng)用題強(qiáng)烈建議多步計(jì)算中間易錯(cuò)邏輯推理強(qiáng)烈建議需要逐步排除情感分類不建議一步判斷加了反而飄文本翻譯不建議直接映射無需推理復(fù)雜決策分析建議需要權(quán)衡多個(gè)因素5. 三者組合真實(shí)項(xiàng)目里沒人只用一種講完三個(gè)單獨(dú)的范式該說說組合了。真實(shí)項(xiàng)目里尤其是稍微復(fù)雜一點(diǎn)的任務(wù)幾乎都是組合使用。5.1 Few-shot CoT復(fù)雜任務(wù)的標(biāo)準(zhǔn)配置這是最常用的組合。樣例里既包含輸入輸出又包含推理過程。模型既學(xué)到了格式又學(xué)到了推理路徑。寫這種樣例時(shí)有個(gè)技巧推理過程要寫得比實(shí)際需要稍微詳細(xì)一點(diǎn)給模型留出模仿空間。但也不能太啰嗦否則模型會(huì)學(xué)得又臭又長。我的經(jīng)驗(yàn)是推理步驟控制在 3 到 6 步之間比較合適。5.2 分層使用不同子任務(wù)用不同范式一個(gè)復(fù)雜任務(wù)往往可以拆成幾個(gè)子任務(wù)每個(gè)子任務(wù)用最適合它的范式。比如做一個(gè)從用戶反饋里提取問題并判斷優(yōu)先級的任務(wù)第一步提取問題用 Few-shot 固定輸出格式第二步判斷優(yōu)先級用 CoT因?yàn)樾枰獧?quán)衡影響范圍和緊急程度第三步生成回復(fù)建議用 Zero-shot因?yàn)楦袷诫S意、模型擅長這樣拆開之后每一段都更可控出問題也容易定位是哪一步的鍋。5.3 組合時(shí)的上下文預(yù)算管理組合用得多上下文消耗就快。這時(shí)候要有預(yù)算意識樣例不是越多越好推理不是越細(xì)越好。我一般會(huì)先跑一版看哪部分對結(jié)果影響最大把預(yù)算往那部分傾斜其他部分能省則省。注意上下文塞太滿模型對中間部分的注意力會(huì)下降反而影響效果。寧可精簡不要堆砌。6. 那些文檔里不會(huì)寫的實(shí)操坑前面講的都是方法論這一節(jié)講點(diǎn)真金白銀踩出來的經(jīng)驗(yàn)。6.1 樣例里的錯(cuò)誤會(huì)被模型完美復(fù)制這是最坑的一點(diǎn)。你樣例里但凡有個(gè)錯(cuò)別字、格式不一致、邏輯小錯(cuò)誤模型會(huì)一絲不茍地學(xué)過去。所以樣例給出去之前一定要逐字檢查。我現(xiàn)在的習(xí)慣是樣例寫完先自己當(dāng)模型跑一遍看有沒有歧義。6.2 指令和樣例沖突時(shí)模型往往聽樣例的如果你文字里說輸出用中文但樣例全是英文模型大概率跟著樣例走。所以指令和樣例必須一致不能打架。這個(gè)坑我在做多語言任務(wù)時(shí)踩過改了半天指令沒用最后發(fā)現(xiàn)是樣例語言不對。6.3 CoT 的推理過程可能看起來很對但結(jié)論錯(cuò)模型寫出來的推理過程是它生成的不是它真實(shí)計(jì)算的。所以它可能寫出一段邏輯通順但結(jié)論錯(cuò)誤的推理。這時(shí)候不能只看推理像不像樣必須驗(yàn)證結(jié)論。我的做法是讓模型給出結(jié)論后再單獨(dú)問一遍這個(gè)結(jié)論對嗎請檢查相當(dāng)于讓它自查一次。6.4 溫度參數(shù)和范式要匹配Zero-shot 想要穩(wěn)定輸出溫度調(diào)低CoT 想要多樣推理溫度可以稍高。但很多人調(diào)范式的時(shí)候忘了調(diào)溫度結(jié)果效果忽好忽壞。這兩個(gè)是要一起調(diào)的。6.5 別指望一次寫對迭代才是常態(tài)我寫過的提示詞幾乎沒有一次成型的。都是先寫一版跑一批測試數(shù)據(jù)看哪類錯(cuò)得多針對性改再跑。這個(gè)過程通常要三到五輪。所以別追求一次寫出完美提示詞追求快速迭代到能用。7. 從零搭一套自己的提示詞測試流程光會(huì)寫還不夠你得能驗(yàn)證寫得好不好。這一節(jié)講怎么搭一個(gè)簡單的測試流程。7.1 準(zhǔn)備一批有代表性的測試樣本不用多20 到 50 條就夠但必須覆蓋各種情況典型的、邊界的、容易出錯(cuò)的。這批樣本是你判斷提示詞好壞的唯一依據(jù)比拍腦袋感覺靠譜得多。7.2 定義清楚的評判標(biāo)準(zhǔn)什么叫好是格式對、內(nèi)容準(zhǔn)、還是風(fēng)格像不同任務(wù)標(biāo)準(zhǔn)不同。我一般會(huì)列三到五條硬標(biāo)準(zhǔn)比如輸出必須是合法 JSON關(guān)鍵字段不能漏語氣符合要求逐條打分。7.3 記錄每次改動(dòng)和結(jié)果這一步很多人省了但特別重要。你改了哪句話、效果變好還是變差記下來。不然改到后面你自己都忘了哪版最好。我用一個(gè)簡單的表格記版本改動(dòng)內(nèi)容通過率主要問題v1初始版本60%格式偶爾錯(cuò)v2加了一個(gè)格式樣例85%邊界情況漏字段v3補(bǔ)了邊界樣例95%基本可用有了這個(gè)表你一眼就能看出哪次改動(dòng)有效哪次是白費(fèi)功夫。7.4 什么時(shí)候算夠用不要追求 100% 通過率那通常意味著你過擬合到測試集了。我的標(biāo)準(zhǔn)是核心場景全過邊界場景大部分過錯(cuò)誤可接受且可兜底。剩下的交給后處理或者人工兜底比無限調(diào)提示詞劃算得多。8. 幾個(gè)真實(shí)場景的完整提示詞拆解理論講完來看幾個(gè)能直接抄的例子。8.1 場景一結(jié)構(gòu)化信息抽取Few-shot你是一位專業(yè)的信息抽取助手。請從下面的文本中抽取指定字段輸出 JSON。 字段說明 - name: 人名字符串 - company: 公司名字符串沒有則填 null - role: 職位字符串沒有則填 null 示例1 輸入張三在字節(jié)跳動(dòng)擔(dān)任產(chǎn)品經(jīng)理。 輸出{name: 張三, company: 字節(jié)跳動(dòng), role: 產(chǎn)品經(jīng)理} 示例2 輸入李四最近離職了暫時(shí)沒有新東家。 輸出{name: 李四, company: null, role: null} 現(xiàn)在請?zhí)幚?輸入王五加入了美團(tuán)負(fù)責(zé)騎手運(yùn)營。這個(gè)例子的關(guān)鍵點(diǎn)字段說明寫清楚、樣例覆蓋了有值和null兩種情況、格式嚴(yán)格一致。8.2 場景二多步推理判斷CoT你是一位資深運(yùn)營分析師。請判斷下面這條用戶反饋的緊急程度高/中/低并說明理由。 請按以下步驟思考 1. 這條反饋涉及的問題影響多少用戶 2. 問題是否影響核心功能 3. 是否有替代方案 4. 綜合以上給出緊急程度。 反饋內(nèi)容今天下午開始所有用戶都無法登錄提示密碼錯(cuò)誤但我們后臺看密碼沒問題。這個(gè)例子里步驟是顯式給出的模型會(huì)照著走。對于判斷類任務(wù)把判斷維度列出來比讓它自由發(fā)揮穩(wěn)定得多。8.3 場景三風(fēng)格化改寫Zero-shot 角色你是一位有十年經(jīng)驗(yàn)的科技媒體編輯擅長把技術(shù)內(nèi)容寫得讓普通人也能看懂。 請把下面這段技術(shù)說明改寫成面向普通讀者的版本 - 控制在 200 字以內(nèi) - 不使用專業(yè)術(shù)語 - 用一個(gè)生活化的類比幫助理解 - 語氣平實(shí)不夸張 技術(shù)說明本系統(tǒng)采用分布式架構(gòu)通過一致性哈希算法實(shí)現(xiàn)數(shù)據(jù)分片并利用多副本機(jī)制保證高可用性。這個(gè)例子沒有樣例全靠角色和約束把方向定死。對于改寫類任務(wù)角色 約束的組合往往比給樣例更靈活。9. 關(guān)于提示詞工程會(huì)不會(huì)過時(shí)這件事最后聊個(gè)大家常問的問題。總有人說模型越來越強(qiáng)提示詞工程遲早沒用。我的看法是基礎(chǔ)范式不會(huì)過時(shí)但具體技巧會(huì)不斷更新。Zero-shot、Few-shot、CoT 這三個(gè)東西本質(zhì)上是在解決如何把任務(wù)信息有效地傳達(dá)給模型這個(gè)根本問題。只要模型還是通過上下文來理解任務(wù)這個(gè)問題的解法就不會(huì)消失。變的只是形式——以前要手寫 CoT現(xiàn)在有些模型內(nèi)置了推理能力你只需要觸發(fā)它。所以與其焦慮會(huì)不會(huì)過時(shí)不如把這三個(gè)范式的底層邏輯吃透。你理解了為什么要給樣例為什么要分步無論模型怎么迭代你都能快速找到對應(yīng)的用法。這才是真正值錢的東西。我自己現(xiàn)在的習(xí)慣是每換一個(gè)新模型都會(huì)拿這三個(gè)范式各跑一遍手頭的典型任務(wù)看看新模型在哪方面變強(qiáng)了、哪方面還需要提示詞補(bǔ)。這個(gè)習(xí)慣幫我省了很多瞎調(diào)的時(shí)間。