حافظه Claude Code: چرا فراموش می‌کند و دو عددی که مشکل را حل می‌کنند

من عملیات یک استودیوی طراحی را از داخل Claude Code اداره می‌کنم. ده تا بیست ترمینال باز، همه‌شان من هستم. و طی چند ماه، هر کدام‌شان باعث می‌شدند یک نفر مدام حرف‌های خودش را تکرار کند.

تیم Brainy جلسه‌ای را که این ماجرا از آن شروع شد با یک جمله باز کرد: از تکرار حرف‌های خودمان خسته شده‌ایم. بعد بنچمارکی از هفت محصول حافظه و یک ریپو را پیست کردند و پرسیدند چرا حافظه پشت من مثل آن نیست.

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

• سیستم حافظه را از نو ساختیم
• شانزده ایجنت پژوهشی هر پلاگین و ارائه‌دهنده حافظه‌ای را که می‌توانستیم نام ببریم بررسی کردند، و هشت‌تای‌شان تلاش کردند هشت‌تای دیگر را رد کنند
• کار خودمان را روی پرامپت‌های واقعی سنجیدیم، نه آزمونی که خودمان نوشته بودیم
• بنچمارک را خودمان اجرا کردیم و هر رقیب را با همان داور نمره‌دهی کردیم

نتیجه یک توصیه برای پلاگین نیست. دو عدد است، یک پرتگاه، و یک قانون درباره اینکه یک حافظه اجازه دارد چه چیزی را ادعا کند.

اشکال: نوشتن دقیق، بازیابی اختیاری

این چهار کلمه کل باگ تکرار حرف زدن است.

حافظه‌ای که با دقت نوشته می‌شود ولی به دلخواه خوانده می‌شود، از هر ممیزی‌ای سربلند بیرون می‌آید، چون هر فایل آنجا هست و هر واقعیت درست است.

و انسان همچنان برای چهارمین بار قانون دیپلوی را توضیح می‌دهد، چون در لحظه‌ای که آن قانون اهمیت داشت، هیچ‌چیز نرفت آن را پیدا کند.

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

هیچ‌کدام به‌طور قابل‌اتکا اتفاق نمی‌افتاد. مخزن بیشتر نوشتنی بود، و یک حافظه‌ی بیشتر-نوشتنی، دفتر خاطرات است، نه حافظه.

نوشتن دقیق، بازیابی اختیاری.

فایل حافظه شما یک پرتگاه پنهان دارد

Claude Code ایندکس حافظه خودکار شما، فایل MEMORY.md، را تا ۲۰۰ خط یا ۲۵٬۰۰۰ بایت بارگذاری می‌کند، هر کدام زودتر برسد. بعد از آن خط، هیچ‌چیز بارگذاری نمی‌شود، و هیچ‌کس به شما نمی‌گوید.

فایل ما ۲۲۹ خط و ۳۱٬۲۸۳ بایت بود. سقف بایت آن را در خط ۱۷۶ قطع کرد. زیر آن خط، سه بخش کامل از قوانین ثابت نشسته بود، از جمله امنیت.

پنجاه‌وسه خط، ۲۳ درصد از ایندکس. آن‌ها حتی یک‌بار هم به هیچ جلسه‌ای نرسیده بودند.

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

اگر تا به حال قانونی را به حافظه‌تان اضافه کرده‌اید و بعد از یک هفته دیده‌اید ایجنت آن را نادیده می‌گیرد، خطوطتان را بشمارید. این سقف در دو ایشو در ردیاب Claude Code مستند شده، و اگر فایلتان از هر کدام از این دو عدد بیشتر شده باشد، همین الان دارد همین کار را با شما می‌کند.

نمره‌ای کامل که فقط ۱۷ درصد درست بود

نسخه اول راه‌حل دو ساعت طول کشید. یک ایندکس تمام‌متن روی مخزن، یک هوک که در هر پرامپت آن را جست‌وجو می‌کند و بهترین نتایج را تزریق می‌کند. روی مجموعه‌ای از ۲۳ کوئری آزمایشی، نمره ۲۲ گرفت.

بعد لاگ زنده را خواندیم. شش پرامپت واقعی، ۱۸ حافظه تزریق‌شده، حدود سه‌تای‌شان مرتبط. هفده درصد.

