NLP stuff

اندر حکایات بازی با کلمات: AI Engineering vs ML Engineering/Data Scientist

این روزها عناوینی مثل AI Engineer، ML Engineer و GenAI Engineer زیاد شنیده می‌شوند، اما مرز بین این نقش‌ها همیشه شفاف نیست. بخشی از فصل اول کتاب AI Engineering (از بانو چیپ هوین، از الهه‌های AI) و همچنین این ویدیو دقیقاً روی همین تمایز تمرکز دارند (این کانال یوتیوب هم کانال قابلی است).
اگر بخواهیم به ‌دور از هایپ و با نگاه مهندسی جلو بریم، تفاوت اصلی این دو نقش در «سطح مسئله» است.

تمرکز ML Engineerها و Data Scientistها روی خود مدل است. یعنی طراحی، آموزش و بهینه‌سازی مدل‌های یادگیری ماشین.
مسائلی مثل آماده‌سازی داده، feature engineering، انتخاب معماری، تنظیم هایپرپارامترها و ارزیابی مدل در این حوزه قرار می‌گیرند. هدف اصلی این است که مدل، روی داده‌های موجود، بهترین عملکرد ممکن را داشته باشد.
به زبان ساده، ML Engineer درگیر این سؤال است که: چگونه مدلی بسازم که درست یاد بگیرد و از آن در پروداکشن به درستی استفاده کنم؟

از طرف دیگر، AI Engineering در یک لایه دیگر می‌ایستد و با «سیستمی» سر و کار دارد که نسخه اولیه یک مدل از‌پیش‌آموزش‌داده‌شده از قبل وجود دارد.
در این نقش، مدل معمولاً بخشی از سیستم است، نه کل آن. AI Engineer با طراحی جریان‌های end-to-end، اتصال مدل به ابزارها، APIها، دیتابیس‌ها و رابط کاربری، و همچنین کنترل هزینه، latency، خطا و رفتار سیستم در دنیای واقعی سروکار دارد.
سؤال محوری این نقش این است: چگونه یک سیستم هوشمند با استفاده از یک مدل از‌پیش‌آموزش‌داده‌شده بسازم که در محصول واقعی پایدار و قابل استفاده باشد؟

نکته مهمی که در فصل اول کتاب به آن اشاره می‌شود این است که با ظهور GenAI و مدل‌های پایه، بخش زیادی از ارزش دیگر در آموزش مدل جدید نیست، بلکه در طراحی سیستم، تعامل انسان و مدل، مدیریت خطا و خصوصا طراحی نظام ارزیابی (درباره نظام ارزیابی بعدا بیشتر سخن‌پراکنی خواهیم کرد) نهفته است.
این همان جایی است که AI Engineering اهمیت پیدا می‌کند. نه به این معنا که ML Engineering کم‌اهمیت شده است، بلکه مسئله‌ها تغییر کرده‌اند. همچنان در حوزه‌هایی مثل credit scoring، Dynamic Pricing، ... که با تسک‌های close-ended مثل classification سر و کار داریم، ML Engineering اولین گزینه مطرح است.

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

#book
@nlp_stuff

مفهوم Agent چیست و چگونه کار می‌کنند؟

خانم چیپ هوین بلاگ پست مفصلی راجع به Agent (به قول راسل، هدف غایی هوش مصنوعی) نوشتند. به شدت توصیه می‌کنیم به دور از هایپ بخونید.
این پست ۴ بخش داره: تعاریف، ابزارها، برنامه‌ریزی، ارزیابی و نقاط شکست!

تعاریف. agent هر چیزیه که از محیطش اطلاعات دریافت کنه و روی محیط عملی انجام بده. پس دو مشخصه داره: محیطش و عملگرهاش. محیطش با هدفی که داره تعریف میشه و عملگرهاش با ابزارهایی که در اختیارش قرار دادیم. مثلا یک ایجنت نرم افزاری محیطش میشه ترمینال و فایل سیستم و اکشن‌هاش میشه سرچ کردن و خوندن  و نوشتن در فایلها (عکس ۱). agentها ‌نیاز به مدل قوی‌تری دارند، چون کارهای مهم‌تری می‌کنند و ریسک بالاتری دارند و چون مراحل زیادی طی می‌کنند، خطاها در هم ضرب میشن و مثلا یک مدل با دقت ۹۵٪ در انجام کاری، بعد از ده مرحله، با ۶۰٪ دقت کار نهایی را تحویل میده.

ابزارها. ابزار بیرونی کمک میکنه ورودی بهتر جمع بشه و اکشن‌های بهتری داشته باشیم. اما نباید همه ابزارها را همینجوری در اختیارش بگذاریم چون بعدش فهمیدن و استفاده مفید ازشون سخت میشه. ابزارها سه گروه میشن: knowledge augmentation، capability extension و write actions. دسته‌ی اول ابزارهای تولید محتوا هستند که کمک میکنند بروز باشیم و کمتر هذیون بگیم مثلا سرچ در اینترنت یا API دیتای محصولات فروشگاه. دسته دوم ابزارهای بهبود یهویی توانایی مدل هستند. مثلا مدل‌های زبانی در انجام عملگرهای ساده ریاضی مثل تقسیم هم گاهی گند می‌زنند. پس بهش یه ماشین حساب بدیم یا مثلا از یک مدل تولید عکس جدا استفاده کنیم. دسته سوم. ابزارهایی که تغییر ایجاد میکنند. مثلا ایمیل زدن، انتقال پول.

