از «حدس کلمه بعدی» تا مهندسی پرامپت

قرار است آخر این فصل چه چیزی را واقعاً بفهمیم؟

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

قرار نیست از همان اول وارد فرمول و معماری‌های سنگین شویم. هر مفهوم را اول با یک تصویر ساده می‌فهمیم، بعد اسم فنی‌اش را یاد می‌گیریم. مثلاً قبل از اینکه درباره‌ی «مدل زبانی» حرف بزنیم، از همان پیشنهاد کلمه‌ی کیبورد موبایل شروع می‌کنیم.

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

1. 01چرا مدل‌های زبانی یک‌دفعه همه‌جا دیده شدند؟←
2. 02اگر LLM جادو نیست، پس در هسته‌اش چه کار می‌کند؟←
3. 03Codex نشان داد مدل می‌تواند از توضیح ما به کد برسد←
4. 04مدل زبانی یعنی چی؟ از پیشنهاد کلمه‌ی موبایل شروع کنیم←
5. 05Seq2Seq را مثل مترجم دو نفره تصور کن←
6. 06Attention یعنی مدل مجبور نباشد همه‌چیز را فقط از حافظه بخواند←
7. 07ترنسفورمر وقتی آمد که Attention قلب معماری شد←
8. 08GPT-1 چه ایده‌ای را جدی‌تر کرد؟←
9. 09وقتی چند مثال داخل پرامپت، جای آموزش جدید را گرفت←
10. 10چرا طراحی ورودی تبدیل به یک کار مهندسی شد؟←
11. 11مهندسی پرامپت فقط «خوب سؤال پرسیدن» نیست←
12. 12بین مشکل واقعی کاربر و LLM یک مترجم لازم داریم←
13. 13وقتی جواب متنی کافی نیست و سیستم باید کاری انجام بدهد←
14. 14Agent چه چیزی بیشتر از یک چت‌بات دارد؟←
15. 15پنج تصور رایج که بهتر است همین اول کنارشان بگذاریم←
16. 16قبل از اینکه بگویی «پرامپتم خوبه»، این‌ها را چک کن←
17. 17از این فصل چه چیزی باید واقعاً در ذهنت بماند؟←

چرا مدل‌های زبانی یک‌دفعه همه‌جا دیده شدند؟

اواخر سال ۲۰۲۲ اتفاق مهمی افتاد: چیزی که قبلاً بیشتر دست پژوهشگرها و تیم‌های تخصصی بود، تبدیل شد به ابزاری که هر کسی می‌توانست با آن حرف بزند. ChatGPT باعث شد برای استفاده از یک مدل زبانی دیگر لازم نباشد API یا یادگیری ماشین بلد باشی؛ کافی بود حرفت را با زبان معمولی بنویسی.

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

در برنامه‌نویسی این تفاوت خیلی واضح بود. به‌جای رفت‌وآمد بین مستندات، Stack Overflow و مقاله‌ها، می‌توانستی کد و خطا را بدهی و بگویی: «این چرا کار نمی‌کند؟ قدم‌به‌قدم توضیح بده.» مدل هم جواب را متناسب با همان مسئله‌ی تو می‌ساخت.

اگر LLM جادو نیست، پس در هسته‌اش چه کار می‌کند؟

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

مدل ذهنی ساده‌تر این است: مدل زبانی تلاش می‌کند ادامه‌ی مناسب متن را پیش‌بینی کند. تو یک تکه متن و اطلاعات به آن می‌دهی، مدل هم بر اساس الگوهایی که در زمان آموزش دیده، حدس می‌زند ادامه‌ی مناسب چه می‌تواند باشد.

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

Codex نشان داد مدل می‌تواند از توضیح ما به کد برسد

قبل از موج Copilot، ابزارهای تکمیل کد بیشتر شبیه autocomplete بودند: چند کلمه یا یک الگوی کوتاه را حدس می‌زدند. چیزی که با مدل‌هایی مثل Codex جذاب شد این بود که مدل می‌توانست از روی توضیح انسانی، بخش بزرگ‌تری از کد را بسازد.

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

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

چطور ممکن است با زبانی که خیلی بلد نیستی، چیزی بسازی؟

