ایک ڈویلپر کا "dreaming" پائپ لائن دن میں دو بار چلتا ہے، جو ایک LLM-agent کے خام ایونٹ لاگ (raw event log) کو ایک جامع اور تصدیق شدہ میموری اسٹور میں تبدیل کر دیتا ہے اور ٹوکن کے اخراجات میں نمایاں کمی لاتا ہے۔ یہ طریقہ اس لیے اہم ہے کیونکہ زیادہ تر ایجنٹ سسٹمز اپنی ورکنگ میموری کو ہر اس تفصیل سے بھر دیتے ہیں جو وہ دیکھتے ہیں، جس کے نتیجے میں جلد ہی تضادات، بھولے ہوئے سیاق و سباق (context) اور بڑھتے ہوئے API اخراجات پیدا ہو جاتے ہیں۔

LLM ایجنٹس کے لیے میموری کیوں اہم ہے

LLM ایجنٹس صارف کی ہر درخواست، ٹول کال، یا اندرونی مشاہدے کو ایک نئے "ایونٹ" کے طور پر دیکھتے ہیں۔ ایک سادہ طریقہ کار ہر ایونٹ کو اس پرامپٹ (prompt) کے ساتھ جوڑ دیتا ہے جو اگلے فیصلے کی بنیاد بنتا ہے۔ عملی طور پر، یہ پرامپٹ کو غیر ضروری معلومات (noise) سے بھر دیتا ہے، ماڈل کو پرانے حقائق کا دوبارہ جائزہ لینے پر مجبور کرتا ہے، اور ٹوکن کے استعمال کو مہنگے ترین قیمت والے درجے میں لے جاتا ہے۔ نتیجہ: زیادہ غلطیاں اور ایک چھپا ہوا بل جو ہر تعامل (interaction) کے ساتھ بڑھتا چلا جاتا ہے۔

رات کا "dreaming" عمل کیسے کام کرتا ہے

یہ سسٹم write path (ایجنٹ کا لائیو لاگ) کو work path (ماڈل کا فیصلہ سازی کا عمل) سے الگ کر دیتا ہے۔ دن میں دو بار ایک بیک گراؤنڈ جاب—جسے "dream" کا نام دیا گیا ہے—جمع شدہ ایونٹس کو تین مراحل کے ذریعے پروسیس کرتی ہے:

  • Reflect – ایک LLM متعلقہ ایونٹس کے گروہوں کا جائزہ لیتا ہے، مختصر حقائق تجویز کرتا ہے، اور یہ ریکارڈ کرتا ہے کہ کون سے ایونٹس ہر تجویز کی تائید کرتے ہیں۔
  • Score – پائپ لائن چیک کرتی ہے کہ آیا کسی حقیقت کے لیے کافی معاون ایونٹس موجود ہیں اور کیا وہ ایونٹس وقت کے لحاظ سے اتنے فاصلے پر ہیں کہ قابل بھروسہ سمجھے جا سکیں۔
  • Judge – دو sanity checks اس بات کی تصدیق کرتے ہیں کہ نیا حقیقت موجودہ میموری کے ساتھ تضاد میں نہ ہو اور وہ کوئی دوہری معلومات (duplicate) نہ ہو۔

وہ حقائق جو تمام چیک پاس کر لیتے ہیں انہیں permanent memory میں منتقل کر دیا جاتا ہے۔ جو معیار پر پورا نہیں اترتے وہ ایک review queue میں چلے جاتے ہیں جہاں ایک انسانی آپریٹر محض ایک کلک کے ذریعے انہیں منظور یا مسترد کر سکتا ہے۔ ہر منظوری ایک git-style commit تخلیق کرتی ہے، جس سے اس بات کا مکمل آڈٹ ٹریل (audit trail) ملتا ہے کہ میموری میں کب اور کیا تبدیلی آئی۔

اہم انجینئرنگ نکات

  • Write کو Work سے الگ رکھیں۔ ایجنٹس کو ہر مشاہدہ لاگ میں ڈالنے دیں؛ ایک مخصوص عمل کو یہ فیصلہ کرنے دیں کہ کیا محفوظ رکھنا ہے۔
  • تخلیق کے بجائے روک تھام پر توجہ دیں۔ آئیڈیاز پیدا کرنا سستا ہے؛ میموری کی آلودگی (memory pollution) کو روکنا مشکل حصہ ہے۔
  • سب سے سستے چیک پوائنٹ پر انسانی مداخلت رکھیں۔ خودکار ڈرافٹنگ کے بعد فوری دستی منظوری، مکمل خود مختاری کے مقابلے میں لاگت اور حفاظت کے لحاظ سے بہتر ہے۔
  • ہر سائیکل میں ٹوکن کے اخراجات کی حد مقرر کریں۔ ہر dreaming run میں ٹوکنز کی ایک سخت حد غیر ضروری اخراجات کو روکتی ہے۔
  • خاموش ناکامیوں کا آڈٹ کریں۔ اگر ایک مرحلہ اگلے مرحلے کے مقابلے میں مختلف قوانین لاگو کرتا ہے، تو ڈیٹا نظر انداز ہوئے بغیر غائب ہو سکتا ہے؛ واضح چیک ان تضاد کو پکڑ لیتے ہیں۔

ممکنہ نقصانات

ڈیٹا کو یکجا کرنے کا عمل آف لائن چلانے سے تاخیر (lag) پیدا ہوتی ہے: ایجنٹ اگلے dream cycle تک نئے تصدیق شدہ حقائق نہیں دیکھ سکے گا۔ تیز رفتار ایپلی کیشنز میں جنہیں فوری سیکھنے کی ضرورت ہوتی ہے، یہ تاخیر ایک نقصان ثابت ہو سکتی ہے۔ یہ سسٹم ایک واحد انسانی ریویو کرنے والے پر بھی انحصار کرتا ہے؛ لیبر کی لاگت بڑھائے بغیر ریویو کیو (review queue) کو وسعت دینا اب بھی ایک چیلنج ہے۔

آگے کیا دیکھنا چاہیے

LLM ایجنٹس کے ساتھ تجربات کرنے والے ڈویلپرز کو ٹوکن بلز اور ایرر لاگز میں "memory pollution" کے آثار پر نظر رکھنی چاہیے — یعنی وہ بار بار دہرائی جانے والی یا متضاد بیانات جو خام ایونٹس کے جمع ہونے کی وجہ سے پیدا ہوتے ہیں۔ ایک dreaming pipeline شامل کرنے سے ان اخراجات کو کم کرنے کا ایک ٹھوس ذریعہ ملتا ہے اور ساتھ ہی ایک قابلِ آڈٹ میموری ہسٹری بھی حاصل ہوتی ہے۔ جیسے جیسے مزید ٹیمیں split-log ماڈل اپنائیں گی، ایسے ٹولز سامنے آنے کا امکان ہے جو reflect-score-judge کے مراحل کو خودکار بنائیں گے اور ورژن کنٹرول طرز کے ریویو کے ساتھ منسلک ہوں گے، جس سے یہ طریقہ کار زیادہ آسان اور plug-and-play بن جائے گا۔ فوری نتائج اور صفائی (cleanliness) کے درمیان توازن ہی یہ طے کرے گا کہ nightly dream کس حد تک LLM-agent آرکیٹیکچر کا ایک معیاری حصہ بن پاتا ہے۔