“ 上下文工程是一種復(fù)雜的提示詞方法論，其作用是為了解決模型上下文窗口限制所導(dǎo)致的問題。”

最近在優(yōu)化RAG的增強問題，也就是提示詞的封裝，包含系統(tǒng)提示詞，用戶問題，歷史記錄和召回文檔等；然后就發(fā)現(xiàn)一個平常沒有關(guān)注的問題，那就是模型上下文窗口大小以及其帶來的問題。

我們都知道模型的上下文窗口是有大小限制的，哪怕隨著模型技術(shù)的發(fā)展其窗口大小也越來越大，但總歸有一個限制；而在這個窗口中不但包含了用戶問題，還同時包含了歷史記錄和參考文檔；特別是在多輪對話中，隨著對話次數(shù)的增多，很容易就達到了上下文窗口的限制。

當然，可能很有人會說，我在使用模型的時候聊天好多輪但都沒有報超長錯誤啊；原因是模型廠商默認給你做了上下文裁剪，當上下文超過模型窗口時會默認丟棄之前的對話，這也是大模型“失憶”的原因。

模型上下文窗口

模型上下文窗口限制，這是一個客觀存在的事實；但可能很多人到現(xiàn)在都沒搞明白這個上下文窗口到底是怎么算的，特別是在多輪對話中，比如說上下文窗口與輸入輸出之間的關(guān)系？

模型上下文窗口因模型不同，其值也不同；但我們要明白一件事，那就是模型上下文窗口是指模型能夠處理的最大數(shù)據(jù)長度，其計量單位是Token，如果不知道什么是token的，自己去查。

因此，模型上下文窗口包含了輸入和輸出；特別是在多輪對話中的處理最為顯著。

舉例來說，一個模型的上下文窗口是1000token；你輸入用了100token(包含問題，系統(tǒng)提示詞，參考文檔等）；然后模型回答問題用了兩百token，這時模型的上下文窗口就還剩700token；然后在第二輪對話中，假如你的輸入還是用了100token，第二輪回答也是用了200token，那么由于歷史記錄的存在，第二輪對話消耗了多少token?

100 + 200 + 300(第一輪對話的輸入和輸出100+200)，這時就用了600token，那么再對話一次，在第四次對話的時候，上下文窗口就超限了。這時應(yīng)該怎么辦？

默認情況下會對上下文進行截取，丟掉最開始的第一輪對話內(nèi)容或者前200個token。

當然，以上內(nèi)容都是基于多輪對話和有記憶功能存在的前提下，如果是單輪對話或者沒有記憶，那么只要單次沒有超出模型上下文限制，那么就不會有問題。

由于目前大部分的應(yīng)用場景都是基于多輪對話，因此基于以上情況就面臨一個問題，上下文超長是一個必然的過程；那么，怎么才能讓模型更好地輸入和輸出呢？

這時，提示詞工程和上下文工程的作用就體現(xiàn)出來了；在這里我們要明白一個前提，不管模型的上下文限制是多少，對模型來說它接受的最終形式就是一串提示詞。

而這就是提示詞工程要做的事情，但這里為什么又搞出了一個上下文工程呢？

在大模型應(yīng)用中，提示詞工程一般是指靜態(tài)的提示詞，其作用是為了在單次對話中，盡可能的引導(dǎo)模型，讓其表現(xiàn)達到最好；但是，在多輪對話中，提示詞最終的來源很復(fù)雜，包括用戶問題，系統(tǒng)提示詞，歷史記錄和參考問題；特別是歷史記錄。

上下文工程雖然很多人都認為它是一個新概念，但事實上我們在開發(fā)過程中已經(jīng)在使用它了；比如說在langchain的提示詞模板中拼接歷史記錄和參考文檔就屬于上下文工程的一部分。

上下文工程可以簡單理解為是提示詞工程的一種復(fù)雜情況，由于歷史記錄和參考文檔的存在；特別是隨著多輪對話，歷史記錄會逐漸增多，這時怎么保證在盡可能不丟失歷史記錄的前提下，還能保證最終的提示詞不會超出上下文窗口，以及使用什么樣的提示詞結(jié)構(gòu)才能讓大模型更好的理解和輸出，這就是上下文工程所需要解決的問題。

為了解決這個問題，因此有了歷史記錄壓縮技術(shù)，提示詞結(jié)構(gòu)設(shè)計，參考文檔處理等一系列技術(shù)問題。

總之，上下文工程的目的是為了解決在模型上下文有限的情況下，盡可能的讓模型表現(xiàn)的更好，輸出更高質(zhì)量的回答。

本文轉(zhuǎn)載自?????AI探索時代????? 作者：DFires