HarnessDev: LLMs اپنی خود مختار انفراسٹرکچر خود تیار کر رہے ہیں
ByteDance اور یونیورسٹیوں کے ایک گروپ نے HarnessDev متعارف کرایا ہے، جو ایک ایسا فریم ورک ہے جو لارج لینگویج ماڈلز (LLMs) کو اپنے "ایجنٹ آپریٹنگ سسٹم" لکھنے کی اجازت دیتا ہے، جنہیں Agent Harnesses کہا جاتا ہے۔ ٹیم ایک LLM کو ایک مختصر اسٹارٹر کٹ فراہم کرتی ہے اور اسے باقی کام خود کرنے دیتی ہے، جس سے یہ ظاہر ہوتا ہے کہ AI کس طرح ایک ایسا کنٹرول لیئر تیار کر سکتا ہے جو اپنے ٹول استعمال کرنے والے لوپس، تصدیقی مراحل اور ایرر ہینڈلنگ کو خود چلا سکے—بغیر کسی انسان کے ہر لائن ٹائپ کیے ۔
خود ساختہ ہارسنس (harness) کیوں اہم ہے
AI ایجنٹس سنگل پرامپٹ اسسٹنٹ سے ارتقاء پا کر اب ملٹی سٹیپ ورکرز بن چکے ہیں جو APIs کو کال کرتے ہیں، ڈیٹا بیسز سے معلومات حاصل کرتے ہیں اور نتائج کو آپس میں جوڑتے ہیں۔ اب تک، ڈویلپرز خود وہ آرکیسٹریشن کوڈ تیار کرتے تھے جو ماڈل کو بتاتا تھا کہ سرچ ٹول کب استعمال کرنا ہے، عبوری حالت (intermediate state) کو کیسے محفوظ کرنا ہے، اور حتمی جواب کی تصدیق کیسے کرنی ہے۔ HarnessDev اس ماڈل کو بدل دیتا ہے: ایک seed harness صرف ضروری بنیادی ڈھانچہ فراہم کرتا ہے—جیسے لوپنگ، ٹولز کا انتخاب، اور اسٹیٹ ٹریک کرنے کے بنیادی فنکشنز—اور پھر LLM اسے ایک مکمل فیچر والے رن ٹائم میں تبدیل کر دیتا ہے۔
پیپر کے بینچ مارک میں، ماڈل نے 18 مختلف ہارسنسز تیار کیے، جس سے اصل سیڈ میں 17,000 سے زیادہ لائنوں کا کوڈ شامل ہو گیا۔ ہر ہارسنس نے کسی کام کے مکمل لائف سائیکل کو سنبھالا: لوپس کو چلانا، صحیح ٹول کا انتخاب کرنا، سیاق و سباق (context) کو برقرار رکھنا، اسٹیٹ کو ٹریک کرنا، نتائج کی تصدیق کرنا، اور غلطیوں سے نکلنا۔
وہ پوشیدہ اخراجات جو اس تحقیق میں سامنے آئے
اعداد و شمار متاثر کن لگتے ہیں، لیکن مصنفین نے خبردار کیا ہے کہ محض کوڈ کی تیاری کا مطلب عملی استعمال نہیں ہے۔
- غیر استعمال شدہ اجزاء – تیار کردہ کوڈ کا ایک بڑا حصہ اصل کام کے دوران کبھی استعمال نہیں ہوا۔ LLM نے ایسے فنکشنز لکھے جنہیں ایجنٹ نے کبھی کال نہیں کیا، جس سے کوڈ بیس تو بڑھ گئی لیکن کوئی فائدہ نہیں ہوا۔
- ماڈل لاک-ان (Model lock-in) – ہارسنسز کا رجحان اس مخصوص LLM کے مطابق ڈھلنے کا تھا جس نے انہیں بنایا تھا۔ جب وہی ہارسنس کسی دوسرے ماڈل کو دیا گیا، تو کارکردگی میں نمایاں کمی آئی، جس سے یہ ظاہر ہوتا ہے کہ خودکار طور پر تیار کردہ کنٹرول لاجک میں ماڈل کے مخصوص انداز (quirks) شامل ہو جاتے ہیں۔
- تصدیقی خلا (Verification gaps) – ایک ٹیسٹ ہارسنس نے 99% کامیابی کی شرح (100 میں سے 99 بار) رپورٹ کی لیکن وہ صرف 48% بار درست تھا۔ مضبوط تصدیق کے بغیر، ایک ایجنٹ اعتماد کے ساتھ غلط جوابات پیش کر سکتا ہے۔
- ٹوکن کا اضافی بوجھ (Token overhead) – ٹوکن کا استعمال—جو کمپیوٹیشن کی لاگت کا پیمانہ ہے—بہت زیادہ مختلف تھا۔ ایک ہی نتیجہ حاصل کرنے کے لیے ایک ہارسنس کو دوسرے کے مقابلے میں سات گنا زیادہ ٹوکنز درکار تھے، جس سے پروڈکشن سیٹنگز میں اس کی پیمائش (scalability) کے حوالے سے خدشات پیدا ہوتے ہیں۔
یہ نتائج اس ضرورت پر روشنی ڈالتے ہیں کہ کوڈ چاہے LLM سے ہی کیوں نہ نکلے، ڈیزائن میں نظم و ضبط ہونا ضروری ہے۔
ڈویلپرز کو کن باتوں کا خیال رکھنا چاہیے
- ہارسنس ڈیزائن کو آرکیٹیکچر کے طور پر لیں – ماڈل کے "خود ہی کام کرنے" پر بھروسہ نہ کریں۔ LLM کو انہیں بھرنے دینے سے پہلے لوپ کنٹرول، ٹول کا انتخاب، اسٹیٹ ہینڈلنگ اور تصدیق کے لیے واضح ماڈیولز متعین کریں۔
- مضبوط تصدیق کا نظام بنائیں – ایسے واضح چیکس شامل کریں جو ایجنٹ کے دعوے کا موازنہ اصل حقیقت (ground truth) یا کسی دوسرے ماڈل سے کریں۔ 99% خود رپورٹ شدہ کامیابی کے باوجود تحقیق کی 48% درستگی یہ ظاہر کرتی ہے کہ تصدیق کو بعد کے لیے نہیں چھوڑا جا سکتا۔
- ٹوکن بجٹ پر نظر رکھیں – زیادہ پیچیدہ ہارسنسز ٹوکن کی تعداد کو بہت زیادہ بڑھا سکتے ہیں۔ پوشیدہ اخراجات کے دھماکے سے بچنے کے لیے ہارسنس کے مختلف ورژنز کا جلد از جلد جائزہ لیں۔
- مختلف ماڈلز پر ٹیسٹ کریں – ایک ہی ہارسنس کو متعدد LLM بیک اینڈز کے ساتھ چلا کر دیکھیں۔ اگر کارکردگی میں تیزی سے کمی آتی ہے، تو آپ کو زیادہ ماڈل سے آزاد (model-agnostic) ڈیزائن یا ہر ماڈل کے لیے الگ ہارسنس کی ضرورت پڑ سکتی ہے۔
خلاصہ: HarnessDev یہ ثابت کرتا ہے کہ LLMs اپنے آپ کے لیے آپریٹنگ سسٹم جیسے کنٹرول کوڈ کا مسودہ تیار کر سکتے ہیں۔