本指南分享了從 GPT-4 等大型語言模型（有時稱為 GPT 模型）獲得更好結(jié)果的策略和策略。有時可以組合使用此處描述的方法以獲得更好的效果。我們鼓勵嘗試找到最適合您的方法。

此處演示的一些示例目前僅適用于我們最強大的模型gpt-4。一般來說，如果您發(fā)現(xiàn)某個模型在某項任務上失敗，并且有一個功能更強大的模型可用，那么通常值得使用功能更強大的模型再次嘗試。

您還可以探索示例提示，展示我們的模型的功能：

這些模型無法讀懂你的想法。如果輸出太長，請要求簡短答復。如果輸出太簡單，請要求專家級別的寫作。如果您不喜歡這種格式，請演示您希望看到的格式。模型猜測你想要什么的次數(shù)越少，你得到它的可能性就越大。

策略：

• 在您的查詢中包含詳細信息以獲得更相關的答案
• 要求模特采用角色
• 使用分隔符清楚地指示輸入的不同部分
• 指定完成任務所需的步驟
• 提供例子
• 指定所需的輸出長度

語言模型可以自信地發(fā)明假答案，特別是當被問及深奧的主題或引文和 URL 時。就像一張筆記可以幫助學生在考試中取得更好的成績一樣，為這些模型提供參考文本可以幫助減少作答次數(shù)。

策略：

• 指示模型使用參考文本回答
• 指示模型通過引用參考文本來回答

正如軟件工程中將復雜系統(tǒng)分解為一組模塊化組件是良好實踐一樣，提交給語言模型的任務也是如此。復雜的任務往往比簡單的任務具有更高的錯誤率。此外，復雜的任務通?？梢员恢匦露x為更簡單任務的工作流程，其中早期任務的輸出用于構(gòu)造后續(xù)任務的輸入。

策略：

• 使用意圖分類來識別與用戶查詢最相關的指令
• 對于需要很長對話的對話應用，總結(jié)或過濾以前的對話
• 分段總結(jié)長文檔并遞歸構(gòu)建完整摘要

如果要求將 17 乘以 28，您可能不會立即知道，但隨著時間的推移仍然可以算出來。同樣，模型在嘗試立即回答而不是花時間找出答案時會犯更多推理錯誤。尋求“思想鏈”在答案可以幫助模型更可靠地推理出正確答案之前。

策略：

• 指示模型在急于得出結(jié)論之前找出自己的解決方案
• 使用內(nèi)心獨白或一系列查詢來隱藏模型的推理過程
• 詢問模型在之前的過程中是否遺漏了任何內(nèi)容

通過向模型提供其他工具的輸出來彌補模型的弱點。例如，文本檢索系統(tǒng)（有時稱為 RAG 或檢索增強生成）可以告訴模型相關文檔。像 OpenAI 的代碼解釋器這樣的代碼執(zhí)行引擎可以幫助模型進行數(shù)學計算并運行代碼。如果一項任務可以通過工具而不是語言模型更可靠或更有效地完成，那么可以卸載它以充分利用兩者。

策略：

• 使用基于嵌入的搜索實現(xiàn)高效的知識檢索
• 使用代碼執(zhí)行來執(zhí)行更準確的計算或調(diào)用外部API
• 授予模型訪問特定功能的權限

如果您可以衡量性能，那么提高性能就會更容易。在某些情況下，對提示的修改將在一些孤立的示例上實現(xiàn)更好的性能，但會導致在一組更具代表性的示例上整體性能變差。因此，為了確保更改對性能有凈積極作用，可能有必要定義全面的測試套件（也稱為“評估”）。

戰(zhàn)術：

• 參考黃金標準答案評估模型輸出

上面列出的每個策略都可以用特定的策略來實例化。這些策略旨在提供嘗試的想法。它們絕不是完全全面的，您應該隨意嘗試此處未列出的創(chuàng)意。

為了獲得高度相關的響應，請確保請求提供任何重要的詳細信息或上下文。否則，你將讓模型來猜測你的意思。

系統(tǒng)消息可用于指定模型在其回復中使用的角色。

三引號、XML 標簽、節(jié)標題等分隔符可以幫助劃分要區(qū)別對待的文本節(jié)。

對于諸如此類的簡單任務，使用分隔符可能不會對輸出質(zhì)量產(chǎn)生影響。然而，任務越復雜，消除任務細節(jié)的歧義就越重要。不要讓模型準確地理解你對他們的要求。

有些任務最好指定為一系列步驟。明確地寫出這些步驟可以使模型更容易遵循它們。

提供適用于所有示例的一般說明通常比通過示例演示任務的所有排列更有效，但在某些情況下提供示例可能更容易。例如，如果您打算讓模型復制響應用戶查詢的特定風格，而這種風格很難明確描述。這被稱為“幾次射擊”。提示。

您可以要求模型生成給定目標長度的輸出。目標輸出長度可以根據(jù)單詞、句子、段落、要點等的計數(shù)來指定。但請注意，指示模型生成特定數(shù)量的單詞并不能高精度工作。該模型可以更可靠地生成具有特定數(shù)量的段落或要點的輸出。

