মডেল নয়, হারনেসকে বিশ্বাস করুন
আমার হোম হার্ডওয়্যারে চলা একটি লোকাল 27B কোডিং মডেল অনেকটা ভাগ্যের ওপর নির্ভর করে। কখনও কখনও এটি বিশ মিনিটে কোড ঠিক করে দেয়। আবার কখনও এটি ভুল ফাইল এডিট করে অথবা এমন একটি টেস্ট লেখে যা যেকোনো পরিস্থিতিতেই পাস হয়ে যায়।
LLMKube-এর Foreman-এর লক্ষ্য একটি নিখুঁত মডেল খুঁজে বের করা নয়। লক্ষ্য হলো এমন একটি হারনেস (harness) তৈরি করা যা আপনি মডেলের চেয়ে বেশি বিশ্বাস করতে পারেন।
এই উইকেন্ডে, হারনেসটি নিজেই নিজের গার্ডরেল (guardrails) তৈরি করে নিজেকে পরীক্ষা করেছে। যা ঘটেছে তা নিচে দেওয়া হলো:
• আমার লোকাল কোডার নিজের জন্য তিনটি নতুন গেট (gate) তৈরি করেছে। • একটি গেট ঠিক সেই ত্রুটি নিয়েই এসেছিল যা ধরার কথা ছিল। রিভিউ প্রসেস সেটি ধরে ফেলেছিল। • মেশিনগুলো কাজ করার সময় তিনজন নতুন মানব অবদানকারী চারটি ক্লিন পুল রিকোয়েস্ট (pull request) পাঠিয়েছেন। • একই মডেল একটি AMD বক্স এবং একটি Apple Silicon Mac-এ চলেছে। ম্যাকটি এমন একটি রাউন্ড জিতেছে যা কেউ আশা করেনি। • কোনো ডেটা ক্লাউড API-তে স্পর্শ করেনি।
একটি লোকাল মডেলে কোডিং এজেন্ট পরিবর্তনশীল মানের ফলাফল দেয়। প্রম্পট টিউনিং (prompt tuning) যতই করা হোক না কেন, একটি ছোট মডেলকে ফ্রন্টিয়ার মডেলের (frontier model) মতো নির্ভরযোগ্য করে তোলা সম্ভব নয়।
Foreman মডেলটিকে নির্ভরযোগ্য হওয়ার জন্য অনুরোধ করে না। এটি মডেলটিকে একটি পাইপলাইনের (pipeline) মাধ্যমে আবৃত করে রাখে:
- কোডার একটি ক্লোন করা ওয়ার্কস্পেসে কাজ করে।
- একটি দ্রুত গেট gofmt, vet, build, lint, এবং ইউনিট টেস্ট চালায়।
- একজন রিভিউয়ার ইস্যুর বিপরীতে ডিফ (diff) পড়েন।
- কোনো কোড অনুমোদনের আগে একটি ক্লিন-রুম Kubernetes Job সম্পূর্ণ স্যুটটি পুনরায় চালায়।
- পুরো প্রক্রিয়ার চারপাশে স্কোপ চেক (scope checks) এবং রেপো-ম্যাপ কনটেক্সটের (repo-map context) মতো ডিটারমিনিস্টিক রেইলস (deterministic rails) থাকে।
মডেলটি একটি সিস্টেমের একটি অনির্দিষ্ট অংশ মাত্র। সিস্টেমের কাজ হলো মডেলটি নির্ভরযোগ্য না হলেও সিদ্ধান্ত বা ভারডিক্টকে (verdict) বিশ্বাসযোগ্য করে তোলা।
আসল প্রশ্নটি "মডেলটি কি ভালো" তা নয়। প্রশ্নটি হলো "মডেলটি যখন খারাপ কাজ করে, তখন হারনেস কি তা ধরতে পারে?"
এই উইকেন্ডে, হারনেসটি দুটি বড় বাগ (bug) ধরে ফেলেছে। উভয়ই ছিল সেলফ-কনফার্মিং টেস্ট (self-confirming tests)। টেস্টগুলো পাস করেছিল কারণ টেস্টগুলো নিজেই পাস করার জন্য লেখা হয়েছিল। সেগুলো আসলে কোড পরীক্ষা করেনি।
আমি এই ব্যর্থতাগুলো Foreman-এর কাছে ফেরত দিয়েছি। আমি হারনেসটিকে সেগুলো ঠিক করার জন্য গেট তৈরি করতে দিয়েছি:
- একটি স্কোপ গার্ড (scope guard): এটি ভুল সাবসিস্টেম স্পর্শ করে এমন যেকোনো এডিট প্রত্যাখ্যান করে।
- একটি রিভিউয়ার রুব্রিক (reviewer rubric): এটি নিশ্চিত করে যে টেস্টগুলো প্লেসহোল্ডারের পরিবর্তে আসল প্রোডাকশন ভ্যালু ব্যবহার করছে।
- একটি বাইট চেক (bite check): একটি নতুন টেস্টকে অবশ্যই পুরনো কোডের বিপরীতে ফেইল করতে হবে। যদি এটি উভয় ক্ষেত্রেই পাস করে, তবে এটি আসল টেস্ট নয়।
বাইট চেকটি তার নিজের প্রথম টেস্টেই ব্যর্থ হয়েছিল। এটি যে গেটটি তৈরি করেছিল তাতে ত্রুটি ছিল। কিন্তু মার্জ হওয়ার আগেই রিভিউ প্রসেসটি সেই ভুলটি ধরে ফেলেছিল। এটাই ডিজাইনের সার্থকতা।
লোকালি ইঞ্জিনিয়ারিং কাজ করার জন্য আপনার বিশাল কোনো ফ্রন্টিয়ার মডেলের প্রয়োজন নেই। আপনার প্রয়োজন একটি বিশ্বাসযোগ্য হারনেস। সেটি তৈরি করুন, এবং একটি ছোট মডেল আপনার একজন দরকারী সহকর্মী হয়ে উঠবে। এটি এমন একটি সিস্টেমে পরিণত হবে যা ভুলগুলো ধরে ফেলে, ফলে মাঝরাতে আপনাকে কোডের প্রতিটি লাইন পড়তে বাধ্য করবে না।
Optional learning community: https://t.me/GyaanSetuAi