پایگاه‌داده‌های برداری: بازیابی تاریخچهٔ کاربر در کمتر از ۶۰ میلی‌ثانیه

«پاسخ‌ها عالی است، اما ما را به یاد نمی‌آورد.» این نقد تند و صریح از سوی یک شرکت لجستیکی در دبی مطرح شد؛ زمانی که عامل پشتیبانی مشتریان آن‌ها دچار یک شکست بحرانی شد: سیستم به تمام سوالات به طور کامل پاسخ می‌داد، اما به محض بسته شدن هر چت، تمام اطلاعات مشتری را فراموش می‌کرد. این «حافظه ماهی قرمز» یک نقص سیستماتیک در نحوه مدیریت وضعیت (State) توسط اکثر عامل‌ها است، جایی که پنجره متنی (Context Window) بین هر جلسه پاک می‌شود. در نتیجه، مشتریان مجبور بودند جزئیات یک مشکل مربوط به سیاست‌های تحویل را که قبلاً در روز سه‌شنبه هفته گذشته مطرح کرده بودند، دوباره توضیح دهند و عامل نیز طوری پاسخ می‌داد که انگار هرگز نام آن‌ها را نشنیده است.

به گزارش یک راهنمای فنی که در تاریخ ۱۵ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، راهکار این مشکل نه در استفاده از مدل‌های بزرگ‌تر و نه در نوشتن پرامپت‌های طولانی‌تر، بلکه در ایجاد یک لایه اختصاصی از پایگاه‌داده برداری (Vector Database) است. در طول یک ماه، بازسازی لایه حافظه این عامل باعث شد سیستمی که در هر جلسه باید خودش را از اول معرفی می‌کرد، به عاملی تبدیل شود که تاریخچه سفارشات، روش تماس ترجیحی و تیکت‌های گذشته مشتری را در کمتر از ۶۰ میلی‌ثانیه در هر جست‌وجو بازیابی می‌کند.

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

سه لایه حافظه در عامل‌های هوش مصنوعی

برای ساخت یک عامل آماده‌ی تولید (Production-ready)، باید حافظه را به سه لایه معماری مجزا تقسیم کنید. ترکیب این لایه‌ها دقیقاً همان جایی است که مهندسان سیستم‌هایی می‌سازند که هم گران هستند و هم غیرقابل‌اعتماد. بهترین مدل ذهنی برای درک این موضوع، مقایسه آن با سخت‌افزار کامپیوتر است: حافظه کاری مانند کش CPU، حافظه بلندمدت مانند دیسک سخت و حافظه اپیزودیک مانند لاگ‌های حسابرسی (Audit Log) است.

• حافظه کاری (Working Memory): این لایه همان توجه کوتاه‌مدت عامل است. این حافظه شامل پنجره متنی فعلی، پرامپت‌های سیستمی، گفتگوهای جاری تا این لحظه، وضعیت فعلی وظیفه (Task State) و خروجی‌های اخیر ابزارهاست. این لایه مانند کش CPU عمل می‌کند اما توسط سقف توکن‌های مدل محدود شده است. هزینه این حافظه با هر توکنی که به آن می‌افزایید رشد می‌کند و تنها نوع حافظه‌ای است که هر عاملی به طور پیش‌فرض دارد.
• حافظه بلندمدت (Long-Term Memory): این لایه در واقع «دیسک» عامل است. هر چیزی که عامل می‌داند و در پنجره متنی فعلی جای نمی‌گیرد، اینجا ذخیره می‌شود؛ مواردی مانند تاریخچه کامل سفارشات یک مشتری، متن کامل دفترچه سیاست‌های شرکت یا تمام تیکت‌هایی که کاربر در گذشته ثبت کرده است. چون این حجم از داده برای قرار گرفتن در یک پرامپت بیش از حد زیاد است، خارج از مدل زندگی می‌کند و فقط در صورت نیاز بازیابی می‌شود. این همان لایه‌ای است که رفتار عامل را در طول جلسات مختلف تغییر می‌دهد.
• حافظه اپیزودیک (Episodic Memory): این لایه به عنوان یک لاگ حسابرسی از کارهایی که عامل در اجراهای گذشته واقعاً انجام داده عمل می‌کند؛ اقداماتی که برداشته، اشتباهاتی که مرتکب شده و نتایجی که حاصل شده است. در استقرارهای جدی، این یک لاگ قابل پرس‌وجو است که برای هوشمندتر کردن اجراهای آینده استفاده می‌شود. در واقع، این لایه یک پایگاه‌داده با قابلیت‌های پرس‌وجوی سطح بالا است.

