تکنیک های پیشرفته پرامپت

این پنج پله چه هستند و پله بالاتر یعنی چه

هر پنج تکنیکی که در این درس می آید یک کار می کنند: چیزی به پرامپت اضافه می کنند که قبلا نبود. بدون نمونه یعنی فقط می پرسید. با نمونه یعنی چند مثال از ورودی و خروجی درست را هم می گذارید. زنجیره فکر یعنی می خواهید قبل از جواب، مراحل رسیدن به آن را بنویسد. خروجی ساختاریافته یعنی شکل جواب را طوری تعیین می کنید که یک برنامه بتواند بخواندش. پرامپت سیستمی یعنی قانون هایی که به همه پیام ها اعمال می شود و هر بار تکرارشان نمی کنید.

حالا نکته ای که در بیشتر آموزش ها گم می شود: این نردبان کیفیت نیست. پله بالاتر جواب بهتری نمی دهد، فقط پرامپت بزرگ تری می سازد. هر پله ای که بالا می روید سه چیز اضافه می کنید: توکن، تاخیر، و یک چیز دیگر که می تواند خراب باشد. نمونه ای که با قانون هایتان تناقض دارد بدتر از نداشتن نمونه است.

پس قاعده عملی این است: از پله اول شروع کنید و فقط وقتی بالا بروید که خروجی نشانتان داده کجا کم آورده. چهار پرامپت از پنج پرامپت کاری واقعی، همان پله اول باقی می مانند و این نشانه مبتدی بودن نیست.

نمونه دادن؛ چند تا کافی است و کجا برعکس عمل می کند

اصطلاح few-shot از مقاله ۲۰۲۰ اوپن ای آی با عنوان «مدل های زبانی یادگیرنده های چند نمونه ای هستند» آمده و ایده اش ساده است: به جای توضیح دادن کار، چند مثال از آن نشان بدهید. برای کارهایی که شکلشان راحت تر از توضیحشان دیده می شود، این پله واقعا جواب می دهد؛ دسته بندی، لحن، و هر قالبی که وسواس دارد.

یک مثال واقعی. فرض کنید پیام های ورودی مشتری ها را می خواهید به چهار دسته تقسیم کنید. بدون نمونه، پرامپت می گوید «این پیام را در یکی از این چهار دسته بگذار» و مدل بیشترشان را درست می زند و سر پیام های مرزی سلیقه ای عمل می کند. با نمونه، همان پیام های مرزی را خودتان انتخاب می کنید:

پیام: سلام، سفارش ۱۲۳ رو دیروز گرفتم ولی جعبه ضربه دیده بود. داخلش سالمه.
دسته: شکایت

پیام: می شه بگید سفارش ۱۲۳ کی می رسه؟
دسته: پیگیری

پیام: سلام. سه تا از همون قبلی می خوام.
دسته: سفارش

ارزش این سه خط در چیزی است که نمی شد نوشتش: اینکه «جعبه ضربه دیده ولی کالا سالم است» باز هم شکایت حساب می شود، تصمیم شماست و نه یک قانون عمومی. نمونه ها همان تصمیم های مرزی را منتقل می کنند.

درباره تعداد، عدد جادویی وجود ندارد و هر کسی عددی به شما بگوید دارد حدس می زند. راهنمای خود اوپن ای آی برای مدل های استدلالی می گوید اول بدون نمونه امتحان کنید و فقط اگر لازم شد نمونه اضافه کنید، و همان جا هشدار می دهد که نمونه ها باید کاملا با دستورها هم خوان باشند، چون ناسازگاری بین این دو خروجی را بد می کند.

سه جایی که نمونه دادن برعکس عمل می کند: وقتی همه نمونه ها از یک دسته اند و مدل همان توزیع را کپی می کند؛ وقتی نمونه ای با یکی از قانون های خودتان تناقض دارد و مدل نمونه را باور می کند نه قانون را؛ و وقتی نمونه ها از داده واقعی مشتری برداشته شده اند، چون آن داده از این به بعد در هر بار اجرا فرستاده می شود.

