但當系統開始加入 AI 助理，新的問題出現了。
使用者前面才說要查台中門市，下一輪問「那今天還有貨嗎？」系統卻不知道「那」指的是哪一項商品。模型回答得很流暢，查到的卻是昨天的庫存。
站在 .NET 系統架構的角度，我更關心的是：每次呼叫模型之前，應用程式能不能把正確、最新，而且符合權限的資料準備好？
Redis 的 AI 能力，值得從這個問題開始理解。
模型負責理解與生成；應用程式必須負責提供可信的上下文。
先釐清：Redis 的 AI 能力有不同層次
「Redis 接入 AI」很容易讓人以為，只要升級資料庫，就會自動多出一個懂業務的助理。
實際上，可以分成資料檢索與上層服務來看。Vector Sets 提供原生向量集合操作；Redis Query Engine 則能在 Hash、JSON 資料上建立索引，組合向量、全文與結構化條件。兩者的操作方式與適用情境不同。
Redis Iris 則把 Agent Memory、LangCache、Context Retriever 與 Data Integration 組合成上下文服務，涵蓋記憶、語意快取、受治理的資料存取及資料同步。
選型時，我會分別確認資料庫版本、部署方案及服務需求。支援某個向量命令，並不表示整套 Agent 記憶流程已經完成設定。
用餐飲 POS 來看：三種問題，需要三種資料
假設我們正在替連鎖餐飲系統開發 AI 客服。使用者可能問：
| 使用者的問題 | 系統需要的資料 | 我會採用的處理方式 |
|---|---|---|
| 「外帶訂單如何取消？」 | 門市適用的取消規則 | 檢索有效版本的政策文件 |
| 「照我上次的口味推薦」 | 已確認的使用者偏好 | 讀取該使用者的長期記憶 |
| 「我剛才那筆訂單退款了嗎？」 | 該筆訂單最新狀態 | 驗證身分後查詢訂單服務 |
這三題都以自然語言提出，資料來源卻完全不同。
退款規則適合從知識庫找；口味偏好適合從記憶找；退款進度應查詢實際訂單。若把所有問題都丟進同一套向量搜尋，很容易找到「看起來相關、實際上不能作答」的內容。
因此，我會先設計問題分流，再決定 Redis 在各條路徑扮演什麼角色。
向量搜尋：先限定資料範圍，再找語意相近的內容
向量可以協助系統找到用詞不同、意思相近的內容。例如「外帶取消」與「撤銷取餐訂單」，不一定包含相同關鍵字，卻可能指向同一份規則。
如果只需要輕量的相似度查詢，可以評估 Vector Sets；若文件還要搭配門市、分類、日期或其他查詢條件，則可以評估 Query Engine。後者提供向量搜尋與 metadata 過濾，向量索引可依需求選擇 FLAT、HNSW 等演算法。
在多租戶系統中，我會讓後端從已驗證的身分取得租戶範圍，把必要的存取限制帶進檢索流程。不能讓使用者輸入一句「查另一家公司的文件」，就改變查詢權限。
資料範圍正確後，才有討論相似度與排序的意義。
Agent 記憶：保存對話，還要管理事實如何更新
Redis Agent Memory 區分會話與長期記憶。啟用相關功能後，可以在背景摘要較早的對話，並抽取值得保留的事實與偏好，形成可搜尋的長期記錄。
但「存起來」只是起點。
使用者上個月偏好辣味，今天說最近想吃清淡一點，系統該採用哪一筆？他只是替朋友訂餐，這次選擇又該不該成為本人的長期偏好？
我的設計會讓記憶保留來源、時間與適用對象，並提供更正、刪除與失效機制。對會影響實際交易的資訊，還要有明確的確認程序。
此外，重要條件不能只靠向量搜尋「剛好找到」。應用程式必須明確載入的限制，就應作為固定業務條件處理。
語意快取：相似的問法，未必有相同答案
LangCache 的用途，是讓語意相近的請求有機會重用既有回答，減少重複生成。
例如同一門市、同一版本規則下，「外帶怎麼取消？」與「取消外帶的流程是什麼？」可能適合共用答案。
但是「我的退款到了嗎？」與「他的退款到了嗎？」即使語意非常接近，也不能因此共用結果。
我會先定義哪些回答允許快取，再檢查租戶、權限、語言、政策版本與有效期限。即時訂單、庫存與個人交易狀態，則走業務查詢路徑。
衡量成效時，也不只看命中率。錯誤重用答案的比例、政策更新後的失效速度，以及整體回應延遲，都應一起觀察。
放進 ASP.NET Core，責任應該怎麼分？
我會把請求入口設計成以下流程：
驗證使用者身分，取得租戶、門市與資料存取範圍。
判斷問題需要政策文件、個人記憶，還是即時業務資料。
對允許重用的問題檢查語意快取，其他問題直接進入檢索或服務查詢。
將取得的資料連同來源、時間與必要限制，整理成模型上下文。
產生回答；資料不足時，要求補充資訊或說明尚無法確認。
依保存政策更新對話、候選記憶及允許快取的答案。
在程式結構上，我會把知識檢索、記憶存取、快取判斷與訂單查詢拆成不同服務介面，讓 Controller 保持簡單，也方便單獨驗證每個環節。
若涉及取消訂單、退款或修改資料，仍由應用服務驗證權限、狀態轉移與重複請求。模型可以協助理解使用者意圖，交易是否成立則必須由業務規則決定。
這樣一來，未來更換模型或檢索服務時，也不必重寫整套訂單邏輯。
導入前，我會先算清楚兩件事
第一件是記憶體。
以 1,536 維 FLOAT32 向量為例，單筆純向量資料是 1,536 × 4 = 6,144 bytes；一千萬筆約 61.44 GB，還沒計入索引、文件、metadata、副本與其他開銷。
即使採用更低位元表示，也不能直接把純向量的縮小比例，當成整個 Redis 執行個體的節省比例。容量規劃應以實際資料與查詢品質測試為準。
第二件是資料生命週期。
可重建的快取與需要保存的長期記憶，對淘汰、備份及復原有不同要求。我不會因為都能放進 Redis，就直接讓它們共用相同的容量與淘汰策略。是否拆成不同執行個體，要看資料重要性、負載與故障影響。
我會從一個能驗證的小場景開始
第一階段，我會選單一門市的政策問答：整理文件版本，建立檢索，再用一組固定問題檢查答案與來源是否一致。
第二階段，才針對穩定、重複的問法加入語意快取，同時測試「問法相近但答案不同」的反例。
等這些行為可預期後，再加入跨會話偏好與即時訂單工具。每增加一項能力，就驗證它對正確率、延遲與維運成本的影響。
從 .NET 架構師的角度看，Redis 在 AI 時代的價值，是讓我們多了一組管理上下文的工具。真正決定系統品質的，仍是資料來源、權限邊界、更新機制，以及每次回答前的判斷流程。
