چطور Datalog می‌تواند از فراموشی حقایق در عامل‌های هوش مصنوعی جلوگیری کند؟

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

حفظ یک وضعیت سازگار در تحلیل‌های طولانی، نبردی علیه آنتروپی است. طبق گزارش pwning.systems در ۲۸ اوت ۲۰۲۶، مدل‌های زبانی حتی وقتی به آن‌ها می‌گوییم اشتباه کرده‌اند، لزوماً تمام استنتاج‌هایی که بر پایه آن اشتباه بنا شده بود را رها نمی‌کنند. یک مدل ممکن است یک فرض غلط را فراموش کند، رویکردی را پیشنهاد دهد که قبلاً رد شده است، یا بر اساس مشاهده‌ای استدلال کند که دیگر معتبر نیست. این چالش تکرار خطاها، پیش از این در مکانیزم‌های لایه نشانی اصلاحات مورد بررسی قرار گرفته بود تا از تکرار اشتباهات توسط عامل‌ها جلوگیری شود. Lemmalog برای حل این مشکل، حافظه را نه به عنوان یک مسئله بازیابی، بلکه به عنوان یک مسئله تحلیل برنامه می‌بیند. به جای تکیه بر «حس» شباهت کسینوسی در یک پایگاه‌داده برداری، از یک زبان برنامه‌نویسی منطقی اعلامی به نام Datalog استفاده می‌کند تا دقیقاً ثبت کند چه چیزی درست است و چرا.

همان‌طور که در تحلیل قبلی ما درباره‌ی ضعف مدل‌های زبانی در محاسبات دقیق — مانند ریاضیات مربوط به ساخت دسته کارت (deckbuilding) — اشاره کردیم، این مدل‌ها در استخراج داده‌های نامنظم عالی هستند اما در حفظ یک وضعیت قطعی از دانش در طول زمان شکست می‌خورند.

مکانیزم: از ابهام به قطعیت

بیشتر سامانه‌های حافظه از تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — استفاده می‌کنند. در این روش، گفتگوهای قدیمی به صورت بردار معنایی (Embedding) ذخیره می‌شوند. وقتی پرسشی مطرح می‌شود، سیستم تکه‌هایی را که «شبیه‌ترین» هستند بازیابی می‌کند. مشکل اینجاست که اگر حقیقتی دو ساعت پیش اصلاح شده باشد، سیستم باز هم ممکن است نسخه قدیمی و غلط را بازیابی کند چون از نظر معنایی به پرسش مرتبط است. یک پایگاه‌داده برداری می‌تواند جمله‌ای مانند «شیء A به شیء B اشاره می‌کند» را بازیابی کند چون مرتبط است، اما ذاتاً نمی‌داند که این جمله بعداً رد شده یا پنج نتیجه‌گیری دیگر به آن وابسته بوده‌اند.

Lemmalog فرآیند حافظه را به دو لایه متمایز تقسیم می‌کند:

• بخش جلویی مبهم (Fuzzy Front-end): یک مدل زبانی بزرگ (LLM) مانند Claude Sonnet 4.6، زبان طبیعی، کد منبع یا خروجی دیباگر را به حقایق ساختاریافته تبدیل می‌کند. این مدل برای استخراج در مرحله ورود داده‌ها استفاده می‌شود و برای بهینه‌سازی هزینه‌ها از تکنیک‌های تکه‌تکه کردن (chunking) و کش کردن فایل‌ها بهره می‌برد. این لایه بخش «نامنظم» را مدیریت می‌کند؛ مثلاً تبدیل جمله‌ای مانند «LLDB نشان می‌دهد که شیء آزاد شده، بعداً به عنوان مقصد نوشتن دوباره استفاده می‌شود» به حقایق ساختاریافته‌ای مثل freed(object_a) و reused_as(object_a, write_target).
• بخش پشتی قطعی (Deterministic Back-end): یک موتور Datalog این حقایق را ذخیره کرده و قوانین استنتاجی را برای رسیدن به نتایج جدید اعمال می‌کند. این موتور بخش قطعی شامل حقایق، قوانین و حقایق مشتق شده را مدیریت می‌کند.

به عنوان مثال، اگر LLM استخراج کند که مهاجم کنترل object_a را دارد، object_a به object_b اشاره می‌کند و object_b یک شیء هسته (Kernel Object) است، موتور Datalog به‌طور خودکار نتیجه می‌گیرد که مهاجم کنترل یک شیء هسته را دارد. این کار از طریق قانونی مانند این انجام می‌شود: controls_kernel_object(Attacker) :- controls(Attacker, ObjectA), points_to(ObjectA, ObjectB), kernel_object(ObjectB).

