這兩年在AI圈子里，真的是新名詞、新概念、新模型層出不窮，貌似隔段時(shí)間不出現(xiàn)一個(gè)新詞感覺整個(gè)行業(yè)都退步了一樣，大家都還在學(xué)習(xí)怎么使用好Prompt Engineering（提示詞工程）的時(shí)候，這不Context Engineering（上下文工程）這個(gè)新詞就出來了。

這篇內(nèi)容來分享一下關(guān)于Context Engineering（上下文工程）這個(gè)新詞的介紹、提示詞工程和上下文工程的區(qū)別、以及二者在實(shí)際工作中的作用是什么，畢竟，現(xiàn)在AI圈子里面的新東西還是要跟上節(jié)奏學(xué)習(xí)的。

首先還是要先說一下這個(gè)背景，也就是為什么會(huì)提出一個(gè)Context Engineering（上下文工程）概念，以及它所解決的問題是啥。

我們其實(shí)還是要回到AI應(yīng)用場(chǎng)景中來，對(duì)于AI Agents（AI 智能體）來說，簡(jiǎn)單的可以認(rèn)為它是由多個(gè)工作流編排而生成的，而工作流編排中可能會(huì)設(shè)計(jì)到非常多環(huán)節(jié)，我們可以通過下圖來理解（基于n8n來構(gòu)建的Agent）

這種流程需要管理構(gòu)成完整上下文的不同類型的信息：

• 系統(tǒng)指令，用于設(shè)定行為和規(guī)則
• 對(duì)話歷史記錄和用戶偏好
• 從文檔或數(shù)據(jù)庫中檢索信息
• 可用的工具及其定義
• 結(jié)構(gòu)化輸出格式和模式
• 實(shí)時(shí)數(shù)據(jù)與外部 API 響應(yīng)

對(duì)應(yīng)的技術(shù)架構(gòu)示意圖如下：

如果想讓 AI Agent 做某件事，我們需要在不恰當(dāng)?shù)臅r(shí)機(jī)以不恰當(dāng)?shù)母袷教峁┱_的上下文。

那其實(shí)就是上下文工程發(fā)揮作用的地方。

這不僅僅是與 LLM 對(duì)話；它還關(guān)于設(shè)置圍繞它的整個(gè)環(huán)境，以便它能夠做出好的決策。

實(shí)際操作中是這樣的：

1. 用戶輸入：他們正在詢問什么

2. 聊天歷史：AI 具有記憶

3. 用戶數(shù)據(jù)：偏好設(shè)置、歷史行為、個(gè)性化

4. RAG 上下文：從文檔、網(wǎng)站和向量數(shù)據(jù)庫中提取

5. Tool Function：API、搜索、計(jì)算器，需要什么就有什么

6.  理由：Agent可以規(guī)劃、反思和適應(yīng)

關(guān)于短期記憶（Short-Term Memory）和長(zhǎng)期記憶（Long-Term Memory）

• 短期記憶 ： 它主要是在當(dāng)前的上下文窗口中
• 長(zhǎng)期記憶 ：存儲(chǔ)在獨(dú)立的向量數(shù)據(jù)庫中

對(duì)于大模型來說，提供給它完整結(jié)構(gòu)化的的信息（上下文內(nèi)容）比一個(gè)固定帶有話術(shù)/措辭的內(nèi)容（提示詞）要重要，因?yàn)槟Ｐ褪紫纫韧暾睦斫膺@些信息，才能給出準(zhǔn)備的答復(fù)，而完整的信息并不是一個(gè)簡(jiǎn)單的提示詞，還包含了過去我們所溝通的歷史信息，以及前期所設(shè)定的內(nèi)容范圍。

所以，很多時(shí)候，模型返回的信息不準(zhǔn)確，通常不是模型的問題，而是我們給模型輸入的內(nèi)容缺少前后背景信息。

提示詞是起點(diǎn)，上下文就是系統(tǒng)。

上下文工程與提示詞工程的區(qū)別是什么？

提示詞工程簡(jiǎn)單來說用于單次窗口對(duì)話，而對(duì)于復(fù)雜、系統(tǒng)化的工程來說，它不僅僅是一個(gè)單次對(duì)話那么簡(jiǎn)單，而是要包含所有前面的對(duì)話內(nèi)容、內(nèi)置的提示詞信息等等

在上下文工程里面也是包含了提示詞內(nèi)容，可以說提示詞工程是上下文工程其中的一個(gè)子集，比如：

