昨天我們透過 Java 成功發起了 API 請求，並將 AI 回傳的 JSON 完美反序列化為系統物件。然而，昨天的實作是一個「無狀態 (Stateless)」的單次任務。

在真實的企業級應用中，使用者通常期望 AI 助手能記住前言後語，進行多輪對話。但殘酷的現實是：大語言模型 API 本質上是沒有記憶的「金魚腦」。

1. 揭開記憶的錯覺：Stateless API
平時我們在使用 ChatGPT 或 Gemini 網頁版時，之所以覺得 AI 有記憶，是因為前端工程師在背後幫我們做足了苦工。模型本身不會儲存你上一個 Request 的內容，每一次呼叫對它來說都是一個全新的宇宙。

要在 API 層面實現「記憶」，我們必須實作 Context Engineering（上下文工程）。也就是在每一次發送請求時，我們必須手動將歷史對話紀錄打包成一個陣列（例如 Java 中的 List），連同最新的問題一起塞進 Payload 傳送給模型。

2. Token 陷阱：無止盡增長的帳單
既然只要把對話紀錄一直 append 上去就好，那工程上有什麼難度？答案在於 Token 限制與成本。

• Token 是 AI 閱讀文本的基本單位（1 個英文字大約等於 1.3 個 Token，中文則更消耗 Token）。

• Context Window（上下文視窗）： 每個模型都有單次能接收的最大 Token 數限制。一旦對話紀錄超過這個長度，API 就會直接報錯 (Out of Context)。

計費模式： API 是依照「輸入 + 輸出」的 Token 數量計費。這意味著在第 10 輪對話時，你必須為前 9 輪已經算過錢的對話「再付一次費」。如果不加以控管，系統的營運成本將會呈指數型暴增。

3. 軟體工程師的對策：記憶管理機制
為了解決這個系統瓶頸，我們通常會在後端實作以下幾種記憶管理策略：

• 滑動視窗 (Sliding Window)： 像 Queue 一樣，只保留最近 N 輪的對話（例如保留最新的 5 個 Message），較舊的對話直接從陣列中丟棄。

• 摘要壓縮 (Summarization)： 當 Token 數量達到警戒值時，在背景發起一個輕量級模型 (SLM) 的請求，請 AI 把過去的長篇大論濃縮成 100 字的精要，再將這個「摘要」作為系統背景提示詞 (System Prompt) 傳給主模型。

透過上述的 Context Engineering，我們勉強解決了「對話記憶」的問題。但這衍伸出了一個更巨大的挑戰。

如果我們今天不是要 AI 記住日常對話，而是要它閱讀我們企業內部高達 500 頁的技術文件或醫療指引，然後回答問題呢？

把整本 PDF 塞進 Prompt 裡？雖然現在少數模型（如 Gemini 1.5 Pro）具備超大上下文視窗，但每一次發問都要付出極端昂貴的 Token 成本，這在系統架構設計上是絕對不合格的。

既然不能「全部塞給它看」，那我們可不可以「只把相關的那一頁找出來，再餵給 AI ？」

這就是目前業界最主流的解法。明天 [Day 08]，我們將正式跨入第二階段：解構 RAG（檢索增強生成），看工程師如何從根本上消除 AI 幻覺