拼貼上下文是整合編排多個管道的資訊,例如對話歷史、記憶庫、檔案摘要、API 回傳、工具輸出 ... 等,拼貼的目標是為了讓大型語言模型在單次的呼叫中,可以看到一個連貫合理的語境,而非一堆雜亂無章的資訊碎片。
當我們試圖將不同來源的資訊拼貼在一起時,可能會碰到以下問題:
我們會碰到的第一個問題就是每個來源的格式都不盡相同,甚至連寫作風格、標點符號都不一樣。如果直接拼在一起,會讓上下文變得混亂,也會導致模型難以判斷,進而影響回答品質。
所以我們想要追求的,會是一套標準化的預處理流程,在拼貼之前將所有資訊轉換成一致的格式,藉此降低模型的負擔
另外一個常發生的狀況,就是不同來源可能包含相同的資訊,甚至數據彼此矛盾,例如市場報告與新聞稿對同一產品的銷售額出現差異。如果不處理,模型可能會在生成時混用這些數據,導致輸出缺乏一致性。那麼,我們是否應該在拼貼前建立一個比對與去重的機制,或至少讓模型在輸出時標註衝突點,確保使用者知道哪些資訊不一致,讓使用者自行判斷
當資訊來源過多時,重要的背景容易被次要內容掩蓋。模型並不知道哪些片段是關鍵、哪些只是輔助,結果可能導致輸出偏離重點。這也促使我們去思考,是否應在拼貼前建立優先級排序機制,將最重要的片段放在前面,並在 Prompt 中明確標註其權重,幫助模型分清層次
當上下文過長時,模型的注意力會被分散,重要資訊反而不容易被捕捉到。即使上下文拼貼完整,也可能出現關鍵訊息被淹沒的情況。我們可以在拼貼流程中加入濃縮與摘要的步驟,將龐雜資訊壓縮成精華片段,再與其他來源合併
首先,給每一段不同來源的資訊,附上明確的標籤識別,例如 [檔案摘要]
、[記憶庫]
、[API回傳]
,並用分隔符號 (---
或 ###
) 將他們區隔開來
[檔案摘要]: 本文探討市場趨"勢 A、B、C。
---
[記憶庫]: 使用者偏好:深夜工作、圖表形式的摘要。
---
[API 回傳]: {"currency_index": 1.12, "inflation_rate": "3.4%"}
這樣能避免模型將不同來源的內容誤認為是連續的,也能讓模型輕易判斷資訊的來源。
再來可以將上下文切片處理,針對每一片段生成摘要或關鍵句,然後再把這些濃縮後的片段拼回去。
例如,假設你有一份 8000 字的市場研究報告,想用它來回答「智慧手錶市場的未來趨勢」這個問題,我們可以先將報告切成 100 ~ 200 字的小段落,大約切成 40 段,再針對每段用提示詞生成 1 ~ 2 句關鍵摘要,例如:
請將以下段落壓縮成一句不超過 30 字的重點句,保留最具資訊量的數字或結論。
這樣每段的摘要會變成:
- [段落 1 摘要] 2024 年智慧穿戴設備銷量年增 12%。
- [段落 7 摘要] 亞洲市場增長率高於歐美,特別是印度。
- [段落 22 摘要] 消費者最在意續航力與健康監測功能。
再根據我們的查詢內容 (例:智慧手錶趨勢),篩選出與智慧手錶直接相關的 8 個摘要,其他與穿戴耳機或 AR 裝置的資訊就不需要了。
最後再將這些摘要重新拼貼進上下文,形成一個乾淨的知識片段:
[市場研究報告濃縮版]
- 2024 年智慧手錶銷量年增 12%。
- 亞洲市場成長尤其顯著,印度是主力市場。
- 消費者關注續航力與健康監測功能。
- 歐洲市場趨勢趨於飽和,但高階手錶仍有利基。
最後的最後,把濃縮後的拼貼上下文丟進模型,讓它基於這些摘要來產生回答。
某些情況下,如果來源數量龐大、品質參差不齊,直接拼貼會讓上下文過於雜亂,這時候我們可以把拼貼分成多個步驟:選擇 → 重寫 → 整合。
假設你需要生成一份 公司競爭策略分析,資料來源包含:
流程可以這樣設計:
先透過 filter 或人工挑選,把和公司 A 競爭策略最相關的段落抓出來,例如白皮書裡的 5 個段落加上新聞稿的重點句:
請從以下文件段落中,挑選與「公司 A 未來競爭策略」最相關的三段,並說明理由。
把挑出來的段落進一步重寫成清晰的摘要,這部分是為了清除寫作風格或格式上的不同,例如:
把重寫後的摘要拼貼成一個乾淨、結構化的上下文:
[公司 A 策略資訊濃縮版]
- 2025 年計畫強化供應鏈整合
- 近期宣布與半導體製造商合作,專注 AI 晶片市場
- 亞洲市場市佔率達 30%
最後把這份濃縮過的上下文交給模型,請它輸出策略分析報告:
基於以上 [公司 A 策略資訊濃縮版],請撰寫一份 500 字的競爭策略分析,涵蓋:
- 未來市場定位
- 主要挑戰
- 可能的對手反應
這樣可以讓每個步驟都有明確的輸入與輸出,也讓最終拼貼的上下文更乾淨、更有針對性。
即使上下文拼貼完成,也不代表它一定能在模型裡發揮最佳效果。資料來源之間可能有矛盾、不相關,或者模型在生成時忽略了某些重要內容。這時候就需要建立一個 驗證與反饋迴路,讓拼貼效果不斷改進。
當我們生成好拼貼內容後,可以請模型檢查輸出的內容是否完整、是否引用了所有來源:
請檢查以上生成的報告:
- 是否有引用三個來源?
- 是否有出現矛盾數據?
- 是否有忽略重要資訊?
請回報檢查結果並提出改進建議。
如果檢查結果顯示忽略了使用者記憶的偏好或白皮書與 API 數據有數字矛盾**... 等回饋,就把這些回應加入下一次的提示詞中,要求模型修正:
請根據檢查結果重新生成報告,
- 加入使用者偏好資訊
- 解釋白皮書與 API 數據矛盾的原因
- 最終報告需在 450 字以內
透過「生成 → 驗證 → 修正 → 再生成」流程,就能形成一個反饋迴路,持續優化拼貼上下文的效果
我們介紹了多種拼貼上下文的方法,,你會發現底層的精神都是一樣的,都是希望再多個資料來源,在有限的上下文中,變得有條理也可追溯。特別注意的是,拼貼上下文不只是單純把資料放在一起那麼簡單,而是要設計一套預處理、整合與驗證的機制,才能真正地發揮作用。