我們讓 ChatGPT “寫一封專業(yè)的電子郵件”，那這個(gè)就是一個(gè)提示詞，我們是在為單個(gè)任務(wù)編寫指令，但如果你正在構(gòu)建一個(gè)需要記住之前工單、訪問用戶賬戶詳細(xì)信息并在多次交互中保持對(duì)話歷史記錄的客戶服務(wù)機(jī)器人，那就是上下文工程。

上下文工程是構(gòu)建動(dòng)態(tài)系統(tǒng)，以在正確的格式中提供正確的信息和工具，使得 LLM 能夠合理地完成任務(wù)。

大部分情況下，當(dāng)Agent表現(xiàn)不可靠時(shí)，根本原因在于適當(dāng)?shù)纳舷挛?、指令和工具沒有傳達(dá)給模型。

與此同時(shí)，LLM 應(yīng)用正從單一提示詞模式發(fā)展到更復(fù)雜、動(dòng)態(tài)的 AI Agent系統(tǒng)，因此，上下文工程正成為 AI 工程師可以發(fā)展的 最重要技能 

所以，在很多公司招聘中，除了提示詞工程時(shí)，還會(huì)有上文下工程師，這也是一項(xiàng)職業(yè)技能。

大多數(shù) AI 應(yīng)用都同時(shí)使用提示工程和上下文工程，在上下文工程系統(tǒng)中，我們其實(shí)仍然需要精心編寫的提示，而區(qū)別在于，這些提示現(xiàn)在與經(jīng)過仔細(xì)編排的前提和背景信息一起運(yùn)行，而不是每次都從頭開始。

上下文工程在應(yīng)用中的實(shí)踐

當(dāng)我們開始構(gòu)建需要處理復(fù)雜、相互關(guān)聯(lián)信息的 AI 應(yīng)用時(shí)，上下文工程便從理論走向現(xiàn)實(shí)構(gòu)建 AI 應(yīng)用考慮一個(gè)需要支持內(nèi)部業(yè)務(wù)系統(tǒng)、當(dāng)前信息處理狀態(tài)，并參考產(chǎn)品文檔的客戶服務(wù)機(jī)器人，同時(shí)還要保持友好的對(duì)話語氣。這就是傳統(tǒng)提示方法失效而上下文工程變得必要的地方。

1. RAG 系統(tǒng)

上下文工程可以說始于檢索增強(qiáng)生成 (RAG) 系統(tǒng)。RAG 是最早讓 LLMs 接觸到其原始訓(xùn)練數(shù)據(jù)之外信息的技術(shù)之一。

RAG 系統(tǒng)使用先進(jìn)的上下文工程技術(shù)來更有效地組織和呈現(xiàn)信息。它們將文檔分解為有意義的片段，按相關(guān)性對(duì)信息進(jìn)行排序，并在令牌限制內(nèi)包含最實(shí)用的細(xì)節(jié)。

在 RAG 之前，如果你想讓 AI 回答關(guān)于你公司內(nèi)部文件的問題，你必須重新訓(xùn)練或微調(diào)整個(gè)模型。RAG 通過構(gòu)建能夠搜索你的文件、找到相關(guān)片段，并將它們與你的問題一起包含在上下文窗口中，改變了這一點(diǎn)。

這意味著 LLMs 突然能夠分析多個(gè)文檔和來源，以回答通常需要人類閱讀數(shù)百頁才能回答的復(fù)雜問題。

2. AI Agent

RAG 系統(tǒng)為外部信息打開了大門，但 AI 代理通過使上下文動(dòng)態(tài)和響應(yīng)式，將這一點(diǎn)進(jìn)一步推進(jìn)。代理在對(duì)話過程中使用外部工具，而不僅僅是檢索靜態(tài)文檔。

AI 決定哪個(gè)工具最能解決當(dāng)前問題。一個(gè)代理可以開始對(duì)話，意識(shí)到需要當(dāng)前的股票數(shù)據(jù)，調(diào)用金融 API，然后使用這些最新信息繼續(xù)對(duì)話。

3. AI 編程助手

例如如 Cursor 代表了上下文工程最先進(jìn)的應(yīng)用之一，因?yàn)锳I編程助手處理高度結(jié)構(gòu)化、相互關(guān)聯(lián)的信息時(shí)，結(jié)合了 RAG 和AI Agent的技術(shù)。

這些系統(tǒng)不僅需要理解單個(gè)文件，還需要理解整個(gè)項(xiàng)目架構(gòu)、模塊之間的依賴關(guān)系以及代碼庫中的編碼模式。