زنجیره فکر از کجا آمد و چرا امروز کمتر لازم است

ژانویه ۲۰۲۲، مقاله ای از پژوهشگران گوگل با عنوان «پرامپت زنجیره فکر، استدلال را در مدل های زبانی بزرگ فرا می خواند» منتشر شد. حرفش این بود که اگر در نمونه ها مراحل میانی رسیدن به جواب را هم نشان بدهید، مدل های به اندازه کافی بزرگ روی مسئله های حساب و منطق بهتر عمل می کنند. از همان مقاله بود که «قدم به قدم فکر کن» به همه آموزش ها راه پیدا کرد.

حالا نزدیک پنج سال بعد، راهنمای خود سازنده ها چیز دیگری می گوید. صفحه اوپن ای آی درباره بهترین روش کار با مدل های استدلالی می نویسد پرامپت ها را ساده و مستقیم نگه دارید و از پرامپت زنجیره فکر پرهیز کنید، چون این مدل ها استدلال را داخل خودشان انجام می دهند و گفتن «قدم به قدم فکر کن» لازم نیست. مستندات انتروپیک هم درباره حالت تفکر گسترده می گوید دستور کلی را به مراحل تجویزی ترجیح بدهید: جمله ای مثل «کامل فکر کن» اغلب نتیجه بهتری می دهد تا یک نقشه قدم به قدمی که خودتان نوشته اید.

پس تکنیک غلط نشده؛ جایش عوض شده. رفته داخل مدل. دو جا هنوز به دردتان می خورد: روی مدل های کوچک تر و قدیمی تر که استدلال درونی ندارند، و وقتی می خواهید مراحل را ببینید تا بتوانید ایراد بگیرید. دومی دلیل خوبی است و دلیلش کیفیت جواب نیست، بازرسی است.

و یک هشدار که کمتر جایی می خوانید: متن مراحلی که مدل چاپ می کند، گزارش چیزی که واقعا داخلش گذشته نیست. آن هم متنی است که مثل بقیه متن تولید شده. می شود جوابی درست باشد و مراحلش بی ربط، یا مراحل قانع کننده باشند و جواب غلط. آن را توضیحی بدانید که به شما پیشنهاد شده، نه رسیدی که مهر خورده. این موضع ماست و از همان مکانیزمی می آید که در درس مدل زبانی بزرگ توضیح داده ایم.

تاریخ بالای این صفحه را جدی بگیرید. راهنمای سازنده ها دقیقا همان چیزی است که در این حوزه سریع عوض می شود، و این بند از همان جنس ادعاهایی است که ممکن است سال بعد نصفش درست نباشد.

خروجی ساختاریافته؛ وقتی جواب باید وارد یک برنامه شود

این تنها پله ای است که در کار واقعی تقریبا همیشه هزینه اش را در می آورد، و دلیلش هم کیفیت متن نیست: جوابی که شکل ثابت دارد را می شود ماشینی چک کرد. تا وقتی خروجی یک پاراگراف روان است، تنها راه سنجیدنش خواندن آن است. وقتی خروجی یک ردیف با کلیدهای مشخص است، پنج خط کد به شما می گوید کدام ردیف خراب است.

دو راه برای گرفتنش هست و فرقشان مهم است. راه اول این است که در پرامپت شکل را بخواهید و امیدوار باشید. راه دوم استفاده از حالتی است که خود سازنده ها ساخته اند و خروجی را به یک شمای مشخص مقید می کند؛ انتروپیک و گوگل هر دو برای این کار مستندات جدا دارند. اگر از طریق ای پی آی کار می کنید، راه دوم را انتخاب کنید. اگر در پنجره گفتگو کار می کنید، راه اول تنها گزینه است و آن وقت چک کردن خروجی تنها تضمین شماست.

