Perplexity-এ এজেন্ট দক্ষতার ডিজাইন, পরিমার্জন এবং রক্ষণাবেক্ষণ
Perplexity যেভাবে এজেন্ট দক্ষতা লেখে, পর্যালোচনা করে এবং রক্ষণাবেক্ষণ করে, সাথে আমাদের প্রকৌশলীরা সেগুলি তৈরি করতে যে গাইড ব্যবহার করেন।
Perplexity-এর ফ্রন্টিয়ার এজেন্ট পণ্যগুলি মডুলার Agent Skills-এ প্যাকেজ করা নো-হাউ এবং ডোমেন দক্ষতার ভিত্তির উপর দাঁড়িয়ে আছে। আমরা আমাদের প্রযুক্তিগত পরিবেশ জুড়ে দক্ষতার একটি সাবধানে কিউরেট করা লাইব্রেরি বজায় রাখি। এই দক্ষতাগুলির মধ্যে রয়েছে Perplexity Computer-কে চালিত করে এমন অনেক সাধারণ-উদ্দেশ্যমূলক ইউটিলিটি; অর্থ, আইন এবং স্বাস্থ্যের মতো ক্ষেত্রগুলিতে উল্লম্ব-নির্দিষ্ট ক্ষমতা; এবং ব্যবহারকারীর চাহিদা পূরণের জন্য মডিউলগুলির একটি দীর্ঘ লেজ। কিছু দক্ষতা খুব কমই আহ্বান করা হয় তবে আহ্বান করা হলে খুব গুরুত্বপূর্ণ। ধারাবাহিকভাবে চমৎকার ব্যবহারকারী অভিজ্ঞতা নিশ্চিত করতে, Perplexity-এর এজেন্টস টিম কোডের মানের মতোই দক্ষতার মানের সমান অগ্রাধিকার দেয়।
একটি উচ্চ-মানের দক্ষতা বিকাশের জন্য প্রয়োজনীয় অন্তর্দৃষ্টি এবং সেরা অনুশীলনগুলি ঐতিহ্যবাহী সফ্টওয়্যার তৈরির জন্য প্রয়োজনীয় বিষয়গুলি থেকে উল্লেখযোগ্যভাবে আলাদা। এজেন্টস টিম চমৎকার প্রকৌশলীদের কাছ থেকে অনেক পুল রিকুয়েস্ট পর্যালোচনা করে যারা তাদের কাজের সময় দক্ষতা বিকাশ করেন। এর ফলাফল প্রায়শই সংশোধনের জন্য অসংখ্য মন্তব্য এবং পরামর্শ হয়। এর কারণ হল কোড লেখার জন্য অনেক দরকারী প্যাটার্ন দক্ষতা তৈরি করার ক্ষেত্রে অ্যান্টি-প্যাটার্ন হয়ে ওঠে।
উদাহরণস্বরূপ, আপনি যদি PEP20 – The Zen of Python থেকে কিছু অ্যাফোরিজম নেন, তবে এটি দ্রুত স্পষ্ট হয়ে যায় যে ভালো পাইথন কোড লেখা ভালো দক্ষতা লেখার মতো নয়। জ্ঞানের ২০টি লাইনের মধ্যে, অন্তত অর্ধেক সম্পূর্ণ ভুল বা দক্ষতা লেখার সময় সক্রিয়ভাবে বিভ্রান্তিকর। এখানে তার মধ্যে পাঁচটি দেওয়া হলো:
Zen of Python | Zen of Skills |
Simple is better than complex | একটি দক্ষতা একটি ফোল্ডার, ফাইল নয়। জটিলতা হলো বৈশিষ্ট্য। |
Explicit is better than implicit | অ্যাক্টিভেশন হলো অন্তর্নিহিত প্যাটার্ন ম্যাচিং। প্রগতিশীল প্রকাশ। |
Sparse is better than dense | প্রসঙ্গ ব্যয়বহুল। প্রতি টোকেনে সর্বাধিক সিগন্যাল। |
Special cases aren’t special enough to break the rules | গ্যাচাসই হলো বিশেষ কেস (এগুলি সর্বোচ্চ মূল্যের সামগ্রী)। |
If the implementation is easy to explain, it may be a good idea | যদি এটি ব্যাখ্যা করা সহজ হয়, তবে মডেলটি এটি ইতিমধ্যেই জানে। এটি মুছে ফেলুন। |
Python-এর জেন ও Skills লেখার জন্য প্রবন্ধের নির্দেশনার মধ্যে পাঁচটি পার্থক্য।
এই গাইডটি এমন একটি নথি যা Perplexity-এর প্রকৌশলীরা দক্ষতা বিকাশ ও পর্যালোচনা করার সময় ব্যবহার করেন। আমাদের আবিষ্কার এবং শিখনগুলি যাতে বৃহত্তর সম্প্রদায়কে উপকৃত করতে পারে সেজন্য আমরা জনসাধারণের কাছেও এই গাইডটি প্রকাশ করছি। আপনি আপনার দৈনন্দিন কাজে প্রোডাকশন দক্ষতা ডিজাইন করা একজন প্রকৌশলী হোন, আপনার পরিচিত কোনো ক্ষেত্রে আপনার নিজস্ব দক্ষতা বিকাশ করতে চান এমন একজন Computer ব্যবহারকারী হোন, অথবা উভয়ই হোন না কেন, এই গাইডটি আপনার জন্যই।
দক্ষতা কী?
আপনি যখন কোনো দক্ষতা লেখেন, তখন আপনি সাধারণ পুরনো কোনো সফ্টওয়্যার লিখছেন না (যদিও দক্ষতাগুলি এখন এজেন্ট সিস্টেমগুলির প্রধান যৌক্তিক ইঞ্জিনগুলির অংশ)। বরং, আপনি মডেল এবং তাদের পরিবেশের জন্য প্রসঙ্গ তৈরি করছেন। একটি দক্ষতার বিভিন্ন সীমাবদ্ধতা এবং বিভিন্ন ডিজাইন নীতি রয়েছে। আপনি যদি কোডের মতো করে কোনো দক্ষতা লেখেন, তবে আপনি ব্যর্থ হবেন।
একটি দক্ষতা অন্তত চারটি বিষয়, বিশেষ করে Perplexity-তে আমরা যেভাবে এগুলি তৈরি করি সেই প্রেক্ষাপটে।
একটি দক্ষতা হলো একটি ডিরেক্টরি
একটি দক্ষতা কেবল একটি একক SKILL.md ফাইল নয়। অনেক ক্ষেত্রে, একটি দক্ষতায় বেশ কয়েকটি ফাইল থাকে। আপনার দক্ষতার নামে নামকরণ করা ডিরেক্টরির অধীনে, আপনার কাছে থাকতে পারে:
SKILL.md: ফ্রন্টম্যাটার এবং নির্দেশাবলী
scripts/: এজেন্ট যে কোডটি চালায়, নতুন করে আবিষ্কার করে না
references/: ভারী ডক্স, শর্তসাপেক্ষে লোড করা হয়
assets/: টেমপ্লেট, স্কিমা এবং ডেটা
config.json: প্রথম-রান ব্যবহারকারী সেটআপ
এই হাব-এন্ড-স্পোক প্যাটার্ন আপনাকে দক্ষতাগুলিকে অত্যন্ত ফোকাসড এবং টাইট রাখতে দেয় এবং কেউ খুব সৃজনশীল উপায়ে ফোল্ডার স্ট্রাকচার ব্যবহার করতে পারে। কখনো কখনো, বিশেষভাবে জটিল দক্ষতাগুলি মডেলকে আরও ভালোভাবে নেভিগেট করতে সাহায্য করার জন্য একাধিক স্তরের হায়ারার্কি থেকে উপকৃত হয়। ধরুন একটি দক্ষতার ৩০০টি বিষয় জুড়ে জ্ঞানের প্রয়োজন, যেগুলিকে ২০টি বিষয়বস্তুর ক্ষেত্রে গ্রুপিং করা যায়। আজকের সেরা ফ্রন্টিয়ার মডেলগুলির জন্যও ৩০০টির মধ্যে সঠিক বিষয়টি নির্ভরযোগ্যভাবে বেছে নেওয়া একটি অমীমাংসিত চ্যালেঞ্জ। মডেলটির জন্য সেই ক্ষেত্রের ১৫টি বিষয়ের মধ্যে থেকে বেছে নেওয়ার চেয়ে ২০টি ক্ষেত্রের একটিতে মনোযোগ কেন্দ্রীভূত করা অনেক সহজ একটি পছন্দের সমস্যা।
বহুস্তরীয় হায়ারার্কি কীভাবে মান প্রদান করে তার একটি উদাহরণ হিসাবে, আমাদের টিম গত ট্যাক্স মরসুমে Computer-এর মার্কিন আয়কর ক্ষমতাগুলিকে চালিত করে এমন দক্ষতাগুলির মধ্যে তিন স্তরের বিষয়ভিত্তিক নেস্টিং ব্যবহার করেছে। ট্যাক্স আইনের জটিলতার পরিপ্রেক্ষিতে এই হায়ারার্কিটি একেবারেই অপরিহার্য ছিল: আমাদের প্রাথমিক পরীক্ষাগুলিতে, মার্কিন ইন্টারনাল রেভিনিউ কোডের সমস্ত ১,৯৪৫টি বিভাগ ধারণকারী একটি একক ফোল্ডার মডেলের সামনে উপস্থাপন করা হলে দক্ষতাটি একেবারেই না লোড করার চেয়েও খারাপ পারফরম্যান্স দেখা দিয়েছিল। উচ্চ-নির্ভুল রিড অপারেশন নিশ্চিত করার জন্য যৌক্তিক উপবিভাগে তথ্য সংগঠিত করা অপরিহার্য ছিল।
Yet this hierarchy did not come free. Increasing levels of hierarchy require increasing levels of curation across the information architecture to manage the resulting indirection. We devised quick reference guides, custom search utilities, and other tools to support the model in locating information with a minimum of indirection. In this case, doing the hard work of curation ultimately produced a positive end result: a Skill that allowed models to perform tax-related tasks much more capably than using general tools alone.
একটি দক্ষতা হলো একটি ফরম্যাট
একটি দক্ষতা হলো একটি ফরম্যাট। মূল রুট SKILL.md ফাইলে একটি নাম এবং একটি বিবরণ উভয়ই থাকতে হবে। তাছাড়া, দক্ষতাটিকে অবশ্যই সেই ডিরেক্টরি নামের সাথে হুবহু মিলতে হবে যেখানে দক্ষতাটি অবস্থিত। নামটি অবশ্যই সম্পূর্ণ ছোট হাতের অক্ষরে হতে হবে, কোনো স্পেস থাকতে হবে না এবং হাইফেন ব্যবহার করতে পারে। বিবরণটি হলো রুটিং ট্রিগার। এটি একটি সাধারণ ব্যর্থতার বিন্দু: বিবরণটি দক্ষতা কী করে তার জন্য কোনো অভ্যন্তরীণ ডকুমেন্টেশন নয়। এটি মডেলের জন্য কখন দক্ষতা লোড করতে হবে তার নির্দেশাবলীর সমতুল্য। সুতরাং, আপনি প্রায়শই দেখতে পাবেন "Load when," "This Skill does." নয়। বেশিরভাগ বাস্তবায়ন যেভাবে মডেলের মধ্যে বিবরণটি ইনজেক্ট করে তার কারণে এটি গুরুত্বপূর্ণ।
ফ্রন্টম্যাটারের মধ্যে, "depends:" ও রয়েছে, যা আপনাকে হায়ারার্কিক্যাল দক্ষতার নির্ভরতা তৈরি করতে দেয়, এবং "metadata:", যা পর্যালোচনা এবং মূল্যায়নের জন্য ব্যবহৃত হয়। বিভিন্ন এজেন্ট সিস্টেম এমনকি সেই সিস্টেমগুলির জন্য নির্দিষ্ট উপায়ে ব্যবহার করার জন্য তাদের নিজস্ব ফ্রন্টম্যাটার ক্ষেত্রগুলি সংজ্ঞায়িত করতে পারে। বিকল্প হিসাবে, মডেলের প্রসঙ্গকে ক্ষুদ্র বিবরণ দিয়ে দূষিত না করে প্রতিটি দক্ষতা প্রতি বিভিন্ন ধরনের রানটাইম আচরণ সহজতর করতে হবে এমন এজেন্ট সিস্টেম তৈরি করার সময় দক্ষতা-নির্দিষ্ট মেটাডেটা একটি অক্জিলিয়ারী JSON বা YAML কনফিগারেশন ফাইলে প্যাকেজ করা যেতে পারে। রিডের সময় দক্ষতার ফ্রন্টম্যাটার স্ট্রিপ করার মাধ্যমে অনুরূপ আচরণ অর্জন করা যায়। Computer এই পদ্ধতিটি ব্যবহার করে, যা রুট SKILL.md ফাইলে কনফিগারেশন সংরক্ষণ করার অনুমতি দেয়। পার্সিং লজিকে বিশদ বিবরণের প্রতি যত্নবান মনোযোগের প্রয়োজন, এবং মডেলের মধ্যে কিছু ক্ষেত্র থাকা দরকারী হলে কেউ শর্তসাপেক্ষ স্ট্রিপিং প্রয়োগ করতে চাইতে পারেন।
একটি দক্ষতা হলো আহ্বানযোগ্য
একটি দক্ষতা হলো আহ্বানযোগ্য। এজেন্ট রানটাইমে একটি দক্ষতা লোড করে। গুরুত্বপূর্ণ বিষয় হলো, দক্ষতাগুলি সবসময় Context-এ বান্ডিল করা থাকে না। ডিফল্টভাবে, বেশিরভাগ এজেন্ট সিস্টেম নির্দিষ্ট প্রয়োজন অনুযায়ী প্রগতিশীলভাবে দক্ষতাগুলি আনফোল্ড করে।
Computer-এ আমরা যেভাবে দক্ষতাগুলি প্রয়োগ করেছি তাতে প্রসঙ্গ খরচের অন্তত তিনটি স্তর রয়েছে। প্রক্রিয়াটি হলো এইরকম:
Computer load_skill(name="...") কল করে
Computer বিচ্ছিন্ন এক্সিকিউশন স্যান্ডবক্সে দক্ষতার ডিরেক্টরি কপি করে
Computer পুনরাবৃত্তভাবে “depends:” ট্যাগে নির্ভরতাগুলি অটো-লোড করে
Computer তখন ফ্রন্টম্যাটার স্ট্রিপ করে এবং এর ফলে এজেন্ট শুধুমাত্র বডি এবং অতিরিক্ত ফাইলগুলি দেখতে পায়
বিভিন্ন এজেন্ট সিস্টেম বিভিন্ন উপায়ে দক্ষতার বিষয়বস্তু প্রকাশ করা বেছে নিতে পারে। উদাহরণস্বরূপ, কিছু সিস্টেম ফাইলের হায়ারার্কিটি একেবারেই প্রকাশ না করা বেছে নিতে পারে, ফাইলসিস্টেম অপারেশনের মাধ্যমে হায়ারার্কি আবিষ্কার করার কাজটি মডেলের উপর ছেড়ে দিতে পারে। অন্যান্য সিস্টেম একটি নির্দিষ্ট ট্রাঙ্কেশন এবং/অথবা গভীরতার সীমা পর্যন্ত মডেলটিকে পুরো ফাইলট্রির একটি ম্যাপিং দেওয়া বেছে নিতে পারে। প্রসঙ্গ পরিষ্কার রাখতে, Computer ইনভকেশন প্রসঙ্গ থেকে সম্পূর্ণ ফাইলের হায়ারার্কি বাদ দেয়; তবে, প্রতি-দক্ষতার ভিত্তিতে এটি ওভাররাইড করা যায়।
একটি দক্ষতা হলো প্রগতিশীল
দক্ষতাগুলি প্রগতিশীল। Computer-এ, প্রসঙ্গ খরচের তিনটি ভিন্ন স্তর রয়েছে, এবং আমরা বিভিন্ন পর্যায়ে এই তিনটিই বহন করি:
স্তর | যা লোড হয় | বাজেট | যখন আপনি অর্থ প্রদান করেন |
সূচক | নাম: প্রতিটি লুকানো নয় এমন দক্ষতার জন্য বিবরণ | প্রতি দক্ষতায় ~১০০ টোকেন | প্রতিটি সেশন, প্রতিটি ব্যবহারকারী, সবসময় পরিশোধ করা হয় |
লোড | সম্পূর্ণ SKILL.md বডি | ~৫,০০০ টোকেন | ~৫,০০০ টোকেন |
রানটাইম | scripts/, references/, assets/, subskills, FORMATTING.md, SPECIAL_CASES.md-এর ফাইলগুলি | সীমাহীন | শুধুমাত্র যখন এজেন্ট সেগুলি পড়ে |
দক্ষতা প্রসঙ্গের তিনটি স্তর: ইনডেক্স, সম্পূর্ণ দক্ষতা লোড, এবং রানটাইম রেফারেন্স ফাইল।
Computer একটি দক্ষতার সূচক তৈরি করে যাতে প্রতিটি উপলব্ধ দক্ষতার নাম এবং বিবরণ রয়েছে। এর জন্য বাজেট প্রতি দক্ষতায় প্রায় ১০০ টোকেন (ছোট হলে আরও ভালো)। এটি এত টাইট কারণ আপনি প্রতিটি সেশনে, প্রতিটি ব্যবহারকারীর জন্য এই খরচ পরিশোধ করছেন। কথোপকথনের একদম শুরুতে এটি সিস্টেম প্রম্পটে ইনজেক্ট করা হয়। মডেলটির একগুচ্ছ নামযুক্ত দক্ষতা এবং বিবরণের অ্যাক্সেস রয়েছে যাতে এটি “load_skill()” কল করতে হবে কিনা তা নির্ধারণ করতে পারে। এই সূচকে প্রবেশ করার বার অত্যন্ত উঁচুতে। আপনার দক্ষতাটিকে অত্যন্ত দরকারী হতে হবে এবং বিবরণটিকে অত্যন্ত ঘন এবং সংক্ষিপ্ত হতে হবে কারণ সবাই সব সময় খরচ পরিশোধ করছে।
এজেন্ট সিস্টেম দক্ষতা লোড করার পরে, সম্পূর্ণ SKILL.md বডি থাকে। আদর্শভাবে, বডি টেক্সট ৫,০০০ টোকেন অতিক্রম করে না। এমনকি সেক্ষেত্রেও, আপনি চান প্রতিটি বাক্য যেন গুরুত্বপূর্ণ হয় কারণ একবার আপনি একটি দক্ষতা লোড করলে, কমপ্যাকশন সীমানায় পৌঁছানো পর্যন্ত বাকি কথোপকথনকে সেই মূল্য পরিশোধ করতে হয়। অনেক থ্রেড তিন থেকে পাঁচটি ভিন্ন দক্ষতার মধ্যে যেকোনো সংখ্যক লোড করে, যা এই খরচ বহুগুণ বাড়িয়ে দেয়। প্রচুর ফ্লাফ বা আবর্জনাযুক্ত দক্ষতা নিশ্চিতভাবেই অন্যান্য দক্ষতার পাশাপাশি সামগ্রিক এজেন্ট ক্ষমতাকে হ্রাস করবে। সংক্ষেপে, যদি আপনার দক্ষতা লোড হয় এবং এটি সঠিক কাজটি না করে, তবে তা নষ্ট হওয়া প্রসঙ্গ।
অগ্রগতির চূড়ান্ত স্তর হলো স্ক্রিপ্ট বা বিশেষ কেস, যেমন সাবস্কিল বা ফরম্যাটিং। এখানেই আপনি সীমাহীন শর্তসাপেক্ষ ব্রাঞ্চড লজিক রাখতে চান। এজেন্ট শুধুমাত্র যখন প্রয়োজন তখনই এটি ব্যবহার করবে, যার অর্থ এখানে আপনি যা রাখতে চান তার জন্য অনেক কম বার রয়েছে।
সূচকে, প্রতিটি টোকেন গুরুত্বপূর্ণ। লোড করা দক্ষতার বডিটি আরও শিথিল, এবং রানটাইম সবচেয়ে বেশি শিথিল। এটি ২০,০০০ টোকেন বা শূন্য টোকেন হতে পারে। এটি এমন একটি স্তর যেখানে আপনি প্রগতিশীল উপায়ে মডেলের প্রসঙ্গ প্রসারিত করার কথা বিবেচনা করতে পারেন।
আপনার কখন একটি দক্ষতা প্রয়োজন?
প্রদত্ত ডোমেন বা ব্যবহারের ক্ষেত্রের জন্য সত্যিই কোনো দক্ষতার প্রয়োজন আছে কিনা সে বিষয়ে মতামত দেওয়ার জন্য প্রায়শই এজেন্টস টিমকে বলা হয়। খুব কম ক্ষেত্রেই আমাদের কাছে কেবল প্রথম নীতি থেকে কোনো চূড়ান্ত উত্তর থাকে। এটি সত্যিই বের করার একমাত্র উপায় হলো দক্ষতা ছাড়াই আপনার এজেন্ট দিয়ে শুরু করা, বেশ কয়েকটি হিরো কোয়েরি চালানো এবং তারপর এজেন্ট ভালো কাজ করছে কিনা তা বের করা।
আপনার যখন কোনো দক্ষতার প্রয়োজন
প্রশিক্ষিত মডেলগুলির জন্য ডিস্ট্রিবিউশনে রয়েছে এমন অনেক কাজ রয়েছে। আপনি যদি এমন কোনো নির্দিষ্ট উপায়ে সেই আচরণ পরিবর্তন করতে চান যা আপনার প্রম্পটে একটি বাক্য দিয়ে করতে পারবেন না তবেই আপনাকে একটি দক্ষতা প্রয়োগ করতে হবে। সুতরাং, বিশেষ প্রসঙ্গ ছাড়া এজেন্ট যখন ভুল করবে, অথবা যদি এমন কোনো অসঙ্গতি বা অ-নির্ধারণবাদ (non-determinism) থাকে যা আপনাকে রান জুড়ে অত্যন্ত সুসংগত রাখতে হবে, তখন আপনার একটি দক্ষতার প্রয়োজন।
এমন হতে পারে যে আপনার জ্ঞান দীর্ঘস্থায়ী কিন্তু প্রশিক্ষণ ডে্টায় নেই। কাটঅফ বা এন্টারপ্রাইজ নির্দিষ্ট ওয়ার্কফ্লো থাকতে পারে, অথবা এটি পছন্দের বিষয় হতে পারে। উদাহরণস্বরূপ, Henry Modisett (আমাদের ডিজাইনের প্রধান) দ্বারা লিখিত Computer-এ আমাদের বেশ কয়েকটি ডিজাইন-সম্পর্কিত দক্ষতা রয়েছে। সেই দক্ষতাগুলিতে প্রতিটি টোকেন থাকার কারণ হলো ওয়েবসাইট এবং PDF ডিজাইন করার ক্ষেত্রে হেনরির খুব ভালো রুচি রয়েছে। হেনরি কোন ফন্টগুলি ব্যবহার করতে হবে এবং কোন ফন্টগুলি ব্যবহার করা যাবে না, সেই ফন্টগুলি কেমন অনুভূতি দেয় এবং বিচারবুদ্ধির অন্যান্য বিষয়গুলি নির্দিষ্ট করেন যা মডেল একা প্রশিক্ষণ ডেটা থেকে শিখতে পারে না।
আপনার যখন কোনো দক্ষতার প্রয়োজন নেই
আমরা এমন অনেক দক্ষতা দেখি যেখানে প্রকৌশলীরা গিট কমান্ডের একটি সিরিজ লিখেছেন যা ক্রমানুসারে কার্যকর করা প্রয়োজন। এটি অপ্রয়োজনীয় কারণ মডেলটি কীভাবে এটি করতে হয় তা ইতিমধ্যেই জানে, যার অর্থ এটি দুর্দান্ত ডকুমেন্টেশন তৈরি করে তবে একটি খারাপ দক্ষতা।
আমরা এমন উদাহরণ দেখি যেখানে দক্ষতাগুলি সিস্টেম প্রম্পট থেকে নির্দেশাবলী পুনরাবৃত্তি করে। তার জন্য আপনার কোনো দক্ষতার প্রয়োজন নেই। সংখ্যাগরিষ্ঠ অনুরোধের সাথে সম্পর্কিত জ্ঞান বিশ্বব্যাপী প্রসঙ্গে অন্তর্ভুক্ত করা উচিত, শর্তসাপেক্ষে লোড হওয়া দক্ষতায় নয়
আপনার রক্ষণাবেক্ষণ করার ক্ষমতার চেয়ে দ্রুত পরিবর্তিত হচ্ছে এমন কিছু যদি থাকে, তবে আপনার কোনো দক্ষতার প্রয়োজন নেই। উদাহরণস্বরূপ, আপনি যদি কিছু দূরবর্তী MCP এন্ডপয়েন্ট হিট করেন এবং এর টুলগুলি বা সেই টুলগুলির সংস্করণগুলি ঘন ঘন পরিবর্তিত হয়, তবে আপনার সেগুলিকে কোনো দক্ষতায় ইনজেক্ট করা উচিত নয়। আপনি যদি তা করেন, তবে আপনি কেবল ড্রিফটের শিকার হবেন এবং মডেলটি ভুল করবে।
প্রতিটি দক্ষতা হলো একটি কর
এখানে একটি দরকারী পরীক্ষা রয়েছে যা আপনি আপনার দক্ষতার প্রতিটি বাক্যে প্রয়োগ করতে পারেন: “এই নির্দেশনা ছাড়া কি এজেন্ট এটি ভুল করত?” বাক্যটির সেখানে থাকার প্রয়োজন না থাকলে, এটি সেখানে থাকার সামর্থ্য রাখে না কারণ সবাই প্রতি একক বার এই খরচ পরিশোধ করছে। আপনি একটি দক্ষতা যোগ করবেন কিনা তা সিদ্ধান্ত নেওয়ার সময়, এই করটি মনে রাখবেন যেখানে প্রতিটি সেশন এবং প্রতিটি ব্যবহারকারীর টোকেন খরচ হয়।
নিম্নলিখিত বিখ্যাত উক্তিটি, যা ফরাসীতে অনেক ভালো শোনায়, মোটামুটিভাবে অনুবাদ করে: “আমি এই চিঠিটি কেবল দীর্ঘ করেছি কারণ এটিকে ছোট করার মতো সময় আমার ছিল না।”
« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657
পাসকালের মতো, আপনাকে প্রতিটি দক্ষতায় সময় বিনিয়োগ করতে হবে। একটি ছোট দক্ষতা লেখা কঠিন। যদি আপনার দক্ষতা লেখা সহজ হয়, তবে এটি সম্ভবত খুব দীর্ঘ বা এর অস্তিত্ব থাকা উচিত নয়। একটি ভালো দক্ষতা যতটা সম্ভব ছোট হয়।
আপনি যদি নিজেকে ওয়ান-শট দক্ষতা জেনারেশন করার চেষ্টা করতে এবং পাঁচ মিনিটের মধ্যে PR আপলোড করতে দেখেন, তবে ফলাফল প্রায় নিশ্চিতভাবেই নিম্নমানের হবে। প্রকৃতপক্ষে, প্রাথমিক গবেষণায় দেখা গেছে যে আপনি যদি দক্ষতা লেখার জন্য LLM ব্যবহার করেন, তবে LLM সম্ভবত এটি থেকে উপকৃত হবে না: “স্ব-উত্পাদিত দক্ষতাগুলি গড়ে কোনো সুবিধা প্রদান করে না, যা দেখায় যে মডেলগুলি তারা যে পদ্ধতিগত জ্ঞান ব্যবহার করে তা নির্ভরযোগ্যভাবে তৈরি করতে পারে না।”
কীভাবে একটি দক্ষতা তৈরি করবেন
অন্য কথায়, আপনার লেখা যেকোনো দক্ষতায় আপনার মতামত ইনজেক্ট করতে হবে। এই ধাপগুলি অনুসরণ করুন।
ধাপ ০: ইভালস লিখুন
প্রথমে কিছু ইভাল লিখুন। আপনি মূল্যায়ন কেসগুলির উৎস পেতে পারেন:
বাস্তব ব্যবহারকারীর কোয়েরি: প্রোডাকশন বা আপনার ব্রেন ট্রাস্ট থেকে নমুনা
পরিচিত ব্যর্থতা: দক্ষতাটি বিদ্যমান না থাকায় এজেন্ট ব্যর্থ হয়েছে
প্রতিবেশী বিভ্রান্তি: আপনার ডোমেন সীমানার কাছাকাছি কিন্তু অন্য কোনো দক্ষতায় রুট করে
সর্বনিম্ন পর্যায়ে, প্রয়োজনীয়তার সময় দক্ষতা লোড হয় কিনা তা আপনি পরীক্ষা করছেন কিনা তা আপনার নিশ্চিত করা উচিত। আদর্শভাবে, আপনি এগুলির কিছু নমুনা নিন, হয়তো কোনো প্রোডাকশন পরিবেশ থেকে। আপনি পরিচিত ত্রুটির কেসগুলিও বিবেচনা করতে পারেন: হয়তো পুরো কারণে আপনি দক্ষতাটি লেখা শুরু করেছেন তা হলো আপনার লক্ষ্য করা একটি নির্দিষ্ট ব্যর্থতা অথবা হয়তো আপনি রিফ্যাক্টর করছেন এবং একটি দক্ষতা দ্বারা কভার করা দুটি কাছাকাছি ডোমেনে কিছু বিভ্রান্তি রয়েছে।
অনুরূপ নেতিবাচক এবং ইতিবাচক উদাহরণ দিয়ে শুরু করুন। নেতিবাচক উদাহরণগুলি অত্যন্ত শক্তিশালী এবং ইতিবাচক উদাহরণের চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে।
ধাপ ১: বিবরণ
এটি দক্ষতার সবচেয়ে কঠিন লাইন। এটি ডকুমেন্টেশন নয়, একটি রুটিং ট্রিগার। নাম এবং বিবরণ ঠিক করার জন্য, আপনি দক্ষতার বিষয়বস্তু নিয়ে মাথা ঘামান না। আপনি শুধুমাত্র এই বিষয়ে যত্ন নেন যে দক্ষতাটি সঠিক বিন্দুতে লোড এবং ইনজেক্ট করা হয়েছে কিনা এবং অফ-টার্গেট সাইড এফেক্ট থেকে মুক্ত কিনা, যা এক নম্বর ব্যর্থতার মোড। প্রতিবার আপনি একটি অতিরিক্ত দক্ষতা যোগ করার সময়, আপনি প্রতিটি অন্যান্য দক্ষতাকে সামান্য খারাপ করার ঝুঁকি নেন, তাই আপনাকে নিশ্চিত করতে হবে যে আপনি রিগ্রেশন কমাচ্ছেন।
আবারও বলছি, একটি খারাপ বিবরণ বর্ণনা করে যে দক্ষতাটি কী করে বা এটি কেন দরকারী। একটি ভালো বিবরণ বলে যে এজেন্টের কখন দক্ষতা লোড করা উচিত। উদাহরণস্বরূপ, ধরুন আপনার কাছে পুল রিকোয়েস্ট মনিটর করার জন্য কিছু আছে। দক্ষতা কী করে তা লিখবেন না। প্রকৌশলীরা যখন হতাশ হন এবং তারা চান যে আপনি নিশ্চিত করুন যে তাদের PR কাজ করে, তখন তারা যা বলেন তা লিখুন, যেমন “babysit” বা “watch CI” বা “make sure this lands.”
এখানে একটি দ্রুত চেককলিস্ট রয়েছে:
"Load when..." দিয়ে শুরু হয়
৫০ শব্দ বা তার কম লক্ষ্য করুন
ব্যবহারকারীর উদ্দেশ্য বর্ণনা করে, আদর্শভাবে বাস্তব কোয়েরি থেকে
ওয়ার্কফ্লো সারসংক্ষেপ করে না
বাস্তব কোয়েরি হলো যা আপনি ৮০-২০ এ কভার করতে পারেন। সাধারণত, দুই বা তিনটি উদাহরণ ভালো কাজ করে। আপনার ঠিক যতটা প্রয়োজন এবং কেবল ততটাই যোগ করা সহজ নয়।
ধাপ ২: বডি লিখুন
এর পরে, দক্ষতার মূল বিষয়বস্তু লিখুন। লক্ষ্য করুন এটি ধাপ ০ বা ধাপ ১ নয়।
কোনো সহকর্মীর কাছে, বা এমনকি আপনার রানটাইম সিস্টেমে ওয়ার্কফ্লো যোগাযোগের চেয়ে কোনো LLM-এর কাছে ওয়ার্কফ্লো যোগাযোগ করা সম্পূর্ণ আলাদা। কোনো নতুন সফ্টওয়্যার টুল শেখার সময়, একজন প্রকৌশলীর ডকুমেন্টেশন পড়ার, অভিজ্ঞতা রয়েছে এমন কারো কাছ থেকে ওয়াকথ্রু নেওয়ার এবং টুলটি কীভাবে ব্যবহার করতে হয় তা শেখার প্রয়োজন হতে পারে। ইতিমধ্যে, অন্তত এক বছর ধরে রয়েছে এমন প্রায় যেকোনো সফ্টওয়্যার টুলের জন্য, আপনার কেবল এর নাম উল্লেখ করতে হবে এবং LLM-এর কাছে এর প্রয়োজনীয় সমস্ত তথ্য রয়েছে।
বডি লেখার সময়, স্পষ্ট বিষয়গুলি এড়িয়ে চলুন। অনেক প্রকৌশলীর readme.md ফাইল লেখার যথেষ্ট অভিজ্ঞতা রয়েছে যা কারো রান করার জন্য প্রয়োজনীয় প্রতিটি কমান্ড তালিকাভুক্ত করে। আপনি যখন কোনো দক্ষতা লেখেন তখন সেই অবস্থায় ফিরে যাওয়া সহজ কারণ এটি মনে হয় যে আপনি ডকুমেন্টেশন লিখছেন, কিন্তু আপনি যদি তা করেন, তবে আপনার দক্ষতা জঞ্জাল হয়ে যাবে। সুতরাং, কমান্ডের কোনো সিরিজ লিখবেন না।
উদাহরণস্বরূপ, আপনার লেখার প্রয়োজন নেই, “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”
পরিবর্তে, লিখুন, “একটি পরিষ্কার শাখায় কমিট চেরি-পিক করুন। উদ্দেশ্য বজায় রেখে দ্বন্দ্ব সমাধান করুন। এটি পরিষ্কারভাবে ল্যান্ড করতে না পারলে, কারণ ব্যাখ্যা করুন।”
পূর্ববর্তীটির অতিরিক্ত নির্দেশমূলক কমান্ডগুলির চেয়ে মডেলটি পরবর্তীটির সাথে অনেক ভালো কাজ করবে, বিশেষ করে যখন জিনিসগুলি ভুল হয়। রেলরোড করবেন না, বা অতিরিক্ত নির্দেশমূলক হবেন না, যা ভঙ্গুর, এবং পরিবর্তে যেখানে একাধিক দৃষ্টিভঙ্গি কাজ করতে পারে সেখানে নমনীয় হোন। আবারও, মানুষের জন্য ভালো ডকুমেন্টেশন প্রায়শই মডেলের জন্য খারাপ ডকুমেন্টেশন।
এর পরে, গ্যাচাস বা নেতিবাচক উদাহরণের উপর ফোকাস করুন। এগুলি অত্যন্ত উচ্চ-সংকেত বিষয়বস্তু কারণ এগুলি প্রায়শই মডেলকে কী করতে হবে না তার পরিপ্রেক্ষিতে গাইড করে। এজেন্ট যখনই আটকে যায় তখন আপনি যদি একটি করে লাইন যোগ করেন, তবে আপনি এটি চালিয়ে শিখবেন এবং গ্যাচাসগুলি স্বাভাবিকভাবে বৃদ্ধি পাবে।
সর্বশেষ, কোনো অংশ যদি শর্তসাপেক্ষ বা বিষয়বস্তুতে অত্যন্ত ভারী হয়, তবে এটিকে SKILL.md (যা হাব) থেকে সরিয়ে ফেলুন এবং স্পোকগুলির একটিতে রাখুন। এটিকে একটি আনুষঙ্গিক ফাইলে রাখুন যা প্রগতিশীলভাবে লোড করা যেতে পারে, যা আমরা পরবর্তীতে আলোচনা করব।
ধাপ ৩: হায়ারার্কি ব্যবহার করুন
আপনার যখন কোনো স্ক্রিপ্ট, রেফারেন্স থাকে, অথবা আপনি কিছু নির্দিষ্ট টুল ব্যবহার করছেন তখন দক্ষতার হায়ারার্কি ব্যবহার করুন:
scripts/নির্ধারক লজিক যা এজেন্ট প্রতিটি রানে নতুন করে আবিষ্কার করবে | পুনর্নির্মাণ না করে কম্পোজ করার জন্য এটি কোড দিন |
references/ভারী ডক্স শুধুমাত্র একটি শর্ত পূরণ হলেই লোড হয় | "API অ-২০০ রিটার্ন করলে api-errors.md পড়ুন" |
assets/আউটপুট টেমপ্লেট যা এজেন্ট কপি করে এবং পূরণ করে | report-template.md, আউটপুট স্কিমা |
config.json প্রথম-রান ব্যবহারকারী সেটআপ | স্ল্যাক চ্যানেল চান, সংরক্ষণ করুন এবং পরবর্তী সময়ে পুনরায় ব্যবহার করুন |
একটি দক্ষতার মধ্যে স্ক্রিপ্ট, রেফারেন্স, সম্পদ, এবং কনফিগারেশনের জন্য প্রস্তাবিত ব্যবহার।
প্রধান দক্ষতা থেকে শর্তসাপেক্ষ বা ব্রাঞ্চিং করছে এমন যেকোনো কিছুর জন্য, এটিকে একটি ফোল্ডারে ভেঙে ফেলুন। মনে রাখবেন যে, বিশেষভাবে জটিল দক্ষতাগুলির জন্য বহুস্তরীয় হায়ারার্কি ব্যবহার করা যেতে পারে। এগুলির জন্য, কার্যকারিতাটি একশিলাভাবে বা দক্ষতার সংগ্রহ হিসাবে প্রয়োগ করা উচিত কিনা তা নিয়ে আপনাকে যত্ন সহকারে চিন্তা করতে হবে (সম্ভবত depends: ভিত্তিক লোডিং সম্পর্কের সাথে)।
ধাপ ৪: পুনরাবৃত্তি করুন
এর পরে, একটি শাখায় একগুচ্ছ পুনরাবৃত্তি করুন। কোনো দক্ষতা ছাড়া প্রধান শাখায় শুরু করুন, কিছু পুনরাবৃত্তি করুন, আপনার হিরো কোয়েরি সেট তৈরি করুন এবং একগুচ্ছ ইভাল চালান। মূল্যায়ন সেট সহ সম্পূর্ণ একক পরিবর্তন সেট জমা দেওয়ার জন্য আপনার দক্ষতার কোড পর্যালোচনা করা যে কেউ আপনাকে ধন্যবাদ জানাবে। পরপর ক্রমবর্ধমান পরিবর্তনগুলি (একটি নতুন গ্যাচা ছাড়া) পর্যালোচনা করা খুব কঠিন, তাই এটি হ্রাস করার চেষ্টা করুন।
আপনি সম্ভবত অনেক ছোট শব্দের পরিবর্তন করবেন। বিবরণের ছোট শব্দের পরিবর্তনগুলির রুটিংয়ের উপর একটি অতিরিক্ত প্রভাব থাকতে পারে (অন্যান্য দক্ষতার উপর স্পিলওভার প্রভাব সহ), তাই ধাপ ৫-এর আগে সমস্ত কাজ করুন।
ধাপ ৫: শিপ
এটি শিপ করুন।
কীভাবে একটি দক্ষতার রক্ষণাবেক্ষণ করবেন
যেহেতু আপনি একটি দক্ষতা লিখেছেন, তাই আপনাকে এর রক্ষণাবেক্ষণ করতে হবে।
গ্যাচাস ফ্লাইহুইল
এই বিন্দু থেকে, আপনার গ্যাচাসের তালিকা অনেক বৃদ্ধি বা পরিবর্তন হতে থাকে। আমরা প্রায়শই এমন প্রকৌশলীদের দেখি যারা PR তৈরি করেন যা মূল্যায়ন করা হয়নি, উদাহরণস্বরূপ, বিবরণ পরিবর্তন করুন। আপনার দক্ষতা মার্জ হওয়ার পরে আপনি যদি বিবরণ পরিবর্তন করেন, তবে আপনি সঠিক পথে নেই। আপনার দক্ষতা রুট করতে হবে কিনা তা নির্ধারণ করে এমন জিনিসটিতে আপনি যদি পরিবর্তন করেন, তবে পরিবর্তনগুলিকে সমর্থন করে এমন কিছু ইভাল আপনার লেখা উচিত।
দক্ষতাগুলি মূলত অ্যাপেন্ড-মোড। সময়ের সাথে সাথে গ্যাচাস বিভাগটি সর্বাধিক মান অর্জন করে:
এজেন্ট কোনো কিছুতে ব্যর্থ হয় → একটি গ্যাচা যোগ করুন
এজেন্ট অফ টার্গেটে দক্ষতা লোড করে → বিবরণ টাইট করুন এবং নেতিবাচক ইভাল যোগ করুন
প্রয়োজনীয় সময়ে এজেন্ট দক্ষতা লোড করে না → কীওয়ার্ড এবং ইতিবাচক ইভাল যোগ করুন
সিস্টেম প্রম্পট পরিবর্তিত হয় → প্রতিদ্বন্দ্বিতা বা ডুপ্লিকেশন পরীক্ষা করুন
অভ্যন্তরীণ টেস্টে বা প্রোডাকশনে একটি একক ব্যর্থতার কেস লক্ষ্য করা এবং একটি গ্যাচা যোগ করা সহজ। এটি একটি নেতিবাচক উদাহরণ তাই এটি সত্যিই স্পষ্ট নির্দেশিকা পরিবর্তন করছে না, তবে এটি মডেলকে জানায়, “আরে, এই পরিচিত ব্যর্থতাটি রয়েছে।”
আপনি যখন ৮০-২০ থেকে ৯৯.৯% বা ৯৯.৯৯% সাফল্যের হারে পৌঁছানোর দিকে এগিয়ে যান, তখন এই গ্যাচা তালিকাটি বৃদ্ধি করা সহজ। আপনি যখন এই নেতিবাচক উদাহরণগুলি দেখতে পান, তখন আপনার মূলত গ্যাচা বিভাগে অ্যাপেন্ড করা উচিত। আপনার দীর্ঘ নির্দেশাবলী যোগ করা বা বিবরণ পরিবর্তন করা উচিত নয়।
ইভাল সুইটস
Perplexity-এ, আমরা বিভিন্ন জিনিস পরীক্ষা করার জন্য অনেক ইভাল সুইট চালাই। দক্ষতা লোডিং এবং দক্ষতা ফাইল রিড রয়েছে, যা দক্ষতা লোডিংয়ের নির্ভুলতা, রিকল এবং নিষিদ্ধ পরীক্ষাগুলি পরীক্ষা করে। যখন প্রয়োজন হবে তখন কি এজেন্ট আপনার দক্ষতা রুট করবে? এগুলি নিশ্চিত করে যে নতুন দক্ষতাগুলি বিদ্যমান সীমানা ভেঙে না দেয়।
এমন ইভালও রয়েছে যা যথাযথ প্রগতিশীল লোডিং পরীক্ষা করতে পারে। এজেন্ট দক্ষতা লোড করতে পারে, তবে এটি কি আনুষঙ্গিক ফাইল বা ফাইলগুলি পড়ে? উদাহরণস্বরূপ, ফাইন্যান্স কোয়েরির জন্য আপনার যদি কোনো ফাইন্যান্স দক্ষতা থাকে, তবে এটি কি বিশেষ FORMATTING.md ফাইলটি পড়ে?
এছাড়াও, Skills-এর জন্য evals রয়েছে, যা ডোমেইনের ভেতরে end-to-end task completion পরীক্ষা করে। আমরা পূর্ণ agent loop চালাই এবং সুস্পষ্ট মানদণ্ডের একটি rubric-এর ভিত্তিতে ফলাফল মূল্যায়ন করতে একটি LLM judge ব্যবহার করি.
অবশেষে, বিভিন্ন মডেলের বিরুদ্ধে এই ইভালগুলি চালানো গুরুত্বপূর্ণ। Computer অন্তত তিনটি ভিন্ন অর্কেস্ট্রেশন মডেল পরিবার সমর্থন করে: GPT, Claude Opus, এবং Claude Sonnet। আপনি ভিন্ন আচরণ পান না তা নিশ্চিত করতে আপনি বিভিন্ন এজেন্ট অর্কেস্ট্রেটারের বিরুদ্ধে আপনার দক্ষতা লোডিং এবং ডোমেন দক্ষতা চালাতে চান। দক্ষতার ক্ষেত্রে Sonnet এবং GPT বেশ আলাদাভাবে আচরণ করে।
চূড়ান্ত ভাবনা এবং টেকঅ্যাওয়ে
আপনি যত বেশি দক্ষতা তৈরি করবেন, সেগুলিতে আপনি তত ভালো হবেন। আপনি যদি দক্ষতা ব্যবহার করে প্রতিদিনের ভিত্তিতে করছেন এমন কাজগুলি অটোমেট বা আরও পুনরুৎপাদনযোগ্য করার চেষ্টা না করেন, তবে অবিলম্বে শুরু করুন।
দক্ষতা তৈরির কাজটি আপনাকে আরও দক্ষতা তৈরিতে ভালো করে তোলে, পাশাপাশি, ব্যবসায়িক প্রক্রিয়া অটোমেট করার ক্ষেত্রে এগুলি অত্যন্ত ভালো। আপনার স্ট্যান্ডআপের আগে প্রতি সপ্তাহে, প্রতিটি স্প্রিন্টের শেষে আপনি যা করেন এমন কিছু বর্ণনা করতে পারলে, অথবা প্রকৌশলী হিসেবে দৈনিক, সাপ্তাহিক বা এমনকি ত্রৈমাসিক ভিত্তিতে আপনি যা করেন তা বর্ণনা করতে পারলে, আপনার সময় ফিরিয়ে কেনার জন্য আপনার একটি দক্ষতা লেখা উচিত।
আপনি কি পোস্টমর্টেম অটোমেট করতে পারেন? আপনি কি পুল রিকোয়েস্ট পর্যালোচনা করতে পারেন? আপনার করা যেকোনো কাজের জন্য, আপনি অন্তত প্রথম পাসটি একটি এজেন্ট দক্ষতা হতে দিতে পারেন। এটি আপনার উল্লেখযোগ্য সময় বাঁচাবে।
তা সত্ত্বেও, মনে রাখবেন যে একটি দক্ষতা সহজ নয় বা সবসময় প্রয়োজনীয়ও নয়। কম হলো বেশি। আরও কিছু টেকঅ্যাওয়ে:
দক্ষতার আগে ইভাল লিখুন। সংলগ্ন কিন্তু স্বতন্ত্র দক্ষতার জন্য নেতিবাচক উদাহরণ এবং নিষিদ্ধ লোড অন্তর্ভুক্ত করুন।
বিবরণটি হলো কঠিন অংশ। "Load when..." (প্রতিটি শব্দের খরচ মনোযোগ)।
গ্যাচাস হলো অত্যন্ত উচ্চ-মূল্যের বিষয়বস্তু। পাতলা দিয়ে শুরু করুন, এজেন্ট ব্যর্থ হওয়ার সাথে সাথে বৃদ্ধি করুন।
মনে রাখবেন যে আপনি নতুন কোনো দক্ষতা যোগ করার মাধ্যমে অন্যান্য প্রাক-বিদ্যমান দক্ষতা ভেঙে ফেলা সহজ, যদিও আপনি এটিকে স্পর্শ করেননি (দূরত্বে ক্রিয়া সম্পর্কে সতর্ক থাকুন)।
আপনি যখনই কোনো দক্ষতা লিখছেন এবং রক্ষণাবেক্ষণ করছেন তখন উপলব্ধ সমস্ত টুল ব্যবহার করুন। আপনি যদি আরও জানতে চান, তবে Agent Skills ওয়েবসাইটে প্রচুর ভালো উদাহরণ রয়েছে, এবং আমাদের অভ্যন্তরীণ সংগ্রহশালা এবং সর্বজনীন ইকোসিস্টেম উভয়টিতেই ভালোভাবে ডিজাইন করা দক্ষতার অনেক উদাহরণ রয়েছে।
উদ্ধৃতি
@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
title = {{Designing, refining, and maintaining agent skills at Perplexity}},
date = {2026-05-01},
url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}