اگر محقق بعداً از طریق LLDB متوجه شود که object_a در واقع به object_b اشاره نمی‌کند، موتور فقط یک یادداشت جدید اضافه نمی‌کند، بلکه به‌طور خودکار هر نتیجه‌گیری که به آن پیوند خاص وابسته بود را باطل می‌کند. این امر مانع از آن می‌شود که مدل مجبور شود کل تحقیق را از روی متن گفتگو بازسازی کند و امیدوار باشد که پیامدهای تغییر را متوجه شود. Lemmalog با تحقیق مانند یک موتور تحلیل استاتیک برخورد می‌کند: حقایق و قوانین ورودی منجر به یک «نقطه ثابت» (fixed point) محاسبه شده از تمام دانسته‌های فعلی می‌شوند.

زمینه: موازی‌سازی با تحلیل برنامه

این رویکرد دقیقاً مشابه تحلیل سنتی برنامه‌هاست. در یک تحلیل استاندارد، سیستم مجموعه‌ای از حقایق و قوانین را برای استخراج حقایق اضافی حفظ می‌کند. برای مثال، اگر سیستم بداند calls(foo, bar) و calls(bar, baz)، قانونی تعریف می‌شود که اگر تابعی تابع دیگری را صدا بزند و آن تابع به سومی برسد، پس اولی می‌تواند به سومی دسترسی داشته باشد.

در تحلیل برنامه، وقتی یک حقیقت ورودی تغییر می‌کند، تکنیک‌هایی وجود دارد که فقط نتایج متأثر را به‌روزرسانی کنند، نه اینکه کل فرآیند را از اول اجرا کنند. Lemmalog این منطق را در حافظه LLM به کار می‌برد. سیستم مانند یک «کامپایلر عجیب» عمل می‌کند که در آن LLM بخش جلویی است (تبدیل کد و خروجی دیباگر به حقایق ساختاریافته)، Lemmalog نقش نمایش میانی (IR) و موتور تحلیل را دارد و در نهایت یک فراخوانی دیگر از LLM، این وضعیت را دوباره به زبان طبیعی یا آزمایش‌های پیشنهادی تبدیل می‌کند.

حل مسئله بازپس‌گیری حقایق

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

Lemmalog منشأ (provenance) هر حقیقت مشتق شده را ردیابی کرده و یک درخت وابستگی می‌سازد. این به سیستم اجازه می‌دهد وقتی عاملی به نتیجه‌ای می‌رسد، به پرسش «چرا؟» پاسخ دهد. اگر عاملی ادعا کند هدفی قابل اکسپلویت است، سیستم می‌تواند ردپای آن را ارائه دهد:

• candidate_3_is_exploitable
• $ \rightarrow $ attacker_controls_pointer $ \rightarrow $ observation_41
• $ \rightarrow $ pointer_reaches_target $ \rightarrow $ observation_57
• $ \rightarrow $ rule_12

اگر observation_41 حذف شود، سیستم دقیقاً می‌داند کدام شاخه‌های درخت منطق را باید هرس کند. این همچنین از یک حالت شکست رایج جلوگیری می‌کند که در آن مدل با اطمینان ادعا می‌کند چیزی ثابت شده است در حالی که نشده است؛ اگر هیچ منشأ پشتیبانی‌کننده‌ای برای یک نتیجه در Lemmalog وجود نداشته باشد، آن نتیجه بخشی از وضعیت حفظ شده نخواهد بود. این امر باعث می‌شود نتایج بدون پشتوانه به‌سادگی وارد جریان تحقیق نشوند. در این راستا، بررسی آسیب‌پذیری‌های ساختاری در زنجیره تفکر (CoT) نشان می‌دهد که چگونه مدل‌های زبانی حتی در استدلال‌های گام‌به‌گام نیز می‌توانند دچار توهم یا خطاهای منطقی شوند.

مدیریت زمان و هویت

حقایق در یک تحقیق واقعی تغییر می‌کنند. یک ابزار ممکن است در ساعت ۱۰:۰۰ صبح کاربردی باشد اما تا ساعت ۱۲:۰۰ ظهر غیرکاربردی بودن آن ثابت شود. Lemmalog این موضوع را با استفاده از «بازه اعتبار» (validity intervals) مدیریت می‌کند و حقایق را به پنجره‌های زمانی خاص مرتبط می‌سازد. از نظر مفهومی، وضعیت به این شکل نمایش داده می‌شود:

