اگر از بات مکالمه ChatGPT سوال کنید که: مهندسی پرسش چیست؟، پاسخ بسیار خوبی به شما می دهد. اما فرض می کند که یک درخواست مانند جستجوی گوگل است.

مهندسی پرسش به تمرین طراحی اعلان های مؤثر و خاص برای مدل های زبان یا سیستم های هوش مصنوعی برای تولید خروجی های دلخواه اشاره می کند. در زمینه مدل های زبانی مانند GPT-3، اعلان ها دستورالعمل های اولیه یا ورودی ارائه شده به مدل برای برانگیختن پاسخ خاصی هستند. مهندسی پرسش موثر شامل ایجاد دستورهایی است که به خروجی های دقیق، مرتبط و منسجم از مدل منجر می شود.

مهندسی پرسش یک مهارت حیاتی در هنگام کار با مدل های زبان بزرگ است، زیرا تعیین می کند که مدل چقدر می تواند ورودی های کاربر را درک کند و به آنها پاسخ دهد. این نیاز به ترکیبی از تخصص زبانی، دانش حوزه و درک نحوه عملکرد مدل خاص دارد.

در سایت ویکی پدیا، درباره مهندسی پرسش گفته می شود:

مهندسی پرسش یک مفهوم در هوش مصنوعی (AI)، به ویژه پردازش زبان طبیعی (NLP) است. معمولاً شرح کار به طور ضمنی به برنامه داده می شود، اما در مهندسی پرسش، برای مثال به عنوان یک سؤال، در ورودی (اعلان) تعبیه می شود.

همچنین در در این دانشنامه گفته می شود:

مهندسی پرسش معمولاً با تبدیل یک یا چند کار به یک مجموعه داده مبتنی بر پرسش و آموزش یک مدل زبان با آنچه “یادگیری مبتنی بر فوری” یا به سادگی “آموزش سریع” نامیده می شود کار می کند. مهندسی پرسش می تواند از یک مدل زبان از پیش آموزش‌دیده بزرگ کار کند و با استفاده از روش هایی مانند “تنظیم پیشوند” یا “تنظیم سریع”، تنها نمایش اعلان را بیاموزد (یعنی بهینه سازی).

برخورد با یک پرسش، مانند کد غیر قابل پیش بینی

اگر کد نوشته اید، دقیقاً می دانید که چه پاسخی خواهید گرفت. کامپایلر تغییر نمی کند. هنگامی که ما یک اعلان می نویسیم، یک مدل زبان بزرگ (LLM) را می زنیم که با نتیجه برمیگردد. این مدل زبان بزرگ می تواند بر اساس آموزش، اصلاح و بهینه سازی در حال تکامل باشد. بنابراین نتیجه در طول زمان تغییر خواهد کرد.

اگر درخواستی را در برنامه ای جاسازی کرده اید یا به عنوان یک الگوی مشترک و قابل استفاده مجدد در دسترس است، باید در چرخه عمر توسعه نرم افزار (SDLC) مدیریت شود. آن را به عنوان کد ترسناک در نظر بگیرید.

بنابراین بدیهی است که شما برنامه ریزی می کنید، این تحلیل تجاری است. شما نتیجه ای را که انتظار دارید مشخص می کنید. این گسترده تر از نتیجه سریع است، اما آنچه که آن نتیجه تلاش می کند به دست آورد.

مثال:

اگر اعلان یک ایمیل را بر اساس داده های مشتری فرموله می کند، که توسط برخی اقدامات ایجاد شده است، پس ایمیل در صدد رسیدن به چه چیزی است؟

سپس فرمان را می سازید. این کاملا تکراری است. شما بنویسید، تست کنید. صرفاً معکوس کردن موقعیت دو کلمه در اعلان نتایج بسیار متفاوتی به دست می دهد. ما متوجه شده ایم که هرچه این درخواست طولانی تر و دقیق تر باشد، پاسخ بهتری دریافت خواهیم کرد. بهتر است یک اعلان فشرده تر بنویسید. یک مجموعه مهارت کامل برای نوشتن اعلان ها وجود دارد که نتایج عالی به دست می آورد.

مثال:

یک تیم برنامه نویسی 3 روز را صرف بهینه سازی یک درخواست در ElementsGPT کرد که مراحل فرآیند تجاری را طی می کند و به طور خودکار داستان های کاربر را با معیارهای پذیرش می سازد.

بعد، تست. اگر هر بار که دستور را اجرا می کنید، پاسخ کمی متفاوت دریافت می کنید، چگونه می توانید یک آزمون را امضا کنید؟ آیا حتی می توانید از تست خودکار استفاده کنید؟ پس باید کمی گسترده تر در مورد معنای آزمایش فکر کنیم.

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

به عنوان نمونه:

تیم مدیریت محصول مجموعه ای از الگوهای پرسش را ساخته است که به طور خودکار وب سایت داخلی آنها را در مورد تمام ویژگی های محصول جدیدی که در حال انتشار است می سازد.

مفاهیم جدیدی وجود دارد که در یک SDLC سنتی نمی توانید آنها را پیدا کنید.

آیا از دستورات استفاده می شود؟ آیا نتایج آن چیزی است که ما انتظار داشتیم؟ آیا کاربران نتایج را می گیرند و باید آنها را ویرایش کنند؟ ما به مکانیزمی برای نظارت بر استفاده، ردیابی میزان تغییر نتایج توسط کاربران و راهی برای جمع آوری بازخورد کاربر نهایی نیاز داریم.

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

اگر درخواست با ریسک بالایی همراه است، زیرا نتیجه ای را ایجاد می کند که تأثیر مادی دارد. ایمیلی همراه با پیشنهادی که بر اساس یک اقدام یا ارزشی که به آستانه رسیده است، به مشتری ارسال می شود، شاید لازم باشد آن را به صورت هفتگی یا روزانه نظارت کنیم. اگر این یک ایمیل داخلی است، پس شاید مشکل کمتری باشد و ما ماهانه آن را نظارت می کنیم. مفهوم نظارت بر چیزی برای دریفت جدید است.

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

به عنوان نمونه:

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

نتیجه گیری

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