اگر زیاد از ابزارهای هوش مصنوعی برای برنامهنویسی استفاده میکنید، احتمالاً با یک مشکل آشنا هستید: محدودیت توکنها زودتر از چیزی که انتظار دارید تمام میشود. در نگاه اول شاید راهحل منطقی این باشد که سراغ یک پلن گرانتر بروید، اما همیشه اینطور نیست.
گاهی مشکل از مقدار کاری که انجام میدهید نیست؛ بلکه از نحوه انتقال Context به مدل است. نگهداشتن یک گفتوگوی بسیار طولانی میتواند باعث شود اطلاعات زیادی همراه هر درخواست دوباره در اختیار مدل قرار بگیرد. در Codex میتوان بخشی از این اطلاعات و دستورالعملهای تکراری را به یک Skill تبدیل کرد و به جای حمل کردن تاریخچه یک گفتوگوی طولانی، همان دستورالعملهای موردنیاز را در پروژههای جدید دوباره به کار گرفت.
مستندات رسمی OpenAI نیز Skills را به عنوان گردشکارهای قابل استفاده مجدد معرفی میکند که میتوانند شامل دستورالعملها، مثالها، کد و منابع موردنیاز برای انجام یک کار مشخص باشند. Codex نیز از Skills برای اجرای کارهای تکراری و تخصصی با روندی ثابت استفاده میکند.
فکر میکردم گفتوگوهای طولانی بهترین راه برای گرفتن نتیجه ثابت هستند
اما هرچه Context بزرگتر شود هزینه توکنی هم بیشتر میشود
حدود یک سال و نیم بود که برای کارهای مختلف از هوش مصنوعی استفاده میکردم و معمولاً گفتوگوهایی را که نتیجه خوبی میدادند نگه میداشتم. حتی اگر قرار بود چند هفته یا چند ماه روی یک موضوع کار کنم، همان Thread را ادامه میدادم تا مدل سبک پاسخگویی و دستورالعملهای قبلی را از دست ندهد.
این روش در بعضی سرویسها مشکل چندانی ایجاد نمیکند. اما در ابزارهایی مانند Codex که محدودیت استفاده و توکن اهمیت بیشتری دارد، ادامه دادن یک گفتوگوی بسیار طولانی میتواند هزینه بیشتری ایجاد کند.
دلیلش ساده است. مدل هوش مصنوعی مانند یک انسان که تمام گفتوگوی قبلی را در ذهن خود نگه داشته باشد عمل نمیکند. برای پاسخ دادن به یک درخواست، سیستم باید اطلاعات مرتبط با مکالمه را در Context در اختیار مدل قرار دهد.
بنابراین اگر یک گفتوگو ماهها ادامه پیدا کرده باشد و شامل دستورالعملها، تصمیمها، نمونههای کد و توضیحات زیادی باشد، بخشی از همین اطلاعات باید دوباره در فرایند پردازش مورد استفاده قرار بگیرد.
هرچه Context بزرگتر باشد، مصرف توکن نیز میتواند افزایش پیدا کند.
اینجاست که یک مشکل دیگر هم ظاهر میشود. گفتوگوهای بسیار طولانی معمولاً برای مدیریت حجم اطلاعات خلاصه یا فشرده میشوند. این فرایند میتواند باعث شود بعضی جزئیات مهم در طول زمان کمرنگ شوند یا مدل برای درک درخواست جدید مجبور شود اطلاعات بیشتری را بررسی کند.
در معماری Codex نیز Context و تاریخچه پیامها بخش مهمی از ورودی مدل هستند و OpenAI برای مواردی که وارد Context میشوند محدودیتهای مشخصی در نظر گرفته است.
راهحل سادهتر این بود که از Skill استفاده کنم
به جای ادامه دادن یک Thread قدیمی، دستورالعملهای مفید آن را جدا کردم
مدتی فکر میکردم ساختن Skill باید کاری کاملاً دستی باشد. تصورم این بود که باید فایلهای مختلف را خودم بنویسم و همه دستورالعملها را از ابتدا طراحی کنم.
اما رویکرد سادهتر این است که از خود Codex برای تبدیل یک روند کاری موفق به یک Skill کمک بگیرید.
اگر در یک گفتوگوی طولانی به مجموعهای از دستورالعملها و روش کاری مناسب رسیدهاید، میتوانید از Codex بخواهید آن روند را استخراج کند و به یک Skill قابل استفاده مجدد تبدیل کند. به همین ترتیب، اگر در یک گفتوگوی جدید به نتیجه بسیار خوبی رسیدید، میتوانید همان روش را به عنوان یک Skill برای کارهای بعدی نگه دارید.
این روش یک مزیت مهم دارد: به جای اینکه هر بار یک گفتوگوی طولانی را ادامه دهید تا Codex متوجه شود دقیقاً چه میخواهید، دستورالعملهای اصلی را یک بار تعریف میکنید و بعد همان روند را دوباره به کار میبرید.
Skill در Codex دقیقاً چه کاری انجام میدهد؟
دستورالعملهای تکراری را به یک گردشکار قابل استفاده مجدد تبدیل میکند
Skill را میتوان مانند یک راهنمای تخصصی برای Codex در نظر گرفت. این راهنما میتواند مشخص کند یک کار چگونه باید انجام شود و چه استانداردهایی باید رعایت شوند.
طبق مستندات OpenAI، یک Skill میتواند شامل فایل SKILL.md باشد و در صورت نیاز اسکریپتها و منابع دیگری نیز در اختیار Codex قرار دهد. Codex ابتدا اطلاعات اولیه Skill را میشناسد و در صورت مرتبط بودن آن را فعال میکند. سپس دستورالعملهای کامل Skill را در زمان نیاز میخواند. این ساختار به اصطلاح Progressive Disclosure کمک میکند که همه جزئیات همه Skills از ابتدا وارد Context نشوند.
برای نمونه فرض کنید همیشه از Codex میخواهید یک پروژه React را با استاندارد مشخصی توسعه دهد. به جای اینکه در هر گفتوگو دوباره توضیح دهید:
- ساختار پروژه چگونه باشد
- نامگذاری فایلها چگونه انجام شود
- تستها چگونه نوشته شوند
- کدها چگونه بررسی شوند
- چه کتابخانههایی مجاز باشند
- چه مراحلی قبل از تحویل اجرا شوند
میتوانید این دستورالعملها را در یک Skill قرار دهید.
از این به بعد هر زمان کاری مرتبط با آن Skill انجام دهید، Codex میتواند از همان دستورالعملها استفاده کند.
نتیجه برای من، مصرف بسیار کمتر توکن بود
وقتی اطلاعات تکراری را از Thread حذف کردم تفاوت کاملاً محسوس شد
بعد از اینکه استفاده از Skill را جدیتر کردم، دیگر برای هر کار مشابه مجبور نبودم یک Thread قدیمی و سنگین را ادامه بدهم.
برای کارهایی که قرار بود چند بار تکرار شوند، Skill ساختم و گفتوگوهای جدید را با همان دستورالعملها شروع کردم. نتیجه فقط کاهش Context نبود؛ پاسخها نیز در بسیاری از موارد منظمتر و قابل پیشبینیتر شدند.
دلیلش این است که یک Skill میتواند دستورالعمل مشخصی را به صورت ساختاریافته نگه دارد. در مقابل، یک Thread طولانی ممکن است شامل صحبتهای غیرمرتبط، آزمونهای ناموفق، تصمیمهای قدیمی و اطلاعاتی باشد که دیگر برای کار فعلی کاربردی ندارند.
به بیان سادهتر، به جای اینکه به Codex بگویید:
«همه آن چیزهایی را که چند ماه پیش درباره این پروژه گفتیم به خاطر بیاور»
میتوانید دستورالعملهای ضروری را در یک Skill نگه دارید و فقط اطلاعات مربوط به کار فعلی را وارد گفتوگو کنید.
این تفاوت برای پروژههای بزرگ میتواند قابل توجه باشد.
Skills فقط برای کاهش مصرف توکن نیستند
مزیت مهمتر میتواند ثبات نتیجه باشد
اگر یک کار را بارها انجام میدهید، کاهش مصرف توکن تنها مزیت استفاده از Skill نیست.
فرض کنید هر هفته باید یک نوع مشخص از کد را تولید کنید. در روش معمول ممکن است هر بار بخشی از دستورالعملها را دوباره بنویسید. حتی اگر همه جزئیات را به خاطر داشته باشید، احتمال دارد ترتیب مراحل یا بعضی استانداردها تغییر کند.
Skill میتواند این روند را استاندارد کند.
به عنوان مثال یک Skill برای بررسی Pull Request میتواند به Codex بگوید ابتدا ساختار تغییرات را بررسی کند، سپس تستها را اجرا کند، خطاهای احتمالی را پیدا کند و در نهایت خلاصهای از مشکلات مهم ارائه دهد.
یک Skill دیگر میتواند برای مستندسازی باشد و قالب مشخصی را برای توضیحات فنی رعایت کند.
در واقع Skill بیشتر از اینکه یک «پرامپت طولانی» باشد، یک گردشکار قابل استفاده مجدد است.
OpenAI نیز Skills را دقیقاً با همین رویکرد معرفی میکند و آنها را برای تبدیل روشهای کاری تکرارشونده به دستورالعملهایی میداند که میتوانند بارها مورد استفاده قرار بگیرند.
چطور یک Skill مناسب برای Codex بسازیم؟
از کارهایی شروع کنید که بیشتر از یک بار انجام میدهید
لازم نیست از همان ابتدا برای همه فعالیتهای خود Skill بسازید. بهترین نقطه شروع، کارهای تکراری هستند.
اگر کاری را مرتب انجام میدهید و هر بار مجبورید همان دستورالعملها را دوباره توضیح دهید، احتمالاً گزینه خوبی برای تبدیل شدن به Skill است.
یک روش کاربردی این است:
- یک کار را با Codex انجام دهید.
- دستورالعملهایی را که باعث نتیجه خوب شدهاند مشخص کنید.
- از Codex بخواهید این روند را به یک Skill تبدیل کند.
- Skill ایجادشده را بررسی و اصلاح کنید.
- در کارهای بعدی همان Skill را دوباره استفاده کنید.
مخزن رسمی Skills شرکت OpenAI نیز نمونههای مختلفی از Skills را ارائه میکند و ساختار آنها بر پایه دستورالعملها و منابع قابل استفاده مجدد طراحی شده است.
چه زمانی Thread طولانی هنوز انتخاب بهتری است؟
همه چیز را نباید به Skill تبدیل کرد
این تغییر به این معنا نیست که باید همه گفتوگوهای طولانی را کنار بگذارید.
اگر در حال انجام یک پروژه پیچیده هستید و تصمیمهای مختلفی در طول همان جلسه گرفته میشود، حفظ Context فعلی میتواند مفید باشد. در چنین شرایطی قطع کردن گفتوگو ممکن است باعث شود اطلاعاتی که هنوز برای کار فعلی اهمیت دارند از دست بروند.
Skill بیشتر برای دانش و دستورالعملهای پایدار مناسب است؛ یعنی چیزهایی که قرار است بارها و در پروژههای مختلف تکرار شوند.
در مقابل، جزئیات موقتی پروژه بهتر است در Context همان پروژه باقی بماند.
به عنوان مثال استاندارد کدنویسی تیم میتواند داخل Skill باشد، اما تصمیمی که امروز درباره یک تابع خاص گرفتهاید لزوماً نباید به Skill منتقل شود.
این تغییر چگونه هزینه استفاده از هوش مصنوعی را کاهش میدهد؟
اگر یک گفتوگوی طولانی مرتباً اطلاعات زیادی را همراه درخواستهای جدید وارد Context کند، بخشی از ظرفیت پردازشی مدل صرف اطلاعاتی میشود که ممکن است برای درخواست فعلی ضروری نباشند.
Skill میتواند این روند را بهینهتر کند؛ زیرا Codex میتواند دستورالعملهای مربوط به کار را هنگام نیاز بارگذاری کند و از وارد کردن تمام جزئیات همه Skills به Context اولیه خودداری کند. مستندات فنی Codex نیز توضیح میدهد که اطلاعات اولیه Skills با حجم محدودی وارد Context میشوند و دستورالعمل کامل تنها زمانی خوانده میشود که Skill انتخاب شود.
بنابراین صرفهجویی واقعی همیشه به معنای «تعداد کمتری پیام» نیست. گاهی کافی است اطلاعات غیرضروری را از مسیر هر درخواست خارج کنید.
آیا ساخت Skill واقعاً ارزش دارد؟
برای کاربری که فقط گاهی از Codex استفاده میکند، احتمالاً تفاوت زیادی ایجاد نمیکند. اما اگر هر روز با Codex کدنویسی میکنید و مرتباً کارهای مشابه انجام میدهید، Skills میتواند یکی از کاربردیترین روشها برای منظمتر کردن جریان کاری باشد.
مهمتر از همه این است که برای ساخت Skill لازم نیست از صفر یک سیستم پیچیده طراحی کنید. میتوانید ابتدا کاری را به همان روشی که همیشه انجام میدهید با Codex انجام دهید و بعد از اینکه به یک روند موفق رسیدید، همان روند را به دستورالعملی قابل استفاده مجدد تبدیل کنید.
این دقیقاً همان تغییری بود که باعث شد دیگر لازم نباشد صرفاً به دلیل مصرف بالای توکن سراغ پلن گرانتر بروم.
آینده کدنویسی با هوش مصنوعی احتمالاً بیشتر به سمت گردشکارهای قابل استفاده مجدد میرود
هوش مصنوعی کدنویسی دیگر فقط درباره نوشتن چند خط کد با یک Prompt نیست. ابزارهایی مانند Codex به سمت محیطهایی حرکت میکنند که در آنها Skills، دستورالعملهای پروژه و ابزارهای تخصصی در کنار مدل قرار میگیرند.
OpenAI نیز Codex را به عنوان عاملی برای انجام کارهای واقعی توسعه نرمافزار معرفی میکند و Skills را روشی برای آموزش استانداردها و گردشکارهای تیم به Codex میداند.
بنابراین اگر احساس میکنید مصرف توکن شما بیش از حد بالا رفته، قبل از ارتقای پلن یک سؤال ساده از خودتان بپرسید: آیا واقعاً به توکن بیشتری نیاز دارید یا فقط اطلاعات تکراری زیادی را هر بار دوباره به مدل میفرستید؟
در بسیاری از پروژهها، پاسخ میتواند دومی باشد.
سادهگو
