ایویلیویشن پر مبنی ایجنٹ ڈویلپمنٹ: میں نے محض اندازوں (vibes) پر پرامپٹس کو ٹیون کرنا کیسے چھوڑا

میں نے ایک پرامپٹ بدلا۔ اگلی بار رن (run) بہتر نظر آیا۔ کیا اس تبدیلی نے مدد کی، یا میں خوش قسمت تھا؟

کافی عرصے تک، میرا جواب ہوتا تھا "میرا خیال ہے کہ ہاں"۔ میں ایک کمانڈ میں تھوڑی بہتری لاتا، پائپ لائن (pipeline) چلاتا، اسے کامیاب ہوتے دیکھتا، اور پھر اسے ریلیز کر دیتا۔ یہ محض اندازوں (vibes) پر مبنی انجینئرنگ ہے۔ ایجنٹس بنانے والا تقریباً ہر شخص یہی کرتا ہے کیونکہ اس کا متبادل مشکل محسوس ہوتا ہے۔

لیکن کوڈنگ ایجنٹس غیر یقینی (non-deterministic) ہوتے ہیں۔ آپ ایک ہی کام کو دو بار چلا سکتے ہیں اور دو مختلف نتائج حاصل کر سکتے ہیں۔ ایک بار کا اچھا رن آپ کو کچھ نہیں بتاتا۔ آپ یہ نہیں بتا سکتے کہ آپ کی تبدیلی نے کام کیا یا محض قسمت نے ساتھ دے دیا۔

میں نے مشین لرننگ کے اصولوں کو اپنا کر اس کا حل نکالا۔ میں نے اپنے پورے سسٹم کو گھیرنے کے لیے ایک ایویلیویشن فریم ورک (evaluation framework) بنایا۔

یہ فریم ورک اس طرح کام کرتا ہے:

• Target: ایک فریز شدہ کوڈ بیس۔ یہ ایک جیسا رہتا ہے تاکہ اسکورز کا موازنہ کیا جا سکے۔ • Task: ایک مخصوص بینچ مارک آئٹم جس میں ایک پرامپٹ اور ایک اوریکل (oracle) ہو۔ • Oracle: ایک یقینی چیک (deterministic check)۔ یہ وہ شیل کمانڈز ہیں جن کا پاس ہونا ضروری ہے۔ • Variant: وہ مخصوص تبدیلی جس کی آپ جانچ کر رہے ہیں، جیسے کہ ایک نیا پلانر۔ • Trial: ایک واحد رن۔ میں بے یقینی (randomness) کو مدنظر رکھتے ہوئے ہر ٹاسک کو کئی بار چلاتا ہوں۔

میں مختلف قسم کی ناکامیوں کو پکڑنے کے لیے دو طرح کے اسکورنگ کا استعمال کرتا ہوں:

  • Code Graders (Deterministic): یہ ٹیسٹ پاس ہونے کی شرح، لاگت، وقت، اور فائل کی تبدیلیوں کو چیک کرتے ہیں۔
  • LLM Judge (Probabilistic): ایک الگ، مستقل ماڈل سپیسیفیکیشن کی کوالٹی اور امپلیمنٹیشن کی درستگی کو اسکور کرتا ہے۔

کوڈ گریڈرز آپ کو بتاتے ہیں کہ کیا کوڈ چل رہا ہے۔ جج آپ کو بتاتا ہے کہ کیا کوڈ اچھا ہے۔ آپ کو دونوں کی ضرورت ہے۔

میں نے اوسط (averages) کا استعمال بھی چھوڑ دیا۔ اوسط (means) ایجنٹس کے بارے میں جھوٹ بولتے ہیں۔ اگر کوئی ٹاسک 3 میں سے 2 بار کامیاب ہو جائے، تو یہ ٹھیک لگتا ہے۔ لیکن یہ قابل اعتماد نہیں ہے۔ اس کے بجائے، میں دو میٹرکس (metrics) استعمال کرتا ہوں:

  • pass@k: کیا ایجنٹ کم از کم ایک بار کامیاب ہوا؟ (صلاحیت)
  • pass^k: کیا ایجنٹ ہر بار کامیاب ہوا؟ (قابل اعتماد ہونا)

pass^k میں اضافہ ہی اصل کامیابی ہے۔ اس کا مطلب ہے کہ آپ نے ایجنٹ کو مستقل مزاج (consistent) بنا دیا ہے، نہ کہ صرف خوش قسمت۔

سسٹم کو بہتر رکھنے کے لیے، میں ایسے مشکل ٹاسک شامل کرتا ہوں جن کے لیے گہری سمجھ بوجھ کی ضرورت ہو۔ جب کوئی ایجنٹ کسی حقیقی بگ (bug) پر ناکام ہوتا ہے، تو میں اس ناکامی کو ایک مستقل ٹاسک میں بدل دیتا ہوں۔ اس سے ایک کلوزڈ لوپ (closed loop) بن جاتا ہے۔ جیسے جیسے ایجنٹ بہتر ہوتا جاتا ہے، بینچ مارک بھی مشکل ہوتا جاتا ہے۔

یہ انفراسٹرکچر بنانے میں بہت محنت لگتی ہے، لیکن یہ میری بنائی ہوئی سب سے زیادہ فائدہ مند چیز ہے۔ اس نے "میرا خیال ہے کہ یہ بہتر ہے" کو "یہ کم لاگت پر 20 فیصد زیادہ قابل اعتماد ہے" میں بدل دیا۔

کوڈنگ ایجنٹس کا ڈیمو دینا آسان ہے لیکن ان پر بھروسہ کرنا مشکل ہے۔ اگر آپ صرف ڈیمو سے آگے بڑھنا چاہتے ہیں، تو آپ کو پیمائش (measure) کرنے کا فیصلہ کرنا ہوگا۔

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi