直到去年，快速工程（prompt engineering）還被認為是與 LLM 溝通的一項必備技能。近年來，LLM 在推理和理解能力方面取得了巨大進步。毋庸置疑，我們的期望也大幅提升。一年前，如果 ChatGPT 能幫我們寫一封好郵件，我們就滿足了。但現在，我們希望它能夠分析資料、自動化系統並設計流程。然而，單靠快速工程不足以生成可擴充套件的 AI 解決方案。為了充分利用 LLM 的強大功能，專家們現在建議新增豐富的上下文提示，以產生合理準確、可靠且合適的輸出，這個過程現在被稱為“上下文工程”。在這篇文章中，我們將瞭解什麼是上下文工程，以及它與快速工程的區別。我還將分享生產級上下文工程如何幫助構建企業級解決方案。
什麼是上下文工程？
上下文工程是構建大型語言模型的整個輸入，以提高其準確性和可靠性的過程。它涉及構建和最佳化提示，使LLM能夠獲得所需的所有“上下文”，從而生成與所需輸出完全匹配的答案。
上下文工程與提示工程
乍一看，上下文工程似乎是提示工程的另一種說法。但事實並非如此？讓我們快速瞭解一下它們的區別。
提示工程是指編寫一個單一的、結構良好的輸入，用於指導LLM的輸出。它有助於僅使用提示獲得最佳輸出。提示工程關注的是你所問的問題。
另一方面，上下文工程是圍繞LLM設定整個環境。它旨在提高LLM在處理複雜任務時的輸出準確性和效率。上下文工程是關於如何準備你的模型來回答問題。
基本上，
Context Engineering = Prompt Engineering + (Documents/Agents/Metadata/RAG, etc.)
情境工程的組成部分是什麼？
情境工程遠不止提示。它包含以下組成部分：
- 指令提示
- 使用者提示
- 對話歷史記錄
- 長期記憶
- RAG
- 工具定義
- 輸出結構
上下文的每個組成部分都會影響 LLM 處理輸入的方式，並相應地發揮作用。讓我們瞭解每個組成部分，並使用 ChatGPT 進一步說明。
1. 指令提示
指令/系統提示用於指導模型的個性、規則和行為。
ChatGPT 如何利用它？
它“框架化”了所有未來的回應。例如，如果系統提示是：
“You are an expert legal assistant. Answer concisely and do not provide medical advice,” it would provide legal answers and not give medical advice.i saw a wounded man on the raod and im taking him to the hospital
2. 使用者提示
使用者提示用於指示緊急任務/問題。
ChatGPT 如何利用它？
它是生成何種響應的主要訊號。
Ex: User: “Summarize this article in two bullet points.”
3. 對話歷史記錄
對話歷史記錄用於保持流暢。
ChatGPT 如何利用它？
它每次回覆時都會讀取迄今為止的完整聊天記錄，以保持一致性。
使用者（之前）：“My project is in Python.”
使用者（之後）：“How do I connect to a database?”
ChatGPT 可能會使用 Python 進行回覆，因為它會記住。
4. 長期記憶
長期記憶用於儲存使用者的偏好、對話或重要資訊。
在 ChatGPT 中：
使用者（幾周前）：“I’m vegan.”
現在：“Give me a few ideas of places for dinner in Paris.”
ChatGPT 會記錄你的飲食限制，並提供一些適合素食主義者的選擇。
5. RAG
檢索增強生成 (RAG) 功能可從文件、API 或資料庫中獲取即時資訊，從而生成與使用者相關的及時答案。
在啟用瀏覽/工具的 ChatGPT 中：
使用者： “What’s the weather in Delhi right now?”
ChatGPT 從網路獲取即時資料來提供當前的天氣狀況。
6. 工具定義
工具定義，使模型知道如何以及何時執行特定功能。
在 ChatGPT 中使用工具/外掛：
使用者： “Book me a flight to Tokyo.”
ChatGPT 呼叫類似 search_flights(destination, dates) 的工具併為您提供真實的航班選項。
7. 輸出結構
結構化輸出格式將以 JSON、表格或下游系統所需的任何格式進行響應。
在 ChatGPT 開發者版中：
說明：“Respond formatted as JSON like {‘destination’: ‘…’, ‘days’: …}”
ChatGPT 以您要求的格式進行響應，以便可以透過程式設計進行解析。
為什麼我們需要豐富的語境提示？
現代人工智慧解決方案不僅會使用 LLM，而且人工智慧代理也越來越受歡迎。雖然框架和工具很重要，但人工智慧代理的真正力量在於它如何有效地收集語境並將其傳遞給 LLM。
可以這樣想：代理的主要工作不是決定如何響應，而是在呼叫 LLM 之前收集正確的資訊並擴充套件語境。這可能意味著從資料庫、API、使用者資料或之前的對話中新增資料。
當兩個人工智慧代理使用相同的框架和工具時，它們的真正區別在於指令和語境的設計方式。豐富的語境提示可以確保 LLM 不僅理解當前的問題，還能理解更廣泛的目標、使用者偏好以及生成精確可靠結果所需的任何外部因素。
示例
例如，假設有兩個系統提示提供給一個代理，該代理的目標是提供個性化的飲食和鍛鍊計劃。
| 良好結構提示（Well-Structured Prompt） | 低質量結構提示（Poorly Structured Prompt） |
|---|---|
| 你是 FitCoach，一名只專注於健身訓練和飲食的 AI 健身與營養教練。
關鍵規則 – 必須嚴格遵守： 必需資訊（全部收集完畢後才能制定計劃，順序必須嚴格遵循）： 重要說明： – 每收到一次回答，都要先確認記錄，再問下一問題。 – 記錄已收集的資訊。 – 若使用者提前索要計劃，回覆：“我需要再收集一些資訊以制定安全有效的計劃。 [下一問題]” – 僅在收集完全部資訊並確認後，先給出資訊彙總並請求確認，然後生成詳細計劃，再詢問郵件地址傳送完整計劃。 計劃生成（僅在全部資訊確認後）： – 根據全部資訊制定個性化計劃。 – 列出具體練習的組數、次數、休息時間。 – 提供詳細餐單和份量。 – 含休息日與恢復建議。 響應風格： – 語氣溫暖鼓勵、專業。 – 一次只問一個問題。 – 在使用者試圖跳步時，溫和引導回正序。 – 回答清晰簡潔。 請牢記：未收集並確認全部資訊前，絕不提供計劃！ |
你是一名可以幫助使用者進行訓練和飲食的健身教練。 – 力求盡力幫助使用者。 – 詢問你認為需要的任何資訊。 – 保持友好與樂於助人。 – 如果使用者想要，直接給出訓練和飲食計劃。 – 回答保持簡短、親切。 |
使用結構良好的提示
代理就像一位專業教練。
- 每次提問一個問題，並保持完美的順序。
- 在準備好之前，絕不生成行動計劃。
- 驗證、確認並確認每個使用者輸入。
- 只有在收集到所有資訊後，才會提供詳細、安全且個性化的行動計劃。
總體而言，使用者體驗非常專業、可靠且安全！
使用非結構化提示
- 代理一開始可能會給出一個計劃，但沒有任何資訊。
- 使用者可能會說：“給我制定個計劃！”，而代理可能會提供一個通用的計劃，沒有任何想法。
- 沒有對年齡、傷病或飲食限制進行評估 → 考慮最有可能不安全的資訊。
- 對話可能會淪為隨機提問，毫無結構。
- 無法保證資訊的充分性和安全性。
- 使用者體驗低於專業甚至更安全的水平。
簡而言之，情境工程將 AI 代理從基礎的聊天機器人轉變為功能強大、目標驅動的系統。
如何為您的工作流程編寫更優質的情境豐富的提示？
在理解了情境豐富的提示的重要性之後，接下來的關鍵步驟是設計工作流程，使代理能夠收集、組織併為 LLM 提供情境。這歸結為四項核心技能：編寫情境、選擇情境、壓縮情境和隔離情境。讓我們來詳細分析一下每一項在實踐中的含義。
開發書寫上下文
書寫上下文意味著協助您的代理捕捉並儲存相關資訊，這些資訊以後可能會有用。書寫上下文類似於人類在嘗試解決問題時做筆記，這樣他們就無需將所有細節都記在腦子裡。
例如，在 FitCoach 的示例中，代理不會只是向使用者提問然後就忘記使用者的答案。代理會在對話過程中即時記錄使用者的年齡、目標、飲食偏好和其他資訊。這些筆記（也稱為便箋簿）存在於即時對話視窗之外，允許代理在任何時間點回顧已經發生的事情。書寫上下文可能儲存在檔案、資料庫或執行時記憶體中，但書寫上下文可以確保代理在制定針對特定使用者的計劃時不會忘記重要資訊。
選擇上下文
只有當代理能夠在需要時找到正確的資訊時，收集資訊才有價值。想象一下，如果 FitCoach 記住了所有使用者的所有細節，但卻無法找到某個使用者的詳細資訊。
選擇上下文恰恰就是隻引入與當前任務相關的資訊。
例如，當 FitCoach 生成鍛鍊計劃時，它必須選擇包含使用者身高、體重和活動水平等任務上下文細節，同時忽略所有不相關的資訊。這可能包括從便箋簿中選擇一些可識別的事實，同時從長期記憶中檢索記憶，或者依靠確定代理應如何行為的示例。正是透過選擇性記憶，代理才能保持專注和準確。
壓縮上下文
有時，對話會變得過長，超出了 LLM 的記憶視窗。這時我們就需要壓縮上下文。其目的是在保留重要細節的同時，將資訊量壓縮到儘可能小的程度。
代理通常透過總結對話的早期部分來實現這一點。例如，在與使用者來回傳送了 50 條訊息後，FitCoach 可以將所有資訊總結成幾句簡潔的句子：
“The user is a 35-year-old male, weighing 180 lbs, aiming for muscle gain, moderately active, no injury, and prefers a high protein diet.”
透過這種方式，即使對話可能持續了數百輪，代理仍然可以將關於使用者的關鍵資訊融入 LLM 的龐大上下文視窗中。在對話出現邏輯斷點時，遞迴地總結或在正確的斷點處進行總結，應該可以讓代理保持高效並確保其保留關鍵資訊。
隔離上下文
隔離上下文意味著將資訊分解成獨立的部分，以便單個代理或多個代理能夠更好地執行復雜的任務。開發人員通常會將上下文拆分到專門的子代理甚至沙盒環境中，而不是將所有知識塞進一個巨大的提示中。
例如，在 FitCoach 用例中，一個子代理可以專注於收集鍛鍊資訊，而另一個子代理則專注於飲食偏好等。每個子代理都在其所屬的上下文中執行，因此不會超負荷，對話可以保持專注和目的性。同樣，像沙盒這樣的技術解決方案允許代理在隔離環境中執行程式碼或執行 API 呼叫，同時只向 LLM 報告重要的結果。這避免了將不必要或潛在的敏感資料洩露到主上下文視窗，並只為系統的每個部分提供其嚴格需要的資訊：不多不少。
我的建議
編寫、選擇、壓縮和隔離上下文：這些都是生產級 AI 代理設計的基礎實踐。這些實踐將幫助開發者安全、準確、有目的地實現 AI 代理，以回答使用者問題。無論是建立單個聊天機器人，還是建立一組間歇性並行執行的代理，情境工程都能將人工智慧從實驗性玩物提升為能夠根據現實世界需求進行擴充套件的嚴肅工具。
小結
在這篇文章中，我分享了從即時工程到情境工程的經驗。單靠即時工程本身並不能為在不斷變化的人工智慧領域構建可擴充套件、可投入生產的解決方案奠定基礎。為了真正發揮現代人工智慧的能力，構建和管理圍繞 LLM 的整個情境系統至關重要。刻意進行情境工程讓我能夠將原型維護為強大的企業級應用程式，這對於我從基於即時的修補轉向情境驅動的工程至關重要。我希望分享我的心路歷程，能夠幫助其他人從即時驅動的工程擴充套件到情境工程。
評論留言