برنامه‌ریزی. مغز یک agent همون مدلیه که تسک پیچیده را برنامه‌ریزی میکنه. خروجی برنامه یک سری مراحله که باید به ترتیب طی بشه. برنامه‌ریزی باید از اجرا جدا باشه. یعنی از مدل اول میخواهی (مثلا با CoT) برنامه (یا برنامه‌ها) را ارائه بده و بعد از تایید شروع به اجرا کنه. تا اینجا سیستم ما سه قسمت داشت: تولید برنامه، ارزیابش، اجراش (عکس ۲). حالا اگر بیای برای هر کدوم یک agent بذاری، میشه mutli-agent مثلا قبل از هر چیز یه agent تشخیص هدف مشتری (intent) بذاری. راحتترین راه برای تولید برنامه هم پرامپته. مثلا برای آموزش مشتری‌ها راجع به محصولات، به مدل توابع لازم و چند تا مثال از سوالات کاربران و جواب درست را میدیم (عکس ۳‍).
سه تا نکته مهم در تولید برنامه هست: نحوه تعریف و صدا زدن ابزارها، ریزدانگی برنامه، برنامه‌های پیچیده. اولی (نحوه معرفی)، یه سری چارچوب داره که به مدل بفهمونیم لازمه از این ابزارها استفاده کنه یا خودش هر طور صلاح میدونه (عکس ۴). در ریزدانگی باید دقت کنیم که نباید زیاد جزئی (تا اسم تابع) از مدل تولیدکننده بخواهی. چون دوباره تعریف کردن یا فاین تیون کردنشون سخته. خوبه بهشون بگی به زبون طبیعی مراحل را تولید کن. بعد یه مدل ساده‌تر این جملات زبان طبیعی را به اسم توابع تبدیل کنه. برای سومی هم؛ همیشه برنامه‌ها به صورت پشت سر هم نیستند. میتونه موازی یا شرطی باشه یا حلقه داشته باشه (عکس ۵).
در ادامه راجع Reflection صحبت میکنه. agent باید مداوم خودش، خودشو بررسی کنه که از برنامه تا نتیجه همه چی درسته؟ این ارزیابی و اصلاح، میتونه توسط خود agent انجام بشه یا بیرونش. چارچوب‌هایی مثل ReAct هست که یک حلقه متشکل از برنامه، اکشن و ارزیابیه تا وقتی که به جواب برسه (عکس ۶). اگر ارزیاب مدل دیگه‌ای باشه به این Reflexion میگن.
برای نحوه انتخاب ابزارها از مقالاتی مثل Chameleon صحبت میکنه که از ۱۳ تا ابزار استفاده میکنه. هر چی تعداد ابزارها بیشتر باشه، مثل انسان برای مدل سخت‌تره ازشون استفاده کنه. راه‌هایی برای انتخاب مجموعه ابزارها هست؛ مثلا با کدوم ابزارها خطای مدل بیشتره، حذف ابزار چقدر کارایی را کاهش میده، از کدوم‌ها بیشتر استفاده میکنه. مقاله Chameleon نشون داد که تسک‌ها و مدل‌های مختلف ابزارهای مختلفی لازم دارند و نباید همینجوری همه ابزارها رو به مدل بدیم (عکس ۷).

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

لینک پست:
https://huyenchip.com/2025/01/07/agents.html

#read
#blog

@nlp_stuff

خلاصه‌تر فکر کن

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

به تازگی کار جالبی اومده با عنوان Chain of Draft یا CoD که همون CoT هست با این تفاوت که در پرامپت از مدل خواسته می‌شه که هر سگمنت استدلالی (reasoning) که می‌خواد خروجی بده حداکثر ۵ کلمه طول داشته باشه. نتایجش جالب شده و نشون داده که با میزان توکن و در نتیجه latency خیلی کمتر تونسته دقت قابل رقابت با CoT رو حفظ کنه و حتی بعضی جاها بهتر از اون نتیجه بده. خلاصه که یکی از جهت‌های آینده احتمالا اینه که چطور مدل‌هایی داشته باشیم که کاراتر فکر کنند.

لینک پیپر:
https://arxiv.org/abs/2502.18600

#read
#paper

@nlp_stuff

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

