আপনার এজেন্টিক সিস্টেমে সিদ্ধান্ত কীভাবে এবং কোথায় নেওয়া হয়, তা সতর্কভাবে বিবেচনা করা গুরুত্বপূর্ণ.
আরও বেশি সিদ্ধান্ত LLM-এর ওপর ছেড়ে দিলে সিস্টেমটি সম্ভাব্যভাবে আরও বেশি ধরনের কাজ সামলাতে পারে, তবে এতে গতি, নির্ভরযোগ্যতা ও দৃঢ়তার সম্ভাব্য ক্ষতি হতে পারে.
যেখানে সম্ভব, সিদ্ধান্ত গ্রহণের প্রক্রিয়ার যতটা সম্ভব অংশ LLM থেকে স্পষ্ট সফটওয়্যার কোডে সরিয়ে নেওয়ার চেষ্টা করুন. উচ্চ-ঝুঁকির এবং/অথবা প্রোডাকশন ওয়ার্কফ্লোর ক্ষেত্রে এটি বিশেষভাবে সত্য.
LLM-ভিত্তিক এজেন্টিক সিস্টেম ডিজাইন করার সময় আপনাকে নেওয়া সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্তগুলোর একটি হলো সিদ্ধান্ত গ্রহণের কতটা অংশ LLM মডেলের ভেতরে থাকবে আর কতটা স্পষ্ট সফটওয়্যারে থাকবে.
বোঝার সুবিধার জন্য, এই পছন্দটিকে আমরা নিচের পদ্ধতিগুলোর মাঝামাঝি একটি বর্ণালী হিসেবে ভাবতে পারি:
রাউটার-ভিত্তিক আর্কিটেকচার কোডে ক্রম ও লজিক স্পষ্টভাবে নির্ধারণ করে, ফলে সীমিত ডোমেইনের কাজের জন্য পরীক্ষাযোগ্যতা, পূর্বানুমানযোগ্যতা ও দৃঢ়তা নিশ্চিত হয় (এগুলোকে ‘ওয়ার্কফ্লো এজেন্ট’ও বলা হয়).
অর্কেস্ট্রেটর এজেন্ট স্বাভাবিক ভাষার প্রম্পট ব্যবহার করে কাজের প্রবাহ গতিশীলভাবে নির্ধারণ করতে বড় ভাষা মডেল (LLM)-এর ওপর নির্ভর করে; যেখানে পূর্বনির্ধারিত লজিক যথেষ্ট নয় বা সম্ভব নয়, সেই উন্মুক্ত মিথস্ক্রিয়ার জন্য এটি আদর্শ.
উচ্চ-ঝুঁকির প্রোডাকশন ওয়ার্কফ্লোর জন্য আমরা সাধারণত বেশি রাউটার-ভিত্তিক বৈশিষ্ট্য ব্যবহারের পরামর্শ দিই, আর নমনীয়, সাধারণ-উদ্দেশ্যের কথোপকথন দরকার এমন অ্যাপ্লিকেশনের জন্য অর্কেস্ট্রেটর রাখি.
রাউটার-ভিত্তিক আর্কিটেকচার
রাউটার এজেন্টিক সিস্টেম:
কোড/সফটওয়্যারের মাধ্যমে সিদ্ধান্ত গ্রহণের প্রবাহ স্পষ্টভাবে নির্ধারণ করে এবং এই সফটওয়্যার কোন রুট নেবে তা নির্ধারণে LLM ব্যবহার করে.
এগুলো ঐতিহ্যগত সফটওয়্যার সিস্টেমের কাছাকাছি, কারণ এগুলোর পথগুলো পরিষ্কার ও পূর্বানুমানযোগ্য, যা আরও সামঞ্জস্যপূর্ণ ফল দেয়.
যেসব কাজ কঠোরভাবে সংজ্ঞায়িত করা যায়, সেগুলোর জন্য আদর্শ.
নিচে ‘রাউটার পদ্ধতি’ ব্যবহার করা একটি এয়ারলাইন চ্যাটবট বুকিং এজেন্টের সরল উদাহরণ দেওয়া হলো. এখানে দেখা যায়, LLM আমাদের প্রশ্নের উদ্দেশ্য তিনটি সম্ভাব্য পছন্দের মধ্যে শ্রেণিবদ্ধ করতে সাহায্য করলেও শেষ পর্যন্ত আমাদের সফটওয়্যারই সেই উদ্দেশ্যকে একটি টেমপ্লেট টেক্সট উত্তরে ম্যাপ করে. LLM খুব সীমাবদ্ধ থাকায় ব্যবহারকারী আরও সামঞ্জস্যপূর্ণ আচরণ অনুভব করবেন.
অর্কেস্ট্রেটর আর্কিটেকচার
রাউটার সিস্টেমের বিপরীতে, অর্কেস্ট্রেটর এজেন্টিক সিস্টেম:
সফটওয়্যারের বদলে স্বাভাবিক ভাষার প্রম্পটের মাধ্যমে লজিক ফ্লো নির্ধারণ করে. নোট: প্রোগ্রামিং ভাষার তুলনায় স্বাভাবিক ভাষা প্রকৃতিগতভাবেই অস্পষ্ট ও নমনীয় (এটি ইতিবাচক ও নেতিবাচক—দুই ধরনের বৈশিষ্ট্যই, যা পরে আলোচনা করব). আমরা একে ‘নির্দেশ নয়, উদ্দেশ্য’ হিসেবে ভাবি.
একাধিক প্রসেসিং বিকল্প দিতে পারে, যেখানে LLM কার্যকর করার ক্রম ও পদ্ধতি নির্ধারণ করে.
সফটওয়্যারে স্পষ্টভাবে সংজ্ঞায়িত করা কঠিন এমন নতুন লজিক পথ গতিশীলভাবে তৈরি করতে পারে.
এই অস্পষ্টতা অসামঞ্জস্যপূর্ণ আউটপুট তৈরি করতে পারে, কিন্তু যখন এটি কাজ করে, তখন তা ‘জাদুকরী’ মনে হতে পারে.
নিচের উদাহরণে একই সরল এয়ারলাইন সমস্যায় অর্কেস্ট্রেটর পদ্ধতি প্রয়োগ করা হয়েছে. কোন উত্তর উপযুক্ত তা সফটওয়্যারকে ঠিক করতে দেওয়ার বদলে সিদ্ধান্ত গ্রহণ LLM স্তরের ওপর ন্যস্ত করা হয়. এখানে আমাদের একটি মাল্টি-এজেন্ট সিস্টেম আছে, যেখানে একটি ‘প্রধান’ অর্কেস্ট্রেটর এজেন্ট ব্যবহারকারীর প্রশ্ন বাছাই করে এবং ফ্লাইট পরিবর্তনের জন্য বিশেষভাবে তৈরি একটি এজেন্টের কাছে হ্যান্ড অফ করে; শেষ পর্যন্ত সেটিই ব্যবহারকারীকে উত্তর দেয়.
এই উদাহরণে LLM স্তরটি শ্রেণিবিন্যাসকারী, রাউটার এবং উত্তর লেখকের ভূমিকা পালন করছে. রাউটার উদাহরণে এটি শুধু শ্রেণিবিন্যাসকারীর ভূমিকা পালন করেছিল (বাকি অংশ সফটওয়্যার সামলেছিল).
যেখানে সম্ভব, আমরা রাউটার-ভিত্তিক পদ্ধতি ব্যবহারের পরামর্শ দিই, কারণ এগুলো নিচের সুবিধা দেয়:
গতি ও দক্ষতা: বাহ্যিক API-নির্ভর অর্কেস্ট্রেটরের তুলনায় লোকাল কম্পিউটেশন বেশি দ্রুত. আপনার ‘IF/ELSE’ লজিক Python-এ প্রসেস করা অনেক সস্তা; সেটিকে কোনো LLM প্রোভাইডারের ৪০০ বিলিয়ন প্যারামিটারের মডেলের মাধ্যমে পাঠানোর খরচ দিতে হয় না.
পরীক্ষাযোগ্যতা ও পূর্বানুমানযোগ্যতা: প্রতিষ্ঠিত সফটওয়্যার পদ্ধতির মাধ্যমে ডিবাগ, পরীক্ষা ও রক্ষণাবেক্ষণ করা অনেক সহজ.
স্বচ্ছতা ও নির্ভরযোগ্যতা: আচরণের কম ভিন্নতা সমস্যা সমাধান সহজ করে. অ্যাপ্লিকেশন ফ্লোর আরও বড় অংশও স্বচ্ছ, ভার্সন-কন্ট্রোলড সফটওয়্যারে প্রকাশিত থাকে; LLM-এর অস্বচ্ছ, ব্যাখ্যাতীত ওজনের ওপর নয়.
রাউটার পদ্ধতির অসুবিধা হলো এগুলো কঠোর ও অনমনীয় হতে পারে এবং বেশি উন্মুক্ত সমস্যায় হিমশিম খেতে পারে. যে চ্যাটবট সব সময় একই উত্তর দেয়, ব্যবহারকারীরা সেটিকে বিরক্তিকর বা স্থবির মনে করতে পারেন.
অর্কেস্ট্রেটর ডিজাইনের শক্তিশালী সক্ষমতা আছে:
পরিকল্পনা: এগুলো গতিশীলভাবে উত্তর পরিকল্পনা করতে পারে.
টুল নির্বাচন/এজেন্ট হ্যান্ড-অফ: উপযুক্ত টুল নির্বাচন করে বা এজেন্টদের কাছে কাজ অর্পণ করে.
আউটপুটের পুনরাবৃত্তিমূলক সমন্বয়: সৃজনশীলভাবে আউটপুট পুনরাবৃত্তি ও পুনঃসমন্বয় করে.
সমাপ্তি নির্ধারণ: উত্তর চূড়ান্ত করার জন্য যথেষ্ট তথ্য সংগ্রহ হয়েছে কি না নির্ধারণ করে.
Pydantic-AI বা OpenAI-এর Agents SDK-এর মতো ফ্রেমওয়ার্ক ব্যবহার করলে অর্কেস্ট্রেশন বাস্তবায়ন সহজ ও দ্রুত হয়. এ কারণে এটি ডেমো বা প্রুফ অব কনসেপ্টের জন্য দারুণ.
এই পদ্ধতির অসুবিধাগুলো হলো:
LLM-এর পরিকল্পনা ধাপ এবং পরবর্তী কাজগুলো সঠিক/উপযুক্ত হবে, এমন কোনো নিশ্চয়তা নেই. রাউটার সিস্টেমেও একই সমস্যা আছে, তবে এটি বেশি সীমাবদ্ধ হওয়ায় এর আচরণ বেশি পূর্বানুমানযোগ্য.
সহজ, সুস্পষ্টভাবে সংজ্ঞায়িত কাজের জন্য সম্ভবত আমাদের মাল্টি-এজেন্ট সিস্টেমের পূর্ণ সক্ষমতা দরকার হয় না. উদাহরণস্বরূপ, আমাদের এয়ারলাইন এজেন্ট উদাহরণে, এয়ারলাইন সাপোর্ট সিস্টেমের সঙ্গে যোগাযোগকারী কেউ বাস্তবে যে ধরনের কাজ করতে চান, সেগুলোর সংখ্যা সম্ভবত সীমিত.
LLM-এর ভেতরে বেশি লজিক থাকায় খারাপ উদ্দেশ্যের লোকদের নিরাপত্তা এড়ানোর কৌশল বা এক্সপ্লয়েটের প্রতি এটি অনেক বেশি ঝুঁকিপূর্ণ.
এটি সিদ্ধান্ত গ্রহণকে LLM-এর ভেতরে বিমূর্ত করে রাখে, ফলে আপনার সিস্টেম বোঝা কঠিন হয় (যদিও Langfuse বা Braintrust-এর মতো মনিটরিং টুল এতে আংশিক সাহায্য করতে পারে).
পাঠকের জন্য নোট: মডেলের সক্ষমতা দ্রুত বদলালেও, নিচের বিষয়গুলো নিকট ভবিষ্যতে বদলানোর সম্ভাবনা কম.
আপনার সমস্যার পরিসর নির্ধারণ করুন.
আপনি কি সহজে একটি ডায়াগ্রামে আপনার কাঙ্ক্ষিত সিদ্ধান্ত লজিক দেখাতে পারেন?
আপনার অ্যাপ্লিকেশনে ব্যর্থতা বা অপ্রত্যাশিত আচরণ কি আপনি মেনে নিতে পারেন না?
উপরের যেকোনো একটির উত্তর ‘হ্যাঁ’ হলে বোঝায় রাউটার বৈশিষ্ট্যই ভালো হবে.
যেখানে সম্ভব, আমরা যতক্ষণ কাজ চালানো যায় রাউটার পদ্ধতি ব্যবহারের পরামর্শ দিই; সাধারণ নীতি হিসেবে, আপনার সিস্টেমের কোনো অংশ কোডে প্রকাশ করা গেলে সেটি কোডেই প্রকাশ করুন (অর্থাৎ দরকার না হলে LLM অতিরিক্ত ব্যবহার করবেন না).
যেখানে এগুলোর সীমায় পৌঁছে যায়, সেখানে উন্মুক্ত অর্কেস্ট্রেটর সুবিধাগুলোর কিছু অংশ সীমাবদ্ধভাবে পুনরুত্পাদন করা যায়. যেমন:
টুল নির্বাচন/এজেন্ট হ্যান্ড-অফ: কন্ডিশনাল ব্রাঞ্চিং বা LLM শ্রেণিবিন্যাসকারীর মাধ্যমে সহজে বাস্তবায়ন করা যায়.
সমাপ্তি নির্ধারণ: সরল LLM শ্রেণিবিন্যাসকারী ব্যবহারকারীকে উত্তর দেওয়ার আগে সেটি সম্পূর্ণ কি না যাচাই করতে পারে.
তবে ‘পরিকল্পনা’ এবং ‘আউটপুটের পুনরাবৃত্তিমূলক সমন্বয়’ কঠোর রাউটার সিস্টেমে অর্জন করা নিঃসন্দেহে অনেক কঠিন. তাই কোনো কাজের জন্য এগুলো দরকার হলে (LLM শ্রেণিবিন্যাসকারী বা অন্য কোনো লজিক দিয়ে নির্ধারিত), আমরা আপনার সিস্টেমে তুলনামূলকভাবে কম সীমাবদ্ধ একটি অর্কেস্ট্রেটর ব্রাঞ্চ তৈরি করার পরামর্শ দিই.
রাউটার ও অর্কেস্ট্রেটর আর্কিটেকচারের মধ্যে আপনার পছন্দটি আপনার অ্যাপ্লিকেশনের স্পষ্টতা, জটিলতা ও মিথস্ক্রিয়ার ধরনকে প্রতিফলিত করা উচিত. রাউটার-ভিত্তিক পদ্ধতি বর্তমানে স্পষ্টভাবে সংজ্ঞায়িত কাজের জন্য নির্ভরযোগ্যতা, দক্ষতা ও সহজ পরীক্ষাযোগ্যতা দেয়. অর্কেস্ট্রেটর বিস্তৃত, কথোপকথনমূলক মিথস্ক্রিয়ার জন্য বেশি নমনীয়তা দেয়.
LLM অগ্রসর হতে থাকলে এই পদ্ধতিগুলোর ভারসাম্য বদলাতে পারে. প্রোডাকশন ওয়ার্কলোডের জন্য আমরা রাউটার-ভিত্তিক বা হাইব্রিড আর্কিটেকচারের দিকে ঝুঁকি, আর গতিশীল, মানুষের মতো সম্পৃক্ততা দরকার এমন উন্মুক্ত সমস্যার জন্য অর্কেস্ট্রেটর রাখি.