大語言模型提示詞工程詳盡實戰指南

引言:與大型語言模型(LLM)高效對話的藝術

大型語言模型(LLM)——例如我們熟知的GPT系列、Claude、Llama等——在自然語言處理(NLP)領域展現了驚人的能力,能夠執行文本摘要、翻譯、代碼生成甚至邏輯推理等多種任務 1。這些模型基于Transformer架構,通過在海量數據上進行預訓練,學會了語言的復雜模式和知識 3。然而,要充分釋放這些模型的潛力,僅僅依賴其預訓練知識是不夠的。LLM雖然能模仿人類,但它們缺乏真正的意圖理解和上下文感知能力 4。它們的工作方式本質上是基于過去的訓練數據,預測最可能的下一個詞(或標記)來生成回應 2。

這時候,“提示詞工程”(Prompt Engineering)就顯得至關重要了。它不僅僅是簡單地向模型提問,更是一門藝術和科學,專注于設計、優化和構建能夠有效引導LLM產生期望輸出的指令(即“提示詞” Prompt)8。一個精心設計的提示詞,就像是給AI的詳細路線圖 8,它提供了必要的上下文、清晰的指令、具體的約束,有時甚至包含示例,幫助模型準確理解我們的意圖,并生成高質量、相關且符合要求的輸出 5。

本人在與各類LLM交互的過程中深刻體會到,提示詞的質量直接決定了輸出的成敗。模糊或結構不良的提示詞往往導致模型的回應偏離主題、信息不準確,甚至產生“幻覺”(即生成看似合理但與事實不符的內容)12。反之,一個好的提示詞能夠顯著提升模型的表現,使其在特定任務上(如遵循特定格式、扮演特定角色、進行復雜推理)更加可靠和高效 3。

提示詞工程的重要性日益凸顯,它已經成為與LLM有效互動和開發相關應用的基礎技能 10。它不僅關乎提升輸出質量,減少后期修改工作 3,也涉及到引導模型行為、規避偏見、確保AI應用的安全性和可靠性 4。隨著LLM技術的不斷發展,掌握提示詞工程無疑將成為AI開發者、研究人員乃至普通用戶不可或缺的能力 4。

這份指南旨在系統性地梳理提示詞工程的核心概念、基本原則、關鍵技術和高級策略。我將結合權威研究和我個人的實踐經驗,提供一個詳盡的教程,幫助你理解并掌握如何構建高效的提示詞,從而更好地駕馭大型語言模型。我們將從基礎定義出發,逐步深入探討各種技術和評估方法,最終目標是讓你能夠自信地運用提示詞工程,與LLM進行更富有成效的對話。

1. 提示詞工程:定義、重要性與作用

1.1. 什么是提示詞工程?核心定義解析

提示詞工程(Prompt Engineering),顧名思義,是圍繞“提示詞”(Prompt)進行設計、構建和優化的過程 8。這里的“提示詞”,在AI(特別是生成式AI)領域,指的是我們提供給模型的輸入,旨在引導模型產生特定的回應 6。這輸入可以非常多樣,從簡單的關鍵詞、問題,到復雜的指令描述、代碼片段,乃至包含背景信息和示例的長篇文本 8。

權威機構如Google Cloud將提示詞工程定義為“設計和優化提示詞以引導AI模型(特別是LLM)生成期望響應的藝術和科學” 8。AWS則將其描述為“引導生成式AI解決方案產生期望輸出的過程”,強調需要詳細指令來獲得高質量和相關的輸出 2。IBM認為,提示詞工程師扮演著關鍵角色,他們精心制作查詢,幫助模型理解語言的細微差別和用戶意圖 3。而學術研究,例如一篇系統性綜述指出,提示詞工程是一種不可或缺的技術,它利用任務特定的指令(提示詞)來擴展LLM和VLM(視覺語言模型)的能力,而無需修改核心模型參數 15。

綜合來看,提示詞工程的核心在于策略性地設計輸入,以最有效地利用和引導底層模型(LLM)的能力 4。它不僅僅是“提問”,更是一種結構化指令、提供上下文、設定約束、甚至模仿交互的過程 9。我個人的理解是,這有點像是在和一位知識淵博但有時缺乏方向感的助手溝通,你需要清晰地告訴他做什么、怎么做、需要注意什么,甚至給他看幾個范例,他才能最好地完成任務。

1.2. 為何提示詞工程如此重要?

大型語言模型雖然強大,但它們并非“讀心者”。它們基于海量的訓練數據學習語言模式 2,卻缺乏對特定任務的內在理解或真實意圖的把握 4。提示詞正是彌合這一差距的關鍵橋梁 2。其重要性體現在以下幾個方面:

  1. 引導與聚焦 (Guidance and Focus): LLM的知識廣闊,但沒有明確指引,它們的回答可能泛泛而談,甚至偏離主題 4。有效的提示詞能夠將模型的“注意力”引導到任務的核心方面,確保輸出的相關性 4。例如,明確要求“總結報告的關鍵發現”比“談談這份報告”更能獲得聚焦的答案 8。

  2. 控制輸出質量與形式 (Output Control): 提示詞工程允許用戶對模型的輸出施加控制 5。你可以通過提示詞指定回應的風格(如正式、幽默)、語氣(如嚴肅、活潑)、格式(如列表、表格、JSON)、長度等 4。這對于需要特定產出的應用(如生成特定格式的報告、撰寫特定風格的文案)至關重要。

  3. 解鎖模型潛力與適應性 (Unlocking Potential & Adaptability): LLM是通用模型,具備執行多種任務的潛力 2。提示詞工程使得無需重新訓練或微調模型,就能讓同一個LLM適應廣泛的任務和領域 4。通過為不同任務量身定制提示詞,開發者和用戶可以充分發掘LLM在教育、研究、客服、內容創作等多個場景的應用價值 4。

  4. 提升準確性與可靠性 (Accuracy & Reliability): 精心設計的提示詞能顯著提高模型輸出的準確性和事實一致性 3。尤其是在結合外部知識源(如RAG技術,后文會詳述)時,提示詞可以將相關信息整合進上下文,幫助模型生成更可靠、更少“幻覺”的答案 12。

  5. 降低偏差與倫理風險 (Bias Mitigation & Ethics): LLM可能在訓練數據中學習到并復制有害的偏見或刻板印象 4。通過審慎地設計提示詞,例如明確要求公正、避免歧視性語言,可以在一定程度上引導模型產生更公平、無偏見的回應 4。雖然這不能完全解決偏見問題,但提示詞是重要的干預手段之一。

  6. 效率提升與成本節約 (Efficiency & Cost Saving): 高質量的提示詞能讓模型“一次性”產生更接近期望的輸出,減少反復試錯和后期編輯修改的需求 3。這不僅節省了時間,也降低了調用LLM API的計算成本。

我個人的經驗是,投入時間優化提示詞,往往比反復修改模型輸出要高效得多。一個好的提示詞是與LLM高效協作的杠桿。

1.3. 提示詞工程在LLM交互中的作用

提示詞工程在與LLM的交互中扮演著“指令發出者”和“行為塑造者”的雙重角色。

  • 作為指令 (Instruction): 提示詞是用戶向LLM傳達意圖和任務要求的主要方式 6。它告訴模型“做什么”(What to do),例如“寫一首關于海洋的詩” 24 或“分析這份財報的盈利能力” 8。

  • 作為上下文提供者 (Context Provider): 提示詞為LLM提供了理解任務背景所需的信息 5。它幫助模型理解“在什么情況下做”(Under what circumstances),例如提供相關事實 8、之前的對話歷史 25 或需要處理的特定數據 12。

  • 作為行為塑造者 (Behavior Shaper): 通過特定的措辭、格式要求、角色設定或示例,提示詞能夠引導和塑造LLM的回應方式 5。它影響著模型“如何做”(How to do it),例如要求模型以特定專家的口吻回答 18,或者要求輸出遵循特定的JSON結構 27。

從技術角度看,提示詞是LLM開始預測并生成新詞元(token)的起點 6。模型會基于提示詞的內容和其內部學到的模式,來預測最可能接續的詞元序列,從而形成回應。因此,提示詞的每一個詞、每一個符號,都可能影響模型的預測路徑和最終輸出 28。

實踐中我發現,提示詞工程是一個迭代優化的過程 2。很少能第一次就寫出完美的提示詞。通常需要根據模型的初步輸出來分析問題所在(是指令不清?上下文不足?還是格式沒指定?),然后不斷調整和改進提示詞,直至獲得滿意的結果 27。這個過程需要創造力,也需要耐心和細致的實驗 2。

2. 設計有效提示詞的基本原則

構建能夠引導LLM產生高質量輸出的提示詞,并非隨心所欲,而是遵循一系列基本原則。這些原則幫助我們確保提示詞能夠被模型準確理解并有效執行。我在實踐中總結并驗證了以下幾個關鍵原則,它們與許多權威指南的建議是一致的。

2.1. 明確性與具體性 (Clarity and Specificity)

這是最核心的原則。提示詞必須清晰、明確,盡量減少歧義和解釋空間 6。模糊的指令只會導致模糊或不可預測的輸出 13。

  • 行動導向: 使用清晰的動詞來指定期望的操作 8。例如,用“撰寫”、“總結”、“分類”、“翻譯”、“比較”等,而不是模糊的“關于”、“處理”。

  • 精確描述: 避免使用含糊不清的詞語(如“一些”、“更好”、“長一點”)。盡可能量化要求 21。例如,不說“寫長一點”,而是說“寫一篇大約500字的文章” 8 或“用三個要點總結” 27。

  • 限定范圍: 明確任務的邊界和范圍 18。例如,在請求分析報告時,指明是分析“過去五年的盈利能力” 8,而不是籠統地“分析公司財務”。

  • 消除歧義: 識別并澄清可能引起誤解的術語或概念 13。如果術語有多種含義,需在上下文中明確其指代 35。例如,“解釋Python(作為編程語言)的概念” 35。

