میموری اور علم

میموری کس لیے ہے

میموری کے بغیر ہر ایجنٹ گفتگو صفر سے شروع ہوتی ہے: وہی کنونشن دوبارہ سمجھانا پڑتا ہے، وہی فیصلہ دوبارہ بحث میں آتا ہے، وہی بند گلی دوبارہ دریافت ہوتی ہے۔ میموری ورک اسپیس کے دائرے میں رہنے والا اسٹور ہے جو رنز سے آگے بھی قائم رہتا ہے، اور یہ اس لیے موجود ہے کہ ایک ایجنٹ کا پیدا کردہ علم بعد میں کسی دوسرے ایجنٹ کو مل سکے۔

اس کی تین تہیں ہیں اور یہ مختلف سوالوں کے جواب دیتی ہیں:

فیکٹس — کیا سچ ہے (ایک کنونشن، ایک نتیجہ، ایک فیصلہ)۔
پالیسیاں — ایجنٹس کو اس بارے میں کیا کرنا چاہیے (ایک معیاری قاعدہ)۔
ورکنگ میموری — ایک ایجنٹ اس وقت کس کام کے درمیان تھا۔

یہ فرق اہم ہے کیونکہ یہ تینوں ایجنٹ تک مختلف راستوں سے پہنچتی ہیں۔ فیکٹس تلاش کیے جاتے ہیں۔ پالیسیاں دھکیلی جاتی ہیں۔ ورکنگ میموری نجی ہوتی ہے۔

فیکٹس

MemoryFact علم کی وہ اکائی ہے جس کا دائرہ ایک ورک اسپیس اور ایک ڈومین تک محدود ہوتا ہے۔

خصوصیت	یہ کیا ہے
`domain`	علم کا ڈومین (“conventions”, “decisions”, “codebase”)
`topic`	موضوع کا مختصر لیبل
`content`	علم کا متن
`confidence`	0.0–1.0، ماخذ سے بیج بنتی ہے اور دوبارہ ذکر سے بڑھتی ہے
`memoryType`	فیکٹ کی قسم — اسی سے اس کا وقتی تنزل کا وکر چلتا ہے
`veracity`	یہ علم کیسے حاصل ہوا — اعتماد کا بیج بناتا ہے اور ہر دوبارہ ذکر کے اضافے کا حجم طے کرتا ہے
`sourceObservationIds`	کون سے مشاہدات اس کی وجہ بنے
`supersededBy`	وہ نئی فیکٹ جس نے اس کی جگہ لی، اگر کوئی ہو
`validUntil`، `recallCount`، `mentionCount`	اختتام اور استعمال کے سگنل جو ری کال پر استعمال ہوتے ہیں

آخری دو قطاریں وہ ہیں جنہیں لوگ نظر انداز کر دیتے ہیں، اور یہی طے کرتی ہیں کہ کون سی فیکٹ سامنے آئے گی۔ memoryType میں ہر قسم کے لیے الگ Weibull تنزل کے پیرامیٹرز ہوتے ہیں، اس لیے وقت سے بندھی ذمہ داری تیزی سے ماند پڑ جاتی ہے جبکہ مستحکم پروفائل فیکٹ نہیں۔ veracity ماخذ ریکارڈ کرتا ہے — انسان کا بتایا ہوا (وزن 1.0)، ایجنٹ کا نکالا ہوا (0.7)، ٹول کا پیدا کردہ (0.5)، درآمد شدہ (0.6) — اور یہی وزن فیکٹ کے ابتدائی اعتماد کا بیج بنتا ہے۔

جب فیکٹس میں تضاد ہو تو انہیں کبھی اسی جگہ ترمیم نہیں کیا جاتا۔ کوئی فیکٹ لکھنا ایک ہی ڈومین اور ایک ہی موضوع کی فیکٹس کے خلاف تضاد کی شناخت چلاتا ہے اور ہارنے والی کی جگہ نئی فیکٹ لے لیتی ہے، ساتھ ہی ایک تضاد قطار ریکارڈ ہوتی ہے۔ اصل مقصد آڈٹ ٹریل ہے: آپ ہمیشہ دیکھ سکتے ہیں کہ پہلے کیا مانا جاتا تھا اور اس کی جگہ کیا آیا۔

پالیسیاں

MemoryPolicy فیکٹس سے نکلا ہوا معیاری قاعدہ ہے، جس کا دائرہ ایک ورک اسپیس اور ڈومین تک ہوتا ہے، اور اس کے ساتھ ایک ایکٹو فلیگ اور اختیاری requiredRole ہوتا ہے۔

ورک اسپیس کی ہر ایکٹو پالیسی ہر ڈسپیچ میں شامل کی جاتی ہے، بغیر کسی فلٹر کے — نہ ڈومین، نہ کردار، نہ ٹاسک اور نہ اسپیس کے لحاظ سے فلٹرنگ۔ اپنی بیسویں پالیسی لکھنے سے پہلے یہ جان لینا چاہیے، کیونکہ پالیسیاں اسی کانٹیکسٹ ونڈو کے لیے مقابلہ کرتی ہیں جس میں ٹاسک ہوتا ہے۔ اسی لیے پالیسی پر requiredRole مشاورتی ہوتا ہے: یہ بتاتا ہے کہ قاعدہ کس کے لیے ہے، مگر یہ نہیں روکتا کہ قاعدہ باقی سب تک بھی پہنچے۔

ڈومینز

MemoryDomain ایک ورک اسپیس کے اندر فیکٹس اور پالیسیوں کو گروپ کرتا ہے۔ ڈومینز علم کو تنظیمی ڈھانچہ دیتے ہیں اور رسائی گرانٹس انہی کے خلاف لکھی جاتی ہیں — لیکن کسی ڈومین کو رازداری کی حد سمجھنے سے پہلے نیچے دی گئی احتیاط پڑھیں۔

ایک ڈومین یا تو پورے ورک اسپیس کا ہوتا ہے (architecture) یا ایک ریپوزٹری تک محدود (repo:<slug>/architecture)۔ دونوں دائرہ کاروں میں ایک ہی نام دو الگ اسٹور ہیں: کسی ایک کوڈ بیس کے بارے میں سچی فیکٹ پورے ورک اسپیس والی فیکٹ کو اوور رائٹ نہیں کرتی۔ جب ایجنٹ کسی ریپو میں کام کر رہا ہو تو search_memory اور ڈسپیچ کا پریمبل ریپو کے دائرے والی میموری کو پہلے درجہ دیتے ہیں؛ باقی کو فلٹر آؤٹ نہیں کرتے۔ اس دائرے میں لکھنے یا اسے بڑھانے کے لیے propose_fact / propose_policy / search_memory پر repo پاس کریں۔

رسائی کنٹرول ریڈز کے لیے فیل-اوپن ہے

MemoryAccessGrant ایجنٹ کے کردار اور ڈومین کو تین اجازت سطحوں میں سے ایک سے جوڑتا ہے:

اجازت	مطلب
`none`	کوئی رسائی نہیں
`read`	فیکٹس تلاش اور حاصل کر سکتا ہے
`write`	`propose_policy` کے لیے ضروری۔ فیکٹ کی رائٹس (`propose_fact`، `supersede_fact`) گرانٹ سے مشروط نہیں

جب کسی (role, domain) جوڑے کے لیے کوئی گرانٹ قطار نہ ہو، تو موثر اجازت read ہوتی ہے۔ ریڈز ڈیزائن سے فیل-اوپن ہیں۔ واحد رائٹ جو استثنا پھینکتا ہے وہ propose_policy ہے write اجازت کے بغیر (InsufficientMemoryPermission)۔ میموری ڈومین میں حساس مواد رکھنے سے یہ محدود نہیں ہوتا کہ اسے کون پڑھ سکتا ہے، الا یہ کہ آپ نے ہر ایسے کردار کے لیے واضح طور پر none گرانٹ لکھی ہو جسے یہ نہیں دیکھنا چاہیے۔

آج پروڈکٹ میں کہیں گرانٹس کا کوئی UI بھی نہیں ہے۔ میموری اسکرین پر فیکٹس، پالیسیاں اور گراف ٹیبز ہی ہیں اور بس؛ گرانٹس تک رسائی صرف memory_access_grant.* RPC اوپس سے ہوتی ہے۔

یہ عدم توازن — ریڈز پر نرمی، پالیسی رائٹس پر سختی — جان بوجھ کر کیا گیا سمجھوتہ ہے۔ میموری اسی وقت سب سے زیادہ کارآمد ہوتی ہے جب وہ گردش کرے، اور ریڈ سے انکار کا نتیجہ ایسا ایجنٹ ہوتا ہے جو خاموشی سے کم جانتا ہے، نہ کہ ایسا ایجنٹ جو مسئلہ بتائے۔ اس کے برعکس پالیسی رائٹ سے انکار بلند آواز اور درست کیے جانے کے قابل ہوتا ہے، اسی لیے نفاذ وہاں رکھا گیا ہے۔ نیا بنایا گیا ڈومین ہر کردار کے لیے write کا بیج دیتا ہے؛ بعد میں اسے سخت کرنا صرف RPC سے ممکن ہے، کیونکہ گرانٹس کا کوئی UI نہیں ہے۔

