کتاب‌های طراحی دستور

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

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

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

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

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

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

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

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

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

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

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

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

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

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

پنجمین ایده انتخاب ساختار ارتباطی مناسب بین وظایف است. مشکل این است که نحوهٔ تبادل داده‌ها تعیین می‌کند سیستم چقدر انعطاف‌پذیر یا پیچیده خواهد بود. گزینه‌ها شامل خطوط لوله خطی، گراف جهت‌دار غیرمدور (Directed Acyclic Graph) و شبکه‌های چرخشی هستند. گراف جهت‌دار غیرمدور به مجموعه‌ای از وظایف متصل گفته می‌شود که اطلاعات تنها در یک جهت رو به جلو جریان دارد و هیچ حلقه بسته‌ای تشکیل نمی‌شود. معاوضه این است که افزودن حلقه‌های بازگشتی برای اصلاح خطاها قدرت سیستم را بالا می‌برد اما درک و دیباگ کردن آن را به‌شدت دشوار می‌کند. برای مثال، اگر کیفیت ایمیل تولیدشده پایین باشد، بازگرداندن آن به مراحل اولیه نیازمند مدیریت دقیق تعداد دفعات تلاش مجدد است.

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

امیدوارم این مرور کوتاه به شما ایده داده باشد که چطور کارهای پیچیده را به جریان‌های کاری قابل‌اعتماد تبدیل کنید. تا برنامه‌ای دیگر، بدرود.

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

کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ جان بریمن و آلبرت زیگلر در این بخش به سراغ ساخت عاملیت مکالمه‌ای می‌رود و نشان می‌دهد چطور می‌توانیم مدل‌ها را به ابزارها و استدلال مجهز کنیم.

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

دومین ایده کلیدی در این کتاب، بهبود استدلال مدل از طریق روش زنجیرهٔ فکر (Chain-of-Thought) است. مدل‌های زبانی در حالت عادی تکه‌های متن را کلمه به کلمه بر اساس احتمال پیش‌بینی می‌کنند و مونولوگ درونی ندارند، یعنی بدون تفکر قبلی پاسخ را بیرون می‌ریزند. نویسندگان توضیح می‌دهند که اگر با چند نمونه یا با جمله‌ای ساده مثل «بیایید قدم‌به‌قدم فکر کنیم»، مدل را وادار کنیم ابتدا مراحل استدلال را بنویسد و بعد به جواب برسد، دقت پاسخ‌ها به شکل چشمگیری افزایش می‌یابد.

ایده سوم، ترکیب هم‌زمان استدلال و اقدام است که در مقاله‌ای به نام ReAct بررسی شده است. در این الگو، مدل در یک چرخهٔ مداوم ابتدا دربارهٔ وضعیت فکر می‌کند، سپس یک اقدام مانند جستجو در ویکی‌پدیا را انجام می‌دهد و در نهایت مشاهدات حاصل از آن اقدام را بررسی می‌کند تا به پاسخ درست برسد. این روش به مدل‌های کوچ‌تر اجازه می‌دهد در حل مسائل چندمرحله‌ای بسیار بهتر از مدل‌های غول‌پیکر عمل کنند.

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

پنجمین نکته، نحوهٔ پیاده‌سازی نهایی و تجربه کاربری است. کتاب توضیح می‌دهد که چگونه می‌توان با نوشتن یک حلقهٔ پردازش ساده در پایتون، ورود کاربر و خروجی مدل را مدیریت کرد تا یک گفتگوی پیوسته شکل بگیرد، و همچنین تأکید می‌کند که در طراحی رابط کاربری باید دکمه‌هایی برای مشاهدهٔ جزئیات فراخوانی ابزار و بازگردانی خطاها در نظر گرفته شود.

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

امیدواریم از این بررسی کوتاه لذت برده باشید و بتوانید در پروژه‌های هوش مصنوعی خود از این ایده‌ها بهره ببرید.

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

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

بیایید با مشکل شروع پاسخ‌ها یعنی پیش‌درآمدها شروع کنیم. مدل‌های زبانی اغلب پیش از ارائهٔ پاسخ اصلی، توضیحات حاشیه‌ای یا تعارفات زیادی تولید می‌کنند که هم وقت می‌گیرد و هم هزینهٔ محاسباتی دارد. برای مدیریت این موضوع، سه راه پیش رو دارید: استفاده از ساختار ثابت در پرامپت، تشویق مدل به تفکر قدم‌به‌قدم برای مسائل پیچیده، یا پنهان کردن حاشیه‌ها در انتهای پاسخ. به عنوان نمونه، اگر از تکنیک زنجیرهٔ فکر (chain-of-thought) استفاده می‌کنید، داشتن یک پیش‌درآمد استدلالی طولانی عیب نیست بلکه کمک می‌کند مدل به پاسخ درستی برسد.

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

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