بنچمارک کوئری‌هایی مثل «deploy to production» بود. هیچ‌کس در تیم این‌طور تایپ نمی‌کند. آن‌ها پرامپت‌های بلند، محاوره‌ای و چندبخشی تایپ می‌کنند که در آن‌ها اسکرین‌شات و URL پیست شده است.

متن تحت‌اللفظی پرامپت یک کوئری جست‌وجوی افتضاح است، و موضوع معمولاً در نوبت قبلی نشسته است. ما یک لوله خوب ساختیم و آب بد از آن عبور دادیم.

پنج علت، هر کدام سنجیده شد، هر کدام رفع شد:

علت پنجم بدترین بود. اجازه دادن به اینکه مکالمه‌ی جلسه جست‌وجو را هدایت کند، یعنی جلسه‌ای درباره حافظه، در هر نوبت هر یادداشت حافظه را بازیابی می‌کرد، و پرسشی درباره دیپلوی به‌جای قانون دیپلوی، فایل‌های ایندکس می‌گرفت. زمینه می‌تواند کوئری‌ای را که از قبل موضوع دارد دقیق‌تر کند. هرگز نباید موضوعی اختراع کند.

بعد از بازنویسی: ۱۴ از ۱۶ پرامپت واقعی، حافظه درست را در دو نتیجه برتر گرفتند، و ۱۸ از ۱۸ پرامپت محاوره‌ای، از نوع «باشه برو جلو»، درست به‌جا هیچ‌چیز نگرفتند.

سکوت یک ویژگی است. حافظه‌ای که در پرامپتی تزریق شود که نیازی به آن نداشت، نویزی است که مدل باید از آن رد شود.

یک قانون: هیچ مدلی در مسیر پرامپت اجرا نمی‌شود

اینک عدد اول. یک رفت‌وبرگشت به یک مدل زبانی از یک هوک، ۸.۶ ثانیه طول می‌کشد. یک جست‌وجوی تمام‌متن روی کل مخزن، ۱۸ میلی‌ثانیه.

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

پس قانون مطلق است: مدل هرگز در مسیر پرامپت اجرا نمی‌شود. آفلاین اجرا می‌شود، در پایان جلسه و در یک پویش روزانه، و آنچه یاد می‌گیرد را در ایندکس می‌نویسد. آنجا سه وظیفه دارد:

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

بعد کنار می‌رود، و چیزی که در زمان پرامپت پاسخ می‌دهد، یک SQLite ساده است.

این تفکیک، صفر دلار و ۱۸ میلی‌ثانیه هزینه دارد

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

زمان بودجه‌ای است که گاز می‌گیرد. هوک در هر پرامپت از نو شروع می‌شود، پس هر چیزی که بارگذاری می‌کند، دفعه بعد دوباره بارگذاری می‌کند. اینک اندازه‌گیری هر گزینه:

جست‌وجوی کلیدواژه‌ای، پیش از آنکه اصلاً بحث کیفیت پیش بیاید، از نظر تأخیر برنده است.

تایپ‌کردن همچنان آنی می‌ماند. کل تصمیم همین بود.

«فایل‌های پراکنده» گلایه اشتباهی است

انتقادی که مدام می‌شنیدیم دو نیمه داشت: حافظه شما در فایل‌های markdown پراکنده است، و شما کل حافظه را به هر مکالمه نمی‌آورید. Hermes، هارنس ایجنتی که تیم به آن اشاره کرد، یک حافظه دارد که با شما رشد می‌کند.

هر دو نیمه سزاوار پاسخی مستقیم هستند.

آوردن کل حافظه به هر مکالمه از نظر ریاضی غیرممکن است. مخزن ما ۸۷۵٬۵۵۳ توکن است. پنجره زمینه ۲۰۰٬۰۰۰ است. این یعنی ۴.۴ پنجره حافظه، و هر روز بزرگ‌تر هم می‌شود.

هیچ‌کس کل حافظه را نمی‌آورد. همه بازیابی می‌کنند.

