پیام سیستمی

برگه‌ی شرح وظایف

قبل از اینکه شما چیزی بگید، یکی به مدل گفته «تو کی هستی و چطور حرف بزنی». به اون می‌گن پیام سیستمی.

توی درس نقش‌ها در گفت‌وگو دیدیم گفت‌وگو سه نقش داره، و نقش «سیستم» اول از همه میاد. مستندات Claude هم می‌گه دستورهای سیستمی معمولا پیش از همه‌ی پیام‌های گفت‌وگو قرار می‌گیرن.

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

یه جمله، یه نقش

ساده‌ترین و موثرترین کار با پیام سیستمی، دادن یه نقش به مدله.

مستندات Claude می‌گه دادن نقش توی پیام سیستمی، رفتار و لحن مدل رو برای کار شما متمرکز می‌کنه، و حتی یه جمله فرق ایجاد می‌کنه. یه جای دیگه هم همین مستندات، نقش دادن رو موثرترین شکل استفاده از پیام سیستمی می‌دونه.

دلیلش رو از درس‌های قبل می‌دونیم: مدل همیشه محتمل‌ترین ادامه‌ی متن رو می‌سازه. وقتی اول متن نوشته «تو مشاور تغذیه‌ی کودکی»، ادامه‌ای که به این نقش می‌خوره، محتمل‌تر می‌شه. نقش، مدل رو می‌بره سمت یه گوشه‌ی مشخص از همه‌ی چیزهایی که بلده.

اپ‌ها هم دارن

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

Anthropic خودش می‌گه رابط وب و اپ‌های موبایل Claude یه پیام سیستمی دارن که اول هر گفت‌وگو اطلاعات به‌روز، مثل تاریخ امروز، رو به مدل می‌ده، و رفتارهایی مثل نوشتن کد توی قالب مشخص رو تشویق می‌کنه. این پیام گاه‌به‌گاه به‌روز می‌شه و متنش رو هم منتشر می‌کنن. یادتونه از درس تاریخ برش دانش که مدل خودش امروز رو نمی‌دونه؟ یکی از کارهای همین پیام سیستمی، گفتن تاریخ امروزه.

پیام سیستمی خوب

اگه خودتون یه چت‌بات می‌سازید، یا یه ابزاری دارید که اجازه می‌ده دستور ثابت بنویسید، چطور بنویسیدش؟

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

یه نمونه، تکه‌تکه

بیاید یه پیام سیستمی ساختگی برای یه نونوایی ببینیم که بخش‌هاش جدا شدن.

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

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

جای رمز نیست

چون کاربر پیام سیستمی رو نمی‌بینه، شاید وسوسه بشید چیزهای محرمانه رو اونجا بذارید. نکنید.

پیام سیستمی هم بخشی از همون متنیه که مدل می‌خونه، و یه کاربر زرنگ ممکنه با درخواست‌های مختلف کاری کنه که مدل بخشی از اون رو تکرار کنه. مستندات Claude به این می‌گه «لو رفتن درخواست» و صاف می‌گه هیچ روشی کامل جلوش رو نمی‌گیره. پس رمز، کلید، و هر چیزی که نباید دیده بشه، جاش توی پیام سیستمی نیست.

وسط گفت‌وگو

پیام سیستمی معمولا یه بار، اول کار میاد. ولی گاهی وسط گفت‌وگو یه دستور تازه لازم می‌شه.

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

چند نکته

• اول یه نقش بدید. حتی یه جمله.
• روشن و صریح بنویسید. مثل برای یه همکار تازه.
• دلیل هر دستور رو بگید. مدل بهتر می‌فهمه.
• رمز و کلید نه. پیام سیستمی ممکنه لو بره.
• اپ‌ها هم پیام سیستمی دارن. مثلا برای گفتن تاریخ امروز.

درس بعد می‌ره سراغ مرحله‌ی بعد از تنظیم با دستور: یاد گرفتن از سلیقه‌ی آدم‌ها، RLHF: یادگیری تقویتی با بازخورد انسانی.