چرا جست‌وجوی برداری استاندارد شده است؟

پایگاه‌داده‌های برداری جنگ حافظه را بردند زیرا معنای مفهومی (Semantic Meaning) را بر تطبیق کلمات کلیدی ترجیح می‌دهند. جست‌وجوی سنتی زمانی شکست می‌خورد که کاربر بگوید «بسته‌ام دیر رسید» اما در مستندات عبارت «تأخیر در ارسال» آمده باشد، زیرا دایره لغات این دو متفاوت است.

جست‌وجوی برداری مفهومی چندین دهه پیشینه در دنیای بازیابی اطلاعات و سیستم‌های توصیه دارد. مشکل اصلی که این فناوری حل می‌کند، یافتن موارد مشابه (مانند مقالات خبری یا محصولات) بر اساس پرس‌وجوی کاربر است. در بازه زمانی ۲۰۱۷ تا ۲۰۱۹، سرویس‌های مقیاس‌بزرگ ثابت کردند که تبدیل محتوا به بردارهای با ابعاد بالا و انجام جست‌وجوی «نزدیک‌ترین همسایه تقریبی» (ANN)، شباهت‌های معنایی بسیار بیشتری را نسبت به کلمات کلیدی بازیابی می‌کند.

الگوریتم‌هایی مانند HNSW (Hierarchical Navigable Small World) و IVF برای سریع کردن این فرآیند ساخته شدند. به طور خاص، HNSW می‌تواند میلیون‌ها بردار را با تأخیر تک‌رقمی (میلی‌ثانیه) روی یک ماشین واحد سرو کند، و به همین دلیل است که همچنان نوع ایندکس پیش‌فرض در اکثر ذخیره‌سازهای برداری است.

تجاری شدن مدل‌های برداری (Embedding Models) — مانند text-embedding-3-small شرکت OpenAI — آنچه را که زمانی یک پروژه تحقیقاتی بود به یک فراخوانی ساده کتابخانه تبدیل کرده است. ناگهان، هر متنی با یک فراخوانی API قابل تبدیل به بردار شد. یک پایگاه‌داده برداری به عامل این امکان می‌دهد که خاطرات مرتبط را از طریق «معنا» پیدا کند؛ برای مثال، می‌تواند عبارت «بسته‌ام گیر کرده» را به شکایت مربوط به تأخیر گمرکی که دو هفته پیش ثبت شده مرتبط کند، حتی اگر هیچ‌کدام از این دو عبارت دقیقاً با هم مطابقت نداشته باشند.

پشته حافظه در محیط تولید

پیاده‌سازی این ساختار نیازمند چهار جزء متحرک است. معماری از یک جریان خاص پیروی می‌کند: embed(chunk) ──▶ vector_db.upsert(id, vector, metadata) و در هنگام پاسخ: user question ──▶ embed(question) ──▶ vector_db.search(top_k) ──▶ context.

مدل‌های برداری (Embedding Models)

