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

چرا حافظه برای عامل‌های LLM اهمیت دارد

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

نحوه عملکرد رویاپردازی شبانه

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

  • تأمل (Reflect) – یک LLM خوشه‌های رویدادهای مرتبط را اسکن کرده، حقایق مختصر را پیشنهاد می‌دهد و ثبت می‌کند که کدام رویدادها از هر پیشنهاد پشتیبانی می‌کنند.
  • امتیازدهی (Score) – خط لوله بررسی می‌کند که آیا یک حقیقت، رویدادهای پشتیبان کافی دارد یا خیر، و آیا این رویدادها از نظر زمانی به اندازه کافی فاصله دارند تا قابل اعتماد باشند یا نه.
  • قضاوت (Judge) – دو بررسی صحت (sanity checks) تأیید می‌کنند که حقیقت جدید با هیچ‌یک از حافظه‌های موجود در تضاد نیست و تکراری نمی‌باشد.

حقایقی که از تمام بررسی‌ها عبور می‌کنند، به حافظه دائمی ارتقا می‌یابند. مواردی که در این مرحله مردود می‌شوند، در یک صف بازبینی قرار می‌گیرند که در آن یک اپراتور انسانی تنها با فشردن یک کلید، آن‌ها را تأیید یا رد می‌کند. هر تأیید، یک کامیت (commit) به سبک git ایجاد می‌کند که یک ردپای حسابرسی کامل از اینکه چه حافظه‌ای و در چه زمانی تغییر کرده است، ارائه می‌دهد.

نکات کلیدی مهندسی

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

معایب احتمالی

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

آنچه باید در آینده زیر نظر داشت

توسعه‌دهندگانی که با عامل‌های LLM کار می‌کنند، باید صورت‌حساب‌های توکن و گزارش‌های خطا را برای یافتن نشانه‌های «آلودگی حافظه» (memory pollution) – یعنی اظهارات تکراری یا متناقض که ریشه در انباشت رویدادهای خام دارند – زیر نظر داشته باشند. افزودن یک خط لوله رویاپردازی، اهرم مشخصی برای کاهش این هزینه‌ها و در عین حال به‌دست آوردن یک تاریخچه حافظه قابل حسابرسی فراهم می‌کند. با پذیرش مدلِ «گزارشِ تفکیک‌شده» توسط تیم‌های بیشتر، ابزارهایی که مراحل reflect-score-judge را خودکار کرده و با سیستم‌های کنترل نسخه (version-control) ادغام می‌شوند، احتمالاً ظاهر خواهند شد و این رویکرد را از حالت سفارشی به حالت آماده‌به‌کار (plug-and-play) تبدیل می‌کنند. تعادل میان فوریت و پاکیزگی، تعیین خواهد کرد که رویاپردازی شبانه تا چه حد به عنوان یک بخش استاندارد در معماری عامل‌های LLM پذیرفته شود.