Tablestore：架構與技術選型

系統架構

記憶儲存服務採用全託管 Serverless 架構，使用者通過 API 與服務互動，底層資源由平台自動管理。資料流轉過程如下：

1. 調用 AddMemories 介面，傳入對話訊息（messages）或純文字（text)。

2. 系統將原始訊息儲存為短期記憶。

3. 系統從訊息中提取可檢索的長期記憶單元，並持久化儲存到Table Store。

4. 調用 SearchMemories 介面時，服務結合語義檢索和文本檢索能力，並支援 Rerank 排序，返回相關長期記憶。

資料模型

記憶庫的資料按以下實體組織。

記憶寫入

記憶服務支援以下兩種方式寫入記憶：

• 對話訊息寫入：通過 AddMemories 介面傳入 messages 數組。服務儲存原始訊息為短期記憶，並從中提取長期記憶單元。

• 文本寫入：通過 AddMemories 介面傳入 text 欄位，直接提交純文字內容。服務從文本中提取可檢索的長期記憶。

寫入時需指定 Scope 資訊，其中 appId 必填，tenantId、agentId、runId 為空白時自動補為 __default__。寫入不允許使用萬用字元 *。

記憶檢索

SearchMemories 支援使用自然語言檢索長期記憶。服務結合語義檢索和文本檢索能力，並支援 Rerank 排序，預設啟用 Rerank。

檢索時 appId 和 tenantId 為必要欄位，agentId 和 runId 可使用萬用字元 * 擴大檢索範圍。

中繼資料

長期記憶支援附加中繼資料（metadata)。中繼資料可用於儲存業務自訂資訊，例如記憶來源、標籤和優先順序等。中繼資料隨記憶單元一起儲存，檢索結果中會返回對應的中繼資料欄位。

請求審計

服務記錄記憶程式庫要求，可通過 ListMemoryStoreRequests 查詢請求日誌。審計記錄包含操作類型、響應狀態、延遲和失敗原因等欄位，適用於排查寫入、檢索和管理操作中的問題。

Scope 多租戶

Scope 用於表示記憶資料的歸屬和隔離邊界。記憶服務使用 appId / tenantId / agentId / runId 四級 Scope。

Scope 的層級為：

appId > tenantId > agentId > runId

核心規則：

• 寫入時，appId 必填，其他欄位為空白時補為 __default__。寫入不允許使用萬用字元 *。

• 檢索長期記憶時，appId 和 tenantId 必填，agentId 和 runId 可使用 * 實現跨 Agent 或跨會話檢索。

• 查詢短期記憶時，四個欄位均為必填且不允許萬用字元。

檢索樣本：

• agentId=""、runId=""：檢索該租戶下所有 Agent、所有會話的記憶。

• agentId="sales_assistant"、runId="*"：檢索該租戶下指定 Agent 的所有會話記憶。

適用性評估

推薦使用的情境：

• 智能客服、銷售助手、企業助手等對話型應用。

• 需要跨會話記住使用者偏好、配置和歷史選擇的個人助理。

• 多 Agent 協作情境下的共用記憶管理。

• 需要保留原始會話記錄並支援審計排查的 Agent 應用。

• 需要在大規模租戶和大量記憶資料下保持穩定檢索效能的生產系統。

需要評估的情境：

• 對記憶寫入即時性要求極高的情境（記憶提取是非同步過程，存在處理延遲）。

• 需要自訂記憶提取策略的情境（當前為系統自動提取）。

不推薦的情境：

• 純結構化資料查詢（建議使用Table Store寬表模型或關係型資料庫）。

• 僅需簡單的上下文視窗管理、不需要持久化記憶（可直接使用 LLM 的上下文視窗）。

效能評測結果

從檢索準確率、檢索延時和儲存規模三個維度對錶格儲存記憶服務進行了評測，並與業界主流記憶方案 Mem0 進行了對比。

上述資料用於展示服務能力邊界，實際效果會受到資料規模、查詢方式、網路環境、模型配置和業務資料分布影響。以下是各維度詳細評測。