عمده استفاده برنامه‌نویس‌ها از LLM‌ها در سطح پیاده‌سازی فانکشن‌ها و یا ادیت تکه‌های مختلف کد بوده. اما آیا LLM‌ها می‌تونند یک پروژه رو به صورت انتها به انتها و ماژولار و البته با کیفیت مناسب پروداکشن پیاده‌سازی کنند؟ یک کار جالبی اومده که سعی کرده برای همین نیازمندی پیاده‌سازی انتها به انتها پروژه‌های بک‌اندی بنچمارک ارائه بده. این بنچمارک که BaxBench نام داره، ۲۸ تا سناریو نیازمندی تعریف کرده و تلاش کرده با ۱۴ تا فریمورک (از شش زبان مختلف) مختلف این نیازمندی‌های رو با LLM‌ها پیاده‌سازی کنه (یعنی سرجمع ۳۹۲ تسک می‌شه). از اونور هم ۱۱ تای LLM‌ پیشرو فعلی رو روی این تسک‌ها گذاشته و خواسته که کدشون رو تولید کنند. برای ارزیابی اما چه کرده؟ دو جهت ارزیابی رو در پیش گرفته، یک جهت فانکشنال تست‌هایی که تعریف کرده و روی کدهای خروجی تست می‌گیره تا ببینه آیا سیستم درست پیاده‌سازی شده یا نه، و جهت دیگه هم این که از نظر امنیتی و آسیب پذیری، کدهای نوشته‌شده رو سنجیده. برای این کار برای هر سناریو، از یک متخصص امنیت خواسته تا اتک‌های ممکن رو تعریف کنه و سپس اونها رو سیستم‌های خروجی تولیدشده اجرا گرفتند تا ببیند وضعشون چه طوریه. پس در نهایت کد خروجی LLM‌ می‌تونه سه وضعیت داشته باشه: اصلا درست نباشه، درست باشه ولی آسیب‌پذیری امنیتی داشته باشه و در نهایت هم درست باشه و هم عاری از آسیب‌پذیری.

نتایج LLM‌های مختلف هم روی این بنچمارک که بهترین‌‌شون که o3-mini بوده باشه حدود ۶۰ درصد از تسک‌ها رو تو فانکشنال تست پاس شده که البته نصف همین رقمش هم دچار آسیب پذیری امنیتی بودند و یعنی o3-mini روی این بنچمارک سرجمع فقط ۳۵.۲ درصد تسک‌ها رو براشون خروجی درست و عاری از آسیب‌پذیری تونسته تولید کنه (البته یک ablation جالبی که زده این بوده که اومده در پرامپت‌دهی به LLM بهش نکات امنیتی رو گوشزد کرده و همینجوری تونسته درصد کدهای درست امن تولیدشده رو بیشتر کنه) البته o3-mini نه بهترین در تولید کد بوده و نه بهترین در امنیت، بلکه شبیه وزنه‌بردارها تونسته در مجموع بهترین باشه. در واقع ممکنه یک مدل در تولید کد عملکرد خوبی داشته باشه ولی در امنیت اون کد نه و بالعکس.

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

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

لینک:
https://baxbench.com/

@nlp_stuff

به سوی سیستم‌۲

پیشرفت‌های هوش مصنوعی در دهه ۲۰۱۰، مدیون آموزش مدل‌های بزرگ دیپ لرنینگی روی دیتاست‌های بزرگ بوده، چیزی که بهش اسکیل‌کردن دیتا و پارامتر گفته می‌شه. با وجود تمام پیشرفت‌های دیپ لرنینگ، اما همچنان شبکه‌های عصبی در برخی مسائل مخصوصا ریزنینگی با سطح انسان فاصله دارند.در چنین شرایطی به قول ایلیا ساتسکیور، دیتا برای هوش مصنوعی به حکم سوخت فسیلی در حال اتمامه و ما دیگه بیشتر از یک اینترنت نداریم تا ازش دیتای آموزشی جدید برای مدل‌هامون بسازیم. وقتی که دیگه نمی‌شه پارامتر‌های مدل و یا داده آموزشی رو اسکیل کرد، شاخه تحقیقاتی جدیدی در پی اسکیل‌کردن میزان محاسبه در زمان اینفرنس یا به اصطلاح inference time compute هست، ایده‌ای که مغز اصلی کارهایی مثل o1 و deepseek هست. این ایده خیلی شبیه بحث‌های دو سیستم پردازشی سیستم‌۱ و سیستم‌۲ در ذهن انسانه. جایی که سیستم‌۱ مسئول اعمال ناخودآگاه و ادراکی انسانه و سیستم‌۲ هم مسئول اعمالی که نیاز به راه‌حل‌های گام به گام دارند (قبلا اینجا راجع بهش صحبت کرده بودیم) حالا این ترم در دانشگاه شریف، درسی با عنوان سیستم‌۲ ارائه شده که قراره به بررسی این داستان و راه‌حل‌های ارائه شده براش بپردازه. موارد زیر جزو سیلابس این درس هستند:

- مقدمه بر مسائل ریزنینگ و سیستم‌۲
- معرفی روش‌های نوروسیمبلیک
- تولید برنامه
- انواع روش‌های پرامپت‌دهی مبتنی بر CoT مثل ToT
- مکانیزم‌های اسکیل‌کردن محاسبه در LLM‌ها
- ریزنینگ با کمک گراف‌های دانش
- نقش LLM Agent‌ها در ریزنینگ
- ارتباط کامپوزیشنالیتی با سیستم‌۲

لینک پلی‌لیست یوتیوب درس:
https://www.youtube.com/playlist?list=PLFr7f4WLNwracR8k8jgYONAp-2pmKrdc3

لینک پلی‌لیست آپارات درس:
https://www.aparat.com/playlist/14269123

لینک کانال تلگرامی درس:
https://t.me/system2_spring2025

پی‌نوشت: اگر میخواید بدانید o1 و deepseek چه ایده‌ و تاریخچه‌ای پشتشونه و مسیر چند سال آتی هوش مصنوعی چه شکلی هست این کورس رو ببینید

#course

@nlp_stuff