فرض کن منطق یک مسئله را می‌فهمی، ولی زبان برنامه‌نویسی‌اش را خوب بلد نیستی. مثلاً می‌دانی تابع باید عدد ۲۰۳۴ را به عبارت «دو هزار و سی و چهار» تبدیل کند، اما Rust را تازه شروع کرده‌ای.

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

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

مدل زبانی یعنی چی؟ از پیشنهاد کلمه‌ی موبایل شروع کنیم

ایده‌ی مدل زبانی خیلی قدیمی‌تر از ChatGPT است. ساده‌ترین نمونه‌اش همان پیشنهاد کلمه‌ی کیبورد موبایل است: چند کلمه تایپ می‌کنی و سیستم حدس می‌زند بعدش چه چیزی محتمل‌تر است.

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

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

Seq2Seq را مثل مترجم دو نفره تصور کن

قبل از ترنسفورمر، یکی از معماری‌های مهم برای ترجمه و کارهای زبانی Sequence-to-Sequence یا به‌اختصار Seq2Seq بود. اسمش ساده است: یک دنباله می‌گیرد و یک دنباله‌ی دیگر تحویل می‌دهد.

در ترجمه مثلاً جمله‌ی انگلیسی وارد می‌شود و جمله‌ی فارسی بیرون می‌آید. این معماری معمولاً دو بخش داشت: Encoder که ورودی را می‌خواند و Decoder که خروجی را می‌نویسد.

نسخه‌های قدیمی‌تر این سیستم‌ها معمولاً از شبکه‌های بازگشتی یا RNN استفاده می‌کردند؛ یعنی جمله را مرحله‌به‌مرحله می‌خواندند و یک حافظه‌ی داخلی را جلو می‌بردند.

توکن، بردار و امبدینگ را قبل از ادامه خیلی ساده کنیم

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

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

بردار یعنی چند عدد کنار هم. شبکه‌ی عصبی نمی‌تواند «معنای کلمه» را مثل ما بفهمد، پس اطلاعات را به عدد تبدیل می‌کند.

امبدینگ همان نمایش عددیِ توکن است؛ یعنی مدل هر تکه‌ی متن را به مجموعه‌ای از عددها تبدیل می‌کند تا بتواند روی آن محاسبه انجام دهد.

Encoder مثل کسی است که متن را می‌خواند و در ذهنش جمع‌بندی می‌کند

Encoder بخشِ «خواندن» در معماری Seq2Seq است. جمله را تکه‌تکه می‌خواند و بعد از هر بخش، وضعیت داخلی خودش را به‌روز می‌کند.

این وضعیت داخلی قرار است چیزهایی را که تا این لحظه از جمله فهمیده، نگه دارد. هرچه جلوتر می‌رویم، خلاصه‌ی داخلی تغییر می‌کند.

مشکل از جایی شروع می‌شود که ورودی طولانی باشد: آیا واقعاً می‌توان همه‌ی جزئیات یک متن بلند را داخل یک حافظه‌ی محدود جا داد؟

وقتی باید یک متن کامل را داخل یک «یادداشت کوچک» جا بدهیم

در Seq2Seq کلاسیک، وقتی Encoder به آخر جمله می‌رسید، وضعیت نهایی را به Decoder می‌دادند. به این نمایش فشرده گاهی Thought Vector می‌گفتند.

اسمش شاید عجیب باشد؛ منظور «فکر واقعی» نیست. فقط یک بسته‌ی عددی ثابت است که قرار است اطلاعات مهم ورودی را با خودش حمل کند.

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

Decoder همان بخشی است که با اطلاعات جمع‌شده، خروجی را می‌نویسد

اگر Encoder را خواننده‌ی متن بدانیم، Decoder نویسنده‌ی خروجی است. اطلاعات فشرده را می‌گیرد و خروجی را توکن‌به‌توکن تولید می‌کند.

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

در مدل کلاسیک، Decoder تقریباً مجبور بود بیشترِ فهم خود را از همان Thought Vector بگیرد؛ و دقیقاً همین موضوع مشکل ایجاد می‌کرد.

شکل منتخب از منبع - مدل ترجمه‌ی Seq2Seq با Encoder، Thought Vector و Decoder.

