模型提供商不斷推出越來越復雜的大型語言模型(LLM)，這些模型具有更長的上下文窗口和增強的推理能力。

這使得模型能夠處理更多信息并進行更多“思考”，但同時也增加了計算量：模型處理和輸出的信息越多，消耗的能量就越大，成本也就越高。

再加上提示詞調整(prompting)所涉及的反復試驗——可能需要嘗試幾次才能得到預期結果，而且有時手頭的問題根本不需要一個能像博士那樣思考的模型——計算支出可能會失去控制。

這催生了提示詞操作(prompt ops)，一個在AI初露鋒芒的時代中全新興起的學科。

“提示詞工程有點像寫作，是實際的創(chuàng)作過程，而提示詞操作則像出版，你不斷優(yōu)化內容，”IDC總裁Crawford Del Prete告訴記者，“內容是活的，內容在不斷變化，你希望確保隨著時間的推移不斷優(yōu)化它?！?/p>

計算使用與成本的挑戰(zhàn)

在大型語言模型的背景下，計算使用與成本是兩個“相關但獨立的概念”，Vector研究所的應用科學家David Emerson解釋道。一般來說，用戶支付的價格基于輸入令牌數(shù)(用戶提示的內容)和輸出令牌數(shù)(模型提供的內容)來計算，然而，對于幕后操作如元提示(meta-prompts)、導向指令或檢索增強生成(RAG)等，費用并不會改變。

雖然更長的上下文允許模型一次處理更多文本，但這直接轉化為更多的FLOPS(計算能力的度量單位)，他解釋道。如果管理不善，模型的某些方面甚至會隨著輸入長度的增加而呈平方級增長。不必要地冗長的響應也會減慢處理時間，并需要額外的計算和成本來構建和維護算法，以便將響應處理成用戶期望的答案。

通常，長上下文環(huán)境會激勵提供商故意提供冗長的響應，Emerson說。例如，許多更復雜的推理模型(如OpenAI的o3或o1)往往會為簡單問題提供長篇大論的回答，從而產生高昂的計算成本。

舉個例子：

輸入：回答以下數(shù)學問題。如果我有2個蘋果，吃了1個后又買了4個，我有多少個蘋果?

輸出：如果我吃了1個，就只剩下1個了。如果我再買4個，就會有5個蘋果。

模型不僅生成了比需要的更多的令牌，還把答案藏在了其中。工程師可能不得不設計一種編程方式來提取最終答案，或者提出后續(xù)問題如“你的最終答案是什么?”這又會增加更多的API成本。

或者，可以重新設計提示詞以引導模型直接給出答案。例如：

輸入：回答以下數(shù)學問題。如果我有2個蘋果，吃了1個后又買了4個，我有多少個蘋果?以“答案是”為開頭回答……

或者：

輸入：回答以下數(shù)學問題。如果我有2個蘋果，吃了1個后又買了4個，我有多少個蘋果?將最終答案用粗體標簽括起來。

“提問的方式可以減少獲得期望答案所需的努力或成本，”Emerson說。他還指出，像少樣本提示(few-shot prompting，提供用戶正在尋找的幾個示例)這樣的技術可以幫助更快地輸出結果。

一個危險是不知道何時使用復雜的技術，如思維鏈(CoT)提示(分步生成答案)或自我優(yōu)化，這些技術直接鼓勵模型生成許多令牌或在生成響應時進行多次迭代，Emerson指出。

并非每個查詢都需要模型在提供答案之前進行分析和重新分析，他強調說;當被指示直接回答時，它們可能完全能夠正確回答。此外，不正確的提示API配置(如OpenAI的o3，需要高推理努力)在只需要低努力、更便宜的請求就足夠時，會產生更高的成本。

“有了更長的上下文，用戶還可能傾向于采用‘無所不包’的方法，即把盡可能多的文本塞進模型上下文中，希望這樣做能幫助模型更準確地執(zhí)行任務，”Emerson說，“雖然更多的上下文可以幫助模型執(zhí)行任務，但這并不總是最佳或最高效的方法?！?/p>

向提示詞操作的演變

如今，AI優(yōu)化的基礎設施很難獲得，這已不是什么秘密。IDC的Del Prete指出，企業(yè)必須能夠最小化GPU的閑置時間，并在GPU請求之間的空閑周期中處理更多查詢。

“我如何從這些極其寶貴的資源中擠出更多?”他問道，“因為我必須提高系統(tǒng)利用率，因為我不能簡單地通過增加容量來解決問題。”

提示詞操作可以在很大程度上解決這一挑戰(zhàn)，因為它最終管理的是提示詞的生命周期。雖然提示詞工程關注的是提示詞的質量，但提示詞操作則是關于重復和優(yōu)化，Del Prete解釋道。

“這更像是編排，”他說，“我把它看作是對問題的策劃以及你如何與人工智能交互，以確保你從中獲得最大利益?！?/p>

模型可能會“疲勞”，陷入循環(huán)中，輸出質量下降，他說。提示詞操作有助于管理、測量、監(jiān)控和調整提示詞?！拔艺J為，三四年后當我們回顧時，這將成為一個完整的學科，它將是一項技能。”

雖然這仍然是一個新興領域，但早期的提供商包括QueryPal、Promptable、Rebuff和TrueLens。隨著提示詞操作的發(fā)展，這些平臺將繼續(xù)迭代、改進并提供實時反饋，以使用戶能夠隨時間更好地調整提示詞，Del Prete指出。

最終，他預測，智能體將能夠自己調整、編寫和構建提示詞。“自動化程度將提高，人機交互程度將降低，你將能夠擁有更自主地創(chuàng)建提示詞的智能體。”

常見的提示詞錯誤

在提示詞操作完全實現(xiàn)之前，實際上沒有完美的提示詞。根據Emerson的說法，人們犯的一些最大錯誤包括：

? 沒有足夠具體地說明要解決的問題，這包括用戶希望模型如何提供答案、回答時應考慮什么、應遵守的約束條件以及其他因素。“在許多情況下，模型需要大量上下文才能提供符合用戶期望的回答。”Emerson說。

? 沒有考慮到可以簡化問題以縮小回答范圍的方法。答案是否應在某個范圍內(0到100)?答案是否應表述為多項選擇題而不是開放性問題?用戶能否提供好的示例來為查詢提供上下文?問題能否分解為步驟以進行單獨和更簡單的查詢?

? 沒有利用結構。大型語言模型非常擅長模式識別，許多模型都能理解代碼。雖然使用項目符號、項目列表或粗體指示器(****)在人類看來可能“有點雜亂”，但Emerson指出，這些標注對大型語言模型來說是有益的。當用戶希望自動處理響應時，請求結構化輸出(如JSON或Markdown)也會有所幫助。

Emerson指出，基于工程最佳實踐，在維護生產管道時還需要考慮許多其他因素。這些包括：

? 確保管道的吞吐量保持一致

? 監(jiān)控提示詞隨時間的表現(xiàn)(可能針對驗證集)

? 設置測試和早期預警檢測以識別管道問題

用戶還可以利用專門設計來支持提示詞過程的工具。例如，開源的DSPy可以根據一些標記的示例自動為下游任務配置和優(yōu)化提示詞。雖然這可能是一個相當復雜的例子，但還有許多其他工具(包括ChatGPT、Google等內置的一些工具)可以協(xié)助設計提示詞。

最終，Emerson說：“我認為用戶能做的最簡單的事情之一就是盡量跟上有效的提示詞方法、模型發(fā)展和與模型交互的新方式。”