Red Hat-এর ২১৯টি রিয়েল-ওয়ার্ল্ড সেশনের বিশ্লেষণের মতে, Claude Code তার টোকেন বাজেটের তিন-চতুর্থাংশ ব্যয় করে শুধুমাত্র কোডবেস পড়ার জন্য। এই ফলাফলটি সেই প্রচলিত ধারণাটিকে উল্টে দেয় যেখানে মনে করা হয় যে AI-চালিত কোডিং এজেন্টরা কোড জেনারেট করতে গিয়ে সময় নষ্ট করে; বরং এটি নির্দেশ করে যে ডেভেলপারদের শুধুমাত্র মডেলের গতির দিকে নজর না দিয়ে কনটেক্সট-ম্যানেজমেন্ট (context-management) সমস্যার সমাধান করা উচিত।

এই দাবির পেছনের তথ্য

Red Hat, Anthropic-এর Claude Code-এর সাথে ২১৯টি ইন্টারঅ্যাকশন পরীক্ষা করেছে এবং প্রতিটি টার্নে টোকেন ব্যবহারের পরিমাণ গণনা করেছে। নমুনা অনুযায়ী, প্রতিটি মিডিয়ান টার্নে টোকেনের ৭৫% ব্যয় হয়েছে আশেপাশের কোড এবং ডকুমেন্টেশন গ্রহণ করতে, যেখানে মাত্র ২৫% ব্যয় হয়েছে নতুন লাইন তৈরির জন্য। যেহেতু বেশিরভাগ AI প্রোভাইডার ইনপুট এবং আউটপুট টোকেনের জন্য একই হারে চার্জ করে, তাই এই লেনদেনের "পড়ার" অংশটিই খরচের সিংহভাগ বহন করে।

কেন পড়ার খরচ গুরুত্বপূর্ণ

অপ্টিমাইজেশন কৌশল

অনেক টিম দ্রুত বা বড় মডেলের পেছনে সম্পদ বিনিয়োগ করে এই আশায় যে, গতি বৃদ্ধি প্রতিটি জেনারেশনে কয়েক সেকেন্ড বাঁচিয়ে দেবে। যদি কাজের তিন-চতুর্থাংশই কেবল কনটেক্সট সংগ্রহ করা হয়, তবে একটি দ্রুততর মডেল মোট সময়ের মাত্র একটি ক্ষুদ্র অংশ সাশ্রয় করতে পারে। আসল নিয়ন্ত্রক হলো প্রতিটি টার্নে মডেলটিকে কতটুকু কনটেক্সট প্রসেস করতে হচ্ছে।

খরচ নিয়ন্ত্রণ

যখন একটি AI অ্যাসিস্ট্যান্ট প্রতিটি অনুরোধে একই রিপোজিটরি স্টেট পুনরায় পড়ে, তখন ইনপুট টোকেনের পরিমাণ বহুগুণ বেড়ে যায়। বড় কনটেক্সট উইন্ডো বিশিষ্ট প্রজেক্টগুলোর বিল নাটকীয়ভাবে বেড়ে যেতে পারে, এমনকি যদি জেনারেট করা কোডের পরিমাণ সামান্যও হয়।

ইঞ্জিনিয়ারিং ফোকাস

টুল নির্মাতারা প্রায়শই প্রম্পট কীভাবে তৈরি করা হচ্ছে তা উপেক্ষা করে উচ্চতর মডেলের গুণমানের পেছনে ছোটে। এই বিশ্লেষণটি পরামর্শ দেয় যে, "কনটেক্সট ইঞ্জিনিয়ারিং" (context engineering) – অর্থাৎ মডেলকে দেওয়া কোডকে ছেঁটে ফেলা (trimming), ক্যাশ করা (caching) এবং সারসংক্ষেপ করা (summarizing) – মডেলের পর্যায়ক্রমিক আপগ্রেডের চেয়ে বেশি ROI প্রদান করে।

