আপনি প্রম্পটে শত শত পৃষ্ঠার ডকুমেন্টেশন পেস্ট করলেন এবং একটি সাধারণ প্রশ্ন করলেন। উত্তরটি ভুল এলো। অথবা এটি উপরে দেওয়া ফরম্যাটিং নিয়মটি উপেক্ষা করল। আপনি তাকে সবকিছু দিয়েছেন। এটি কাজ করার কথা ছিল। কিন্তু তা হলো না।
এটিই হলো কনটেক্সট ট্র্যাপ (context trap)। বেশিরভাগ ডেভেলপার মনে করেন যে AI-কে বেশি তথ্য দিলে স্বয়ংক্রিয়ভাবে আরও ভালো ফলাফল পাওয়া যাবে। কিন্তু বাস্তবে প্রায়ই এর উল্টোটা ঘটে। নির্ভরযোগ্য AI অ্যাপ্লিকেশন তৈরির জন্য তিনটি মূল মেকানিক্স বোঝা প্রয়োজন: মডেলগুলো কীভাবে টেক্সট গণনা করে, তারা একসাথে কতটা তথ্য ধারণ করতে পারে এবং একটি কথোপকথন শেষ হওয়ার পর তথ্যের কী হয়।
টোকেন: প্রকৃত মুদ্রা
একটি টোকেন হলো ল্যাঙ্গুয়েজ মডেল প্রসেস করা ক্ষুদ্রতম একক। এটি একটি একক অক্ষর, একটি শব্দের অংশ বা একটি সম্পূর্ণ সাধারণ শব্দ হতে পারে। "purchase" শব্দটি প্রায়ই দুটি টোকেনে বিভক্ত হয়, যেখানে "cat"-এর মতো ছোট শব্দগুলো একটি টোকেন হিসেবেই থাকে। বিরামচিহ্ন এবং স্পেসও টোকেন খরচ করে। কোড বিশেষ করে বেশি টোকেন ব্যবহার করে। নেস্টেড ইনডেন্টেশন এবং বিশেষ ক্যারেক্টারযুক্ত একটি Python কোড ব্লকের টোকেন সংখ্যা আপনার অনুমানের চেয়ে তিন বা চার গুণ বেশি হতে পারে।
নির্মাতাদের কেন এটি নিয়ে ভাবা উচিত? API-এর মূল্য নির্ধারণ করা হয় প্রতি টোকেনের ভিত্তিতে। প্রসেসিং টাইমও একইভাবে কাজ করে। একটি প্রম্পট যা দেখতে দুই পৃষ্ঠার টেক্সটের মতো মনে হয়, তার ভেতরে কী আছে তার ওপর ভিত্তি করে তার খরচ কয়েক পয়সা বা কয়েক ডলার হতে পারে। আরও খারাপ বিষয় হলো, বিনিময়ের উভয় দিকেই টোকেন যোগ হয়। আপনি আপনার প্রম্পটের প্রতিটি টোকেনের জন্য অর্থ প্রদান করেন এবং মডেল যে প্রতিটি টোকেন জেনারেট করে তার জন্যও আপনাকে অর্থ দিতে হয়। অনিয়ন্ত্রিত কনটেক্সট বৃদ্ধি নীরবে আপনার লাভের মার্জিন কমিয়ে দেয়।
কনটেক্সট উইন্ডো হলো একটি হোয়াইটবোর্ড
কনটেক্সট উইন্ডো নির্ধারণ করে যে একটি মডেল একবারে সর্বোচ্চ কতটুকু দেখতে পারে। একটি ছোট ঘরে ঝুলানো একটি হোয়াইটবোর্ডের কথা কল্পনা করুন। আপনি এটি সিস্টেম ইনস্ট্রাকশন, ব্যবহারকারীর প্রশ্ন, রিট্রিভ করা ডকুমেন্ট এবং পূর্ববর্তী কথোপকথন দিয়ে পূর্ণ করতে পারেন। কিন্তু বোর্ডটি কখনোই বড় হয় না। যখন নতুন টেক্সট আসে, পুরনো টেক্সট বোর্ডের প্রান্ত দিয়ে হারিয়ে যায়।
এটি গুরুত্বপূর্ণ কারণ মডেলগুলো যখন কন্টেন্ট বাদ দিতে শুরু করে তখন তারা আপনাকে সতর্ক করে না। যদি আপনার সিস্টেম ইনস্ট্রাকশন একটি দীর্ঘ কথোপকথনের একদম উপরে থাকে এবং আপনি ক্রমাগত মেসেজ যোগ করতে থাকেন, তবে সেই ইনস্ট্রাকশনটি একসময় ভিউ থেকে হারিয়ে যাবে। মডেলটি তার ডিফল্ট আচরণে ফিরে যেতে পারে, আপনার ফরম্যাটিং নিয়ম উপেক্ষা করতে পারে বা পূর্ববর্তী নির্দেশনার বিপরীত কাজ করতে পারে। বিভিন্ন মডেলের লিমিট ভিন্ন ভিন্ন হয়—কিছু কয়েক হাজার টোকেন হ্যান্ডেল করতে পারে আবার কিছু কয়েক লক্ষ টোকেন হ্যান্ডেল করতে পারে, কিন্তু মেকানিক্স একই থাকে। ইনপুট এবং আউটপুট একই বাজেট শেয়ার করে। একটি মডেল যদি দুই হাজার টোকেনের একটি রেসপন্স জেনারেট করে, তবে আপনি তাকে যা বলেছিলেন তা মনে রাখার জন্য তার কাছে দুই হাজার টোকেন কম অবশিষ্ট থাকে।
মেমরি হলো একটি হ্যাক, কোনো ফিচার নয়
ইনফারেন্সের (inference) সময় মডেল ওয়েটসের (model weights) ভেতরে কোনো স্থায়ী মেমরি থাকে না। একদমই না। আপনি যখন ট্যাবটি বন্ধ করে কাল ফিরে আসবেন, মডেল আপনাকে চিনতে পারবে না। প্রতিটি API কল একটি কোল্ড স্টার্ট (cold start)।
যা মেমরির মতো মনে হয় তা আসলে অ্যাপ্লিকেশন লেয়ারের একটি চতুর বুককিপিং মাত্র। ফ্রন্টএন্ড আপনার মেসেজগুলো একটি ডাটাবেসে সংরক্ষণ করে। যখন আপনি একটি নতুন কুয়েরি পাঠান, সফটওয়্যারটি প্রাসঙ্গিক ইতিহাস সংগ্রহ করে, সেটিকে একটি নতুন প্রম্পটে যুক্ত করে এবং পুরো প্যাকেজটি মডেলের কাছে পাঠিয়ে দেয়। মডেলটি নিজে এ বিষয়ে কিছুই জানে না।
প্রোডাক্ট টিমের জন্য এই পার্থক্যটি বোঝা অত্যন্ত জরুরি। আপনি যদি ব্যবহারকারীর পছন্দ "মনে রাখার" জন্য মডেলের ওপর নির্ভর করেন, তবে আপনি বালির ওপর ভিত্তি করে কিছু তৈরি করছেন। আপনাকে নিজেই স্টেট ম্যানেজমেন্ট (state management) তৈরি করতে হবে। কী ক্যাশ (cache) করতে হবে তা ঠিক করুন। কীভাবে এটি রিফ্রেশ করতে হবে তা ঠিক করুন। এবং এটি মনে রাখুন যে আপনি যে প্রতিটি বাইট ইতিহাস পুনরায় পাঠান, তা আপনার হোয়াইটবোর্ডের জায়গা দখল করে নেয়।
যখন কনটেক্সট নয়েজে পরিণত হয়
প্রম্পটকে অতিরিক্ত তথ্যে ভরিয়ে দেওয়াটি প্রত্যাশিতভাবেই উল্টো ফল দেয়।
নয়েজ সিগন্যালকে নষ্ট করে দেয়। আপনি যদি একটি বাগ সম্পর্কে জানতে পুরো একটি কোডবেস দিয়ে দেন, তবে মডেলটি 'নিডল-ইন-এ-হেস্ট্যাক' (needle-in-a-haystack) সমস্যার সম্মুখীন হয়। এটি ভুল ফাইল রেফার করতে পারে, ডেড কোডে (dead code) পরিবর্তনের পরামর্শ দিতে পারে, অথবা একটি সাধারণ উত্তর দিতে পারে কারণ এটি পারে না