如果我們可以為模型提供與當前查詢相關的可信信息，那么我們可以指示模型使用提供的信息來組成其答案。

鑒于所有模型的上下文窗口都有限，我們需要某種方法來動態(tài)查找與所提出的問題相關的信息。?嵌入可用于實現(xiàn)高效的知識檢索。請參閱策略“使用基于嵌入的搜索實現(xiàn)高效的知識檢索”，了解有關如何實現(xiàn)此策略的更多詳細信息。

如果輸入已補充相關知識，則可以直接要求模型通過引用所提供文檔中的段落來為其答案添加引用。請注意，輸出中的引用可以通過所提供文檔中的字符串匹配以編程方式進行驗證。

對于需要大量獨立指令集來處理不同情況的任務，首先對查詢類型進行分類并使用該分類來確定需要哪些指令可能會很有幫助。這可以通過定義與處理給定類別中的任務相關的固定類別和硬編碼指令來實現(xiàn)。該過程還可以遞歸地應用以將任務分解為一系列階段。這種方法的優(yōu)點是每個查詢僅包含執(zhí)行任務下一階段所需的指令，與使用單個查詢執(zhí)行整個任務相比，這可以降低錯誤率。這還可以降低成本，因為較大的提示運行成本更高（查看定價信息）。

例如，假設對于客戶服務應用程序，查詢可以有效地分類如下：

根據(jù)客戶查詢的分類，可以向模型提供一組更具體的指令，以供其處理后續(xù)步驟。例如，假設客戶需要“故障排除”方面的幫助。

請注意，模型已被指示發(fā)出特殊字符串來指示對話狀態(tài)何時發(fā)生變化。這使我們能夠?qū)⑽覀兊南到y(tǒng)變成一個狀態(tài)機，其中狀態(tài)決定注入哪些指令。通過跟蹤狀態(tài)、哪些指令與該狀態(tài)相關，以及可選地允許從該狀態(tài)進行哪些狀態(tài)轉(zhuǎn)換，我們可以為用戶體驗設置護欄，而使用不太結(jié)構(gòu)化的方法很難實現(xiàn)這一點。

由于模型具有固定的上下文長度，因此用戶和助手之間的對話（其中整個對話都包含在上下文窗口中）無法無限期地繼續(xù)。

解決此問題有多種解決方法，其中之一是總結(jié)對話中的先前回合。一旦輸入的大小達到預定的閾值長度，這可能會觸發(fā)總結(jié)部分對話的查詢，并且先前對話的摘要可以作為系統(tǒng)消息的一部分包括在內(nèi)?；蛘?，可以在整個對話過程中在后臺異步總結(jié)之前的對話。

另一種解決方案是動態(tài)選擇與當前查詢最相關的對話的先前部分。請參閱策略“使用基于嵌入的搜索實現(xiàn)高效的知識檢索”。

由于模型具有固定的上下文長度，因此它們不能用于總結(jié)長于上下文長度減去單個查詢中生成的摘要長度的文本。

要總結(jié)一個很長的文檔（例如一本書），我們可以使用一系列查詢來總結(jié)文檔的每個部分。章節(jié)摘要可以連接和總結(jié)，生成摘要的摘要。這個過程可以遞歸地進行，直到總結(jié)整個文檔。如果有必要使用前面部分的信息來理解后面的部分，那么另一個有用的技巧是在書中任何給定點之前包含文本的運行摘要，同時總結(jié)該點的內(nèi)容。 OpenAI 在之前的研究中已經(jīng)使用 GPT-3 的變體研究了這種書籍總結(jié)過程的有效性。

有時，當我們明確指示模型在得出結(jié)論之前從第一原理進行推理時，我們會得到更好的結(jié)果。假設我們想要一個模型來評估學生對數(shù)學問題的解決方案。解決這個問題最明顯的方法是簡單地詢問模型學生的解決方案是否正確。

但這位同學的解法其實并不正確！我們可以通過提示模型首先生成自己的解決方案來讓模型成功注意到這一點。

前面的策略表明，模型有時在回答特定問題之前詳細推理問題很重要。對于某些應用程序，模型用于得出最終答案的推理過程不適合與用戶共享。例如，在輔導應用程序中，我們可能希望鼓勵學生得出自己的答案，但模型關于學生解決方案的推理過程可能會向?qū)W生揭示答案。

內(nèi)心獨白是一種可以用來緩解這種情況的策略。內(nèi)心獨白的想法是指示模型將原本對用戶隱藏的部分輸出放入結(jié)構(gòu)化格式中，以便于解析它們。然后，在向用戶呈現(xiàn)輸出之前，將解析輸出并且僅使部分輸出可見。

或者，這可以通過一系列查詢來實現(xiàn)，其中除了最后一個查詢之外，所有查詢的輸出都對最終用戶隱藏。

首先，我們可以要求模型自己解決問題。由于這個初始查詢不需要學生的解決方案，因此可以省略。這提供了額外的優(yōu)勢，即模型的解決方案不會因?qū)W生嘗試的解決方案而產(chǎn)生偏差。

