隨著 ChatGPT、GPT-4 等大型語言模型（LLM）的出現(xiàn)，提示工程（Prompt Engineering）變得越來越重要。很多人將 prompt 視為 LLM 的咒語，其好壞直接影響模型輸出的結(jié)果。
如何寫好 prompt，已經(jīng)成為 LLM 研究的一項(xiàng)必修課。
引領(lǐng)大模型發(fā)展潮流的 AI target=_blank class=infotextkey>OpenAI，近日官方發(fā)布了一份提示工程指南，該指南分享了如何借助一些策略讓 GPT-4 等 LLM 輸出更好的結(jié)果。OpenAI 表示這些方法有時(shí)可以組合使用以獲得更好的效果。
指南地址：https://platform.openai.com/docs/guides/prompt-engineering
六個(gè)策略，獲得更好的結(jié)果
策略一：寫清楚指令
首先用戶要寫清楚指令，因?yàn)槟Ｐ蜔o法讀懂你的大腦在想什么。舉例來說，如果你希望模型的輸出不要太簡單，那就把指令寫成「要求專家級別的寫作」；又比如你不喜歡現(xiàn)在的文本風(fēng)格，就換個(gè)指令明確一下。模型猜測你想要什么的次數(shù)越少，你得到滿意結(jié)果的可能性就越大。
只要你做到下面幾點(diǎn)，問題不會太大：
首先是提示中盡量包含更詳細(xì)的查詢信息，從而獲得更相關(guān)的答案，就像下面所展示的，同樣是總結(jié)會議記錄，采用這樣的提示「用一個(gè)段落總結(jié)會議記錄。然后寫下演講者的 Markdown 列表以及每個(gè)要點(diǎn)。最后，列出發(fā)言人建議的后續(xù)步驟或行動項(xiàng)目（如果有）?！菇Y(jié)果會比較好。
其次是用戶可以提供示例。例如，當(dāng)你想讓模型模仿一種難以明確描述的回答風(fēng)格時(shí)，用戶可以提供少數(shù)示例。
第三點(diǎn)是指定模型完成任務(wù)時(shí)所需的步驟。對于有些任務(wù)，最好指定步驟如步驟 1、2，顯式地寫出這些步驟可以使模型更容易地遵循用戶意愿。
第四點(diǎn)是指定模型輸出的長度。用戶可以要求模型生成給定目標(biāo)長度的輸出，目標(biāo)輸出長度可以根據(jù)單詞、句子、段落等來指定。
第五點(diǎn)是使用分隔符來明確劃分提示的不同部分。"""、XML 標(biāo)簽、小節(jié)標(biāo)題等分隔符可以幫助劃分要區(qū)別對待的文本部分。
第六點(diǎn)是讓模型扮演不同的角色，以控制其生成的內(nèi)容。
策略 2 提供參考文本
語言模型會時(shí)不時(shí)的產(chǎn)生幻覺，自己發(fā)明答案，為這些模型提供參考文本可以幫助減少錯(cuò)誤輸出。需要做到兩點(diǎn)：
首先是指示模型使用參考文本回答問題。如果我們可以為模型提供與當(dāng)前查詢相關(guān)的可信信息，那么我們可以指示模型使用提供的信息來組成其答案。比如：使用由三重引號引起來的文本來回答問題。如果在文章中找不到答案，就寫「我找不到答案」。
其次是指示模型從參考文本中引用答案。
策略 3：將復(fù)雜的任務(wù)拆分為更簡單的子任務(wù)
正如軟件工程中將復(fù)雜系統(tǒng)分解為一組模塊化組件一樣，提交給語言模型的任務(wù)也是如此。復(fù)雜的任務(wù)往往比簡單的任務(wù)具有更高的錯(cuò)誤率，此外，復(fù)雜的任務(wù)通?？梢员恢匦露x為更簡單任務(wù)的工作流程。包括三點(diǎn)：
- 使用意圖分類來識別與用戶查詢最相關(guān)的指令；
- 對于需要很長對話的對話應(yīng)用，總結(jié)或過濾以前的對話；
- 分段總結(jié)長文檔并遞歸的構(gòu)建完整摘要。
由于模型具有固定的上下文長度，因此要總結(jié)一個(gè)很長的文檔（例如一本書），我們可以使用一系列查詢來總結(jié)文檔的每個(gè)部分。章節(jié)摘要可以連接起來并進(jìn)行總結(jié)，生成摘要的摘要。這個(gè)過程可以遞歸地進(jìn)行，直到總結(jié)整個(gè)文檔。如果有必要使用前面部分的信息來理解后面的部分，那么另一個(gè)有用的技巧是在文本（如書）中任何給定點(diǎn)之前包含文本的運(yùn)行摘要，同時(shí)在該點(diǎn)總結(jié)內(nèi)容。OpenAI 在之前的研究中已經(jīng)使用 GPT-3 的變體研究了這種過程的有效性。
策略 4：給模型時(shí)間去思考
對于人類來說，要求給出 17 X 28 的結(jié)果，你不會立馬給出答案，但隨著時(shí)間的推移仍然可以算出來。同樣，如果模型立即回答而不是花時(shí)間找出答案，可能會犯更多的推理錯(cuò)誤。在給出答案之前采用思維鏈可以幫助模型更可靠地推理出正確答案。需要做到三點(diǎn)：
首先是指示模型在急于得出結(jié)論之前找出自己的解決方案。
其次是使用 inner monologue 或一系列查詢來隱藏模型的推理過程。前面的策略表明，模型有時(shí)在回答特定問題之前詳細(xì)推理問題很重要。對于某些應(yīng)用程序，模型用于得出最終答案的推理過程不適合與用戶共享。例如，在輔導(dǎo)應(yīng)用程序中，我們可能希望鼓勵(lì)學(xué)生得出自己的答案，但模型關(guān)于學(xué)生解決方案的推理過程可能會向?qū)W生揭示答案。
inner monologue 是一種可以用來緩解這種情況的策略。inner monologue 的思路是指示模型將原本對用戶隱藏的部分輸出放入結(jié)構(gòu)化格式中，以便于解析它們。然后，在向用戶呈現(xiàn)輸出之前，將解析輸出并且僅使部分輸出可見。
最后是詢問模型在之前的過程中是否遺漏了任何內(nèi)容。
策略 5：使用外部工具
通過向模型提供其他工具的輸出來彌補(bǔ)模型的弱點(diǎn)。例如，文本檢索系統(tǒng)（有時(shí)稱為 RAG 或檢索增強(qiáng)生成）可以告訴模型相關(guān)文檔。OpenAI 的 Code Interpreter 可以幫助模型進(jìn)行數(shù)學(xué)運(yùn)算并運(yùn)行代碼。如果一項(xiàng)任務(wù)可以通過工具而不是語言模型更可靠或更有效地完成，或許可以考慮利用兩者。
- 首先使用基于嵌入的搜索實(shí)現(xiàn)高效的知識檢索；
- 調(diào)用外部 API；
- 賦予模型訪問特定功能的權(quán)限。
策略 6：系統(tǒng)的測試變化
在某些情況下，對提示的修改會實(shí)現(xiàn)更好的性能，但會導(dǎo)致在一組更具代表性的示例上整體性能變差。因此，為了確保更改對最終性能產(chǎn)生積極影響，可能有必要定義一個(gè)全面的測試套件（也稱為評估），例如使用系統(tǒng)消息。
更多內(nèi)容，請參考原博客。
