স্বল্পমূল্যের AI কোডিং মডেলের জন্য একটি ভেরিফিকেশন ল্যাডার
কোনো মডেল একটি কাজের জন্য যথেষ্ট শক্তিশালী কি না, তা জিজ্ঞেস করা বন্ধ করুন।
পরিবর্তে জিজ্ঞেস করা শুরু করুন যে আপনি কত দ্রুত আউটপুটটি যাচাই করতে পারবেন।
এই পরিবর্তনটি সস্তা AI মডেল ব্যবহারের পদ্ধতি বদলে দেবে। এদের দামী মডেলের দুর্বল সংস্করণ হিসেবে দেখবেন না। বরং এদের এমন কর্মী হিসেবে দেখুন যাদের কাজের যাচাইকরণ পথ (verification path) সংক্ষিপ্ত।
দৃশ্যমান আউটপুট আছে এমন কাজের জন্য স্বল্পমূল্যের মডেল ব্যবহার করুন। উদাহরণ:
- README ক্লিনআপ
- ব্যবহারের উদাহরণ (Usage examples)
- কোড কমেন্ট (Code comments)
- চ্যানজলগ নোট (Changelog notes)
- ছোট ফরম্যাটিং স্ক্রিপ্ট
- ইস্যু টেমপ্লেট (Issue templates)
যদি কোনো মডেল একটি খারাপ README লিখে ফেলে, আপনি তা সাথে সাথে দেখতে পাবেন। এর সমাধান করা দ্রুত এবং সাশ্রয়ী।
পরীক্ষাযোগ্য কাজের জন্য স্বল্পমূল্যের মডেল ব্যবহার করুন। আপনি যদি প্রত্যাশিত আচরণ (expected behavior) নির্ধারণ করে দেন এবং একটি টেস্ট স্যুট (test suite) চালান, তবে প্রথম ড্রাফটের জন্য আপনি একটি সস্তা মডেল ব্যবহার করতে পারেন। আপনাকে আপনার প্রম্পটে (prompt) কঠোর সীমাবদ্ধতা নির্ধারণ করতে হবে।
এর পরিবর্তে: "Add tests for this helper." ব্যবহার করুন: "Add tests for empty input, null input, duplicate values, invalid config, default config, and normal input. Do not change runtime code."
এটি মডেলটিকে একটি ভেরিফিকেশন ফ্রেমের মধ্যে কাজ করতে বাধ্য করে।
স্পষ্ট ম্যানুয়াল চেকের প্রয়োজন আছে এমন কাজের জন্য স্বল্পমূল্যের মডেল ব্যবহার করুন। উদাহরণ:
- CLI আউটপুট ফরম্যাটিং
- কনফিগ উদাহরণ (Config examples)
- মাইগ্রেশন ড্রাই-রান নোট (Migration dry-run notes)
- ছোট ডেটা কনভার্সন স্ক্রিপ্ট
এই কাজগুলোর জন্য, মডেলটিকে নিচের বিষয়গুলো অন্তর্ভুক্ত করতে বাধ্য করুন:
- কোডটি কীভাবে চালাতে হবে
- কী ইনপুট ব্যবহার করতে হবে
- কী আউটপুট আশা করা যায়
- কোন এজ কেসগুলো (edge cases) পরীক্ষা করতে হবে
যদি মডেলটি তার নিজের আউটপুট কীভাবে যাচাই করতে হবে তা ব্যাখ্যা করতে না পারে, তবে তাকে বিশ্বাস করবেন না।
উচ্চ-ঝুঁকিপূর্ণ রিফ্যাক্টরের (high-risk refactors) ক্ষেত্রে স্বল্পমূল্যের মডেল এড়িয়ে চলুন। ছোট পরিবর্তনগুলো প্রায়ই বড় বিপদ লুকিয়ে রাখে। একটি ছোট ডিফ (diff) একটি ফলব্যাক পাথ (fallback path), পারমিশন চেক বা কম্প্যাটিবিলিটি ব্রাঞ্চকে (compatibility branch) নষ্ট করে দিতে পারে।
নিচের বিষয়গুলো জড়িত কাজের ক্ষেত্রে আপনার ঝুঁকির মাত্রা বাড়িয়ে দিন:
- ফলব্যাক এবং ডিফল্ট (Fallbacks and defaults)
- রাউটিং এবং পারমিশন (Routing and permissions)
- বিলিং এবং রেট লিমিট (Billing and rate limits)
- মাইগ্রেশন এবং ব্যাকওয়ার্ড কম্প্যাটিবিলিটি (Migrations and backwards compatibility)
একটি সাধারণ কোড রিভিউতে এই ব্যর্থতাগুলো ধরা কঠিন। এগুলোর জন্য গভীর প্রেক্ষাপট (deep context) প্রয়োজন।
ভেরিফিকেশন খরচ অনুযায়ী আপনার কাজ ভাগ করুন: • স্বল্প খরচ: মডেল এটি ড্রাফট করবে। আপনি দ্রুত এটি যাচাই করবেন। • মাঝারি খরচ: মডেল এটি ড্রাফট করবে। একজন মানুষ এটি এডিট করবেন। • উচ্চ খরচ: একটি শক্তিশালী মডেল সাহায্য করবে। আপনার টেস্ট এবং ব্যাপক মানুষের পর্যালোচনার (human review) প্রয়োজন হবে।
কাজের আকার বড় বা ছোট হওয়া গুরুত্বপূর্ণ নয়। একটি ছোট কাজও ব্যয়বহুল হয়ে উঠতে পারে যদি সেটি যাচাই করা কঠিন হয়।
AI কোডিংয়ের খরচ জেনারেশনে নয়। খরচ হলো আস্থার (trust)।
উৎস: https://dev.to/zephyrelabs369/a-verification-ladder-for-low-cost-ai-coding-models-p16
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi