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

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

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

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

用戶領(lǐng)域和文檔領(lǐng)域之間的轉(zhuǎn)換正是提示詞工程所覆蓋的領(lǐng)域——由于我們已經(jīng)在 GitHub Copilot 項(xiàng)目上工作了兩年多，所以在這個(gè)過程中發(fā)現(xiàn)了一些模式。

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

實(shí)現(xiàn)提示詞工程有很多種方法。最近，微軟開源了 LMOps 工具包，其中包含了 Promptist（一種用于優(yōu)化用戶文本輸入以生成圖像的工具）和結(jié)構(gòu)化提示詞（一種用于在少量學(xué)習(xí)提示詞中包含更多樣本來生成文本的技術(shù)）。

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

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