為什麼你的 AI 總是「不記得」任何事？
用過 ChatGPT 的人都遇過這個情境：開始新對話，AI 像失憶了一樣，什麼都不記得。你花了半小時解釋公司產品規格，關掉分頁，再開一個對話，又要從頭說起。
這不是 AI 不夠聰明，是預設架構根本沒有長期記憶。Transformer 的 attention 機制只活在單次 context window 裡，session 結束，記憶就跟著消失了。
但現實世界的需求不是這樣的。你需要 AI 記住：上次客戶問了什麼報價、現在網站開發到哪個階段、設計偏好是什麼。而 Memory RAG（記憶檢索增強生成），就是用向量資料庫把長期記憶「焊接」進 AI 架構的實作方式。
Memory RAG 的核心原理
RAG（Retrieval-Augmented Generation）的基本流程是：檢索 → 增強 → 生成。傳統 RAG 從外部文件知識庫檢索，Memory RAG 的差別在於——檢索的對象是「過往對話紀錄」本身。
運作流程如下：
- 記憶編碼：每段對話在結束時被切成 chunk（段落），透過 embedding model（如
text-embedding-3-small）轉成向量，存入向量資料庫。 - 相似度檢索：新對話到來時，把用戶輸入編碼成向量，在資料庫中做 ANN（近似最近鄰）搜尋，找出最相關的歷史記憶。
- 上下文注入：召回的記憶片段以 system prompt 或 injection 的方式傳給 LLM，讓它在回答時能參考「之前發生過什麼」。
關鍵技術細節在於 chunk size 策略：太大會稀釋相關性，太小會斷裂語義。一個常見的做法是保留「對話輪次（turn）」作為基本單位，再根據長度決定是否合併。想知道進階調教技巧可以看讓 AI 記住一切：OpenClaw 知識庫調教與 RAG 進階實戰。
用 OpenClaw + pgvector 實作 Memory RAG
OpenClaw 的 workspace 架構本身就支援記憶持久化。以下是實作路徑：
Step 1：建立記憶向量資料庫
使用 pgvector 擴充 PostgreSQL，在本地端儲存對話向量：
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory_chunks (
id SERIAL PRIMARY KEY,
session_id TEXT NOT NULL,
chunk_text TEXT NOT NULL,
embedding vector(1536),
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX ON memory_chunks USING ivfflat (embedding vector_cosine_ops);
1536 維度適用於 text-embedding-3-small，若使用 OpenAI text-embedding-3-large 則是 3072 維。
Step 2：設定 OpenClaw Memory Skill
在 ~/.openclaw/skills/self-improvement/skills/SKILL.md 中定義記憶行為。關鍵指令包括：
- 記憶寫入時機：每次有意義的任務完成、決策產生、偏好揭露時，都應該寫入。
- 記憶召回觸發：新 session 啟動時，根據用戶輸入 query 向量資料庫，召回最相關的記憶注入 system prompt。
使用 OpenAI embedding API 將文字編碼：
## 三個讓 Memory RAG 真正有效的關鍵設計### 1. 記憶分層（Memory Tiering）import openai import pgdbdef embed_text(text):
response = openai.Embedding.create(
model="text-embedding-3-small",
input=text
)
return response['data'][0]['embedding']
def retrieve_memory(query, top_k=5):
query_vec = embed_text(query)
conn = pgdb.connect(database="openclaw_memory")
cur = conn.cursor()
cur.execute("""
SELECT chunk_text, 1 - (embedding <=> %s) AS similarity
FROM memory_chunks
ORDER BY embedding <=> %s
LIMIT %s
""", (query_vec, query_vec, top_k))
return cur.fetchall()
不是所有記憶都同等重要。建議分三層：
- 即時記憶：存在 session 變數中，壽命=單次對話。
- 短期記憶：當日完成的任務、正在進行的專案，存進 PostgreSQL，TTL=7 天。
- 長期記憶：永久性的用戶偏好、決策歷史、專案背景，存進 pgvector，永久保留。
向量資料庫不會自己刪東西。設定兩種忘記規則：
- 時間衰減：每次召回成功後更新
last_accessed_at，6 個月未召回的記憶標記為「冷儲存」。 - 語義衰減：新記憶與舊記憶 cosine similarity 超過 0.95 時，判定為「已過時」，合併或取代。
向量相似度不是完美信號。建議在召回後多做一層 cross-encoder reranking：用更精確的模型（如 cross-encoder/ms-marco-MiniLM-L-12v2）對候選記憶重新打分，過濾掉「表面相似但語義偏離」的結果。
實戰案例：網站設計公司的 Memory RAG
舉例來說，一家臺中網頁設計公司用 OpenClaw 做客服 AI，Memory RAG 讓 AI 能：
- 記住客戶 A 上次說「要參考 wpw.design 的極簡風格」→ 下次談話自動帶入此偏好。
- 記住客戶 B 詢問過「響應式網站加價多少」→ 業務接手時能看到完整報價歷史。
- 記住設計師回饋「不要用滾動視差」→ 下一個專案自動排除此選項。
這些資訊如果每次都要從頭問，浪費的不只是時間——是客戶感受到的「被理解」程度。
結論：讓 AI 成為真正的同事，而不是每次都重置的實習生
Memory RAG 解決的不是技術問題，是體驗問題。當 AI 能記住對話脈絡，它就不再是「每次都要重新開始」的工具，而是「累積經驗、持續優化」的長期夥伴。
實作上，建議從 pgvector + OpenClaw workspace memory 起步，先把「今日對話」記憶穩定化，再逐步擴展到長期記憶層。別想一次做到完美，先讓 AI 記住「今天聊過什麼」這個基本場景。
## 延伸閱讀
・Speculative Decoding 完整解析：2026 年本地 AI 推論加速的關鍵技術
Memory RAG 的推論速度是體驗瓶頸，Speculative Decoding 可與本地 RAG 系統疊加，大幅提升回應速度
・用 Ollama 打造本地 RAG 搜尋引擎：不用 API key 的企業級知識庫
另一個本地 RAG 建構方式的完整攻略，涵蓋向量資料庫選型、chunk 策略與 embedding 模型優化
・RAG 知識庫建構服務
從企業知識庫評估、架構規劃到落地部署，鍛碼匠提供 RAG 系統的規劃與建構服務，支援本地與雲端混合部署
結語
Memory RAG 解決的不是技術問題，是體驗問題。對於網頁設計公司來說，這意味著：當你替客戶的網站建置 AI 客服，能記住對話脈絡的 AI 和每次都重置的 AI，給訪客的感受是完全不同的。前者讓訪客覺得被認真對待，後者只會不斷重複同樣的問題。把 Memory RAG 的概念實作進網站功能，是小型工作室做出差異化 AI 服務的實際方法。
業主 5 個常見問題 （FAQ）
整理自台灣業主最常問的問題，讓你在開會前先有基本答案：
Q1：為什麼要關心這個主題？
每個產業都有關鍵的技術趨勢，業主了解後可以做更好的技術選擇與預算分配。本文整理的內容對應你可能會面臨的真實決策情境，實際細節依各家專案範圍與技術選型而異，本文不替任何特定解決方案背書。
Q2：花多少時間投入才合理？
技術主題的學習與投入時間依團隊規模與技術成熟度而異。建議業主先做小範圍測試（2-4 週）確認可行性，再決定是否擴大投入。實際時間分配依團隊能力與預算而異。
Q3：該自己來還是委外？
技術能力依團隊而異。如果團隊有熟悉相關技術的工程師，可以自己嘗試；如果沒有，建議找有經驗的顧問協助，避免走錯路浪費時間。實際選擇依團隊能力、預算、時程而異。
Q4：預算要抓多少？
技術主題的預算依規模而異。建議業主先確認：要做什麼（範圍）、做到什麼程度（品質）、多快完成（時程）。這 3 個變數決定預算規模，本文不提供具體數字，實際依各家專案範圍評估。
Q5：做完之後怎麼驗收？
驗收不只是「能不能用」，還要看「效能」「安全」「可維護性」「未來擴充性」。建議合約前先約定驗收標準，避免「做完才發現不是我要的」。
進一步閱讀 （fordigE 站內）
本文主題延伸閱讀見 網頁設計完整決策指南 主索引， 形象網站設計原則 與 SEO 完整策略。技術細節見 網站設計技術趨勢。 詳見 OpenClaw Memory 教學 與 Ollama 本地 RAG 教學 與 LanceDB 向量資料庫文件。
