MemoBase: حذف توهمات مدل از طریق گیت کد-محور و حافظه محلی

اگر امروز برای مدیریت حافظهٔ عامل‌های هوش مصنوعی خود به دیتابیس‌های برداری گران‌قیمت ابری متکی هستید، باید بدانید که یک فایل سادهٔ SQLite می‌تواند تمام این زیرساخت را جایگزین کند. این تغییر مسیر، مشکل دیرینهٔ «فراموشی بین جلسات» و توهمات مدل در مواجهه با اسناد خصوصی را به‌طور کامل حل می‌کند. توسعه‌دهندهٔ MemoHood و MemoBase این پلاگین‌ها را دقیقاً برای رفع دو شکست مزمن در عامل‌ها عرضه کرده است: فقدان بافتار (Context) بین جلسات و تمایل مدل به ساختن واقعیت‌های جعلی (توهم) درباره اسناد خصوصی.

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

به همین دلیل، روش‌های متداول تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اغلب شکست می‌خورند. این سیستم‌ها معمولاً برای جلوگیری از دروغ‌گویی تنها به «پرامپت‌های سیستم» متکی هستند. وقتی کاربر فایلی را در کشی قرار می‌دهد که هر ۲۴ ساعت پاک می‌شود، تنها دو گزینهٔ بد دارد: یا کل سند را در پرامپت قرار دهد که بسیار هزینه‌بر است و باعث «گم شدن مدل در میانه متن» (Lost in the Middle) می‌شود، یا اجازه دهد مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — با تکیه بر دانش عمومی، با اطمینان کامل اطلاعات غلط یا توهم بسازد.

همان‌طور که در تحلیل‌های فنی اشاره شده، راهکار این است که لایه‌های «صداقت» و «پایداری» را از پرامپت خارج کرده و به داخل کد واقعی پلاگین منتقل کنیم. این ابزارها با متصل شدن به API پلاگینِ عامل، بدون تغییر در حتی یک خط از سورس‌کد اصلی مدل عمل می‌کنند. همچنین با استفاده از معماری محلی-محور (Local-first)، سیستم از سربارهای سنگین PyTorch و پیچیدگی‌های قانونی مجوزهای AGPL — که می‌تواند توسعه‌دهندگان را مجبور به باز کردن سورس‌کد پروژه‌هایشان کند — دوری می‌کند.

موتور جست‌وجوی ترکیبی

برای اینکه عامل دقیقاً همان چیزی را که نیاز دارد بیابد، یک استراتژی جست‌وجوی ترکیبی (Hybrid Search) پیاده‌سازی شده است که رویکردهای لفظی و معنایی را با هم ترکیب می‌کند:

FTS5 (جست‌وجوی تمام‌متن): این بخش از الگوریتم BM25 برای تطبیق کلمات کلیدی دقیق استفاده می‌کند. برای یافتن توکن‌های دقیق مانند کدهای خطا، شماره‌های SKU، نام توابع یا نام‌های خانوادگی، این روش بی‌رقیب است. با این حال، این جست‌وجو کاملاً لفظی است؛ یعنی اگر عبارت «قرارداد» را جست‌وجو کنید، تکه متنی که فقط کلمه «توافق‌نامه» دارد را پیدا نمی‌کند.
جست‌وجوی برداری (Vector Search): با استفاده از sqlite-vec، معنای کلمات را می‌سنجد. در این فضا، «توافق‌نامه» و «قرارداد» در نزدیکی یکدیگر قرار دارند. اما این روش در مواجهه با رشته‌های دقیق مانند شماره سفارش (مثلاً A-4471) دچار مشکل می‌شود، زیرا این رشته‌ها هیچ «معنای» معنایی ندارند که بر اساس آن در فضای برداری نزدیک به چیزی باشند.
تلفیق رتبه متقابل (RRF): برای حذف نقاط کور هر دو سیستم، RRF نتایج را ترکیب می‌کند. این روش امتیازات خام را (که در سیستم‌های مختلف قابل مقایسه نیستند) نادیده می‌گیرد و بر اساس رتبه با استفاده از ثابت استاندارد k=60 ترکیب را انجام می‌دهد.