🔎 به کجای شکل دقت کنیم؟ تمام اطلاعات ورودی از مسیر باریک Thought Vector به Decoder منتقل می‌شود. همین نقطه، گلوگاه معماری است.

چرا یک خلاصه‌ی ثابت برای متن‌های بلند کافی نبود؟

حالا مشکل را واضح می‌بینیم: حجم زیادی از اطلاعات باید از یک مسیر باریک عبور کند. به این وضعیت گلوگاه اطلاعات می‌گوییم.

برای جمله‌ی کوتاه شاید مسئله‌ی بزرگی نباشد. اما در جمله یا متن بلند، اطلاعات اول متن ممکن است تا زمانی که Decoder به آن نیاز دارد کم‌رنگ شده باشد.

اینجا سؤال مهمی مطرح شد: چرا Decoder فقط یک خلاصه‌ی ثابت بگیرد؟ چرا نتواند هر وقت لازم شد، مستقیم به قسمت مناسبِ ورودی نگاه کند؟

Attention یعنی مدل مجبور نباشد همه‌چیز را فقط از حافظه‌ی فشرده یادش بماند

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

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

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

ترنسفورمر وقتی آمد که Attention از یک کمک جانبی به قلب معماری تبدیل شد

در سال ۲۰۱۷ معماری Transformer معرفی شد. مدل‌های قبلی معمولاً جمله را مرحله‌به‌مرحله و با وابستگی مستقیم به وضعیت قبلی پردازش می‌کردند. ترنسفورمر مسیر متفاوتی رفت و Attention را در مرکز کار قرار داد.

این معماری توانست رابطه‌ی بین توکن‌های مختلف را بهتر و موازی‌تر بررسی کند. همین موضوع آموزش مدل‌های بزرگ‌تر را عملی‌تر کرد.

ترنسفورمر اصلی هنوز بخش Encoder و Decoder داشت، اما خانواده‌ی GPT بعداً بیشتر از سمت تولیدکننده‌ی این معماری الهام گرفت.

چهار واژه‌ی روی شکل Transformer را خیلی ساده بخوانیم

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

Multi-Head Attention یعنی مدل چند نوع رابطه را هم‌زمان دنبال کند. یک مسیر ممکن است روی ارتباط فاعل و فعل حساس باشد، مسیر دیگر روی فاصله‌ی بین کلمات.

Positional Encoding اطلاعات ترتیب را اضافه می‌کند. چون «سگ علی را گاز گرفت» با «علی سگ را گاز گرفت» یک معنی ندارد.

Feed Forward یک شبکه‌ی کوچک در هر لایه است که نمایش هر موقعیت را بیشتر پردازش می‌کند. در پایان هم Softmax امتیازها را به احتمال تبدیل می‌کند.

شکل منتخب از منبع - معماری اصلی Transformer با سمت Encoder و Decoder.

🔎 به کجای شکل دقت کنیم؟ Attention در هر دو سمت چند بار تکرار شده و ساختار Layerها روی هم Stack شده‌اند. این معماری بعدها پایه‌ی مستقیم خانواده‌ی GPT شد.

مدل هم یک میز کار با اندازه‌ی محدود دارد

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

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

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

GPT-1 چه ایده‌ای را جدی‌تر کرد؟

در سال ۲۰۱۸ خانواده‌ی GPT با ایده‌ای مهم وارد شد: اول مدل را روی حجم زیادی متن عمومی آموزش بده، بعد اگر لازم بود برای یک کار خاص کمی تخصصی‌ترش کن.

اسم GPT از سه بخش می‌آید: Generative یعنی تولیدکننده، Pre-trained یعنی از قبل آموزش‌دیده، و Transformer هم معماری پایه‌ی آن است.

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

پارامتر یعنی چه و چرا بزرگ‌تر شدن مدل مهم شد؟

وقتی می‌شنوی یک مدل چند میلیارد پارامتر دارد، منظور چند میلیارد «قانون نوشته‌شده توسط آدم‌ها» نیست. پارامترها عددهایی هستند که مدل در زمان آموزش تنظیم می‌کند.

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

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

وقتی یک مدل عمومی روی چند کار مختلف از خودش توانایی نشان داد

