生活分享

上下文工程(Context Engineering)是什麼

上下文工程處理的是每次模型作答前,應該看見哪些指令、資料、歷史與工具結果。本文以社區場地借用助理為例,說明資料篩選、版本標示、權限、長對話整理與缺漏處理,並比較它和提示詞工程、檢索增強生成的關係。讀完能辨認回答錯誤是因為資料沒進來、進來的資料過時,還是資料彼此衝突,建立更可核對的工作流程。

更新日期: 閱讀時間約 7 分鐘

多份檔案經過漏斗篩選後,少數有用的資料卡落在發亮的工作桌上。
圖片:Mokaair (© Mokaair)

上下文工程是安排 每一次工作時所能看到的資訊:哪些要先給、哪些需要時再讀、哪些已經過時,以及哪些資料根本不應進入這次任務。它包含提示詞,但還會處理檔案、對話歷史、工具結果與持續儲存的工作狀態。核心問題不是一次塞多少資料,而是當下做決定需要什麼證據。

想像住戶詢問社區交誼廳能否借來辦活動。助理可能需要最新借用規章、當日空檔、住戶資格與這次活動的人數,卻不需要另一戶的繳費明細。以下用這個原創例子說明資料如何進出模型,以及出錯時怎麼查。資料查證截至 2026 年 9 月 14 日。

上下文是一份會改變的工作材料

Anthropic 把上下文工程描述為選擇並維護推論時所需資訊的策略,涵蓋系統指令、工具、外部資料與歷史。LangChain 文件則進一步區分當次模型看見的內容、持續狀態與工具可使用的環境資訊。這些是相關的實務觀點,並不是所有產品都採用同一套欄位或正式標準。

可以把模型的上下文視窗想成暫時展開的工作桌,但比喻有個限制:資料存放在系統裡,不等於模型此刻看見它。某份規章即使已上傳或存在資料庫,仍可能沒有被選進這次呼叫。回答遺漏條文時,應先檢視實際傳入的內容,再決定要不要重寫提示詞。

工作桌也不是越滿越好。大量重複對話、互相矛盾的舊公告和無關附件,都可能讓關鍵條件變難辨識。這不表示長上下文必然答錯,而是需要用任務測試選出合適材料。刪掉無關內容的同時,不能把例外條款、日期和來源一起清掉。

借用助理需要哪些材料

這個示例的輸入是:「週六想借交誼廳辦讀書會,可以嗎?」助理先辨識尚缺確切日期、時段與參加人數,再取得現行借用規章。規章中若有住戶優先、容納人數與禁止營利等條件,都應保留原文依據。行事曆只能回答時段是否空著,不能單獨證明申請符合規章。

當住戶補上日期與人數後,系統再查該時段,而不是把整年的預約紀錄全部送入模型。工具回傳可以包含時段、空檔狀態、查詢時間與資料來源;其他人的姓名與聯絡方式則沒有必要帶入。資料最小化同時幫助閱讀與權限控制,但權限仍應由後端實際執行。

預期答案可以是:「此時段目前空著;人數符合場地限制,但需完成管理室申請。」這句話把查詢結果與完成預約分開。若模型直接說「已預約成功」,應檢查工具是否真的執行預約、是否返回有效確認;只看它用了肯定語氣,無法判斷外部狀態有沒有改變。

先處理來源、版本與缺漏

每份資料最好有明確身份,例如規章名稱、生效日與取得位置。舊規章可留作歷史參考,但不能和現行規章沒有區別地混在一起。假設公告說場地整修暫停開放,行事曆卻仍顯示空白,這是來源衝突;助理應回報衝突並請管理室確認,而不是只選最容易完成任務的那份。

資料沒找到也應是一種可辨識的結果。搜尋沒有命中、來源連線失敗與條文沒有規定,代表不同狀態。把這些全部壓成「無資料」,模型就可能把技術故障誤讀為沒有任何限制。工具介面保留狀態及原因,能讓後續回答清楚說出目前還不能確定什麼。

外部檔案也可能夾帶與任務無關的指令,例如要求忽略原先規則或把資料送往另一個地方。上下文設計要標示哪些文字只是待分析的內容,不能因為出現在搜尋結果裡就得到系統權限。分隔與能降低混淆,真正可執行的動作仍需搭配工具授權和輸入檢查。