مدل‌های استدلالی (reasoning) چیست و چگونه ساخته می‌شوند؟

حتما این روزها بارها مدل‌های استدلالی مثل DeepSeek R1 به گوش و چشمتون خورده. اگر هنوز دقیق نمی‌دونید این مدلها معنیشون چیه و کجا به درد میخورند، بیاید که دواتون پیش آقای سباستین راشکا (نویسنده کتاب Build a Large Language Model From Scratch) هست. ایشون یه بلاگ مشتی راجع به مدل‌های استدلالی (همون reasoning) نوشته و مثل همیشه خیلی خوب داستان را شفاف کرده. این را داشته باشید تا منابع بعدی.

مواردی که در این بلاگ توضیح میده:
- تعریف مدل استدلالی چیه؟
- کجا باید از این مدل‌ها استفاده کنیم؟
- پایپلاین پشت R1 چیه؟
- چهار روش اصلی برای ساختن و بهبود مدلهای استدلالی چیه؟
- نکاتی پیرامون مدل R1
- نکاتی برای توسعه مدل‌های استدلالی با بودجه بسیار کم (حتی به اندازه دانشگاه‌های ایران کم ☺️)

اول میگه استدلال (reasoning) واسه وقتیه که سوالی را حل کنیم که نیاز به راه‌حل پیچیده و چندمرحله‌ای داره. مثلا پایتخت فرانسه کجاست اینجوری نیست ولی مثلا حل یه سوال فیزیک و ریاضی یا سوال acmای اینجوریه.

بعد میاد میگه سه جا خوب نیست اصلا از این مدل‌ها استفاده کنیم:
- وقتی ما نیاز به سرعت و قیمت پایین داریم
- وقتی سوال‌های دانشی (knowledge based) مثل همین پایتخت داریم چون این مدل‌ها دچار هذیان‌گویی میشن
- سوالات ساده چون این مدل‌ها مثل اکثر ما overthink میکنند

در ادامه میاد پایپلاین R1 را به شکل بسیار روان و ساده‌ای توضیح میده. عکس ضمیمه یک کلیتی از این پایپلاینه. میگه deepseek سه تا مدل داده: DeepSeek-R1-Zero، DeepSeek-R1 و DeepSeek-R1-Distill.
اول. با مدل DeepSeek-V3 که سپتامبر بیرون دادن، با یک RL cold start (بدون SFT) شبیه همون RLHF با دو تا reward (یکی دقت و دومی فرمت به جای ترجیح آدمیزاد) آموزش میده؛ و مدل DeepSeek-R1-Zero را درست میکنه. بعد از همین مدل میاد یه داده SFT بزرگ درست میکنه. ریوارد دقت میاد از leetcode استفاده میکنه که نتیجه کد را مستقیما اجرا کنه و بگه!! فرمت هم میاد از یه سری تگ استفاده میکنه که دقیقا با همون فرمت جواب بده.
دوم. بعد دوباره همون مدل زبانی اولیه سپتامبری DeepSeek-V3 را با همین دیتا SFT که در مرحله قبل ساخته شده بود یه بار فاین تیون میکنه و دوباره همون RL رو میزنه. این بار ولی بهش consistency هم اضافه میکنه که مدل سر چند زبانه بودن پنالتی نزنه. از همین مدل دو تا دیتاست SFT میسازه که یکیش با اندازه ۶۰۰ هزارتا chaing of thoughts داره و دیگری با اندازه ۲۰۰هزارتا knowldegeای هستش. بعد میاد یه RL دیگه هم میزنه که دیتاش کد و ریاضی هست. اینجا مدل DeepSeek R1 معروف ساخته میشه.
سوم. از اون دوتا دیتای SFT هم برای آموزش مدل‌های distill استفاده میکنه. البته اینجا distill مثل اون معروفه نیست، اینجا وقتی دیتای sft رو یه مدل قوی درست میکنه و مدل کوچیک (نیم الی ۷۰ میلیاردی) باهاش فاین تیون میشه، بهش میگن distillation.

خلاصه چهار تا روش برای تولید مدل استدلالی میگه:
- روش inference-time scaling: که از پرامپت و اینا استفاده میشه. منابع بیشتری لازمه. گرونتر هم درمیاد چون خیلی حرف میزنه.
- روش RL خالص مثل DeepSeek-R1-Zero
- روش SFT + RL مثل DeepSeek-R1
- روش SFT خالص با distillation: مثل DeepSeek-R1-Distill-Qwen
برای هر کدوم میزان کارایی رو توضیح میده و نهایتا میگه حالت سوم بهترین نتیجه رو میده ولی موارد دیگه هم چیزای جالبی بهمون یاد میده مثل اینکه RL خالی هم به استدلال مدل خیلی کمک میکنه.

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

در نهایت هم میاد نظراتش رو راجع به R1 vs O1 میگه: در کل شبیه هم هستند ولی R1 بهینه‌تر و ارزانتره که دلیلش رو این میدونه که دیپ‌سیک بیشتر روی آموزش مدل وقت گذاشته ولی o1 روی inference-time رفته. و چون ما اندازه مدل o1 رو نمیدونیم خیلی مقایسه منصفانه‌ای نخواهیم داشت. درباره‌ی هزینه هم میگه این ۶ میلیون دلار که معروف شده ترکیب DeepSeek-R1 (همون سپتامبریه که پایه‌ی R1 هست) و R1 هستش ولی هزینه R1 رو دیپ‌سیک مشخص نکرده.