طبق فرمول def rrf(rank, k=60): return 1 / (k + rank)، تکه متنی که در جست‌وجوی کلیدواژه رتبه ۲ و در جست‌وجوی برداری رتبه ۵ را دارد، رتبه‌ای بالاتر از تکه متنی خواهد داشت که در یکی از لیست‌ها رتبه ۱ است اما در لیست دیگر اصلاً وجود ندارد. این تضمین می‌کند نتایجی که هم از نظر معنایی و هم از نظر عبارت دقیق یافت شده‌اند، برنده شوند.

یکپارچگی پایگاه داده محلی

برخلاف استک‌های سازمانی غول‌پیکر، تمام این سازوکار در یک فایل SQLite قرار دارد. سیستم از FTS5 با پیاده‌سازی خاصی برای ریشه‌یابی (Stemming) زبان روسی در ستون مربوطه استفاده می‌کند تا مثلاً جست‌وجوی «договора» بتواند کلمه «договор» را بیابد. بردارها نیز از طریق sqlite-vec در همین دیتابیس ذخیره می‌شوند. این کار نیاز به سرور برداری جداگانه یا ایندکس خارجی را از بین می‌برد و نتیجه آن یک فایل واحد است که به‌راحتی قابل کپی، پشتیبان‌گیری یا حذف است. این رویکرد یادآور استراتژی مدیریت حافظه در OpenClaw است که در آن نیز جایگزینی گزارش‌های متنی با پایگاه‌داده دنبال می‌شد.

در صورت وجود کلید API شرکت Cohere، کاندیداهای برتر یک مرحله‌ی نهایی بازرتبه‌بندی (Reranking) را برای رسیدن به حداکثر دقت طی می‌کنند. اگر کلیدی در دسترس نباشد، سیستم بدون نمایش خطا، به ترتیب RRF بازگشته و روند را ادامه می‌دهد.

حذف توهمات از طریق کد

MemoBase برای کشتن توهم (Hallucination) — یعنی زمانی که مدل با اطمینان چیزی می‌گوید که وجود ندارد — یک حلقهٔ چهارمرحله‌ای سخت‌گیرانه دارد. توسعه‌دهنده استدلال می‌کند که پرامپت صرفاً یک «درخواست» است، در حالی که او به دنبال یک «تضمین» بود. صداقت در اینجا یک ویژگی شخصیتی نیست که از طریق پرامپت القا شود، بلکه در کد و از طریق این خط لوله (Pipeline) تحمیل می‌شود:

۱. گیت کفایت (Sufficiency Gate): سیستم ابتدا ارزیابی می‌کند که آیا جست‌وجو یک تکه متن واقعاً مرتبط و با اطمینان بالا بازگردانده است یا خیر. اگر نتایج ناکافی باشند، سیستم پیش از آنکه مدل هر چیزی تولید کند، بلافاصله از پاسخ دادن خودداری می‌کند.
۲. تولید بدون ابزار (Tool-less Generation): مدل از تمام ابزارها، از جمله دسترسی به وب، محروم می‌شود. او مجبور است تنها با استفاده از تکه‌های بازیابی‌شده پاسخ دهد و هیچ راهی برای «پر کردن جاهای خالی» از طریق اینترنت ندارد.
۳. بررسی استنادی (Citation Check): این بخش ستون فقرات سیستم است. هر نقل‌قول در پاسخ، به‌صورت کلمه به کلمه (یا تطبیق نزدیک/Fuzzy) با متن منبع مقایسه می‌شود. اگر نقل‌قول دقیق نباشد، حذف می‌شود. ادعاهای مدل با متن خام منبع مقایسه (Diff) می‌شوند.
۴. رد صادقانه (Honest Refusal): اگر پس از فرآیند پاک‌سازی، هیچ استناد تأییدشده‌ای باقی نماند، سیستم به‌جای ارائه متن غیرقابل‌اعتماد، پیام «در پایگاه دانش موجود نیست» را بازمی‌گرداند.

حافظه نسخه‌دار MemoHood

