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

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

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

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

این باگ یک اسم دارد

نوشتنِ دقیق، بازیابیِ اختیاری. کل باگ تکرار-خودت این است.

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

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

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

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

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

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

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

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

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

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

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

نمره‌ی کامل که ۱۷٪ درست بود

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

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

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

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

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

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

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

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

قانون یگانه: هیچ مدلی در مسیر پرامپت نباشد

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

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

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

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

این تفکیک چه هزینه‌ای دارد

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

دو اندازه‌گیری کوچک‌تر این قانون را ملموس می‌کنند. یک مدل embedding کوچک حدود ۱.۵ ثانیه فقط برای بارگذاری هزینه دارد، در فرآیندی که در هر پرامپت با بودجه‌ی ۱۸ میلی‌ثانیه از نو شروع می‌شود.

وارد کردن یک کتابخانه‌ی عددی سرد ۷۰ میلی‌ثانیه هزینه دارد در برابر یک فرآیند خام ۱۷ میلی‌ثانیه‌ای. سه برابر کل بودجه، برای صرفه‌جویی در ۰.۰۲ میلی‌ثانیه محاسبات. جستجوی کلیدواژه در تأخیر برنده می‌شود قبل از اینکه اصلاً بحث کیفیت شروع شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

چهار محافظ، و یک بازگشت

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

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

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

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

هرگز محافظ‌ها را پایین نیاورید تا کیوریتور را پرکارتر نشان دهید.

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

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

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

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

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

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

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

پنج حافظه به پروژه‌های Doppler اشاره می‌کردند که دیگر وجود نداشتند. پنج pull request که حافظه‌ها آن‌ها را باز خوانده بودند ادغام شده بودند. هفت مسیر فایل مرده بودند. یک حافظه گفته بود یک ریپازیتوری خصوصی است و عمومی بود.

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

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

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

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

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

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

چه چیزی را دزدیدیم، و از کجا

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

طول اهمیتی دارد که هیچ‌کس انتظارش را ندارد. مهارت‌های فشرده ۱۹ امتیاز کسب کردند، استاندارد ۲۱.۵، تفصیلی ۱۴.۵، جامع ۰.۷. این یک کوهان است، نه یک شیب. بعد از یک صفحه، مستندسازی کمک‌کننده بودن را متوقف می‌کند.

نقطه‌ی مقابل خودمختاری

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

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

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

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

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

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

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

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

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

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

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

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

پنج قانون

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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