ورکنگ میموری

ہر ایجنٹ کی ایک AgentWorkingMemory ہوتی ہے: ایک فری ٹیکسٹ اسکریچ پیڈ جس کی کلید ورک اسپیس اور ایجنٹ ہوتی ہے۔ یہ رنز کے پار قائم رہتا ہے، اسی ایجنٹ کے لیے نجی ہوتا ہے اور ہر ڈسپیچ پر اس کے پرامپٹ میں شامل کیا جاتا ہے۔ “میں auth ری فیکٹر کرتے ہوئے آدھے راستے میں تھا” جیسی باتیں یہیں رہتی ہیں — وہ حالت جو اگلے رن تک لے جانے کے قابل ہے مگر پائیدار فیکٹ بنانے کے قابل نہیں۔

ایجنٹ کے پرامپٹ تک اصل میں کیا پہنچتا ہے

ڈسپیچ کے وقت میموری پریمبل بالکل تین چیزوں سے تیار ہوتا ہے:

ورک اسپیس کی ہر ایکٹو پالیسی، بطور - [domain] rule سطریں۔
خود ایجنٹ کی ورکنگ میموری، لفظ بہ لفظ۔
اس ٹاسک کے لیے کلیدی لفظ سے میچ ہونے والی فیکٹس کی مختصر فہرست — زیادہ سے زیادہ پانچ، تقریباً 1,200 حروف کے بجٹ میں، اور صرف اسی صورت جب ٹاسک کی تفصیل کم از کم 20 حروف کی ہو۔ اس سے چھوٹے ٹاسکس کو کوئی فیکٹ نہیں ملتی۔

یہ مختصر فہرست صرف FTS/کلیدی لفظ پر مبنی ہے اور اسے جان بوجھ کر محدود رکھا گیا ہے۔ کوئری کی ایمبیڈنگ بنانا سست ہے اور ڈسپیچ کا راستہ وہ واحد جگہ ہے جہاں تاخیر فوراً نظر آتی ہے، اس لیے سست معنوی راستہ جان بوجھ کر اس سے باہر رکھا گیا ہے۔ پریمبل کے آخر میں ایجنٹ کو بتایا جاتا ہے کہ بنیادی اہمیت کی چیزیں search_memory سے جانچے، جہاں ری کال کا مکمل ماڈل موجود ہے۔

اس راستے پر کوئی رسائی گرانٹ نہیں دیکھی جاتی۔ مختصر فہرست جو ڈھونڈ لے، ایجنٹ وہی دیکھتا ہے۔

ری کال: ایک کوئری، چار آوازیں

ایجنٹ کے لیے دستیاب search_memory ٹول کے تین موڈ ہیں اور یہ واقعی الگ الگ تلاشیں ہیں:

keyword — صرف FTS5۔
semantic — BM25 اور ویکٹر کے نتائج ریسیپروکل رینک فیوژن سے جوڑے جاتے ہیں۔
hybrid (ڈیفالٹ) — پولی فونک ری کال: چار درجہ بند آوازیں جوڑی جاتی ہیں، پھر متنوع بنائی جاتی ہیں۔

چار آوازیں یہ ہیں: لغوی (FTS)، معنوی (ویکٹر KNN)، زمانی (حالیہ ایکٹو فیکٹس) اور گراف — مضبوط ترین لغوی اور معنوی بیجوں سے شروع ہو کر ایپی سوڈک کناروں پر دو ہاپ کی واک۔ گراف کی آواز ہی ایپی سوڈک کناروں کے وجود کی وجہ ہے: یہ وہ فیکٹ سامنے لاتی ہے جو آپ کے جواب سے جڑی ہے مگر آپ کے کسی لفظ سے میچ نہیں کرتی۔ آوازوں کا وزن درجہ بند کی گئی کوئری نیت سے طے ہوتا ہے (ڈیفالٹ میں معنوی کا وزن سب سے زیادہ، پھر گراف اور لغوی، پھر تازگی)، ہر امیدوار کا اسکور اس کے Weibull تنزل سے ضرب ہوتا ہے، اور نتیجے MMR کے ذریعے متنوع بنائے جاتے ہیں تاکہ ایک ہی فیکٹ کی پانچ دہرائیاں چار مختلف فیکٹس کو باہر نہ دھکیل دیں۔