• viable(primitive_a) [10:14, 12:37)
• not_viable(primitive_a) [12:37, ...)

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

برای عملیاتی کردن این سیستم در دنیای واقعی، یک مرحله «تطبیق» (reconciliation pass) اجرا می‌شود. این مرحله اشاره‌های محلی در یک اپیزود (مثلاً «ماشین») را به موجودیت‌های استاندارد (مثلاً «هوندا سیویک») متصل می‌کند. بدون این کار، اگر استخراج منجر به bought(user, honda_civic)، broke_down(car) و fixed(civic) شود، موتور Datalog آن‌ها را سه شیء متفاوت می‌بیند و زنجیره منطقی می‌شکند.

عملکرد در محک‌ها

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

نتایج LongMemEval:
این محک از ۱۰۲ پرسش در دسته‌هایی مانند حقایق کاربر، حقایق دستیار، ترجیحات، پرسش‌های چند-جلسه‌ای، استدلال زمانی و به‌روزرسانی دانش استفاده می‌کند. Lemmalog به امتیاز F1 برابر با ۰.۴۶۳ (+/- ۰.۰۱۰) و دقت ۰.۵۷۵ (+/- ۰.۰۰۴) دست یافت.

• به‌روزرسانی دانش (Knowledge Updates): Lemmalog امتیاز ۰.۵۷۹ را کسب کرد و PropMem (۰.۵۲۸) را شکست داد و مدل‌های Full-context (۰.۲۰۲) را به‌طور کامل کنار زد. این تسک دقیقاً مربوط به به‌روزرسانی یک باور هنگام رسیدن اطلاعات جدید است (مثلاً باور به A، و سپس یادگیری اینکه A دیگر درست نیست).
• حافظه واقعی (Factual Memory): در حقایق کاربر به ۰.۷۹۰ و در حقایق دستیار به ۰.۶۷۲ رسید.
• استدلال زمانی (Temporal Reasoning): امتیاز ۰.۴۱۶ را کسب کرد که تقریباً مشابه امتیاز ۰.۴۲۴ در PropMem است.
• استدلال چند-جلسه‌ای (Multi-session Reasoning): این بخش همچنان یک نقطه ضعف است (۰.۲۱۱)، اغلب به این دلیل که استخراج‌کننده در تولید حقایق لازم شکست خورده است (مثلاً عدم استخراج یک رزرو Airbnb).

برای مقایسه، سیستم‌های دیگر مانند OpenClaw (۰.۲۴۴ F1) و Full Context (۰.۲۲۲ F1) بسیار ضعیف‌تر عمل کردند. یک اجرای Full-context با GPT-4.1 تنها ۰.۱۹۷ F1 کسب کرد. همچنین متنی که به مدل پاسخ‌دهنده ارسال شد به‌شدت کوچک‌تر بود: حدود ۲۷۰۰ توکن برای هر پرسش در Lemmalog در مقابل ۱۰۴۰۰۰ توکن برای Full context (کاهش ۳۸ برابری).

نتایج LoCoMo:
این محک بزرگ‌تر است و شامل ۱۰ گفتگوی طولانی و ۱۹۸۶ پرسش است. Lemmalog به F1 برابر با ۰.۵۳۳ (+/- ۰.۰۰۱) دست یافت و در رتبه سوم در میان سیستم‌های حافظه اختصاصی قرار گرفت (بعد از PropMem با ۰.۶۰۵ و OpenClaw با ۰.۵۵۷).