و «یک حافظه»ی Hermes، ۳٬۵۷۵ کاراکتر است. یک فایل حافظه ۲٬۲۰۰ کاراکتری به‌علاوه یک پروفایل کاربر ۱٬۳۷۵ کاراکتری، هر دو همیشه در پرامپت، هر دو با سقف سخت. هر چیز دیگری که Hermes می‌داند در فایل‌هایی روی دیسک زندگی می‌کند و در صورت نیاز با همان نوع ایندکسی که ما استفاده می‌کنیم جست‌وجو می‌شود.

«پراکنده در فایل‌های markdown» هر دو سیستم را توصیف می‌کند. تعداد فایل، ذخیره‌سازی است. دسترسی، ایندکس است. ۴۸۷ فایل پشت یک ایندکس تمام‌متن، پراکندگی نیست؛ یک کوئری در ۱۸ میلی‌ثانیه همه آن‌ها را لمس می‌کند.

جایی که انتقاد درست بود

این انتقاد درباره‌ی نقطه مقابل ادعای خودش درست بود. لایه‌ی همیشه-روشن Hermes حدود ۱٬۳۰۰ توکن است. مال ما ۶٬۱۵۲ بود. آن‌ها ۴.۷ برابر لاغرتر هستند، و این لاغری از یک قانون سخت می‌آید: وقتی حافظه پر می‌شود، نوشتن شکست می‌خورد و ایجنت باید پیش از افزودن هر چیزی، تحکیم/فشرده‌سازی کند.

به این قانون از نزدیک نگاه کردیم و آن را رد کردیم. خود ردیاب ایشوهای Hermes یک استقراری را نشان می‌دهد که سقف‌ها را به ۸٬۰۰۰ و ۳٬۰۰۰ کاراکتر رساند و همچنان به آن‌ها برخورد کرد، «که باعث شکست فراخوانی‌های memory.add و از‌دست‌رفتن مکرر اصلاحات اپراتور می‌شد.»

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

هفت محصول حافظه چه چیزی به ما آموختند

بنچمارکی که تیم با آن شروع کرد، MemConflict، هفت ارائه‌دهنده حافظه‌ی self-hosted را از میان همان ۳۰ کاربر شبیه‌سازی‌شده عبور داد و از هر ارائه‌دهنده ۳٬۷۵۰ سوال پرسید. به پاسخ اشتباه، منفی یک نمره داد، نه صفر. همین یک انتخاب، بیشتر آنچه در ادامه می‌آید را برملا کرد.

سه یافته که مهم‌تر از رتبه‌بندی هستند

رتبه‌بندی کم‌فایده‌ترین بخش آن جدول است. سه الگو در میان همه ارائه‌دهندگان صادق بود:

• هیچ‌کس به‌طور قابل‌اتکا یک حافظه جعلیِ کاشته‌شده را رد نمی‌کند. بهترین، Honcho، تنها به ۳۶.۴ درصد از آن پرسش‌ها به‌طور کاملاً درست پاسخ داد و در ۲۵.۸ درصد موارد، دروغ کاشته‌شده را تأیید کرد. Mnemosyne زیر صفر نمره گرفت: مقادیر اشتباه را بیشتر از مقادیر درست تأیید می‌کند.

• با رشد تاریخچه، همه بدتر می‌شوند. از جلسات ۶ تا ۱۰ نسبت به جلسات ۴۶ تا ۵۰، سهم پاسخ‌های اشتباه mem0 از ۸.۳ درصد به ۲۲.۱ درصد رسید. تقریباً همه ارائه‌دهندگان دو برابر شدند.

• آن‌هایی که امن به نظر می‌رسیدند، بیشتر ساکت بودند. OpenViking در ۶۷ درصد پاسخ‌ها خالی گذاشت، Mnemosyne در ۵۰ درصد. با یک کف صفر، رقابتی به نظر می‌رسیدند.

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

Honcho همچنین ۶۱۷٬۲۷۸ توکن مدل در هر جلسه صرف استخراج در پس‌زمینه می‌کند. کل مخزن ما ۸۷۵٬۵۵۳ توکن است. پذیرفتن آن یعنی خرج کردن بیشتر پیکره، در هر جلسه، برای همیشه، برای پاسخ به پرسش‌هایی که یک ایندکس جست‌وجو از قبل پاسخ می‌دهد.