برای موضوع آخر هم میگه کسایی که پول کم هم دارند خوبه برن سراغ Distillation: به لطف مقاله مفصلی که برای R1 نوشتند مشخص شد که این روش هم خیلی موثره. مثلا میگه مقاله‌ای اومده یه مدل به نام Sky-T1 منتشر کرده که با ۴۵۰ دلار (۴۰ تومن) مدل ۳۲ میلیاردی را با ۱۷ هزارتا دیتای sft یه فاین تیون هدفمند کرده و در مواردی شبیه o1 عمل کرده!! موارد مهمی هم ادامش راجع به Journey Learning میگه که دیگه توی پست جا نمیشه :))

لینک پست:
https://sebastianraschka.com/blog/2025/understanding-reasoning-llms.html

#read
#blog

@nlp_stuff

درس یادگیری ماشین شریف

دکتر شریفی زارچی و تیم ۷۰نفرشون، محتوای (ویدیوها، کدها و اسلایدها) درس یادگیری ماشین دانشگاه شریف رو به صورت رایگان منتشر کردند.
سیلابس جلسات (عکس ضمیمه شده) مخصوصا جلسه ۲۰ به بعد، بسیار جذاب و به‌روزه و یک منبع فارسی غنیه. البته موضوعات کلاسیک و بسیار مهم مثل SVM و GMM هم داخلش نیست و در موضوعاتی مثل ensemble learning کم صحبت شده و لازمه از کورس‌های دیگه (کورس انگلیسی اندرو انگ و کورس فارسی دکتر سلیمانی) یاد گرفته بشه. اما در کل قدر بدونیم!

سایت این درس:
https://www.sharifml.ir
لینک پلی‌لیست یوتیوب:
https://www.youtube.com/playlist?list=PLk-NQNQe8Inds3uL0JrE5NwLUM9dBGVsL

#coach
#course

@nlp_stuff

فاین تیون در سال ۲۰۲۵

اخیرا یکی از مهندس‌های هاگینگ فیس به نام فیلیپ اشمیت با یک بلاگ پست زیر و بم «تنظیم دقیق (SFT) مدل‌های زبانی وزن‌باز با هاگینگ فیس» را توضیح داده. نوت‌بوک‌ها و اسکریپت‌های پایتونیش را هم گذاشته.

پست شامل این موارده:
- کجا خوبه فاین تیون کنیم و کجا از پراپمتینگ استفاده کنیم؟
- چطور از کتابخونه‌ای مثل TRL (Transformer Reinforcement Learning) (برای SFT) استفاده کنیم؟
- چطور دیتاست مناسب فاین تیون را آماده کنیم؟
- چطور از روش QLoRA (برای آموزش با کوانتیزیشن ۴ بیتی)، روش Spectrum (برای انتخاب بهینه‌ی لایه‌های پراطلاعات)، Flash Attention و Liger Kernel (برای سریعتر شدن) استفاده کنیم؟
- چطور از کتابخونه‌ی فوق العاده‌ی DeepSpeed و Accelerate برای استفاده از چندین GPU بهره ببریم؟
- چطور ارزیابی کنیم؟
- چطور با استفاده از کتابخونه‌هایی مثل TGI (Text Generation Inference) و vLLM مدلمون را روی پروداکشن ببریم.

خلاصه توصیه می‌کنیم این پست جمع و جور (البته با کلی لینک برای مطالعه عمیق‌تر) را حتما بخونید.

لینک به بلاگ:
https://www.philschmid.de/fine-tune-llms-in-2025

#read
#blog

@nlp_stuff

ابزار markitdown؛ همه چیز را به فرمت markdown تبدیل کن!

ما با معرفی یه ابزار به‌دردبخور برگشتیم!
مایکروسافت یک کتابخونه به نام MarkItDown را به صورت متن‌باز بیرون داده که باهاش می‌تونید فایل‌هایی با فرمت‌های زیر (فرمت‌های آفیسش مهمه) را به فرمت markdown (مثل فایل‌های readme گیت) تبدیل کنید. همچین ابزاری موقع ساختن دیتاست (برای آموزش مدل زبانی مثلا) خیلی میتونه کمک کنه. تا حالا هم بیشتر از ۳۰ هزارتا استار گرفته. فایل ورد فارسی رو هم خوب پشتیبانی می‌کنه اما پی‌دی‌اف فارسیش تعریفی نداره. برای OCR و تبدیل صوت هم به llmها مثل جی‌پی‌تی وصل میشه. خدا بده برکت. فرمت‌های پشتیبانی شده:
• PDF
• PowerPoint
• Word
• Excel
• Images (EXIF metadata and OCR)
• Audio (EXIF metadata and speech transcription)
• HTML
• Text-based formats (CSV, JSON, XML)
• ZIP files (iterates over contents)


لینک ریپو گیتهاب:
https://github.com/microsoft/markitdown/tree/main

#tool

@nlp_stuff

سفت کردن جای پا با فریم‌بندی درست مسائل ML