現行規章、當次需求與時段查詢經過版本、權限和相關性篩選後進入模型;舊規章與他人個資留在外部。
已儲存、可讀取、實際送入模型,是需要分別確認的狀態。 · 圖片:Mokaair (© Mokaair)

長對話需要儲存決定,而不只是縮短

住戶與助理討論多次後,歷史可能累積大量改期與取消方案。整理時應保留目前選定日期、仍待確認的事項、明確拒絕的選項及理由。只儲存最後一段漂亮摘要,可能讓早先「不能收費」的限制消失。壓縮的目標是維持決策所需資訊,而不是讓字數看起來很少。

一種可行做法是將工作狀態分成已確認、待確認、已失效,並附上對應來源。舊時段被放棄後保留為失效紀錄,新一輪只帶入目前有效的時段和必要背景。這份狀態存在外部儲存時,還要決定何時重新讀入;儲存成功並不代表模型下一輪已經讀過。

可以用刻意包含多次改期的測試對話檢查壓縮品質。讓測試者問「最後要借哪天、哪些事項還沒處理」,再對照原始紀錄。如果摘要把未核准寫成已核准,問題出在狀態語意丟失,而不是單純 token 不夠。修正時要調整儲存規則與驗證案例。

從回答錯誤追回資料流

上下文工程與提示詞工程的交界很大,但調查方向不同。指令已清楚要求依現行規章回答,卻只送入舊檔案,就應修資料選取;正確條文已在輸入裡但被忽略,才需要檢查提示方式、位置安排或模型能力。檢索增強生成提供找資料的一種方式,並不涵蓋所有歷史與權限管理。

實作前可以畫出資料來源、篩選程式、當次輸入與答案的路徑,選幾筆可核對的問題逐段追查。除了答對與否,還要檢查來源是否足夠、是否讀到不必要的私人資料,以及過期資訊能否退出。這些檢查讓團隊知道該改善哪個環節,而不必遇到每次錯誤都更換模型。

對一般使用者,最容易開始的做法是提供明確版本的檔案,只附當前需要的段落,並要求答案列出尚缺資訊。當對話已充滿被放棄的方案,可以另開一份整理過的任務說明,保留決定、限制與來源,再開始下一階段。

上下文問題的追查方向(2026 年 9 月查證)
常見情況要查的環節可採取的處理
引用過期規章版本篩選標示生效日並移除失效來源
知道已上傳卻答不出實際模型輸入確認相關段落有被載入
把待確認寫成已完成狀態整理儲存未決事項與操作證據

  • 生活分享

    世界模型(World Model)是什麼:讓 AI 預測「接下來會怎樣」

    世界模型指 AI 內部用來預測「這樣做之後會怎樣」的模型,但這個詞至少有三種用法:強化學習代理在想像中練習用的環境模型、LeCun 主張預測抽象表示的架構路線,以及能隨操作即時生成畫面的互動環境。內容用示例說明怎麼在想像中規劃,並列出大型語言模型有沒有世界模型的正反研究,附讀新聞時的檢查問題。

  • 生活分享

    視覺語言模型(VLM)是什麼:讓 AI 讀圖片、再用文字回答

    視覺語言模型(VLM)能同時接收圖片與文字,再用文字回答。內容拆解視覺編碼器、連接層與語言模型三段結構,說明 CLIP、Flamingo、LLaVA 三篇論文各補上哪一塊,並和多模態 AI、文字生圖分清楚;也整理它常犯的錯:數錯數量、搞混位置、說出圖裡沒有的東西,附上讀收據時逐行核對的步驟。

  • 生活分享

    溫度(Temperature)是什麼:AI 回答變化程度的取樣參數

    溫度(temperature)是文字生成時調整取樣的參數,讓模型從下一個 token 的機率分布裡抽得更集中或更分散。用假想的台南早餐示例算出低溫與高溫的差別,說明 top-p 的來源和它與 top-k 的差別,並依官方文件與論文指出:調低溫度不代表更準,設成 0 也不保證每次相同,部分模型還不開放調整。

  • 生活分享

    合成資料(Synthetic Data)是什麼:兩種用途、品質控管與模型崩潰

    合成資料是由演算法或模型產生、模仿真實資料特徵的資料,常見用途有兩種:訓練模型,以及在隱私需求下替代真資料。內容依 Self-Instruct、模型崩潰研究(替換與累積資料的差別)與 NIST、ICO 的隱私文件,說明做法、抽查流程,以及它不能保證的事。

最新旅遊情報攻略

資料來源

生活分享