接下來，我們可以讓模型使用所有可用信息來評估學生解決方案的正確性。

最后，我們可以讓模型使用自己的分析來以樂于助人的導師的角色構(gòu)建回復。

假設我們使用一個模型來列出與特定問題相關的來源的摘錄。列出每個摘錄后，模型需要確定是否應該開始編寫另一個摘錄或者是否應該停止。如果源文檔很大，模型通常會過早停止并且無法列出所有相關摘錄。在這種情況下，通過使用后續(xù)查詢提示模型查找之前傳遞中錯過的任何摘錄，通常可以獲得更好的性能。

如果作為輸入的一部分提供，模型可以利用外部信息源。這可以幫助模型生成更明智和最新的響應。例如，如果用戶詢問有關特定電影的問題，則將有關電影的高質(zhì)量信息（例如演員、導演等）添加到模型的輸入中可能會很有用。嵌入可用于實現(xiàn)高效的知識檢索，從而可以在運行時動態(tài)地將相關信息添加到模型輸入中。

文本嵌入是一個可以衡量文本字符串之間相關性的向量。相似或相關的字符串比不相關的字符串更接近。這一事實以及快速向量搜索算法的存在意味著嵌入可以用于實現(xiàn)高效的知識檢索。特別地，文本語料庫可以被分割成塊，并且每個塊可以被嵌入和存儲。然后可以嵌入給定的查詢，并且可以執(zhí)行矢量搜索以從語料庫中查找與查詢最相關的嵌入文本塊（即在嵌入空間中最接近的文本塊）。

示例實現(xiàn)可以在?OpenAI Cookbook?中找到。請參閱策略“指示模型使用檢索到的知識來回答查詢”，了解如何使用知識檢索來最小化模型出現(xiàn)問題的可能性的示例。編造不正確的事實。

不能依賴語言模型自行準確地執(zhí)行算術或長時間計算。在需要的情況下，可以指示模型編寫和運行代碼，而不是進行自己的計算。特別是，可以指示模型將要運行的代碼放入指定的格式，例如三重反引號。產(chǎn)生輸出后，可以提取代碼并運行。最后，如有必要，可以將代碼執(zhí)行引擎（即 Python 解釋器）的輸出作為下一個查詢的模型的輸入。

代碼執(zhí)行的另一個很好的用例是調(diào)用外部 API。如果模型接受了如何正確使用 API 的指導，它就可以編寫使用該 API 的代碼。通過向模型提供展示如何使用 API 的文檔和/或代碼示例，可以指導模型如何使用 API。

警告：執(zhí)行模型生成的代碼本質(zhì)上并不安全，任何試圖執(zhí)行此操作的應用程序都應采取預防措施。特別是，需要沙盒代碼執(zhí)行環(huán)境來限制不受信任的代碼可能造成的危害。

聊天完成 API 允許在請求中傳遞功能描述列表。這使得模型能夠根據(jù)提供的模式生成函數(shù)參數(shù)。生成的函數(shù)參數(shù)由 API 以 JSON 格式返回，可用于執(zhí)行函數(shù)調(diào)用。然后，可以將函數(shù)調(diào)用提供的輸出反饋到以下請求中的模型中以關閉循環(huán)。這是使用OpenAI模型調(diào)用外部函數(shù)的推薦方式。要了解更多信息，請參閱我們的介紹性文本生成指南中的函數(shù)調(diào)用部分以及更多函數(shù)調(diào)用示例?在 OpenAI Cookbook 中。

有時很難判斷更改（例如新指令或新設計）是否使您的系統(tǒng)變得更好或更差?？磶讉€例子可能會暗示哪個更好，但由于樣本量較小，很難區(qū)分真正的改進或隨機運氣。也許這種變化有助于某些輸入的性能，但會損害其他輸入的性能。

評估過程(或“evals”)對于優(yōu)化系統(tǒng)設計是有用的。好的評估是：

• 代表現(xiàn)實世界的使用情況（或至少是多樣化的）
• 包含許多測試用例以獲得更大的統(tǒng)計能力（有關指南，請參閱下表）
• 易于自動化或重復

輸出的評估可以由計算機、人類或兩者混合來完成。計算機可以使用客觀標準（例如，具有單一正確答案的問題）以及一些主觀或模糊標準自動進行評估，其中模型輸出由其他模型查詢進行評估。?OpenAI Evals是一個開源軟件框架，提供用于創(chuàng)建自動化評估的工具。

當存在一系列可能的輸出被認為質(zhì)量同樣高時（例如，對于答案很長的問題），基于模型的評估可能會很有用。通過基于模型的評估可以實際評估的內(nèi)容與需要人類評估的內(nèi)容之間的界限是模糊的，并且隨著模型變得更加強大而不斷變化。我們鼓勵進行實驗，以確定基于模型的評估對您的用例的效果如何。

假設已知問題的正確答案應參考一組特定的已知事實。然后我們可以使用模型查詢來計算答案中包含多少必需的事實。

例如，使用以下系統(tǒng)消息：

這是一個滿足兩點的示例輸入：

這是一個僅滿足一個點的示例輸入：