زنجیره‌سازی پرامپت‌ها
Prompt Chaining
موارد استفاده از زنجیره‌ای کردن پرامپت‌ها
یکی از تکنیک‌های مهم در مهندسی پرامپت برای بهتر کردن عملکرد و اطمینان از دقت مدل‌های زبانی بزرگ (LLM) اینه که کارها رو به ریزکارها تقسیم کنیم. وقتی که این ریزکارها مشخص شدن، از مدل با یکی از زیرکارها سوال می‌پرسیم و بعد پاسخ اون رو به عنوان ورودی برای پرامپت بعدی استفاده می‌کنیم. به این کار “زنجیره‌سازی پرامپت‌ها” می‌گن، جایی که یک کار به زیرکارها تقسیم می‌شه تا یک زنجیره از پرسش ایجاد بشه.
زنجیره‌سازی پرامپت‌ها (Prompt Chaining) به ما کمک می‌کند تا کارهای پیچیده‌ای را انجام دهیم که ممکن است یک مدل زبان بزرگ (LLM) نتواند به راحتی با یک درخواست خیلی جزئی به آنها پاسخ بدهد. در این روش، پرامپت‌ها به صورت زنجیره‌ای به هم متصل می‌شوند و هر کدام وظیفه‌ای روی پاسخ‌های تولید شده انجام می‌دهد تا به حالت نهایی مطلوب برسیم.
علاوه بر این که با زنجیره‌سازی درخواست‌ها عملکرد بهتری کسب می‌کنیم، این روش باعث می‌شود تا برنامه‌مون بهتر قابل فهم و کنترل باشد و اطمینان بیشتری به آن داشته باشیم. این یعنی می‌توانیم راحت‌تر مشکلات پاسخ‌های مدل را بررسی کنیم و عملکرد آن را در مراحل مختلفی که نیاز به بهبود دارند، تحلیل و بهبود ببخشیم.
زنجیره‌ای سازی پرامپت‌ها (Prompt Chaining) وقتی که می‌خواهید دستیارهای گفتگو محور با استفاده از مدل‌های زبان بزرگ بسازید، خیلی به درد می‌خوره و کمک می‌کنه تا شخصی‌سازی و تجربه کاربری برنامه‌هایتان بهتر بشه.
زنجیره‌ای سازی پرامپت‌ها از متن‌های سوال و جواب
زنجیره‌سازی پرامپت‌ها (Prompt chaining) می‌تونه در موقعیت‌های مختلفی به کار بره که شامل چند عملیات یا تغییرات باشه. مثلاً، یکی از کاربردهای معروف مدل‌های زبانی بزرگ (LLM) پاسخ دادن به سوالات مربوط به یک متن بزرگه. بهتره که دو تا پرامپت متفاوت طراحی کنی؛ پرامپت اول مسئول استخراج جملات مرتبط برای پاسخ دادن به سواله و پرامپت دوم، جملات و سند اصلی رو به عنوان ورودی می‌گیره تا به سوال پاسخ بده. به عبارت دیگه، دو تا درخواست متفاوت درست می‌کنی تا کار پاسخ دادن به سوالی که در یک سند هست رو انجام بدی.
برای مثال پرامپتی که در ادامه میاد،ریسک‌ها رو از یک متن یک قرارداد استخراج می‌کنه. برای راحتی کار، ما یک جایگزین برای متن گذاشتیم به اسم {{CONTRACT}}. به خاطر اینکه برای این کار به زمینه (context) بزرگتری نیاز داریم، از مدل OpenAi gpt-4-1106-preview استفاده می‌کنیم. می‌تونی از این دستور از سایر مدل‌های زبان طولانی مثل کلاود هم استفاده کنی.
پرامپت ۱:
شما مدیر ارشد حقوقی ما هستید. این قرارداد SaaS را برای شناسایی ریسک‌ها بررسی کنید، با تمرکز بر حفاظت از داده‌ها، توافقنامههای سطح خدمات (SLA)، و سقف‌های مسئولیت.
<contract>
{{CONTRACT}}
</contract>
یافته‌های خود را در تگ‌های <risks> بنویسید.
خروجی پرامپت ۱:
موارد مورد نگرانی
۱. حفظ حریم خصوصی داده‌ها (بخش ۷):
– مسئله: فروشنده حقوق گسترده‌ای برای استفاده از داده‌های مشتری به منظور “بهبود خدمات” دارد.
– ریسک: می‌تواند منجر به اشتراک گذاری غیرمجاز داده‌ها یا کسب درآمد از داده‌های مشتری شود.
– تاثیر: احتمال نقض اعتماد مشتری، جریمه‌های قانونی (GDPR, CCPA).
۲. توافقنامههای سطح خدمات (SLAs) (بخش ۵):
– مسئله: تضمین ۹۹.۵٪ زمان اتصال در دسترس بودن زیر استاندارد صنعت است (معمولا ۹۹.۹۹٪).
– ریسک: حداکثر ۴۳.۸ ساعت خرابی در سال در مقایسه با ۵۲.۶ دقیقه در ۹۹.۹۹٪.
– تاثیر: اختلالات عملیاتی، از دست رفتن درآمد، نارضایتی مشتریان.
۳. مسئولیت (بخش ۹):
– مسئله: سقف مسئولیت به سه ماه هزینه‌ها محدود شده است.
– ریسک: ناکافی برای موارد نقض داده‌ها، سرقت مالکیت فکری، یا شکست‌های طولانی مدت خدمات.
– تاثیر: جبران ناکافی برای خساراتی که می‌توانند به مراتب بیشتر از سقف باشند، مانند دعوای گروهی یا جریمه‌های قانونی.
پرامپت ۲:
یک ایمیل به یک فروشنده محصول SaaS بنویسید که نگرانی‌های زیر را بیان می‌کند و تغییراتی را پیشنهاد می‌کند. در اینجا نگرانی ها وجود دارد:
<concerns>
{{CONCERNS}}
</concerns>
خروجی پرامپت ۲:
{{فروشنده}} عزیز،
پس از بررسی دقیق توافقنامه پیشنهادی SaaS، تیم حقوقی ما چندین نگرانی مهم شناسایی کرده است که باید قبل از ادامه کار به آنها پرداخته شود:
۱. حریم خصوصی داده‌ها (بند ۷): – وضعیت فعلی: حقوق گسترده برای استفاده از داده‌های مشتری به منظور “بهبود خدمات.”
– نگرانی: احتمال به اشتراک‌گذاری غیرمجاز یا کسب درآمد از داده‌ها.
– تغییر پیشنهادی: محدود کردن استفاده از داده‌ها به ارائه مستقیم خدمات. هرگونه استفاده برای بهبود، تحلیل یا بازاریابی باید به صورت اختیاری، قابل بازگشت و ناشناس باشد.
۲. توافقنامههای سطح خدمات (بند ۵): – وضعیت فعلی: ضمانت آپ‌تایم ۹۹.۵٪.
– نگرانی: حداکثر ۴۳.۸ ساعت زمان خرابی در سال، که ریسک اختلالات عملیاتی را افزایش می‌دهد.
– تغییر پیشنهادی: آپ‌تایم ۹۹.۹۹٪ با اعتباردهی خدمات طبق سطوح مشخص. مثلاً، ۱۰٪ اعتبار برای آپ‌تایم کمتر از ۹۹.۹۹٪، ۲۵٪ برای کمتر از ۹۹.۹٪، ۵۰٪ برای کمتر از ۹۹.۵٪.
۳. مسئولیت‌ها (بند ۹): – وضعیت فعلی: محدودیت تا ۳ ماه از هزینه‌ها.
– نگرانی: ناکافی بودن برای نقض داده‌ها، سرقت مالکیت معنوی، یا توقفات طولانی مدت.
– تغییر پیشنهادی: ۱۲ ماه هزینه برای مسئولیت عمومی. بدون محدودیت برای نقض داده‌ها، سوء رفتار عمدی، نقض مالکیت معنوی.
این تغییرات برای ما غیرقابل مذاکره هستند. آنها با استانداردهای صنعتی و تعهد ما به امنیت داده‌ها، تعالی عملیاتی، و مسئولیت مالی همخوانی دارند. ما به پتانسیل این همکاری ارزش می‌دهیم و پرداختن به این مسائل پایه محکمی برای همکاری ما خواهد گذاشت.
لطفاً تیم حقوقی شما این تغییرات را بررسی و اعمال نمایند. ما خوشحال می‌شویم که برای درک و توافق متقابل بیشتر با شما گفتگو کنیم.
با احترام،
{{نام مدیر ارشد حقوقی}}
پرامپت ۳:
وظیفه شما بررسی یک ایمیل و ارائه بازخورد است. این ایمیل است:
<email>
{{EMAIL}}
</email>
در مورد لحن، وضوح و حرفه ای بودن بازخورد بدهید.
خروجی پرامپت ۳:
۱. لحن:
– حرفه‌ای و قاطع بدون ایجاد درگیری.
– استفاده از “غیرقابل مذاکره” قوی است اما با توجه به اهمیت مسائل موجه است.
– زبان همکاری (“ما ارزش قائل هستیم”، “خوشحال می‌شویم که بحث کنیم”) نشان‌دهنده تعادل در قاطعیت و حفظ لحن سازنده است.
۲. شفافیت:
– ساختار عالی: وضعیت فعلی، نگرانی و تغییر پیشنهادی برای هر مسئله.
– اصطلاحات فنی (مانند “EBITDA”، “اعتبارات خدمات مرحله‌بندی شده”) برای بافت B2B SaaS مناسب است.
– موارد اقدام واضح هستند: تیم حقوقی فروشنده برای بررسی و اعمال تغییرات.
۳. حرفه‌ای‌گرایی:
– تمرکز بر نفع متقابل و استانداردهای صنعتی، نه فقط خواسته‌های ما.
– اشاره به مسئولیت‌های گسترده‌تر (امنیت داده، برتری عملیاتی، وظیفه امانت‌داری) که بحث را به سطح بالاتری می‌برد.
– پیشنهاد بحث‌های بیشتر، که نشان‌دهنده تعهد به درک و حل مسائل است.
در مجموع، ایمیل تعادل مناسبی از قاطعیت و همکاری را ایجاد می‌کند. نگرانی‌های ما را به وضوح بیان می‌کند، راه‌حل‌های خاصی را پیشنهاد می‌دهد و لحن حرفه‌ای و متمرکز بر همکاری را حفظ می‌کند. نیازی به بازبینی نیست؛ ادامه دهید و ارسال کنید.