حافظه ترکیبی گراف-بردار در Cognee مشکل فراموش‌کاری عامل‌های هوش مصنوعی را حل کرد

تصور کنید یک معلم خصوصی دارید که هر بار شما را می‌بیند، تمام پیشینه تحصیلی شما را فراموش کرده است. این سناریوی کلافه‌کننده، هسته مرکزی چالش‌های توسعه در هکاتون WeMakeDevs Hangoverでした که بین ۲۹ ژوئن تا ۵ جولای ۲۰۲۶ برگزار شد. شعار این رویداد با جمله‌ای طنزآمیز شروع شد: «یک هوش مصنوعی در وجاس بیدار شد، در حالی که هیچ خاطره‌ای از شب گذشته نداشت.» این premise ساده اما تکان‌دهنده، تعریف‌کننده مسیر پروژه Continuum بود. در این پروژه، هدف ساخت یک معلم هوشمند بود که تاریخچه دانش‌آموز را فراموش نکند و ثابت کند که ایجاد حافظه واقعی در یک عامل (Agent) — یعنی موجودیتی که می‌تواند به‌طور مستقل تصمیم بگیرد و عمل کند — یک چالش ساختاری است، نه یک مسئله‌ی مربوط به نحوه نوشتن پرامپت‌ها.

بیشتر برنامه‌نویسان حافظه را به‌عنوان یک افزونه‌ی ساده یا یک فکر afterthought می‌بینند؛ مثلاً در ساعت ۲ صبح و در آخرین لحظات توسعه، یک جدول ساده در پایگاه‌داده می‌سازند، یک دیکشنری تصادفی ایجاد می‌کنند یا لیستی از پنج پیام آخر را در پنجره زمینه (Context Window) می‌چپانند. پنجره زمینه شبیه میز کاری است که فقط جای چند ورق کاغذ دارد، نه کل کتابخانه. همان‌طور که در تحلیل‌های پیشین ما درباره ابزارهای تخصصی برای رفع نیازهای برنامه‌نویسان اشاره کردیم، این رویکرد منجر به ایجاد سیستمی شکننده می‌شود که به محض لغزش اطلاعات از پنجره زمینه، کانتکست کاملاً گم می‌شود. پروژه Continuum اما حافظه را از یک افزونه به قلب معماری منتقل کرد.

مکانیسم: فراتر از جست‌وجوی برداری

پایگاه‌های داده‌ی برداری استاندارد، جست‌وجوی معنایی ارائه می‌دهند که اساساً «تخت» است. در این سیستم، شما یک متن را به بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — تبدیل می‌کنید و ذخیره می‌کنید. سپس در زمان نیاز، بر اساس شباهت معنایی، تکه‌هایی از متن را بازیابی می‌کنید. در این حالت، هر تکه اطلاعات به گونه‌ای برخورد می‌کند که انگار هیچ رابطه تعریف‌شده‌ای با تکه‌های دیگر ندارد و آن‌ها هیچ پیوندی با یکدیگر ندارند.

Cognee این مشکل را با پیاده‌سازی یک لایه‌ی حافظه ترکیبی گراف-بردار حل می‌کند. به نقل از توسعه‌دهندگان پروژه، وقتی سیستم تابع remember() را صدا می‌زند، صرفاً یک بردار نمی‌سازد؛ بلکه یک مرحله استخراج (extraction pass) را اجرا می‌کند تا موجودیت‌ها و روابط (entities and relationships) را شناسایی کرده و آن‌ها را به‌صورت گره‌ها و یال‌ها در یک گراف دانش (Knowledge Graph) ذخیره کند. این قابلیت به عامل اجازه می‌دهد در طول فرآیند بازیابی (recall())، در گراف گشت‌زنی (traversal) کند. این توانمندی است که عامل را قادر می‌سازد اطلاعاتی را که در زمان‌های مختلف و در قالب موضوعات متفاوت به او گفته شده، به هم متصل کند و به پرسش‌های پیچیده چند-گامی (multi-hop questions) پاسخ دهد. این رویکرد مکمل راهکارهای دیگری است که در پروژه‌هایی مانند Lorekeeper برای کاهش فراموشی عامل‌ها از طریق چرخه‌های بازاندیشی به کار گرفته شده‌اند.

این تفاوت معماری در حوزه آموزش حیاتی است. یک حافظه برداری تخت ممکن است فقط یک حقیقت ساده را ثبت کند: «دانش‌آموز سوال ۴ را غلط جواب داد». اما Cognee می‌تواند زنجیره‌ای از روابط منطقی را ترسیم کند: دانش‌آموز در مفهوم «علامت» در تجزیه دچار اشتباه است $\rightarrow$ این مفهوم پیش‌نیاز «مربع کامل» است $\rightarrow$ و حالا دانش‌آموز در همین نقطه متوقف شده است. این رویکرد دوم است که در واقعیت یک سیستم را قادر می‌سازد تا به‌طور مؤثرتر آموزش دهد.

