এজেন্ট কাজটি গ্রহণ করার পরে, প্রথম জিনিসটি আঁটসাঁট করার জন্য কাজ ইউনিট।

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

কাজের ইউনিটটি প্রথমে গ্রহণযোগ্য হতে হবে

গত কয়েকদিনে, সফটওয়্যার ডেভেলপমেন্ট রিট্রিটের থটওয়ার্কস ফিউচারে মার্টিন ফাউলারের টুকরো টুকরো টুকরো এবং বেশ কয়েকটি আলোচনা একসাথে করার পরে, সবচেয়ে স্পষ্ট অনুভূতি হল যে মিটিংয়ে কথোপকথনটি অতিমাত্রায় ছড়িয়ে ছিটিয়ে ছিল, কিন্তু এর নীচে আসলে শুধুমাত্র একটি জিনিসকে ঘিরে ছিল - এজেন্টের কাছে একটি বড় কাজ হস্তান্তর করা।

কিফ মরিসের ফিনিশিং সবচেয়ে সোজা। বিভিন্ন সেশনে কোড পর্যালোচনা, উৎপাদন দুর্ঘটনা, শ্রমের দলগত বিভাগ এবং মডেল রাউটিং নিয়ে আলোচনা করা হয়েছে। তারা বিভিন্ন বিষয়ে কথা বলছে বলে মনে হয়েছিল, কিন্তু উপসংহারটি একই হতে চলেছে: লোকেরা “ইউনিট ওয়ার্ক” এর আকার সামঞ্জস্য করছে। ইউনিটটি যত বড় হবে, এটি হস্তান্তর করা তত সহজ হবে; ইউনিটটি যত বড় হবে, এটি ফিরে আসার পরে এটি গ্রহণ করা তত কঠিন হবে। এটি এমন নয় যে মডেলটি এটি করতে পারে না, এটি হল যে পরবর্তী নিশ্চিতকরণ লিঙ্কটি প্রথমে ধরে রাখতে পারে না।

এই কারণেই জোতা বারবার উল্লেখ করা হয়। কনটেক্সট ম্যানেজমেন্ট, কম্পিউটেশনাল সেন্সর, সম্পত্তি-ভিত্তিক পরীক্ষা, আনুষ্ঠানিক পদ্ধতি, এই জিনিসগুলি অতিরিক্ত সরঞ্জামের মতো শোনায়, কিন্তু তারা আসলে কাজের ইউনিট সংগ্রহ করে। কিছু লোক agents.md কে 200 এর কম লাইনে নিয়ন্ত্রণ করে, আকারে পরিচ্ছন্নতা অনুসরণ করার জন্য নয়, তবে সিস্টেমকে কেবল সেই তথ্যের অংশ গ্রহণ করতে বাধ্য করে যা সত্যিই দরকারী এবং সত্যই পরীক্ষা করা যেতে পারে। প্রসঙ্গ খুব শিথিল, অবশ্যই এজেন্ট চালাতে পারে; কিন্তু দৌড়ানোর পরে, কেউ জানে না কোন স্তরের সীমাবদ্ধতা গ্রাস করেছে।

স্ব-হোস্টিং নিয়ন্ত্রণ পৃষ্ঠকে উপরে নিয়ে আসে

স্ব-হোস্টেড মডেলের আলোচনাও একই জিনিসের দিকে ইঙ্গিত করে। টোকেনগুলি আরও ব্যয়বহুল হওয়ার পরে, সম্মতির প্রয়োজনীয়তাগুলি আরও কঠোর হয়ে যায় এবং ডেটা ফাঁস করা যায় না, ওপেন সোর্স মডেল এবং স্থানীয় মডেলগুলি স্বাভাবিকভাবেই আরও আকর্ষণীয় হয়ে উঠবে। কিন্তু একবার আপনি নিজেই মডেলটি বহন করলে, আপনারও সমস্যা হবে: GPU, ইনফারেন্স রুম, রাউটিং, রোলব্যাক, ফাইন-টিউনিং এবং মডেল নির্বাচন। এগুলি নিজেরাই মডেলের ক্ষমতা নয়, তবে তারা নির্ধারণ করবে যে সিস্টেমটি শেষ পর্যন্ত স্থিতিশীল কিনা।

এই ধরনের খরচ প্রায়ই অবমূল্যায়ন করা হয়. অনেক দল প্রাথমিকভাবে “মডেলটি শক্তিশালী কিনা” এর উপর দৃষ্টি নিবদ্ধ করেছিল, কিন্তু পরে আবিষ্কার করেছিল যে যেটি সত্যিই সময় ব্যয় করে তা হল একাধিক মডেলের মধ্যে কাজের ইউনিটের স্থিতিশীল স্থানান্তর। কখন একটি বড় মডেল ব্যবহার করবেন, কখন একটি হালকা মডেল ব্যবহার করবেন এবং কখন একটি স্থানীয় মডেল ব্যবহার করবেন, এটি মৌখিক পছন্দের উপর নির্ভর করে না, তবে নিয়ন্ত্রণ পৃষ্ঠের একটি স্তরের উপর নির্ভর করে যা ডাইভারশন এবং কভার-আপের জন্য ব্যবহার করা যেতে পারে। এই স্তরের জিনিসগুলি ছাড়া, স্ব-হোস্টিং “উদ্যোগ নেওয়া” থেকে “পরিচালনা এবং রক্ষণাবেক্ষণের জটিলতা নিজের হাতে নেওয়া” থেকে পিছলে যাবে।

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

