مدل زبانی یعنی چه؟
تعریف رسمی‌اش این است: مدل زبانی اطلاعات آماری یک یا چند زبان را در خود ذخیره می‌کند. ولی بیایید ساده‌تر بگوییم.
یک دوست را تصور کنید که عادت دارد جمله‌های شما را تمام کند. می‌گویید «رنگ مورد علاقهٔ من ...» و او می‌گوید «آبی». چرا آبی گفت و نگفت «ماشین»؟ چون در تمام عمرش هزاران بار شنیده که بعد از این جمله یک رنگ می‌آید، نه یک وسیلهٔ نقلیه. او قاعدهٔ دستور زبان را حفظ نکرده — فقط آمار را از تجربه بلد است.
یک LLM در اصل یک ماشین تکمیل جمله است. متنی به آن می‌دهید (به آن متن پرامپت می‌گویند) و او سعی می‌کند ادامه‌اش را بنویسد. همین. تمام کارهای خارق‌العاده‌ای که می‌بینید، از همین یک قابلیت ساده بیرون می‌آید.
توکن: واحد شمارش دنیای مدل‌ها
مدل با «کلمه» کار نمی‌کند و با «حرف» هم کار نمی‌کند. واحد کارش چیزی بین این دو است که به آن توکن می‌گویند. کار شکستن متن به توکن را توکن‌سازی (tokenization) می‌نامند، و مجموعهٔ همهٔ توکن‌هایی که یک مدل می‌شناسد واژگان (vocabulary) آن مدل است.
با حدود ۳۲ هزار قطعهٔ لگو می‌توانید میلیون‌ها چیز بسازید. اگر واحد ساخت را «حرف» بگذاریم، قطعات خیلی ریزند و ساختن هر چیزی طول می‌کشد. اگر «کلمه» بگذاریم، باید برای هر کلمهٔ فارسی و انگلیسی و هر کلمهٔ تازه‌ساخته یک قطعهٔ جدا داشته باشیم — انبار بی‌نهایت می‌شود. توکن حد وسط است: مثلاً کلمهٔ cooking به دو قطعهٔ cook و ing شکسته می‌شود؛ هر دو قطعه معنی دارند و قابل استفادهٔ مجددند.
همین ترفند باعث می‌شود مدل با کلمه‌ای که تا حالا ندیده هم کنار بیاید. کلمهٔ ساختگی chatgpting را می‌شکند به chatgpt و ing و حدس می‌زند که احتمالاً فعل است.
برای متن انگلیسی، هر توکن به‌طور میانگین حدود سه‌چهارم یک کلمه است. یعنی ۱۰۰ توکن تقریباً برابر ۷۵ کلمه. این را یادتان باشد، چون بعداً هزینهٔ API و محدودیت طول متن، هر دو بر حسب توکن حساب می‌شوند نه کلمه. برای فارسی نسبت بدتر است: چون بیشتر مدل‌ها عمدتاً روی متن انگلیسی آموزش دیده‌اند، متن فارسی به توکن‌های بیشتری شکسته می‌شود — یعنی همان جمله برای شما گران‌تر تمام می‌شود.
دو نوع مدل زبانی
از این به بعد هرجا فقط بگوییم «مدل زبانی»، منظورمان نوع خودبازگشتی است — چون امروز تقریباً تمام کارهای تولید متن با همین نوع انجام می‌شود.
چرا این یکی منفجر شد و بقیه نه؟
مدل زبانی فقط یکی از ده‌ها الگوریتم یادگیری ماشین است. مدل تشخیص چهره داریم، مدل پیش‌بینی آب‌وهوا داریم، مدل پیشنهاد فیلم داریم. پس چرا لحظهٔ انفجاری هوش مصنوعی با مدل زبانی رقم خورد؟
جواب در یک کلمه است: خودنظارتی (self-supervision).
روش سنتی، نظارت‌شده (supervised) بود: باید هزاران نمونه را دستی برچسب می‌زدید تا مدل یاد بگیرد. می‌خواهید مدل تقلب بانکی را تشخیص دهد؟ باید روی هزاران تراکنش دستی بنویسید «تقلب» یا «سالم».
فرض کنید برچسب زدن هر عکس ۵ سنت آب بخورد. برای یک میلیون عکس می‌شود ۵۰ هزار دلار. اگر بخواهید دو نفر مستقل هر عکس را برچسب بزنند تا کیفیت را چک کنید، دو برابر. و این برای «سگ» و «گربه» است که هر کسی بلد است. حالا تصور کنید بخواهید یک رادیولوژیست هزاران عکس سی‌تی‌اسکن را برچسب بزند — عملاً غیرممکن.
خودنظارتی این گلوگاه را کنار می‌زند. ایدهٔ نابغه‌وارش این است: خود متن، برگهٔ پاسخ خودش است. هیچ انسانی لازم نیست چیزی برچسب بزند.
یک جملهٔ ساده را ببینید. از همین یک جمله، مدل به‌طور خودکار چند نمونهٔ آموزشی می‌سازد:
آن <BOS> و <EOS> دو توکن ویژه‌اند: BOS علامت شروع متن و EOS علامت پایان. دومی خیلی مهم‌تر از آن چیزی است که به‌نظر می‌رسد — همین توکن است که به مدل می‌گوید کِی حرفش را تمام کند. بدون آن، مدل تا ابد ادامه می‌دهد.
متن همه‌جا هست: کتاب، ویکی‌پدیا، وبلاگ، کامنت اینترنتی. وقتی برای آموزش هیچ برچسب دستی لازم نباشد، حجم دادهٔ آموزشی عملاً بی‌نهایت می‌شود. و وقتی داده بی‌نهایت شد، می‌شود مدل را بزرگ و بزرگ‌تر کرد. این‌طور بود که «مدل زبانی» تبدیل شد به «مدل زبانی بزرگ».
خودنظارتی با بدون‌نظارت (unsupervised) فرق دارد. در خودنظارتی برچسب وجود دارد، منتها از خود داده استخراج می‌شود. در بدون‌نظارت اصلاً برچسبی در کار نیست.
چقدر بزرگ، بزرگ است؟
اندازهٔ مدل را با تعداد پارامترهایش می‌سنجند. پارامتر یعنی یک عدد داخل مدل که در جریان آموزش تنظیم می‌شود — مثل یک پیچ تنظیم روی یک دستگاه غول‌پیکر. هرچه پیچ بیشتر، ظرفیت یادگیری بیشتر (البته نه همیشه).
معیار «بزرگ» مدام عوض می‌شود. در سال ۲۰۱۸ مدلی با ۱۱۷ میلیون پارامتر بزرگ حساب می‌شد؛ یک سال بعد همان عدد کوچک شد. امروز صد میلیارد پارامتر بزرگ است، و احتمالاً چند سال دیگر همین هم کوچک به‌نظر می‌رسد.
مدل بزرگ‌تر ظرفیت یادگیری بیشتری دارد، پس برای اینکه آن ظرفیت هدر نرود به دادهٔ بیشتری نیاز دارد. می‌توانید مدل غول‌پیکری را روی دادهٔ کم آموزش دهید، ولی آن‌وقت پول و برق را دور ریخته‌اید — با مدل کوچک‌تر هم به همان نتیجه می‌رسیدید.
قدم آخر: از LLM به مدل پایه
مدل زبانی فقط متن می‌فهمد. ولی ما آدم‌ها دنیا را فقط با زبان درک نمی‌کنیم — می‌بینیم، می‌شنویم، لمس می‌کنیم. برای اینکه هوش مصنوعی در دنیای واقعی کار کند، باید فراتر از متن برود.
مدلی که با بیش از یک نوع داده کار می‌کند چندوجهی (multimodal) نام دارد. اگر چندوجهی و مولد باشد، به آن LMM می‌گویند. وقتی این مدل‌ها هم بزرگ شدند و هم چندوجهی، اصطلاح LLM دیگر کافی نبود. اینجا بود که نام مدل پایه یا FM باب شد.
مثل فونداسیون یک ساختمان. فونداسیون به‌تنهایی خانه نیست، ولی روی یک فونداسیون خوب می‌شود خانه، مغازه یا مدرسه ساخت. مدل پایه هم به‌تنهایی محصول نیست؛ زیرساختی است که ده‌ها محصول مختلف روی آن بنا می‌شود. این کلمه هر دو معنی را با هم می‌رساند: بنیادی بودن و قابل بنا شدن.
سه راه برای رام کردن مدل
مدل پایه از جعبه که بیرون می‌آید همه‌منظوره است. برای کار شما «خوب» است ولی «عالی» نیست. فرض کنید می‌خواهید برای یک فروشگاه، توضیح محصول بنویسد. مدل متن درستی تولید می‌کند، اما لحن برند شما را ندارد و پر از کلیشه‌های تبلیغاتی است.
سه ابزار برای حل این مشکل دارید. کل باقی این دوره، شرح همین سه‌تاست:
همیشه از ساده‌ترین شروع کنید. تطبیق دادن یک مدل آماده با کار شما معمولاً «ده نمونه و یک آخر هفته» وقت می‌برد، در حالی که ساختن مدل از صفر «یک میلیون نمونه و شش ماه» است. اکثر تیم‌ها مستقیم سراغ تنظیم دقیق می‌روند در حالی که یک پرامپت بهتر مشکلشان را حل می‌کرد.
خودآزمایی
فهرست کردن تمام کاربردهای ممکن مدل‌های پایه عملاً شدنی نیست؛ هر روز چیز تازه‌ای اضافه می‌شود. ولی الگوها محدودند. اگر الگوها را بشناسید، می‌توانید فرصت‌های امروز را ببینید و حدس بزنید فردا چه می‌آید.
هشت دستهٔ اصلی
قاعدهٔ سرانگشتی: کجا خوب است، کجا نه
یک پژوهش معروف، شغل‌ها را بر اساس «میزان در معرض بودن» نسبت به هوش مصنوعی رتبه‌بندی کرده است. تعریفشان دقیق است: یک کار در معرض است اگر هوش مصنوعی بتواند زمان انجامش را دست‌کم نصف کند.
نتیجه، الگوی روشنی دارد. شغل‌هایی با بیشترین در معرض بودن: مترجم، پژوهشگر نظرسنجی، نویسنده، کارشناس روابط عمومی، حسابدار مالیاتی، طراح وب. شغل‌هایی با کمترین: آشپز، سنگ‌تراش، ورزشکار.
هرجا کار اصلی جابه‌جا کردن نماد و متن باشد — کلمه، عدد، کد، قرارداد — هوش مصنوعی قوی است. هرجا کار اصلی دست بردن در دنیای فیزیکی باشد، تقریباً بی‌فایده است. این ساده‌ترین فیلتری است که می‌توانید روی هر ایده‌ای بگذارید.
دو چیزی که باید حواستان باشد
ساختن یک دموی چشم‌گیر با مدل‌های پایه آسان است. ساختن محصولی که واقعاً کار کند، سخت است. یک تیم بزرگ گزارش داده که یک ماه طول کشید تا به ۸۰٪ کیفیت مطلوب برسد — و چهار ماه دیگر تا از ۹۵٪ رد شود. به این پدیده چالش آخرین مایل می‌گویند: مسیر صفر تا شصت آسان است، شصت تا صد کمرشکن.
ورود آسان یعنی خروج هم آسان است. اگر ساختنش برای شما راحت بود، برای رقیب هم راحت است. بدتر: اگر خودِ مدل‌های پایه قوی‌تر شوند، ممکن است لایه‌ای که شما ساخته‌اید کلاً بی‌معنی شود. اپلیکیشنی که فقط PDF را تحلیل می‌کند، با نسخهٔ بعدی مدل که خودش PDF می‌خواند، بی‌فایده می‌شود.
در برابر این، سه نوع مزیت رقابتی وجود دارد: فناوری، داده و دسترسی به کاربر. با مدل‌های پایه، فناوری تقریباً برای همه یکسان شده. دسترسی به کاربر معمولاً دست شرکت‌های بزرگ است. پس چیزی که برای یک تیم کوچک واقعاً می‌ماند، داده است — به‌ویژه دادهٔ استفادهٔ کاربران واقعی شما. به همین دلیل است که در فصل ۱۰ یک فصل کامل روی جمع‌آوری بازخورد کار می‌کنیم.
خودآزمایی
سؤال اول: اصلاً چرا؟
ساختن یک اپلیکیشن هوش مصنوعی، مثل هر تصمیم کسب‌وکاری دیگر، پاسخی است به یک ریسک یا یک فرصت. سه سطح انگیزه وجود دارد، از پرفشارترین تا آرام‌ترین:
بقا: اگر این کار را نکنم، رقیبی که هوش مصنوعی دارد مرا از دور خارج می‌کند. رایج در کارهای مبتنی بر پردازش سند و اطلاعات — تحلیل مالی، بیمه — و کارهای خلاقانه مثل تبلیغات و طراحی وب.
سود و بهره‌وری: اگر این کار را نکنم، فرصت بهتر شدن را از دست می‌دهم. انگیزهٔ اکثر شرکت‌ها همین است.
نترسیدن از جاماندن: هنوز نمی‌دانم کجای کارم به درد می‌خورد، ولی نمی‌خواهم عقب بمانم. اگر توانش را دارید، بد نیست — ولی بدانید که همین است.
اگر هوش مصنوعی برای کسب‌وکارتان تهدید بقا است، احتمالاً باید خودتان بسازید — نه اینکه آن را به رقیب برون‌سپاری کنید. اما اگر فقط برای بهره‌وری است، گزینه‌های آمادهٔ زیادی هست که وقت و پول کمتری می‌برند و نتیجهٔ بهتری می‌دهند.
نقش هوش مصنوعی در محصول را مشخص کنید
سه محور وجود دارد که هر کدام مستقیماً روی سختی کار و سطح کیفیتی که لازم دارید اثر می‌گذارند:
انسان کجای کار است؟
این سؤال را تیم‌ها معمولاً دیر از خودشان می‌پرسند. برای یک چت‌بات پشتیبانی، سه حالت کاملاً متفاوت وجود دارد:
هوش مصنوعی چند پاسخ پیشنهاد می‌دهد و انسان انتخاب و ویرایش می‌کند.
هوش مصنوعی فقط به سؤال‌های ساده جواب می‌دهد و بقیه را به انسان ارجاع می‌دهد.
هوش مصنوعی مستقیماً به همه جواب می‌دهد بدون دخالت انسان.
دخالت دادن انسان در تصمیم‌گیری هوش مصنوعی را انسان در حلقه (human-in-the-loop) می‌نامند. نکتهٔ مهم این است که این نقش قرار نیست ثابت بماند — قرار است به‌تدریج جلو برود.
موفقیت را عددی تعریف کنید
این مهم‌ترین قسمت این درس است. تا وقتی نتوانید بگویید «موفقیت یعنی این عدد به اینجا برسد»، نمی‌دانید کِی کار تمام شده و کِی باید بس کنید.
دو دستهٔ متفاوت سنجه لازم دارید:
سنجه‌های کسب‌وکار — چه درصدی از پیام‌ها خودکار شود؟ چقدر سریع‌تر پاسخ دهیم؟ چقدر نیروی انسانی صرفه‌جویی شود؟
آستانهٔ سودمندی — یعنی «چقدر خوب، یعنی به‌اندازهٔ کافی خوب برای اینکه جلوی کاربر بگذاریمش».
آستانهٔ سودمندی معمولاً از چند گروه سنجه تشکیل می‌شود: کیفیت پاسخ‌ها، تأخیر (شامل TTFT و TPOT و زمان کل)، هزینهٔ هر درخواست، و گاهی مواردی مثل انصاف و تفسیرپذیری.
اگر همین حالا همهٔ درخواست‌های مشتریان شما را آدم‌ها با میانگین یک ساعت جواب می‌دهند، هر چیزی سریع‌تر از یک ساعت پیشرفت است. اما اگر رقیبتان در دو ثانیه جواب می‌دهد، پنج ثانیه فاجعه است. تأخیر را همیشه نسبت به وضعیت فعلی بسنجید، نه نسبت به یک عدد آرمانی.
برنامهٔ مرحله‌ای و نگهداری
بعد از تعیین هدف، باید بدانید از کجا شروع می‌کنید. اول مدل‌های موجود را ارزیابی کنید. اگر هدفتان خودکارسازی ۶۰٪ تیکت‌هاست و مدل آماده همین حالا ۳۰٪ را می‌زند، مسیر شما خیلی کوتاه‌تر از حالتی است که از صفر شروع کند.
بعد از ارزیابی ممکن است بفهمید منابعی که برای رسیدن به آستانهٔ سودمندی لازم است، از ارزشی که برمی‌گرداند بیشتر است. آن‌وقت تصمیم درست این است که پروژه را کنار بگذارید. این شکست نیست؛ این همان کاری است که ارزیابی برایش وجود دارد.
و کار با رسیدن به هدف تمام نمی‌شود. این حوزه با سرعت عجیبی تغییر می‌کند و ساختن روی مدل‌های پایه یعنی سوار شدن بر همین قطار سریع. خیلی از تغییرات خوبند — طول متن قابل پردازش بیشتر می‌شود، کیفیت بالا می‌رود، قیمت‌ها پایین می‌آید. ولی حتی تغییر خوب هم اصطکاک ایجاد می‌کند:
تصمیم می‌گیرید مدل را خودتان میزبانی کنید چون ارزان‌تر است؛ سه ماه بعد ارائه‌دهنده‌ها قیمتشان را نصف می‌کنند و انتخاب شما گران‌ترین گزینه می‌شود.
روی یک راه‌حل شرکت ثالث سرمایه‌گذاری می‌کنید و زیرساختتان را دورش می‌چینید؛ آن شرکت سرمایه جذب نمی‌کند و تعطیل می‌شود.
مدل جدیدی می‌آید که بهتر است، ولی پرامپت‌های شما با آن همان جواب را نمی‌دهند — و بدون زیرساخت نسخه‌بندی و ارزیابی، اصلاً نمی‌فهمید بهتر شده یا بدتر.
همان جملهٔ آخر، دلیل وجود فصل‌های ۳ و ۴ این دوره است. زیرساخت ارزیابی و نسخه‌بندی، کاری نیست که «بعداً» انجام دهید. همان چیزی است که به شما اجازه می‌دهد بدون ترس، چیزها را عوض کنید.
خودآزمایی
هر اپلیکیشن هوش مصنوعی، هر قدر ساده یا پیچیده، از سه لایه ساخته شده است. معمولاً از بالا شروع می‌کنید و فقط در صورت نیاز پایین می‌روید.
چه چیزی عوض شد، چه چیزی نه
نکتهٔ جالب اینجاست: با آمدن مدل‌های پایه، لایهٔ بالا منفجر شد — تعداد ابزارهای توسعهٔ اپلیکیشن در یک سال چند برابر شد. اما لایهٔ زیرساخت تقریباً همان ماند. دلیلش روشن است: مدل‌ها و اپلیکیشن‌ها عوض شده‌اند، ولی نیاز به مدیریت منابع، سرویس‌دهی و پایش همان چیزی است که همیشه بوده.
خیلی از اصول ساخت اپلیکیشن هوش مصنوعی عوض نشده‌اند. هنوز باید سنجهٔ کسب‌وکار را به سنجهٔ فنی ترجمه کنید. هنوز باید منظم آزمایش کنید. هنوز باید حلقهٔ بازخورد بسازید. یعنی یک دهه تجربهٔ جمعی مهندسان یادگیری ماشین هنوز به کار می‌آید — و شما لازم نیست همه‌چیز را از نو کشف کنید.
مهندسی هوش مصنوعی در برابر مهندسی یادگیری ماشین
سه تفاوت اصلی وجود دارد و هر سه مهم‌اند:
مهندسی هوش مصنوعی کمتر دربارهٔ ساختن مدل است و بیشتر دربارهٔ تطبیق دادن و ارزیابی کردن آن. به همین دلیل است که از ده فصل این دوره، دو فصل کامل فقط به ارزیابی اختصاص دارد.
تطبیق مدل: دو خانوادهٔ بزرگ
همهٔ روش‌های تطبیق، بر اساس یک سؤال ساده به دو دسته تقسیم می‌شوند: آیا وزن‌های مدل را عوض می‌کنیم یا نه؟
چهار کلمه که مدام قاطی می‌شوند
این چهار اصطلاح را همه‌جا می‌بینید و تفاوتشان اغلب توضیح داده نمی‌شود:
آموزش همیشه وزن‌ها را عوض می‌کند — ولی هر تغییری در وزن‌ها آموزش نیست. کوانتیزیشن وزن‌ها را تغییر می‌دهد ولی چیزی یاد نمی‌گیرد؛ فقط همان دانش را در فضای کمتری می‌چپاند.
خودآزمایی
در فصل ۱ دیدید که مدل زبانی از روی حجم عظیمی از متن، پیش‌بینی توکن بعدی را یاد می‌گیرد. حالا سؤال مهم‌تر این است: کدام متن؟ جوابش تقریباً همه‌چیز را دربارهٔ توانایی‌ها و ضعف‌های یک مدل توضیح می‌دهد.
قاعدهٔ اول ساده است: مدل فقط به اندازهٔ داده‌اش خوب است. اگر در دادهٔ آموزشی هیچ متن ویتنامی نباشد، مدل نمی‌تواند از انگلیسی به ویتنامی ترجمه کند. اگر یک مدل دسته‌بندی تصویر فقط عکس حیوان دیده باشد، روی عکس گیاه درمانده است. هر رفتار عجیبی که از مدل می‌بینید، اول باید بپرسید: «این مدل اصلاً چنین چیزی دیده بود؟»
مدل‌ها از کجا داده می‌آورند؟
جمع کردن داده به اندازهٔ کافی برای یک مدل بزرگ، سخت و گران است. برای همین سازندگان مدل معمولاً از همان داده‌ای استفاده می‌کنند که در دسترس است، حتی اگر دقیقاً همانی نباشد که لازم دارند.
مهم‌ترین منبع، Common Crawl است: پروژهٔ یک سازمان غیرانتفاعی که هر چند وقت یک بار صفحه‌های وب را جمع می‌کند — در سال‌های ۲۰۲۲ و ۲۰۲۳ حدود ۲ تا ۳ میلیارد صفحه در ماه. گوگل نسخهٔ پالایش‌شده‌ای از آن ساخته به نام C4. تقریباً همهٔ مدل‌هایی که منبع دادهٔ آموزشی‌شان را اعلام کرده‌اند — از جمله GPT-3 و Gemini — نسخه‌ای از Common Crawl را به کار برده‌اند.
Common Crawl همان اینترنت است، با همهٔ خوب و بدش: تیترهای طعمه، اطلاعات غلط، تبلیغات سیاسی و تئوری توطئه. تحلیل واشنگتن‌پست نشان داد که در میان هزار وب‌سایت پرتکرار این مجموعه، چند رسانه با امتیاز اعتبار پایین هم هست. به زبان ساده: مدل‌ها با مقدار قابل‌توجهی اخبار جعلی بزرگ شده‌اند.
بعضی تیم‌ها با قاعده‌های سرانگشتی دادهٔ بی‌کیفیت را کنار می‌گذارند. مثلاً OpenAI برای آموزش GPT-2 فقط لینک‌هایی از Reddit را برداشت که دست‌کم سه رأی مثبت گرفته بودند. این کار لینک‌هایی را که هیچ‌کس به آن‌ها اهمیت نداده حذف می‌کند — ولی Reddit هم لزوماً نمونهٔ اعلای ادب و دقت نیست.
یک نکتهٔ ناخوشایند هم هست: شرکت‌ها روزبه‌روز کمتر می‌گویند مدلشان را با چه داده‌ای آموزش داده‌اند — هم برای فرار از انتقاد عمومی و هم برای اینکه رقبا نفهمند. پس شما اغلب مجبورید دادهٔ آموزشی یک مدل را از روی رفتارش حدس بزنید. بخش بزرگی از فصل‌های ۳ و ۴ همین است: سنجیدن آنچه نمی‌توانید مستقیم ببینید.
وقتی داده بر اساس در دسترس بودن انتخاب می‌شود، مدل در کارهایی خوب می‌شود که در اینترنت فراوان‌اند — نه لزوماً در کاری که شما لازم دارید. راه‌حل، گزینش دادهٔ متناسب با نیاز است؛ کاری که در فصل ۸ یاد می‌گیرید.
بیشتر همیشه بهتر نیست
شاید بپرسید چرا همهٔ داده‌های موجود — عمومی و تخصصی — را به مدل نمی‌دهیم تا همه‌کاره شود؟ خیلی‌ها همین کار را می‌کنند. ولی دادهٔ بیشتر محاسبات بیشتری می‌خواهد و همیشه به عملکرد بهتر نمی‌رسد.
پژوهشگران مایکروسافت (Gunasekar و همکاران، ۲۰۲۳) فقط با ۷ میلیارد توکن دادهٔ برنامه‌نویسیِ باکیفیت، مدلی با ۱٫۳ میلیارد پارامتر ساختند که در چند آزمون مهم برنامه‌نویسی از مدل‌های بسیار بزرگ‌تر بهتر عمل کرد. درس: یک کتابخانهٔ کوچک با کتاب‌های خوب، از انبار بزرگی پر از روزنامهٔ باطله مفیدتر است.
زبان: چرا مدل‌ها در فارسی ضعیف‌ترند
اینترنت انگلیسی‌زبان است. تحلیل Common Crawl نشان می‌دهد تقریباً نیمی از داده (۴۵٫۸۸٪) انگلیسی است — هشت برابر زبان دوم، یعنی روسی. در فهرست زبان‌هایی که دست‌کم ۱٪ از این مجموعه را دارند، فارسی نیست. به زبانی که دادهٔ کمی از آن در دسترس است، «کم‌منبع» (low-resource) می‌گویند.
کمبود داده مستقیم در عملکرد دیده می‌شود. در آزمون MMLU — چهارده هزار پرسش چندگزینه‌ای در ۵۷ موضوع — GPT-4 در انگلیسی به‌مراتب بهتر از زبان‌های کم‌منبع عمل کرد. آزمایش دیگری روی شش مسئلهٔ ریاضی نشان داد GPT-4 مسئله‌ها را به انگلیسی بیش از سه برابر بیشتر از فارسی یا ارمنی حل می‌کند.
کمبود داده تنها دلیل نیست. ساختار یک زبان و فرهنگی که با خودش دارد هم یادگیری‌اش را برای مدل سخت‌تر یا آسان‌تر می‌کند. ولی کمبود داده بزرگ‌ترین و قابل‌سنجش‌ترین دلیل است: سه زبانی که در MMLU بدترین نتیجه را گرفتند، از کم‌سهم‌ترین زبان‌های Common Crawl هم بودند.
چرا همه‌چیز را به انگلیسی ترجمه نکنیم؟
راه‌حلی که به ذهن خیلی‌ها می‌رسد: پرسش فارسی را به انگلیسی ترجمه کن، جواب را بگیر، و دوباره به فارسی برگردان. خیلی‌ها واقعاً همین کار را می‌کنند، ولی دو ایراد دارد:
برای ترجمهٔ درست، باز هم مدلی لازم است که فارسی را خوب بفهمد — یعنی مشکل حل نشده، فقط جابه‌جا شده.
ترجمه اطلاعات را دور می‌ریزد. فارسی بین «تو» و «شما» فرق می‌گذارد و همین تفاوت، رابطهٔ دو طرف گفت‌وگو را نشان می‌دهد. در انگلیسی هر دو می‌شوند you. پیامی که مؤدبانه و رسمی نوشته شده، در رفت‌وبرگشت ترجمه ممکن است خودمانی برگردد — یا برعکس.
رفتار مدل هم با زبان عوض می‌شود
این یکی شاید غافلگیرکننده‌ترین نتیجه باشد. در سال ۲۰۲۳، NewsGuard از ChatGPT-3.5 خواست دربارهٔ چین مقالهٔ حاوی اطلاعات غلط بنویسد. به انگلیسی، مدل در شش مورد از هفت درخواست را رد کرد. به چینی، هر هفت بار متن غلط تولید کرد. دلیلش هنوز روشن نیست.
اگر نگهبان‌ها و محدودیت‌های یک مدل را به انگلیسی آزموده‌اید، هیچ تضمینی نیست که به فارسی هم همان‌طور رفتار کند. آزمون ایمنی را باید به زبان واقعی کاربرانتان انجام دهید. در فصل ۵ که به حملهٔ تزریق پرامپت می‌رسیم، این نکته دوباره به کارتان می‌آید.
و گران‌تر و کُندتر هم هست
هزینه و زمان پاسخ مدل‌ها به تعداد توکن‌ها بستگی دارد. توکنایزر یک مدل، که بیشتر روی متن انگلیسی ساخته شده، معمولاً یک متن هم‌معنا را در زبان‌های دیگر به توکن‌های بیشتری می‌شکند.
این عددها از مجموعهٔ MASSIVE هستند: یک میلیون جملهٔ کوتاه که به ۵۲ زبان ترجمه شده‌اند. نتیجه ساده است: برای سرویسی که به ازای توکن پول می‌گیرد، همان پیام به برمه‌ای ده برابر گران‌تر است و — اگر تولید هر توکن زمان یکسانی بگیرد — ده برابر کُندتر.
کتاب مرجع برای فارسی عدد مشخصی گزارش نمی‌کند و ما هم عددی از خودمان نمی‌سازیم. عدد فارسی به توکنایزر هر مدل بستگی دارد و با نسخهٔ تازه عوض می‌شود. خبر خوب: در پروژهٔ همین فصل یک توکنایزر می‌سازید و خودتان می‌سنجید متن فارسی در برابر انگلیسی چند برابر توکن می‌خورد — همان عددی که باید پیش از انتخاب مدل برای محصول فارسی بدانید.
راه‌حل دیگر، مدل‌هایی است که از اول برای یک زبان خاص ساخته شده‌اند. فعال‌ترین زبان بعد از انگلیسی، چینی است (ChatGLM، YAYI، Llama-Chinese و…). برای فرانسوی CroissantLLM، برای ویتنامی PhoGPT و برای عربی Jais ساخته شده است. این مدل‌ها یا از صفر آموزش می‌بینند یا — که رایج‌تر است — روی یک مدل همه‌منظوره تنظیم دقیق می‌شوند.
مدل‌های تخصصی یک حوزه
مدل‌های همه‌منظوره مثل Gemini، GPT و Llama در حوزه‌های گوناگون — برنامه‌نویسی، حقوق، علوم، کسب‌وکار — به‌طرز شگفت‌انگیزی خوب‌اند. دلیلش ساده است: این حوزه‌ها در دادهٔ آموزشی‌شان بوده‌اند. ولی یک نکتهٔ ظریف در تحلیل‌های توزیع داده هست: فقط نشان می‌دهند چه چیزی هست، نه چه چیزی نیست.
برای مدل‌های تصویری حتی همین تحلیل هم کم است، چون دسته‌بندی تصویر سخت‌تر از متن است. پس حوزه‌های یک مدل را باید از روی عملکردش در آزمون‌ها حدس زد. مقایسهٔ دو مدل تصویری CLIP و نسخهٔ متن‌باز آن، Open CLIP، این را خوب نشان می‌دهد:
معماری دو مدل یکی است؛ تفاوت از داده است. و دنیا خیلی بزرگ‌تر از پرنده و گل و خودرو است. برای کارهایی که در دادهٔ عمومی تقریباً وجود ندارند، مدل همه‌منظوره کم می‌آورد:
کشف دارو با دادهٔ پروتئین، DNA و RNA کار می‌کند؛ قالب‌های خاص و گران‌قیمتی که در اینترنت عمومی پیدا نمی‌شوند.
غربالگری سرطان به تصویر پرتونگاری و fMRI نیاز دارد که به دلیل حریم خصوصی به‌سختی به دست می‌آید.
برای همین مدل‌های تخصصی ساخته می‌شوند. معروف‌ترینشان شاید AlphaFold از DeepMind باشد که روی توالی و ساختار سه‌بعدی حدود صد هزار پروتئین شناخته‌شده آموزش دید. BioNeMo از NVIDIA برای کشف دارو و Med-PaLM2 از گوگل برای پرسش‌های پزشکی نمونه‌های دیگرند.
مدل تخصصی بیشتر در زیست‌پزشکی دیده می‌شود، ولی هر حوزه‌ای که دادهٔ خاص خودش را دارد می‌تواند از آن سود ببرد: مدلی که روی نقشه‌های معماری آموزش دیده، یا مدلی که فرایندهای یک کارخانه را می‌شناسد. برای یک کسب‌وکار ایرانی، متن قوانین و بخشنامه‌ها یا اسناد داخلی سازمان همان «دادهٔ تخصصی»ای است که هیچ مدل عمومی به‌خوبی ندیده.
این درس برای کار شما یعنی چه؟
پیش از آنکه برای یک محصول فارسی مدل انتخاب کنید، چهار سؤال بپرسید:
خودآزمایی
پیش از آموزش هر مدل، سازنده‌اش دو تصمیم بزرگ می‌گیرد: معماری (مدل چه شکلی باشد) و اندازه (چند پارامتر داشته باشد). این دو تصمیم فقط توانایی مدل را تعیین نمی‌کنند؛ تعیین می‌کنند شما با آن چه دردسری دارید. مدل ۷ میلیارد پارامتری را روی یک کارت گرافیک معمولی راه می‌اندازید؛ مدل ۱۷۵ میلیاردی را نه.
ترنسفورمر برای حل چه مشکلی آمد؟
پیش از ترنسفورمر، معماری غالب برای کار با متن seq2seq بود (از ۲۰۱۴). گوگل در ۲۰۱۶ آن را به مترجمش اضافه کرد و گفت «بزرگ‌ترین پیشرفت تاکنون» در کیفیت ترجمه را گرفته است. seq2seq دو بخش داشت: یک رمزگذار که ورودی را می‌خواند و یک رمزگشا که خروجی را تولید می‌کرد — هر دو از نوع RNN، یعنی کلمه‌به‌کلمه و به ترتیب.
دو ایراد اساسی داشت:
رمزگشا فقط خلاصهٔ ورودی را می‌دید. رمزگذار کل ورودی را در یک «حالت نهایی» فشرده می‌کرد و رمزگشا فقط همان را داشت. مثل این است که بخواهید دربارهٔ یک کتاب به پرسش‌ها جواب بدهید ولی فقط خلاصهٔ کتاب در دستتان باشد.
همه‌چیز پشت‌سرهم بود. اگر ورودی ۲۰۰ توکن داشت، باید صبر می‌کردید تا توکن‌ها یکی‌یکی پردازش شوند. برای متن بلند، کُند بود.
ترنسفورمر (Vaswani و همکاران، ۲۰۱۷) هر دو را با یک ایده حل کرد: سازوکار توجه (attention). به‌جای خلاصهٔ کتاب، مدل موقع تولید هر توکن می‌تواند به هر صفحه‌ای از کتاب مراجعه کند و خودش تصمیم بگیرد کدام صفحه‌ها مهم‌ترند. و چون دیگر RNN در کار نیست، توکن‌های ورودی هم‌زمان پردازش می‌شوند.
سازوکار توجه را ترنسفورمر اختراع نکرد — سه سال قبلش معرفی شده بود و گوگل هم در ۲۰۱۶ آن را کنار seq2seq به کار برد. کار بزرگ مقالهٔ ترنسفورمر این بود که نشان داد توجه به‌تنهایی کافی است و RNN را می‌شود کلاً کنار گذاشت. عنوان مقاله هم همین بود: «توجه تمام چیزی است که لازم دارید».
دو مرحلهٔ هر پاسخ: پیش‌پر کردن و رمزگشایی
ترنسفورمر گلوگاه ورودی را برداشت، ولی گلوگاه خروجی هنوز هست: مدل هنوز یک توکن در هر گام تولید می‌کند. برای همین هر پاسخ مدل دو مرحله دارد:
این تفکیک را به خاطر بسپارید؛ در فصل ۹ تقریباً همهٔ ترفندهای سریع‌تر و ارزان‌تر کردن مدل از همین‌جا شروع می‌شوند. بخش موازی را می‌شود با سخت‌افزار بیشتر تندتر کرد؛ بخش پشت‌سرهم را نه به همان راحتی.
سازوکار توجه، با تشبیه کتاب
در دل توجه سه بردار هست. همان تشبیه کتاب را ادامه بدهیم:
مدل برای هر توکن قبلی حساب می‌کند که «پرسش» فعلی چقدر با «کلید» آن جور است. هرچه امتیاز بالاتر، سهم بیشتری از «مقدار» آن صفحه در ساختن توکن بعدی به کار می‌رود. همین. بقیه‌اش جزئیات محاسبه است.
برای هر توکن قبلی یک بردار کلید و یک بردار مقدار لازم است. هرچه متن طولانی‌تر، بردارهای بیشتری باید حساب و در حافظه نگه داشته شوند. این یکی از دلایل اصلی است که بزرگ کردن پنجرهٔ زمینهٔ ترنسفورمرها سخت و گران است — و در فصل‌های ۷ و ۹ با نام حافظهٔ KV دوباره سراغش می‌رویم.
دو جزئیات دیگر هم ارزش دانستن دارند. اول، توجه تقریباً همیشه چندسَر است: بردارها به چند تکهٔ کوچک‌تر شکسته می‌شوند تا مدل بتواند هم‌زمان به چند گروه از توکن‌ها توجه کند. در Llama 2-7B، بعد مدل ۴۰۹۶ است و ۳۲ سَر توجه دارد؛ پس هر سَر با بردارهایی به طول ۱۲۸ کار می‌کند (۴۰۹۶ ÷ ۳۲). دوم، خروجی همهٔ سَرها کنار هم گذاشته و یک بار دیگر تبدیل می‌شود تا به مرحلهٔ بعد برود.
ترنسفورمر از چه ساخته شده
هر مدل ترنسفورمری از سه بخش ساخته شده:
لایهٔ تعبیه در ورودی: هر توکن و جایگاهش در متن را به بردار تبدیل می‌کند. در ساده‌ترین حالت، تعداد جایگاه‌هایی که مدل می‌شناسد، حداکثر طول زمینه‌اش را تعیین می‌کند — مدلی که ۲۰۴۸ جایگاه دارد، زمینه‌اش ۲۰۴۸ توکن است (البته ترفندهایی برای فراتر رفتن از آن هست).
بلوک‌های ترنسفورمر، چندین بار پشت‌سرهم. هر بلوک دو بخش دارد: توجه (چهار ماتریس Q، K، V و خروجی) و MLP (لایه‌های خطی که با یک تابع غیرخطی ساده از هم جدا شده‌اند — مثلاً ReLU که فقط عددهای منفی را صفر می‌کند).
لایهٔ خروجی: بردار نهایی را به احتمال هر توکن ممکن تبدیل می‌کند. از این احتمال‌ها، توکن بعدی انتخاب می‌شود — موضوع درس نمونه‌برداری.
اندازهٔ مدل از ابعاد همین قطعه‌ها درمی‌آید: بُعد مدل، تعداد بلوک‌ها، بُعد لایهٔ پیش‌خور و اندازهٔ واژگان. خانوادهٔ Llama نمونهٔ خوبی است:
واژگان Llama 3 چهار برابر Llama 2 است. واژگان بزرگ‌تر یعنی توکنایزر می‌تواند تکه‌های بیشتری از زبان‌های گوناگون را یک‌جا بشناسد — و معمولاً متن غیرانگلیسی را با توکن کمتری بشکند. عدد دقیقش را برای فارسی در پروژهٔ این فصل می‌سنجید.
آیا ترنسفورمر همیشه می‌ماند؟
معماری‌ها معمولاً عمر کوتاهی دارند: seq2seq حدود چهار سال در صدر ماند. ترنسفورمر از ۲۰۱۷ مانده و به‌شدت بهینه شده؛ جایگزینش باید در همان مقیاس و روی همان سخت‌افزار بهتر باشد، که کار آسانی نیست. ولی رقبای جدی پیدا شده‌اند: RWKV (یک RNN که آموزشش موازی می‌شود) و خانوادهٔ SSM. مثلاً Mamba با ۳ میلیارد پارامتر از ترنسفورمرهای هم‌اندازه بهتر بود و به ترنسفورمرهای دو برابر بزرگ‌تر رسید، و هزینه‌اش با طول متن خطی رشد می‌کند، نه درجهٔ دو. Jamba هم لایه‌های ترنسفورمر و Mamba را ترکیب کرد.
حتی اگر فردا معماری دیگری جای ترنسفورمر را بگیرد، رویکردهای اصلی این دوره — ارزیابی، پرامپت، RAG، تنظیم دقیق — عوض نمی‌شوند. همان‌طور که گذار از مهندسی یادگیری ماشین به مهندسی هوش مصنوعی خیلی چیزها را دست‌نخورده گذاشت.
اندازهٔ مدل: عدد آخر اسم‌ها
Llama-13B یعنی نسخه‌ای از Llama با ۱۳ میلیارد پارامتر. در یک خانوادهٔ مدل، بیشتر بودن پارامتر معمولاً یعنی ظرفیت یادگیری بیشتر و مدل بهتر. ولی بین نسل‌ها این قاعده نمی‌ماند: Llama 3-8B (۲۰۲۴) در MMLU حتی از Llama 2-70B (۲۰۲۳) بهتر است، چون جامعه یاد گرفته مدل‌ها را بهتر آموزش دهد.
تعداد پارامتر کمک می‌کند منابع لازم را تخمین بزنید. اگر مدلی ۷ میلیارد پارامتر داشته باشد و هر پارامتر در ۲ بایت (۱۶ بیت) ذخیره شود، فقط برای بار کردن وزن‌ها دست‌کم ۱۴ گیگابایت حافظهٔ GPU لازم دارید: ۷ میلیارد × ۲ بایت. در فصل ۷ این حساب را دقیق‌تر می‌کنیم و یک ماشین‌حساب حافظه می‌سازیم.
وقتی عدد پارامتر گول می‌زند: مدل‌های پراکنده
در مدل پراکنده (sparse) بخش بزرگی از پارامترها صفر است یا هم‌زمان به کار نمی‌آید. رایج‌ترین نوعش ترکیب متخصص‌ها (MoE) است: مدل به چند گروه پارامتر — «متخصص» — تقسیم می‌شود و برای هر توکن فقط چند تا از آن‌ها فعال می‌شوند.
نتیجه: Mixtral 8x7B با ۴۶٫۷ میلیارد پارامتر، هزینه و سرعتی مثل یک مدل ۱۲٫۹ میلیاردی دارد. ولی حافظه‌ای که برای بار کردنش لازم است، از روی کل پارامترهاست. این همان تفاوتی است که موقع انتخاب مدل برای سرور خودتان باید حواستان به آن باشد.
اندازه بدون داده هیچ است
مدلی با ۱۳ میلیارد پارامتر را تصور کنید که فقط روی یک جمله آموزش دیده: «من آناناس دوست دارم.» از یک مدل خیلی کوچک‌تر که دادهٔ فراوان دیده، بدتر است. پس اندازهٔ مدل را همیشه کنار اندازهٔ داده بسنجید — و اندازهٔ داده را با توکن می‌شمارند، نه با تعداد نمونه، چون یک کتاب خیلی بیشتر از یک جمله می‌ارزد.
یک ظرافت: «توکن‌های مجموعهٔ داده» با «توکن‌های آموزشی» فرق دارد. اگر مجموعه‌ای یک تریلیون توکن داشته باشد و مدل دو بار از رویش رد شود (دو دوره یا epoch)، مدل روی دو تریلیون توکن آموزش دیده است.
سه عدد که مقیاس یک مدل را نشان می‌دهند
سومی نیاز به توضیح دارد. FLOP یعنی یک عملیات ریاضی روی عدد اعشاری. FLOPs (با s کوچک) یعنی یک کار چند عملیات لازم دارد؛ FLOP/s یعنی یک دستگاه در هر ثانیه چند عملیات انجام می‌دهد. این دو مدام با هم قاطی می‌شوند، مخصوصاً وقتی FLOP/s را FLOPS بنویسند.
آموزش GPT-3-175B حدود ۳٫۱۴ × ۱۰²³ FLOPs لازم داشت. یک کارت H100 در بهترین حالت حدود ۵٫۲ × ۱۰¹⁸ FLOPs در روز انجام می‌دهد. با ۲۵۶ کارت که صددرصد ظرفیت و بی‌هیچ خطایی کار کنند، حدود ۲۳۶ روز (نزدیک ۸ ماه) طول می‌کشد. ولی هیچ‌کس به ظرفیت کامل نمی‌رسد: ۵۰٪ بهره‌وری قابل‌قبول و بالای ۷۰٪ عالی است. با ۷۰٪ بهره‌وری و ۲ دلار برای هر ساعت هر کارت، هزینهٔ فقط محاسبات از ۴ میلیون دلار می‌گذرد.
قانون مقیاس: با بودجهٔ ثابت، چه اندازه‌ای؟
هیچ تیمی با «یک مدل بزرگ بسازیم ببینیم چقدر می‌شود» شروع نمی‌کند. با بودجه شروع می‌کنند و می‌پرسند: با این مقدار محاسبه، چه اندازه مدل و چه مقدار داده بهترین نتیجه را می‌دهد؟
جوابش قانون مقیاس Chinchilla است. پژوهشگران DeepMind (۲۰۲۲) ۴۰۰ مدل — از ۷۰ میلیون تا بیش از ۱۶ میلیارد پارامتر — را روی ۵ تا ۵۰۰ میلیارد توکن آموزش دادند و به یک قاعدهٔ ساده رسیدند:
برای آموزش بهینه، تعداد توکن‌های آموزشی باید حدود ۲۰ برابر تعداد پارامترها باشد. مدل ۳ میلیارد پارامتری حدود ۶۰ میلیارد توکن می‌خواهد. و این دو باید با هم بزرگ شوند: مدل را دو برابر کردید، داده را هم دو برابر کنید.
ولی برای محصول، کیفیت همه‌چیز نیست. سازندگان Llama با بودجه‌شان می‌توانستند مدل بزرگ‌تر و قوی‌تری بسازند، ولی عمداً مدل کوچک‌تر ساختند — روی دادهٔ بیشتر از آنچه Chinchilla می‌گوید. مدل کوچک‌تر برای استفاده ارزان‌تر و راحت‌تر است، و همین به محبوبیتش کمک کرد. وقتی مدل میلیون‌ها بار استفاده می‌شود، هزینهٔ استنتاج از هزینهٔ یک‌بارهٔ آموزش مهم‌تر می‌شود.
هزینهٔ رسیدن به یک کیفیت مشخص هر سال پایین‌تر می‌آید، ولی هزینهٔ بهتر شدن همچنان بالاست. بردن دقت از ۹۰ به ۹۵ درصد گران‌تر از ۸۵ به ۹۰ است؛ مدلی با ۲٪ خطا ممکن است ده برابر بیشتر از مدلی با ۳٪ خطا داده و محاسبه بخواهد. همان «چالش کیلومتر آخر» فصل ۱.
یک پدیدهٔ غافلگیرکننده هم هست: مقیاس معکوس. در مسابقه‌ای که در ۲۰۲۳ برای پیدا کردن کارهایی برگزار شد که مدل بزرگ‌تر در آن‌ها بدتر است، معلوم شد مدل‌های بزرگ‌تر گاهی — فقط گاهی — در کارهای مبتنی بر حفظ کردن یا کارهایی با پیش‌فرض‌های قوی بدتر عمل می‌کنند. ولی هیچ‌کدام در دنیای واقعی شکست جدی نشان ندادند.
پارامتر در برابر ابرپارامتر
پارامتر را مدل در طول آموزش یاد می‌گیرد. ابرپارامتر را انسان تعیین می‌کند: تعداد لایه‌ها، بُعد مدل، اندازهٔ واژگان، نرخ یادگیری، اندازهٔ دسته. برای مدل کوچک می‌شود ده بار با ابرپارامترهای مختلف آموزش داد و بهترین را برداشت. برای مدل بزرگ، معمولاً فقط یک شانس دارید. برای همین پژوهشگران ابرپارامترها را روی مدل‌های کوچک می‌آزمایند و به مدل بزرگ تعمیم می‌دهند — مایکروسافت و OpenAI نشان دادند می‌شود از مدل ۴۰ میلیونی به ۶٫۷ میلیاردی رسید.
دو دیوار پیش روی بزرگ‌تر شدن
تا امروز هر ده برابر شدن اندازه، مدل بهتری داده: GPT-2 ده برابر GPT-1 پارامتر داشت و GPT-3 صد برابر GPT-2. ولی دو گلوگاه دیده می‌شود:
داده تمام می‌شود. سرعت رشد داده‌های آموزشی از سرعت تولید متن تازه در اینترنت بیشتر است. هرچه تا امروز در اینترنت نوشته‌اید، احتمالاً در دادهٔ آموزشی مدلی هست — با رضایت شما یا بی‌آن. و اینترنت دارد از متن تولیدشده با هوش مصنوعی پر می‌شود؛ مدلی که روی آن آموزش ببیند، از خروجی مدل‌های دیگر یاد می‌گیرد. در همین حال سایت‌ها درشان را می‌بندند: بین ۲۰۲۳ و ۲۰۲۴، ۴۵٪ از C4 برای استفاده محدود شد. دادهٔ اختصاصی — کتاب، قرارداد، پروندهٔ پزشکی — به مزیت رقابتی تبدیل می‌شود.
برق. مراکز داده امروز ۱ تا ۲ درصد برق دنیا را مصرف می‌کنند و برآورد می‌شود تا ۲۰۳۰ به ۴ تا ۲۰ درصد برسد. تا راهی برای تولید انرژی بیشتر پیدا نشود، مراکز داده حداکثر حدود ۵۰ برابر می‌توانند بزرگ شوند — کمتر از دو مرتبهٔ بزرگی.
چون دادهٔ عمومی رو به تمام شدن است، دادهٔ اختصاصی سازمان شما — مکاتبات، گزارش‌ها، پرسش‌های مشتری — ارزشمندتر از همیشه است. این هم فرصت است (برای RAG و تنظیم دقیق) و هم مسئولیت: پیش از فرستادنش به هر سرویس بیرونی، بدانید چه چیزی را کجا می‌فرستید.
خودآزمایی
مدلی که تازه پیش‌آموزش دیده، دو ایراد دارد. اول، با خودنظارتی برای تکمیل متن بهینه شده، نه برای گفت‌وگو. دوم، چون از دادهٔ بی‌گزینش اینترنت یاد گرفته، ممکن است حرف نژادپرستانه، توهین‌آمیز یا صاف‌وساده غلط بزند. پس‌آموزش برای حل همین دو ایراد است.
پس‌آموزش هر مدل با دیگری فرق دارد، ولی معمولاً دو گام دارد:
پیش‌آموزش کیفیت را در سطح توکن بهینه می‌کند: پیش‌بینی درست توکن بعدی. ولی کاربر به توکن اهمیت نمی‌دهد؛ به کل پاسخ اهمیت می‌دهد. پس‌آموزش مدل را برای پاسخ‌هایی بهینه می‌کند که کاربر می‌پسندد. تشبیه رایج: پیش‌آموزش مثل خواندن برای کسب دانش است؛ پس‌آموزش مثل یاد گرفتن به‌کارگیری همان دانش.
نکتهٔ جالب: پس‌آموزش در برابر پیش‌آموزش تقریباً ارزان است. InstructGPT (نیای ChatGPT) فقط ۲٪ محاسباتش را برای پس‌آموزش خرج کرد و ۹۸٪ را برای پیش‌آموزش. پس بهتر است پس‌آموزش را این‌طور ببینید: باز کردن قفل توانایی‌هایی که مدل از قبل داشت ولی دسترسی به آن‌ها فقط با پرامپت سخت بود.
بعضی‌ها «تنظیم دقیق دستوری» (instruction finetuning) را فقط به معنای SFT به کار می‌برند و بعضی‌ها برای هر دو گام. در این دوره برای جلوگیری از سردرگمی، این اصطلاح را به کار نمی‌بریم.
گام اول: یاد دادن گفت‌وگو (SFT)
به مدل خام بنویسید «طرز تهیهٔ پیتزا». مدل نمی‌داند این شروع یک گفت‌وگوست؛ فقط می‌خواهد جمله را ادامه دهد. هر سه ادامهٔ زیر برایش به یک اندازه درست‌اند:
اضافه کردن جزئیات به پرسش: «…برای یک خانوادهٔ شش‌نفره»
اضافه کردن پرسش‌های بعدی: «چه موادی لازم است؟ چقدر طول می‌کشد؟»
دادن دستور پخت
اگر هدف پاسخ دادن به کاربر است، فقط گزینهٔ ۳ درست است. می‌دانیم مدل از دادهٔ آموزشی‌اش تقلید می‌کند؛ پس برای یاد دادن رفتار درست، نمونهٔ رفتار درست نشانش می‌دهیم. این نمونه‌ها به شکل (دستور، پاسخ) هستند و به آن‌ها دادهٔ نمایشی (demonstration data) می‌گویند. بعضی به این روند «شبیه‌سازی رفتار» می‌گویند: شما رفتار را نشان می‌دهید و مدل تقلیدش می‌کند.
چون کاربر انواع درخواست دارد — پرسش‌وپاسخ، خلاصه‌سازی، ترجمه، ایده‌پردازی — دادهٔ نمایشی باید همهٔ این‌ها را پوشش دهد. و مهم‌تر از همه: چه کسی این پاسخ‌ها را می‌نویسد.
معلم خوب، مدل خوب
برچسب‌زنی سنتی — مثلاً «در این عکس گربه هست؟» — چند ثانیه وقت می‌گیرد و تخصص نمی‌خواهد. ولی نوشتن یک پاسخ نمونهٔ خوب ممکن است تا ۳۰ دقیقه طول بکشد و به تفکر انتقادی، جست‌وجو و قضاوت دربارهٔ مناسب بودن درخواست نیاز داشته باشد. برای همین شرکت‌ها از برچسب‌زن‌های تحصیل‌کرده استفاده می‌کنند: در InstructGPT حدود ۹۰٪ برچسب‌زن‌ها دست‌کم مدرک کارشناسی داشتند و بیش از یک‌سوم کارشناسی ارشد.
اگر هر جفت (دستور، پاسخ) ۱۰ دلار تمام شود، ۱۳ هزار جفتی که OpenAI برای InstructGPT به کار برد، ۱۳۰ هزار دلار می‌شود — و این هنوز بدون هزینهٔ طراحی داده، استخدام برچسب‌زن و کنترل کیفیت است.
همه نمی‌توانند چنین خرجی بکنند. سازمان غیرانتفاعی LAION با ۱۳٬۵۰۰ داوطلب از سراسر دنیا ده هزار گفت‌وگو به ۳۵ زبان جمع کرد. ولی کنترلی روی سوگیری نبود: در نظرسنجی خوداظهاری، ۹۰٪ داوطلبان مرد بودند. در حالی که اصولاً کسانی که «ترجیح انسانی» را به مدل یاد می‌دهند باید نماینده‌ای از کل جمعیت باشند.
این پرسش برای کاربر فارسی‌زبان جدی است. رفتار «مؤدبانه» و «مناسب» یک مدل را آدم‌هایی تعیین کرده‌اند که آن را برچسب زده‌اند — با زبان، فرهنگ و پیش‌فرض‌های خودشان. پس لحن، شوخی، حد و مرز و ارزش‌هایی که از مدل می‌بینید را جهانی فرض نکنید؛ برای مخاطب خودتان بیازماییدشان.
راه‌های ارزان‌تری هم هست. DeepMind برای مدل Gopher با یک قاعدهٔ ساده از اینترنت گفت‌وگو بیرون کشید: متن‌هایی که شکل «[الف]: پاراگراف کوتاه / [ب]: پاراگراف کوتاه / …» داشتند. و روزبه‌روز تیم‌های بیشتری از دادهٔ تولیدشده با هوش مصنوعی استفاده می‌کنند — موضوع فصل ۸.
گام دوم: یاد دادن اینکه چه چیزی بگوید
دادهٔ نمایشی به مدل یاد می‌دهد چطور گفت‌وگو کند، ولی نه چه گفت‌وگویی. مدلی که می‌تواند در کارهای بزرگ کمک کند، می‌تواند در کارهای وحشتناک هم کمک کند. اگر کسی بخواهد دربارهٔ برتری یک نژاد بنویسد یا روش ربودن هواپیما را بپرسد، بیشتر آدم‌ها می‌دانند مدل چه کند. ولی خیلی موضوع‌ها این‌قدر روشن نیستند: آدم‌ها با پیشینه‌های فرهنگی، سیاسی و دینی گوناگون مدام با هم اختلاف دارند.
مدلی که دربارهٔ موضوع بحث‌برانگیز حرف بزند — هر حرفی — بخشی از کاربران را ناراحت می‌کند. مدلی که بیش از حد سانسور شود، خسته‌کننده می‌شود و کاربر را فراری می‌دهد. هدف تنظیم دقیق ترجیحی، رساندن مدل به رفتاری مطابق ترجیح انسانی است — هدفی بلندپروازانه، که فرض می‌کند اصلاً «ترجیح انسانی» یکسانی وجود دارد.
RLHF در دو قدم
قدیمی‌ترین روش موفق — و هنوز رایج — RLHF است:
روش‌های تازه‌تر مثل DPO ساده‌ترند و طرفدار پیدا کرده‌اند؛ Meta از RLHF در Llama 2 به DPO در Llama 3 رفت تا پیچیدگی را کم کند. ولی RLHF انعطاف بیشتری برای تنظیم مدل می‌دهد؛ نویسندگان Llama 2 حتی نوشتند توانایی نوشتن برتر مدل‌ها «اساساً از RLHF می‌آید».
چرا مقایسه، نه نمره؟
سخت‌ترین بخش ساختن مدل پاداش، داده است. اگر از برچسب‌زن‌ها بخواهید به هر پاسخ مستقیم از ۱ تا ۱۰ نمره بدهند، یکی ۵ می‌دهد و دیگری ۷ — و حتی یک نفر هم ممکن است به همان پاسخ دو بار دو نمرهٔ مختلف بدهد. کار آسان‌تر این است که دو پاسخ را مقایسه کنند و بگویند کدام بهتر است. خروجی، دادهٔ مقایسه‌ای است: (دستور، پاسخ برنده، پاسخ بازنده).
این نمونه از مجموعه‌دادهٔ Anthropic است — و نویسندهٔ کتاب مرجع دوره می‌گوید خودش پاسخ «بازنده» را ترجیح می‌دهد. همین یک مثال نشان می‌دهد جا دادن ترجیح‌های گوناگون آدم‌ها در یک فرمول ریاضی چقدر سخت است.
دو ترفند دیگر: برچسب‌زن‌ها می‌توانند چند پاسخ را یک‌جا رتبه‌بندی کنند؛ رتبه‌بندی A > B > C سه جفت مقایسه می‌سازد. و توافق بین برچسب‌زن‌ها کامل نیست: در InstructGPT حدود ۷۳٪ بود — یعنی از ده نفر، حدود هفت نفر رتبه‌بندی یکسانی می‌دادند.
هدف آموزشش ساده است: فاصلهٔ نمرهٔ پاسخ برنده و بازنده را تا جای ممکن زیاد کن. اگر مدل به پاسخ برنده نمرهٔ بیشتری بدهد، خطایش کم است؛ اگر برعکس، زیاد. از میلیون‌ها چنین مقایسه‌ای، مدل یاد می‌گیرد به هر پاسخ تنهایی هم نمرهٔ معناداری بدهد.
آیا مدل پاداش باید از مدل اصلی قوی‌تر باشد؟ بعضی این‌طور فکر می‌کنند. ولی در فصل ۳ می‌بینید که داوری از تولید آسان‌تر است و مدل ضعیف‌تر هم می‌تواند مدل قوی‌تر را داوری کند — پایهٔ «هوش مصنوعی در نقش داور».
میان‌بُر: فقط مدل پاداش، بدون RL
همه تا آخر راه نمی‌روند. شرکت‌هایی مثل Stitch Fix و Grab دیدند برای کارشان خود مدل پاداش کافی است: از مدل چند پاسخ می‌گیرند و پاسخی را برمی‌دارند که مدل پاداش بیشترین نمره را به آن داده. به این روش بهترین از N (best of N) می‌گویند و از این واقعیت سود می‌برد که مدل هر بار پاسخ کمی متفاوتی می‌دهد — موضوع درس بعد.
هر دو گام برای جبران کیفیت پایین دادهٔ پیش‌آموزش‌اند. اگر روزی دادهٔ پیش‌آموزش بهتری داشته باشیم، شاید اصلاً لازمشان نداشته باشیم. تا آن روز، RLHF و DPO هر دو در عمل بهتر از SFT تنها جواب می‌دهند — هرچند هنوز بحث است که دقیقاً چرا.
این درس برای کار شما یعنی چه؟
مدل «پایه» و مدل «دستوری» را از هم تشخیص دهید. وقتی مدل متن‌بازی دانلود می‌کنید، نسخهٔ base فقط متن را ادامه می‌دهد؛ برای گفت‌وگو نسخهٔ instruct یا chat را بردارید.
رد کردن‌ها و لحن مدل را طبیعت آن ندانید. این‌ها نتیجهٔ ترجیح‌های برچسب‌زن‌های سازنده‌اند. اگر برای کاربر شما مناسب نیست، با پرامپت (فصل ۵) و در نهایت تنظیم دقیق (فصل ۷) عوضش کنید.
برای تصمیم‌های پرخطر، بهترین از N را جدی بگیرید. چند پاسخ بگیرید و با یک معیار — حتی یک داور خودکار — بهترین را انتخاب کنید.
خودآزمایی
در درس قبل دیدید مدل در آخرین لایه برای هر توکن ممکن یک احتمال حساب می‌کند. ولی خروجی مدل یک توکن است، نه یک جدول احتمال. فرایند انتخاب از میان این احتمال‌ها را نمونه‌برداری (sampling) می‌گویند — و شاید کم‌قدرترین مفهوم در کل هوش مصنوعی باشد. هم رفتارهای عجیب مدل را توضیح می‌دهد، هم با کمترین زحمت کیفیت را بالا می‌برد.
از عدد خام تا احتمال
مدل مستقیم احتمال بیرون نمی‌دهد. برای هر توکن واژگانش یک عدد خام به نام لوجیت (logit) می‌سازد — پس اگر واژگان ۱۰۰ هزار توکن باشد، ۱۰۰ هزار لوجیت. لوجیت بزرگ‌تر یعنی احتمال بیشتر، ولی خودش احتمال نیست: جمعشان یک نمی‌شود و می‌تواند منفی باشد. یک تابع به نام سافت‌مکس (softmax) آن‌ها را به احتمال‌های درست تبدیل می‌کند: همه مثبت، جمعشان یک.
حالا از این احتمال‌ها چطور انتخاب کنیم؟ ساده‌ترین راه، برداشتن محتمل‌ترین است که به آن نمونه‌برداری حریصانه (greedy) می‌گویند. برای دسته‌بندی عالی است: اگر مدل فکر می‌کند ایمیل به احتمال ۹۰٪ هرزنامه است، هرزنامه‌اش بدان. ولی برای تولید متن، نتیجه خسته‌کننده است: مدلی که به هر پرسشی با پیش‌پاافتاده‌ترین کلمه‌ها جواب بدهد.
راه دیگر، انتخاب به نسبت احتمال است. اگر بعد از «رنگ موردعلاقه‌ام…» کلمهٔ «سبز» ۵۰٪ و «قرمز» ۳۰٪ احتمال داشته باشد، مدل نصف دفعه‌ها سبز و یک‌سوم دفعه‌ها قرمز می‌گوید. همین یک تصمیم است که مدل را غیرقطعی می‌کند.
سه پیچ تنظیم: دما، top-k و top-p
دما: خلاقیت در برابر ثبات
انتخاب به نسبت احتمال هم یک ایراد دارد: کلمه‌های رایج آن‌قدر محتمل‌اند که جواب شبیه حرف یک بچهٔ پنج‌ساله می‌شود: «رنگ موردعلاقه‌ام سبز است.» جملهٔ خلاق — «رنگ موردعلاقه‌ام رنگ برکه‌ای آرام در صبح بهار است» — شانس کمی دارد، چون کلمهٔ اولش کم‌احتمال است.
دما (temperature) احتمال‌ها را بازتوزیع می‌کند. پیش از سافت‌مکس، همهٔ لوجیت‌ها بر دما تقسیم می‌شوند. دمای بالا فاصلهٔ توکن‌های رایج و نادر را کم می‌کند (خلاق‌تر، ولی شاید بی‌ربط‌تر)؛ دمای پایین فاصله را زیاد می‌کند (یکنواخت‌تر، ولی شاید کسل‌کننده‌تر). یک مثال عددی: مدلی با دو خروجی A و B که لوجیت‌هایشان ۱ و ۲ است:
سرویس‌دهنده‌ها معمولاً دما را بین ۰ و ۲ محدود می‌کنند. برای کار خلاقانه، ۰٫۷ توصیهٔ رایجی است — ولی خودتان آزمایش کنید. برای کار دقیق و تکرارپذیر، ۰. دمای صفر از نظر ریاضی ممکن نیست (تقسیم بر صفر)؛ در عمل یعنی «بدون محاسبه، محتمل‌ترین را بردار» — همان حریصانه.
بعضی سرویس‌ها احتمال‌ها را به شکل لگاریتمی (logprobs) برمی‌گردانند. چرا لگاریتم؟ با واژگان ۱۰۰ هزارتایی، احتمال خیلی از توکن‌ها آن‌قدر کوچک است که کامپیوتر گردش می‌کند به صفر؛ لگاریتم این مشکل را حل می‌کند. logprobs برای دسته‌بندی، ارزیابی و اشکال‌زدایی بسیار مفید است — اگر احتمال‌ها تصادفی به نظر می‌رسند، مدل چیز زیادی یاد نگرفته. ولی خیلی از سرویس‌ها آن را نمی‌دهند یا محدود می‌دهند، احتمالاً چون کپی کردن مدل را آسان‌تر می‌کند.
top-k: فقط از میان k تای اول
سافت‌مکس روی ۱۰۰ هزار لوجیت گران است. top-k فقط k لوجیت بزرگ‌تر را نگه می‌دارد و سافت‌مکس و انتخاب را فقط روی همان‌ها انجام می‌دهد. k معمولاً بین ۵۰ تا ۵۰۰ است. k کوچک‌تر یعنی متن قابل‌پیش‌بینی‌تر ولی کم‌جذاب‌تر.
top-p: به اندازهٔ لازم، نه عدد ثابت
ایراد top-k این است که تعداد گزینه‌ها ثابت است، در حالی که باید به موقعیت بستگی داشته باشد. برای «موسیقی دوست داری؟ فقط بگو بله یا نه» دو گزینه کافی است؛ برای «معنای زندگی چیست؟» خیلی بیشتر لازم است. top-p (یا نمونه‌برداری هسته‌ای) توکن‌ها را از محتمل‌ترین به پایین جمع می‌زند و وقتی جمع احتمال به p رسید، می‌ایستد. فقط همین مجموعه در انتخاب شرکت می‌کند.
مقدار رایج p بین ۰٫۹ تا ۰٫۹۵ است. روی کاغذ مزیت چشمگیری ندارد، ولی در عمل خوب جواب داده و برای همین رایج شده. روش نزدیک دیگری هم هست به نام min-p: حداقل احتمالی که هر توکن باید داشته باشد تا در انتخاب شرکت کند.
کِی بایستد؟
خروجی بلندتر یعنی زمان و هزینهٔ بیشتر. دو راه برای متوقف کردن مدل هست: سقف تعداد توکن (ساده، ولی ممکن است وسط جمله قطع کند) و توکن یا کلمهٔ توقف (مثلاً توکن پایان دنباله).
اگر از مدل JSON خواسته‌اید و به سقف توکن بخورد، خروجی بی‌کروشهٔ پایانی و خراب برمی‌گردد. دستیار همین سایت هم این را تجربه کرد: پاسخ‌هایی که به سقف طول می‌خوردند، نیم‌جمله می‌ماندند و باید دور ریخته می‌شدند. سقف را با نگاه به طول واقعی پاسخ‌ها تعیین کنید، نه با حدس.
چند بار بپرس، بهترین را بردار
تا اینجا دربارهٔ انتخاب یک توکن بود. حالا دربارهٔ کل پاسخ: یک راه ساده برای بهتر کردن کیفیت این است که به‌جای یک پاسخ، چند پاسخ بگیرید و بهترین را انتخاب کنید. به این کار در ادبیات این حوزه محاسبهٔ زمان آزمون (test time compute) می‌گویند — یعنی خرج محاسبهٔ بیشتر در لحظهٔ استفاده، نه در آموزش.
OpenAI برای مسئله‌های ریاضی «وارسی‌گر»هایی آموزش داد که بهترین راه‌حل را انتخاب کنند. اثرش تقریباً برابر با سی برابر کردن اندازهٔ مدل بود: مدل ۱۰۰ میلیون پارامتری با وارسی‌گر، هم‌تراز مدل ۳ میلیاردی بدون آن. گوگل هم برای گزارش نمرهٔ Gemini در MMLU از هر پرسش ۳۲ پاسخ گرفت و پرتکرارترین را برداشت.
دو نکتهٔ عملی. اول، تنوع پاسخ‌ها کمک می‌کند؛ اگر از یک مدل چند پاسخ می‌گیرید، پارامترهای نمونه‌برداری را بین درخواست‌ها کمی عوض کنید. دوم، این روش هزینه دارد: دو پاسخ تقریباً دو برابر یک پاسخ خرج دارد. در آزمایش OpenAI، بهبود تا حدود ۴۰۰ پاسخ ادامه داشت و بعد افت کرد — ولی هیچ محصول واقعی‌ای برای هر پرسش ۴۰۰ پاسخ نمی‌گیرد.
مدلی که با تغییر کوچک ورودی، خروجی‌اش خیلی عوض می‌شود، «ناپایدار» است — و بیشترین سود را از چند بار پرسیدن می‌برد. در یک پروژهٔ واقعی، مدل اطلاعات روی عکس محصول را فقط در نیمی از دفعه‌ها می‌خواند و بقیه را «تار است» می‌گفت. با سه بار تلاش برای هر عکس، تقریباً همه خوانده شدند.
خروجی ساختاریافته
در محصول واقعی خروجی مدل اغلب باید قالب مشخصی داشته باشد: یا چون خود کار ساختاریافته است (تبدیل پرسش فارسی به SQL، دسته‌بندی به یکی از چند برچسب)، یا چون خروجی به برنامهٔ دیگری داده می‌شود — مثلاً JSON با کلیدهای مشخص، که در فصل ۶ برای ابزارهای ایجنت حیاتی می‌شود. پنج راه هست، از سبک به سنگین:
حالت JSON که بعضی سرویس‌ها دارند فقط تضمین می‌کند خروجی JSON معتبر باشد — نه اینکه محتوایش درست باشد، و نه اینکه اگر به سقف توکن خورد، ناقص نماند. نکتهٔ جالب دیگر: LinkedIn قالب YAML را به JSON ترجیح داد، چون پرگویی کمتری دارد و توکن کمتری می‌خورد.
طبیعت احتمالی: ناسازگاری و توهم
از دوستتان دو بار با یک دقیقه فاصله بپرسید «بهترین غذای دنیا چیست؟» — هر دو بار یک جواب می‌دهد. مدل ممکن است ندهد: اگر فکر کند غذای ایرانی ۷۰٪ و ایتالیایی ۳۰٪ «بهترین» است، ۷۰٪ دفعه‌ها ایرانی می‌گوید و ۳۰٪ ایتالیایی. این احتمالی بودن همان چیزی است که مدل را برای ایده‌پردازی عالی می‌کند — خلاقیت یعنی بیرون رفتن از مسیرهای رایج — و برای بقیهٔ کارها دردسرساز.
ناسازگاری
دو شکل دارد: ورودی یکسان، خروجی متفاوت (یک پرسش را دو بار بپرسید، دو جواب بگیرید — مثلاً مدلی که به یک انشا یک بار ۳ از ۵ و بار دیگر ۵ از ۵ نمره می‌دهد) و ورودی کمی متفاوت، خروجی بسیار متفاوت (مثلاً فقط یک حرف بزرگ‌تر نوشته شده).
برای شکل اول: پاسخ را ذخیره کنید تا پرسش تکراری همان جواب را بگیرد؛ دما، top-p و top-k را ثابت کنید؛ و بذر تصادفی (seed) را ثابت نگه دارید.
ولی حتی با همهٔ این‌ها تضمین صددرصد نیست: سخت‌افزار هم روی خروجی اثر دارد. اگر از سرویس ابری استفاده می‌کنید، این کنترل دست شما نیست.
برای شکل دوم: ثابت کردن پارامترها کمکی نمی‌کند؛ راهش پرامپت دقیق (فصل ۵) و سامانهٔ حافظه (فصل ۶) است.
ثابت کردن تنظیمات کار خوبی است، ولی اعتماد نمی‌سازد. معلمی را تصور کنید که فقط وقتی در یک اتاق خاص می‌نشیند نمرهٔ ثابت می‌دهد؛ در اتاق دیگر نمره‌هایش بی‌حساب است.
توهم
توهم یعنی پاسخی که ریشه‌ای در واقعیت ندارد — و برای هر کاری که به درستی وابسته است، کشنده است. در ژوئن ۲۰۲۳ یک مؤسسهٔ حقوقی آمریکایی جریمه شد چون پرونده‌ای به دادگاه داده بود که پژوهش حقوقی‌اش را ChatGPT ساخته بود — با رأی‌هایی که هرگز وجود نداشتند.
اگر ناسازگاری از تصادف نمونه‌برداری می‌آید، توهم پیچیده‌تر است: چطور چیزی که مدل هرگز ندیده، گزینهٔ محتملی می‌شود؟ دو فرضیهٔ مکمل هست:
گلوله‌برفی یک جنبهٔ نگران‌کننده دارد: فرض غلط اولیه می‌تواند مدل را در پرسش‌هایی هم به اشتباه بیندازد که در حالت عادی درست جواب می‌داد — مثلاً ادعا کند ۹۶۷۷ بر ۱۳ بخش‌پذیر است، با اینکه خودش می‌داند نیست. و یک نتیجهٔ غافلگیرکننده: در مقالهٔ InstructGPT، مدلی که RLHF دیده بود بیشتر توهم داشت تا مدلی که فقط SFT دیده بود — هرچند برچسب‌زن‌ها در مجموع همان را ترجیح می‌دادند.
با فرض اینکه مدل تا حدی «می‌داند چه می‌داند»، دو ترفند ساده جواب می‌دهد: در پرامپت بنویسید «اگر مطمئن نیستی، بگو نمی‌دانم»، و پاسخ کوتاه بخواهید — هرچه توکن کمتری تولید شود، فرصت کمتری برای ساختن هست. راه‌های جدی‌تر — دادن متن مرجع به مدل (RAG، فصل ۶) و سنجیدن توهم (فصل ۴) — در ادامهٔ دوره می‌آیند.
خودآزمایی