• OpenAI text-embedding-3-small: تا ۱۵۳۶ بُعد را ارائه می‌دهد (که تا ۵۱۲ بُعد قابل تنظیم است) و هزینه آن تقریباً ۰.۰۲ دلار به ازای هر میلیون توکن است.
• گزینه‌های متن‌باز: مدل‌هایی مانند bge-small یا all-MiniLM-L6-v2 دارای ۳۸۴ بُعد هستند و به صورت رایگان روی سخت‌افزار محلی اجرا می‌شوند.
• توازن‌ها (Trade-offs): تعداد ابعاد، توازنی بین کیفیت، هزینه و اندازه ایندکس است. تعداد ۷۶۸ بُعد به عنوان یک پیش‌فرض منطقی برای محیط تولید در نظر گرفته می‌شود.

انتخاب پایگاه‌داده برداری (Vector Store Selection)

• pgvector: یک افزونه برای Postgres است. این گزینه برای ۹۰٪ کارهای تولیدی پیش‌فرض است زیرا اجازه می‌دهد بردارها در کنار داده‌های رابطه‌ای (Relational) زندگی کنند. این ابزار تنها به یک دستور CREATE EXTENSION نیاز دارد. با ایندکس HNSW، جست‌وجوی top-k در یک میلیون بردار روی یک نمونه مناسب، زیر ۱۰ میلی‌ثانیه باقی می‌ماند.
• Qdrant: یک پایگاه‌داده مستقل با APIهای REST و gRPC است. این سیستم دارای قابلیت فیلترینگ داخلی در جست‌وجو است و تجربه کاربری آسانی دارد. زمانی که پروژه از ظرفیت pgvector فراتر می‌رود یا به فیلترینگ متادیتای سنگین نیاز دارد، Qdrant انتخاب ترجیحی است.
• Chroma: سریع‌ترین گزینه برای نمونه‌های اولیه (Prototypes) و نوت‌بوک‌ها است زیرا با چند خط پایتون در داخل فرآیند (In-process) اجرا می‌شود، هرچند برای مقیاس‌های جدی توصیه نمی‌شود.

تکه‌بندی و متادیتا (Chunking and Metadata)

• استراتژی تکه‌بندی: اسناد طولانی باید قبل از تبدیل به بردار، تقسیم شوند. نقطه شروع توصیه شده، تکه‌هایی بین ۵۰۰ تا ۸۰۰ کاراکتر با هم‌پوشانی (Overlap) ۵۰ تا ۱۰۰ کاراکتر است. قانون این است که تکه‌ها باید «به اندازه یک ایده» باشند، زیرا عامل دقیقاً همان چیزی را می‌خواند که توسط سیستم بازیابی بازگردانده شده است، نه کل سند را.
• متادیتا: ذخیره منبع، برچسب زمانی (Timestamp) و تگ‌های کنترل دسترسی غیرقابل مذاکره است. فیلتر کردن متادیتا تنها راه تضمین حریم خصوصی هر کاربر است (مثلاً: «فقط تیکت‌های این مشتری خاص را بازیابی کن») و تضمین می‌کند که فقط سیاست‌های جاری بازیابی شوند. بدون این مورد، نمی‌توان محصولی ساخت که الزامات اولیه حریم خصوصی را برآورده کند.

پیاده‌سازی عملی (Python)