গ্রহণযোগ্যতা এবং লক্ষ্য আউটসোর্স করা যাবে না

স্যাম রুবির “আমাকে একটি রক আনুন” আরেকটি সমস্যা আলোকে এনেছে। মডেলকে কাজ দেওয়া একজন নির্বাহক যোগ করার সমতুল্য; দায়িত্ব অদৃশ্য হয় না। পরিচালকরা অন্বেষণের জন্য এলএলএম ব্যবহার করতে পারেন, এবং তারা প্রথমে এটিকে প্রার্থীর সমাধানগুলির একটি গুচ্ছ থুতু দিতে পারেন, তবে চূড়ান্ত গ্রহণযোগ্যতার মানদণ্ড এখনও মানুষের হাতে পড়তে হবে। লুকানো লক্ষ্য সবচেয়ে ঝামেলার। অনুমতি, গোপনীয়তা, ধ্বংসাত্মক কর্ম, এবং প্রসঙ্গ ফাঁস প্রায়ই মূল প্রয়োজনীয়তা অন্তর্ভুক্ত করা হয় না.

সুতরাং কনফরমেন্স পরীক্ষাগুলি প্রায়শই স্পেসিফিকেশনের চেয়ে বেশি কার্যকর। স্পেসিফিকেশনগুলি “কী প্রয়োজন” বর্ণনা করতে ভাল এবং “কী ঘটতে পারে না” তা প্রকাশ করার ক্ষেত্রে পরীক্ষাগুলি ভাল। এটি বিশেষ করে এজেন্ট সিস্টেমে সত্য। মডেলটি সুস্পষ্ট লক্ষ্যগুলির জন্য খুব ভালভাবে তৈরি করতে পারে, তবে অন্তর্নিহিত সীমানাগুলি আরও কঠিন যাচাইয়ের মাধ্যমে যাচাই করা দরকার। যতক্ষণ গ্রহণযোগ্যতার শর্তগুলি অস্পষ্ট বর্ণনায় থাকবে, এজেন্ট যত বেশি করবে, সিস্টেমটি তত বেশি দেখাবে যে এটি সম্ভাব্যতার উপর বাজি ধরছে।

অতএব, কোড পর্যালোচনা, ঘটনা পরিচালনা, এবং টাস্ক অ্যাসাইনমেন্ট, যা খুব মানব-সদৃশ কাজ ছিল, এখন অন্য রূপ নিতে শুরু করেছে। পরিচালকরা মডেলটি সরাসরি ব্যবহার করেন। পৃষ্ঠে, এটি দক্ষতার উন্নতি করছে বলে মনে হচ্ছে, কিন্তু নীচের স্তরে, তারা আসলে একটি ব্যবস্থাপনা পদ্ধতি পরিবর্তন করছে: পরিচালনা পদ্ধতি থেকে লক্ষ্য পরিচালনা পর্যন্ত। লক্ষ্য স্পষ্টভাবে লেখা থাকলে, মডেলের কাজ করার সুযোগ থাকবে; যদি লক্ষ্যটি অস্পষ্ট হয়, মডেলটি শুধুমাত্র অন্যদের জন্য অস্পষ্টতাকে প্রসারিত করবে।

অভিজ্ঞতা এবং পড়ার দক্ষতা এখনও উন্নত হচ্ছে

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

সফ্টওয়্যার সরবরাহের ক্ষেত্রে এই বিষয়টি আরও সহজবোধ্য। এজেন্ট দায়িত্ব নেওয়ার পরে, মানুষের কাজ ম্যানুয়াল এক্সিকিউশনে কম পড়বে এবং টাস্ক সেগমেন্টেশন, সীমানা সংজ্ঞা, গ্রহণযোগ্যতা ডিজাইন এবং ব্যতিক্রম পরিচালনার উপর বেশি পড়বে। কাজগুলি হস্তান্তর করা যেতে পারে কিনা তা স্পষ্টভাবে নির্ধারণ করে যে পরবর্তী প্রসঙ্গ ব্যবস্থাপনা, মডেল রাউটিং এবং টুল অর্কেস্ট্রেশন করা উপযুক্ত কিনা। যদি ইউনিটটি পরিষ্কার না হয়, তবে কতগুলি স্তরই থাকুক না কেন, এটি কেবল সমস্যাটিকে পিছনে ঠেলে দেবে।

গত কয়েক দিনে এই টুকরোগুলি পড়ার পরে, আমার মনে যা থেকে যায় তা একটি নির্দিষ্ট মডেলের নাম বা একটি নতুন কাঠামো নয়, তবে একটি সহজ রায়: এজেন্ট সিস্টেমকে প্রথমে যে জিনিসটি শক্ত করতে হবে তা হল মডেলের ক্ষমতা নয়, কিন্তু কাজের ইউনিট। যদি ইউনিটটি ছোট হয়, গ্রহণযোগ্যতা কঠোর হয়, এবং অনুমতিগুলি কঠোর হয়, তবে সিস্টেমটি একটি নিয়ন্ত্রণযোগ্য সীমার মধ্যে জটিলতা রাখার সুযোগ পাবে।