當(dāng)你要求代碼助手重構(gòu)一個(gè)函數(shù)時(shí)，它需要了解該函數(shù)的使用位置、期望的數(shù)據(jù)類型以及更改可能如何影響項(xiàng)目的其他部分。

在此，上下文工程變得至關(guān)重要，因?yàn)榇a具有跨越多個(gè)文件甚至多個(gè)存儲(chǔ)庫的關(guān)系。一個(gè)好的編碼助手會(huì)維護(hù)關(guān)于你的項(xiàng)目結(jié)構(gòu)、你最近所做的更改、你的編碼風(fēng)格以及你正在使用的框架的上下文信息。

上下文工程可能存在的問題

好了，上面其實(shí)基本講清楚了關(guān)于上下文工程相關(guān)的內(nèi)容，以及在實(shí)際應(yīng)用場(chǎng)景中是怎么體現(xiàn)出上下文的作用的，那反過來說，這東西難道就沒有其它問題嗎？畢竟，如果我們要做一個(gè)很復(fù)雜的、超長(zhǎng)鏈路的Agent服務(wù)時(shí)，中間要處理的上下文信息可能要非常龐大，Token數(shù)量也會(huì)用的非常龐大。

帶著這個(gè)疑問，找到了一篇關(guān)于上下文工程中異常/失敗問題的論述，博客放在文末了，該興趣的讀者可以直接查看原版，這里我總結(jié)歸納為幾點(diǎn)：

總體來說，會(huì)出現(xiàn)四個(gè)上下文異常/失敗問題：

第一：上下文污染

上下文污染是指幻覺或其他錯(cuò)誤進(jìn)入上下文，并被反復(fù)引用。

這個(gè)問題的一種特別嚴(yán)重的表現(xiàn)形式是“上下文中毒”——上下文（目標(biāo)、摘要）的許多部分被關(guān)于游戲狀態(tài)的錯(cuò)誤信息“污染”，這通常需要很長(zhǎng)時(shí)間才能糾正。結(jié)果，模型可能會(huì)執(zhí)著于實(shí)現(xiàn)不可能或不相關(guān)目標(biāo)。

第二：上下文干擾

上下文干擾是指當(dāng)上下文變得過長(zhǎng)時(shí)，模型過度關(guān)注上下文，忽視了在訓(xùn)練過程中所學(xué)到的內(nèi)容。

在AI Agent工作流程中，隨著上下文增長(zhǎng)，即模型收集更多信息并積累歷史，累積的上下文可能會(huì)變得令人分心，而不是有所幫助。 

第三：上下文混淆

上下文混淆是指模型在生成低質(zhì)量響應(yīng)時(shí)，使用了上下文中多余的內(nèi)容

如果把某些內(nèi)容放入上下文中 模型就必須關(guān)注它，這可能是無關(guān)緊要的信息或由無用的工具定義，但模型 會(huì) 將其納入考慮范圍。

大型模型，尤其是推理模型，在忽略或丟棄冗余上下文方面正變得越來越好，但我們持續(xù)看到無用的信息讓Agent陷入困境。

總之來說，越長(zhǎng)的上下文能夠容納更多的信息，但這種能力伴隨著弊端，就是容易混淆。

第四：上下文沖突

上下文沖突是指你在當(dāng)前上下文中積累的新信息或工具與其他上下文中的信息發(fā)生沖突。

這是一個(gè)更麻煩版本的《 上下文混淆 》：這里的壞上下文并非無關(guān)緊要，它直接與其他提示中的信息沖突。

微軟和 Salesforce 團(tuán)隊(duì)從多個(gè)基準(zhǔn)測(cè)試中獲取提示，并將他們的信息“分片”到多個(gè)提示中?？梢赃@樣理解：

有時(shí)，在按下回車鍵之前，你可能會(huì)坐下來在 ChatGPT 或 Claude 中輸入段落，考慮每一個(gè)必要的細(xì)節(jié)。

其他時(shí)候，你可能會(huì)從一個(gè)簡(jiǎn)單的提示開始，然后在聊天機(jī)器人的回答不令人滿意時(shí)添加更多細(xì)節(jié)。微軟/Salesforce 團(tuán)隊(duì)修改了基準(zhǔn)測(cè)試提示，使其看起來像這些多步驟的交流：

圖片

本文轉(zhuǎn)載自???DataForAI???，作者：??DataForAI???