در ادامه رشته‌پست‌ها از کتاب Designing Machine Learning Systems با یک موضوع مهم از فصل دوم این کتاب در خدمتتون هستیم. فریم‌بندی درست مسائل در حوزه ML می‌تونه درصد موفقیت پروژه‌ها رو در این حوزه تا حد زیادی بالا ببره. برای فریم‌بندی می‌تونیم به این شکست فکر کنیم که چه نوع ورودی باید به مدل بدیم (input features)، چه خروجی باید بگیریم (target labels) و انتظار داریم چه چیزی رو مدل یاد بگیره (objective functions).
درباره مورد اول و دوم یک چاله رایج وجود داره و اون هم وابسته کردن مدل به مفاهیمیه که متغیر هستند. کتاب درباره نوع خروجی دادن مدل یک مثال میزنه و اون هم مساله تشخیص اپ بعدی‌ای ست که کاربر بر روی اون در یک اپ‌استور کلیک می‌کنه. یک مدل اولیه می‌تونه این باشه که خروجی مدل رو یک وکتور به اندازه سایز تمام اپ‌ها درنظر بگیریم و مدل با دادن فیچرهای ترجیحات کاربر، حدس بزنه که احتمال کلیک بر روی هر یک از اپ‌ها چقدر هست. با این فریم‌بندی عملا سایز خروجی مدل به تعداد اپ‌های حاضر بر روی اپ استور bind شده که می‌دونیم با نرخ بالایی تغییر می‌کنه. همچنین مساله شبیه یک multi class classification شده که مساله‌ای به مراتب سخت‌تر از binary classification است. شکل درست کار در این جا می‌تونه ورودی دادن فیچرهایی از ترجیحات کاربر و فیچرهای اپ‌ها به صورت توامان با هم باشه و از مدل بخوایم که بگه فلان اپ رو کاربر کلیک میکنه یا نه (طبق تصاویر در اینجا موقع inference نیاز داریم که به تعداد اپ‌ها مدل رو صدا بزنیم که قابلیت موازی‌سازی داره و مشکلی ایجاد نمی‌کنه ولی در عوض خروجی باینری برای مدل داریم و ابعاد خروجی متغیر نیست).
با این تغییر همچنین نیاز نیست برای adopt شدن مدل با هر اپ جدید، حتما retrain انجام بشه و حتی چالش cold start برای اپ‌های جدید هم تا حدی با الگویابی مدل از اپ‌های قبلی که شبیه اپ‌های جدید هستند، می‌تونه بهتر بشه.
همین چاله برای فیچرهای ورودی هم می‌تونه پیش بیاد که البته کتاب بهش اشاره‌ای نمی‌کنه اما با کمی فکر کردن می‌تونیم مثال‌های مختلفی براش پیدا کنیم. مثلا ممکنه شما در مساله‌تون فیچری داشته باشید که انواع مختلف واکنش‌های کاربر رو بخواید بشمارید و ممکنه مثلا واکنش‌های مثبت، انواع مختلفی داشته باشند که اثر یکسانی در بیزنس دارند اما بسته به برخی تصمیمات دیزاین یا بیزنس کم و زیاد می‌شند. در اینجا یک مفهوم ثابت وجود داره و اون واکنش مثبت کاربره و تفکیک انواع واکنش‌ها باعث میشه روی فیچری تکیه کنید که جزییات بیشتری رو فراهم می‌کنه اما در عوض می‌تونه تغییر کنه و یا حتی مرز مشخصی بین کاربر‌ها برای اون وجود نداره.
نکته‌ای که مهمه اینه که با فریم‌بندی درست مسائل ML می‌تونیم تا حد زیادی از effort مساله کم کنیم و به نوعی جای پامون رو برای توسعه پروژه در آینده سفت‌تر کنیم.

#book

@nlp_stuff

اندر تفاوت‌های ML در ریسرچ و پروداکشن

تا حالا زیاد درباره تفاوت‌های نگاه در یادگیری ماشین به جهت ریسرچ و پروداکشن صحبت شده. اما در این پست به بهانه معرفی کتاب Designing Machine Learning Systems می‌خواستیم که خیلی جمع و جور و خلاصه این تفاوت نگاه رو به رشته تحریر دربیاریم. همون‌طور که در تصویر دوم ضمیمه‌شده مشخصه (این جدول برگرفته از فصل اول این کتابه) یکی از ملموس‌ترین تفاوت‌ها بحث اولویت محاسباتیه که در ریسرچ، بیشتر تمرکز بر روی کوتاه‌تر کردن زمان Train گذاشته میشه اما در پروداکشن بیشتر تمرکز بر روی زمان inference کوتاهه. یا مثلا بحث distribution shiftهای مداوم که در یک مساله تحقیقاتی شاید کمتر اتفاق بیفته.
اما به نظر مهم‌ترین تفاوت که عمدتا باعث fail شدن پروژه‌های ML در صنعت میشه همون سطر اول این جدوله که شاید برای افراد ناملموس‌تر باشه. بله؛ وجود افراد در سازمان با نگاه‌های متفاوت که هر کدوم به نوعی هدف و سهمی از این نوع پروژه‌ها دارند، مهم‌ترین تهدید و همزمان مهم‌ترین فرصت برای این پروژه‌هاست. اگر بتونیم به جای تمرکز بر متریک‌های تکنیکال بر روی بهبود متریک‌های بیزنسی تمرکز کنیم این تهدید رو تبدیل به فرصت کردیم و در غیر این صورت باید بریم خونه‌هامون.
در آینده منتظر پست‌های بعدی از این کتاب باشید.