عملیات کلیدی و پیاده‌سازی

بر اساس گزارش Build Log پروژه، Cognee چهار عملیات اصلی دارد که شالوده چرخه شناختی عامل را می‌سازند. شعار آن‌ها «بازیابی کامل» (Total Recall) است و داوران هکاتون به‌طور مشخص روی میزان عمیق بودن استفاده از این عملیات‌ها نمره داده‌اند:

• remember(): متن‌ها، فایل‌ها یا URLها را دریافت کرده و آن‌ها را در گراف دانش ساختارمند می‌کند.
• recall(): گراف را با یک پرسش به زبان طبیعی می‌کاوَد و نتایج مرتبط را با استفاده از هر دو روش «شباهت معنایی» و «گشت‌زنی گراف» بازمی‌گرداند.
• improve(): یک مرحله غنی‌سازی پس از جذب داده (post-ingestion) را اجرا می‌کند تا گره‌ها را بازوزن‌بندی کرده و داده‌های قدیمی یا تکراری را هرس کند. این فرآیند هرس و پالایش داده‌ها یادآور اهمیت حذف نویز در حافظه هوش مصنوعی است که گاهی از افزایش قدرت خام مدل‌های زبانی ارزشمندتر می‌شود.
• forget(): داده‌های خاصی را به‌صورت جراحی‌شده و دقیق از گراف حذف می‌کند، بدون اینکه کل تاریخچه پاک شود.

یک نکته فنی بسیار حیاتی این است که عملیات remember() به کلید API یک مدل زبانی بزرگ (LLM) نیاز دارد. برخلاف پایگاه‌های برداری خالص که فقط به یک Embedding Model نیاز دارند، Cognee در لایه داخلی خود برای انجام مرحله استخراج گراف از یک LLM استفاده می‌کند. این موضوع در طی تنظیمات اولیه یکی از نقاط اصطکاک بود، زیرا کاربر انتظار یک گردش کار ساده‌ی برداری را داشت، اما متوجه شد که فراخوانی داخلی LLM برای استخراج ضروری است. پس از پیکربندی در فایل .env سیستم طبق انتظار عمل کرد.

زیرساخت و مدیریت سرویس

برای پشتیبانی از این عملیات‌های ناهمگام (Async)، پروژه از FastAPI استفاده می‌کند. از آنجایی که توابع remember()، recall()، improve() و forget() همگی توابع Asynchronous هستند و با عملیات‌های IO (مانند فراخوانی LLMها، نوشتن در دیتابیس و گشت‌زنی در گراف) سروکار دارند، استفاده از یک سرور همگام (Synchronous) باعث مسدود شدن سیستم یا بروز خطاهای پیچیده در Event Loop می‌شد؛ خطاهایی که معمولاً در اواخر چرخه توسعه ظاهر می‌شوند (به قول توسعه‌دهنده: «خطاهایی که ساعت ۱۱ شب روز چهارم شما را به گریه می‌اندازند»).

FastAPI به دلیل پشتیبانی بومی از async انتخاب شد تا برنامه‌نویسان بتوانند مستقیماً در Route Handlerها، فراخوانی‌های Cognee را await کنند. مزایای تکمیلی این انتخاب عبارت بودند از:

• مستندات خودکار OpenAPI: این ویژگی به هم‌تیمی‌های بخش فرانت‌اند اجازه داد بدون اینکه توسعه‌دهنده بک‌اند تک‌تک Endpointها را توضیح دهد، ساختار API را درک کنند.
• اعتبارسنجی نوع با Pydantic: تضمین سلامت و یکپارچگی داده‌ها در تمامی سرویس‌های حافظه.
• قلاب Startup lifespan: این بخش به‌طور خاص برای اعتبارسنجی پیکربندی‌های محیطی و کلیدهای API پیش از پذیرش درخواست‌ها پیاده‌سازی شد. این کار از بروز خطاهای مبهم ۵۰۰ در زمان دموهای زنده جلوگیری کرد، چرا که کلیدهای گم‌شده را در همان لحظه استارت‌آپ با پیام‌های خطای واضح شناسایی می‌کرد.

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