با GPT-2 اتفاق جالبی افتاد. مدل بزرگ‌تر و روی داده‌ی بیشتری آموزش دیده بود و بدون اینکه برای هر کار جداگانه Fine-tune شود، روی چند کار زبانی رفتار قابل‌توجهی نشان می‌داد.

این موضوع ذهنیت پژوهشگران را تغییر داد. قبلاً سؤال این بود: «برای این کار چه مدل تخصصی بسازیم؟» کم‌کم سؤال جدیدی شکل گرفت: «آیا می‌توانیم همین مدل عمومی را با ورودی مناسب روی کارهای مختلف هدایت کنیم؟»

بعضی توانایی‌ها با بزرگ‌تر شدن مدل واضح‌تر ظاهر شدند؛ توانایی‌هایی که نسخه‌های کوچک‌تر یا اصلاً نشان نمی‌دادند یا خیلی ضعیف بودند.

چرا بهترشدن تولید متن، نگرانی سوءاستفاده هم ایجاد کرد؟

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

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

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

وقتی چند مثال داخل پرامپت، جای آموزش جدید را گرفت

یکی از مهم‌ترین چیزهایی که GPT-3 نشان داد این بود که برای عوض‌کردن کار مدل همیشه لازم نیست وزن‌هایش را دوباره آموزش دهیم. گاهی کافی است چند مثال داخل همان پرامپت بگذاریم.

مدل با دیدن الگوی مثال‌ها می‌فهمد احتمالاً چه کاری از آن می‌خواهیم و همان الگو را ادامه می‌دهد. این اتفاق بدون تغییر پارامترهای مدل رخ می‌دهد.

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

چرا طراحی ورودی تبدیل به یک کار مهندسی شد؟

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

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

این روش سرعت ساخت محصول را بالا می‌برد، چون برای هر تغییر کوچک لازم نیست یک دوره‌ی آموزش جدید اجرا کنی. البته بعضی مسئله‌ها هنوز به Fine-tuning نیاز دارند؛ پرامپت جای همه‌چیز را نمی‌گیرد.

مدل‌ها فقط قوی‌تر نشدند؛ استفاده از آن‌ها هم ساده‌تر شد

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

هم‌زمان مدل‌های کوچک‌تر و سریع‌تر هم بهتر شدند. برای ما مهم نیست همه‌ی برندها را حفظ کنیم؛ روند مهم این است که مدل عمومی‌تر و در دسترس‌تر شد.

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

جدول رشد GPT را چطور بخوانیم که در عددها گم نشویم؟

در جدول‌های تاریخی GPT معمولاً تعداد پارامترها، حجم داده و توان محاسباتی نسل‌های مختلف را می‌بینی. لازم نیست اعداد را حفظ کنی؛ چیزی که مهم است روند رشد است.

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

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

جدول منتخب از منبع - مقایسه‌ی تاریخی چند نسل GPT از نظر اندازه، داده‌ی آموزشی و Compute.

🔎 به کجای جدول دقت کنیم؟ رشد چند مرتبه‌ای Scale را ببین. اعداد GPT-4 در منبع صراحتاً «rumored/estimated» معرفی شده‌اند و نباید به‌عنوان مشخصات رسمی در نظر گرفته شوند.

مهندسی پرامپت فقط «خوب سؤال پرسیدن» نیست

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

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

از طرف دیگر خروجی مدل هم همیشه قرار نیست مستقیم به کاربر نمایش داده شود. شاید لازم باشد بررسی شود، به JSON تبدیل شود، وارد یک API شود یا فقط بخشی از آن استفاده شود.

چرا گاهی پرامپت را مثل یک سند ساختگی می‌سازیم؟

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

به چنین ساختاری می‌توان شبه‌سند گفت. داخل آن می‌تواند سؤال کاربر، تاریخچه، قوانین، چند مثال و بخش‌هایی از مستندات کنار هم قرار بگیرند.

هدف این نیست که مدل بفهمد این سند «واقعی» است؛ هدف این است که اطلاعات لازم را در یک ساختار قابل‌فهم و قابل‌ادامه در اختیارش بگذاریم.

بین مشکل واقعی کاربر و LLM یک مترجم لازم داریم

