AI বিষয়ক আলোচনায় একটি অনুপস্থিত অংশ
সবাই এখন AI এজেন্ট নিয়ে কথা বলছে। যেকোনো টেক ফিড স্ক্রল করলেই আপনি এমন ডেমো দেখতে পাবেন যেখানে একটি লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) একটি মাত্র চমৎকার কথোপকথনের মাধ্যমে ফ্লাইট বুক করছে, কোড লিখছে বা সাপোর্ট টিকিটের উত্তর দিচ্ছে। এর অন্তর্নিহিত বার্তাটি স্পষ্ট বলে মনে হয়: আপনি যদি একজন ব্যবহারকারীকে একটি LLM-এর সাথে যুক্ত করতে পারেন, তবে জাদু ঘটে।
এই বিভ্রমটি পাঁচ মিনিটের একটি ডেমোর জন্য চমৎকারভাবে কাজ করে। কিন্তু যখন প্রকৃত ব্যবহারকারী, প্রকৃত ডেটা এবং প্রকৃত অর্থের বিষয়টি সামনে আসে, তখনই এটি ভেঙে পড়ে। প্রোডাকশন লেভেলে সম্পর্কটি কখনোই কেবল User ↔ LLM নয়। এটি হলো User ↔ একটি জটিল সিস্টেম যার মধ্যে একটি LLM অন্তর্ভুক্ত রয়েছে। সেই সিস্টেমের যে অংশটি নিয়ে কেউ কথা বলে না তা হলো হারনেস (harness)—সেই কাঠামো যা মডেলের চারপাশের সবকিছু নির্বাচন, রুট, সুরক্ষা এবং সমন্বয় (orchestrate) করে। এটি ছাড়া আপনার কাছে কোনো পণ্য নেই; আপনার কাছে আছে কেবল একটি প্রোটোটাইপ।
কেন সাধারণ লুপটি ভেঙে পড়ে
একটি ডেমো হলো একটি নিয়ন্ত্রিত পরিবেশ। সেখানে কুয়েরিগুলো ছোট হয়, কনটেক্সট সীমিত থাকে এবং ঝুঁকিও কম থাকে। ডেভেলপার একটি মাত্র API কল করেন, একটি সাবলীল রেসপন্স পান এবং দর্শক তালি দেয়। কিন্তু প্রোডাকশন অত্যন্ত জটিল। ব্যবহারকারীরা অস্পষ্ট ফলো-আপ প্রশ্ন করতে পারেন। থার্ড-পার্টি API টাইম-আউট হতে পারে। যে মডেলটি গতকাল নিখুঁত JSON তৈরি করেছিল, সেটি হঠাৎ করে markdown spit করতে পারে। কনটেক্সট উইন্ডো পূর্ণ হয়ে যেতে পারে। সবচেয়ে খারাপ মুহূর্তে রেট লিমিট কার্যকর হতে পারে।
একটি সাধারণ প্রম্পট-রেসপন্স লুপের কাছে এগুলোর কোনো সমাধান নেই। এটি জানে না কোন মডেল ভ্যারিয়েন্ট একটি নির্দিষ্ট কাজ সম্পন্ন করতে সক্ষম। এটি মনে রাখতে পারে না যে তিন ধাপ আগে কী ঘটেছিল। এটি একটি ব্যর্থ কল পুনরায় চেষ্টা করতে পারে না, খরচ বেড়ে গেলে রিকোয়েস্টের গতি কমিয়ে আনতে পারে না, অথবা আপনার ডেটাবেসে পৌঁছানোর আগে আউটপুট স্যানিটাইজ করতে পারে না। এগুলো কোনো ব্যতিক্রমী ঘটনা (edge cases) নয়; এগুলো বাস্তব জগতের সফটওয়্যারের প্রধান বৈশিষ্ট্য। এগুলো সামলানোই হলো হারনেসের কাজ।
হারনেস আসলে কী করে
হারনেসকে এমন একটি ইঞ্জিনিয়ারিং লেয়ার হিসেবে ভাবুন যা একটি ল্যাঙ্গুয়েজ মডেলকে কেবল একটি চতুর টেক্সট জেনারেটর থেকে একটি নির্ভরযোগ্য সার্ভিস কম্পোনেন্টে রূপান্তরিত করে। এর দায়িত্বগুলো অত্যন্ত সুনির্দিষ্ট এবং খুব একটা চাকচিক্যময় নয়, আর ঠিক এই কারণেই এগুলোকে প্রায়ই উপেক্ষা করা হয়।
প্রাসঙ্গিক কাজের জন্য মডেল নির্বাচন। প্রতিটি ইন্টারঅ্যাকশনের জন্য সবসময় সবচেয়ে শক্তিশালী ফাউন্ডেশন মডেলের প্রয়োজন হয় না। কিছু কাজের জন্য প্রয়োজন বিশুদ্ধ যুক্তি প্রদানের ক্ষমতা; আবার কিছু কাজের জন্য প্রয়োজন কেবল গতি এবং স্বল্প খরচ। একটি সুগঠিত হারনেস বুদ্ধিমত্তার সাথে রিকোয়েস্ট রুট করে। উদাহরণস্বরূপ, একটি কাস্টমার সাপোর্ট এজেন্ট একটি দ্রুত ও সাশ্রয়ী মডেল ব্যবহার করতে পারে ইনকামিং মেসেজের ইনটেন্ট (উদ্দেশ্য) ক্লাসিফাই করার জন্য—যেমন এটি কি রিফান্ড রিকোয়েস্ট নাকি শিপিং সংক্রান্ত প্রশ্ন। যদি ইনটেন্ট কোনো জটিল পলিসি সংক্রান্ত বিবাদের ইঙ্গিত দেয়, তবে হারনেস কাজটি একটি শক্তিশালী রিজনিং মডেলে পাঠিয়ে দেয় (escalate করে)। আর ব্যবহারকারী যদি কেবল একটি ট্র্যাকিং লিঙ্ক চায়, তবে হালকা মডেলটি তাৎক্ষণিকভাবে উত্তর দিয়ে দেয় এবং আপনার খরচ নিয়ন্ত্রণে থাকে।
ডেটা প্রবাহ পরিচালনা করা। বাস্তব অ্যাপ্লিকেশনগুলো শূন্যে কাজ করে না। একটি AI এজেন্টের প্রায়ই একটি ভেক্টর স্টোর থেকে ডকুমেন্ট সংগ্রহ করা, একটি CRM কুয়েরি করা, সাম্প্রতিক ব্যবহারকারীর কার্যক্রম পড়া এবং তারপর সেই সবগুলোকে একটি সুসংগত রেসপন্সে রূপান্তর করার প্রয়োজন হয়। হারনেস সেই ইনজেশন (ingestion) প্রক্রিয়াটি পরিচালনা করে। এটি সঠিক কনটেক্সট চাঙ্কস সংগ্রহ করে, সেগুলো প্রাসঙ্গিকতা না হারিয়ে টোকেন লিমিটের মধ্যে আছে কি না তা যাচাই করে, মডেলের জন্য সেগুলোকে সাজায় এবং প্রাপ্ত আউটপুটটি চেইনের পরবর্তী সিস্টেমের কাছে পাঠিয়ে দেয়। এই অর্কেস্ট্রেশন ছাড়া মডেলটি হয় কনটেক্সটের অভাবে পড়ে যায় অথবা অপ্রাসঙ্গিক তথ্যের ভিড়ে হারিয়ে যায়।
ত্রুটি বা এরর ম্যানেজ করা। LLM এমনভাবে ব্যর্থ হয় যা প্রথাগত সার্ভিসগুলোর ক্ষেত্রে ঘটে না। তারা স্ট্রাকচার্ড আউটপুট হ্যালুসিনেশন করতে পারে। তারা খালি কমপ্লিশন প্রদান করতে পারে। এমনকি মডেলের ভার্সন সামান্য পরিবর্তন হলেই তারা ফরম্যাটিং নির্দেশাবলী লঙ্ঘন করতে পারে। হারনেস এই ব্যর্থতাগুলোকে কোনো বিস্ময় হিসেবে না দেখে বরং একটি প্রত্যাশিত আচরণ হিসেবে বিবেচনা করে। এটি স্কিমা ভ্যালিডেট করে, ভুল ফরম্যাটের রেসপন্স শনাক্ত করে, এক্সপোনেনশিয়াল ব্যাকঅফ (exponential backoff) সহ রিট্রাই লজিক প্রয়োগ করে এবং প্রাইমারি এন্ডপয়েন্ট কাজ না করলে একটি সেকেন্ডারি প্রোভাইডার বা ক্যাশ করা রেজাল্টের সাহায্য নেয়। যখন আর কোনো উপায় থাকে না, তখন এটি একজন হিউম্যান অপারেটরের কাছে বিষয়টি পাঠিয়ে দেয়, যাতে একজন অর্থ প্রদানকারী গ্রাহককে অর্থহীন উত্তর না দিতে হয়।
সিস্টেমের নির্ভরযোগ্যতা নিশ্চিত করা। প্রোডাকশন মানেই হলো সমসাময়িক ব্যবহারকারী (concurrent users), খরচের সীমা (cost caps) এবং অননুমেয় ল্যাটেন্সি (latency)। হারনেস রেট লিমিট প্রয়োগ করে, কানেকশন পুলিং পরিচালনা করে এবং সার্কিট ব্রেকার (circuit breakers) কার্যকর করে, যাতে কোনো একটি ধীরগতির মডেল প্রোভাইডার আপনার পুরো অ্যাপ্লিকেশনটিকে অচল করে না দেয়। এটি প্রতিটি ইন্টারঅ্যাকশন লগ করে যাতে আপনি ট্র্যাক করতে পারেন কেন একটি নির্দিষ্ট সেশন বিচ্যুত হয়েছে, এবং এটি আপনার প্রম্পটগুলোর ভার্সন বজায় রাখে যাতে কোনো ডিপ্লয়মেন্ট ভুলবশত অডিট ট্রেইল ছাড়াই আপনার এজেন্টের ব্যক্তিত্ব পরিবর্তন করে না দেয়।
একই মডেল, সম্পূর্ণ ভিন্ন ফলাফল
এটি এমন একটি ঘটনা ব্যাখ্যা করে যা অনেক প্রোডাক্ট টিমকে বিভ্রান্ত করে। দুটি কোম্পানি একই ফাউন্ডেশন মডেল দিয়ে শুরু করতে পারে—একই weights, একই context window, একই training cutoff—এবং এমন অভিজ্ঞতা প্রদান করতে পারে যা সম্পূর্ণ আলাদা। একটি মনে হয় ভঙ্গুর, ধীর এবং অদ্ভুতভাবে বিস্মৃতিপ্রবণ। অন্যটি মনে হয় দ্রুত, সামঞ্জস্যপূর্ণ এবং নির্ভরযোগ্য।
পার্থক্যটি কখনোই মডেলটির নয়। এটি হলো মডেলটির চারপাশে তৈরি করা সিস্টেম। একটি টিম মডেলটিকে পুরো প্রোডাক্ট হিসেবে বিবেচনা করেছে। অন্যটি এটিকে একটি সুশৃঙ্খল আর্কিটেকচারের (architecture) একটি অংশ হিসেবে বিবেচনা করেছে। এই শৃঙ্খলা বা ডিসিপ্লিনটি মূলত 'harness'-এর মধ্যেই থাকে।
প্রম্পট থেকে আর্কিটেকচারের দিকে পরিবর্তন
শুরুর দিকে AI ডেভেলপমেন্টে প্রম্পট ইঞ্জিনিয়ারিংকে (prompt engineering) কেন্দ্রবিন্দুতে রাখা হয়েছিল। শব্দের পরিবর্তন, উদাহরণ যোগ করা এবং রোল-প্লে ইন্সট্রাকশন ব্যবহারের মাধ্যমে আউটপুটের মান নাটকীয়ভাবে উন্নত করা সম্ভব ছিল। সেই দক্ষতা এখনও গুরুত্বপূর্ণ, তবে একটি প্রতিযোগিতামূলক সুবিধা (competitive moat) হিসেবে এর কার্যকারিতা এখন কমে আসছে। একটি অনুপস্থিত retry policy বা একটি জটিল ডেটা পাইপলাইন যা পাবলিক রেসপন্সে প্রাইভেট কনটেক্সট ফাঁস করে দেয়, তা কেবল প্রম্পট দিয়ে সমাধান করা সম্ভব নয়।
বর্তমানে যে আসল পরিবর্তনটি ঘটছে তা হলো সফটওয়্যার আর্কিটেকচারের (software architecture) দিকে যাত্রা। ইঞ্জিনিয়াররা এখন state machine ডিজাইন করছেন, মডেল লেয়ার এবং অ্যাপ্লিকেশন লজিকের মধ্যে কঠোর ইন্টারফেস (interface) নির্ধারণ করছেন এবং non-determinism-কে একটি প্রধান ইঞ্জিনিয়ারিং সমস্যা হিসেবে বিবেচনা করছেন। তারা ডিস্ট্রিবিউটেড সিস্টেমের (distributed systems) প্রশ্নগুলো করছেন: একটি মাল্টি-টার্ন কনভারসেশনের মাধ্যমে স্টেট (state) কীভাবে বজায় থাকে? যদি কোনো ডাউনস্ট্রিম টুল অনুপলব্ধ থাকে তবে কী হবে? একটি সিস্টেমের মূল উপাদান যদি প্রোবাবিলিস্টিক (probabilistic) হয়, তবে আমরা কীভাবে সেটি টেস্ট করব? এই প্রশ্নগুলোই একটি খেলনা এবং একটি আসল টুলের মধ্যে পার্থক্য তৈরি করে।
প্রোডাকশনের জন্য তৈরি করা: Observability এবং Control
আপনি যদি প্রোডাকশনে কিছু লঞ্চ করার ব্যাপারে সিরিয়াস হন, তবে harness-এর দুটি গুণ থাকা সবচেয়ে জরুরি: observability এবং orchestration।
Observability মানে হলো মডেলটি কী গ্রহণ করেছে, কী প্রদান করেছে এবং প্রতিটি ধাপে কত সময় লেগেছে তা দেখতে পারা। এর মানে হলো চৌদ্দটি টুল কলের মাধ্যমে একজন এজেন্টের ডিসিশন লুপ (decision loop) ট্র্যাক করা এবং ঠিক কোথায় সেটি লুপে আটকে যাচ্ছে বা লক্ষ্য থেকে বিচ্যুত হচ্ছে তা শনাক্ত করা। এই ভিজিবিলিটি ছাড়া একটি AI সিস্টেম ডিবাগ করা অনেকটা অন্ধকারে গাড়ির ইঞ্জিন ঠিক করার মতো।
Orchestration মানে হলো আপনার বিজনেস লজিক (business logic) মডেল ইন্টারঅ্যাকশন লেয়ার থেকে আলাদা থাকবে। এর মানে হলো কোডের মতো প্রম্পটকেও ভার্সনিং (versioning) করা, যাতে নতুন কোনো ডিপ্লয়মেন্ট নিঃশব্দে সিস্টেমের আচরণ পরিবর্তন না করে। এর মানে হলো পরিকল্পিতভাবে ফেইলর মোড (failure modes) টেস্ট করা—যেমন রিকোয়েস্ট চলাকালীন একটি API বন্ধ করে দেওয়া, ভুল টুল রেজাল্ট দেওয়া, বা context window overflow সিমুলেট করা—যাতে দেখা যায় harness সিস্টেমটিকে স্থিতিশীল রাখতে পারে কি না। ফ্রেমওয়ার্ক আসে এবং যায়, আপনি রেডিমেড orchestration লাইব্রেরি ব্যবহার করুন বা নিজের তৈরি করুন, ব্র্যান্ড নামের চেয়ে ডিসিপ্লিন বা শৃঙ্খলা বেশি গুরুত্বপূর্ণ।
আসল শিক্ষা
ফাউন্ডেশন মডেলগুলো ক্রমাগত উন্নত হতে থাকবে। সেগুলো আরও দ্রুত, সস্তা এবং আরও সক্ষম হবে। কিন্তু একটি শক্তিশালী ইঞ্জিন একটি ভাঙা চ্যাসিসকে (chassis) ঠিক করতে পারে না। আগামী কয়েক বছরে যারা জিতবে তারা সবচেয়ে উন্নত মডেল ব্যবহারের সুযোগ পাবে না; বরং তারা হবে সেই সব টিম যারা একটি নির্ভরযোগ্য, observable এবং সুসংগঠিত (well-orchestrated) harness তৈরি করতে পেরেছে। তারা অ্যাপ্লিকেশন নতুন করে না লিখে সহজেই মডেল পরিবর্তন করতে পারবে। তারা খরচ নিয়ন্ত্রণ করতে পারবে কারণ harness প্রতিটি টোকেন (token) নিয়ন্ত্রণ করে। তারা নিশ্চিন্তে ঘুমাতে পারবে কারণ তাদের সিস্টেমগুলো সুন্দরভাবে ত্রুটি মোকাবিলা (fail gracefully) করতে পারে।
শুধু মডেল নিয়ে পড়ে না থেকে, সেটি চালানোর সিস্টেমটি নিয়ে কাজ শুরু করুন। ভবিষ্যৎ তাদেরই যারা স্মার্ট মডেলের চারপাশে স্মার্ট সিস্টেম তৈরি করতে জানে।
এই নিবন্ধটি মূলত Abdulaziz Zos-এর "Beyond The Model" আলোচনায় আলোচিত ধারণাগুলোর ওপর ভিত্তি করে লেখা।
AI ইঞ্জিনিয়ারিং এবং সিস্টেম ডিজাইন নিয়ে আরও আলোচনার জন্য, GyaanSetu learning community দেখুন।