大語言模型的提示工程-Part 1

此篇整理自OpenAI的技術文件

提示工程(Prompt Engineering)的目的是為了從LLM(Large language models)得到較佳的回答,而不是亂問要LLM去通靈。

重點在於問對問題

針對對LLM的提問,此篇文件提供了好幾種重大組合因素能夠影響LLM回答的結果。而我們需要組合這些不同的因素,並且去進行嘗試與試驗。而OpenAI也針對提示工程提供了一些範例,並針對這些範例進行分門別類。

以下介紹OpenAI介紹的六種策略:

策略一: 寫出清晰的指示

如同剛剛說的,LLM不會通靈、不會讀心術。你必須下達清楚的指示,告訴它你想要甚麼樣的結果,甚至給它"範例"。你可以要求LLM在回答是某個專家給出專業的答案。如果LLM猜測的你意圖的次數越少,它給出的答案越接近你想要的。我們可以實行的戰術有

戰術一: 在問題中給出詳細的資訊

如同在我們與他人溝通,特別是第一次見面的人。如果你不給這個陌生人一個問題的重要且詳細的資訊或整體內容脈絡,這個陌生人是不可能回答我們的問題的。而LLM就是這個摸生人,而且每次在一個新的對談會話(Session)都是陌生人。不然你就是要求LLM進行通靈。以下是一些好提問跟爛提問範例:

爛提問一:
我如何使用Excel?

好提問一:
如何在 Excel 中新增一行台幣金額?我想對整題分頁的行自動執行此操作,所有加總都在右側名為“總計”的列中完成。

爛提問二:
寫程式來計算斐波那契數列。

好提問二:
編寫一個 Python 函數來有效率地計算斐波那契數列。註釋每一行代碼以解釋每部分的作用以及為什麼這樣編寫。

戰術二:讓LLM進行角色扮演

讓語言模型暫時變身成某領域的專家。

例如對模型進行系統的宣告:
當我發出問題時,你(LLM)將是一個雲端運算架構師會並且回覆問題時會包含一個與雲端運算相關的案例。接著後續文字就可以接續後續的問題。

戰術三: 使用分隔符號清楚指示輸入的不同部分

三引號( triple quotation marks)、XML 標籤、章節標題等分隔符號可以幫助分割要區別對待的文字段落。例如:

三引號:
用五言絕句總結由三引號分隔的文字。

“””在此寫入文字”””

XML標籤:
跟LLM說: 以下的兩篇關於相同主題的文章(以 XML 標籤分隔)。首先總結每篇文章的論點。然後指出哪一個提出了更好的論點並解釋原因。

<文章> 在這插入第一份文章 </文章>

<文章>在這插入第二份文章 </文章>

章節標題:
以下是論文摘要和建議的標題。論文標題應該讓讀者清楚了解論文的主題,但也應該引人注目。如果標題不符合這些標準,請提出 5 個替代方案。

摘要: XXXXXX

標題: XXXXXX

對於一些簡單作業,使用分隔符號可能不會對輸出品質產生影響。然而,任務越複雜,消除任務細節的歧義就越重要。要讓LLM準確地理解我們對模型的要求。

戰術四:指定完成作業所需的步驟

有些作業最好指定為一系列步驟。明確地寫出步驟可以使模型更容易遵循作業規定。

使用以下逐步說明來回應使用者輸入。例如輸入以下文字:

步驟 1 — 將以下三引號中的文字。用一個句子總結這段文字,並加上前綴「總結:」。

步驟 2 — 將步驟 1 中的摘要翻譯成英文,並加上前綴「翻譯:」。

“””XXXXXXXXXXXXXXXXXX”””

戰術五:提供範例

提供適用於所有範例的一般性指示通常比透過範例展示作業的所有排列更有效,但在某些情況下提供範例可能更容易。例如,如果打算讓模型複製回應我們問題的特定風格,而這種風格很難明確描述。這稱為“few-shot”提示。

例如一開始跟LLM說:

以一致的風格回答。
告訴我甚麼是雲端運算。(接續輔助性文字)從佈署模式到運用模式進行解說。

戰術六:指定所需的回答長度

我們可以要求模型產生特定目標文字的輸出。目標輸出長度可以根據單字、句子、段落、重點等的計量來指定。模型可以更可靠地產生具有特定數量的段落或要點產生輸出。

例如:

用大約 50 個單字總結由三引號分隔的文字。

“””XXXXXXXXXXXXXXXXXXXXXXXXX”””

策略二:提供參考的內容

LLM可以很有自信地回答假的答案,特別是當被問及深奧的主題或引文和 URL 時。就像一張筆記可以幫助學生在考試中取得更好的成績一樣,為LLM提供參考文件可以幫助減少回答的次數。可以實行的戰術有:

戰術一:指示模型使用參考文本回答

如果我們可以為模型提供與想要問的問題相關的可信資訊,那麼我們可以指示模型使用提供的資訊來組成其答案。例如的問題:

使用以下三重引號引入的文章來回答問題。如果在文章中找不到答案,請回答「我找不到答案」。(接著輸入引號中的文章與其後續問題)

鑑於所有模型的問題輸入視窗都有限,我們需要某種方法來動態地尋找與所提出的問題相關的資訊。嵌入(Embeddings)可用於實現高效率的知識檢索。有關如何實現這一點的更多詳細資訊,我們在後面的戰術「使用基於嵌入的搜尋來實現高效的知識檢索」會說明。

戰術二:指示模型透過引用參考文本來回答問題

如果輸入(input)已補充相關知識,則可以直接要求模型透過引用所提供文件中的段落來為其答案新增引用。需要注意,輸出中的引用可以透過所提供文件中的字串匹配以程式設計方式進行驗證。例如問題是:

以下有一份由三重引號和一個問題分隔的文件。任務是僅使用提供的文件回答問題,並引用用於回答問題的文件段落。如果文件不包含回答此問題所需的資訊,則只需寫:「資訊不足」。如果提供了問題的答案,則必須附有引文註釋。使用以下格式引用相關段落({“引用”:…})。

“””使用的文件”””

問題:XXXXXXXX

策略三: 將複雜作業分解成簡單的作業

正如軟體工程中將複雜系統分解為一組模組化元件是良好實踐一樣,提交給LLM的作業也是如此。複雜的作業往往比簡單的作業有更高的錯誤率。此外,複雜的作業通常可以被重新定義為更簡單作業的工作流程,其中早期作業的輸出用於建構後續作業的輸入。可以運用的戰術有:

戰術一:使用意圖分類(intent classification)來識別與問題最相關的指示

對於需要大量獨立指示集來處理不同情況的作業,首先對問題進行分類並使用該分類來確定需要哪些指示可能是有效益的。這可以透過定義與處理特訂定類別中的作業相關的固定類別和硬編碼(hardcode)指示來實現。該過程也可以遞迴地(recursively)應用,將一個大型作業分解為一系列階段。這種方法的優點是每個問題僅包含執行作業下一階段所需的指令,與使用單一問題執行整個作業相比,這可以降低錯誤率。這也可以降低成本,因為複雜問運作的成本更高。

例如,假設對於雲端維運客戶服務應用程式,問題可以有效地分類如下:

提供客戶服務問題查詢。將每個查詢分為主要類別和次要類別。提供 json 格式的輸出,其中包含以下類別:主要和次要。

主要類別:費用、技術支援、帳號管理或一般查詢。

計費第二級類別:
- 取消訂閱或升級
- 新增付款方式
- 收費說明
- 對收費提出爭議

技術支援第二級分類:
- 故障排除
- 設備相容性
- 軟體更新

帳號管理第二級分類:
- 密碼重設
- 更新個人資訊
- 關閉帳戶
- 帳戶安全

一般查詢第二級類別:
- 產品資訊
- 定價
- 回饋
- 與人類交談

使用者問題: (例如)我需要讓我的雲端重新作業。

根據使用者問題的分類,可以向模型提供一組更具體的指令,以供其處理後續步驟。例如,假設客戶需要「故障排除」方面的協助。

需要在技術支援環境中進行故障排除的客戶服務查詢。透過以下方式幫助使用者:

  1. 請使用者檢查所有進出路由器的線路是否已連接。請注意,隨著時間的推移,線路鬆動是很常見的。
  2. 如果所有線路都已連接且問題仍然存在,詢問使用者正在使用哪種路由器型號
  3. 現在將建議使用者如何重新啟動設備:
  4. 如果型號是 xxx-xxx,建議他們按下紅色按鈕並按住 5 秒鐘,然後等待 5 分鐘後再測試連接。
  5. 如果型號是 xxx-xxx,建議使用者拔下並重新插入,然後等待 5 分鐘再測試連接。
  6. 如果使用者的問題在重新啟動裝置並等待 5 分鐘後仍然存在,請透過輸出 {「IT 支援請求」} 將他們連接到 人類的IT 支援。
  7. 如果使用者開始詢問與此主題無關的問題,請確認他們是否想結束當前有關故障排除的對話,並根據以下方案對使用者的請求進行分類:

<在此插入上面的主要/次要分類方案>

需要注意,模型已被指示發出特殊字串來指示對話狀態何時發生變化。這使我們能夠將我們的系統變成一個狀態機(state machine),其中狀態決定要注入哪些指令。透過追蹤狀態、哪些指令與該狀態相關,以及可選地允許從該狀態進行哪些狀態轉換,我們可以在使用者體驗周圍設定邊界,而使用不太結構化的方法很難實現這一點

戰術二:對於需要很長對話的聊天應用,總結或過濾先前的對話

由於模型具有固定的背景脈絡長度(也就是你不可以問他一個論文類的問題),因此使用者和模型之間的對話(其中整個對話都包含在脈絡視窗中)無法無限期地持續。

解決此問題有多種解決方法,其中之一是上一次對話中的總結對話。一旦輸入的大小達到預定的閾值長度,這可能會觸發總結部分對話的問題,並且先前對話的摘要可以作為系統訊息的一部分包括在內。或者,可以在整個對話過程中在後台非同步總結先前的對話

另一個解決方案是動態選擇與目前查詢最相關的對話的先前部分。這個會在「使用基於嵌入的搜尋來實現高效的知識檢索」的戰術來介紹。

戰術三:分段並總結內容龐大的文件並遞歸地建構完整摘要

由於模型具有固定的脈絡長度,因此它們不能用於總結是長於脈絡長度減去單一問題中產生的摘要長度的文字。

要總結一個很長的文件(例如一本書),我們可以使用一系列問題來總結文件的每個部分。章節摘要可以連結和總結,產生摘要的摘要。這個過程可以遞迴地進行,直到總結整個文件。如果有必要使用前面部分的資訊來理解後面的部分,另一個有用的技巧是在該文件中任何特定點之前包含文本的運行摘要,同時總結該點的內容。 OpenAI 在先前的研究中已經使用 GPT-3 的變體研究了這種總結書籍的過程的有效性。

--

--

運用"雲端服務"加速企業的數位轉型願景
運用"雲端服務"加速企業的數位轉型願景

Written by 運用"雲端服務"加速企業的數位轉型願景

我們協助您駕馭名為"雲端運算"的怪獸,馴服它為您所用。諮詢請來信jason.kao@suros.com.tw. https://facebook.com/jason.kao.for.cloud

No responses yet