کاربر در دنیای واقعی «مسئله» دارد؛ مدل فقط متن و داده می‌بیند. پس یک لایه‌ی نرم‌افزاری باید این دو دنیا را به هم وصل کند.

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

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

Thin Application یعنی برنامه تقریباً همان حرف کاربر را مستقیم به مدل بدهد

ساده‌ترین حالت این است که برنامه تقریباً هیچ چیز خاصی به ورودی اضافه نکند. متن کاربر را می‌گیرد، کمی قالب‌بندی می‌کند و به مدل می‌فرستد.

برای نمونه‌های اولیه و کارهای ساده این روش عالی است؛ چون سریع و کم‌هزینه است.

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

وقتی برنامه قبل از پرسیدن از مدل، اطلاعات لازم را جمع می‌کند

در سطح بعد، برنامه ورودی کاربر را با اطلاعات مرتبط کامل می‌کند. مثلاً یک دستیار کدنویسی علاوه بر فایل فعلی، چند تکه از فایل‌های مرتبط را هم داخل زمینه می‌گذارد.

یک سیستم پشتیبانی می‌تواند سؤال کاربر را با تاریخچه‌ی حساب و مستندات مرتبط ترکیب کند. این کار را Context Augmentation یا غنی‌سازی زمینه می‌نامیم.

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

چرا یک گفت‌وگوی چندمرحله‌ای بدون نگه‌داشتن گذشته ناقص می‌شود؟

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

این یعنی بیشترِ چیزی که ما به‌عنوان «حافظه‌ی چت» می‌بینیم، در لایه‌ی برنامه مدیریت می‌شود. برنامه تاریخچه را ذخیره می‌کند و بخش مناسبش را دوباره وارد زمینه می‌کند.

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

وقتی جواب متنی کافی نیست و سیستم باید واقعاً کاری انجام بدهد

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

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

اما اجرای واقعی ابزار معمولاً بر عهده‌ی خود برنامه است. نتیجه‌ی ابزار دوباره وارد زمینه می‌شود و مدل با دیدن نتیجه ادامه می‌دهد.

وصل‌کردن API تازه شروع کار است؛ خطاها از همین‌جا جدی می‌شوند

وقتی ابزار وارد سیستم می‌شود، مسئله‌های تازه‌ای داریم. اگر دو نفر به اسم سارا در مخاطبان باشند چه؟ اگر API تقویم خطا بدهد؟ اگر مدل تاریخ را با فرمت اشتباه بفرستد؟

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

مدل نباید هر خروجی دلخواهی را مستقیم اجرا کند. برنامه باید بین «پیشنهاد مدل» و «عمل واقعی» یک لایه‌ی کنترل داشته باشد.

به‌جای گفتن تک‌تک قدم‌ها، فقط هدف را بدهیم چه می‌شود؟

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

مثلاً به‌جای اینکه بگویی «اول هتل‌ها را جست‌وجو کن، بعد قیمت را مقایسه کن، بعد پرواز را ببین»، می‌گویی «برای آخر هفته یک سفر دو روزه‌ی ارزان برنامه‌ریزی کن».

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

Agent چه چیزی بیشتر از یک چت‌بات دارد؟

چت‌بات معمولاً پیام می‌گیرد و پاسخ می‌دهد. Agent معمولاً چند جزء اضافه دارد: هدف، وضعیت، ابزار، انتخاب اقدام و یک چرخه‌ی چندمرحله‌ای.

یعنی ممکن است ابتدا اطلاعات جمع کند، بعد ابزار صدا بزند، نتیجه را بررسی کند و بر اساس همان نتیجه تصمیم بعدی بگیرد.

البته اسم‌گذاری در صنعت همیشه کاملاً یکسان نیست. برای فهم این فصل کافی است بدانیم Agent بیشتر از یک «پاسخ‌دهنده‌ی متنی» است؛ یک جریان تصمیم و عمل دارد.

پنج تصور رایج که بهتر است همین اول کنارشان بگذاریم

۱) «مهندسی پرامپت یعنی پیدا کردن کلمات جادویی.»
نه. انتخاب کلمه مهم است، اما زمینه، مثال، تاریخچه، ابزار و پردازش خروجی هم همان‌قدر مهم‌اند.