我的經驗: 我曾嘗試讓模型“寫一個關于AI的故事”,結果五花八門,大多不符合我的設想。當我把提示詞改為“寫一個設定在火星上的科幻短篇故事,聚焦于第一個人類殖民地的生活” 27,得到的輸出就精確多了。明確性和具體性是獲取目標輸出的第一步。

2.2. 提供充足的上下文 (Context Provision)

LLM本身沒有記憶或對特定情境的先驗知識,除非我們在提示詞中提供 5。上下文為模型提供了理解任務背景、約束條件和相關信息的框架,是生成相關且準確回應的關鍵 5。

  • 背景信息: 提供必要的背景知識或情境描述 5。例如,“考慮到當前的經濟衰退背景,請提供投資建議” 36。

  • 相關數據/事實: 包含模型需要用來推理或回答問題的數據或事實 8。例如,“鑒于全球氣溫自工業化前已上升1攝氏度,討論海平面上升的潛在后果” 8。

  • 引用來源: 如果需要模型基于特定文檔或信息源回答,應在提示詞中明確指出或提供相關內容 8。這對于需要事實依據的任務(如RAG)尤其重要。

  • 定義關鍵術語: 對可能不明確或有特定含義的術語進行定義 8。

  • 多輪對話維護: 在連續對話中,需要通過提示詞(或系統機制)來維持上下文,例如引用之前的對話要點 5。

我的經驗: 在處理需要特定領域知識的任務時,比如分析一份具體的財務報告 8,或者讓模型遵循特定的內部操作流程,僅僅給出指令是遠遠不夠的。必須將報告內容或流程步驟作為上下文提供給模型,它才能基于這些信息進行操作。上下文就像是給模型的“原材料”。

2.3. 設定角色或視角 (Role Setting / Persona Assignment)

指示LLM扮演一個特定的角色或采用某種視角,是一種強大的技術,可以顯著影響回應的風格、語氣、專業深度和內容 5。

  • 明確角色: 在提示詞開頭清晰地指定角色 5。例如,“你是一位經驗豐富的市場分析師...” 18,“扮演一位耐心的數學老師...” 37,“假設你是一名莎士比亞戲劇演員...” 36。

  • 利用專業知識: 通過設定專家角色(如醫生、律師、程序員),可以引導模型調用相關的專業知識和術語 18。

  • 控制語氣風格: 角色設定自然地影響語氣。例如,“扮演一個幽默的導游”會比“扮演一個嚴肅的歷史學家”產生更輕松的語調 4。

  • 多視角分析: 可以要求模型從不同角色或立場出發,對同一問題提供多角度的看法 5。例如,“從開發者和用戶的角度,分別闡述這項新功能的優缺點” 5。

我的經驗: 我曾需要為初學者解釋量子計算的概念。直接提問得到的答案雖然正確,但術語過多。當我讓模型“扮演一位能夠向11歲孩子解釋復雜概念的科學教師” 24 時,得到的解釋就非常通俗易懂,并且使用了恰當的比喻。角色設定是調整輸出風格和深度的有效工具。

2.4. 施加約束與指令 (Constraints and Instructions)

