پرامپت را مثل کد منتشر کنید؛ نسخهٔ بهتر بدون آزمون معلوم نمی‌شود

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

برای شروع، فایل پرامپت و مجموعهٔ آزمون را در Git نگه دارید و خروجی هر اجرا را به شناسهٔ نسخه پیوند دهید. معیار پذیرش را پیش از دیدن نتایج تعیین کنید و نسخهٔ فعال قبلی را در دسترس بگذارید. این کار به تیم امکان می‌دهد تصمیم انتشار را بازبینی کند و هنگام پسرفت کیفیت، پیکربندی تأییدشده را دوباره فعال سازد.

هر تغییر را به نسخه‌ای قابل‌ردگیری تبدیل کنید

پرامپت را در فایلی جدا نگه دارید و برای هر ویرایش، شناسهٔ commit، دلیل تغییر و تفاوت متن با نسخهٔ قبلی را ثبت کنید. دستور اصلی، نمونه‌های داخل پرامپت، ترتیب پیام‌ها، قالب خروجی و شیوهٔ برخورد با ورودی نامعتبر همگی بر پاسخ اثر می‌گذارند؛ تغییر ثبت‌نشده در هرکدام، یافتن علت یک پسرفت را دشوار می‌کند. در مستندات ارزیابی MLflow، ثبت نسخه، اجرای آن روی دادهٔ ارزیابی و نگهداری تاریخچهٔ نتایج در یک گردش‌کار نشان داده شده است.

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

مجموعهٔ آزمون ثابت، اما متناسب با فارسی محصول بسازید

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

در محصول فارسی‌زبان، تفاوت نوشتار می‌تواند رفتار پرامپت را آشکار کند. نمونه‌های مرتبط با کاربرد محصول را با «ی» و «ک» فارسی و عربی، نیم‌فاصله، ارقام فارسی و لاتین، نام انگلیسی در جملهٔ فارسی و صورت‌بندی‌های رایج در فارسی ایران و افغانستان بگنجانید. لازم نیست همهٔ این حالت‌ها را برای هر وظیفه تکرار کنید؛ همان جا آزمونشان کنید که بر فهم ورودی یا قالب خروجی اثر دارند. اگر نمونه‌ای از درخواست واقعی کاربران می‌آورید، اطلاعات شخصی را پیش از ثبت در مخزن آزمون حذف یا بی‌نام کنید.

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

کیفیت پاسخ و درستی قالب را جدا بسنجید

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

برای ویژگی‌هایی مانند کامل بودن پاسخ یا پرهیز از ادعای بی‌پشتوانه، معیار کوتاهی بنویسید که ارزیابان بتوانند آن را به یک شکل اعمال کنند. کنار نتیجهٔ هر مورد، خود پاسخ و دلیل رد یا قبول را نگه دارید تا معلوم شود تغییر دقیقاً کجا اثر گذاشته است. اگر خروجی با اجرای دوباره تغییر می‌کند، موارد تعیین‌کننده را چند بار با تنظیمات ثابت اجرا کنید و پراکندگی نتیجه را ببینید؛ تصمیم بر پایهٔ یک پاسخ اتفاقی می‌تواند گمراه‌کننده باشد.

شرط انتشار را پیش از دیدن نتیجه مشخص کنید

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

پس از اجرا، مواردی را که از قبول به رد تبدیل شده‌اند کنار موارد بهبودیافته بگذارید. بررسی کنید آیا پسرفت به نوعی از درخواست، قالب مشخصی از خروجی یا گونه‌ای از نوشتار فارسی مربوط است. اگر نسخهٔ جدید در هدف اصلی بهتر شد اما شرط قطعی را شکست، آن را اصلاح کنید و دوباره بر همان مجموعه بیازمایید. تصمیم نهایی و دلیل آن را همراه با شناسهٔ پرامپت، مدل، تنظیمات و مجموعهٔ آزمون در رکورد انتشار نگه دارید.

مرحله‌ای منتشر کنید و نسخهٔ قبلی را آماده نگه دارید

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

شناسهٔ نسخهٔ قبلی باید تا پایان این مرحله قابل‌استفاده بماند. در قابلیت بتای Azure Databricks، راهنمای پرامپت‌های مستقر نمونه‌ای از ارجاع به نسخهٔ فعال با نام مستعار و حفظ ارجاع جداگانه به نسخهٔ قبلی برای بازگشت ارائه می‌کند. در پیاده‌سازی ساده‌تر هم می‌توان شناسهٔ پرامپت فعال را در تنظیمات انتشار نگه داشت و هنگام پسرفت به شناسهٔ تأییدشدهٔ قبلی برگرداند. اگر مدل یا تنظیمات تولید نیز همراه پرامپت تغییر کرده‌اند، بازگشت باید کل پیکربندی تأییدشده را برگرداند؛ سپس نتیجه در ترافیک واقعی دوباره سنجیده شود.

بیشتر بخوانید:

• نسخه‌بندی S3 بکاپ را مصون نمی‌کند؛ Object Lock را درست فعال کنید
• Playwright یا Cypress؛ سرعت بدون جداسازی آزمون‌ها دوام نمی‌آورد
• Moodle 5.3 به نسخهٔ LTS رسید؛ ارتقا بدون PHP 8.3 متوقف می‌شود