یک تله که مخصوص فارسی زبان هاست و در هیچ مستند انگلیسی پیدا نمی کنید: اگر در قانون های پرامپت با عدد فارسی بنویسید «عددی بین ۱ تا ۳»، احتمال دارد مدل هم عدد فارسی برگرداند و آن وقت خروجی دیگر JSON معتبر نیست، چون JSON فقط رقم لاتین می پذیرد. راه حلش یک جمله است: در همان قانون بنویسید ارقام لاتین باشند. ما این را در نسخه آماده پایین گذاشته ایم.

و یک عادت که ارزشش از خود شما به تکنیک بیشتر است: اجازه ندهید یک خروجی ساختاریافته مستقیم کاری را انجام دهد که برگرداندنش سخت است. ایمیل فرستادن به مشتری، ثبت مرجوعی، تغییر قیمت. بین خروجی و آن کار یک آدم بگذارید، دست کم تا وقتی روی صد ردیف واقعی امتحانش کرده باشید.

پرامپت سیستمی؛ قانون هایی که هر بار تکرار نمی کنید

پرامپت سیستمی جایی است که قانون های ثابت کارتان می نشینند و به همه پیام های آن گفتگو اعمال می شوند. در ای پی آی این یک پارامتر جداست و مستندات انتروپیک برایش صفحه اختصاصی دارد. در محصولات گفتگویی، همان چیزی است که با اسم هایی مثل دستور سفارشی یا دستور پروژه می بینید.

چه چیزی آنجا می نشیند: اینکه شما کی هستید و برای چه کسی می نویسید، محدودیت های همیشگی، و قراردادهای خروجی مثل اینکه هیچ وقت فهرست گلوله ای نمی خواهید. چه چیزی آنجا نمی نشیند: جزئیات یک کار مشخص، هر چیزی که هر بار عوض می شود، و بدیهی است که هیچ رمز و کلیدی.

یک نکته که در بیشتر آموزش ها نیست: پرامپت سیستمی مرز امنیتی نیست. یک قانون است که مدل معمولا رعایتش می کند، نه دیواری که چیزی از آن رد نمی شود. متنی که در پیام بعدی می چسبانید، مثلا محتوای یک صفحه وب یا یک پیام مشتری، می تواند دستوری داخل خودش داشته باشد که با قانون های شما مخالف است. این همان چیزی است که در بلاک پایین همین صفحه با اسم درست خودش آمده.

کجا این تکنیک ها را نگذارید

چهار حالت هست که در آنها بالا رفتن از نردبان فقط هزینه است. اول کار یک باره: چیزی که یک بار انجامش می دهید ارزش ساختن نمونه و شما و پرامپت سیستمی را ندارد؛ بپرسید، جواب را بخوانید، تمام. دوم وقتی مشکل، نبود اطلاعات است: اگر جواب درست به داده ای نیاز دارد که مدل ندارد، هیچ پله ای آن را نمی سازد و راه حل دادن همان داده است.

سوم وقتی خروجی برای یک آدم است و نه یک برنامه. خروجی ساختاریافته آنجا فقط اصطکاک اضافه می کند و متن را خشک تر می کند. چهارم و مهم تر از همه: وقتی هیچ راهی برای چک کردن نتیجه ندارید. تکنیک بیشتر، جواب غلط را مطمئن تر و منظم تر جلوه می دهد و همین آن را خطرناک تر می کند. اگر نمی توانید بگویید یک خروجی درست چه شکلی است، اول آن را حل کنید.

یک جمع بندی که ارزش تکرار دارد: بین این پنج پله، آن که بیشترین بازده را در کار روزمره دارد خروجی ساختاریافته است، چون تنها پله ای است که کیفیت را قابل سنجش می کند. بقیه پله ها کیفیت را عوض می کنند و سنجش را نه.