清晰地告知模型需要遵守的規則和限制,有助于確保輸出符合特定要求 5。

  • 格式約束: 明確指定輸出的格式,如項目列表、編號列表、表格、JSON對象、代碼塊等 5。例如,“請以JSON格式返回結果,包含'name'和'age'字段”。

  • 長度約束: 設定輸出的長度限制,如字數、段落數、句子數 8。例如,“用不超過100字總結” 18。

  • 內容約束: 指示模型包含或排除特定信息 21。例如,“在你的回答中必須包含對可持續性的討論” 24 或“只描述產品的優點,不要提及特性” 43。

  • 風格/語氣約束: 直接指定所需的溝通風格或語氣(補充角色設定)4。例如,“使用正式、專業的語調” 43。

  • 使用分隔符: 使用特殊字符(如###, ``, <tag>`)來清晰地界定提示詞的不同部分(如指令、上下文、輸入數據),幫助模型區分和聚焦 6。

我的經驗: 在需要模型生成結構化數據(例如,用于程序處理的JSON)時,明確的格式約束是必不可少的。我發現,如果不指定格式,模型可能會返回自然語言描述,這需要額外的解析工作。使用約束就像是給輸出設定了一個“模具”。

2.5. 使用肯定式指令 (Affirmative Directives)

指導模型“做什么”(Do this)通常比告訴它“不要做什么”(Don't do that)更有效 21。LLM有時難以完全遵循否定指令。

  • 正面表述: 將否定性約束改寫為肯定性指令。例如,與其說“不要使用復雜的詞匯”,不如說“請使用簡單易懂的語言” 21。與其說“別忘了提及A”,不如說“請務必包含A” 24。

  • 聚焦目標: 明確指出期望的行為或結果。例如,“請提供簡潔的摘要”優于“不要寫太多細節” 21。

我的經驗: 我曾經指示模型“不要包含2000年以前的例子”,但結果中偶爾還是會出現舊例子。當我改為“請提供2000年及以后的例子” 21 后,效果好了很多。這雖然是個小細節,但確實有影響。我個人感覺,肯定式指令讓目標更清晰。

2.6. 提供示例(Few-Shot原則)(Providing Examples)

在提示詞中包含一到多個輸入輸出示例(Few-shot Prompting),是引導模型理解復雜任務、特定格式或風格的強大手段 8。這利用了LLM的上下文學習(In-Context Learning, ICL)能力 45。

  • 示范格式/風格: 示例可以直觀地展示期望的輸出結構、語氣或內容模式 4。

  • 處理復雜任務: 對于難以用語言清晰描述的指令,示例往往更有效 30。

  • 數量與質量: 示例的數量(one-shot vs. few-shot)和質量很關鍵 30。通常需要2-5個高質量、相關的示例 47。示例應覆蓋不同的情況,避免模式過于單一 30。

  • 格式一致性: 提供的示例應遵循一致的格式 30。

  • 隨機順序: 示例的順序有時會影響結果(新近度偏見 6),建議隨機排列或混合不同類別的示例 30。

我的經驗: 當我需要模型將非結構化文本轉換為特定JSON格式時,僅用指令描述往往不夠精確。提供幾個轉換示例后 46,模型的輸出準確率和格式遵循度都大幅提升。示例就像是給模型看的“樣板”。

遵循這些基本原則,可以顯著提高提示詞的有效性,從而引導LLM生成更符合預期的、高質量的輸出。當然,這些原則并非孤立存在,往往需要結合使用,并通過不斷的迭代(下一節將詳述)來找到最佳的平衡點。

3. 剖析高質量提示詞:關鍵構成要素

一個結構良好、信息豐富的提示詞,通常包含幾個關鍵的組成部分。理解這些要素及其作用,有助于我們系統性地構建和優化提示詞。雖然并非每個提示詞都必須包含所有要素 30,但對于復雜任務,明確這些組成部分能帶來很大幫助。以下是我根據實踐和參考資料 12 總結的關鍵要素:

3.1. 指令 (Instruction / Directive)

這是提示詞的核心,明確告知模型需要執行的具體任務 12。指令應當清晰、直接、無歧義(遵循原則2.1)。

  • 作用: 定義LLM的目標和行動。

  • 形式: 通常是祈使句(如“總結…”、“翻譯…”、“生成…”)或疑問句(如“什么是…?”、“…的原因是什么?”)。

  • 例子:

    • "將以下文本分類為中性、負面或正面" 49 (分類任務指令)

    • "寫一個關于宇航員騎馬的高質量照片的描述" 9 (圖像生成任務指令)

    • "根據所附財務報告,分析公司過去五年的盈利能力" 8 (分析任務指令)

    • "你的任務是分析COVID-19的經濟影響" 24 (明確任務分配)

我的觀察: 指令的措辭至關重要。即使是同義詞,細微差別也可能導致模型理解偏差。例如,“解釋”和“闡述”可能會引導出不同深度和風格的回應。使用強指令性動詞(如“必須”、“需要”)有時能增強指令的約束力 24。

3.2. 上下文 (Context / Background Information)

上下文為模型提供了執行指令所需的背景信息、外部知識或約束環境 12。它幫助模型更好地理解任務的特定情況或條件,生成更相關、更準確的回應 5。

  • 作用: 減少歧義,提供必要知識,設定場景,引導模型關注特定方面。

  • 形式: 可以是事實陳述、背景描述、引用的文檔片段、之前的對話摘要、甚至是一系列示例(Few-Shot示例本身就是一種上下文)5。

  • 例子:

    • "鑒于全球氣溫已上升1攝氏度..." 8 (提供事實背景)

    • "以下是從維基百科檢索到的相關段落:[段落內容]" (RAG場景下的外部知識上下文) 12

    • "你正在扮演一位幫助學生學習西班牙語的語言導師。" 53 (角色扮演上下文)

    • 提供一系列“輸入文本 -> 情感標簽”的示例,用于Few-Shot分類任務 7。

我的觀察: 對于需要特定知識或超出模型訓練數據范圍(如近期事件、私有數據)的任務,上下文是必不可少的 12。上下文的質量和相關性直接影響輸出質量。提供不相關或冗余的上下文反而可能干擾模型 34。在RAG應用中,如何有效地將檢索到的文檔塊作為上下文整合到提示詞中,是一個關鍵的技術點 14。

3.3. 輸入數據 (Input Data)

這是模型需要直接處理或操作的具體信息 12。它構成了任務的主體內容。

  • 作用: 提供模型進行分析、轉換、回答等操作的對象。

  • 形式: 可以是文本段落、問題、代碼片段、數據集、用戶評論、待翻譯的句子等。

  • 例子:

    • "文本:我認為這食物還行。" 49 (用于情感分類的輸入文本)

    • "英文原文:'Hello, how are you?'" 39 (用于翻譯的輸入句子)

    • "需要總結的文章:[文章全文]" (用于摘要的輸入長文本)

    • "用戶反饋評論:[評論內容]" 27 (用于分析的輸入數據)

我的觀察: 輸入數據的清晰度和完整性對結果影響很大。如果輸入數據本身模棱兩可或包含錯誤,模型很難產生準確的輸出。對于需要處理大量輸入數據的情況(如長文檔摘要),需要考慮模型的上下文窗口限制,可能需要對輸入數據進行分塊處理或采用特殊技術。

3.4. 輸出指示器/格式 (Output Indicator / Format)

這部分明確了期望模型返回結果的類型、結構或格式 12。它為模型的輸出設定了“模板”。

  • 作用: 確保輸出符合后續處理或展示的要求,提高結果的可用性。

  • 形式: 可以是明確的格式說明(如“以JSON格式輸出”、“生成一個項目符號列表”)、語氣/風格要求(如“用正式語氣”、“像5歲小孩解釋一樣簡單”)、長度限制(如“總結成一句話”),或者是一個引導性的詞語(如在分類任務末尾加上“Sentiment:”)5。

  • 例子:

    • "Sentiment:" 49 (引導模型輸出情感標簽)

    • "輸出:" (通用輸出引導)

    • "請以項目符號列表的形式回答。" 5

    • "生成一個包含'標題'和'摘要'鍵的JSON對象。"

    • "用簡單的英語寫,就像你在向一個5歲的孩子解釋一樣。" 24

    • "確保你的回答是公正的,不依賴于刻板印象。" 24 (內容風格約束)

我的觀察: 輸出指示器對于獲得結構化、一致性的輸出至關重要。有時,僅僅在提示詞末尾添加一個簡單的詞(如“答案:”)就能有效引導模型給出期望的簡潔回答。對于復雜格式,提供一個輸出格式的示例(Few-Shot的一部分)通常比純文字描述更有效 30。

3.5. 元素之間的協同與平衡

這些要素并非孤立存在,它們共同作用,影響著最終的輸出。一個高質量的提示詞需要將這些要素有機地結合起來 34。

  • 指令是核心: 任務目標必須明確。

  • 上下文支撐指令: 上下文為指令的執行提供必要的信息和環境。

  • 輸入數據是對象: 指令和上下文最終作用于輸入數據。

  • 輸出格式規范結果: 輸出指示器確保結果以可用形式呈現。

平衡是關鍵。 過多的指令或上下文可能超出模型的處理能力(上下文窗口限制)或使其混亂 22。過少的細節則可能導致輸出過于寬泛或不準確 13。我個人的實踐表明,找到合適的平衡點需要反復試驗和調整(迭代過程)。

結構化提示詞模板示例:

為了更清晰地組織這些元素,有時我會使用模板結構,并用分隔符區分 6。例如:

指令

[清晰說明任務目標,例如:根據提供的上下文,回答以下問題。]

上下文

輸入數據

[給出具體的問題或需要處理的數據。例如:問題:XXX的主要原因是什么?]

輸出格式

[指定期望的輸出格式、長度、語氣等。例如:請用不超過三句話回答,并列出要點。]

輸出:

這種結構化方法有助于確保所有必要信息都已包含,并且模型能夠更容易地解析和理解提示詞的各個部分 6。當然,具體結構和分隔符可以根據任務和個人偏好調整。關鍵在于清晰地傳達意圖和要求。

4. 核心提示詞技術類型詳解

掌握了基本原則和構成要素后,我們來深入了解幾種在實踐中廣泛應用且效果顯著的核心提示詞技術。這些技術為與LLM交互提供了更強大的工具箱,尤其是在處理復雜任務時。

4.1. 零樣本提示 (Zero-Shot Prompting)

這是最基礎的提示技術。顧名思義,“零樣本”意味著我們在提示詞中不提供任何任務完成的具體示例 7。我們直接給出指令和輸入數據,完全依賴LLM在預訓練階段學到的知識和指令遵循能力來完成任務 35。

  • 工作原理: 大型語言模型(如GPT-3.5及之后版本、Claude 3等)經過了大規模數據訓練和指令微調(Instruction Tuning)以及基于人類反饋的強化學習(RLHF)55,使其能夠理解并執行未在訓練中明確見過的任務指令 55。

  • 示例:

    • 文本分類:將文本分類為中性、負面或正面。\n文本:我覺得這次假期還行。\n情感: 55

    • 翻譯:將“你好,世界”翻譯成法語。 7

    • 摘要:用一句話總結以下段落:[段落內容] 29

    • 問答:云計算如何幫助小企業? 54

    • 信息提取:從以下文本中提取人名和組織名:[文本內容] 54

  • 優點:

    • 簡單直接,易于構建提示詞 56。

    • 無需準備示例數據,效率高 54。

    • 適用于模型已經具備相關能力的簡單、直接的任務 29。

  • 缺點:

    • 對于復雜、新穎或需要特定輸出格式的任務,效果往往不佳 12。

    • 模型可能因缺乏具體指導而產生不準確或不相關的輸出 45。

    • 結果的可預測性相對較低 45。

  • 適用場景: 簡單問答、基本文本分類、常見語言翻譯、通用內容生成、初步探索模型能力等 45。

本人操作得知: 零樣本提示是我的起點。對于很多日常任務,比如快速獲取信息、簡單文本處理,它足夠有效。但一旦任務變得復雜或需要精確控制輸出,我就需要轉向更強大的技術。

4.2. 少樣本提示 (Few-Shot Prompting)

當零樣本提示效果不佳時,少樣本提示是自然的選擇。這種技術在提示詞中包含少量(通常是1到5個,或更多,但數量有限)任務完成的示例 8。這些示例向模型展示了期望的輸入-輸出行為模式。

  • 工作原理: Few-Shot Prompting利用了LLM強大的上下文學習(In-Context Learning, ICL)能力 45。模型在處理當前提示詞時,會“學習”輸入中包含的示例模式,并將這種模式應用到提示詞末尾的實際查詢中,而無需更新模型參數 45。

  • 變體:

    • 單樣本提示 (One-Shot Prompting): 只提供一個示例 29。適用于需要輕微引導或消除歧義的任務 45。

    • 少樣本提示 (Few-Shot Prompting): 提供兩個或更多示例 12。更利于模型識別復雜模式和處理多樣化輸入 45。

  • 示例:

    • 新詞使用:

      “whatpu”是一種原產于坦桑尼亞的小型毛茸茸動物。使用whatpu這個詞的例句是:我們在非洲旅行時看到了這些非常可愛的whatpus。
      “farduddle”的意思是快速地上下跳動。使用farduddle這個詞的例句是:
      輸出:當我們贏得比賽時,我們都開始farduddle慶祝。

      (模型通過一個例子學會了如何使用新詞造句)

      58

    • 情感分類 (含示例):

      這太棒了! // 負面
      這太糟糕了! // 正面
      哇,那部電影真棒! // 正面
      多么可怕的節目! //
      輸出:負面

      (即使標簽是隨機的,模型也能通過示例格式學習任務)

      58

    • 代碼生成 (含示例): 提示詞中包含其他Python函數的示例,然后要求生成階乘函數。相比零樣本,生成的代碼可能包含更好的輸入驗證和注釋 46。

  • 優點:

    • 顯著提升模型在復雜或新穎任務上的表現 12。

    • 能夠通過示例隱式地傳達期望的輸出格式、風格或語氣 4。

    • 對于只有少量標注數據的情況非常有用,避免了昂貴的模型微調 46。

  • 缺點:

    • 需要精心設計和挑選高質量、相關的示例 47。

    • 提示詞長度增加,受模型上下文窗口大小的限制 30。

    • 示例的選擇、順序和格式可能影響性能 6。

    • 示例過多可能導致模型“過擬合”到示例模式,泛化能力下降 42。

  • 適用場景: 復雜分類任務、需要特定輸出格式的任務(如JSON生成、代碼生成)、風格遷移、當零樣本效果不足且缺乏大量訓練數據時 30。

本人操作得知: 少樣本提示是我工具箱里的常用武器。當我需要模型輸出特定結構(比如特定格式的JSON)或者模仿某種寫作風格時,提供幾個好的示例幾乎總能帶來立竿見影的改善。關鍵在于示例的質量和代表性。我甚至有時會用LLM本身來幫我生成一些初步的示例 46。

4.3. 思維鏈提示 (Chain-of-Thought Prompting, CoT)

思維鏈(CoT)提示是一種旨在提升LLM復雜推理能力的技術 2。它通過引導模型在給出最終答案之前,先顯式地生成一系列中間推理步驟(即“思維鏈”),模仿人類解決復雜問題的思考過程 60。

  • 工作原理: CoT的核心思想是,將一個復雜的推理任務分解為多個更簡單的中間步驟,可以讓LLM更有效地處理 60。通過在提示詞中展示這種分步推理的過程(無論是通過示例還是直接指令),模型被鼓勵生成自己的推理鏈條,從而提高最終答案的準確性 60。

  • 兩種主要形式:

    1. 少樣本CoT (Few-Shot CoT):

      在提示詞中提供幾個完整的示例,每個示例都包含問題、詳細的推理步驟和最終答案

      60

      。模型學習這種“問題 -> 推理步驟 -> 答案”的模式。

      • 示例 (數學題):

        Q: 食堂原來有23個蘋果。他們用20個做午餐。所以他們剩下23 - 20 = 3個。他們又買了6個蘋果,所以他們現在有3 + 6 = 9個。答案是9。
        Q: 羅杰有5個網球。他又買了2罐網球。每罐有3個網球。他現在有多少個網球?
        A: 羅杰開始有5個球。2罐各有3個網球是6個網球。5 + 6 = 11。答案是11。

        (模型被展示了如何分步解決數學應用題)

        60

    2. 零樣本CoT (Zero-Shot CoT):

      無需提供示例,只需在問題末尾添加一個簡單的觸發短語,如“讓我們一步一步地思考” (Let's think step by step)

      63

      。這個簡單的指令就能誘導大型LLM生成推理過程

      67

      • 示例 (數學題):

        Q: 我去市場買了10個蘋果。我給了鄰居2個,修理工2個。然后我又去買了5個蘋果,吃了1個。我還剩下多少個蘋果?
        A: 讓我們一步一步地思考。
        輸出:
        開始時有10個蘋果。
        給鄰居2個,剩下10 - 2 = 8個。
        給修理工2個,剩下8 - 2 = 6個。
        又買了5個,現在有6 + 5 = 11個。
        吃了1個,最后剩下11 - 1 = 10個。
        答案是10。

        (對比直接問答可能出錯,加入觸發短語后模型進行了分步計算)

        64

  • 優點:

    • 顯著提高LLM在需要多步推理的任務(如算術、常識推理、符號推理)上的表現 2。

    • 使模型的推理過程更加透明和可解釋,便于調試和理解錯誤來源 60。

    • 能夠將復雜問題分解為更易于模型處理的子步驟 60。

  • 缺點:

    • 主要對足夠大的模型(通常指百億參數級別以上)才有效,被認為是一種“涌現能力” 60。

    • 少樣本CoT需要精心設計高質量的推理示例,成本較高 60。

    • 零樣本CoT雖然簡單,但生成的推理鏈有時可能包含錯誤或遺漏步驟 66。

    • 生成的推理過程可能非常冗長,增加API調用成本和延遲 74。

    • 零樣本CoT有時需要額外的步驟來從生成的文本中提取最終答案 69。

  • 適用場景: 算術應用題、邏輯謎題、常識問答、需要分步解決的復雜問題、需要解釋推理過程的場景 2。

本人操作得知: CoT是我解決復雜推理問題的首選技術。特別是零樣本CoT,用一句“讓我們一步一步地思考”就能顯著提升解題能力,這給我留下了深刻印象。雖然它不完美,有時推理會出錯,但相比直接問答,成功率高得多。對于要求極高準確率的任務,我會結合下面的自洽性技術使用。

4.4. 自洽性 (Self-Consistency)

自洽性是一種解碼策略,旨在提高思維鏈(CoT)推理的穩定性和準確性 77。它建立在CoT的基礎上,通過生成多個不同的推理路徑并選擇最一致的答案來工作 79。

  • 工作原理:

    1. 使用CoT提示: 首先,像進行CoT提示一樣,向LLM提供問題(通常帶有少樣本CoT示例或零樣本CoT觸發語)。

    2. 采樣多樣化推理路徑: 關鍵區別在于解碼階段。不使用貪婪解碼(只選擇最可能的下一步),而是采用采樣方法(如設置temperature > 0)多次運行同一個提示,生成多個(例如10個、40個或更多)不同的推理鏈 78。由于采樣的隨機性,這些推理鏈在中間步驟上會有所不同。

    3. 提取最終答案: 從每個生成的推理鏈中提取最終的答案。

    4. 聚合與選擇: 統計所有提取出的答案。采用多數投票(Majority Voting)等策略,選擇出現次數最多、最“一致”的那個答案作為最終輸出 77。

  • 核心思想: 復雜問題往往有多種解法都能得到唯一正確的答案 79。模型在推理中犯的錯誤往往是隨機的、多樣化的,而正確的推理路徑雖然可能不同,但更傾向于收斂到同一個正確答案 79。通過采樣大量路徑并取多數,可以有效“邊緣化”掉錯誤的推理路徑,提高最終答案的可靠性 79。它就像是模型內部進行了一次“自我投票”或“自我集成” 79。

  • 示例 (算術題):

    • 問題:我6歲時,妹妹是我年齡的一半。我現在70歲,妹妹多大?

    • 使用CoT提示并多次采樣,可能得到以下推理路徑和答案:

      • 路徑1:我6歲時妹妹3歲。年齡差是6-3=3歲。我現在70歲,妹妹是70-3=67歲。答案是67。

      • 路徑2:我6歲時妹妹3歲。我們相差3歲。我現在70歲,所以妹妹是70-3=67歲。答案是67。

      • 路徑3:我6歲時妹妹是6/2=3歲。我現在70歲,妹妹是70/2=35歲。答案是35。 (錯誤推理)

      • 路徑4:年齡差是3歲。我現在70歲,妹妹年齡是70-3=67。答案是67。

    • 聚合答案:{67, 67, 35, 67}。

    • 最終答案(多數投票):67 86。

  • 優點:

    • 顯著提升CoT在算術、常識和符號推理等任務上的性能,效果優于樸素的CoT 79。

    • 對于CoT可能出錯的問題,提供了更強的魯棒性 79。

    • 無需額外訓練或模型,是一種純粹的解碼時技術 79。

  • 缺點:

    • 計算成本高,因為需要為同一個問題多次調用LLM進行采樣 78。采樣次數越多,成本越高。

    • 最終效果依賴于采樣路徑的多樣性和多數答案的正確性。如果模型本身能力不足或問題極其困難,多數路徑可能都指向錯誤答案。

    • 近期研究指出,在極長上下文任務中,自洽性可能因位置偏差等問題而失效甚至降低性能 89。

  • 適用場景: 對推理準確性要求極高的任務,尤其是算術和常識推理,且可以接受更高計算成本的場景 79。

本人操作得知: 當我對CoT的結果還不夠放心時,自洽性是我的“殺手锏”。雖然它需要多次調用模型,成本較高,但在一些關鍵的計算或邏輯判斷任務上,用多次采樣和投票的方式來確認答案,確實能讓我對結果更有信心。我通常會采樣5-10次路徑,觀察答案的分布情況。

4.5. 其他值得關注的技術 (Brief Mention)

除了上述核心技術,還有一些其他重要的提示工程技術值得了解:

  • 生成知識提示 (Generated Knowledge Prompting): 在回答問題前,先提示LLM生成與問題相關的知識或事實,然后將這些生成的知識加入到原始提示中,以提高回答的準確性和深度 20。這有點像讓模型自己“做筆記”或“查找資料”。

  • 思維樹提示 (Tree-of-Thoughts, ToT): (將在第5節詳述) 允許模型探索多個推理分支,形成樹狀結構,并進行評估和回溯,適用于需要探索和規劃的復雜問題 2。

  • 檢索增強生成 (Retrieval-Augmented Generation, RAG): (將在第5節詳述) 結合外部知識庫進行檢索,將相關信息注入提示詞,以減少幻覺、提供最新知識 12。

  • ReAct (Reasoning and Acting): (將在第5節詳述) 使LLM能夠交錯地生成推理步驟和與外部工具(如搜索引擎、計算器)交互的動作,適用于需要與環境互動的任務 20。

這些技術代表了提示工程領域不斷發展的方向,它們通過更復雜的交互模式或結合外部資源,進一步拓展了LLM的應用邊界。選擇哪種技術取決于具體任務的復雜性、對準確性的要求、可用的資源(如是否有外部知識庫、是否能接受多次API調用)以及模型本身的能力。實踐中,這些技術也常常被組合使用,以達到最佳效果。

5. 探索高級提示策略

掌握了基本原則和核心技術后,我們可以進一步探索更高級的策略,以應對更復雜的挑戰,實現更精細的控制,并提升LLM應用的魯棒性和效率。

5.1. 提示詞的迭代優化:一個持續改進的過程

如前所述,提示工程本質上是一個迭代過程 2。很少能一次就寫出完美的提示詞,持續的測試、分析和改進是關鍵。

  • 為什么需要迭代?

    • LLM行為有時難以預測,需要通過實驗找到最有效的表達方式 2。

    • 任務需求可能很微妙,需要逐步調整提示詞來精確匹配 32。

    • 不同模型對同一提示詞的反應可能不同,需要針對性優化 3。

    • 發現并修復初始提示詞中的模糊性或遺漏 27。

  • 迭代方法:

    1. 制定初始提示: 基于對任務的理解和基本原則(第2節)構建第一個版本的提示詞 32。

    2. 測試與評估: 使用該提示詞獲取LLM的輸出,并對照預期目標和評估指標(第6節)進行評估 32。

    3. 分析反饋: 檢查輸出中的問題:是否相關?是否準確?格式對嗎?是否存在偏見?推理過程有無錯誤?32。

    4. 改進提示詞:

      根據分析結果調整提示詞。這可能包括:

      • 增加明確性/具體性 6。

      • 補充或調整上下文信息 27。

      • 添加或修改Few-Shot示例 42。

      • 調整指令措辭(如使用更強的動詞,或肯定式表達)6。

      • 明確或修改輸出格式/約束 6。

      • 嘗試不同的提示結構或元素順序 6。

      • 引入更高級的技術(如CoT、Self-Consistency)29。

    5. 重復測試: 使用修改后的提示詞再次測試,比較結果,看是否有改進 32。

    6. 記錄與版本控制: 記錄每次修改的內容和對應的測試結果,便于追蹤有效的變更和回滾 30。

  • 自我修正提示 (Self-Refine):

    這是一種更自動化的迭代方法。LLM被提示生成初始輸出后,再被提示對該輸出進行

    自我評估和反饋

    ,最后根據反饋

    自我修正

    ,這個過程可以重復進行

    17

    • 流程: Generate -> Feedback -> Refine -> (Repeat) 17。

    • 示例: 讓模型寫代碼 -> 讓模型評審代碼并給出改進建議 -> 讓模型根據建議修改代碼 105。

    • 效果: 在代碼優化、情感逆轉等任務上顯示出顯著效果,尤其對于GPT-4等強能力模型 17。但需要模型本身具備較強的指令遵循和反思能力 105。

本人操作得知: 迭代優化是我花費時間最多的環節。我會準備一個小的測試集(代表性的輸入樣例),反復調整提示詞,觀察輸出的變化。有時一個小小的詞語調整就能帶來巨大差異。記錄每次嘗試和結果非常重要,否則很容易迷失在各種變體中。Self-Refine是個有趣的方向,我嘗試過讓模型“批評”自己的草稿,有時確實能發現一些我自己沒注意到的問題。

5.2. 提示鏈與任務分解 (Prompt Chaining & Decomposition)

對于無法通過單一提示詞有效解決的復雜任務,可以將其分解為一系列更小、更易于管理的子任務,然后通過鏈接(chaining)多個提示詞來依次完成這些子任務 18。前一個提示詞的輸出作為后一個提示詞的輸入或上下文。

  • 為什么分解?

    • 降低單個提示詞的復雜度,讓LLM能更好地聚焦于每個子任務 18。

    • 提高整體任務的可靠性和準確性,因為每個子任務更容易控制和評估 107。

    • 增強流程的透明度和可調試性,更容易定位問題發生在哪個環節 110。

    • 適用于涉及多個步驟、多種轉換或需要中間處理的工作流 106。

  • 如何實現?

    1. 任務分解: 將復雜任務(如“撰寫一份基于某長篇報告的市場分析簡報”)分解為邏輯子步驟(例如:1. 總結報告要點;2. 識別目標市場;3. 分析競爭格局;4. 提出策略建議;5. 撰寫簡報)18。可以手動分解,有時也可以讓LLM輔助規劃 73。

    2. 設計子提示: 為每個子任務設計專門的提示詞 107。

    3. 規劃銜接: 確保每個子提示的輸出格式能夠被下一個子提示有效利用(規劃好“交接棒”)106。

    4. 順序執行: 按順序執行提示詞鏈,將上一步的輸出作為下一步的輸入 107。

  • 示例:

    • 文檔問答鏈:

      • Prompt 1 (提取): 從文檔 {{document}} 中提取與問題 {{question}} 相關的引文。輸出格式:<quotes>...</quotes>

      • Prompt 2 (回答): 基于問題 {{question}} 和引文 <quotes>...</quotes>,回答問題。 110

    • 數據處理鏈:

      • Prompt 1 (提取): 從數據庫轉儲 {{Database Dump}} 中提取Q1-Q4的收入和用戶參與度數據。

      • Prompt 2 (轉換): 將提取的數據轉換為CSV格式。

      • Prompt 3 (分析): 分析CSV數據中的趨勢。 106

    • 自我修正鏈:

      • Prompt 1 (草稿): 生成初步摘要。

      • Prompt 2 (批判): 評估摘要的缺點。

      • Prompt 3 (精煉): 根據批判意見改進摘要。 106

  • 相關技術:

    • Plan-and-Solve (PS) Prompting: 一種在單個提示內部實現分解和執行的技術,通過指令引導模型先規劃再解決 66。

    • Decomposed Prompting (Decomp): 明確將任務分解,并可能將子任務分配給不同的處理程序(可以是LLM提示,也可以是外部函數)109。

本人操作得知: 對于多步驟的工作流,比如從原始數據生成報告,提示鏈非常有效。它讓整個過程更可控。雖然增加了API調用次數,但往往能獲得比單個復雜提示詞好得多的結果。關鍵在于子任務劃分的邏輯性和接口(輸出/輸入格式)的匹配。

5.3. 結合外部知識與工具 (RAG & ReAct)

LLM的知識受限于其訓練數據,可能過時或不包含特定領域的細節 12。高級策略通常涉及將LLM與外部資源結合起來。

  • 檢索增強生成 (Retrieval-Augmented Generation, RAG):

    • 核心: 在生成回應前,先從外部知識庫(如文檔集合、數據庫)中檢索相關信息,并將這些信息作為上下文注入到給LLM的提示詞中 12。

    • 流程: (如4.5節所述) Indexing -> Retrieval -> Generation 14。

    • 目的: 減少幻覺,提供最新信息,增強事實性,實現領域知識問答 12。

    • 挑戰: 檢索質量是關鍵;如何有效融合檢索到的多個文檔片段;處理不相關或沖突的信息。

  • 推理與行動 (Reasoning and Acting, ReAct):

    • 核心: 使LLM能夠交錯地生成推理步驟(Thought)*和*行動(Action),并通過觀察(Observation)行動結果來調整后續推理和行動 97。

    • 流程: Thought -> Action -> Observation -> Thought ->... 循環 98。

    • 行動: 通常是調用外部工具,如搜索引擎API、計算器、數據庫查詢、代碼執行器等 98。

    • 目的: 解決需要與外部世界交互或利用外部工具能力的復雜任務,如實時信息查詢、復雜計算、操作軟件或物理設備(通過API)98。

    • 挑戰: 需要可靠的工具接口;LLM需要準確地生成工具調用指令并理解返回結果;錯誤處理機制。

本人操作得知: RAG對于構建基于特定文檔庫(如公司內部知識庫、產品手冊)的問答系統非常有效。ReAct則為構建更強大的AI智能體(Agent)打開了大門,讓LLM能夠像人一樣“思考-行動-觀察-再思考”。這兩種技術都大大擴展了LLM的應用范圍,但實現起來比純提示詞要復雜,通常需要結合代碼框架(如LangChain, LlamaIndex)。

5.4. 控制模型行為的高級技巧

除了上述策略,還有一些技巧可以更精細地控制模型行為:

  • 使用特定模型的控制標記: 某些模型可能支持特殊的控制標記或元指令,用于更直接地影響生成過程(例如,控制輸出風格、啟用/禁用某些功能)。需要查閱特定模型的文檔。

  • 溫度(Temperature)和Top-P/Top-K采樣: (已在5.8節提及) 通過調整解碼參數來控制輸出的隨機性和創造性 6。低Temperature/Top-P產生更確定性、保守的輸出;高則產生更多樣、創新的輸出。這是平衡創造力與一致性的重要手段。

  • 引導性提示 (Priming Prompts): 在主任務之前,使用一個或多個“熱身”提示來設定模型的思維框架或風格 5。例如,先讓模型回答幾個關于歷史的問題,再讓它以歷史學家的口吻寫作。

  • 使用“出口策略” (Exit Strategy): 在提示詞中明確指示模型,如果無法完成任務或缺乏足夠信息時應該如何回應,而不是強行生成或編造答案 6。例如,“如果你不知道答案,請回答‘我不知道’” 6。這有助于避免幻覺。

  • 對抗性提示與防御: 了解潛在的“提示注入”(Prompt Injection)攻擊(即用戶通過惡意輸入誘導模型忽略原始指令或泄露信息)19,并在設計提示詞和系統時考慮防御措施,例如使用清晰的分隔符、強化指令、對用戶輸入進行過濾或限制模型能力 19。

5.5. 處理與引導模型偏見 (Mitigating Bias)

(已在5.7節提及) 這是一個重要的倫理考量,也是高級提示工程的一部分。

  • 明確指令: 要求模型保持中立、客觀、避免刻板印象 4。

  • 平衡示例: 在Few-Shot場景中,確保示例來源多樣、觀點平衡 4。

  • 多視角提示: 要求模型從不同群體或角度分析問題 5。

  • 來源核查: 結合RAG或ReAct,要求模型引用來源,便于核查信息是否片面 43。

  • 后處理審查: 對模型輸出進行人工或自動審查,識別和過濾偏見內容。

本人操作得知: 處理偏見非常棘手。直接指令有時有效,但模型可能只是“表面上”遵循。我發現結合多種策略,特別是提供平衡的上下文和示例,并要求模型解釋其推理(使用CoT),有助于暴露和減少一些明顯的偏見。但這需要持續的警惕和評估。

掌握這些高級策略,需要更深入地理解LLM的工作機制,并進行大量的實驗。它們為解決復雜問題、提升應用質量和確保負責任地使用LLM提供了強大的工具。

6. 評估提示詞效果:方法與迭代改進

設計了提示詞,如何知道它是否有效?又如何根據評估結果進行改進?這是提示詞工程閉環中不可或缺的一環 31。有效的評估不僅能衡量當前提示詞的性能,更能指導后續的優化方向 32。

6.1. 為何需要評估提示詞?

僅僅依賴直覺或少數幾個例子的“感覺”來判斷提示詞的好壞是不可靠的 119。系統性的評估至關重要,原因在于:

  • 量化性能: 提供客觀、可量化的指標來衡量提示詞在特定任務上的表現 120。

  • 對比擇優: 能夠科學地比較不同提示詞版本或不同提示技術的優劣 23。

  • 識別問題: 幫助診斷提示詞失敗的原因(例如,是指令不清、上下文不足還是模型能力限制?)32。

  • 指導優化: 評估結果為迭代改進(見5.1節)提供了明確的方向 32。

  • 確保一致性與可靠性: 驗證提示詞在不同輸入下的表現是否穩定,尤其是在部署到生產環境前 101。

  • 滿足質量標準: 確保輸出滿足準確性、相關性、流暢性、安全性等預定標準 101。

6.2. 評估提示詞的關鍵指標

評估提示詞效果需要從多個維度進行考量。以下是一些常用的關鍵指標,具體選擇哪些指標取決于任務目標和應用場景 101:

  1. 任務完成度/準確性 (Task Completion / Accuracy):

    • 定義: 模型輸出是否成功完成了指定任務,或者其內容是否準確、符合事實。

    • 衡量方法:

      • 對于分類任務:精確率(Precision)、召回率(Recall)、F1分數、準確率(Accuracy)121。

      • 對于信息提取任務:與標準答案的精確匹配(Exact Match)、F1分數。

      • 對于問答/生成任務:與參考答案(Ground Truth)的對比(如果存在),或基于事實核查 121。

      • 對于需要特定格式的任務:格式遵循度(Format Adherence)100。

    • 重要性: 這是衡量提示詞基本有效性的核心指標 101。

  2. 相關性 (Relevance):

    • 定義: 模型輸出與用戶提示詞的意圖或主題的契合程度 101。

    • 衡量方法:

      • 人工評估(如打分或二元判斷“相關/不相關”)121。

      • 自動方法:計算輸出與輸入的嵌入向量相似度(如余弦相似度)101,或使用LLM作為評估者(LLM-as-a-judge)來判斷相關性 119。

    • 重要性: 確保輸出切題,不偏離用戶需求 101。

  3. 流暢性與連貫性 (Fluency & Coherence):

    • 定義: 輸出文本的語言質量,包括語法是否正確、語句是否通順、邏輯是否連貫 100。

    • 衡量方法:

      • 人工評估(主觀打分)。

      • 自動指標:可讀性分數(如Flesch-Kincaid)101,語法檢查工具,或使用LLM評估者 122。

      • 困惑度(Perplexity):衡量模型對生成序列的自信程度,較低通常表示更流暢(但并非絕對)121。

    • 重要性: 影響用戶體驗和信息的可理解性 101。

  4. 一致性/魯棒性 (Consistency / Robustness):

    • 定義: 對于相同或語義相似的輸入,提示詞是否能引導模型產生穩定、一致的輸出 101。以及提示詞對于微小變動(如措辭調整)的敏感度 118。

    • 衡量方法: 多次運行相同提示詞比較輸出相似性 101;使用微小變動的提示詞測試輸出變化;使用對抗性提示測試魯棒性 23。

    • 重要性: 確保模型行為的可預測性和可靠性 101。

  5. 效率 (Efficiency):

    • 定義: 生成響應所需的時間(延遲)和計算資源(成本)101。

    • 衡量方法: 測量API響應時間;監控計算資源使用(如token消耗量)101。

    • 重要性: 對于實時應用和成本控制非常關鍵 101。

  6. 安全性與偏見 (Safety & Bias):

    • 定義: 輸出內容是否包含有害信息(如仇恨言論、歧視)、不當內容或反映出不期望的偏見 48。

    • 衡量方法:

      • 使用預定義的有害內容分類器或敏感詞過濾器 124。

      • 人工審查特定數據集上的輸出,評估是否存在偏見 117。

      • 使用專門的偏見評估基準(如HH-RLHF數據集)125。

      • LLM評估者判斷是否存在偏見或不當內容 122。

    • 重要性: 確保AI應用的倫理和社會責任 119。

  7. RAG特定指標:

    對于使用RAG的應用,還需要評估檢索和生成環節的特定指標

    120

    • 上下文相關性 (Context Relevancy): 檢索到的上下文與問題的相關度。

    • 上下文召回率 (Context Recall): 檢索到的上下文是否包含了回答問題所需的所有信息。

    • 忠實度/事實一致性 (Faithfulness / Factual Consistency / Grounding): 生成的答案是否忠實于提供的上下文,沒有捏造信息。

本人操作得知: 沒有單一指標是萬能的。我會根據任務目標選擇一組核心指標。例如,對于客服機器人,我會關注相關性、準確性、流暢性和安全性;對于代碼生成,我會關注功能正確性(可能通過單元測試評估)和效率。

6.3. 評估方法:人工、自動與混合

評估提示詞效果的方法主要有三類:

  1. 人工評估 (Human Evaluation):

    • 方法:

      由人類評估員根據預定標準(如相關性、準確性、流暢性)對模型輸出進行打分或排序

      119

      。常用的方法包括:

      • 評分 (Scoring): 對單個輸出按等級(如1-5分)評分 121。

      • A/B測試/成對比較 (Pairwise Comparison): 評估員比較兩個不同提示詞(或模型)生成的輸出,選出更好的一個 121。

      • 用戶反饋: 直接收集最終用戶的反饋(如點贊/點踩按鈕)23。

    • 優點: 通常被認為是評估質量(特別是主觀質量如流暢性、創造性)的“黃金標準”,能捕捉細微差別和上下文理解 119。

    • 缺點: 成本高、耗時長、難以規模化、可能存在評估者主觀偏差 119。

  2. 自動評估 (Automatic Evaluation):

    • 方法:

      使用預定義的算法或模型來計算指標分數。

      • 基于參考的指標 (Reference-based):

        將模型輸出與一個或多個“標準答案”(reference)進行比較。常用指標包括:

        • BLEU: 主要用于機器翻譯,衡量n-gram重疊度(精確率導向)。

        • ROUGE: 主要用于文本摘要,衡量n-gram重疊度(召回率導向)101。

        • BERTScore: 使用BERT嵌入計算語義相似度,比基于詞匯重疊的指標更能捕捉意義 119。

        • METEOR, CIDEr: 其他用于翻譯或圖像描述的指標。

      • 無參考的指標 (Reference-free):

        不需要標準答案,直接評估輸出文本的某些固有屬性。

        • 困惑度 (Perplexity): 衡量模型對生成文本的流暢度或自信度 121。

        • 語法檢查/可讀性分數: 101。

        • 特定任務指標: 如代碼評估中的功能正確性(通過單元測試)122。

      • 基于模型的評估 (Model-based / LLM-as-a-judge): 使用另一個(通常是更強大的)LLM來評估目標LLM的輸出 119。評估LLM根據特定指令(例如,“評估以下回答的相關性,評分1-5”)和標準進行打分 120。

    • 優點: 速度快、成本低、可擴展、結果一致 119。LLM評估者還能提供解釋性反饋 122。

    • 缺點: 傳統自動指標(BLEU, ROUGE)與人類判斷的相關性有限,尤其對于生成任務 119。LLM評估者本身可能存在偏見、不一致性,且表現依賴于評估提示的設計 119。

  3. 混合評估 (Hybrid Evaluation):

    • 方法: 結合人工和自動評估的優點。例如,使用自動指標進行快速迭代和初步篩選,然后對表現最好或有爭議的提示詞進行人工評估 119。或者使用自動指標監控生產環境,當指標下降時觸發人工審查。

    • 優點: 在效率、成本和評估質量之間取得平衡。

    • 缺點: 需要設計合理的混合策略。

本人操作得知: 我通常采用混合方法。在開發階段,我會用自動指標(如BERTScore或簡單的關鍵詞匹配)和LLM評估者快速迭代提示詞。對于關鍵的改進或最終版本,我會進行小規模的人工評估(A/B測試或評分)來確認效果。LLM評估者是個很有潛力的方向,雖然它不完美,但確實能提供比傳統指標更接近人類判斷的評估,而且還能給出理由 120。

6.4. 基于評估的迭代改進流程

評估的最終目的是為了改進。一個實用的迭代改進流程大致如下 32:

  1. 定義目標與指標: 明確當前提示詞要實現的目標,并選擇合適的評估指標(見6.2節)101。

  2. 建立基線: 使用初始提示詞在一組代表性的測試數據(可以是“黃金數據集”127或生產數據的隨機樣本127)上運行,得到基線性能分數。

  3. 提出改進假設: 分析基線結果和失敗案例,根據提示工程原則(第2節)或高級策略(第5節),提出一個或多個改進提示詞的假設(例如,“增加更多上下文應該能提高相關性”)。

  4. 設計新提示詞: 根據假設修改提示詞,創建新版本。

  5. 對比測試 (A/B Test): 在相同的測試數據上運行新舊提示詞,收集評估指標分數 23。

  6. 分析結果: 比較新舊提示詞的性能。新提示詞是否在目標指標上顯著優于舊提示詞?是否引入了新的問題(例如,提高了準確性但降低了流暢性)?

  7. 決策與采納: 如果新提示詞效果更好,則采納為新基線。否則,回到第3步,提出新的改進假設或嘗試其他修改。

  8. 持續監控: 即便提示詞在測試中表現良好,部署后仍需持續監控其在真實世界數據上的表現,因為數據分布可能變化,或出現新的邊緣案例 100。

這個循環是提示詞工程不斷成熟和優化的核心動力。使用專門的評估框架或工具(見第7節)可以大大簡化這個流程 100。

7. 輔助提示詞工程的工具與平臺

隨著提示詞工程變得越來越重要和復雜,一系列工具和平臺應運而生,旨在幫助開發者和研究人員更高效地設計、測試、評估、管理和部署提示詞。這些工具可以顯著簡化迭代流程,促進團隊協作,并提高LLM應用的質量。

7.1. 為何需要工具?

手動進行提示詞工程,尤其是在涉及大量提示詞、多種模型或需要嚴格評估的場景下,可能會面臨諸多挑戰:

  • 迭代效率低: 反復手動修改、測試、記錄結果非常耗時 100。

  • 版本管理混亂: 追蹤哪個版本的提示詞對應哪個結果可能變得困難 30。

  • 評估標準化難: 確保使用一致的數據集和指標進行公平比較需要規范流程 100。

  • 協作不便: 團隊成員之間共享、評審和復用提示詞可能效率低下 32。

  • 缺乏系統性測試: 容易忽略邊緣案例或對抗性輸入的測試 32。

  • 監控困難: 難以持續追蹤生產環境中提示詞的性能表現 100。

專門的工具和平臺通過提供結構化的環境和自動化功能,可以有效緩解這些問題。

7.2. 主流工具/平臺概覽

以下是一些在提示詞工程領域比較有代表性的工具和平臺(注意:具體功能和側重點可能隨時間演變,請以官方文檔為準):

  1. LangChain & LlamaIndex:

    • 定位: 這兩者主要是用于構建LLM應用的開發框架,而非純粹的提示詞管理工具,但它們內部包含了強大的提示詞處理功能 36。

    • 核心功能 (與提示詞相關):

      • 提示模板 (Prompt Templates): 提供標準化的方式來創建、管理和復用包含變量的提示詞結構 25。LangChain支持多種模板格式,LlamaIndex也有自己的模板系統(如PromptTemplate, ChatPromptTemplate)129。

      • 提示詞組合與鏈式調用 (Chaining): LangChain的核心特性之一是能夠將多個LLM調用或其他操作鏈接起來,形成復雜的處理鏈(Chains),這自然支持了提示鏈(Prompt Chaining)的實現 25。LlamaIndex也支持在查詢引擎中自定義提示詞 129。

      • 示例選擇 (Few-Shot): LangChain提供了動態選擇Few-Shot示例的功能,可以根據輸入從數據集中選擇最相關的示例加入提示詞 128。

      • 集成: 兩者都與多種LLM、向量數據庫和工具集成,方便構建RAG、Agent等復雜應用,這些應用都高度依賴提示工程 130。

    • 我的看法: LangChain和LlamaIndex是構建LLM應用的強大基礎。雖然它們本身不是專門的“提示詞評估平臺”,但在開發過程中,它們的提示模板和鏈式結構極大地便利了提示詞的設計和組織。我經常在這些框架內進行提示詞的初步構建和調試 133。

  2. LangSmith:

    • 定位: 由LangChain團隊開發,專注于LLM應用開發生命周期的調試、測試、評估和監控平臺 102。

    • 核心功能:

      • 追蹤與調試 (Tracing & Logging): 記錄LLM調用、鏈和智能體的詳細執行過程(trace),便于理解流程和定位錯誤 102。

      • 提示管理 (Prompt Hub): 提供一個中心化的位置來組織、版本化和管理提示詞 128。

      • 測試與評估: 支持創建數據集,運行評估(包括自定義評估器和LLM-as-a-judge),比較不同提示詞或模型版本的性能 102。

      • Playground: 提供交互式環境,用于快速迭代和測試提示詞及模型參數 128。

      • 監控: 監控生產環境中的應用性能和行為 102。

    • 優點: 與LangChain深度集成,提供端到端的開發與運維支持,評估功能強大 102。

    • 缺點: 主要圍繞LangChain生態,與其他框架的集成可能受限;可能成本較高 102。

    • 我的看法: 如果你主要使用LangChain開發,LangSmith幾乎是必備的配套工具,它極大地簡化了調試和評估復雜鏈或智能體的過程。

  3. PromptLayer:

    • 定位: 專注于LLM提示詞管理、版本控制、測試和性能監控的平臺 102。

    • 核心功能:

      • 提示注冊與版本控制: 集中管理所有提示詞,跟蹤版本歷史,支持可視化編輯和部署 102。

      • 使用日志與分析: 記錄所有LLM請求和響應,提供延遲、成本、使用頻率等統計數據 102。

      • 評估與測試: 支持A/B測試,比較不同提示詞或模型的效果 102。

      • 團隊協作: 允許多用戶協作管理和優化提示詞,非技術人員也能參與 102。

    • 優點: 用戶界面友好,易于上手,特別適合團隊協作和提示詞的版本管理 102。

    • 缺點: 可能評估功能相對于LangSmith等更專注于評估的平臺來說稍弱一些。

    • 我的看法: PromptLayer對于需要系統化管理大量提示詞模板、并進行版本控制和基本性能跟蹤的團隊來說,是個不錯的選擇。

  4. Helicone:

    • 定位: LLM可觀測性平臺,提供監控、調試和優化LLM應用的功能,也包含強大的提示評估特性 100。

    • 核心功能:

      • 請求監控與日志: 記錄所有LLM交互,提供詳細的元數據。

      • 提示實驗 (Prompt Experiments): 允許針對生產數據測試提示詞變更,對比效果,防止回歸 100。

      • 評估器與評分 (Evaluators & Scores): 支持使用LLM-as-a-judge或自定義評估器對輸出質量進行量化評分 100。

      • 自動提示跟蹤: 自動跟蹤代碼中的提示詞變化并進行版本管理 100。

      • 會話可視化 (Sessions): 可視化多輪對話或復雜工作流,便于調試 100。

      • 用戶反饋: 集成用戶反饋機制 100。

    • 優點: 強大的可觀測性和調試能力,實驗功能適合在生產環境中安全地測試提示詞,支持多種LLM提供商 100。QA Wolf與Helicone的合作案例展示了使用生產數據隨機抽樣進行評估的有效性 127。

    • 缺點: 可能更側重于監控和實驗,而非純粹的提示詞創作。

    • 我的看法: Helicone在連接開發測試與生產監控方面做得很好,它的Prompt Experiments功能對于需要頻繁更新提示詞并確保線上效果的應用很有價值。

  5. Promptfoo:

    • 定位: 一個用于系統性評估LLM輸出質量的命令行工具和庫 100。

    • 核心功能:

      • 基于配置的評估: 通過配置文件定義測試用例(prompts, inputs)、模型提供商、以及斷言(assertions,即評估標準)。

      • 并行測試: 可以同時對多個提示詞、多個模型進行測試。

      • 多種斷言類型: 支持基于關鍵詞、正則表達式、JSON結構、語義相似度、甚至自定義函數或LLM-as-a-judge的斷言。

      • 結果展示: 提供命令行界面和Web UI來查看和比較測試結果。

    • 優點: 輕量級,易于集成到CI/CD流程,適合自動化測試和回歸測試,支持多種模型提供商 100。

    • 缺點: 主要面向開發者,需要編寫配置文件;可能不如集成平臺功能全面。

    • 我的看法: Promptfoo非常適合需要將提示詞評估納入自動化測試流程的場景。它的斷言機制很靈活,可以定義非常具體的評估標準。

  6. OpenAI Evals:

    • 定位: OpenAI官方提供的用于評估其模型(及其他LLM)性能的開源框架和基準注冊表 100。

    • 核心功能:

      • 評估模板: 提供創建和運行評估任務的框架。

      • 基準數據集: 包含一系列用于評估模型在不同任務上表現的標準數據集。

      • 自定義評估: 允許用戶創建自己的評估邏輯。

    • 優點: 來自OpenAI官方,與OpenAI模型集成緊密,提供了標準化的評估方法 100。

    • 缺點: 主要圍繞OpenAI生態,可能對其他模型的支持不如第三方工具廣泛 100。框架本身可能需要一定的學習成本。

    • 我的看法: 對于主要使用OpenAI模型并希望遵循官方評估范式的團隊,OpenAI Evals是一個重要的參考和工具。

  7. 其他平臺: 還有一些平臺如Traceloop 100, Langfuse 102, Braintrust 100 等,它們也提供類似的可觀測性、追蹤、評估和提示管理功能,各有側重。例如,Langfuse以其開源和詳細的追蹤分析著稱 102,Braintrust提供端到端的LLM應用開發和評估 100。選擇哪個平臺通常取決于具體需求、預算、技術棧以及對開源vs商業解決方案的偏好 100。

7.3. 如何選擇合適的工具?

選擇哪個工具或平臺取決于你的具體需求:

  • 如果你是個人開發者或研究者,剛開始探索:

    • 可以從LangChain/LlamaIndex入手,利用它們的提示模板功能。

    • 使用Promptfoo進行本地的、基于配置的評估。

    • 利用OpenAI Playground 102 或類似模型的在線交互界面進行快速手動迭代。

  • 如果你在團隊中開發LLM應用,需要協作和版本管理:

    • PromptLayer 102 或 LangSmith 128 的Prompt Hub功能可能很合適。

    • Helicone 100 也支持團隊協作和自動提示跟蹤。

  • 如果你需要對復雜的鏈或Agent進行調試和評估:

    • LangSmith 128 的追蹤和評估功能非常強大,特別是與LangChain結合時。

    • Helicone 100 的會話可視化和評估器也很有幫助。

  • 如果你需要將提示詞評估集成到CI/CD流程:

    • Promptfoo 100 是為此設計的。

    • 一些平臺如LangSmith 102 或 Traceloop 也支持CI/CD集成。

  • 如果你非常關注生產環境的監控和安全迭代:

    • Helicone 100 的Prompt Experiments功能值得考慮。

    • LangSmith 102 和 Traceloop 100 也提供生產監控。

本人操作得知: 我在不同的項目階段會使用不同的工具。早期探索和快速原型制作時,我可能就在Jupyter Notebook里結合LangChain/LlamaIndex進行。當提示詞變得復雜或需要團隊協作時,我會考慮引入LangSmith或PromptLayer。對于需要嚴格自動化測試的場景,Promptfoo是個好幫手。沒有一個工具是萬能的,關鍵是找到適合當前工作流和需求的組合。

使用這些工具可以極大地提升提示詞工程的效率和效果,使得開發者能夠更快地構建出高質量、可靠的LLM應用。

8. 總結與展望

經過對提示詞工程的深入探討,從核心定義、基本原則,到關鍵要素、各類技術,再到高級策略和評估方法,我們可以清晰地看到,提示詞工程遠不止是簡單的“提問技巧”。它是一門結合了語言理解、邏輯思維、創造力以及嚴謹實驗精神的新興學科 2。它是有效利用大型語言模型(LLM)強大能力的關鍵鑰匙 4。

核心要點回顧:

  1. 清晰具體是基石: 明確的指令、充足的上下文、具體的約束和角色設定是構建有效提示詞的基礎 5。模糊性是提示工程的大敵。

  2. 理解提示詞構成: 認識到提示詞通常包含指令、上下文、輸入數據和輸出指示器等要素,有助于系統性地設計和優化 12。

  3. 掌握核心技術: 零樣本、少樣本、思維鏈(CoT)、自洽性等技術各有優劣,適用于不同復雜度的任務 12。選擇合適的技術是成功的關鍵。

  4. 擁抱高級策略: 迭代優化是常態 31。任務分解與提示鏈能處理復雜工作流 106。結合外部知識(RAG)14和工具(ReAct)98能極大擴展LLM的應用邊界。探索性思維(ToT)72和自動化優化(APE/OPRO)136代表了更前沿的方向。同時,必須關注并主動緩解模型偏見 4。

  5. 評估驅動改進: 不能僅憑感覺。需要使用合適的指標(準確性、相關性、流暢性、安全性等)和方法(人工、自動、混合)來客觀評估提示詞效果,并指導迭代改進 101。

  6. 善用工具: 提示工程工具和平臺(如LangChain/LlamaIndex框架內的工具、LangSmith、PromptLayer、Helicone、Promptfoo等)能顯著提升效率、促進協作、加強管理 100。

實踐感悟:

我個人的經驗是,提示詞工程沒有“銀彈”。最好的方法往往是具體問題具體分析。需要理解你的目標、你的模型的能力和局限性,以及你所能投入的資源(時間、數據、計算力)。

  • 從小處著手: 從簡單的零樣本提示開始,逐步增加復雜性。

  • 實驗與記錄: 大膽嘗試不同的措辭、結構和技術,但一定要記錄下什么有效,什么無效。

  • 理解模型: 不同模型對提示詞的敏感度和遵循能力不同。針對特定模型進行優化通常是必要的 3。

  • 保持學習: 提示工程是一個快速發展的領域,新的技術和最佳實踐不斷涌現 20。保持對最新研究的關注很重要。

未來展望:

提示詞工程的重要性只會與日俱增 10。隨著LLM變得更加強大和普及,高效、可靠、安全地引導這些模型的能力將成為一項核心競爭力。我們可以預見以下趨勢:

  • 更自動化的提示工程: 類似APE、OPRO的技術會更加成熟,減少手動優化的負擔 11。可能會出現更智能的工具,能夠根據任務描述和反饋自動生成和優化提示詞。

  • 多模態提示工程: 隨著多模態模型(能處理文本、圖像、音頻等)的發展,提示工程將擴展到設計能夠有效融合和引導多種輸入模態的提示 9。

  • 個性化與自適應提示: 系統可能會根據用戶歷史、偏好或當前對話狀態動態調整提示,實現更個性化和自適應的交互 5。

  • 更深入的理論理解: 對LLM內部工作機制以及它們如何響應提示的理解將不斷加深,為提示工程提供更堅實的理論基礎 28。

  • 標準化與最佳實踐: 隨著領域成熟,可能會出現更標準化的提示設計模式和評估框架 119。

總之,提示詞工程是釋放LLM潛力的關鍵。它要求我們像與智能助手溝通一樣,既要清晰明確,又要善于引導和利用其能力。掌握這門“與AI對話的藝術”,無論對于開發者、研究者還是普通用戶,都將在未來的人工智能時代中受益匪淺。希望這份詳盡的指南能為你提供堅實的基礎和有益的啟示。繼續探索,不斷實踐,你會發現與LLM的交互可以變得如此高效和富有創造力。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/web/96113.shtml
繁體地址,請注明出處:http://hk.pswp.cn/web/96113.shtml
英文地址,請注明出處:http://en.pswp.cn/web/96113.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

HTTP 請求體格式詳解

1. 概覽與概念 Content-Type&#xff1a;HTTP 請求/響應頭&#xff0c;表示消息體的媒體類型&#xff08;MIME type&#xff09;。服務端用它決定如何解析請求體。常見場景&#xff1a; 純結構化數據&#xff08;JSON&#xff09; → application/json表單 文件上傳 → multip…

事務設置和消息分發

事務 RabbitMQ是基于AMQP協議實現的&#xff0c;該協議實現了事務機制&#xff0c;因此RabbitMQ也支持事務機制. SpringAMQP也提供了對事務相關的操作&#xff0c;RabbitMQ事務允許開發者確保消息的發送和接收是原子性的&#xff0c;要么 全部成功&#xff0c;要么全部失敗.| 前…

Python 中 try / except / else / finally 異常處理詳解

1. 基本結構 try:# 可能會拋出異常的代碼 except SomeException as e:# 捕獲并處理異常 else:# 如果 try 中代碼沒有異常&#xff0c;就執行這里 finally:# 無論是否發生異常&#xff0c;最后都會執行這里2. 各部分的作用 try 用途&#xff1a;包含可能發生異常的代碼段。如果代…

冰火島 Tech 傳:Apple Foundation Models 心法解密(下集)

引子 上集說到冰火島冰屋內,謝遜、張翠山、殷素素三人親見 “指令(Instructions)” 如何讓 AI 脫胎換骨,從木訥報地名的 “愣頭青”,變身為文采斐然的 “旅行作家”。 正當素素驚嘆這 AI 武學的奇妙時,謝遜卻突然神色一凜,指著手腕上用冰屑刻的 “4096” 字樣道:“這等…

Qt信號與槽機制全面解析

? 1. 核心概念信號與槽是Qt獨創的一種對象間通信機制&#xff0c;它使得一個對象的狀態變化或事件發生能夠自動通知其他對象作出響應&#xff0c;從而實現高度解耦的代碼設計。1.1 信號&#xff08;Signals&#xff09;定義&#xff1a;信號是由對象在特定事件發生時發出&…

2025年COR SCI2區,基于近似細胞分解的能源高效無人機路徑規劃問題用于地質災害監測,深度解析+性能實測

目錄1.摘要2.問題描述與數學模型3.能源網格混合元啟發式算法4.結果展示5.參考文獻6.代碼獲取7.算法輔導應用定制讀者交流1.摘要 本文提出了一種能源高效的無人機路徑規劃方法&#xff08;EURP&#xff09;用于監測分散的地質災害易發區域&#xff0c;通過建立無人機飛行模式的…

LangChain關于提示詞的幾種寫法

上文中 <---->(可點擊移步查閱),我們已經了解到LangChain如何編寫調用大模型的一個基本框架, 在編寫完這個基本框架后,就要與大模型進行交互了,這時候,就需要我們編寫提示詞了, 那么以下,就會介紹提示詞的幾種編寫方式 1 可攜帶變量的提示詞 1.1 PromptTempla…

CyberPoC 是一個現代化的網絡安全練習和競賽平臺,支持容器化部署的安全挑戰,為用戶提供實踐網絡安全技能的環境。

工具介紹 CyberPoC 是一個現代化的網絡安全練習和競賽平臺&#xff0c;支持容器化部署的安全挑戰&#xff0c;為用戶提供實踐網絡安全技能的環境。 &#x1f680; 快速開始 使用 Docker Compose (推薦) 克隆項目 git clone https://github.com/dushixiang/cyberpoc.gitcd cy…

【單片機day03】

UART串口通用異步收發器&#xff0c;2個串口(1個串口被用于ISP下載程序&#xff0c;1個串口被用于和主機之間的通信)全雙工&#xff08;兩根線TX、RX&#xff09;、串行、異步通信方式&#xff1a;單工&#xff1a;發送方和接收方是固定的&#xff0c;數據只能從發送方 發給 …

react16到react19更新及底層實現是什么以及區別

好問題 &#x1f44d;。React 16 → 19 的更新跨度其實涵蓋了 React 的幾個“時代級”的演進&#xff1a;從 Fiber 架構 的重寫、到 并發特性 的引入&#xff0c;再到 React Server Components 和 現代語法支持。我幫你梳理下主要更新點和底層實現的區別&#xff0c;方便你系統…

【分享】基于百度腦圖,并使用Vue二次開發的用例腦圖編輯器組件

偶然間發現了這個項目&#xff0c;分享出來。 【分享】基于百度腦圖&#xff0c;并使用Vue二次開發的用例腦圖編輯器組件1 項目地址2 項目簡介3 項目部署3.1 安裝node和npm3.2 項目下載3.3 修改npm鏡像源3.4 部署4 項目中使用1 項目地址 基于百度腦圖&#xff0c;并使用Vue二次…

Kotlin中抽象類和開放類

抽象類 (Abstract Class) 定義和特點 抽象類使用 abstract 關鍵字聲明&#xff0c;是一種不能被直接實例化的特殊類&#xff0c;主要用于被其他類繼承。 abstract class Base {open fun f() {} }abstract class Derived : Base() {override abstract fun f() // 抽象成員在類中…

TensorFlow深度學習實戰(37)——深度學習的數學原理

TensorFlow深度學習實戰&#xff08;37&#xff09;——深度學習的數學原理0. 前言1. 反向傳播歷史2. 微積分相關概念2.1 向量2.2 導數和梯度2.3 梯度下降2.4 鏈式法則2.5 常用求導公式2.6 矩陣運算3. 激活函數4. 反向傳播4.1 前向計算4.2 反向傳播5. 交叉熵及其導數6. 批量梯度…

1.1 汽車運行滾動阻力

汽車運行阻力由4部分構成&#xff1a;滾動阻力、空氣阻力、坡度阻力、加速阻力。 1).汽車在水平道路上等速行駛時&#xff0c;必須克服來自地面的滾動阻力和來自空氣的空氣阻力。 2). 當汽車在坡道上上坡行駛時&#xff0c;還必須克服重力沿坡道的分力&#xff0c;稱為坡度阻…

e203000

1&#xff09;①BIU作為核心通信樞紐&#xff0c;主要承擔兩大功能&#xff1a;一是連接處理器核內的關鍵執行單元&#xff08;包括IFU、LSU和EAI協處理器&#xff09;&#xff0c;統一管理指令和數據的內部傳輸路徑&#xff1b;二是作為"核內計算"與"核外資源&…

Infortrend普安科技IEC私有云平臺VM解決方案

Infortrend企業云&#xff08;IEC&#xff09;內置Hypervisor運行VM。功能完整、無需額外付費。在本文中&#xff0c;我們將為您詳細介紹IEC是如何支持 VM的。市場現狀與挑戰市場現狀 虛擬化市場面臨轉型&#xff0c;主流廠商&#xff08;如 VMware&#xff09;改用訂閱制…

【代碼隨想錄算法訓練營——Day6(Day5周日休息)】哈希表——242.有效的字母異位詞、349.兩個數組的交集、202.快樂數、1.兩數之和

LeetCode題目鏈接 https://leetcode.cn/problems/valid-anagram/ https://leetcode.cn/problems/intersection-of-two-arrays/ https://leetcode.cn/problems/happy-number/ https://leetcode.cn/problems/two-sum/ 題解 242.有效的字母異位詞 這道題要想到用哈希表來做。同時注…

安科瑞基站智慧運維云平臺:安全管控與節能降耗雙效賦能

功能&#xff1a;基站智慧用電云平臺通過對5G宏站和室分站點加裝交/直流智能監控設備、無線采集設備以及系統管理平臺&#xff0c;完成夜間無業務時段的下電操作&#xff0c;減少電能消耗&#xff0c;降低運營成本支出&#xff0c;以及提升通信設備供電線路狀態的實時監測保護功…

處理省市區excel數據加工成SQL

原始數據相關內容鏈接 處理excel數據加工成SQL的腳本 #!/usr/bin/env python3 # -*- coding: utf-8 -*- """ Excel行政區域數據轉SQL腳本 - 支持特殊行政單位處理&#xff08;如省直轄縣級行政單位&#xff09; - 支持批量處理 """import pand…

雙碳目標下的24小時分時綜合能源系統低碳優化調度:基于 Matlab/YALMIP/CPLEX的方法與仿真

在“雙碳”戰略目標的推動下&#xff0c;綜合能源系統&#xff08;Integrated Energy System, IES&#xff09;已成為實現能源結構優化與碳排放控制的重要途徑。本文以光伏、風電、燃氣—電熱聯產&#xff08;CHP&#xff09;、燃氣鍋爐、電鍋爐、電儲能以及碳捕集&#xff08;…