برای پیاده‌سازی این سیستم با استفاده از pgvector، طرح (Schema) نیازمند جدولی با ستون VECTOR(1536) و یک ایندکس HNSW با استفاده از vector_cosine_ops است.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE agent_memory (
    id BIGSERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding VECTOR(1536),
    user_id TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX ON agent_memory USING hnsw (embedding vector_cosine_ops);

منطق برنامه شامل یک تابع remember برای درج یا به‌روزرسانی (Upsert) بردارها و یک تابع recall است که از عملگر <=> برای محاسبه فاصله کسینوسی جهت یافتن نتایج top-k برای یک user_id خاص استفاده می‌کند.

در حلقه اجرای عامل، سیستم ابتدا بستر (Context) را بازیابی کرده و سپس تعامل را دوباره در حافظه می‌نویسد: remember(user_id, f"User asked: {message} | We answered: {answer}"). این کار تضمین می‌کند که دفعه بعد که مشتری بازمی‌گردد، عامل از قبل او را می‌شناسد زیرا عملیات recall در هر نوبت گفتگو اجرا می‌شود.

خطاهای رایج در محیط تولید

افزودن لایه حافظه ریسک‌های جدیدی ایجاد می‌کند که می‌تواند ساعت‌ها زمان عیب‌یابی (Debugging) ببرد. «حافظه منقضی شده» (Stale Memory) خطرناک‌ترین مورد است؛ اگر یک سیاست تغییر کند اما بردار قدیمی در دیتابیس باقی بماند، عامل با اطمینان کامل به اطلاعات قدیمی استناد می‌کند. راهکار این است که یک چرخه عمر با فیلد expires_at یا تگ‌های نسخه در متادیتا پیاده کنید و در زمان پرس‌وجو روی آن‌ها فیلتر بگذارید.

سایر نقاط ضعف بحرانی عبارت‌اند از:

• تکه‌بندی بد: من یک بار قراردادها را در تکه‌های ۴۰۰۰ کاراکتری تقسیم کردم تا تعداد فراخوانی‌های Embedding را کاهش دهم، و نتیجه این شد که عامل از روی نیمی از یک بند پاسخ می‌داد. کیفیت بازیابی دقیقاً از مرزهای تکه‌بندی شروع و به آن ختم می‌شود.
• شباهت کسینوسی کورکورانه: جست‌وجوی برداری متن «مشابه» را می‌یابد، نه لزوماً متن «درست». یک پرس‌وجو درباره بازپرداخت وجه ممکن است هر سیاست بازپرداختی که تا به حال نوشته شده را بازیابی کند. این موضوع نیازمند جست‌وجوی ترکیبی (Hybrid Search) — ترکیب شباهت برداری با تطبیق کلمات کلیدی BM25 — و یک مرحله بازرتبه‌بندی (Re-ranking) روی ۲۰ نتیجه برتر قبل از ورود به پرامپت است.
• سرریز بستر (Context Overflow): بازیابی تکه‌های زیاد (مثلاً پنج تکه ۸۰۰ کاراکتری در هر نوبت) می‌تواند به طور نامحسوس بودجه توکن‌ها را مصرف کرده و حافظه کاری عامل را اشغال کند. بهتر است تکه‌ها را به ۸۰۰ کاراکتر محدود کرده و فقط ۳ تا ۵ مورد برتر را بازیابی کنید.
• پوسیدگی خاموش کیفیت: هیچ تابع زیان (Loss Function) داخلی برای بازیابی وجود ندارد. توسعه‌دهندگان باید یک مجموعه ارزیابی شامل ۵۰ تا ۱۰۰ پرس‌وجوی واقعی را برای رصد معیارهای Recall@k نگه دارند، زیرا این عدد سریع‌تر از حد انتظار افت می‌کند.
• افزایش هزینه و تأخیر: در حالی که تبدیل به بردار ارزان است، هر بازیابی یک فراخوانی شبکه و یک فراخوانی Embedding به بودجه تأخیر (Latency) اضافه می‌کند. این مقدار باید بسیار کمتر از هزینه زمانی فراخوانی خود LLM باشد.
• حریم خصوصی و نگهداری: حافظه دائمی برای هر کاربر به معنای ذخیره داده‌های شخصی است. سیستم‌ها باید شامل محدودسازی بر اساس user_id، سیاست نگهداری داده‌ها و قابلیت حذف حافظه کاربر در صورت درخواست باشند تا الزامات رگولاتورها برآورده شود. این قابلیت‌ها را قبل از اینکه از شما خواسته شود، بسازید. با این حال، باید به یاد داشت که حافظه تنها یک ویژگی دیتابیسی نیست، بلکه یک پروتکل اعتماد است؛ در تحلیل‌های ما درباره مسموم‌سازی حافظه اشاره شد که چگونه داده‌های مخرب می‌توانند اعتماد به عامل را تخریب کنند.

چه زمانی از پایگاه‌داده برداری دوری کنیم؟

هر عاملی به یک ذخیره‌ساز برداری نیاز ندارد. در سناریوهای زیر از آن‌ها دوری کنید:

• پایگاه‌های دانش کوچک: اگر یک FAQ با ۳۰ مورد یا مجموعه‌ای ثابت از سیاست‌ها در پرامپت سیستمی جا می‌شود، دیتابیس فقط تأخیر و احتمال خطا (Drift) را افزایش می‌دهد. بدون فراخوانی Embedding، بدون ایندکس، بدون خطا.
• نیازهای رابطه‌ای دقیق: سوالاتی مانند «کاربر X ماه گذشته چند سفارش ثبت کرد؟» نیازمند یک پرس‌وجوی SQL برای Joinها و تجمیع‌های (Aggregates) دقیق هستند. جست‌وجوی برداری اغلب پاسخی «مشابه» می‌دهد که از نظر ریاضی غلط است.
• الزامات تازگی بالا (High Freshness): اگر داده‌ها باید تغییرات ۵ ثانیه اخیر را منعکس کنند، یک ایندکس برداری که شبانه بازسازی می‌شود، بسیار کند است. در این حالت مستقیماً از منبع حقیقت (Source of Truth) داده‌ها را بازیابی کنید.
• واژگان ثابت: اگر کاربران و اسناد همیشه از عبارات یکسانی استفاده می‌کنند، جست‌وجوی کلمات کلیدی ۹۵٪ ارزش را با کسری از هزینه عملیاتی فراهم می‌کند.

قانون تصمیم‌گیری ساده است: زمانی به سراغ پایگاه‌داده برداری بروید که یک سوال با عبارات مختلفی پرسیده شود و حجم بدنه پاسخ‌ها برای قرار گرفتن در پرامپت بیش از حد بزرگ باشد.

چک‌لیست متخصصین

قبل از اینکه یک عامل را «دارای حافظه» بنامید، موارد زیر را تأیید کنید:

• لایه‌های حافظه کاری، بلندمدت و اپیزودیک مجزا هستند.
• تکه‌ها به اندازه یک ایده (۵۰۰-۸۰۰ کاراکتر) با مرزهای تست شده هستند.
• مدل برداری بر اساس توازن بُعد در برابر هزینه انتخاب شده است.
• ذخیره‌ساز برداری روی داده‌های واقعی بنچ‌مارک شده است.
• متادیتا شامل منبع، محدوده کاربر، نسخه و برچسب زمانی است.
• بازیابی دقیقاً بر اساس کاربر محدود شده تا نشت حافظه رخ ندهد.
• جست‌وجوی ترکیبی یا بازرتبه‌بندی فعال است و Recall@k روی یک مجموعه ارزیابی اندازه گیری می‌شود.
• چرخه عمر حافظه (انقضا، نگهداری، حذف) پیاده‌سازی شده است.
• تزریق بستر برای نگه داشتن توکن‌ها در هر نوبت، محدود شده است.
• هشدارها برای افت کیفیت بازیابی (بازیابی‌های خالی یا افت Recall@k) تنظیم شده‌اند.

برای مشتری لجستیک در دبی، این تغییر در معماری تحول‌آفرین بود. با بازیابی تاریخچه مشتری در کمتر از ۶۰ میلی‌ثانیه، عامل دیگر از مشتریان نمی‌خواست که حرف‌هایشان را تکرار کنند. عامل تاریخچه تحویل را استخراج می‌کرد، روش‌های تماس ترجیحی را به یاد می‌آورد و تیکت‌های قبلی را با نام می‌خواند. نرخ حل مشکلات افزایش یافت زیرا عامل بالاخره بستر لازم برای ساختن روی گفتگوهای دیروز را داشت، به جای اینکه هر شب همه چیز را از صفر شروع کند.

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.