۲) «مدل قوی‌تر یعنی محصول بهتر.»
نه لزوماً. اگر اطلاعات اشتباه یا ناقص به مدل بدهی، مدل بسیار قوی هم می‌تواند جواب بد بدهد.

۳) «حافظه داخل خود مدل است.»
در خیلی از محصولات، تاریخچه بیرون از مدل ذخیره و در زمان لازم دوباره وارد زمینه می‌شود.

۴) «Tool Call یعنی مدل خودش API را اجرا کرد.»
مدل معمولاً فقط درخواستِ استفاده از ابزار را تولید می‌کند؛ اجرای واقعی بر عهده‌ی برنامه است.

۵) «پرامپت فقط همان پیام کاربر است.»
در سیستم واقعی، پرامپت می‌تواند ترکیبی از پیام کاربر، قوانین، تاریخچه، اسناد و نتیجه‌ی ابزارها باشد.

از پیشنهاد کلمه تا مهندسی پرامپت، مسیر را یک بار جمع کنیم

مدل زبانی: احتمال ادامه‌ی متن را یاد می‌گیرد.

Seq2Seq: ورودی را با Encoder می‌خواند و خروجی را با Decoder می‌سازد.

گلوگاه اطلاعات: یک خلاصه‌ی ثابت برای متن‌های بلند کافی نبود.

Attention: اجازه داد مدل هرجا لازم شد روی بخش مرتبط تمرکز کند.

Transformer: Attention را به قلب معماری تبدیل کرد.

GPT-1: پیش‌آموزش عمومی + آموزش تکمیلی را جدی کرد.

GPT-2: نشان داد افزایش مقیاس، توانایی‌های عمومی‌تر ایجاد می‌کند.

GPT-3: Few-shot نشان داد با چند مثال داخل پرامپت می‌توان کار مدل را تغییر داد.

محصولات LLM: لایه‌ی برنامه، زمینه، حافظه و ابزارها را به مدل اضافه کردند.

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

مسیر تاریخی: Seq2Seq → Attention → Transformer → GPT → مهندسی پرامپت.

مسیر یک محصول: نیاز واقعی کاربر → برنامه → پرامپت و زمینه → LLM → پاسخ یا عمل.

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

اصطلاحات پایه‌ی مدل‌های زبانی

LLM: مدل زبانی بزرگی که با حجم زیادی داده آموزش دیده و بر اساس زمینه، متن تولید می‌کند.

Language Model: مدلی برای پیش‌بینی ادامه‌ی یک دنباله‌ی زبانی.

Prompt: متن و اطلاعاتی که به مدل می‌دهیم.

Completion / Response: ادامه یا پاسخی که مدل تولید می‌کند.

Token: واحدی از متن که مدل پردازش می‌کند.

Embedding: نمایش عددی توکن یا داده.

Vector: فهرستی مرتب از عددها.

Parameter: عدد قابل یادگیری داخل شبکه.

Context Window: مقدار متنی که مدل در یک نوبت می‌تواند ببیند.

Scale: بزرگ‌تر شدن مدل، داده و توان محاسباتی.

اسم‌های فنی معماری را یک بار خیلی ساده مرور کنیم

Seq2Seq: تبدیل یک دنباله به دنباله‌ی دیگر.

RNN: شبکه‌ای که اطلاعات مرحله‌ی قبلی را به مرحله‌ی بعد می‌برد.

Encoder: بخش خواندن و ساخت نمایش داخلی از ورودی.

Decoder: بخش تولید خروجی.

Hidden State: حافظه‌ی عددی موقت شبکه.

Thought Vector: خلاصه‌ی عددی ثابت ورودی در Seq2Seq کلاسیک.

Information Bottleneck: محدودیت عبور اطلاعات زیاد از کانال کوچک.

Attention: تمرکز بیشتر روی بخش‌های مرتبط.

Transformer: معماری مبتنی بر Attention.

Multi-Head Attention: چند مسیر توجه موازی.

Positional Encoding: اطلاعات ترتیب توکن‌ها.

Feed Forward: شبکه‌ی داخلی برای پردازش بیشتر نمایش‌ها.

این اصطلاحات را با معنی فارسی‌شان نگه دار