مسئلهٔ چهارم انتخاب مدل مناسب از میان گزینه‌های گوناگون بازار است. انتخاب مدل نیازمند تعادل میان هوش، سرعت، هزینه، سادگی استفاده و نیازهای خاص است. گزینه‌های پیش رو شامل سرویس‌های تجاری بسته و مدل‌های متن‌باز است. راهکار پیشنهادی این است که اگر پروژه در مرحلهٔ آزمایشی است، می‌توانید از ای‌پی‌آی API که رابط برنامه‌نویسی کاربردی است استفاده کنید و بعداً با کتابخانه‌های یکپارچه‌ساز مدل خود را تغییر دهید. همچنین اگر مدل‌های آماده نیازهای خاص شما را برآورده نمی‌کنند، می‌توانید به سراغ تنظیم دقیق fine-tuning بروید تا با آموزش مدل روی داده‌های خاص، فرمت و سبک دلخواه خود را به دست آورید.

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

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

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

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

نخستین ایدهٔ کلیدی در ساخت پرامپت، پدیدهٔ دره‌ای از بی‌حالی «Valley of Meh» است که از تأثیر یادگیری درون‌زمینه‌ای و پدیدهٔ میانِ گم‌شده ناشی می‌شود. مدل‌های زبانی اطلاعات ابتدای متن و انتهای متن را به‌خوبی به خاطر می‌سپارند اما در به‌کارگیری اطلاعاتی که در بخش میانی انباشته شده‌اند دچار مشکل می‌شوند. برای حل این مشکل، نویسندگان پیشنهاد می‌کنند که عناصر کلیدی و حیاتی را بیرون از این بخش میانی قرار دهیم و متن را تا حد امکان خلاصه نگه داریم تا مدل تمرکز خود را از دست ندهد.

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

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

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

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

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

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

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

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

اولین ایدهٔ کلیدی، استفاده از روش چندنمونه‌ای (few-shot) است؛ یعنی گنجاندن چند مثال نمونه در پرامپت تا مدل الگو و سبک پاسخ‌دهی را یاد بگیرد. مشکل اینجاست که مثال‌های زیاد ممکن است با افزایش حجم متن، از پنجرهٔ زمینه (context window) که حداکثر حجم متن قابل پردازش در مدل است فراتر بروند یا مدل را دچار سوگیری کنند. گزینهٔ جایگزین، اتکا به دستورات صریح است، اما توازن بین مثال‌ها و دستورات دشوار است. برای نمونه، اگر بخواهید مدل امتیاز یک کتاب را پیش‌بینی کند، دادن چند نمونه بررسی قبلی با امتیازهای مختلف به مدل کمک می‌کند فرمت خروجی را دقیقاً رعایت کند.

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

ایدهٔ سوم به نحوهٔ بازیابی اطلاعات برمی‌گردد که به کمک تولید مبتنی بر بازیابی (RAG) انجام می‌شود؛ روشی که در آن سیستم ابتدا مستندات مربوط را جستجو کرده و سپس به پرامپت اضافه می‌کند تا مدل به داده‌های خارج از داده‌های آموزشی خود دسترسی داشته باشد. مسئله این است که جستجو ممکن است اطلاعات نامربوط بیاورد و مدل هم اصرار دارد تمام اطلاعات داده‌شده را به کار بگیرد. انتخاب میان بازیابی واژگانی بر اساس تطابق کلمات و بازیابی عصبی (neural retrieval) که بر اساس معنا و مفهوم کار می‌کند، یکی از تصمیمات مهم است. نویسندگان کتاب اشاره می‌کنند که اگر به دنبال یافتن دقیق نظرات پیشین کاربر دربارهٔ ژانر خاصی از کتاب هستید، جستجوی مبتنی بر معنا معمولاً نتایج بهتری نسبت به تطابق سادهٔ کلمات به دست می‌دهد.

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

پیشنهاد من به شما این است که هنگام طراحی پرامپت‌های پیچیده، ابتدا اطلاعات ثابت و متغیر را تفکیک کنید و پیش از افزودن حجم انبوهی از مثال‌ها یا داده‌های پویا، حتماً عملکرد مدل را با داده‌های کمتر بسنجید تا از گمراه شدن آن جلوگیری کنید.

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

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

در کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ «جان بریمن و آلبرت زیگلر»، فصل چهارم به طراحی برنامه‌های کاربردی مبتنی بر این مدل‌ها اختصاص دارد و نشان می‌دهد که چطور باید پل ارتباطی میان دنیای مسائل انسانی و دنیای مستندات مدل ساخت.