این شکلِ تصمیم ساختن-در-برابر-پذیرفتن است. نقاط قوت آن‌ها تنگنای ما نبود. نقاط ضعف آن‌ها دقیقاً همان نیازمندی‌های ما بود: یک مدل زبانی یک سوی یک تناقض را حذف می‌کند، و هیچ‌چیز آن را بررسی یا خنثی نمی‌کند.

بنچمارک را خودمان اجرا کردیم: ۰.۴۰۹ در تلاش اول

جدولی که فرد دیگری تولید کرده، یک ادعاست، پس با آن مثل یک ادعا رفتار کردیم. حافظه‌مان را در همان هارنس وصل کردیم و روی همان کاربران شبیه‌سازی‌شده و همان پرسش‌ها نمره‌دهی کردیم.

دو جزئیات تعیین می‌کنند که آیا عددی مثل این اصلاً معنایی دارد یا نه:

• یک داور برای هر ردیف. جدول منتشرشده توسط یک مدل نمره‌دهی شده بود و سخت‌افزار ما مدل دیگری را اجرا می‌کند، و مستندات خود هارنس می‌گوید نمرات این دو هرگز قابل‌مقایسه نیستند. پس پاسخ‌های منتشرشده‌ی هر رقیب را برداشتیم و با داور خودمان، کنار پاسخ‌های خودمان، دوباره نمره‌دهی کردیم: همان پنج کاربر، همان ۶۱۶ پرسش.

• تنظیمی که نمی‌تواند نشت کند. هر تغییر روی دو کاربر دیگر تنظیم شد و دقیقاً یک‌بار روی همان پنج کاربر گزارش‌شده، با قانونی که پیش از رسیدن هر نتیجه‌ای نوشته شده بود، نمره‌دهی شد.

اجرای اول ما را هم‌سطح RetainDB قرار داد و پشت سر آن دو تای دیگری که می‌توانستیم نمره‌دهی کنیم.

تنگنا عمق بازیابی بود، نه پاسخ‌دهی

تشخیص یک چیز بود، و آن رتبه‌بندی یا پاسخ‌دهی نبود. وقتی جمله‌ی درست به پنج نتیجه برتر ما می‌رسید، پاسخ در ۹۴ درصد موارد درست بود. فقط معمولاً به آنجا نمی‌رسید.

بیشتر خطاها در پنجاه نتیجه برتر جا داشتند، ولی رتبه‌شان آن‌قدر پایین بود که خوانده نمی‌شدند. جست‌وجوی کلیدواژه‌ای همچنین یک نقطه کور دارد که هیچ عمقی آن را رفع نمی‌کند: وقتی سوال شود که آیا محل سکونت کاربر تغییر کرده، نمی‌تواند جمله‌ای مثل «تازه به Melbourne نقل مکان کردم» را پیدا کند، چون حتی یک کلمه هم تطبیق پیدا نمی‌کند.

پس سه تغییر ایجاد کردیم و هر کدام را روی دو کاربر تنظیمی نمره‌دهی کردیم.

راه‌حل: جست‌وجوی معنایی و یادداشت‌های واقعیت که خودشان را به‌روزرسانی می‌کنند

جست‌وجوی معنایی یک مدل نیست. یک جدول embedding ایستا است، یک بردار برای هر تکه‌کلمه، میانگین‌گیری‌شده. با numpy و بدون شبکه اجرا می‌شود و ۷۱٬۰۶۲ نوبت مکالمه‌ی گذشته‌ی ما را در ۳۴ ثانیه روی یک لپ‌تاپ embed می‌کند. هوک هر-پرامپت همچنان هرگز به آن دست نمی‌زند.

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

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

یک‌بار نمره‌دهی شد، با mem0 در ۰.۵۲۰ مساوی شدیم

روی همان پنج کاربر گزارش‌شده، دقیقاً یک‌بار نمره‌دهی شد، نسخه نهایی با mem0 مساوی شد.

زیر این تساوی، ما در دو معیار جلوتریم و در دو معیار عقب:

دو نمره‌دهی مستقل از پاسخ‌های تقریباً یکسان ما، ۰.۰۰۷ تفاوت داشتند، پس این تساوی واقعاً تساوی است. آن را با سه احتیاط بخوانید:

• این پنج کاربر به همه مهربان‌اند. mem0 روی هر سی کاربر ۰.۳۹۲ منتشر می‌کند و اینجا ۰.۵۲۰ می‌گیرد، پس هیچ‌چیز در این جدول به‌طور مستقیم به جدول عمومی برنمی‌گردد.

• Honcho در این جدول نیست. در جدول عمومی پیشتاز است، اما در هر پرسش ۱۱۴٬۸۰۴ کاراکتر به مدل تحویل می‌دهد، و نمره‌دهی آن روی یک GPU با سرعت یک پرسش در دقیقه می‌خزید. به‌احتمال زیاد همچنان پیشتاز است.

• تساوی در دقت، برد نیست. حافظه‌ای که در دقت مساوی است در حالی که یک مکالمه را بیست برابر سریع‌تر، با نصف متن، ثبت می‌کند، محصولی متفاوت است، نه لزوماً بهتر. اینکه کدام‌یک اهمیت دارد، به قبض شما بستگی دارد.

حافظه‌ای که خودش را اصلاح می‌کند، دو سیستم است

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

مقاله‌ای درباره‌ی control plane های حافظه این را اندازه گرفت: قوانین قطعی روی یک دسته از پاک‌سازی ۵ درصد نمره می‌گیرند و یک مدل روی همان ۱۰۰ درصد، در حالی که همان مدل روی حذفِ آگاه-از-قصد که قوانین در آن خوب کار می‌کنند، صفر درصد نمره می‌گیرد. انجام هر دو ۲۷.۸ امتیاز سود می‌دهد. حافظه‌ی خودترمیم‌شونده به یک گذر قطعی و یک گذر مدلی در نقاط متفاوت نیاز دارد، هرگز فقط یکی از آن دو.

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

بدون محافظ، گذر مدلی حدود ۵۵ درصد درست بود، و هر اشتباه با اطمینان کامل رخ می‌داد. یک قانون دسترسی ثابت را با استفاده از یک یادداشت مرجع درباره جلسات کلود بازنشسته کرد. یک واقعیت درباره‌ی CDN یک محصول را با استفاده از یادداشت انتشار محصولی دیگر از بین برد، چون هر دو گفته بودند «CloudFront».

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

چهار محافظ و یک بازگردانی، ناظم را ایمن کرد

چهار محافظ این را رفع کرد:

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

دلیل اینکه اجرای بدون‌نظارت آن امن است، خوب‌بودنِ مدل در این کار نیست. این است که هیچ‌چیز هرگز حذف نمی‌شود، هر تصمیم در یک لاگ ممیزی ثبت می‌شود، و یک دستور آن را برمی‌گرداند.

حافظه‌های باطل‌شده با یک برچسب قابل‌مشاهده و یک جریمه‌ی رتبه‌بندی در مخزن باقی می‌مانند. واقعیت‌های قدیمی به‌جای ناپدید شدن، با نیمه‌عمر افول می‌کنند: وزن یک یادداشت پروژه هر ۱۵۰ روز نصف می‌شود، یک قانونی که کاربر داده اصلاً افول نمی‌کند.

هرگز محافظ‌ها را پایین نیاورید تا ناظم مولدتر به نظر برسد.

یک حافظه یک ادعاست، پس آن را بررسی کنید

این بخشی است که هیچ‌کدام از چیزهایی که بررسی کردیم انجام نمی‌دهند.

حافظه‌ای که در ماه می درست بود و بی‌سروصدا از درست‌بودن دست کشید، نامرئی است. با هیچ‌چیز تناقض ندارد، هیچ مسیر مرده‌ای را نام نمی‌برد، فقط همان‌جا می‌نشیند و اشتباه است.

مال ما یکی داشت که می‌گفت توکن‌های Instagram «هفتگی و به‌صورت خودکار توسط یک Lambda چرخانده می‌شوند». هیچ Lambdaای وجود نداشت. در کل عمرش هیچ چیزی هیچ توکنی را نچرخانده بود. ماه‌ها به‌عنوان درست خوانده می‌شد.