لینک کتاب:
https://www.amazon.com/Designing-Machine-Learning-Systems-Production-Ready/dp/1098107969

#book

@nlp_stuff

لاما۳ با پشتیبانی از فارسی آمد

سلام بعد از مدتها. گفتیم با یه خبر برگردیم: شرکت متا لاما۳ رو بیرون داد. علی الحساب چند تا بولت راجع بهش بگیم تا جزئیات مفصل‌تر رو در آینده نزدیک بهتون بگیم:
• پشتیبانی از فارسی (لینک دمو در انتهای پست و عکس اول از نمونه سوال و جواب)
• ۱۰ درصد بهبود نسبت به ورژن‌های قبلی داره
• در دو سایز ۸ و ۷۰ میلیاردی در دو نسخه base و instruct ارائه شده
• توکنایزرش با اندازه ۱۲۸ هزار تا آپدیت شده
• باز هم اجازه استفاده تجاری داده شده
• روی ۱۵ تریلیون توکن آموزش داده شده
• روی ۱۰ میلیون نمونه لیبل‌زده شده توسط انسان فاین‌تیون شده
• برای alignment هم از sft و ppo و dpo استفاده شده
• روی mmlu بهترین مدل زبانی وزن‌باز هست (بالای ۸۰)
• مدل ۸ و ۷۰ میلیاردی نسخه instruct یه ترتیب با ۶۲.۲ و ۸۱.۷ در HumanEval وضعیت بسیار خوبی در کدزنی دارند.
• اندازه context window با اندازه پیش فرض ۸۱۹۲ و با قابلیت افزایش

لینک به تصاویری از مدل:
https://t.me/overfit_stuff/313
لینک بلاگ متا:
https://ai.meta.com/blog/meta-llama-3/
لینک بلاگ توضیح و استفاده لاما:
https://huggingface.co/blog/llama3
لینک دمو لاما۳ (پشتیبانی از فارسی):
https://www.llama2.ai/
لینک کالکشن هاگینگ‌فیس:
https://huggingface.co/collections/meta-llama/meta-llama-3-66214712577ca38149ebb2b6



#model


@nlp_stuff

دادگان PCoQA: Persian Conversational Question Answering

دادگان (دیتاست) جدیدی به نام PCoQA منتشر شده که شامل ۹۰۲۶ پرسش از ۸۷۰ صفحه ویکی‌پدیاست. هر گفتمان (conversation) روی یک صفحه ویکی‌پدیا انجام شده و طول هر گفتمان هم حدودا ۱۰ است. به منظور ارزیابی انسانی شبیه دادگان‌های گذشته مثل SQuAD و CoQA، برای هر پرسش در مجموعه‌ی ارزیابی و تست چندین پاسخ دراومده و دقت F1 انسان‌ها و چندین مدل بر روی پاسخ‌دهی به این پرسش‌ها بدست اومده که برای انسان حدودا ۸۶ درصده.

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

دو خصوصیت مهم این دیتاست:
- پرسش‌های این دادگان بیشتر open ended هستند، بر خلاف قبلی‌ها مثل CoQA و SQuAD که بیشتر به شکلی مصنوعی‌ بر روی named entity و noun phrase متمرکزند.
- سعی شده lexical overlap تا حد امکان کاهش داده بشه تا کیفیت بالاتر بیاد.

لینک مقاله: 
arxiv.org/abs/2312.04362

لینک گیت‌هاب:
github.com/HamedHematian/PCoQA

#dataset

@nlp_stuff

شکست gpt3.5 توسط مدل وزن‌باز Mixtral-8x7B-v0.1 !

خلاصه بخوایم بگیم: جدیدا شرکت Mistral.ai یه مدل داده بیرون به اسم Mixtral-8x7B-v0.1 که با هشت تا مدل هفت میلیارد پارامتری Mistral با روش  high-quality sparse mixture of experts model (SMoE) ساخته شده، تونسته در اکثر ارزیابی‌ها هم لاما ۷۰ میلیاردی و هم جی‌پی‌تی۳.۵ رو شکست بده. خوش‌مزگی داستان اینه که یک سال بعد از جی‌پی‌تی ۳.۵ حالا میشه این مدل رو به صورت لوکال (طبیعتا با رم و جی‌پی‌یو به اندازه کافی) سرو کرد. این مدل رو میسترال خیلی لاتی‌طور اول یه لینک تورنت بدون توضیح گذاشت و بعد که ملت به جنب و جوش دراومدند، چند روز بعد یه توضیحی هم منتشر کرد!