اولین ایده کلیدی این است که اپلیکیشن‌های هوش مصنوعی در واقع یک چرخه یا حلقه هستند که مسئله را از کاربر دریافت کرده، به زبان مدل تبدیل می‌کنند و بعد پاسخ را به دنیای واقعی برمی‌گردانند. مسئله اینجاست که مدل‌های زبانی بزرگ کار خاصی نمی‌کنند جز تکمیل سند پرامپت (Prompt)، که به متن‌هایی گفته می‌شود که به مدل زبانی داده می‌شود تا خروجی تولید کند. نویسندگان این روش را اصل شنل‌قرمزی می‌نامند؛ یعنی نباید از مسیری که مدل برای آن آموزش دیده دور شویم و پرامپت ما باید شبیه اسناد موجود در داده‌های آموزشی باشد تا خروجی قابل پیش‌بینی و پایداری به دست آوریم. برای نمونه، در یک برنامه توصیف سفر، ساختار دادن به متن با استفاده از علامت‌های مشخص یا قالب تکالیف درسی کمک می‌کند مدل دقیقا همان الگو را دنبال کند.

ایده دوم به ساختاردهی و آماده‌سازی جریان جلوبر فیدفوروارد مربوط می‌شود که شامل استخراج زمینه، خرد کردن متن به تکه‌های کوچک‌تر و ارزیابی اهمیت آن‌هاست. مشکل اینجاست که اگر اطلاعات زیادی به مدل بدهیم، دچار حواس‌پرتی می‌شود و اگر اطلاعات کم بدهیم، پاسخ درستی نمی‌گیرد. راهکار این است که تکه‌های متن را اولویت‌بندی کنیم و مطمئن شویم که از پنجرهٔ زمینه (Context Window) که به حداکثر حجم متن یا توکنی گفته می‌شود که مدل در یک درخواست می‌بیند، فراتر نمی‌رویم. برای مثال، اگر در یک برنامه پشتیبانی فنی، جستجویی در مستندات انجام می‌شود، باید فقط بخش‌های واقعاً مرتبط را استخراج کنیم و در پرامپت قرار دهیم.

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

ایده چهارم دربارهٔ استفاده از ابزار و استدلال گام‌به‌گام است. مدل‌های زبانی به صورت پیش‌فرض در یک دنیای بسته کار می‌کنند و نمی‌توانند تغییری در دنیای خارج ایجاد کنند. مبادلهٔ مداوم بین برنامه و مدل از طریق زنجیرهٔ فکر (Chain-of-Thought)، که به معنای واداشتن مدل به بیان مراحل استدلال پیش از ارائه پاسخ نهایی است، کیفیت تصمیم‌گیری را به شدت بالا می‌برد. مبادلهٔ ابزار به مدل اجازه می‌دهد که توابع مشخصی را صدا بزند. مثلاً وقتی کاربر درخواست خرید بلیت دارد، مدل یک درخواست ساختاریافته برای اجرای تابع صادر می‌کند و اپلیکیشن پس از تأیید کاربر، عملیات خرید را در دنیای واقعی انجام می‌دهد.

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

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

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

تا حالا به این فکر کرده‌اید که چرا مدل‌های اولیهٔ اینترنت مثل یک انشای بی‌پایان ادامه پیدا می‌کردند اما دستیارهای امروزی درست مثل یک انسان آگاه به سوالات شما جواب می‌دهند؟ راز این تغییر بزرگ در نحوهٔ آموزش و هدایت مدل‌ها پنهان است. در این اپیزود از شب‌گفتار می‌خواهیم ببینیم چطور یک موتور سادهٔ تکمیل متن به یک دستیار هوشمند تبدیل می‌شود.

در کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ جان بریمن و آلبرت زیگلر، در فصل سوم که Moving to Chat نام دارد، دقیقاً همین مسیر دگرگونی بررسی می‌شود و نشان می‌دهد که چطور مدل‌ها از حالت تکمیل سند خارج شده و به ابزارهای گفتگومحور تبدیل شده‌اند.

مدل‌های پایه به‌تنهایی مانند یک تیغ دوطبه عمل می‌کنند؛ هم می‌توانند یک دستور پخت خوشمزه تولید کنند و هم اطلاعات خطرناک را شبیه‌سازی کنند. گزینهٔ جایگزین، آموزش نظارت‌شده Supervised Fine-Tuning است که در آن مدل با هزاران سند نمونه آموزش می‌بیند تا مثل یک دستیار مفید عمل کند. معاملهٔ این روش در این است که مدل رفتاری قاعده‌مند پیدا می‌کند، اما ممکن است در پاسخ‌دهی دچار مشکلاتی مانند ارائهٔ اطلاعات نادرست با لحن مطمئن halluciation (توهم‌زایی) شود که به معنی تولید محتوای نادرست اما با ظاهری کاملاً موجه است.

برای حل چالش صداقت و کیفیت، از یادگیری تقویتی از بازخورد انسانی reinforcement learning from human feedback (RLHF) استفاده می‌شود. در این روش، ابتدا مدل‌ها پاسخ‌های متعددی به پرامپت تولید می‌کنند که پرامپت به معنی متنی است که به مدل زبانی داده می‌شود تا خروجی تولید کند. سپس داوران انسانی این پاسخ‌ها را رتبه‌بندی می‌کنند تا یک مدل پاداش بسازند. چالش اینجاست که آموزش بیش از حد بر اساس پاداش می‌تواند متن انسان‌گونه را خراب کند و معاملهٔ آن افت هوش کلی مدل یا اصطلاحاً مالیات همسویی است.

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

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

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

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

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

اولین مسئله‌ای که نویسندگان مطرح می‌کنند این است که مدل زبانی اساساً یک ماشین تقلید است که با دریافت پرامپت (Prompt) که یعنی متنی که به مدل زبانی داده می‌شود تا خروجی تولید کند، ادامهٔ متن را حدس می‌زند. مشکل اینجاست که مدل‌ها نمی‌توانند مثل انسان‌ها بین کار جستجو در وب یا بازنویسی جابجا شوند و همیشه جواب می‌دهند، حتی اگر اطلاعات نادرست تولید کنند. به این پدیده توهم‌زایی (Hallucination) می‌گویند که یعنی تولید اطلاعات نادرست با لحن مطمئن و بدون اینکه مدل خودش بداند در حال حدس زدن است. راه حل این است که به جای نهی کردن مدل از دروغ‌گفتن، از آن بخواهیم مستندات و استدلال‌های قابل بررسی ارائه دهد.

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

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

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

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

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

امیدوارم این مرور کوتاه به شما کمک کند تا در پروژه‌های هوش مصنوعی خود تعامل دقیق‌تر و هوشمندانه‌تری با مدل‌ها داشته باشید.

تا حالا به این فکر کرده‌اید که چطور ماشین‌هایی مثل چت‌جی‌پتی توانسته‌اند در مدت زمانی کوتاه، میلیون‌ها کاربر را جذب کنند و شیوهٔ کار و جستجوی ما را تغییر دهند؟ آیا این ابزارها واقعاً مثل جادو کار می‌کنند یا فرمول ساده‌ای در پشت صحنه جریان دارد؟

این اپیزود از شب‌گفتار به فصل اول کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ جان بریمن و آلبرت زیگلر می‌پردازد و به ما نشان می‌دهد که چطور مدل‌های زبانی از یک ابزار پیش‌بینی سادهٔ کلمات به دستیارهای همه‌فن‌حریف تبدیل شده‌اند.

در گام نخست، مسئله این است که مدل‌های زبانی در بنیادین‌ترین سطح خود فقط کلمهٔ بعدی را پیش‌بینی می‌کنند و این کار ممکن است در نگاه اول ساده و حتی کم‌کاربرد به نظر برسد. نویسندگان نشان می‌دهند که مدل‌های اولیه مانند شبکه‌های عصبی بازگشتی با یک تنگنای اطلاعاتی روبه‌رو بودند زیرا یک بردار تفکر ثابت و محدود داشتند که اطلاعات متن‌های طولانی را فراموش می‌کرد. گزینه‌ای که این مشکل را حل کرد، مکانیسم توجه (Attention Mechanism) بود که به مدل اجازه داد بدون از دست رفتن جزئیات، به بخش‌های مختلف متن توجه کند. نمونهٔ بارز این پیشرفت را در معماری ترنسفورمر (Transformer) می‌بینیم که مبنای مدل‌های جی‌پی‌تی شد و توانست قابلیت‌های چشمگیری در ترجمه و خلاصه سازی ارائه دهد.

مسئلهٔ دوم دربارهٔ جهش مدل‌ها از کارهای تک‌منظوره به مدل‌های چندمنظوره است که با افزایش حجم داده‌ها و پارامترها رخ داد. گزینهٔ پیش رو این بود که مدل‌ها را برای هر کار خاص آموزش دهیم یا از مدل‌های بزرگ‌تری استفاده کنیم که توانایی یادگیری چندنمونه‌ای (Few-Shot) را دارند. ترفند مبادله در اینجا هزینه‌های بالای آموزش و محاسبات است، اما دستاوردش این است که مدل می‌تواند با دیدن تنها چند مثال در ورودی، الگوی مورد نظر را درک کند. برای نمونه، مدل جی‌پی‌تی سه توانست با همین رویکرد، کارهای متنوع زبانی را بدون نیاز به بازآموزی تخصصی انجام دهد.

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

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

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

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

امیدواریم از این بررسی لذت برده باشید و تا اپیزودی دیگر، خدانگهدار.

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

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

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

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

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

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

امیدوارم این مرور کوتاه توانسته باشد دید روشن‌تری از دنیای مهندسی پرامپت به شما بدهد. تا اپیزود بعدی، پیروز و هوشمند باشید.