آج کل GitHub پر ملٹی ایجنٹ ورک فلو (multi-agent workflows) کا غلبہ ہے۔ ڈویلپرز لارج لینگویج ماڈلز کو ایک زنجیر میں پرو رہے ہیں، ہر ایجنٹ کو ایک مخصوص مہارت سونپ رہے ہیں، اور ان کے نتائج کو اس طرح منظم کر رہے ہیں کہ ایسے کام انجام دیے جا سکیں جو کوئی ایک ماڈل اکیلے نہیں کر سکتا۔ نتائج متاثر کن ہو سکتے ہیں۔ ایک ایجنٹ تحقیق کرتا ہے، دوسرا ڈرافٹ تیار کرتا ہے، تیسرا حقائق کی جانچ کرتا ہے، اور چوتھا حتمی آؤٹ پٹ کو فارمیٹ کرتا ہے۔ لیکن اس تمام ہم آہنگی کے پیچھے ایک کمزور انحصار چھپا ہوا ہے۔ اگر پہلا قدم، یعنی انسانی ان پٹ کو مشین کے قابل ہدایات میں تبدیل کرنا، سست یا غیر درست ہو، تو پوری زنجیر ٹوٹ جاتی ہے۔ کوئی بھی بعد والا ایجنٹ غلط ڈیٹا (garbage) کو درست نہیں کر سکتا؛ وہ صرف اسے آگے پھیلا سکتا ہے۔
یہی وہ رکاوٹ ہے جہاں Iflytek/domux کام آتا ہے۔ یہ ایک اوپن سورس ماڈل ہے جو خاص طور پر ایک اہم کام کے لیے بنایا گیا ہے: کمانڈز کو تیزی سے سمجھنا۔ مضامین لکھنے یا طویل گفتگو کرنے کے بجائے، domux قدرتی زبان کو پروسیس کرتا ہے اور ایسا منظم ڈیٹا فراہم کرتا ہے جسے دوسرے ایجنٹس فوری طور پر استعمال کر سکیں۔ اسمارٹ ہوم ہب سے لے کر صنعتی کنٹرول پینلز تک، ہر وہ سسٹم جسے ریئل ٹائم منظم ان پٹ کی ضرورت ہے، اسے ایک 'پرسیپشن لیئر' (perception layer) کے طور پر استعمال کر سکتا ہے۔
زنجیر کی سب سے کمزور کڑی
غور کریں کہ کیا ہوتا ہے جب کوئی صارف ایک سادہ سی کمانڈ دیتا ہے جیسے "یہاں روشنی تھوڑی بڑھا دو"۔ ایک ملٹی ایجنٹ سیٹ اپ میں، اس جملے کو لائٹنگ کنٹرولر، انرجی مانیٹر، اور سیکیورٹی لاگر سے گزرنا پڑ سکتا ہے۔ اگر ابتدائی پارسر ایک مبہم جملہ واپس کرتا ہے جیسے "صارف کو مزید روشنی چاہیے،" تو ہر اگلے ایجنٹ کو اس کے معنی کی دوبارہ تشریح کرنی پڑتی ہے۔ کچھ ایجنٹس درست پیرامیٹرز کے انتظار میں رک سکتے ہیں، جبکہ کچھ کمرے یا روشنی کی سطح کا اندازہ لگا کر غلطی کر سکتے ہیں۔ اس طرح ورک فلو رک جاتا ہے۔
لیٹنسی (Latency) اس مسئلے کو مزید خراب کر دیتی ہے۔ اگر انٹری پوائنٹ پر پارسنگ میں چند سو ملی سیکنڈ کی تاخیر بھی ہو جائے، تو جب تک معلومات تیسرے ایجنٹ تک پہنچتی ہیں، سسٹم پہلے ہی ناکام محسوس ہونے لگتا ہے۔ ریئل ٹائم ماحول سست آغاز کو برداشت نہیں کرتے۔ ڈویلپرز یہ دیکھ رہے ہیں کہ آرکیٹریشن فریم ورکس آرکیٹیکچر ڈایاگرام پر تو خوبصورت نظر آتے ہیں لیکن جب انہیں مبہم یا سست ان پٹ دیا جاتا ہے تو وہ ناکام ہو جاتے ہیں۔ آپ کو ایک ایسی مخصوص تہہ (layer) کی ضرورت ہے جو ورک فلو کے سوچنے سے پہلے ہی کمانڈز کو معیاری بنا دے۔
Domux اسی تہہ کے طور پر ڈیزائن کیا گیا ہے۔ یہ انسانی زبان کی پیچیدگیوں کو قبول کرتا ہے اور اسے ایک صاف ستھرے اسکیمہ (schema) میں تبدیل کر دیتا ہے جسے بعد والے ایجنٹس مستند ڈیٹا (ground truth) کے طور پر استعمال کر سکتے ہیں۔
رفتار، ساخت اور درستگی
یہ پروجیکٹ تین ایسی خصوصیات کا اشتہار دیتا ہے جو براہ راست پروڈکشن کے عمل پر اثر انداز ہوتی ہیں۔
پہلا، یہ 150 ملی سیکنڈ سے کم میں جواب دیتا ہے۔ یہ حد بہت اہمیت رکھتی ہے۔ انٹرایکٹو سیٹنگز میں، ایک چوتھائی سیکنڈ سے کم کا جواب فوری محسوس ہوتا ہے، جبکہ ایک مکمل سیکنڈ کے قریب کا کوئی بھی جواب صارفین کو ٹول چھوڑنے پر مجبور کر دیتا ہے۔ چاہے ان پٹ آواز سے آئے یا چیٹ انٹرفیس سے، domux پائپ لائن کو متحرک رکھتا ہے۔
دوسرا، یہ ان پٹ کو ایک سخت سات فیلڈز والے اسکیمہ (schema) میں ترتیب دیتا ہے۔ بعد والے سسٹمز کے لیے ڈی کوڈ کرنے کے لیے کوئی آزاد متن (free-form text) نہیں ہوتا۔ ہر کمانڈ کو پیش گوئی کے قابل کالموں میں رکھا جاتا ہے۔
تیسرا، یہ 100 فیصد فارمیٹ کی تعمیل کے ساتھ 98.37 فیصد درستگی کا دعویٰ کرتا ہے۔ درستگی کا مطلب ہے کہ ماڈل عام طور پر صارف کو صحیح سمجھتا ہے۔ فارمیٹ کی تعمیل کا مطلب ہے کہ آؤٹ پٹ ہر بار ساختی طور پر درست ہوتا ہے۔ ایک ایسا پارسر جو 99 فیصد درست ہو لیکن کبھی کبھار کوئی فیلڈ چھوڑ دے یا کوئی نئی فیلڈ بنا دے، وہ خودکار زنجیر میں ایک خطرہ بن جاتا ہے۔ ایک غلط فارمیٹ والی قطار بھی صارف ایجنٹ کو کریش کر سکتی ہے۔
آؤٹ پٹ اصل میں ایسا نظر آتا ہے۔ جب ماڈل کسی کمانڈ کو پروسیس کرتا ہے، تو یہ ایک پائپ-ڈیلیمیٹڈ (pipe-delimited) ریکارڈ واپس کرتا ہے:
action|device|attribute|value|unit|room|floorturnOn|light|brightness|80|percent|living room|ground floor
یہ فارمیٹ جان بوجھ کر منتخب کیا گیا ہے۔ پائپ-ڈیلیمیٹڈ ٹیکسٹ کو کسی بھی پروگرامنگ زبان میں بھاری انحصار کے بغیر آسانی سے پارس کیا جا سکتا ہے۔ یہ JSON کے بوجھ (bloat) اور نیاسٹڈ سیریلائزیشن (nested serialization) کی تاخیر سے بچاتا ہے۔ ایک لائٹنگ ایجنٹ 'action' اور 'device' کالموں کو پڑھ کر فوری کارروائی کر سکتا ہے۔ ایک لاگنگ ایجنٹ بغیر کسی اضافی انفرنس پاس کے 'room' اور 'floor' نکال سکتا ہے۔ یہ ساخت ڈیزائن کے لحاظ سے ابہام کو ختم کر دیتی ہے۔
پیچیدہ انسانی ارادوں کو سنبھالنا
حقیقی لوگ API دستاویزات کی طرح بات نہیں کرتے۔ وہ "روشنی بڑھا دو" یا "یہاں کا ماحول تھوڑا گرم کر دو" جیسی باتیں کرتے ہیں۔ ایک کمزور پارسر ان پر ناکام ہو جائے گا۔ Domux ارادے کو ایک ایڈجسٹمنٹ ایکشن سے جوڑ کر اس ابہام کو سنبھالتا ہے اور بعد والے سسٹمز کو درست ویلیو طے کرنے دیتا ہے۔ اگر کوئی کہتا ہے "روشنی بڑھا دو،" تو ماڈل اس ایکشن کو برائٹنس میں اضافے کے طور پر شناخت کرتا ہے۔ مخصوص عددی سطح کا فیصلہ لائٹنگ ایجنٹ پر چھوڑ دیا جاتا ہے جو موجودہ ریڈنگز، وقت، یا