فصل سوم: حرکت به سمت گفتگو (Chat) 💬
تو فصل قبلی، با معماری ترنسفورمر و نحوه کارکرد مدلهای زبان آشنا شدیم. روشی که این مدلها آموزش میبینن، تاثیر خیلی زیادی روی رفتارشون داره. یه «مدل پایه» (Base Model)، مدلیه که فقط مرحله پیشآموزش رو گذرونده. یعنی با میلیاردها متن و سند از سراسر اینترنت آموزش دیده. اگه شما نصف یه متن رو به این مدل بدید، اون یه ادامه کاملاً باورپذیر براش تولید میکنه. همین قابلیت به تنهایی خیلی کاربردیه و ما تو این کتاب بهتون نشون میدیم که چطور میشه این مدلها رو «گول زد» تا کلی کار دیگه غیر از تکمیل متن هم برامون انجام بدن!
اما استفاده از مدلهای پایه تو اپلیکیشنهای واقعی، به چند دلیل میتونه سخت و چالشبرانگیز باشه.
چالش شماره ۱: جنبه تاریک اینترنت! 😈
چون مدل پایه با هر چی که تو اینترنت بوده آموزش دیده، هم میتونه روی روشن ماجرا رو تقلید کنه و هم روی تاریکش رو! اگه بهش پرامپت «این دستور پخت لازانیای سیسیلی است:» رو بدید، یه دستور پخت غذای ایتالیایی خوشمزه بهتون میده. 🍝 اما اگه بهش بگید «این مراحل دقیق ساخت متامفتامین است:»، خیلی زود هرچی برای شروع یه زندگی پر از جرم و جنایت لازم دارید رو در اختیارتون میذاره! ما نیاز داریم که مدلها «ایمن» (Safe) باشن تا کاربرا با مکالمات ناخوشایند در مورد خشونت، مسائل جنسی یا توهینآمیز غافلگیر نشن.
چالش شماره ۲: ما فقط یه تکمیلکننده متن نمیخوایم!
مدلهای پایه فقط بلدن متن رو کامل کنن. اما ما خیلی وقتا بیشتر از این میخوایم. ما میخوایم LLMها مثل یه دستیار (Assistant) عمل کنن، کد پایتون اجرا کنن، تو اینترنت دنبال اطلاعات بگردن و از ابزارهای خارجی استفاده کنن. اگه از یه مدل پایه یه سوال بپرسید، به جای اینکه مثل یه دستیار بهتون جواب بده، به احتمال زیاد یه لیست بیپایان از سوالهای شبیه به سوال شما تولید میکنه!
مثال: خروجی یه مدل پایه (بدون آموزش دستیار)
شما: یه غذای خوب برای مرغ چیه؟
مدل:
یه غذای خوب برای گوشت گاو چیه؟
یه غذای خوب برای گوشت خوک چیه؟
یه غذای خوب برای برنج چیه؟
...
اما با آموزش درست، میشه به یه مدل یاد داد که مثل یه دستیار رفتار کنه و به کاربرا برای حل مشکلاتشون کمک کنه.
مثال: خروجی یه مدل آموزشدیده به عنوان دستیار
شما: یه غذای خوب برای مرغ چیه؟
مدل:
یه غذای عالی برای مرغ، چیکن پیکاتا است. یه غذای کلاسیک ایتالیایی-آمریکاییه که آماده کردنش سادهست ولی طعم فوقالعادهای داره. اینم یه دستور پخت ساده برای شروع:
...
دستیار ایدهآل ما چه ویژگیهایی داره؟
ما فقط یه دستیار معمولی نمیخوایم! ما یه دستیار میخوایم که مؤدب باشه، رک باشه ولی بیادب نه، جوابهاش کامل باشه ولی پرحرف نه، راستگو باشه و توهم نزنه. میخوایم شخصیسازیش راحت باشه (مثلاً کاری کنیم مثل یه دکتر حرف بزنه که لحن دزدای دریایی رو داره!) ولی «جیلبریک» کردنش (یعنی از بین بردن این شخصیسازیها) سخت باشه. و در نهایت، میخوایم قابلیت اجرای کد و استفاده از ابزارهای خارجی رو هم داشته باشه.
بعد از موفقیت چشمگیر ChatGPT، کل اکوسیستم LLMها داره از سمت «تکمیل متن» به سمت «گفتگو» حرکت میکنه. تو این فصل، شما با یادگیری تقویتی از بازخورد انسانی (RLHF) آشنا میشید؛ یه روش آموزش خیلی تخصصی که برای تنظیم دقیق یه مدل پایه استفاده میشه تا بتونه وارد گفتگو بشه. همچنین با تاثیرات این روش روی مهندسی پرامپت و ساخت اپلیکیشنهای مبتنی بر LLM آشنا میشید تا برای فصلهای بعدی آماده باشید.
یادگیری تقویتی از بازخورد انسانی (RLHF): رام کردن غول سرکش! 🐴
RLHF یک تکنیک آموزش LLM است که از ترجیحات و نظرات انسانها برای تغییر رفتار یک LLM استفاده میکنه. تو این بخش، یاد میگیریم که چطور میشه یه مدل پایه سرکش و غیرقابل کنترل رو با فرآیند RLHF به یه دستیار خوشرفتار و مفید تبدیل کرد که بتونه با کاربرها گفتگو کنه.
شرکتهای بزرگی مدلهای گفتگومحور خودشون رو با این روش ساختن: گوگل Gemini رو ساخته، Anthropic مدل Claude رو و OpenAI هم مدلهای GPT خودش رو. فرآیند ساخت یه مدل RLHF خیلی پیچیدهست و شامل چهار مدل مختلف، سه مجموعه داده آموزشی و سه روش تنظیم دقیق کاملاً متفاوته! اما تا آخر این بخش، شما کاملاً میفهمید که این مدلها چطور ساخته شدن و رفتارهاشون از کجا میاد.
فرآیند ساخت یک مدل RLHF در چند مرحله
اولین چیزی که لازم داریم، یه مدل پایه (Base Model) است. این مدل با خوندن تقریباً کل اینترنت، «خیلی چیزا میدونه»، اما رام کردنش خیلی سخته! مثلاً اگه ازش بخواید ادامه یه خبر رو بنویسه، اولش خوب پیش میره ولی خیلی زود شروع به توهم زدن و گفتن جزئیات عجیب و غریب میکنه.
دقیقاً به همین خاطره که به «همراستاسازی مدل» (Model Alignment) نیاز داریم. یعنی تنظیم دقیق مدل تا جوابهاش با انتظارات ما آدما سازگارتر باشه. ما دنبال یه دستیار با سه ویژگی اصلی هستیم (که بهش میگن همراستاسازی HHH):
- مفید (Helpful): دستورات کاربر رو دنبال کنه و جوابهای کوتاه و مفید بده.
- صادق (Honest): توهم نزنه و اگه از چیزی مطمئن نیست، بگه.
- بیضرر (Harmless): محتوای توهینآمیز، تبعیضآمیز یا خطرناک تولید نکنه.
برای رسیدن به این هدف، چند مرحله رو طی میکنیم:
مرحله ۱: ساخت مدل SFT (تنظیم دقیق نظارتشده)
اولین قدم، ساخت یه مدل میانی به اسم SFT است. برای این کار، ما هزاران نمونه گفتگوی ایدهآل بین یه آدم و یه دستیار HHH رو با دست مینویسیم. بعد مدل پایه رو با این نمونههای باکیفیت، تنظیم دقیق (Fine-tune) میکنیم.
مدل SFT خیلی بهتر از مدل پایه رفتار میکنه و بیشتر به حرف کاربر گوش میده. اما هنوز یه مشکل بزرگ داره: یه کم دروغگوئه و زیاد توهم میزنه! برای حل این مشکل، وارد دنیای یادگیری تقویتی میشیم.
مرحله ۲: ساخت مدل پاداش (Reward Model)
یادگیری تقویتی (RL) مثل تربیت کردن یک حیوان خانگی است. حیوان یه کاری میکنه و اگه خوب بود، بهش جایزه (پاداش) میدیم. تو دنیای ما، LLM اون حیوانه و پاداش، یه امتیاز برای «خوب بودن» جوابشه. اما کی باید این امتیاز رو بده؟ یه مدل دیگه به اسم مدل پاداش (RM).
برای آموزش دادن این مدلِ داور، این کارها رو میکنیم:
- به مدل SFT یه عالمه پرامپت مختلف میدیم.
- برای هر پرامپت، از مدل SFT میخوایم که چندتا (مثلاً ۴ تا ۹ تا) جواب مختلف و متنوع تولید کنه (با بالا بردن دما).
- یه تیم از داورهای انسانی، این جوابها رو از بهترین تا بدترین، رتبهبندی میکنن.
- این جوابهای رتبهبندی شده، میشن داده آموزشی برای مدل پاداش ما!
مدل پاداش یاد میگیره که دقیقاً مثل یه داور انسانی فکر کنه و به جوابهای باکیفیتتر، امتیاز بالاتر و به جوابهای بیکیفیت، امتیاز پایینتری بده.
مرحله ۳: ساخت مدل نهایی (RLHF) - پرده آخر! 🎬
با داشتن مدل پاداش، همه چیز برای قدم نهایی آماده است: ساخت مدل واقعی RLHF. درست همونطور که از مدل SFT به عنوان نقطه شروع برای مدل پاداش استفاده کردیم، اینجا هم از مدل SFT شروع میکنیم و اون رو با استفاده از قضاوتهای مدل پاداش، بیشتر تنظیم دقیق میکنیم.
فرآیند آموزش اینطوریه: ما به مدل SFT یه پرامپت میدیم و بهش اجازه میدیم یه جواب تولید کنه. این بار، به جای داورهای انسانی، مدل پاداش میاد و به این جواب امتیاز میده. بعد، پارامترهای مدل RLHF مستقیماً بر اساس این امتیاز، آپدیت میشن.
اما حتی اینجا هم یه پیچیدگی جدید داریم! اگه مدل رو فقط بر اساس امتیاز مدل پاداش تنظیم کنیم، تمایل به تقلب کردن پیدا میکنه! یعنی یاد میگیره جوری جواب بده که فقط امتیاز بالایی از مدل پاداش بگیره، حتی اگه اون جوابها دیگه شبیه به یه متن عادی انسانی نباشن!
برای حل این مشکل آخر، از یه الگوریتم یادگیری تقویتی خاص به اسم PPO استفاده میکنیم. این الگوریتم به مدل اجازه میده تا برای گرفتن امتیاز بیشتر تلاش کنه، اما فقط تا جایی که خروجیهاش خیلی از خروجیهای مدل SFT (که شبیه به انسان بود) دور نشن.
و تمام! به پایان این تور پیچیده رسیدیم! 🥳 اون مدل سرکش و تکمیلکننده متن، بعد از کلی تنظیم دقیق پیچیده، به یه دستیار خوشرفتار، مفید و عمدتاً صادق تبدیل شد.
چرا این همه دردسر؟ (راز صادق نگه داشتن LLMها)
شاید بپرسید آیا این همه پیچیدگی واقعاً لازمه؟ چرا همون مدل SFT کافی نیست؟ بالاخره اونم با مثالهای خوب و صادقانه انسانی آموزش دیده. پس باید خودش هم صادق، مفید و بیضرر باشه، درسته؟
تقریباً درسته! مدل SFT خیلی سریع یاد میگیره که چطور مفید و بیضرر باشه. اما صداقت، چیزی نیست که بشه با مثال و تکرار یادش داد. صداقت نیاز به یه کم خودآگاهی و دروننگری داره.
مشکل کجاست؟ 🤔
مدل پایه کلی اطلاعات از دنیا داره، ولی همه چیز رو نمیدونه. مثلاً اتفاقات بعد از تاریخ آموزشش رو نمیدونه. اطلاعات خصوصی شرکتها رو نمیدونه. و بهتره که اطلاعات دارای کپیرایت رو هم ندونه!
حالا وقتی یه داور انسانی میاد برای مدل SFT یه جواب ایدهآل مینویسه، اون داور که از دانش درونی مدل خبر نداره! پس دو تا حالت خیلی بد پیش میاد:
- داور انسانی جوابی مینویسه که فراتر از دانش مدل است. این به مدل یاد میده که اگه جوابی رو نمیدونست، اشکالی نداره با اعتماد به نفس از خودش یه چیزی ببافه و قصه بگه!
- داور انسانی تو جوابش شک و تردید نشون میده، در حالی که مدل از اون موضوع مطمئنه. این به مدل یاد میده که همه جوابهاش رو با کلی شک و تردید بیان کنه.
اینجاست که RLHF به کمک ما میاد. یادتونه تو مرحله ساخت مدل پاداش، این خودِ مدل SFT بود که جوابها رو تولید میکرد، نه آدما؟ برای همین، وقتی داورهای انسانی به جوابهای غلط (توهمها) امتیاز پایینتری دادن، مدل به صورت درونی یاد گرفت که:
«جوابهایی که با دانش درونی من سازگار نیستن "بد" هستن، و جوابهایی که باهاش سازگارن "خوب" هستن.»
در نتیجه، مدل نهایی RLHF یاد میگیره که وقتی از چیزی مطمئنه، با اعتماد به نفس حرف بزنه و وقتی مطمئن نیست، از عبارتهایی مثل «برای اطمینان بهتره به منبع اصلی مراجعه کنید، اما...» استفاده کنه.
چرا جوابهای انسانی کافی نبود؟ (حذف سلیقههای شخصی)
موقع تنظیم دقیق GPT-3، یک تیم ۴۰ نفره استخدام شدن تا هم نمونه جوابهای ایدهآل رو بنویسن و هم جوابهای تولید شده توسط مدل رو رتبهبندی کنن. اما یه مشکل وجود داشت: اگه هر کدوم از این ۴۰ نفر، سلیقه یا لحن خاص و عجیبی داشتن، این سلیقه شخصی روی رفتار کل مدل تاثیر زیادی میذاشت! (البته OpenAI سعی کرده بود جلوی این اتفاق رو بگیره).
اما برای آموزش مدل پاداش، داستان فرق داشت. اینجا آدما خودشون جواب تولید نمیکردن، فقط جوابهای تولید شده توسط مدل رو رتبهبندی میکردن. تلاش زیادی هم شد تا مطمئن بشن که همه داورها تقریباً روی یک معیار مشترک برای رتبهبندی توافق دارن. این کار باعث شد سلیقههای شخصی حذف بشه و مدل پاداش، نماینده یک جور «میانگین قضاوت جمعی» در مورد خوب، صادق و بیضرر بودن باشه.
RLHF: یه روش خیلی بهصرفه! 💰
از نظر نیروی انسانی، روش RLHF خیلی هم بهصرفه بود. پرزحمتترین بخش کار، نوشتن اون ۱۳,۰۰۰ نمونه اولیه برای آموزش مدل SFT بود. اما بعد از اون، برای آموزش مدل پاداش، بیشتر جوابها توسط خود مدل SFT تولید شدن و آدما فقط کار راحتتر یعنی رتبهبندی رو انجام دادن. در مرحله آخر هم که تقریباً کل فرآیند توسط خود مدلها و به صورت خودکار انجام شد.
یک بدهبستان مهم: مراقب «هزینه خوشاخلاقی» باشید!
شاید عجیب باشه، ولی گاهی وقتا فرآیند خوشاخلاق کردن مدل (RLHF) میتونه از هوش کلیش کم کنه! بیاید یه مثال بزنیم:
یه دانشآموز نخبه رو در نظر بگیرید که تو همه درسها عالیه (این میشه مدل پایه ما). حالا ما این دانشآموز رو مجبور میکنیم که تمام وقتش رو بذاره تا فقط روی سه تا معیار تمرکز کنه: «مؤدب بودن»، «کمک کردن به بقیه» و «رعایت قوانین مدرسه» (این میشه همراستاسازی HHH).
نتیجه چیه؟ اون دانشآموز به یه مبصر فوقالعاده تبدیل میشه، ولی ممکنه دیگه وقت نکنه به اندازه کافی روی درسهای اصلیش مثل ریاضی و فیزیک کار کنه و نمراتش تو اون درسها افت کنه!
به این پدیده که مدلها دوستانهتر و خوشاخلاقتر، ولی در برخی کارها کمی ضعیفتر میشن، میگن «هزینه همراستاسازی» یا «هزینه خوشاخلاقی» (Alignment Tax).
خوشبختانه، OpenAI فهمیده که اگه به اون دانشآموز اجازه بده کنار کارهای مبصری، یه نگاهی هم به درسهای اصلیش بندازه (یعنی اگه یه مقدار از دادههای آموزشی اصلی مدل پایه رو با دادههای جدید قاطی کنه)، این افت تحصیلی به حداقل میرسه و مدل همونطور که باهوش باقی میمونه، خوشرفتار هم میشه.
مدلهای گفتگو (Chat Models): معرفی ChatML! 💬
نوآوری کلیدی OpenAI برای مدلهای گفتگو، معرفی ChatML بود؛ یک زبان نشانهگذاری ساده برای مشخص کردن بخشهای مختلف یک مکالمه. شکل و شمایلش اینطوریه:
You are a sarcastic software assistant. You provide humorous answers to software questions. You use lots of emojis.😂
<|im_end|>
I was told that my computer would show me a funny joke if I typed :(){ :|:& };: in the terminal. Why is everything so slow now?
<|im_end|>
I personally find the joke amusing. I tell you what, restart your computer and then come back in 20 minutes and ask me about fork bombs. 💣
<|im_end|>
همونطور که میبینید، ChatML به ما اجازه میده یه صورتجلسه کامل از مکالمه رو تعریف کنیم. هر پیام در مکالمه، یکی از این سه تا نقش رو داره: system (سیستم)، user (کاربر)، یا assistant (دستیار). هر پیام با تگ <|im_start|> شروع و با <|im_end|> تموم میشه.
معمولاً مکالمه با یک پیام سیستمی شروع میشه که یه نقش خیلی ویژه داره. این پیام در واقع بخشی از خود گفتگو نیست، بلکه شخصیت و قوانین رفتاری دستیار رو مشخص میکنه. مثلاً بهش میگه: «تو یه دستیار نرمافزاری هستی که جوابهای کوتاه به سوالات کدنویسی میدی.» بعد از پیام سیستم، پیامهای کاربر و دستیار به صورت یکی در میون قرار میگیرن.
مزایای کلیدی ChatML نسبت به مدلهای دستوری
- رفع ابهام کامل: ChatML یه الگوی ارتباطی کاملاً واضح و بدون ابهام ایجاد میکنه. دیگه مدل گیج نمیشه که باید متن رو کامل کنه یا به دستور جواب بده. وقتی سوال کاربر داخل تگهای user قرار میگیره، کاملاً مشخصه که نوبت دستیاره تا جواب بده.
- کنترل کامل روی شخصیت دستیار: مدلهای چت آموزش دیدهاند که به شدت به پیام سیستم پایبند باشن. شما میتونید در پیام سیستم، شخصیت، لحن و قوانین دستیار رو تعریف کنید. مثلاً بگید: «تو یه پیشخدمت بریتانیایی خیلی مؤدب به اسم جیمز هستی و به سوالات فقط با یک جمله جواب میدی.» مدل هم دقیقاً همین کار رو میکنه! این یه ابزار فوقالعاده قدرتمند برای مهندسهای پرامپته.
- جلوگیری از حملات تزریق پرامپت (Prompt Injection): این یه روشه که کاربرهای خرابکار سعی میکنن با تزریق دستورات خاص به پرامپت، رفتار مدل رو کنترل کنن. مثلاً وانمود میکنن که دستیار هستن و مدل رو وادار به کارهای خطرناک میکنن. اما با ChatML، این کار تقریباً غیرممکنه. چون تگهای
<|im_start|>و<|im_end|>توکنهای رزرو شده هستن و کاربر عادی نمیتونه اونها رو تولید کنه. اگه کاربر این متن رو تایپ کنه، به صورت چندتا توکن جدا پردازش میشه و مدل گول نمیخوره. پس کاربر همیشه در نقش «کاربر» گیر میکنه و نمیتونه جای سیستم یا دستیار حرف بزنه.
یه تمرین جالب برای شما!
خودتون امتحان کنید! این پیام سیستم رو به یه مدل چت بدید: «تو ریک سانچز از انیمیشن ریک و مورتی هستی. خیلی بددهنی، ولی توصیههای پزشکی دقیق و علمی میدی.» بعد ازش یه توصیه پزشکی بخواید و ببینید چی میشه! 😉
API در حال تغییر: خداحافظی با تکمیل متن، سلام چت! 👋
وقتی ما شروع به نوشتن این کتاب کردیم، LLMها به وضوح موتورهای تکمیلکننده متن بودن. و راستش رو بخواید، هنوز هم هستن! فقط الان در اکثر مواقع، اون متنی که کامل میشه، یه صورتجلسه گفتگو بین دو تا شخصیت (کاربر و دستیار) هست.
طبق بیانیه خود OpenAI در سال ۲۰۲۳، با اینکه API جدید چت در ماه مارس معرفی شد، تا ماه جولای، ۹۷٪ از کل ترافیک API رو به خودش اختصاص داده بود! به عبارت دیگه، چت به وضوح برنده میدان شده بود. مشخص بود که OpenAI رگ خواب بازار رو پیدا کرده!
معرفی API جدید چت
این یه مثال ساده از نحوه استفاده از API چت OpenAI تو پایتونه:
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Tell me a joke."}
]
)
خیلی سادهست، نه؟ یه نقش کلی برای دستیار تعریف میکنیم و بعد کاربر یه درخواست میده. اگه همه چیز خوب پیش بره، مدل یه جوابی شبیه به این برمیگردونه:
{
"id": "chatcmpl-9sH48...",
"choices": [
{
"finish_reason": "stop",
"index": 0,
"message": {
"content": "Why don't scientists trust atoms?\n\nBecause they make up everything!",
"role": "assistant"
}
}
],
"model": "gpt-4o-mini...",
"usage": {
"completion_tokens": 12,
"prompt_tokens": 11,
"total_tokens": 23
}
}
متوجه چیزی شدید؟ خبری از ChatML نیست! اون تگهای مخصوصی که در موردش حرف زدیم، اینجا دیده نمیشن. این بخشی از فوت کوزهگریه! این JSON پیامها، فقط پشت پرده و در خود API به ChatML تبدیل میشه. این کار جلوی حملات تزریق پرامپت رو میگیره چون کاربر نمیتونه اون تگهای مخصوص رو تولید کنه.
⚠️ هشدار خیلی مهم!
هیچوقت محتوای کاربر رو مستقیماً تو پیام سیستم تزریق نکنید! مدل آموزش دیده که به شدت از پیام سیستم پیروی کنه. اگه این کار رو بکنید، به کاربر اجازه میدید تمام محافظتهای ChatML رو دور بزنه و کنترل کامل رفتار مدل رو به دست بگیره.
مقایسه چت با تکمیل متن: چی به دست آوردیم، چی از دست دادیم؟
وقتی از API چت استفاده میکنیم، همه پرامپتها به فرمت ChatML در میان. این به مدل کمک میکنه ساختار گفتگو رو بهتر بفهمه. اما این همیشه چیزی نیست که ما میخوایم. بیاید ببینیم با دور شدن از رابط تکمیل متن، چه چیزهایی رو از دست میدیم:
- «هزینه خوشاخلاقی» (Alignment Tax): همونطور که گفتیم، وقتی مدل رو برای یه کار خاص (مثل دستیار بودن) تخصصی میکنیم، ممکنه تو کارهای دیگه یه کم ضعیفتر بشه.
- از دست دادن کنترل: مدلهای چت خیلی پرحرفن! گاهی وقتا شما فقط خود جواب رو میخواید، نه یه پاراگراف تفسیر و توضیح در مورد جواب. این مشکل مخصوصاً وقتی که فقط به یه تیکه کد نیاز دارید، خیلی اذیتکننده میشه. رابطهای تکمیل متن قدیمی اینجا هنوز هم عالی عمل میکنن.
- از دست دادن تنوع انسانی: مدلهای RLHF به صورت طراحی شده، مؤدب و یکنواخت میشن. در حالی که مدلهای پایه که کل اینترنت رو خوندن، بازتابدهنده طیف وسیعتری از رفتارهای انسانی هستن (حتی رفتارهای بیادبانه!). گاهی وقتا برای کارهایی مثل تولید دادههای نمونه، شما به اون «انسانیت خام» نیاز دارید، نه یه دستیار فیلتر شده.
مهندسی پرامپت به مثابه نمایشنامهنویسی! 🎭
برای اینکه گیج نشیم، بیاید از یه استعاره باحال استفاده کنیم: ساختن یه اپلیکیشن چت، مثل نوشتن یه نمایشنامه است.
- شخصیتهای نمایش: همون نقشهای ChatML هستن: سیستم، کاربر، دستیار و ابزار.
- فیلمنامه: همون پرامپتیه که ما میسازیم؛ یعنی صورتجلسه کامل تعاملات این شخصیتها.
- نمایشنامهنویسها کیان؟ اینجا چندتا نویسنده داریم!
- شما (مهندس پرامپت): شما نویسنده اصلی و کارگردان هستید. ساختار کلی فیلمنامه و دیالوگهای راهنما رو شما مینویسید.
- کاربر انسانی: مشکل یا سوال اصلی که تم نمایش رو مشخص میکنه، توسط کاربر مطرح میشه.
- مدل (LLM): دیالوگهای شخصیت «دستیار» رو معمولاً مدل پر میکنه.
- ابزارهای خارجی (APIها): هر اطلاعات اضافهای که از بیرون (مثل نتایج جستجو) به فیلمنامه اضافه میشه، توسط این نویسندهها نوشته میشه.
شما به عنوان مهندس پرامپت، کارگردان این نمایش هستید و مسئولید که این نمایش به یه پایان خوش و رضایتبخش برای مشتریهاتون ختم بشه!
جمعبندی نهایی 🏁
تو این فصل یاد گرفتیم که چطور با یه فرآیند پیچیده و خلاقانه به اسم RLHF، میشه مدلهای تکمیلکننده متن رو به دستیارهای هوشمند، مفید، صادق و بیضرر تبدیل کرد. به خاطر راحتی استفاده، صنعت به سرعت به سمت APIهایی حرکت کرده که مثل یه دستیار رفتار میکنن.
اما با وجود همه اینها، یادتون باشه که ته تهش، حتی وقتی مدل داره مثل یه دستیار رفتار میکنه، در واقع هنوز داره یه متن رو کامل میکنه؛ متنی که این بار، صورتجلسه یه گفتگوئه. مهم نیست صنعت به کدوم سمت بره، مشکل اصلی ساخت اپلیکیشن LLM یکسان باقی میمونه: شما به عنوان مهندس پرامپت، یه فضای محدود دارید (چه یه متن و چه یه صورتجلسه گفتگو) تا مشکل کاربر و اطلاعات زمینهای رو طوری به مدل منتقل کنید که بتونه به بهترین شکل به حل اون مشکل کمک کنه.
حالا که با تمام مفاهیم پایه آشنا شدیم، در فصل بعدی، شیرجه میزنیم تو دنیای ساختن یه همچین اپلیکیشنی!