مدل mixtral 8x7b که امروز توسط میسترال منتشر شد یک سطح جدیدی برای مدل وزن‌باز (نه متن‌باز، چون کد و دیتا و... رو نداده) را ارائه کرد و تونست مدل چت جی‌پی‌تی ۳.۵ رو در اکثر بنچمارک‌ها شکست بده. معماری این مدل شبیه مدل میسترال ۷ میلیاردیه (به زودی معماری اون هم براتون شرح خواهیم داد) با این تفاوت که در حقیقت این مدل جدید ۸ تا مدل expert در یک پکه. اینجا از یک تکنیک به نام MoE (Mixture of Experts) استفاده شده. این مدل یک مدل دیکودریه که بلوک فیدفوروارد بین ۸ گروه از پارامترها در هر لایه و برای هر توکن دو تا از این کارشناس‌ها (expert) رو انتخاب میکنه که توکن پردازش بشه. در معماری ترنسفورمرها یک سری لایه feed-forward داره، در MoE جای بعضی از این لایه‌ها از لایه‌های MoE استفاده شده است. لایه‌ی MoE یک شبکه‌ی روتری داره که انتخاب میکنه کدوم کارشناس (Expert) کدوم توکن‌ها رو بهتر پردازش می‌کنند. این تکنینم باعث میشه تعدا پارامترها زیاد بشه اما هزینه و سرعت کنترل بشه چون مدل فقط از بخشی از تعداد کل پارامترها رو برای یک توکن استفاده می‌کنه. همونطور که گفتیم در این میکسترال دو تا کارشناس در هر لحظه انتخاب میشن که باعث میشه سرعت دیکودینگ شبیه یه مدل ۱۲.۹ میلیاردی بشه در صورتی که ۴ برابرش (۴۶.۷ میلیارد) پارامتر داره!! یه عده اشتباه فکر میکردند ۵۶ میلیارد (۸*۷) پارامتر داره ولی اشتباهه چون فقط بعضی لایه‌های feed-forward فقط تکرار شدند نه همگی پارامترها. اگر بابت MoE کمی گیج شدید، نگران نباشید چون این یکی هم مفصلا در پست دیگه‌ای شرح میدیم. تا اینجا دو تا  طلبتون پس.

جونمون براتون بگه که مدل پایه و مدل Instruct رو منتشر کردند. طول کانتکستش ۳۲ هزار شده. تونسته مساوی یا بهتر از مدل ۷۰ میلیاردی لاما۲ و  جی‌پی‌تی ۳.۵ در اکثر بنچ‌مارک‌ها باشه. عکس نتایج رو در پیوست گذاشتیم. پنج تا زبون انگلیسی، فرانسوی، آلمانی، اسپانیایی و ایتالیایی رو بلده (به نظر روی دیتای togethercomputer/RedPajama-Data-V2 ترینش کردند، حدس ماست). توی تسک کدزنی هم خوبه و توی HumanEval به ۴۰.۲ رسیده. در نهایتا هم با Apache2.0 منتشرش کردند که همگی صفا کنیم. مدل Instruct فرمت پرامپت خودشو داره که توی لینک‌هایی که آخر میذاریم هست. مثل میسترال ۷b نمیدونیم دیتاستش چیه و چه حجمی داره و چجور پیش‌پردازش شده. دیتای sft و DPO (برای فاین تیون کردن) هم نمیدونیم! کد لود کردن و اینفرنس هم توی لینک‌ها هست که البته حداقل ۳۰ گیگ رم و جی‌پی‌یویی مثل A100 می‌خواد.


لینک بلاگ پست انتشار مدل:
https://mistral.ai/news/mixtral-of-experts/

لینک مدل پایه Mixtral-8x7B-v0.1:
https://huggingface.co/mistralai/Mixtral-8x7B-v0.1

لینک مدل Mixtral-8x7B-Instruct-v0.1:
https://huggingface.co/mistralai/Mixtral-8x7B-Instruct-v0.1

لینک بلاگ هاگینگ‌فیس:
https://huggingface.co/blog/mixtral

#read
#blog
#link
#model

@nlp_stuff

بهبود عملکرد LLM با نشون‌دادن Chain of Thought غلط

مدل‌های زبانی بزرگ با این که کلی از مسائل حوزه پردازش زبان رو درنوردیدند ولی همچنان در برخی مسائل با فاز reasoning‌طور (مثل مثلا حل مسائل ریاضی) دچار مشکلات جدی هستند. یکی از راه‌حل‌های پیشنهادشده برای بهبود عملکرد این مدل‌ها روی این مسائل، راهکار Chain-of-Thought Prompting (به اختصار CoT) هست. تو این راهکار وقتی میخوایم یک مساله را به صورت few-shot به LLM توضیح بدیم عوض این که در example‌هامون صرفا جواب آخر رو بنویسیم و میایم و مرحله به مرحله نحوه رسیدن به جواب رو توضیح می‌دیم و این جوری مدل هم وقتی میخواد به کوئری ما پاسخ بده به نوعی مجبور میشه که مرحله به مرحله جواب رو بنویسه. آزمایشات نشون داده که باعث می‌شه درصد جواب‌های پایانی درستی که می‌ده بیشتر بشه.

حالا یک مقاله اومده و یک ایده به نام contrastive chaint of thought prompting رو مطرح کرده. تو این ایده، علاوه بر این که CoT درست به مدل داده می‌شود بهش CoT اشتباه هم نشون داده می‌شه و آزمایشات مقاله نشون می‌ده که این ایده نشون دادن CoT غلط در کنار CoT باعث میشه تا عملکرد LLM باز هم بهبود پیدا کنه.

لینک مقاله:
https://arxiv.org/abs/2311.09277

#paper
#read

@nlp_stuff