در حالی که MemoBase اسناد را مدیریت می‌کند، MemoHood تکامل گفتگو را ردیابی می‌کند. توسعه‌دهنده مشاهده کرد که اکثر حافظه‌ها صرفاً داده‌ها را بازنویسی (Overwrite) می‌کنند؛ مثلاً اگر کاربر ضرب‌الاجل را از جمعه به دوشنبه تغییر دهد، تاریخ جمعه پاک می‌شود، اما جست‌وجوی کلیدواژه ممکن است هنوز یک خلاصه قدیمی را بیرون بکشد و باعث شود عامل با تکیه بر نقشه قدیمی، کاربر را «تصحیح» کند. این تضاد در ساختارهای ذخیره‌سازی، بحث‌هایی را درباره تأثیر فرمت حافظه بر انعطاف‌پذیری مدل‌ها ایجاد کرده است.

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

برای بهینه‌سازی هزینهٔ استنتاج (Inference) و جلوگیری از هزینه‌های غیرضروری LLM، دو مکانیزم اضافی به کار گرفته شده است:

ضبط آزاد (Free Capture): سیگنال‌های صریح — مانند تصحیحات، تصمیمات یا عباراتی چون «این را به خاطر بسپار» — توسط یک امتیازدهنده کلیدواژه شناسایی می‌شوند. این کار به صفر فراخوانی LLM نیاز دارد. تنها موارد مبهم به یک مدل ارزان‌قیمت فرستاده می‌شوند تا تصمیم بگیرد آیا ارزش ذخیره دارند یا خیر.
گیت بازخوانی (Recall Gate): یک مدل جاسازی استاتیک آفلاین و بسیار کوچک (Model2Vec) به‌عنوان گیت عمل می‌کند. این مدل قضاوت می‌کند که آیا ورودی کاربر واقعاً سؤالی مرتبط با حافظه است یا خیر. این کار مانع از فعال شدن جست‌وجو برای گفتگوهای ساده‌ای مثل «ممنونم» می‌شود.
منحنی‌های زوال (Decay Curves): اطلاعات دسته‌بندی می‌شوند. واقعیت‌های بادوام (نام‌ها، تاریخ تولدها، حساسیت‌ها) پین می‌شوند تا منحنی فراموشی شبانه را دور بزنند. سایر موارد به‌مرور زمان کمرنگ می‌شوند — اتفاقات گذرا سریع‌تر و واقعیت‌های پایدار کندتر — که این کار توسط یک پردازش پس‌زمینه انجام می‌شود تا سرعت پاسخ‌دهی کاهش نیابد.

زیرساخت محلی و عملکرد

نویسنده به‌طور عمدی PyTorch را حذف کرد تا استک به اندازه کافی سبک باشد که روی یک VPS ۵ دلاری اجرا شود. یک استک RAG معمولی گیگابایت‌ها وزن مدل و وابستگی‌های سنگین را به همراه دارد. در مقابل، این سیستم به کتابخانه استاندارد و چند بسته سبک متکی است:

sqlite-vec برای ایندکس برداری.
PyStemmer برای ریشه‌یابی کلمات.
fastembed که از طریق ONNX Runtime برای جاسازی‌های (Embeddings) آفلاین اجرا می‌شود.

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

مسیر ابری (Cloud Path): کیفیت حداکثری با استفاده از Cloudflare Workers AI (مدل BGE-M3) برای بردارها و بازرتبه‌بندی اختیاری Cohere. این مسیر شامل منابع اضافی مانند زیرنویس‌های یوتیوب و تبدیل صوت به متن است و برای جلوگیری از قبض‌های غیرمنتظره، سقف هزینه ماهانه برای هر ارائه‌دهنده دارد.
مسیر محلی (Local Path): یک استقرار کاملاً ایزوله (Air-gapped) که از طریق دستور ./install.sh --local (در لینوکس/مک) یا .\install.ps1 -Local (در ویندوز) فعال می‌شود. این مسیر از یک مدل چندزبانه (حدود ۲.۲ گیگابایت که یک‌بار دانلود می‌شود) استفاده کرده و به هیچ کلید API نیاز ندارد.