پس اکنون با هر حافظه مثل یک مجموعه‌ ادعا رفتار می‌شود، و ادعاها کاوش می‌شوند. یک مدل حافظه را می‌خواند و آرگومان‌های تایپ‌شده را برای یک مجموعه‌ی ثابت از کاوشگرها پر می‌کند: آیا این مسیر وجود دارد، آیا این برنچ وجود دارد، آیا این pull request مرج شده، آیا این پروژه‌ی Doppler وجود دارد، آیا این سکرت وجود دارد، آیا این نمونه (instance) وجود دارد، آیا این URL پاسخ می‌دهد.

مدل هرگز دستوری نمی‌نویسد. هر آرگومان پیش از اجرای هر چیزی اعتبارسنجی می‌شود، و نه تلاش prompt-injection علیه آن همگی رد شدند. شل نوشته‌شده توسط مدل روی یک زمان‌بندی، یک حفره‌ی remote code execution با چند مرحله‌ی اضافه‌تر است.

اولین اجرای کامل، ۳۸۳ ادعا را از ۳۶۵ حافظه استخراج کرد. ۳۲۸ تا قبول شدند. ۲۵ تا شکست خوردند، و شکست‌ها واقعی بودند:

یک حافظه اجازه دارد چه چیزی بگوید

دو قانون از این شکست‌ها بیرون آمد، و هر دو درباره‌ی این هستند که یک حافظه اجازه دارد چه چیزی بگوید.

وضعیت یک pull request یک واقعیت نیست، یک حال‌وهوا است. در عرض چند ثانیه تغییر می‌کند. استخراج‌کننده اکنون فقط «merged» را می‌پذیرد، چون merged نهایی است، و open یا closed را رد می‌کند. یازده ادعا کنار گذاشته شد.

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

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

یک ادعای شکست‌خورده، یک برچسب «تأییدنشده» روی حافظه می‌نویسد. بازیابی آن را کنار نتیجه نشان می‌دهد. انسان لازم نیست آن را دست بزند؛ حافظه با برچسب می‌رسد.

چه چیزی دزدیدیم، و از چه کسی

شانزده ایجنت پژوهشی ریپوها را خواندند، آن‌ها را روی کامیت‌های سنجاق‌شده کلون کردند، کد را اجرا کردند، و تلاش کردند یکدیگر را رد کنند. از ۶۴ ادعا، ۵۵ تا زنده ماندند. دو «نقل‌قول» جعلی بودند و یک جدول با جدولی دیگر عوض شده بود. به همین دلیل است که باید ایجنت‌های پژوهشی را فکت‌چک کنید.

گرفتن و رد کردن: سه ایجنت

گرفتن و رد کردن: بقیه‌ی میدان

یک استناد یک فرضیه است

یک رخداد از پژوهش سزاوار بخش مخصوص خودش است، چون همان اشتباهی است که هر کسی که مقاله‌ای مثل این را می‌خواند، در آستانه‌ی انجام‌دادنش است.

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

پرامپتِ غنی‌سازیِ ما صراحتاً به مدل گفته بود که واژه‌هایی که تولید می‌کند نباید در یادداشت ظاهر شوند. ما نیمه‌ی بازنده را تولید می‌کردیم، نیمه‌ی برنده را سرکوب می‌کردیم، و نیمه‌ی بازنده را با ضریب ۱.۷۵ تقویت می‌کردیم.

پس یافته را به کار بستیم. همه‌ی ۴۷۴ حافظه را دوباره استخراج کردیم. مجموعه‌آزمون از ۱۴ از ۱۶ به ۱۳ از ۱۶ افتاد. بدتر.

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

برگردانده شد، دوباره استخراج شد، برگشت به ۱۴ از ۱۶. چهل دقیقه، و اگر پیش از باور کردن اندازه‌گیری می‌کردیم، صفر می‌بود.

یک استناد، فرضیه‌ای درباره‌ی سیستم شخص دیگری است.

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

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

اجازه دادن به ایجنت برای نوشتن مهارت‌های خودش، آن را بدتر می‌کند

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

روی بنچمارکی از ۸۷ تسک با بررسی‌کننده‌های قطعی، مهارت‌هایی که ایجنت برای خودش تولید کرد، روی Claude Code با قوی‌ترین مدل، ۸.۱ امتیاز پایین‌تر از نداشتن هیچ مهارتی فرود آمدند. همین الگو روی دو هارنس دیگر هم صادق بود.

