با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

خلاصهٔ صوتی کتاب ۱۴۰۵/۰۸/۰۲

فصل دهم: ارزیابی برنامه‌های کاربردی مدل‌های زبانی بزرگ

از کتاب مهندسی پرامپت برای مدل‌های زبانی بزرگ · جان بریمن و آلبرت زیگلر

جلد مهندسی پرامپت برای مدل‌های زبانی بزرگ
SHABGOFTAR PORTABLE AUDIOهمراهِ شنیدن
صدایی برای همراه بردنPODCAST · PERSONAL STEREO
شب‌گفتار / دفترچهٔ همراهSHABGOFTAR · LINER NOTES

دربارهٔ این فصل

یادداشتِ همراه نوار
جلد مهندسی پرامپت برای مدل‌های زبانی بزرگمهندسی پرامپت برای مدل‌های زبانی بزرگجان بریمن و آلبرت زیگلردیدن همهٔ قسمت‌های این کتاب ←

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

در کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ جان بریمن و آلبرت زیگلر، فصل دهم به موضوع بسیار حیاتیِ ارزیابی (evaluation) می‌پردازد؛ فرآیندی که کیفیت خروجی مدل را با استفاده از آزمون‌ها و معیارهای مشخص می‌سنجد و مسیر توسعهٔ اپلیکیشن ما را هموار می‌کند.

یکی از چالش‌های اصلی در شروع کار این است که اصلاً چه چیزی را باید تست کنیم و از کجا نمونه‌های کافی برای این کار بیاوریم. اگر بخواهیم ارزیابی آفلاین (offline evaluation) انجام دهیم، یعنی ارزیابی نمونه‌ها مستقل از اجرای زندهٔ اپلیکیشن، با کمبود داده روبه‌رو می‌شویم. نویسندگان اشاره می‌کنند که می‌توانیم از رکوردهای موجود استفاده کنیم، داده‌ها را از تعاملات کاربران جمع‌آوری کنیم یا حتی با کمک خود مدل، داده‌های مصنوعی بسازیم. تعادل برقرار کردن میان شباهت داده‌ها به دنیای واقعی و مقیاس‌پذیر بودن آن‌ها، معامله‌ای است که باید در این مرحله انجام دهیم.

مسئلهٔ بعدی این است که پس از داشتن نمونه‌ها، چطور پاسخ‌های مدل را در مقیاس وسیع بسنجیم. ساده‌ترین راه، مقایسه با استاندارد مرجع (gold standard) است، اما وقتی خروجی مدل متن آزاد است، تطابق دقیق عملاً غیرممکن می‌شود. گزینهٔ دیگر استفاده از آزمون کارکردی (functional testing) است که بررسی می‌کند آیا خروجی مثلاً قابل پردازش است یا توابع معتبر را صدا می‌زند. راه‌حل سوم این است که از خود مدل برای ارزیابی استفاده کنیم که برای جلوگیری از تعصبات مدل، باید از روش صوما (SOMA assessment) شامل سؤالات مشخص، پاسخ‌های طیفی و پوشش چندبعدی استفاده کنیم.

در کنار سنجش‌های آزمایشگاهی، ارزیابی آنلاین (online evaluation) به ما اجازه می‌دهد ایده‌های خود را مستقیماً روی کاربران واقعی آزمایش کنیم. چالش اینجاست که خطاهای محیط زنده به تجربهٔ کاربر آسیب می‌زند و حجم نمونه‌ها محدود است. برای غلبه بر این مشکل، آزمایش ای/بی (A/B testing) به کار گرفته می‌شود؛ روشی که در آن کاربران به گروه‌های مختلف تقسیم می‌شوند تا دو نسخهٔ متفاوت از اپلیکیشن را تجربه کنند و عملکرد آن‌ها با معیارهای ازپیش‌تعیین‌شده مقایسه شود.

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

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

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