記憶管理不一定要外包給向量資料庫
LLM 的上下文理解已經強到可以自己管理記憶，不一定要依賴向量資料庫和 embeddings。
問題的真實面貌
過去幾年，RAG 的標準做法是：把文件切碎、轉成 embeddings、丟進向量資料庫、再用相似度檢索。這套流程有個隱藏假設——LLM 本身不夠聰明，所以要靠外部系統幫它管理記憶。
但這個假設現在值得重新檢視。
LLM 內建的記憶管理能力
新一代 LLM 已經有相當強的上下文理解和信息組織能力。如果你給它清楚的結構化資訊，它可以自己判斷什麼重要、什麼可以忽略、什麼時候應該回顧前文。
這意味著：
- 不一定要先轉 embeddings。直接用文本，讓模型自己理解語義。
- 不一定要複雜的檢索策略。結構清晰的上下文往往比「找最相似的 top-k」更有效。
- 不一定要向量資料庫。簡單的文本儲存 + 模型的推理能力，有時候就夠了。
什麼時候還是需要向量資料庫
這不是說向量資料庫沒用。當你面對的是：
- 超大規模語料（百萬級以上文件），模型一次放不下
- 需要毫秒級檢索的線上系統
- 語義相似但表述完全不同的內容要聚在一起
向量資料庫還是更經濟的選擇。
但如果你的資料量適中、允許更長的推理時間、或者檢索精度比速度更重要，直接用 LLM 的記憶管理能力可能更簡單。
實際的權衡
這是一個架構選擇，而不是技術優劣。
用向量資料庫的好處是確定性強、可控、成熟。壞處是多了一層系統複雜度，embedding 模型的品質也會成為瓶頸。
用 LLM 內建記憶的好處是少一套基礎設施、端到端更簡潔。壞處是推理成本高、不適合超大規模場景。
我的判斷是：先從模型內建記憶開始，確認這套方案能不能解決你的問題。只有當瓶頸真的出現了——檢索太慢、成本太高、資料太多——再加上向量資料庫。反過來設計會浪費時間。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。