حافظهٔ گرافی، راهحل حافظهٔ مشترک برای ایجنتهای هوش مصنوعی
خلاصهٔ کاملتر
نویسنده (Neo Kim) با یه سناریوی آشنا شروع میکنه: چندتا ایجنت هوش مصنوعی روی یه پروژه کار میکنن؛ چندتا ایجنت کدنویسی تو ترمینال، یه چتبات تو مرورگر، یه ایجنت روی AWS. مشکل اینه که هرکدوم حافظهٔ «خودش» رو داره؛ ایجنت ترمینال نمیدونه ۱۰ دقیقه پیش به چتبات مرورگر چی گفتی، و تو باید تصمیمها و زمینه (context) رو دستی بینشون جابهجا کنی. یه «حافظهٔ مشترک» که همه بتونن ازش بخونن و توش بنویسن، غایبه.
نویسنده میگه راههای بدیهی برای ساختن این حافظه خوب کار نمیکنن. اولی پوشهٔ اسناد مشترکه (Notion، Google Drive، ویکی): این فقط یه تودهٔ متنه بدون ساختاری که ایجنت بتونه روش استدلال کنه. اگه جواب سؤال تو ۲۰۰ تا فایل پخش باشه، ایجنت نمیفهمه «دیپلوی»، «سرویس» و «آدم» مفهومهای جدان و یا باید همهچی رو بخونه یا به عادت کلاسیک توهمزدن پناه میبره. پوشه «متن» ذخیره میکنه، نه «دانش».
دومی دیتابیس برداریه که با RAG بهش سؤال میدی و نزدیکترین تکههای متن رو برمیگردونه. این برای «اون پاراگراف دربارهٔ X رو پیدا کن» خوبه، ولی هیچ رابطه یا نوعی نگه نمیداره؛ نمیتونه از مشتری شروع کنه، به تیکتهای بازش و بعد به مهندس کشیک و بعد به کامیتی که احتمالاً باگ رو ساخته برسه. فقط یه مشت قطعهٔ شبیهبههم بهت میده و وصلکردن نقطهها با خودته.
نویسنده میگه یه حافظهٔ مشترک باید سه کار بکنه: خوندن (سرهمکردن زمینه از روی واقعیتهای بههموصل)، نوشتن (ماندگارکردن دانش جدید بعد از تمومشدن کار) و هماهنگی (اجازه دادن به چند ایجنت برای خوندن و نوشتن همزمان بدون بازنویسی همدیگه). خوندن و نوشتن جدید نیست، ولی هماهنگی مسئلهٔ اصلیه؛ چون سیستمهای سنتی فرض میکنن چندتا نویسندهٔ قطعی دارن بهروزرسانیهای کوتاه و محتاطانه میکنن، ولی ایجنتها دقیقهها استدلال میکنن، نتیجههای قبلی رو بازنویسی میکنن و اشتباه هم میکنن.
راهحل، حافظهٔ گرافیه. واقعیتها رو نقطه (گره/node) و رابطهها رو خط (یال/edge) در نظر بگیر: مشتری یه گره، هر تیکتش یه گره، مهندس صاحب تیکت یه گره، کامیت مقصر یه گره؛ همه با یال به هم وصل. برای جواب دادن، سیستم هزاران سند رو نمیگرده، بلکه از رو یالهای موجود چند پرش میکنه (مشتری ← تیکت ← مهندس ← کامیت). گراف، رابطه رو کنار خود واقعیت ذخیره میکنه؛ همون چیزی که تا حالا کم بود.
نویسنده تأکید میکنه که گراف بهتنهایی کافی نیست و به «اسکیما» نیاز داره. اگه سه ایجنت یه رویداد رو با سه کلمهٔ «deploy»، «deployment» و «release» بنویسن، برای گراف اینا سه گره جدان و یه کوئری «همهٔ دیپلویهای این هفته» بیسروصدا فقط بخشی از جواب رو میده؛ نتیجه کامل به نظر میرسه ولی غلطه. راهحل اینه که گراف رو قبل از اینکه کسی توش بنویسه تعریف کنی تا همه یه واژگان مشترک داشته باشن.
مطالعهٔ موردی مقاله ابزار متنباز Omnigraphه که ایدهاش شبیه «گیت برای حافظهٔ AI»ه: به هر ایجنت یه شاخهٔ ایزوله از همون گرافِ نوعدار میده تا موازی داده رو غنی کنن، بعد آدمها عمداً تغییرها رو بازبینی، تأیید و ادغام میکنن؛ اینطوری اشتباه یه ایجنت بلافاصله به ورودی همه تبدیل نمیشه. این ابزار روی Lance و Arrow و DataFusion ساخته شده، حالت گراف رو تو object storage (مثل S3) بهصورت اتمیک ذخیره میکنه و مجوزش MITه. دسترسی هم با یه سیستم سیاست (به زبان Cedar از AWS) و توکنِ هویت در سطح شاخه کنترل میشه، و چون هیچ دادهای درجا بازنویسی نمیشه، هر تغییر برگشتپذیره و تاریخچهٔ کامیتها همون رد ممیزی (audit) رو میسازه.
نکتهٔ فنی جالب آخر اینه که یه کوئری همزمان سهجور جستوجو میکنه: پیمایش گراف برای رابطهها، جستوجوی تماممتن (BM25) برای کلمات دقیق، و جستوجوی برداری (k-NN با شباهت کسینوسی) برای معنا. بهجای نگهداشتن سه سیستم جدا که از هم عقب میافتن، Omnigraph یه نسخهٔ گراف نگه میداره و سه ایندکس روش میسازه، بعد نتیجهها رو با روش Reciprocal Rank Fusion (RRF) با هم ترکیب میکنه. نویسنده در آخر میگه این حافظه برای جایی خوبه که چند ایجنت روی یه دانش مشترک در طول زمان کار میکنن، ولی برای هر باری مناسب نیست؛ بزرگترین محدودیتش تأخیر نوشتنه.
نکات کلیدی:
- چند ایجنت روی یه پروژه هرکدوم حافظهٔ جدا دارن و به یه حافظهٔ مشترک نیاز دارن
- پوشهٔ مشترک و دیتابیس برداری رابطه بین دادهها رو نگه نمیدارن و موقع نوشتن همزمان بههم میریزن
- حافظهٔ گرافی دادهها رو گره و رابطهها رو یال میکنه تا بشه از یه واقعیت به واقعیت مرتبط رفت
- بدون اسکیمای مشترک، ایجنتها واژگان جدا میسازن و کوئریها بیسروصدا ناقص جواب میدن
- Omnigraph مثل «گیت» به هر ایجنت شاخهٔ جدا میده تا آدمها تغییرها رو بازبینی و ادغام کنن
- یه کوئری همزمان پیمایش گراف، جستوجوی کلمه (BM25) و جستوجوی معنایی (برداری) رو با RRF ترکیب میکنه




