ساخت حافظه بلندمدت ایجنت با PostgreSQL و Embedding

ایجنتی که هر بار سؤال‌های تکراری می‌پرسد، حتی با یک مدل قوی تجربه خوبی نمی‌سازد. راه‌حل هم فرستادن کل تاریخچه برای هر درخواست نیست: این کار هزینه را بالا می‌برد و اطلاعات قدیمی یا نامرتبط را وارد تصمیم جدید می‌کند. حافظه بلندمدت یعنی انتخاب آگاهانه اطلاعاتی که باید باقی بمانند، بازیابی محدود آن‌ها و امکان اصلاح یا حذفشان.

در این آموزش یک طراحی عملی با PostgreSQL، Embedding و API مدل می‌سازیم. این معماری را خود برنامه شما پیاده می‌کند؛ API هوش مصنوعی پاستا به‌تنهایی حافظه خودکار برای کاربران برنامه ایجاد نمی‌کند. پاستا می‌تواند مسیر دسترسی به مدل و Embedding و اجرای برنامه را فراهم کند، اما سیاست داده، دسترسی و نگهداری بر عهده محصول شماست.

حافظه ایجنت با تاریخچه چت و RAG چه تفاوتی دارد؟

تاریخچه چت، توالی پیام‌های یک گفتگوست. RAG معمولاً اطلاعات را از مجموعه اسناد بازیابی می‌کند. حافظه کاربر می‌تواند ترجیح زبان، تصمیم تأییدشده یا خلاصه یک کار ادامه‌دار باشد. این سه می‌توانند کنار هم استفاده شوند، ولی نباید همه را در یک مخزن بدون نوع، تاریخ و مالک ذخیره کرد.

مثلاً «پاسخ‌ها کوتاه باشند» یک ترجیح قابل تغییر است. «سفارش ارسال شد» یک وضعیت تجاری است و باید از سامانه سفارش خوانده شود، نه از یادآوری احتمالی مدل. «رمز من این است» نیز چیزی نیست که برای راحتی گفتگو وارد حافظه برداری کنیم. از ابتدا مشخص کنید چه نوع داده‌ای قابل ذخیره است و چه نوع داده‌ای باید رد شود.

معماری پیشنهادی: ثبت، بازیابی و فراموشی

مسیر ثبت از پیام شروع می‌شود، اما مستقیماً به دیتابیس نمی‌رسد. ابتدا برنامه یک نامزد حافظه استخراج می‌کند، نوع و حساسیت آن را می‌سنجد و در صورت نیاز تأیید کاربر می‌گیرد. سپس متن کوتاه، منبع، زمان انقضا و بردار آن ذخیره می‌شوند. مسیر بازیابی نیز فقط در محدوده همان کاربر و سازمان جست‌وجو می‌کند.

در مسیر حذف، فقط متن نمایشی را پاک نکنید. بردار، cache و نسخه‌های مشتق‌شده نیز باید مطابق سیاست نگهداری مدیریت شوند. درباره ماندگاری در نسخه پشتیبان شفاف باشید. قابلیت «این را فراموش کن» زمانی معنی دارد که درخواست کاربر در لایه داده اثر قابل بررسی داشته باشد، نه اینکه صرفاً یک پاسخ مؤدبانه از مدل تولید شود.

طرح جدول و انتخاب ابعاد بردار

نمونه زیر یک طرح آموزشی است. عدد ۱۵۳۶ نمونه است و باید با ابعاد خروجی مدل انتخابی شما هماهنگ باشد. نصب افزونه vector به دسترسی دیتابیس و پشتیبانی محیط بستگی دارد؛ وجود PostgreSQL به‌تنهایی به معنی فعال‌بودن آن نیست. قبل از انتخاب سرویس، امکان استفاده از افزونه را بررسی کنید.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE agent_memories (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  user_id uuid NOT NULL,
  kind text NOT NULL CHECK (kind IN ('preference', 'task_summary')),
  content text NOT NULL CHECK (length(content) BETWEEN 1 AND 2000),
  source_id text NOT NULL,
  embedding_model text NOT NULL,
  embedding vector(1536) NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now(),
  expires_at timestamptz NOT NULL,
  UNIQUE (tenant_id, user_id, source_id)
);
CREATE INDEX agent_memories_owner
  ON agent_memories (tenant_id, user_id);

کلید source_id برای جلوگیری از ثبت دوباره همان رویداد است، نه حذف همه متن‌های مشابه. شناسه‌ها را در سرور تولید کنید. برای تغییر ترجیح، رکورد قبلی را طبق سیاست مشخص جایگزین یا منقضی کنید. اگر دو حافظه متناقض پیدا شد، نسخه جدیدتر به‌تنهایی همیشه معتبرتر نیست؛ منبع و تأیید کاربر را هم در تصمیم لحاظ کنید.