ویکٹر کی آواز اسی وقت حصہ ڈالتی ہے جب ڈیوائس پر موجود ایمبیڈنگ ماڈل ڈاؤن لوڈ ہو چکا ہو۔ تب تک ہائبرڈ ری کال تین آوازوں کے ساتھ چلتی ہے اور ماضی کی کوئی بھرائی نہیں ہوتی — ماڈل انسٹال ہونے سے پہلے لکھی گئی فیکٹس کو کبھی ویکٹر نہیں ملتے۔ اگر SQLite ویکٹر ایکسٹینشن خود لوڈ ہونے میں ناکام ہو جائے تو ویکٹر کا راستہ مزید تنزلی کر کے Dart کے اندر پیک شدہ ایمبیڈنگز پر اسکین بن جاتا ہے؛ ری کال پھر بھی جواب دیتی ہے، البتہ زیادہ سست روی سے۔

ڈیسک ٹاپ اور ویب کی میموری تلاش ایک الگ اور سادہ راستہ ہے: memory_fact.search RPC اوپ صرف FTS5 ہے، کیونکہ ایک ہلکا کلائنٹ کوئری کی ایمبیڈنگ نہیں بھیج سکتا اور ہائبرڈ راستہ ہوسٹ کے اندرونی حصے میں ہی رہتا ہے۔ تو میموری براؤزر میں آپ کو جو درجہ بندی نظر آتی ہے وہ وہی نہیں جو ایجنٹ کو search_memory سے ملتی ہے۔ یہ متوقع ہے، کوئی بگ نہیں، مگر اس کا مطلب یہ ہے کہ UI میں “میں نے تلاش کیا اور نہیں ملا” یہ ثبوت نہیں کہ ایجنٹ کو بھی نہیں ملے گا۔

میموری کہاں رہتی ہے اور اسے کون لکھتا ہے

میموری براؤزر ترتیبات → ورک اسپیس → میموری پر ہے (/workspaces/<id>/settings/memory)، جس میں فیکٹس، پالیسیاں اور گراف ٹیبز ہیں۔

وہاں ایک ایسا عدم توازن ہے جو لوگوں کو حیران کرتا ہے: آپ میموری میں ترمیم اور اسے حذف کر سکتے ہیں، مگر اسے بنا نہیں سکتے۔ نہ فیکٹس ٹیب میں شامل کرنے کی کوئی سہولت ہے اور نہ پالیسیاں ٹیب میں۔ تحریر ایجنٹ کی طرف سے ہوتی ہے، propose_fact اور propose_policy کے ذریعے (ان کی جگہ لینے کے لیے supersede_fact / supersede_policy)۔ remember سیشن تک محدود ہاٹ ٹیئر آئٹم لکھتا ہے جسے consolidate_memory بعد میں فیکٹ کا درجہ دے سکتا ہے؛ record_observation اور update_my_notes وہ نجی اسکریچ پیڈ لکھتے ہیں جو ڈسپیچ پر شامل کیا جاتا ہے۔ براؤزر جائزے اور اصلاح کی سطح ہے، تحریر کی سطح نہیں — تو اگر آپ میموری میں کوئی فیکٹ چاہتے ہیں، اسے وہاں پہنچانے کا طریقہ یہ ہے کہ کسی ایجنٹ کو بتائیں۔

دو دیکھ بھال کے آپریشن بھی شیڈول کے بجائے ایجنٹ ہی چلاتا ہے: consolidate_memory جمع شدہ فیکٹس کو ضم اور تراش کرتا ہے اور harmonize_memory ان یقینوں میں تطبیق پیدا کرتا ہے جو ایجنٹس کے درمیان مختلف ہو گئے۔ list_memory_conflicts دکھاتا ہے کہ تضاد کی شناخت نے پہلے سے کیا ریکارڈ کیا ہے۔ انہیں ٹائمر پر آپ کے لیے کوئی نہیں چلاتا۔ جب میٹنگ محفوظ کرنے والا قدم انہیں ریکارڈ کرتا ہے تو میٹنگ کے فیصلے decisions ڈومین میں اکٹھے کیے جاتے ہیں؛ یہ مکمل شدہ ایجنٹ رنز پر کوئی ٹائمر نہیں ہے۔