سود:
- می تواند طراحی کند که چگونه اعلان سیستم مدل را در کل مکالمه هدایت می کند
- نقش و تأثیر هزینه پارامترهای تفکر انطباقی و تلاش را درک می کند
- کنترلهای خروجی مانند max_tokens، توالی توقف و خروجی ساختاریافته را پیادهسازی میکند
دو محصول مختلف از یک مدل ممکن است کاملاً متفاوت رفتار کنند. تفاوت در خود مدل نیست، بلکه در فرمان سیستم و پارامترهای داده شده به آن است. اعلان سیستم «قرارداد کاری» مدل و پارامترها «تنظیمات کاری» هستند. در این بخش، شما یاد خواهید گرفت که چگونه یک سیستم اعلان قدرتمند طراحی کنید، تنظیمات تفکر و تلاش در مدل های مدرن چه کاری انجام می دهند، و چگونه خروجی را برای فرمت/طول کنترل کنید. تنظیم صحیح این تنظیمات به شما امکان می دهد همزمان کیفیت و هزینه را مدیریت کنید.
اعلان سیستم: دستورالعمل دائمی مدل
اعلان سیستم دستورالعمل سطح بالایی است که در کل مکالمه اعمال می شود. این قوانین بدون توجه به نوع نوع کاربر معتبر باقی می مانند. یک سیستم اعلان خوب شامل اجزای زیر است:
- نقش/هویت: مدل کیست؟ ("شما یک دستیار پشتیبانی شرکت هستید.")
- محدوده و مرز: چه کاری انجام می دهد و چه کاری انجام نمی دهد؟ ("فقط بر اساس سند خط مشی ارائه شده.")
- قوانین قالب: خروجی باید چگونه باشد؟ ("حداکثر 3 مقاله، زبان رسمی.")
- رفتار در عدم قطعیت: وقتی فرد مطمئن نیست چه می کند؟ (در صورت عدم وجود اطلاعات، آن را به واحد مربوطه هدایت کنید.)
- امنیت/حریم خصوصی: چه چیزی نمی خواهد/نمی خواهد؟ ("درخواست اطلاعات شخصی.")
نکته: اعلان سیستم را ثابت نگه دارید. اطلاعاتی را که با هر درخواست تغییر می کند (تاریخ فعلی، نام کاربری، شناسه جلسه) جاسازی نکنید. این امر هم سازگاری را از بین می برد و هم حافظه پنهان اعلان را در واحد 6 باطل می کند. اطلاعات متغیر را در پیام کاربر قرار دهید.
تله دستورالعمل بیش از حد تهاجمی
مدل های مدرن از دستورالعمل ها بسیار دقیق پیروی می کنند. عبارات تهاجمی مانند "باید"، "همیشه"، "قطعاً این کار را انجام دهید"، و غیره، که در مدلهای قدیمیتر کار میکردند، امروزه منجر به تحریک بیشازحد میشوند: مدل زمانی یک عامل را فراخوانی میکند که نیازی به آن نباشد یا برای مدت طولانی غیرضروری اجرا شود. نرم کردن قانون: به جای "باید از ابزار جستجو استفاده کنید"، "اگر پاسخ در گفتگو نیست، از ابزار جستجو استفاده کنید" دقیق تر است.
پارامترهای مدل: فکر و تلاش
LLMهای کلاسیک دارای یک پارامتر دما بودند: یک مقدار کمتر خروجی خاص/منطبقتری ایجاد میکرد، یک مقدار بالاتر خروجی متنوع/خلاقتری ایجاد میکرد. مدل های نسل مدرن (مانند Opus 4.8، Sonnet 5) این رویکرد را با دو مکانیسم قدرتمندتر جایگزین می کنند و دیگر پارامترهای نمونه برداری مانند دما را نمی پذیرند.
- تفکر انطباقی: مدل قبل از پاسخ دادن، قدم به قدم در "سر" خود دلیل می کند. مدل بر اساس سختی کار تصمیم می گیرد که چقدر فکر کند. به طور قابل توجهی دقت را در مسائل پیچیده و چند مرحله ای بهبود می بخشد. او کمتر فکر می کند تا از تأخیر بی مورد در سؤالات ساده جلوگیری کند.
- تلاش: دستگیره سطح بالا که میزان عمق فرورفتن مدل در یک کار و تعداد توکنهایی را که در کل خرج میکند را تنظیم میکند. سطوح معمولی: کم، متوسط، زیاد و بالاتر. تلاش زیاد ممکن است کیفیت را بهبود بخشد، اما تاخیر و هزینه را نیز افزایش می دهد. تلاش کم باعث سرعت و صرفه جویی می شود.
تنظیم
چه می کند
چه زمانی
فکر کردن / تلاش کم
سریع، ارزان، سطحی
طبقه بندی ساده، پاسخ کوتاه، تاخیر در کارهای حساس
تفکر انطباقی + تلاش متوسط
کیفیت / هزینه متوازن
اکثر وظایف با هدف عمومی
تفکر انطباقی + تلاش زیاد
بالاترین دقت
استدلال پیچیده، کدنویسی، کار عامل دوربرد
احتیاط: رفلکس "حداکثر تلاش مهم نیست" هزینه ها را افزایش می دهد. تلاش را به وظیفه تنظیم کنید؛ در کارهای ساده، تلاش کم اغلب همان نتیجه دقیق را با قیمت بسیار ارزانتری میدهد. جایی که به دقت حیاتی نیاز است، به اوج بروید.
کنترل خروجی: فرمت، طول، ساختار
علاوه بر پارامترها، شما خود خروجی را نیز کنترل می کنید:
- max_tokens: سقف سخت خروجی (واحد 1 و 3).
- Stop sequences: توقف مدل زمانی که رشته خاصی را می بیند. برای تعیین نقاط شکست در تولید ساخت یافته مفید است.
- خروجی ساختاریافته: پاسخ مدل را مجبور کنید تا با طرح JSON که ارائه میکنید مطابقت داشته باشد. این تضمین می کند که خروجی از نظر برنامه ریزی قابل تجزیه و معتبر است. این قابل اعتمادتر از گفتن "فقط JSON را با یک اعلان برگردانید" است.
{ "output_config": { "format": { "type": "json_schema"، "schema": { "type": "object"، "additionalProperties": false، "properties": { "category": { "type": "string"، "enum": ["invoice", "Technical"، ":"] "نوع": "رشته"، "enum": ["کم"، "متوسط"، "بالا"] } }، "لازم": ["رده"، "اضطرار"] } } }}
الگوهای درخواست سیستم قابل کپی
# دستیار پشتیبانی شرکت شما یک دستیار پشتیبانی شرکتی هستید.- فقط به سند خط مشی ارائه شده تکیه کنید. اگر در سند نیست، بگویید «این اطلاعات را ندارم». - حداکثر در 3 جمله پاسخ رسمی و واضح بدهید. - اطلاعات شخصی (شماره شناسه TC، شماره کارت) را بخواهید و آن را در پاسخ خود تکرار نکنید. - اگر مطمئن نیستید، حدس نزنید.
# طبقه بندی کننده اجباری خروجی ساختاریافته شما یک طبقه بندی کننده تقاضا هستید. ورودی پیام مشتری است. فقط فیلدهای درخواستی را برگردانید، نظر ننویسید. اگر مطمئن نیستید، از "دیگر" استفاده کنید.
# تحلیلگر با رفتار تعریف شده ایستادن در عدم قطعیت شما یک تحلیلگر داده هستید. از جدول ارائه شده فقط استنباط های قابل تأیید بگیرید. هرگز نتیجهگیری نکنید که در دادهها وجود ندارد. اگر استنباط نامشخص است، بنویسید «داده کافی نیست».
# نویسنده محتوا با کنترل لحن و طول شما یک نویسنده محتوا هستید. از لحن گرم اما حرفه ای استفاده کنید. هر متن را به 120 کلمه یا کمتر محدود کنید. از زبان بازاریابی کلیشه ای خودداری کنید.
اعلان ضعیف / اعلان قوی
# ضعیف مفید باشید و پاسخ های خوبی بدهید. تمام تلاش خود را بکنید.
# STRONGنقش: متخصص پشتیبانی فنی. دامنه: راهنمای محصول فقط ارائه شده است. قالب: گام به گام، فهرست شماره گذاری شده، حداکثر 5 مرحله. محدودیت: راه حل پیشنهادی در راهنما نیست. بگویید "من نتوانستم آن را در دفترچه راهنما پیدا کنم." حریم خصوصی: از تکرار شماره سریال به اشتراک گذاشته شده توسط کاربر در پاسخ خودداری کنید.
نسخه قدرتمند؛ نقش، محدوده، قالب، مرزها و محرمانه بودن را به طور جداگانه تعیین می کند. سازگاری خروجی مستقیماً از این وضوح ناشی می شود.
سه کیف کوچک
مورد 1 - کاهش هزینه از طریق تعدیل تلاش. یک تیم تمام تماس های خود را با تلاش زیاد + تفکر انجام می داد. حتی خلاصه های ساده ایمیل گران و دیر تولید می شدند. آنها وظایف ساده ای مانند خلاصه به تلاش کم و تجزیه و تحلیل قرارداد به تلاش زیاد اختصاص دادند. دقت حفظ شد، متوسط تأخیر به نصف کاهش یافت و هزینه ماهانه یک سوم کاهش یافت.
مورد 2 - ضمانت JSON. یک تیم عملیاتی خروجی طبقهبندی را با عبارت «فقط به JSON بدهید» درخواست کرد، اما مدل گهگاه مینویسد «نتیجه اینجاست:» و تجزیهکننده خراب میشود. وقتی طرح خروجی پیکربندی شده را وصل کردم، خروجی هر بار JSON معتبر را برمیگرداند. خطاهای تجزیه بازنشانی شده است.
مورد 3 - پس زدن سریع تهاجمی. یک دستیار گفت: "باید هر سوالی را جستجو کرد". این مدل حتی برای سؤالات ساده ای که پاسخ آنها را قبلاً می دانست، جستجوهای غیرضروری انجام می داد و باعث کاهش سرعت و افزایش هزینه ها می شد. آنها قانون را به "اگر پاسخ در متن نیست، جستجو کنید" را کاهش دادند. تماس های غیر ضروری 70 درصد کاهش یافت و پاسخ ها تسریع شد.
اشتباهات رایج
- جاسازی داده های متغیر در اعلان سیستم: سازگاری را از بین می برد و حافظه پنهان را باطل می کند.
- دستورالعمل بیش از حد تهاجمی: تحریک بیش از حد و هزینه غیر ضروری در مدل های مدرن.
- تلاش زیاد در هر کار: اتلاف در کارهای ساده. تلاش را به وظیفه تنظیم کنید
- درخواست JSON فقط از طریق prompt: گاهی اوقات خراب می شود. اگر حیاتی است، از خروجی ساخت یافته استفاده کنید.
- عدم تعریف رفتار مرزی/ابهامی: مدل شکاف را با ساختگی پر می کند (توهم).
- عادت قدیمی "دما": مدل های مدرن این را نمی پذیرند. رفتار را با سریع و تلاش هدایت کنید.
عمیق تر: نوشتن درخواست مانند یک قرارداد
تیمهای باتجربه با دستورات سیستم مانند یک قرارداد رفتار میکنند، نه یک متن ادبی: بندهای واضح، قوانین قابل اندازهگیری، مرزهای بدون ابهام. این رویکرد سه مزیت مشخص دارد. اولین مورد سازگاری است: ورودی یکسان در زمان های مختلف خروجی مشابهی می دهد. دوم تست پذیری است: می توانید هر مورد را به طور جداگانه با یک نمونه آزمایش کنید. سوم، سهولت نگهداری است: اگر رفتاری اشتباه است، می دانید که کدام مورد را جایگزین کنید.
یک تمرین خوب این است که با مثال های مثبت رهبری کنید. به جای ارائه فهرستی از «این کار را نکنید»، در مدلهای مدرن ارائه مثالی که میگوید «خروجی مورد نظر دقیقاً به این شکل است» بسیار مؤثرتر است. به عنوان مثال، در یک طبقهبندی، افزودن یک یا دو نمونه از JSON مورد انتظار به درخواست، خطاهای قالببندی را به میزان قابل توجهی کاهش میدهد.
یکی دیگر از تکنیک های قدرتمند نوشتن رفتار عدم قطعیت به صراحت است. عبارتی مانند «اگر مطمئن نیستید، حدس نزنید؛ بگویید «دادههای ناکافی»» تمایل مدل را برای پر کردن جای خالی با ساختگی (توهم) سرکوب میکند. این جمله واحد لایه تأیید را تخلیه می کند، که در واحد 11 پوشش خواهیم داد: زمانی که مدل قبلاً عدم قطعیت را علامت گذاری کرده است، منجر به تأیید اعتبار انسانی آسان تر می شود.
در نهایت، تلاش و سریع را با هم در نظر بگیرید. با تلاش زیاد، مدل بیشتر کاوش می کند و گاهی اوقات "کار اضافی" ناخواسته انجام می دهد (توضیحات غیر ضروری، پیشنهاد اضافی). گفتن "فقط خروجی دلخواه را بدهید، نظرات اضافی اضافه نکنید" در اعلان، این عارضه جانبی تلاش زیاد را خنثی می کند.
به طور خلاصه
اعلان سیستم دستور دائمی مدل است: نقش، محدوده، قالب، رفتار مبهم و محرمانه بودن را تعریف می کند. در مدلهای مدرن، رفتار توسط پارامترهای تفکر و تلاش تطبیقی به جای دما هدایت میشود. هماهنگی تلاش با کار، کیفیت و هزینه را به طور همزمان مدیریت می کند. خروجی را با max_tokens، توقف آرایه ها و خروجی ساختاریافته ایمن می کنید.
وظیفه کاربردی
یک کار را انتخاب کنید. (1) یک دستور سیستم با پنج جزء (نقش، دامنه، قالب، ابهام، محرمانه) بنویسید. (2) بیان کنید که چه سطحی از تلاش را برای این کار انتخاب می کنید و چرا. (3) اگر خروجی باید ساختاری باشد، یک طرح کوچک JSON را ترسیم کنید. (4) بررسی کنید که آیا یک الگوی بیش از حد تهاجمی در دستور شما وجود دارد و آن را نرم کنید.
چک لیست
- [ ] من می توانم پنج جزء از یک دستور سیستم خوب را نام ببرم.
- [ ] می توانم توضیح دهم که پارامترهای تفکر انطباقی و تلاش چه می کنند.
- [ ] می توانم کیفیت/هزینه را با تنظیم تلاش بر اساس وظیفه متعادل کنم.
- [ ] من می دانم که چرا خروجی ساختاریافته ایمن تر از درخواست JSON از طریق درخواست است.
- [ ] من می توانم خطر را در مدل های مدرن دستورالعمل های بیش از حد تهاجمی تشخیص دهم.