ভেরিফিকেশন খরচই হলো এআই কোডিংয়ের আসল খরচ
কোডিংয়ের জন্য একটি এআই মডেল বেছে নেওয়ার সময় আমি একটি প্রশ্ন করতাম।
এই কাজের জন্য কোন মডেলটি যথেষ্ট শক্তিশালী?
প্রশ্নটি ঠিক আছে। কিন্তু এটি এখন আর আমার প্রথম প্রশ্ন নয়।
আরও ভালো প্রশ্ন হলো: আমি কত দ্রুত আউটপুটটি যাচাই (verify) করতে পারি?
এই মানসিকতা আপনি কীভাবে কম খরচের মডেলগুলো ব্যবহার করবেন তা বদলে দেয়। সেগুলোকে বড় মডেলগুলোর দুর্বল সংস্করণ হিসেবে দেখবেন না। বরং সেগুলোকে এমন কাজের জন্য কর্মী হিসেবে দেখুন যেগুলোর ভেরিফিকেশন প্রক্রিয়া সহজ বা সংক্ষিপ্ত।
কিছু কাজ রিভিউ করা সাশ্রয়ী কারণ আপনি ফলাফলগুলো সাথে সাথে দেখতে পান।
• README ক্লিনআপ • ব্যবহারের উদাহরণ (Usage examples) • কোড কমেন্ট (Code comments) • চেঞ্জলগ নোট (Changelog notes) • ছোট ফরম্যাটিং স্ক্রিপ্ট (Small formatting scripts) • ইস্যু টেমপ্লেট (Issue templates)
যদি একটি মডেল একটি খারাপ README প্যারাগ্রাফ লেখে, আপনি তা দেখতে পাবেন। আপনি খারাপ অংশটি মুছে ফেলবেন। ভুলটি বিরক্তিকর হতে পারে, কিন্তু এতে আপনার প্রায় কোনো খরচই হবে না। সস্তা মডেলগুলোর জন্য এটিই সেরা ব্যবহার।
পরবর্তী বিভাগ হলো টেস্টযোগ্য কাজ (testable work)।
আপনি যদি প্রত্যাশিত আচরণ (expected behavior) সংজ্ঞায়িত করতে পারেন এবং একটি টেস্ট স্যুট (test suite) চালাতে পারেন, তবে প্রথম ড্রাফটের জন্য একটি সস্তা মডেল ব্যবহার করুন। আপনাকে মডেলটিকে স্পষ্ট সীমানা দিতে হবে।
বলবেন না: 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) • ছোট ডেটা কনভার্সন স্ক্রিপ্ট (Small data conversion scripts)
এগুলোর জন্য মডেলটিকে নিচের বিষয়গুলো অন্তর্ভুক্ত করতে বলুন:
- কোডটি কীভাবে চালাতে হবে
- কী ইনপুট ব্যবহার করতে হবে
- কী আউটপুট আশা করা যায়
- কোন এজ কেসগুলো (edge cases) চেক করতে হবে
যদি একটি মডেল তার নিজের কাজ কীভাবে যাচাই করতে হবে তা ব্যাখ্যা করতে না পারে, তবে সেই কোডটি বিশ্বাস করবেন না।
ছোট রিফ্যাক্টর (refactor) বিপজ্জনক হতে পারে। একটি ডিফ (diff) দেখতে ছোট এবং পরিষ্কার মনে হতে পারে। কিন্তু কোনো লুকানো পাথ (path), ডিফল্ট ভ্যালু বা পারমিশন চেকের ক্ষেত্রে আচরণ বদলে যেতে পারে।
যখন কোনো কাজ নিচের বিষয়গুলোকে স্পর্শ করে, তখন আপনার ঝুঁকির মাত্রা বাড়িয়ে দিন:
- Fallbacks
- Defaults
- Routing
- Permissions
- Billing
- Rate limits
- Migrations
- Backwards compatibility
এই ভুলগুলো একটি সাধারণ কোড রিভিউতে দেখা কঠিন। এগুলোর জন্য গভীর প্রেক্ষাপট (deep context) প্রয়োজন।
ভেরিফিকেশন খরচ অনুযায়ী আপনার কাজ ভাগ করুন:
- কম ভেরিফিকেশন খরচ: ড্রাফট করার জন্য একটি কম খরচের মডেল ব্যবহার করুন।
- মাঝারি ভেরিফিকেশন খরচ: একটি কম খরচের মডেল ব্যবহার করুন, তারপর মানুষের মাধ্যমে এডিট করুন।
- উচ্চ ভেরিফিকেশন খরচ: টেস্ট এবং মানুষের রিভিউসহ একটি শক্তিশালী মডেল ব্যবহার করুন।
আকার কোনো বিষয় নয়। একটি ছোট কাজও ব্যয়বহুল হতে পারে যদি সেটি যাচাই করা কঠিন হয়।
এআই কোডিংয়ের ব্যয়বহুল অংশটি জেনারেশন নয়। এটি হলো বিশ্বাস (trust)।
Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354
Optional learning community: https://t.me/GyaanSetuAi