مهارت‌های گلچین‌شده توسط انسان، نرخ قبولی را از ۳۳.۹ درصد به ۵۰.۵ درصد رساندند. و مدلی که پرسیده می‌شود کدام‌یک از دو مهارت بهتر است، وقتی شکاف واقعی است، ۸۴ بار از ۱۰۰ بار، بدتری را انتخاب می‌کند.

طول اهمیت دارد به شیوه‌ای که هیچ‌کس انتظارش را ندارد. یک تپه است، نه یک شیب:

بعد از یک صفحه، مستندسازی دیگر کمکی نمی‌کند.

نسخه‌ای که ساختیم منتظر یک انسان می‌ماند

پس نسخه‌ای که ساختیم، نقطه مقابل خودمختار است. فقط رویه‌ای را تشخیص می‌دهد که در سه جلسه‌ی جداگانه یا بیشتر تکرار شده، و این را با شمارش می‌داند، چون همه‌ی ۷۱٬۰۶۲ نوبتِ رونوشت ایندکس شده، پس «آیا این تکراری است» یک کوئری پایگاه‌داده است، نه حدس یک مدل.

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

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

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

چه چیزی هنوز اشتباه است

صداقت از جایگزینش ارزان‌تر است، پس این هم ته‌مانده.

لایه‌ی همیشه-روشن هنوز سه تا چهار برابر سنگین‌تر از مال Hermes است، امروز حدود ۲۴٬۰۰۰ بایت، و یک ایندکس است نه یک پروفایل. لاغری‌ای که تحسینش می‌کردیم از سازوکاری می‌آید که رد کردیم، و هنوز نسخه‌ی ملایم‌تری پیدا نکرده‌ایم که همان انضباط را تولید کند.

سازگاری در سراسر مرزها اجرا نمی‌شود. لحظه‌ای که پروفایل کاربر عرضه شد، هر واقعیتی در آن دو بار وجود داشت. ناظم، حافظه را در برابر حافظه بررسی می‌کند، نه پروفایل را در برابر مخزن، و نه حافظه را در برابر فایل دستورالعمل خود پروژه. Honcho اثبات این است که دو دیدگاه استخراج‌شده از یک واقعیت، سرانجام با هم اختلاف پیدا می‌کنند و مدل از دیدگاه اشتباه پیروی می‌کند.

ثبت، در پایان جلسه و پیش از فشرده‌سازی فعال می‌شود، که دقیقاً همان زمانی است که نوشتن مطمئنِ توالی‌ای که هرگز کار نکرد، محتمل‌ترین است. استناد ردشده‌ی بالا نمونه‌ی زنده‌ی همین است.

یک حافظه فقط به‌اندازه‌ی کاوشگرهایش قابل‌بررسی است. یک مسیر، یک برنچ، یک pull request، یک سکرت و یک نمونه (instance) قابل‌تأیید هستند. «سه هزار تا از آن ردیف‌ها متعلق به آن صفحه هستند» نمی‌تواند، و «کاربر X را ترجیح می‌دهد» اصلاً یک ادعا نیست.

مخزن هنوز می‌تواند یک بیانیه‌ی به‌آرامی نادرست را نگه دارد؛ فقط نمی‌تواند یک مسیرِ به‌آرامی نادرست را نگه دارد.

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

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

شش قانون

اگر فقط یک چیز از این دفترچه بردارید، این فهرست را بردارید.

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

هیچ‌کس آن نیمه را نمی‌فروشد، چون یک ویژگی نیست. یک انضباط است، و باید در کد کامپایل شود تا لازم نباشد کسی آن را به‌خاطر بسپارد.

کد، آداپتور بنچمارک و هر نتیجه‌ی نمره‌دهی‌شده، متن‌باز هستند در github.com/brainyboon/quipu.

اگر می‌خواهید بقیه‌ی چیزهایی که Boon روی آن‌ها کار می‌کند را ببینید، از Claude Code برای طراحان شروع کنید، سرورهای MCP که به یک ایجنت دست می‌دهند، ایجنت‌های هوش مصنوعی برای طراحان، و هزینه‌ی توکن‌های یک ایجنت، که همان قبضی است که این حافظه آن را صفر نگه می‌دارد. اگر می‌خواهید این سطح از دقت روی برند خودتان اعمال شود، Brainy Studio جایی است که از آنجا شروع می‌شود.

---

سوالات متداول

چرا Claude Code چیزهایی را که در MEMORY.md می‌گذارم فراموش می‌کند؟

Claude Code ایندکس حافظه‌ی خودکار را تا ۲۰۰ خط یا ۲۵٬۰۰۰ بایت بارگذاری می‌کند، هر کدام زودتر به آن برسد، و بقیه را بی‌سروصدا نادیده می‌گیرد. فایل جدیدترین‌ها را در انتها اضافه می‌کند و از پایین قطع می‌شود، پس تازه‌ترین حافظه‌ها اول می‌افتند. اگر ایجنت قانونی را که اخیراً اضافه کرده‌اید نادیده می‌گیرد، خطوط و بایت‌های فایل را بشمارید.

آیا باید یک پلاگین حافظه برای Claude Code نصب کنم؟

دو چیز را بررسی کنید: آیا یک مدل در مسیر پرامپت اجرا می‌کند، که چند ثانیه به هر پرامپت اضافه می‌کند، و آیا یک daemon در پس‌زمینه اجرا می‌کند، که بیشتر ایشوهای باز بزرگ‌ترین پلاگین‌ها آنجا زندگی می‌کنند. چیزی که مشکل ما را حل کرد، یک ایندکس تمام‌متن بود که در هر پرامپت جست‌وجو می‌شود، گذرهای آفلاینِ مدل، و یک مرحله‌ی تأیید. هیچ‌کدام از این‌ها به یک daemon نیاز ندارد.

آیا جست‌وجوی کلیدواژه‌ای واقعاً برای حافظه‌ی ایجنت‌های هوش مصنوعی کافی است؟

برای هوک هر-پرامپت، بله. در بنچمارک استاندارد بازیابیِ zero-shot، هر مدل embedding تک‌برداری از جست‌وجوی کلیدواژه‌ایِ ساده‌ی BM25 باخت، و یک reranker عصبی حدود ۱.۵ ثانیه بارگذاری مدل هزینه دارد در برابر بودجه‌ی ۱۸ میلی‌ثانیه‌ای. برای جست‌وجوی مکالمات گذشته کافی نیست: یک جدول embedding ایستا، یک جست‌وجوی مستقیم به‌جای یک مدل، جمله‌ای که تغییری را اعلام می‌کند، دو برابر بیشتر از کلیدواژه پیدا کرد. اگر ساده‌لوحانه با رتبه‌بندی کلیدواژه‌ای ترکیب شود، نتایج را بدتر می‌کند؛ اگر بر اساس رتبه ترکیب شود و به‌شکل گسترده جمع‌آوری شود، بخشی از چیزی است که با mem0 مساوی شد.

آیا این سیستم حافظه متن‌باز است؟

بله. پلاگین، آداپتور بنچمارک MemConflict، متد و هر خلاصه‌ی نمره‌دهی‌شده در github.com/brainyboon/quipu تحت لایسنس MIT موجودند. هسته فقط به کتابخانه‌ی استاندارد Python نیاز دارد؛ جست‌وجوی معنایی به numpy نیاز دارد.

چطور جلوی حافظه را می‌گیرید که چیزی نادرست را باور نکند؟

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

اجرای این سیستم حافظه چه هزینه‌ای دارد؟

در حاشیه، صفر دلار: بازیابی یک کوئری پایگاه‌داده‌ی محلی است، و هر فراخوانی مدل (ثبت در پایان جلسه، غنی‌سازی حافظه‌های جدید، پویش روزانه‌ی تناقض) از طریق اشتراکی می‌گذرد که از قبل پرداخت شده، هرگز یک API اندازه‌گیری‌شده. هزینه‌ی واقعی، سهمیه‌ی پلن است، تقریباً یک فراخوانی کوچک به ازای هر جلسه. در بنچمارک MemConflict، یک مکالمه را در ۱.۶ ثانیه ثبت کرد، در برابر ۳۱.۶ ثانیه برای mem0 روی همان دستگاه.