آیا تابهحال دیدهاید که اعلان خاصی خوب کار کند، اما ناگهان از کار بیفتد؟
آیا تابهحال در چرخه اصلاح مداوم اعلان سیستمی برای بهبود نتایج گرفتار شدهاید، اما در نهایت هیچچیز جواب نداده باشد؟
شاید یادگیری اعلان سیستمی دقیقاً همان چیزی باشد که نیاز دارید.
یادگیری اعلان سیستمی (SPL) حوزهای نوظهور و مورد توجه جامعه هوش مصنوعی است که در ماه مه، آندری کارپاتی آن را در X بهطور گسترده رواج داد.
یادگیری اعلان سیستمی محدودیتهای سامانههای هوش مصنوعی انعطافناپذیر و شکنندهای را برطرف میکند که به اعلانهای سیستمی ثابت یا سازوکارهای تنظیم دقیق دستوپاگیر متکیاند. این روش راه دیگری برای پشتیبانی از یادگیری پیوسته در سامانههای هوش مصنوعی ارائه میدهد.
پیش از ورود به بحث، بیایید مبانی اعلاننویسی را بهاختصار مرور کنیم.
هنگام توسعه یک عامل یا مدل سفارشی، ابتدا باید دو مؤلفه کلیدی را طراحی کنیم:
یک اعلان سیستمی
یک اعلان کاربر
اعلانهای سیستمی قواعد پایه رفتار مدل را تعیین میکنند. در راهکارهای سفارشی هوش مصنوعی، این اعلانها اغلب با عبارتی شبیه نمونه زیر آغاز میشوند:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
در مقابل، اعلانهای کاربر معمولاً شامل پرسش کاربر و اطلاعات مرتبط دیگری مانند منطقه زمانی و ترجیحات او هستند. یک اعلان کاربر ممکن است چنین باشد:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
پس از انتشار مدلهای جدید آزمایشگاههای بزرگ هوش مصنوعی، افشای اعلانهای سیستمی رایج شده است؛ زیرا کاربران با دور زدن محدودیتهای چتباتها، دستورالعملهای زیربنایی آنها را آشکار میکنند. اکنون یک محل نگهداری محبوب در GitHub بسیاری از این اعلانهای سیستمی را در یکجا گردآوری میکند. این اعلانها «فرمول محرمانهای» را آشکار میکنند که آزمایشگاههای هوش مصنوعی بهمرور برای ترغیب مدل به رفتار مناسب ساختهاند. برای نمونه، اعلان سیستمی GPT-5 که بهتازگی افشا شد (از درون ChatGPT) حدود ۶٬۰۰۰ کلمه دارد و نشان میدهد برای شکلدهی رفتار سامانه چه میزان دانش و راهنمایی باید در آن گنجانده شود.
این اعلانهای سیستمی جامع معمولاً چند حوزه کلیدی را پوشش میدهند، از جمله:
دستورالعملهای جستوجو
تعریف ابزارها
ترجیحات کاربر
دستورالعملهای ارجاعدهی
اصلاحات فوری برای مشکلات شناختهشده
در عمل، توسعهدهندگان سامانههای سفارشی هوش مصنوعی هنگام آزمایش و بهبود برنامههایشان، اعلانهای سیستمی را بهصورت دستی و تکرارشونده اصلاح میکنند و عمدتاً از ارزیابیها برای هدایت این فرایند بهره میگیرند.
روشهای دیگر هدایت رفتار مدل عبارتاند از:
مهندسی اعلان، از جمله تولید تقویتشده با بازیابی (RAG)، که محتوای ارائهشده به مدل را کنترل میکند
تنظیم دقیق (تغییر مستقیم وزنهای زیربنایی مدل)
اگر راه دیگری برای تأثیرگذاری بر رفتار مدل وجود داشته باشد چه؟ سامانهای را تصور کنید که با استفاده از افکار، برنامهها و راهبردهای تولیدشده پیشین، اعلان سیستمی خود را بهصورت پویا یاد میگیرد و بهبود میدهد. این سامانه میتواند برای ارزیابی خروجیهای خود هم از بازخورد کاربر و هم از ارزیابیهای الگوهای زبانی بزرگ (LLM) در نقش داور بهره بگیرد.
یک چالش تجاری همیشگی را در نظر بگیرید که میخواهید با سامانهای عاملمحور خودکار کنید. راهکارهای مؤثر به توانایی استدلالی فراتر از خودکارسازی ساده گردشکار نیاز دارند. در چنین مواردی، افزودن مؤلفه تولید برنامه به سامانه هوش مصنوعی ضروری میشود. این کار به سامانه امکان میدهد بسته به وظیفه، به شیوههای گوناگون با چند عامل کار کند. هر مرحله ممکن است شامل دستورالعمل دسترسی به عاملهای دیگر برای انجام وظایف فرعی یا استفاده از ابزارها باشد.
نکته: ابزار عامل هر تابع خارجی، API یا منبعی است که عامل هوش مصنوعی میتواند برای فراتر رفتن از متن و انجام اقدامات واقعی فراخوانی کند.
میتوانید اعلان سیستمی مدل را با برنامهای «بذرگذاری» کنید که مراحل منطقی یک انسان را دنبال میکند؛ هرچند الگوهای زبانی بزرگ (LLM) معمولاً درباره استفاده از ابزار، قالببندی خروجی و الزامات مرتبط به راهنمایی دقیقتری نیاز دارند. گاهی راهبرد بهینه مشخص نیست یا با مسئلهای روبهرو هستید که چون قبلاً حلشده تلقی شده، دوباره بررسی نشده است. اینجاست که یادگیری اعلان سیستمی (SPL) وارد عمل میشود.
SPL با گنجاندن راهبردهای تولیدشده پیشین، اعلان سیستمی را بهصورت تکرارشونده بهبود میدهد. با پدیدارشدن مسائل جدید، سامانه بهتدریج دانش انباشته میکند و مقاومتر میشود. آن را مانند تدوین یک راهنما برای حل مسائل حوزه خود در نظر بگیرید.
SPL بهتدریج بینشهای حاصل از بازخورد کاربر را وارد اعلان سیستمی میکند. با بلوغ سامانه، ممکن است مشکلات تکرارشوندهای بیابید که بتوان آنها را به اصولی کلیتر و سطحبالاتر تبدیل کرد.
بیایید نحوه کار این فرایند را گامبهگام دقیقتر بررسی کنیم:
با پرسش کاربر آغاز کنید و از سامانه بخواهید وظیفه مشخصی را انجام دهد.
اگر سامانه فقط به یک مسئله میپردازد، میتوانید با انتخاب راهبردهای دارای بالاترین امتیاز از اجراهای پیشین، رویکردی «حریصانه» در پیش بگیرید. یا میتوانید با نمونهگیری از توزیعی که راهبردهای پُرامتیاز را ترجیح میدهد، اما گاهی موارد کمامتیاز را هم برمیگزیند، کاوش را تشویق کنید. این روش بهویژه در ابتدای گردآوری راهبردها مفید است.
برای سامانههایی که برای مجموعه مسائل متنوع طراحی شدهاند، افزودن یک لایه طبقهبندی یا استفاده از تعبیهها و شباهت کسینوسی را برای شناسایی رویکردهای مرتبط در نظر بگیرید؛ همان روشهایی که معمولاً در RAG بهکار میروند. این کار به انتخاب راهبردهای متناسب با مسئله خاص کمک میکند؛ برای نمونه، راهبردهای ویژه وظایف برنامهنویسی.
نکته: تعبیهها در ترکیب با شباهت کسینوسی امکان سنجش میزان ارتباط دو قطعه اطلاعات را فراهم میکنند و تطبیق اسناد، پرسشها یا ایدهها را حتی با وجود تفاوت در واژگان دقیقشان آسانتر میسازند.
نمونهای از نقطه شروع یک مخزن راهبرد ساده برای حل مسائل برنامهنویسی.
نکته: «راهبردهای بذر» نمایشدادهشده صرفاً نمونهاند. در سناریوهای واقعی برنامهنویسی، آنها را بیشتر بهبود میدهیم. مسائل تخصصی کسبوکار مستلزم گردآوری بینشهای بیشتر در گذر زمان هستند.
شناسه_نسل (ترتیب معکوس) | موضوع | امتیاز | متن_راهبرد | توضیح |
|---|---|---|---|---|
۴ | برنامهنویسی | ۱ | مسئله، محدودیتها و حالتهای مرزی را درک کنید. الگوریتمی با ساختارهای داده مناسب طراحی کنید. برنامه را با مثالها و ناورداها اعتبارسنجی کنید. کدی تمیز و خوانا پیادهسازی کنید. با بازآرایی، بهینهسازی و قالببندی نهایی، کار را بهبود دهید. استفاده از ابزار: هنگام استفاده از ابزار، مختصر توضیح دهید چرا به آن نیاز داشتید. | بهترین عناصر سه راهبرد زیر را دربرمیگیرد و با هم ترکیب میکند. |
۳ | برنامهنویسی | ۱ | مسئله، محدودیتها و حالتهای مرزی را درک کنید. الگوریتمی با ساختارهای داده مناسب طراحی کنید. برنامه را با مثالها و ناورداها اعتبارسنجی کنید. کدی تمیز و خوانا پیادهسازی کنید. با بازآرایی، بهینهسازی و قالببندی نهایی، کار را بهبود دهید. | راهبردی جامعتر است، اما راهنماییای درباره استفاده از ابزار ندارد. |
۲ | برنامهنویسی | -۱ | مسئله، محدودیتها و حالتهای مرزی را درک کنید. الگوریتمی با دادههای مناسب طراحی کنید. کدی تمیز و خوانا پیادهسازی کنید. استفاده از ابزار: هنگام دسترسی به ابزارها، خلاصهای کوتاه درباره علت استفاده از آن ابزار ارائه دهید. | راهبرد بهتری است که به استفاده از ابزار اشاره میکند، اما همچنان جای بهبود دارد. |
۱ | برنامهنویسی | -۱ | مسئله را سریع مرور کنید. مسئله را حل کنید. آزمونهای حداقلی بسازید. هر چیزی را که اجرا میشود تحویل دهید. | به آزمونها اشاره میکند، اما در مجموع راهبرد ضعیفی است. |
۳. پس از نمونهگیری N مورد، آنها را در اعلان سیستمی بگنجانید. این کار تولید برنامه را بر بازخوردهای تخصصی پیشین استوار میکند، بهجای آنکه مدل با حداقل راهنمایی برنامه بسازد. مدل را تشویق کنید «خارج از چارچوب فکر کند» و در صورت نیاز مراحلی بیفزاید، نه اینکه راهبردهای نمونه را کلمهبهکلمه کپی کند.
۴. با اعلان سیستمی پویای ایجادشده، راهبرد جدیدی برای رسیدگی به درخواست کاربر تولید کنید. این فرایند باید وظایف دیگری ایجاد کند که خروجی نهایی را بهبود دهند. هدف، خلاقیت است: بهترین عناصر راهبردهای پیشین را ترکیب کنید، مراحل همپوشان را یکپارچه سازید و هرجا لازم بود مراحل مفید تازهای بیفزایید.
نکته: به یاد داشته باشید که دما پارامتری قابلتنظیم است که خروجیهایی متنوعتر و کمتر قطعی ایجاد میکند و در موارد نیاز به خلاقیت مفید است. با دمای غیرصفر، هر برنامه تولیدشده ممکن است متفاوت باشد.
۵. پس از دریافت خروجی مدل، آن را با ارزیاب انسانی یا داوری الگوهای زبانی بزرگ (LLM) و براساس معیارهای مشخصی بسنجید که راهحل مناسب مسئله شما را تعریف میکنند. برای نمونه فعالیتهای پرتغال که پیشتر ذکر شد، معیارهای ارزیابی میتوانند شامل موارد زیر باشند:
ایجاز (پاسخی محدود به یک جمله)
مرتبطبودن فعالیت پیشنهادی
دقت مکانی
۶. براساس این ارزیابی، با استفاده از مدلی دیگر راهبرد را بهبود دهید. یک حلقه بازخورد اختیاری میتواند نظر انسان را نیز دربرگیرد و از بهبودهای مشارکتی پشتیبانی کند. راهبرد بهبودیافته را همراه با فراداده مناسب در پایگاه داده ذخیره کنید تا نسخهها و تغییرات قابلردیابی باشند.
اما چرا باید این همه زحمت کشید؟ میتوانید خروجیها را دستی بررسی و اعلان سیستمی را متناسب با آنها تنظیم کنید. بااینحال، مدلهای استدلالی قدرتمند میتوانند با بهرهگیری از زمینه خروجی و بازخورد انسان، راهبردها را بهبود دهند. انسانها ایرادهای رویکردهای ساده را بهآسانی تشخیص میدهند، اما یافتن آنها در سامانههای پیچیدهای که مجموعه مسائل گستردهتری را پوشش میدهند، دشوار و خستهکننده میشود.
الگوهای زبانی بزرگ (LLM) اغلب برای گردآوری دانش زمینهای که انسانها بهطور طبیعی وارد مسئله میکنند، به دستورالعملهای دقیق و مراحل بیشتری نیاز دارند. با گسترش دامنه مسائل سامانه، تعداد وظایف لازم میتواند بهسرعت افزایش یابد. برای مثال، انسانها هنگام حل مسائل برنامهنویسی ممکن است ساختار کلی کد را بهصورت شهودی درک کنند، اما الگوی زبانی بزرگ (LLM) شاید ابتدا ناچار باشد چندین فایل را «بخواند».
زمانی که مفید است: فرض کنید تیم پشتیبانی مشتریان را مدیریت میکنید و یک عامل هوش مصنوعی دستهبندی اولیه تیکتها را انجام میدهد. SPL ممکن است بهمرور روشی برای دستهبندی بیابد که تیم شما در نظر نگرفته بود و نرخ ارجاع به سطوح بالاتر را کاهش دهد.
زمانی که مفید نیست: اگر الزامات انطباق یا مقررات، گردشکار شما را از پیش تعیین کرده باشند، مانند گزارشگری مالی، SPL ارزش چندانی ندارد؛ زیرا خلاقیت بهجای مزیت به مخاطره تبدیل میشود.
زمانی که مفید است: در نقشهای پژوهشمحور، مانند تحلیل بازار یا راهبرد محصول، میتوانید با اصلاح برنامههای هوش مصنوعی، غنیسازی خروجی آن و ثبت این بهبودها برای استفاده آینده، با آن همکاری کنید. هر تعامل، اثربخشی سامانه را افزایش میدهد.
زمانی که مفید نیست: اگر تیم شما عمدتاً از هوش مصنوعی برای گردشکارهای سادهای با حداقل دخالت انسان، مانند پردازش صورتحساب، استفاده میکند، سربار همکاری ممکن است از مزایای آن بیشتر شود.
زمانی که مفید است: فرض کنید فعالیت خود را به منطقهای جدید گسترش میدهید و هوش مصنوعی ناگهان باید به پرسشهای مالیاتی محلی پاسخ دهد. SPL به شما امکان میدهد قواعد و روشهای اکتشافی جدید را همزمان با ظهورشان بهسرعت ثبت کنید و از تکرار خطاها جلوگیری کنید.
زمانی که مفید نیست: اگر محیط شما ثابت است، مثلاً رونوشت جلسات را به خلاصههای استاندارد تبدیل میکنید، سازگاری مداوم فایده چندانی ندارد.
در نظریه همه اینها امیدوارکننده به نظر میرسد، اما پیادهسازی SPL چالشهای واقعی دارد. در ادامه به برخی از مهمترین آنها میپردازیم:
در مراحل ابتدایی تولید راهبرد، پیشرفت اغلب متوقف میشود: خروجیهای جدید بر خروجیهای قبلی بنا نمیشوند و شتاب کار کاهش مییابد. این وضعیت معمولاً دو علت اصلی دارد:
راهحل: همه دانش تجاری موجود را از همان ابتدا ثبت کنید تا سامانه پشتوانه عمیقی برای استفاده داشته باشد.
راهحل: معیارنامهای دقیق طراحی کنید که جنبههای مختلف پاسخ، مانند دقت، وضوح و ارتباط را امتیازدهی کند و نمونهگیری را متناسب با این نشانهها تنظیم کنید.
اگر سامانه صدها راهبرد تولید کند، اما برای تشخیص خوب از بد بازخورد اندکی بگیرد، نمونهگیری بهسرعت مهارنشدنی میشود. راهحل، هرسکردن است.
هنگام پالایش مخزن راهبردها، این موارد را در نظر بگیرید:
طول عمر: راهبردها را پس از گذشت بازه زمانی یا تعداد نسلهای تعیینشده کنار بگذارید.
امتیاز: با استفاده از معیارنامه ارزیابی، راهبردهایی را که پیوسته عملکرد ضعیفی دارند حذف کنید. ترکیب این روش با طول عمر تضمین میکند فقط رویکردهایی حفظ شوند که ارزش خود را در گذر زمان ثابت کردهاند.
داوری الگوهای زبانی بزرگ (LLM): راهبردها را دورهای ارزیابی کنید تا مواردی را بیابید که دیگر بینش منحصربهفردی نمیافزایند؛ زیرا احتمالاً عناصر مفیدشان در نسخههای جدیدتر جذب شده است.
راهحل: پایگاه داده راهبردها را سامانهای زنده در نظر بگیرید و مرتب هرس کنید تا فقط دانش مرتبط و ارزشمند باقی بماند.
یادگیری اعلان سیستمی هنوز در آغاز راه است، اما ظرفیت عظیمی دارد. کسبوکارهایی که فقط به اعلانهای ثابت یا تنظیم دقیق بیپایان متکیاند، با محدودیتهای آشنا روبهرو میشوند: سامانههای شکننده، هزینههای فزاینده و تلاشهای هدررفته. SPL با ساخت سامانههایی که بهمرور بهتر میشوند و بهجای اصلاحات پراکنده، اصول سطحبالاتر را ثبت میکنند، راهی برای خروج از این چرخه ارائه میدهد.
SPL همچنان در حال شکلگیری است، اما مسیر آن روشن است: سامانههایی که میتوانند از خود بیاموزند، از سامانههای ناتوان در این کار پیشی خواهند گرفت. اکنون زمان آزمایش است: از مقیاسی کوچک آغاز کنید، آموختهها را ثبت کنید و پایه سامانههای هوش مصنوعیای را بسازید که با هر تعامل بهتر میشوند.