۱. عیب‌یابی متمرکز: هرگونه شکست مربوط به حافظه در یک فایل ایزوله شده است و در موتور تدریس، سرویس نمره‌دهی، انتخاب‌گر استراتژی یا روترهای مختلف پخش نشده است.
۲. قابلیت حسابرسی (Auditability): هر فراخوانی از چهار عملیات اصلی در یک فایل JSON همراه با برچسب زمانی (Timestamp)، شناسه‌ی دانش‌آموز، مجموعه داده و شرحی به زبان ساده از Trigger ثبت می‌شود. این کار یک «رسید زمان‌بندی شده» از فرآیند شناختی AI ایجاد کرد تا معیار «بهترین استفاده از Cognee» برای داوران ملموس باشد.
۳. انضباط معماری: این کار از «رانش معماری» (Architectural Drift) در محیط پرشتاب هکاتون جلوگیری کرد و یک استاندارد تیمی ایجاد کرد که هیچ‌کس برای دسترسی مستقیم به Cognee، سلسله‌مراتب سرویس را دور نزند.

این ماژول شامل پنج تابع است که به چهار عملیات Cognee و یک ابزار خواندن Log نگاشت شده‌اند:

• remember_interaction(): توصیفی ساختارمند از تلاش یک دانش‌آموز را ذخیره می‌کند.
• recall_student_context(): یک شناسه‌ی دانش‌آموز و رشته پرس‌وجو را می‌گیرد تا تاریخچه مرتبط را بازگرداند.
• improve_student_memory(): مرحله غنی‌سازی را روی مجموعه داده‌های خاص یک دانش‌آموز اجرا می‌کند.
• forget_resolved_misconception(): باورهای غلط اصلاح‌شده را هرس کرده و مجدداً improve() را اجرا می‌کند تا گراف پاکیزه بماند.
• get_lifecycle_log(): تاریخچه رویدادها را بازمی‌گرداند که بر اساس شناسه‌ی دانش‌آموز قابل فیلتر است.

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

نتیجه و گردش کار

پیش از نوشتن کدهای اصلی اپلیکیشن، توسعه‌دهنده یک تست «اثبات حیات» (Proof-of-life) با استفاده از یک اسکریپت ساده پایتون به نام test_cognee.py اجرا کرد. این یک Unit Test یا pytest fixture نبود، بلکه یک اسکریپت موقت بود که سه کار انجام می‌داد: فراخوانی remember() با یک تعامل جعلی دانش‌آموز، سپس فراخوانی recall() برای پرس‌وجو و در نهایت چاپ نتیجه.

این تمرین ۴۰ دقیقه‌ای (که شامل زمان مطالعه مستندات برای تنظیم صحیح Config بود)، از جلسات عیب‌یابی فاجعه‌بار در روز سوم جلوگیری کرد. با تایید اینکه گشت‌زنی گراف می‌تواند اطلاعات درستی را از یک حقیقت که تنها ۱۰ ثانیه پیش ذخیره شده بود استخراج کند، توسعه‌دهنده ثابت کرد که سیستم یک «اسباب‌بازی» نیست و می‌تواند در مقیاس صدها تعامل عمل کند.

تا پایان روز اول، پروژه هیچ منطق تدریسی، سیستم تولید سوال، سیستم نمره‌دهی یا المان‌های رابط کاربری نداشت. در عوض، یک زیربنای تاییدشده داشت:

• یک محیط مجازی (Virtual Env) با چهار وابستگی (Dependency).
• یک فایل .env.example برای تنظیمات سریع هم‌تیمی‌ها.
• یک فایل config.py که متغیرهای محیطی را در هنگام استارت‌آپ متمرکز و اعتبارسنجی می‌کرد.
• سرویس memory.py با هر چهار عملیات و قابلیت Log فعال.
• یک فایل tests/test_memory_service.py که کامل‌ترین چرخه remember-recall-improve-forget را تایید کرده و Logها را بررسی می‌کرد.
• یک اپلیکیشن FastAPI در main.py با یک Endpoint فعال برای Health Check و یک README جامع برای اجرای سرور.

این رویکرد «اول حافظه»، تالاری از داده‌های پویا می‌سازد که به‌جای تکیه بر ارسال پیام‌های اخیر به مدل، یک گراف دانش تکامل‌یافته برای هر کاربر نگه می‌دارد. در این سیستم، باورهای غلط اصلاح‌شده هرس می‌شوند تا داده‌های منقضی‌شده آموزش‌های آینده را آلوده نکنند و تاریخچه مرتبط از طریق گشت‌زنی (Traversal) به‌جای تطبیق ساده کلمات کلیدی (Keyword Matching) بازیابی می‌شود.

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

گام بعدی شما

• اگر از Vector DB استفاده می‌کنید، بررسی کنید چه مقدار از داده‌های شما رابطه‌مند هستند و نیاز به ساختار گراف دارند.
• مستندات Cognee را برای پیاده‌سازی لایه‌ی improve() جهت پاکسازی داده‌های تکراری و غنی‌سازی گره‌ها مطالعه کنید.
• تفاوت هزینه و سرعت توکن‌ها در گشت‌زنی گراف در مقابل تزریق کل Context را در پروژه‌های خود اندازه بگیرید.

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