GitHub 工程師 Albert Ziegler 和 John Berryman 表示，不需要擁有機器學習或生成式 AI 博士學位就可以創建有效的基于 LLM 的應用程序，提示詞工程是關鍵。他們還分享了他們在開發 GitHub Copilot 過程中所積累的經驗。

LLM 的崛起為那些希望在應用程序中利用生成式 AI 的從業者創造了一個全新的領域。這個領域被稱為提示詞工程，專注于如何指導 LLM 產生不屬于其預訓練部分內容的輸出。人們可以通過提示詞工程定義包含足夠多上下文信息的提示詞，讓 LLM 產生可能最佳的輸出。

上下文信息存在于用戶領域，并且應該與任務規范一起被包含在提示詞中，而任務規范存在于不確定的文檔領域，在那里，LLM 只是一種可以預測下一個標記的預測器。如果這兩個領域之間沒有被正確映射，例如，沒有在提示詞中告知響應應該被作為“一個有用的 IT 專家”生成的內容返回，那么返回的響應可能會很一般。

Ziegler 和 Berryman 表示，對于 Copilot 來說，有用的上下文信息可能包括語言、文件路徑、光標上方的文本、光標下方的文本、其他文件中的文本，等等。

用戶領域和文檔領域之間的轉換正是提示詞工程所覆蓋的領域——由于我們已經在 GitHub Copilot 項目上工作了兩年多，所以在這個過程中發現了一些模式。

總的來說，他們建議的方法是基于一系列步驟的。首先，你需要收集所有相關上下文（也就是上下文收集），可能包含所有的源文件。在大多數情況下，這些上下文信息的量將超出可用的 LLM 窗口，因此你需要通過將其分割成較小不重疊的塊。接下來的兩個階段是找到一種自然的方式將上下文信息注入到 LLM 文檔中，例如，對于 Copilot 來說就是使用代碼注釋，并根據其相關性確定要包含的片段的優先級。如果你有多個 LLM 模型可選擇，那么另一個階段是決定使用哪個模型進行推理。最后一步是定義一個停止標準，讓 LLM 知道何時完成，例如，當輸出換行符時。

實現提示詞工程有很多種方法。最近，微軟開源了 LMOps 工具包，其中包含了 Promptist（一種用于優化用戶文本輸入以生成圖像的工具）和結構化提示詞（一種用于在少量學習提示詞中包含更多樣本來生成文本的技術）。

盡管我們可以推測 LLM 將發展到不再需要提示詞工程的地步，但 OpenAI 工程師 Sherwin Wu 在上一次紐約 QCon 大會的“生產環境中的 LLM”小組討論會上指出，至少在未來五年內仍然可能需要它。

如果你對 GitHub 在提示詞工程方面所采用的方法感興趣，請不要錯過這篇完整的文章，它涵蓋了比本文更多的細節內容。