ইভাল-চালিত (Eval-Driven) এজেন্ট ডেভেলপমেন্ট: কীভাবে আমি অনুমানের ভিত্তিতে প্রম্পট টিউন করা বন্ধ করলাম

আমি একটি প্রম্পট পরিবর্তন করলাম। পরের রানটি আরও ভালো দেখাচ্ছিল। পরিবর্তনটি কি আসলেই সাহায্য করেছে, নাকি আমি কেবল ভাগ্যবশত সফল হয়েছি?

দীর্ঘ সময় ধরে আমার উত্তর ছিল "আমার মনে হয় তাই।" আমি একটি কমান্ড সামান্য পরিবর্তন করতাম, পাইপলাইনটি চালাতাম, সেটি সফল হতে দেখতাম এবং তারপর তা শিপ (ship) করে দিতাম। এটি হলো 'ভাইবস-বেসড' (vibes-based) ইঞ্জিনিয়ারিং। এজেন্ট তৈরির প্রায় সবাই এটি করে কারণ এর বিকল্প পদ্ধতিগুলো বেশ কঠিন মনে হয়।

কিন্তু কোডিং এজেন্টগুলো নন-ডিটারমিনিস্টিক (non-deterministic)। আপনি একই টাস্ক দুবার চালাতে পারেন এবং দুটি ভিন্ন ফলাফল পেতে পারেন। একটি মাত্র ভালো রান আপনাকে কিছুই জানাতে পারে না। আপনার পরিবর্তনটি কাজ করেছে নাকি কেবল ভাগ্য সহায় ছিল, তা আপনি বুঝতে পারবেন না।

আমি মেশিন লার্নিং ডিসিপ্লিন ব্যবহার করে এই সমস্যার সমাধান করেছি। আমি আমার পুরো সিস্টেমটিকে ঘিরে একটি ইভালুয়েশন ফ্রেমওয়ার্ক (evaluation framework) তৈরি করেছি।

ফ্রেমওয়ার্কটি যেভাবে কাজ করে:

• টার্গেট (Target): একটি স্থির কোডবেস (frozen codebase)। স্কোরগুলো যেন তুলনামূলকভাবে বোঝা যায়, তাই এটি অপরিবর্তিত থাকে। • টাস্ক (Task): একটি প্রম্পট এবং একটি ওরাকল (oracle) সহ একটি নির্দিষ্ট বেঞ্চমার্ক আইটেম। • ওরাকল (Oracle): একটি ডিটারমিনিস্টিক চেক। এগুলো হলো কিছু শেল কমান্ড যা অবশ্যই পাস করতে হবে। • ভেরিয়েন্ট (Variant): আপনি যে নির্দিষ্ট পরিবর্তনটি পরীক্ষা করছেন, যেমন একটি নতুন প্ল্যানার। • ট্রায়াল (Trial): একটি একক রান। র‍্যান্ডমনেস (randomness) বা অনিশ্চয়তার বিষয়টি বিবেচনায় রাখতে আমি প্রতিটি টাস্ক একাধিকবার চালাই।

বিভিন্ন ধরনের ব্যর্থতা শনাক্ত করতে আমি দুই ধরনের স্কোরিং পদ্ধতি ব্যবহার করি:

  • কোড গ্রেডার্স (Code Graders - Deterministic): এগুলো টেস্ট পাস রেট, খরচ, সময় এবং ফাইল পরিবর্তন পরীক্ষা করে।
  • এলএলএম জাজ (LLM Judge - Probabilistic): একটি আলাদা, নির্দিষ্ট মডেল স্পেক কোয়ালিটি (spec quality) এবং ইমপ্লিমেন্টেশন ফিডেলিটি (implementation fidelity) স্কোর করে।

কোড গ্রেডার আপনাকে জানায় কোডটি কাজ করছে কি না। জাজ আপনাকে জানায় কোডটি কতটা ভালো। আপনার উভয়েরই প্রয়োজন।

আমি গড় (average) ব্যবহার করাও বন্ধ করে দিয়েছি। গড় মান এজেন্টদের সম্পর্কে ভুল ধারণা দিতে পারে। যদি একটি টাস্ক ৩ বারের মধ্যে ২ বার সফল হয়, তবে এটি ঠিক মনে হতে পারে। কিন্তু এটি নির্ভরযোগ্য নয়। এর পরিবর্তে, আমি দুটি মেট্রিক ব্যবহার করি:

  • pass@k: এজেন্ট কি অন্তত একবার সফল হয়েছে? (Capability)
  • pass^k: এজেন্ট কি প্রতিবারই সফল হয়েছে? (Reliability)

pass^k-এ বৃদ্ধি পাওয়াটাই হলো আসল সাফল্য। এর মানে হলো আপনি এজেন্টটিকে কেবল ভাগ্যবান নয়, বরং ধারাবাহিক (consistent) করে তুলেছেন।

সিস্টেমটিকে তীক্ষ্ণ রাখতে আমি এমন কিছু কঠিন টাস্ক যোগ করি যেগুলোর জন্য গভীর অনুধাবনের প্রয়োজন হয়। যখন কোনো এজেন্ট একটি রিয়েল বাগের ক্ষেত্রে ব্যর্থ হয়, আমি সেই ব্যর্থতাকে একটি স্থায়ী টাস্কে পরিণত করি। এটি একটি ক্লোজড লুপ (closed loop) তৈরি করে। এজেন্ট যত উন্নত হয়, বেঞ্চমার্ক তত কঠিন হতে থাকে।

এই ইনফ্রাস্ট্রাকচার তৈরি করা অনেক পরিশ্রমের কাজ, কিন্তু এটি আমার তৈরি করা সবচেয়ে কার্যকর (highest leverage) জিনিস। এটি "আমার মনে হয় এটি আরও ভালো" কথাটিকে "এটি কম খরচে ২০% বেশি নির্ভরযোগ্য" হিসেবে বদলে দিয়েছে।

কোডিং এজেন্টগুলোর ডেমো দেখানো সহজ কিন্তু বিশ্বাস করা কঠিন। আপনি যদি ডেমোর গণ্ডি পেরিয়ে সামনে এগোতে চান, তবে আপনাকে পরিমাপ করার (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