پیام نویسنده درباره حریم خصوصی این است که در حالت ابری، تنها متن سؤال و تکه‌های کاندید برای بردارسازی/بازرتبه‌بندی از دستگاه خارج می‌شوند؛ فایل‌های منبع و دیتابیس هرگز خارج نمی‌شوند. در حالت محلی، هیچ داده‌ای از دستگاه خارج نمی‌شود.

زمینه صنعت و شباهت‌ها

اگرچه ترکیب این پلاگین‌ها منحصر‌به‌فرد است، اما نویسنده اشاره می‌کند که طراحی آن بازتابی از استانداردهای سطح بالای صنعت است. جست‌وجوی ترکیبی تلفیق‌شده با RRF همان منطقی است که در Microsoft Azure AI Search (تأمین‌کننده Copilot)، Google Vertex AI Search، Amazon OpenSearch و Elasticsearch استفاده می‌شود. رویکرد «پاسخ فقط از روی منابع» همراه با استنادات، پایه و اساس Perplexity و Google NotebookLM است.

در زمینه حافظه، ابزارهایی مثل mem0 و AWS Bedrock AgentCore از روش‌های استخراج واقعیت مشابهی استفاده می‌کنند. Zep از گراف‌های زمانی برای جلوگیری از پاک کردن حالت‌های قدیمی بهره می‌برد (مشابه SUPERSEDE) و Letta (ex-MemGPT) با حافظه مانند یک سیستم‌عامل برخورد می‌کند. هدف این پروژه، بسته‌بندی این ایده‌های مقیاس غول‌پیکر در یک فایل SQLite محلی بود.

محدودیت‌های فعلی

کاربران باید پیش از نصب از محدودیت‌های فعلی آگاه باشند:

عدم بازپروری تاریخچه: MemoHood واقعیت‌ها را از گفتگوهایی که «بعد از نصب» رخ می‌دهند استخراج می‌کند. اگرچه می‌تواند تاریخچه قدیمی را برای بازخوانی ایندکس کند، اما تاریخچه‌های قدیمی را برای استخراج واقعیت‌های جدید پیمایش نمی‌کند.
هزینه‌های تقریبی: اعداد مربوط به هزینه‌های ارائه‌دهندگان ابری بر اساس قیمت‌های عمومی هستند و صورت‌حساب تضمین‌شده نیستند.
انحراف در تبدیل صوت: مسیر اصلی Whisper زمان‌بندی‌های واقعی دکودر را ارائه می‌دهد، اما مسیر جایگزین (Fallback) آن‌ها را تخمین می‌زند که در فایل‌های صوتی طولانی باعث انحراف (Drift) می‌شود (این موارد با تراز اعتماد پایین علامت‌گذاری می‌شوند).
درج دستی شبکه‌های اجتماعی: ابزاری برای استخراج تک‌کلیکی از شبکه‌های اجتماعی وجود ندارد. صفحات وب به‌عنوان متن دریافت می‌شوند، اما ویدیوهای تیک‌تاک یا اینستاگرام باید دستی دانلود و به‌عنوان فایل وارد شوند.
بازیابی دستی: پشتیبان‌های شبانه به‌عنوان فایل دیتابیس ایجاد می‌شوند، اما هنوز ابزار بازیابی تک-دستوری (One-command restore) پیاده‌سازی نشده است.

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

برای شروع ساخت، می‌توانید مخازن MIT-licensed مربوط به MemoHood (حافظه درون‌گفتگویی) و MemoBase (پایگاه دانش) را در گیت‌هاب بررسی کنید.

گام بعدی شما

اگر عامل‌های شما دچار توهم در اسناد خصوصی هستند، لایه «بررسی استنادی» (Citation Check) را در کد خود پیاده کنید.
برای کاهش هزینه‌ها، مدل‌های کوچک مثل Model2Vec را به‌عنوان گیت ورودی برای تشخیص نیاز به جست‌وجو به کار ببرید.
نحوه تعامل این حافظه‌ها با پروتکل‌های جدید مدل‌ها را در تحلیل ما درباره MCP بررسی کنید.

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما