提示詞工程還沒玩明白，又多了一個新詞叫上下文工程！
這兩年在AI圈子里，真的是新名詞、新概念、新模型層出不窮，貌似隔段時間不出現一個新詞感覺整個行業都退步了一樣，大家都還在學習怎么使用好Prompt Engineering（提示詞工程）的時候，這不Context Engineering（上下文工程）這個新詞就出來了。
這篇內容來分享一下關于Context Engineering（上下文工程）這個新詞的介紹、提示詞工程和上下文工程的區別、以及二者在實際工作中的作用是什么，畢竟，現在AI圈子里面的新東西還是要跟上節奏學習的。
首先還是要先說一下這個背景，也就是為什么會提出一個Context Engineering（上下文工程）概念，以及它所解決的問題是啥。
我們其實還是要回到AI應用場景中來，對于AI Agents（AI 智能體）來說，簡單的可以認為它是由多個工作流編排而生成的，而工作流編排中可能會設計到非常多環節，我們可以通過下圖來理解（基于n8n來構建的Agent）
這種流程需要管理構成完整上下文的不同類型的信息：
- 系統指令，用于設定行為和規則
- 對話歷史記錄和用戶偏好
- 從文檔或數據庫中檢索信息
- 可用的工具及其定義
- 結構化輸出格式和模式
- 實時數據與外部 API 響應
對應的技術架構示意圖如下：
如果想讓 AI Agent 做某件事，我們需要在不恰當的時機以不恰當的格式提供正確的上下文。
那其實就是上下文工程發揮作用的地方。
這不僅僅是與 LLM 對話；它還關于設置圍繞它的整個環境，以便它能夠做出好的決策。
實際操作中是這樣的：
1. 用戶輸入：他們正在詢問什么
2. 聊天歷史：AI 具有記憶
3. 用戶數據：偏好設置、歷史行為、個性化
4. RAG 上下文：從文檔、網站和向量數據庫中提取
5. Tool Function：API、搜索、計算器，需要什么就有什么
6. 理由：Agent可以規劃、反思和適應
關于短期記憶（Short-Term Memory）和長期記憶（Long-Term Memory）
- 短期記憶 ： 它主要是在當前的上下文窗口中
- 長期記憶 ：存儲在獨立的向量數據庫中
對于大模型來說，提供給它完整結構化的的信息（上下文內容）比一個固定帶有話術/措辭的內容（提示詞）要重要，因為模型首先要先完整的理解這些信息，才能給出準備的答復，而完整的信息并不是一個簡單的提示詞，還包含了過去我們所溝通的歷史信息，以及前期所設定的內容范圍。
所以，很多時候，模型返回的信息不準確，通常不是模型的問題，而是我們給模型輸入的內容缺少前后背景信息。
提示詞是起點，上下文就是系統。
上下文工程與提示詞工程的區別是什么？
提示詞工程簡單來說用于單次窗口對話，而對于復雜、系統化的工程來說，它不僅僅是一個單次對話那么簡單，而是要包含所有前面的對話內容、內置的提示詞信息等等
在上下文工程里面也是包含了提示詞內容，可以說提示詞工程是上下文工程其中的一個子集，比如：
我們讓 ChatGPT “寫一封專業的電子郵件”，那這個就是一個提示詞，我們是在為單個任務編寫指令，但如果你正在構建一個需要記住之前工單、訪問用戶賬戶詳細信息并在多次交互中保持對話歷史記錄的客戶服務機器人，那就是上下文工程。
上下文工程是構建動態系統，以在正確的格式中提供正確的信息和工具，使得 LLM 能夠合理地完成任務。
大部分情況下，當Agent表現不可靠時，根本原因在于適當的上下文、指令和工具沒有傳達給模型。
與此同時，LLM 應用正從單一提示詞模式發展到更復雜、動態的 AI Agent系統，因此，上下文工程正成為 AI 工程師可以發展的 最重要技能
所以，在很多公司招聘中，除了提示詞工程時，還會有上文下工程師，這也是一項職業技能。
大多數 AI 應用都同時使用提示工程和上下文工程，在上下文工程系統中，我們其實仍然需要精心編寫的提示，而區別在于，這些提示現在與經過仔細編排的前提和背景信息一起運行，而不是每次都從頭開始。
方法 | 最適用于 |
提示工程 | 一次性任務，內容生成，特定格式輸出 |
上下文工程 | 對話式 AI，文檔分析工具，代碼助手 |
兩者結合 | 需要一致、可靠性能的生產 AI 應用 |
上下文工程在應用中的實踐
當我們開始構建需要處理復雜、相互關聯信息的 AI 應用時，上下文工程便從理論走向現實構建 AI 應用考慮一個需要支持內部業務系統、當前信息處理狀態，并參考產品文檔的客戶服務機器人，同時還要保持友好的對話語氣。這就是傳統提示方法失效而上下文工程變得必要的地方。
1. RAG 系統
上下文工程可以說始于檢索增強生成 (RAG) 系統。RAG 是最早讓 LLMs 接觸到其原始訓練數據之外信息的技術之一。
RAG 系統使用先進的上下文工程技術來更有效地組織和呈現信息。它們將文檔分解為有意義的片段，按相關性對信息進行排序，并在令牌限制內包含最實用的細節。
在 RAG 之前，如果你想讓 AI 回答關于你公司內部文件的問題，你必須重新訓練或微調整個模型。RAG 通過構建能夠搜索你的文件、找到相關片段，并將它們與你的問題一起包含在上下文窗口中，改變了這一點。
這意味著 LLMs 突然能夠分析多個文檔和來源，以回答通常需要人類閱讀數百頁才能回答的復雜問題。
2. AI Agent
RAG 系統為外部信息打開了大門，但 AI 代理通過使上下文動態和響應式，將這一點進一步推進。代理在對話過程中使用外部工具，而不僅僅是檢索靜態文檔。
AI 決定哪個工具最能解決當前問題。一個代理可以開始對話，意識到需要當前的股票數據，調用金融 API，然后使用這些最新信息繼續對話。
3. AI 編程助手
例如如 Cursor 代表了上下文工程最先進的應用之一，因為AI編程助手處理高度結構化、相互關聯的信息時，結合了 RAG 和AI Agent的技術。
這些系統不僅需要理解單個文件，還需要理解整個項目架構、模塊之間的依賴關系以及代碼庫中的編碼模式。
當你要求代碼助手重構一個函數時，它需要了解該函數的使用位置、期望的數據類型以及更改可能如何影響項目的其他部分。
在此，上下文工程變得至關重要，因為代碼具有跨越多個文件甚至多個存儲庫的關系。一個好的編碼助手會維護關于你的項目結構、你最近所做的更改、你的編碼風格以及你正在使用的框架的上下文信息。
上下文工程可能存在的問題
好了，上面其實基本講清楚了關于上下文工程相關的內容，以及在實際應用場景中是怎么體現出上下文的作用的，那反過來說，這東西難道就沒有其它問題嗎？畢竟，如果我們要做一個很復雜的、超長鏈路的Agent服務時，中間要處理的上下文信息可能要非常龐大，Token數量也會用的非常龐大。
帶著這個疑問，找到了一篇關于上下文工程中異常/失敗問題的論述，博客放在文末了，該興趣的讀者可以直接查看原版，這里我總結歸納為幾點：
總體來說，會出現四個上下文異常/失敗問題：
第一：上下文污染
上下文污染是指幻覺或其他錯誤進入上下文，并被反復引用。
這個問題的一種特別嚴重的表現形式是“上下文中毒”——上下文（目標、摘要）的許多部分被關于游戲狀態的錯誤信息“污染”，這通常需要很長時間才能糾正。結果，模型可能會執著于實現不可能或不相關目標。
第二：上下文干擾
上下文干擾是指當上下文變得過長時，模型過度關注上下文，忽視了在訓練過程中所學到的內容。
在AI Agent工作流程中，隨著上下文增長，即模型收集更多信息并積累歷史，累積的上下文可能會變得令人分心，而不是有所幫助。
第三：上下文混淆
上下文混淆是指模型在生成低質量響應時，使用了上下文中多余的內容
如果把某些內容放入上下文中 模型就必須關注它，這可能是無關緊要的信息或由無用的工具定義，但模型 會 將其納入考慮范圍。
大型模型，尤其是推理模型，在忽略或丟棄冗余上下文方面正變得越來越好，但我們持續看到無用的信息讓Agent陷入困境。
總之來說，越長的上下文能夠容納更多的信息，但這種能力伴隨著弊端，就是容易混淆。
第四：上下文沖突
上下文沖突是指你在當前上下文中積累的新信息或工具與其他上下文中的信息發生沖突。
這是一個更麻煩版本的《 上下文混淆 》：這里的壞上下文并非無關緊要，它直接與其他提示中的信息沖突。
微軟和 Salesforce 團隊從多個基準測試中獲取提示，并將他們的信息“分片”到多個提示中。可以這樣理解：
有時，在按下回車鍵之前，你可能會坐下來在 ChatGPT 或 Claude 中輸入段落，考慮每一個必要的細節。
其他時候，你可能會從一個簡單的提示開始，然后在聊天機器人的回答不令人滿意時添加更多細節。微軟/Salesforce 團隊修改了基準測試提示，使其看起來像這些多步驟的交流：
圖片
本文轉載自???DataForAI???，作者：??DataForAI???