• پرسش‌های خصمانه (Adversarial Questions): Lemmalog امتیاز ۰.۷۰۷ را در مقابل ۰.۵۰۹ برای مدل‌های Full-context کسب کرد. این پرسش‌ها حاوی پیش‌فرض‌های غلط هستند. چون Lemmalog از حقایق ساختاریافته استفاده می‌کند، متوجه می‌شود که پیش‌فرض پرسش پشتیبانی نمی‌شود، در حالی که LLMها اغلب بر اساس شباهت معنایی، پاسخی توهمی می‌سازند.
• استدلال زمانی: عملکرد پس از رفع یک باگ (که در آن مقادیر تاریخ‌مانند به عنوان نمادهای داخلی Datalog مقایسه می‌شدند) حدود ۲۰ امتیاز F1 رشد کرد. نرمال‌سازی تاریخ‌ها به اعداد قابل مقایسه و استخراج happened_before از برچسب‌های زمانی این مشکل را حل کرد.
• بهره‌وری: کاهش توکن‌ها چشمگیر است. برای LoCoMo، مدل پاسخ‌دهنده حدود ۳۴۰۰ توکن را در هر پرسش دید، در حالی که در Full context این عدد ۱۸۹۰۰ توکن بود (کاهش ۶ برابری). در حالی که استخراج هزینه یک‌باره دارد، اما Full-context در هر پرسش هزینه کل تاریخچه را می‌پردازد، بنابراین مزیت Lemmalog با گذشت زمان بیشتر می‌شود.

موازنه و محدودیت‌ها

Lemmalog یک راهکار جادویی نیست. این سیستم در استنتاج‌های پیچیده‌ای که نیاز به ظرافت دارند، دچار مشکل می‌شود. برای مثال، ترجیحی مانند «من رستوران‌های آرام را دوست دارم مگر وقتی با دوستانم سفر می‌کنم» را نمی‌توان بدون از دست دادن منطق شرطی، به یک توپل ساده Datalog تبدیل کرد. در LoCoMo، امتیاز استنتاجی Lemmalog برابر با ۰.۱۶۴ بود، در حالی که PropMem ۰.۲۸۹ را کسب کرد.

در حال حاضر، این سیستم به عنوان یک مدل ترکیبی (Hybrid) بیشترین اثربخشی را دارد. معماری ایده‌آل ترکیبی از این دو است:

• وضعیت استنتاجی (Deductive State): حقایق، قوانین، زمان و منشأ برای منطق سخت.
• حافظه اپیزودیک (Episodic Memory): زمینه مبهم، متن منبع و بازیابی معنایی برای ظرافت‌ها.

جزئیات پیاده‌سازی

سازنده اشاره می‌کند که سخت‌ترین بخش، ارزیابی Datalog نیست، بلکه ساخت یک نمایش میانی (IR) قابل اعتماد از زبان طبیعی است. این کار شامل چندین اصلاح مهندسی کامپیوتر بود:

• ریشه‌یابی و شمارش (Stemming and Counting): یک ریشه‌یاب جمع که کلمه "owns" را با "own" تطبیق نمی‌داد، باعث شکست پرسش‌های مبتنی بر شمارش می‌شد. رفع این مورد، رندر کردن شمارش‌ها با حقایق آن‌ها و پیش‌محاسبه محاسبات تاریخ، F1 را به ۰.۴۶۳ رساند.
• بازیابی: ترکیب BM25، تقویت‌های گراف/موجودیت و Embeddingها برای اطمینان از بازیابی مستعار‌های معنایی (مانند «یک ماشین» در مقابل «یک اتومبیل»).
• منطق استدلال: در ابتدا مدل به اشتباه یاد گرفته بود هر پاسخی را که دقیقاً در یک حقیقت واحد وجود ندارد رد کند. راه حل این بود که موارد تفکیک شوند: اگر پیش‌فرض غایب است رد شود، اما اگر شواهد وجود دارند ولی نیاز به شمارش، مقایسه یا ترتیب‌بندی دارند، استدلال انجام شود.
• ویژگی‌های موتور: موتور اکنون از ارزیابی افزایشی، بازپس‌گیری (retractions)، منشأ، حقایق زمانی، تجمیع (aggregations)، تطبیق موجودیت‌ها، بازیابی ترکیبی و پرس‌وجوهای تقاضامحور پشتیبانی می‌کند.

این تغییر در معماری نشان می‌دهد که مسیر رسیدن به عامل‌های بهتر، صرفاً بزرگ‌تر کردن پنجره‌های متنی (Context Window) نیست، بلکه مدیریت بهتر وضعیت (State Management) است. این رویکرد در کنار پروژه VoltMem که از محاسبات زمان خواب برای تثبیت حافظه استفاده می‌کند، نشان‌دهنده حرکت به سمت سیستم‌های حافظه فعال‌تر است. با تبدیل یک تحقیق به یک مسئله تحلیل استاتیک — با حقایق ورودی، قوانین و یک نقطه ثابت محاسبه شده — می‌توانیم جلوی عامل‌هایی را بگیریم که فرضیات مرده را دوباره زنده می‌کنند.

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

گام بعدی شما

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.