تصور کنید یک دستیار هوشمند دارید که هرگز هیچ جزئیاتی را فراموش نمی‌کند، اما گاهی چند ثانیه طول می‌کشد تا به یاد بیاورد چه گفته است. برای رسیدن به این سطح از پایداری، باید نگاه ما به مدیریت وضعیت (State) در هوش مصنوعی به‌طور کلی تغییر کند. یک چت‌بات که هرگز فراموش نمی‌کند، به چیزی فراتر از یک پایگاه‌داده ساده نیاز دارد؛ این امر مستلزم تغییری بنیادین در نحوه مدیریت وضعیت توسط هوش مصنوعی است.
در جریان هکاتون Walrus Sessions 8، یک توسعه‌دهنده بات تلگرامی را با استفاده از مدل DeepSeek طراحی کرد که حافظه را به‌جای پایگاه‌داده‌های سنتی و قابل‌ویرایش، به‌صورت خطوط متنی تغییرناپذیر روی فضای ذخیره‌سازی Walrus ثبت می‌کند.
اکثر عامل‌های هوش مصنوعی (AI Agents) — شبیه به کارمندی که مدام یادداشت‌های قدیمی‌اش را پاک می‌کند تا جا برای اطلاعات جدید باز شود — بر پایه جداول تاریخچه یا ذخیره‌سازهای برداری هستند که می‌توان آن‌ها را به‌روزرسانی یا حذف کرد. این رویکرد در تضاد با سنجش کارآمدی معماری‌های حافظه در ابزارهایی مانند Mem0 و Zep است که بر بهینه‌سازی بازیابی داده‌ها تمرکز دارند. اما در معماری این بات، هر خطی که نوشته شود، برای همیشه باقی می‌ماند؛ هیچ دستور «ویرایش» یا «حذف» وجود ندارد. برای تغییر نظر یا تکمیل یک وظیفه، بات صرفاً یک خط جدید می‌نویسد و اعلام می‌کند که کار تمام شده است و سیستم، آخرین ورودی را به عنوان وضعیت نهایی می‌پذیرد و ورودی‌های قبلی را به نفع جدیدترین مورد کنار می‌زند.
زمینه: معماری حافظه
برای درک بهتر این سیستم، باید به اجزای تشکیل‌دهنده آن نگاه کنیم:
- پلتفرم: این بات بر روی پیام‌رسان تلگرام اجرا می‌شود.
- مدل زبانی (LLM): برای پردازش زبان و تولید پاسخ‌ها از DeepSeek استفاده می‌کند.
- ذخیره‌سازی: حافظه به‌جای یک پایگاه‌داده محلی یا شخصی، روی شبکه Walrus قرار دارد.
- قالب: تمامی اطلاعات به‌صورت خطوط متنی همراه با تگ‌های شناسایی ذخیره می‌شوند.
بر اساس گزارش منتشر شده در وب‌سایت dev.to در ۲۳ سپتامبر ۲۰۲۶، چالش اصلی این پروژه نه در مدل زبانی، بلکه در ماهیت ناهمگام (Asynchronous) لایه ذخیره‌سازی بود. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های زیرساختی اغلب گلوگاه اصلی عملکرد هستند. توسعه‌دهنده این پروژه سه نقطه شکست بحرانی را در خط لوله حافظه تغییرناپذیر شناسایی کرد:
شکاف نوشتن ناهمگام
نوشتن یک خط در این حافظه، یک «فرمان» یا Job است نه یک «عمل آنی». طبق مستندات پروژه، یک درخواست نوشتن در حدود یک ثانیه شناسه عملیات (Job ID) و وضعیتی چون «در حال اجرا» (Running) را برمی‌گرداند، اما داده‌ها ممکن است برای مدتی طولانی قابل خواندن نباشند.
در یک مورد رصد شده، یک عملیات ۱.۲ ثانیه در وضعیت «در انتظار» (Pending)، ۳.۲ ثانیه در وضعیت «در حال اجرا» بود و تنها پس از ۲۶.۱ ثانیه به وضعیت «آپلود شده» (Uploaded) رسید تا در نهایت قابل خواندن شود. از آنجا که یک عملیات شکست‌خورده و یک عملیات کند در چهار دقیقه اول کاملاً یکسان به نظر می‌رسند، کلاینت باید یک صندوق خروجی (Outbox) اختصاصی داشته باشد و هر خط را تا زمانی که یک عملیات خواندن ثابت کند جهان می‌تواند آن را ببیند، در حافظه موقت نگه دارد.
توهم لیست خالی
بازیابی داده‌ها همیشه سازگار نیست. بات گاهی برای بخش‌هایی (Namespaces) که در واقعیت ۳۰ دقیقه پیش سه خط داده داشتند، گزارش «حافظه خالی» می‌داد.
اما وقتی توسعه‌دهنده همان پرسش را تنها ۳ ثانیه بعد تکرار کرد، هر سه خط بازگردانده شدند. در واقع، سیستم بازیابی گاهی برای پرسشی که تطبیق دارد، ابتدا یک لیست خالی برمی‌گرداند و سپس در دفعات بعد پاسخ درست می‌دهد. برای حل این مشکل، یک استراتژی «عقب‌نشینی نمایی» (Exponential Backoff) با بازه‌های ۰.۶، ۲ و سپس ۳ ثانیه پیاده شد. برای جلوگیری از این تأخیر در هر پیام، اکنون ابتدا یک تست انجام می‌شود تا بررسی شود آیا یک فضای نام واقعاً خالی است یا خیر، پیش از آنکه زمان انتظار کامل پرداخت شود.
تداخل برچسب‌های زمانی
از آنجا که بات تمام خطوط یک نوبت (Turn) را با یک برچسب زمانی واحد ثبت می‌کند، چندین خط ممکن است زمان کاملاً یکسانی داشته باشند. اگر در یک نوبت، یک وظیفه دو بار ذکر شود، دو خط با دقت ثانیه‌ای یکسان ایجاد می‌شود.
بدون ترتیب تضمین‌شده در لایه ذخیره‌سازی، بات گاهی یادآورهای حیاتی را گم می‌کرد، زیرا دو خط برای جایگاه «جدیدترین» (Newest) با هم تساوی داشتند. این مشکل زمانی کشف شد که یک ضرب‌الاجل یکسان با دو عبارت متفاوت ظاهر شد. راهکار نهایی، شکستن این تساوی‌ها بر اساس اطلاعاتی بود که هر خط در خود دارد، پیش از آنکه از متن خط استفاده شود؛ این کار تضمین می‌کند که نتایج بدون توجه به ترتیب ذخیره‌سازی، سازگار بمانند.
این چرخش به سمت لاگ‌های تغییرناپذیر، نقش توسعه‌دهنده را از «مدیریت داده» به «مدیریت زمان» تغییر می‌دهد. با این حال، باید مراقب بود که تراکم بیش از حد تاریخچه کامل داده‌ها منجر به ایجاد سوگیری در تحلیل‌های هوش مصنوعی نشود، چرا که حجم زیاد لاگ‌ها می‌تواند باعث «کوری» مدل در شناسایی ریشه مشکلات شود. دیگر نمی‌توان فرض کرد که یک پاسخ موفق از API به معنای وجود واقعی داده در جهان است.
با این اصلاحات، یادآورها حتی پس از ری‌استارت سیستم باقی می‌مانند و وظایف تکمیل‌شده، تکمیل‌شده می‌مانند. توسعه‌دهنده اسکریپتی را در مخزن پروژه قرار داده که نتایج قبل و بعد از اصلاحات را در کنار هم چاپ می‌کند تا اثبات کند دو خط کد اصلاح‌شده که یک رفع خطا را نشان می‌دهند، ارزشمندتر از یک پاراگراف ادعاست.
برای یک توسعه‌دهنده عملیاتی، این یعنی حافظه یک عامل تنها به اندازه منطق «تلاش مجدد» (Retry Logic) لایه ذخیره‌سازی‌اش قابل اعتماد است. تکیه بر رویکرد ساده «بنویس و فراموش کن»، منجر به بات‌هایی می‌شود که دچار توهم (Hallucination) — شبیه به دوستی که با اطمینان خاطره‌ای را اشتباه تعریف می‌کند — شده یا ضرب‌الاجل‌ها را به دلیل تداخل میلی‌ثانیه‌ای گم می‌کنند.
اگر می‌خواهید حافظه عامل‌های هوش مصنوعی را خارج از فضای برداری (Non-vector) آزمایش کنید، رویداد Walrus Sessions 8 با عنوان «چت‌بات‌هایی که به یاد می‌آورند» تا اکتبر ادامه دارد. شما می‌توانید از طریق DeepSurge (https://www.deepsurge.xyz/hackathons/c0141a4a-21be-4009-bc63-7c168608c849) ثبت‌نام کنید تا عامل‌هایی در مقیاس کوچک بسازید که این مرزهای پایداری را به چالش می‌کشند.
گام بعدی شما
- اگر به دنبال جایگزینی برای حافظه‌های برداری هستید، معماری Log-based را برای داده‌های حساس بررسی کنید.
- منطق Retry را در لایه‌های ذخیره‌سازی ناهمگام با استراتژی Exponential Backoff پیاده کنید.
- برای ثبت وقایع در حافظه عامل، از برچسب‌های زمانی با دقت میکروسانی یا شناسه‌های ترتیبی (Sequence ID) استفاده کنید.
این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.
گفتگو