Pre-training — پیش‌آموزش: آموزش اولیه‌ی مدل روی داده‌ی بزرگ و عمومی.

Fine-tuning — آموزش تکمیلی: آموزش بیشتر برای کار یا رفتار مشخص.

Unlabeled Data — داده‌ی بدون برچسب: داده‌ی خام بدون پاسخ یا دسته‌بندی دستی.

Few-shot: نشان‌دادن چند مثال داخل پرامپت.

In-context Learning: یادگرفتن الگو از زمینه‌ی همان درخواست بدون تغییر وزن‌های مدل.

Conditioning: جهت‌دادن رفتار مدل با اطلاعات و الگوهای ورودی.

Prompt Engineering: طراحی پرامپت، زمینه و جریان تعامل برای رسیدن به خروجی مفید.

Pseudodocument: سند ساختگی و منظم‌شده‌ای که برنامه برای مدل می‌سازد.

Application Layer: منطق نرم‌افزاری بین کاربر و مدل.

اصطلاحات سیستم‌های واقعی LLM

Context Augmentation — غنی‌سازی زمینه: اضافه‌کردن اطلاعات مرتبط قبل از فراخوانی مدل.

State: اطلاعاتی که بین درخواست‌ها نگه داشته می‌شود.

Stateful: سیستمی که گذشته روی رفتار فعلی‌اش اثر دارد.

Summarization: خلاصه‌کردن تاریخچه برای حفظ نکات مهم با متن کمتر.

Tool: قابلیت بیرونی مثل جست‌وجو، تقویم یا پایگاه داده.

API: راه استاندارد ارتباط نرم‌افزارها با یکدیگر.

Validation: بررسی ورودی یا خروجی قبل از استفاده.

Agency: توان انتخاب مراحل و اقدام‌ها برای رسیدن به هدف.

Autonomy: میزان آزادی سیستم در تصمیم‌گیری.

AI Agent: سیستمی چندمرحله‌ای که می‌تواند هدف بگیرد، اطلاعات جمع کند و ابزار استفاده کند.

قبل از اینکه بگویی «پرامپتم خوبه»، این‌ها را چک کن

✅ دقیقاً می‌دانم کاربر چه مسئله‌ای را می‌خواهد حل کند.

✅ می‌دانم چه اطلاعاتی باید داخل زمینه باشد و چه چیزهایی بی‌ربط‌اند.

✅ اگر متن کاربر کافی نیست، برنامه اطلاعات مرتبط را اضافه می‌کند.

✅ تاریخچه فقط وقتی لازم است وارد پرامپت می‌شود.

✅ برای گفت‌وگوی طولانی، راهی برای حذف یا خلاصه‌سازی دارم.

✅ کارهایی که نیاز به داده‌ی واقعی دارند با ابزار انجام می‌شوند، نه با حدس مدل.

✅ ورودی ابزارها قبل از اجرا اعتبارسنجی می‌شود.

✅ می‌دانم کدام تصمیم باید با مدل و کدام با کد قطعی انجام شود.

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

✅ مدل را جادویی فرض نمی‌کنم و محدودیت‌هایش را در طراحی لحاظ می‌کنم.

از این فصل چه چیزی باید واقعاً در ذهنت بماند؟

داستان را با چیزی شروع کردیم که شبیه جادو بود: مدلی که حرف می‌زند، کد می‌نویسد و مسئله حل می‌کند. بعد دیدیم هسته‌ی ماجرا از ایده‌ی ساده‌ی پیش‌بینی ادامه‌ی متن شروع می‌شود.

Seq2Seq با Encoder و Decoder قدم مهمی بود، اما خلاصه‌ی ثابتِ ورودی گلوگاه ایجاد می‌کرد. Attention اجازه داد مدل مستقیماً روی بخش مرتبط تمرکز کند و Transformer همین ایده را به قلب معماری برد.

خانواده‌ی GPT نشان داد پیش‌آموزش روی داده‌ی بزرگ می‌تواند یک مدل عمومی بسازد. با افزایش مقیاس، توانایی‌های بیشتری ظاهر شدند و GPT-3 نشان داد چند مثال داخل پرامپت می‌تواند بدون آموزش دوباره، رفتار مدل را برای یک کار جدید هدایت کند.

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

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