পড়ার অতিরিক্ত খরচ কমানোর ব্যবহারিক পদক্ষেপ

  • অপ্রাসঙ্গিক ফাইল ছেঁটে ফেলুন (Prune irrelevant files) – প্রম্পট থেকে সেই ফাইলগুলো সরিয়ে ফেলুন যেগুলোর বর্তমান কাজের জন্য প্রয়োজন নেই। ছোট প্রম্পট মানে কম ইনপুট টোকেন।
  • বারবার পড়া ক্যাশ করুন (Cache repeated reads) – কোডবেসের স্থিতিশীল অংশগুলোর মডেলের ব্যাখ্যা সংরক্ষণ করুন এবং একই টেক্সট বারবার না পাঠিয়ে প্রতিটি টার্নে তা পুনরায় ব্যবহার করুন।
  • টুল আউটপুট কম্প্রেস করুন (Compress tool outputs) – যখন এক্সটার্নাল টুলগুলো বড় ডেটা (যেমন: lint রিপোর্ট) প্রদান করে, তখন সেগুলো Claude-কে দেওয়ার আগে সারসংক্ষেপ করে নিন।
  • ইনক্রিমেন্টাল ডিফস ব্যবহার করুন (Use incremental diffs) – পুরো ফাইলের বিষয়বস্তু না পাঠিয়ে শুধুমাত্র শেষ টার্নের পর থেকে হওয়া পরিবর্তনগুলো পাঠান।

এই কৌশলগুলোর লক্ষ্য হলো AI-কে প্রতিটি ইন্টারঅ্যাকশনে একই রিপোজিটরি স্ন্যাপশট পুনরায় পড়া থেকে বিরত রাখা, যা ল্যাটেন্সি এবং খরচ উভয়ই কমায়।

পাল্টা যুক্তি: গতি এখনও গুরুত্বপূর্ণ

কিছু ডেভেলপার যুক্তি দেন যে একটি দ্রুততর মডেলের গুরুত্ব এখনও আছে কারণ এটি সেই ২৫% টোকেনের ল্যাটেন্সি কমিয়ে দেয় যা জেনারেট করা হচ্ছে। ল্যাটেন্সি-সংবেদনশীল পরিবেশে—যেমন IDE প্লাগইন যা তাৎক্ষণিক প্রতিক্রিয়া জানাতে হয়—প্রতিটি মিলিসেকেন্ড গুরুত্বপূর্ণ। পড়ার প্রাধান্য থাকা সত্ত্বেও দ্রুততর মডেলের সুবিধা শেষ হয়ে যায় না; এটি কেবল এর আপেক্ষিক প্রভাব কমিয়ে দেয়।

পরবর্তীতে যা লক্ষ্য রাখা উচিত

Red Hat-এর গবেষণাটি সীমিত সংখ্যক সেশনের ওপর ভিত্তি করে করা হয়েছে, তাই আরও ব্যাপক নমুনা সংগ্রহ করলে অন্যান্য ভাষা বা প্রজেক্টের আকারের জন্য ভিন্ন টোকেন ডিস্ট্রিবিউশন দেখা যেতে পারে। যদি ভবিষ্যতের ডেটা ৭৫% পড়ার এই পরিসংখ্যানটি নিশ্চিত করে, তবে আমরা এমন টুলের দিকে একটি পরিবর্তন দেখতে পারি যা স্বয়ংক্রিয়ভাবে কনটেক্সট ছেঁটে ফেলে এবং ক্যাশ করে, অথবা এমনকি দ্রুত কনটেক্সট গ্রহণের জন্য টিউন করা মডেল আর্কিটেকচারের দিকেও যেতে পারি।

সারকথা: AI-সহায়তা প্রাপ্ত কোডিংয়ের জন্য, সবচেয়ে সস্তা পারফরম্যান্স বৃদ্ধি আসে মডেলকে কম তথ্য দেওয়ার মাধ্যমে, দ্রুত লেখার মাধ্যমে নয়। Red Hat-এর পরিসংখ্যান একটি স্পষ্ট যুক্তি দেয়: আপনার প্রম্পটগুলো ছেঁটে ফেলুন, ক্যাশ করুন এবং সারসংক্ষেপ করুন, তাহলেই আপনি সময় এবং অর্থ উভয় ক্ষেত্রেই দৃশ্যমান সাশ্রয় দেখতে পাবেন।